API管理向けの無料オープンソースCLIツール

API管理といえば、かつてはGUIコンソールとベンダーからの請求書を意味していました。それらは今でも存在しますが、実際の作業の多くは今やターミナルから行われています。設定ファイルでルート、プラグイン、レート制限を定義し、Gitにコミットして、CLIにゲートウェイへプッシュさせます。ダッシュボードをクリックすることなく、デプロイされたものとレビューされたものの間にずれが生じることもありません。

ここでは、オープンソースという側面が重要になります。独自のゲートウェイを運用する場合、ライセンスによって、席ごとの支払いをせずに何をセルフホストし、フォークし、出荷できるかが決まります。以下のツールのほとんどはApache 2.0またはMPL 2.0であり、これはソースが利用可能で、どこでも実行でき、ユーザーごとのコストがかからないことを意味します。これは、最小のバイナリを選ぶのとは異なる視点です。ここでは、ライセンス、セルフホスティング、そしてGitHubリポジトリがどれだけ活発であるかが問題となります。

これは、コマンドラインの利用が可能な真のオープンソースゲートウェイのリストです：decKを伴うKong Gateway OSS、Tyk、KrakenD Community Edition、Apache APISIX、そしてGravitee。それぞれについて、ライセンス、CLIが実際に何をするのか、そして実際に貼り付けて使えるインストールおよび実行コマンドを紹介します。より広範な分野を知りたい場合は、「オープンソースAPI管理ツール」のまとめ記事がプラットフォームを網羅しています。この記事は、そのターミナルファーストな切り口です。依存している規約を一度も読んだことがない場合は、公式のApache 2.0ライセンス文言を一読する価値があります。

まず、正直な注意点があります。Apidogは最後に登場しますが、オープンソースのエントリではありません。なぜなら、そうではないからです。これはフリーミアムモデルの商用製品です。そうではないものをそうであるかのように見せかけることなく、それがどこに位置づけられるかを説明します。

API管理においてCLIツールを「オープンソース」にするもの

3つの要素が、本物のオープンソースオプションと、カウントダウン付きの無料トライアルを区別します。

ライセンス。クライアントSDKだけでなく、コアゲートウェイでApache 2.0、MIT、またはMPL 2.0を探してください。Apache 2.0は、自由にセルフホストおよび変更することを可能にします。MPL 2.0（Tykの選択）はファイルレベルのコピーレフトであり、MPLファイルがオープンなままであれば、プロプライエタリなコードと組み合わせることができます。「ソース利用可能」またはBSLとラベル付けされたものは同じではないため、リポジトリ内の実際のLICENSEファイルを読んでください。

セルフホスティング。ゲートウェイは、ライセンスサーバーがホームに電話することなく、あなたのインフラストラクチャ上で動作します。あなたがデータプレーンを制御します。「コミュニティエディション」がデモと化すほど機能が制限されている場合、それはカウントされません。

メンテナンスされたリポジトリと動作するCLI。GitHubのスター数を確認するだけでなく、コミット履歴も確認してください。コマンドラインから宣言的に設定でき、Gitでバージョン管理し、CIで実行できるゲートウェイが、このリストの最も重要なポイントです。これら全ての背後にある一般的な管理概念については、「API管理が実際にカバーするもの」を参照してください。

Kong Gateway OSS (decK付き)

Kong Gateway OSSは、KongのApache 2.0ライセンスビルドです。Kong Inc.は、エンタープライズ版とは別に、Apache 2.0コードのみを求める人々のためにOSSビルドを提供し続けています。ゲートウェイ自体はAdmin APIを通じて設定されますが、実際に使用するツールはdecKです。

decKはKongの宣言型設定CLIです。実行中のゲートウェイの状態をYAMLファイルにダンプし、編集して、同期し直します。最初に差分が表示されるため、変更前に何が変更されるかを正確に確認でき、設定のずれがサイレントではなく可視化されます。

# 現在のKong設定をファイルにエクスポート
deck gateway dump -o kong.yaml

# 宣言型設定をゲートウェイにプッシュ
deck gateway sync kong.yaml

