API管理といえば、かつてはGUIコンソールとベンダーからの請求書を意味していました。しかし現在の運用では、設定ファイルでルート、プラグイン、レート制限を定義し、Gitにコミットし、CLIからゲートウェイへ反映するワークフローが主流です。レビュー済みの設定をそのままデプロイできるため、ダッシュボード上の手作業による設定ドリフトも減らせます。
オープンソースのゲートウェイを選ぶときは、単に小さなバイナリかどうかではなく、ライセンス、セルフホスティングの可否、リポジトリの活動状況を確認する必要があります。以下で扱うツールの多くはApache 2.0またはMPL 2.0で提供されており、ユーザー単位のライセンスコストなしでセルフホスト、変更、運用できます。
この記事では、CLIで運用できるオープンソースAPIゲートウェイを紹介します。
- Kong Gateway OSS + decK
- Tyk
- KrakenD Community Edition
- Apache APISIX
- Gravitee
それぞれについて、ライセンス、CLIで実行できる操作、すぐ試せるコマンド、向いている運用モデルを確認します。より広い選択肢を比較したい場合は、オープンソースAPI管理ツールも参照してください。ライセンスの前提を確認するなら、公式のApache 2.0ライセンス文言も読んでおくとよいでしょう。
なお、最後に紹介するApidogはオープンソースではありません。フリーミアム型の商用製品として、OSSゲートウェイとは異なる役割を持ちます。
API管理CLIを「オープンソース」と呼ぶための条件
無料トライアル付きの製品と、実運用できるオープンソースソフトウェアを区別するには、次の3点を確認します。
1. コアゲートウェイのライセンス
確認対象はクライアントSDKではなく、ゲートウェイ本体です。Apache 2.0、MIT、MPL 2.0などのライセンスを確認してください。
- Apache 2.0: セルフホスト、変更、配布が可能
- MPL 2.0: ファイル単位のコピーレフト。MPL対象ファイルの変更は公開が必要ですが、別ファイルのプロプライエタリコードと組み合わせられる
- ソース利用可能やBSL: OSSライセンスとは同一ではない
製品ページの説明だけで判断せず、リポジトリ内のLICENSEファイルを確認しましょう。
2. ライセンスサーバーに依存しないセルフホスティング
ゲートウェイが自分のインフラ上で動作し、データプレーンを自分で制御できることが重要です。「Community Edition」であっても、主要機能が大幅に制限されて実用にならない場合は、OSS運用の選択肢として慎重に評価すべきです。
3. 継続的にメンテナンスされるCLIとリポジトリ
GitHubスター数だけでなく、コミット履歴、Issue対応、リリース頻度を確認してください。特に重要なのは、設定を宣言的に管理でき、Gitでバージョン管理し、CIから実行できることです。
API管理全体の役割については、API管理が実際にカバーするものも参照してください。
Kong Gateway OSS + decK
Kong Gateway OSSは、Apache 2.0ライセンスで提供されるKongのOSSビルドです。ゲートウェイ自体はAdmin API経由で設定できますが、GitOpsやInfrastructure as Codeで運用する場合はdecKが実用的です。
decKはKongの宣言型設定CLIです。実行中の設定をYAMLへエクスポートし、レビュー後に差分を確認して同期できます。
# 現在のKong設定をファイルにエクスポート
deck gateway dump -o kong.yaml
# 変更内容を確認してから同期する
deck gateway diff kong.yaml
# 宣言型設定をゲートウェイに反映
deck gateway sync kong.yaml
CIでは、kong.yamlへの変更をプルリクエストでレビューし、マージ後にdeck gateway syncを実行する構成にすると、設定変更を追跡しやすくなります。
最適な用途: Kongのルートやプラグイン設定をGitで管理するIaCワークフロー。
注意点: decKはKong専用であり、API設計、テスト、ドキュメント生成を行うツールではありません。また、Kongのフルスタックを運用するため、単一バイナリ型ゲートウェイより構成は重くなります。
Tyk
Tyk GatewayはMozilla Public License 2.0でオープンソースとして提供されています。Goで実装されたコアゲートウェイは、REST、GraphQL、TCP、gRPCをサポートします。
CLIでよく使われる機能は、カスタムミドルウェアプラグインをパッケージ化するバンドラーです。tyk bundle buildを使うと、マニフェストとミドルウェアファイルから、ゲートウェイがロードできる署名付きバンドルを生成できます。
# マニフェストとミドルウェアファイルからプラグインバンドルを構築
tyk bundle build -o bundle.zip
カスタム認証、リクエスト変換、レスポンス変換などをプラグインとして運用する場合は、バンドル生成をCIジョブに含めると再現性を確保できます。
最適な用途: カスタム認証や変換プラグインを繰り返しビルド・配布したいチーム。
注意点: CLIは主にプラグインバンドル向けです。ゲートウェイ全体を宣言的に管理するCLIではなく、多くの管理操作はGateway APIまたは有料のダッシュボードを通じて行います。
KrakenD Community Edition
KrakenD Community Editionは、Apache 2.0ライセンスのステートレスな高性能APIゲートウェイです。データベースを必要とせず、ゲートウェイの状態を設定ファイルだけで定義できます。
設定ファイルをGitの唯一の信頼できる情報源にしたい場合、KrakenDは扱いやすい選択肢です。krakendバイナリで設定検証とゲートウェイ起動を実行します。
# デプロイ前に設定を検証し、リンティングする
krakend check -c krakend.json --lint
# 検証済みの設定でゲートウェイを実行する
krakend run -c krakend.json
CIでは、デプロイ前のチェックとして次を実行できます。
krakend check -c krakend.json --lint
Flexible Configurationを使う場合は、FC_ENABLE=1を設定してテンプレートや環境変数を利用できます。環境ごとに巨大な設定ファイルを複製せずに済みます。
FC_ENABLE=1 krakend run -c krakend.json
最適な用途: 設定ファイルだけで完全に定義する、宣言型・ステートレスなゲートウェイ。
注意点: Community Editionには組み込みの永続ストアや管理UIはありません。GUIでトグルを切り替えるのではなく、設定ファイルで挙動を管理する運用が前提です。
Apache APISIX
Apache APISIXはApache Software Foundationのトップレベルプロジェクトで、Apache 2.0ライセンスで提供されています。単一ベンダーの限定版ではなく、ASFプロジェクトとして運営されている点も、OSS採用の判断材料になります。
APISIXにはライフサイクル操作のためのCLIと、ルート・プラグイン管理のためのREST Admin APIがあります。CLIは起動、停止、再読み込みに使います。
# 利用可能な制御コマンドを確認
apisix help
# ゲートウェイを起動
apisix start
# 設定変更をホットリロード
apisix reload
apisix reloadは、接続を切断せずに設定変更を反映するために使えます。ルートやプラグインの動的な更新は、通常Admin APIを介して実施します。
最適な用途: 高スループットな動的ルーティングと、実行時のルート・プラグイン変更が必要なケース。
注意点: ルーティング設定の中心はAdmin APIです。Gitベースの運用を行う場合は、Admin API呼び出しをスクリプト化するか、APISIX ADCのような補助ツールを追加する必要があります。
Gravitee
GraviteeのコアAPI管理プラットフォームはApache 2.0でオープンソースとして提供されています。単なるゲートウェイではなく、次のコンポーネントを含むAPI管理レイヤーです。
- APIM Gateway
- APIM API
- APIM Console
REST中心のコア機能はセルフホストできます。一方、イベントネイティブな非同期APIなど、一部のエンタープライズ機能は有料版に含まれます。
セルフホスト環境では、Docker CLIでゲートウェイを起動できます。
# Gravitee APIMゲートウェイコンテナを実行する
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest
日常的な管理はManagement REST APIとConsoleを中心に行います。GitHubにはgraviteeio-cliもありますが、これは公式バイナリではなくコミュニティメンテナンスのツールです。CIに組み込む前に、リリース状況やメンテナンス状態を確認してください。
最適な用途: ゲートウェイに加えて、コンソールとスクリプト操作可能な管理APIを備えたOSS管理レイヤーが必要なチーム。
注意点: 公式の自動化インターフェースは単一の統合CLIではなく、Management REST APIです。コミュニティCLIを採用する場合は、その依存関係と保守リスクも運用対象になります。
Apidogの立ち位置（オープンソースリストに含まれない理由）
Apidogはオープンソースではありません。フリーミアム型の商用製品であり、Apache 2.0やMPL 2.0のOSSゲートウェイとして分類すべきではありません。
ただし、役割はゲートウェイと競合するものではありません。上記のツールは、主にトラフィック、ルート、プラグインを管理します。一方で、APIスキーマ設計、エンドポイントテスト、ドキュメント生成、バックエンド実装前のモックといった作業には別のツールチェーンが必要になります。
Apidogは、設計、テスト、モック、ドキュメント作成を1つのワークスペースにまとめ、apidog-cliでCLIからも実行できるようにします。
# Apidog CLIをインストールして認証する
npm install -g apidog-cli
apidog login --with-token <TOKEN>
# CIでテストシナリオを実行する
# テスト失敗時は非ゼロ終了
apidog run
CLIはagentHints.nextStepsを含む構造化JSONを出力するため、CIやAIエージェントのワークフローへ組み込みやすい設計です。AIエージェント経由のAPI運用については、AIエージェントから離れずにAPIを管理する方法を参照してください。
OpenAPIのインポート・エクスポート、シナリオ実行、モック駆動のワークフローもCLIから扱えます。利用可能なコマンドグループはApidog CLIの完全ガイドで確認できます。
Apidogはセルフホスト型OSSゲートウェイの代替ではなく、ゲートウェイが扱わない設計・テスト・モック・ドキュメントを補う統合オプションとして考えるのが適切です。
選び方
| ツール | 最適な用途 | ライセンス | オープンソース？ | CLI / コマンド |
|---|---|---|---|---|
| Kong Gateway OSS + decK | GitでのKong IaC設定 | Apache 2.0 | はい | deck gateway sync |
| Tyk | カスタムプラグインのバンドル、マルチプロトコル | MPL 2.0 | はい | tyk bundle build |
| KrakenD CE | ステートレスな設定コード型ゲートウェイ | Apache 2.0 | はい | krakend run |
| Apache APISIX | 動的な高スループットルーティング | Apache 2.0 | はい（ASFプロジェクト） |
apisix start / apisix reload
|
| Gravitee | OSS管理レイヤーとコンソール | Apache 2.0 | はい（コア） | Docker CLI / REST API |
| Apidog CLI | 設計、テスト、モック、ドキュメントの統合 | フリーミアム | いいえ | apidog run |
スター数ではなく、実際の運用ワークフローで選びましょう。
-
すでにKongを運用している:
decKでGitOpsを導入する - 設定ファイルだけでゲートウェイを定義したい: KrakenD
- 実行時にルーティングを変更したい: Apache APISIX
- コンソール付きの管理レイヤーが必要: Gravitee
- カスタムミドルウェアを配布したい: Tyk
商用製品も含めた比較は、2026年版ベストAPI管理ツールを参照してください。APIファーストな構成を検討している場合は、ヘッドレスAPI管理の考え方も参考になります。
まとめ
CLIから運用できるオープンソースAPI管理は成熟しています。
- Kong Gateway OSS + decK
- Tyk
- KrakenD Community Edition
- Apache APISIX
- Gravitee
これらはApache 2.0またはMPL 2.0で提供され、セルフホストでき、ターミナルから制御できます。ダッシュボード操作中心の運用ではなく、Git、コードレビュー、CIを中心にした変更管理を実現できます。
ゲートウェイが扱わないAPI設計、テスト、モック、ドキュメントについては、統合ツールで補完できます。Apidogをダウンロードし、まずパイプラインでapidog runを実行してCLIベースのテストを確認してから、採用するOSSゲートウェイとCIで連携させてください。
Top comments (0)