最適な用途：KongのInfrastructure-as-Code。すでにKongを運用しており、レビューとCIでGitにルートとプラグインを管理したい場合、decKがその答えです。正直な限界：Kong固有であり、ドキュメント作成やテストではなく、設定を管理します。また、Kongのフルスタックを実行することになり、これはシングルバイナリゲートウェイよりも重いです。

Tyk

TykのゲートウェイはMozilla Public License 2.0のもとでオープンソースです。MPLはファイルレベルのコピーレフトであり、MPLライセンスファイルの変更はオープンなままでなければなりませんが、プロプライエタリなプラグインが別のファイルに存在する場合、それらをゲートウェイとバンドルすることができます。Goで書かれたコアゲートウェイは、REST、GraphQL、TCP、およびgRPCをサポートしています。

多くの人が使うコマンドライン機能は、v2.8以降ゲートウェイバイナリ内に同梱されているバンドラーです。これは、カスタムミドルウェアプラグインを、ゲートウェイがロードできる署名付きバンドルにパッケージ化します。

# マニフェストとミドルウェアファイルからプラグインバンドルを構築
tyk bundle build -o bundle.zip

最適な用途：カスタム認証や変換プラグインでゲートウェイを拡張したいチームで、それらを繰り返しパッケージ化する方法が必要な場合。正直な限界：CLIはバンドルに特化しており、ゲートウェイ全体の完全な宣言型設定には対応していません。Tykの管理の多くは、依然としてダッシュボード（有料部分）またはGateway APIを直接通じて行われます。

KrakenD Community Edition

KrakenDはステートレスで高性能なゲートウェイであり、Community EditionはApache 2.0のもとで完全なコア機能セットを提供します。ステートレスであることが興味深い点です。データベースは不要です。ゲートウェイは完全に設定ファイルによって定義され、GitやCIに自然に適合します。

`krakend`バイナリがCLIです。`check`で設定を検証し、`run`でゲートウェイを実行します。単一のGoバイナリであるため、インストールは1回のダウンロードで済みます。

# デプロイ前に設定を検証し、リンティングする
krakend check -c krakend.json --lint

# その設定でゲートウェイを実行する
krakend run -c krakend.json

Flexible Configuration機能（`FC_ENABLE=1`）により、一つの大きな設定を変数を含むテンプレートファイルに分割できるため、環境をDRY（Don't Repeat Yourself）に保つことができます。最適な用途：設定ファイルが唯一の真実のソースとなる、宣言型でステートレスなゲートウェイ。正直な限界：CEには組み込みの永続性や管理UIがありません。トグルをクリックするのではなく、設定で動作を構成するため、IaCを好むなら機能ですが、そうでないなら手間がかかります。

Apache APISIX

Apache APISIXは、Apache Software Foundationのトップレベルプロジェクトであり、Apache 2.0ライセンスです。そのガバナンスはオープンソースの問題において重要です。これは単一ベンダーのコミュニティエディションではなく、財団プロジェクトであるため、OSSビルドは簡略化されたお試し版ではなく、真のプロジェクトです。

APISIXには、ライフサイクル操作のための制御CLIと、ルートおよびプラグイン管理のためのREST Admin API（デフォルトで`127.0.0.1`にバインド）があります。CLIはゲートウェイを開始、停止、再ロードします。`apisix reload`は接続を切断することなく設定変更を反映します。

# 利用可能な制御コマンドを見る
apisix help

# ゲートウェイを起動し、設定変更後にホットリロードする
apisix start
apisix reload

最適な用途：Admin APIによって駆動され、再起動なしで実行時にルートやプラグインを変更したい動的で高スループットなルーティング。正直な限界：ルーティング設定は、単一の宣言型CLIプッシュではなくAdmin APIに存在するため、「Gitでの設定」ワークフローは通常、Admin API呼び出しのスクリプト化、またはAPISIXのADCのようなツールを追加することを意味します。

Gravitee

GraviteeのコアAPI管理プラットフォームは、Apache 2.0のもとでオープンソースです。これはゲートウェイ以上のものです。Community EditionにはAPIM Gateway（ランタイム）、APIM API（REST管理インターフェース）、APIM Consoleが含まれています。イベントネイティブな非同期APIのようなエンタープライズ機能は有料版にありますが、REST中心のコアは、セルフホスト可能な真のOSSです。

コマンドラインに関する話には正直な注意が必要です。Graviteeの日常管理は、そのManagement REST APIとConsoleを通じて行われ、公式のセルフホストインストールはDocker CLIで実行されることが多いです。GitHubには、Management APIをラップしてモジュール間のアクションを自動化するコミュニティによってメンテナンスされている`graviteeio-cli`がありますが、これはコミュニティツールであり、公式のバイナリではないため、それに依存する前に他のコミュニティプロジェクトと同様にそのメンテナンス状況を評価してください。

# Gravitee APIMゲートウェイコンテナを実行する (セルフホスト、OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

最適な用途：単なるプロキシではなく、完全なオープンソース管理層（ゲートウェイ、コンソール、スクリプトで操作可能な管理API）を求めるチーム。正直な限界：公式の自動化インターフェースはREST Management APIであり、洗練された単一のCLIではありません。コミュニティCLIがそのギャップを埋めますが、そのメンテナンスリスクを負うことになります。

Apidogの立ち位置（そしてオープンソースリストにない理由）

Apidogはオープンソースではないため、上記のリストに含めるべきではありません。これはフリーミアムモデルの商用製品です。これをApache 2.0に分類するのは、あなたを誤解させることになります。

とにかく、正直な説明をします。上記のツールはゲートウェイであり、トラフィック、ルート、プラグインを管理します。これらはAPIスキーマを設計したり、エンドポイントテストを実行したり、ドキュメントを生成したり、バックエンドが存在する前にレスポンスをモックしたりすることはありません。これらのジョブを連携させるには、通常、Spectral、openapi-generator、モックサーバー、Newmanを組み合わせることになり、それぞれ独自の設定が必要です。Apidogは、設計、テスト、モック、ドキュメント作成を1つのワークスペースにまとめ、`apidog-cli`はこれらすべてへのターミナルパスを提供します。

# Apidog CLIをインストールして認証する
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# CIでテストシナリオを実行する（失敗すると非ゼロで終了）
apidog run

CLIは`agentHints.nextSteps`を含む構造化されたJSONを出力するため、CIやAIエージェントのワークフローにスムーズに組み込めます。Claude Codeなどを通じてAPI作業をルーティングしている場合、「AIエージェントから離れずにAPIを管理する方法」がそのパターンをカバーしています。また、OpenAPIのインポートとエクスポート、シナリオの実行、コマンドラインからのモック駆動もサポートしています。Apidog CLIの完全ガイドは、コマンドグループを詳しく説明しています。セルフホスト型OSSゲートウェイの代替ではなく、それに並ぶ統合されたフリーミアムオプションと考えてください。

選び方

スターの数ではなく、ワークフローで選びましょう。すでにKongを運用しているなら、decKが最も手軽な選択肢です。ファイルによって完全に定義されるステートレスなゲートウェイを求めるなら、KrakenDが適しています。APISIXは動的なランタイムルーティング変更で優れており、Graviteeはコンソール付きの完全な管理レイヤーを提供します。商用プラットフォームを含むより広範な比較については、「2026年版ベストAPI管理ツール」およびAPIファーストなスタックを構築している場合は「ヘッドレスAPI管理」の視点も参照してください。

まとめ

CLIからのオープンソースAPI管理は成熟しています。decKを伴うKong Gateway OSS、Tyk、KrakenD CE、Apache APISIX、そしてGraviteeはすべてApache 2.0またはMPL 2.0であり、すべてセルフホスト可能で、ターミナルから制御できます。これは、ダッシュボードをクリックする代わりにGit、レビュー、CIを意味します。あなたのデプロイ方法に合うモデルを選びましょう。

ゲートウェイが扱わない設計、テスト、モック、ドキュメントについては、統合ツールがそのギャップを埋めます。Apidogをダウンロードし、パイプラインで`apidog run`を実行してCLIパスを確認し、その後、どのOSSゲートウェイを採用するかにかかわらず、それをCIに組み込んでください。