APIコラボレーションとは、重いアプリを起動し、同期を待ってからパネルをクリックして、チームメイトが何を変更したかを確認することを意味していました。しかし、もうそんな手間は必要ありません。APIがOpenAPIファイルで記述されている場合、ほとんどのコラボレーション作業は実際にはテキスト作業です。仕様のバージョン管理、差分のレビュー、共有された変更のマージなど、すべてがターミナルで行えます。
このガイドでは、これらの3つのタスクを処理する軽量なCLIツールについて説明します。ここに挙げられているすべてのツールは数秒でインストールでき、単一のコマンドで実行でき、GitまたはCIに組み込むことができます。GUIも、バックグラウンドデーモンも、変更ログを読むためだけにチーム全員のシート設定も不要です。チームのワークフローに関するより全体像については、APIコラボレーションツールのまとめから始めてください。この記事は、ターミナルファーストに特化したサブセットです。
ここに枠組みを示します。コマンドラインからのコラボレーションは、仕様のバージョン管理(誰がどのバージョンを持っているか)、レビュー(何が変更され、安全か)、共有変更(ある個人の編集を全員の信頼できる情報源にマージする)に分かれます。以下の各ツールは、これらのうち1つか2つをうまくこなします。OpenAPI仕様は、これらのツールが読み書きする公式標準であり、全体を機能させる共有言語です。7つのツール、それぞれの実際のインストール方法とコマンド例、そして選択に役立つ短い表が提供されます。
ボタン
APIコラボレーションにおけるCLIツールの「軽量性」とは
軽量性とは、気分的なものではなく、具体的な基準です。ツールが以下のほとんどを満たしていれば、その資格があります。
- 小さなインストール。単一のバイナリ、`npx`呼び出し、または`npm install -g`の1行で済む。インストーラーも、実行し続けるサービスも不要。
- 高速起動。実行して終了するため、スクリプトやプリコミットフックから呼び出すことができます。
- 低設定。ゼロまたは最小限の設定でプレーンなOpenAPIファイルに対して動作します。`openapi.yaml`を指定してすぐに使えます。
- ターミナルファースト。出力はターミナルで読むか、CIにパイプするために設計されており、Webパネルでレンダリングされることはありません。
- 一つの仕事をうまくこなす。差分比較、公開、またはマージなど、採用しなければならないプラットフォーム全体ではありません。
ツールは、およそ最小で最も特化したものから、最も統合されたものへと並んでいます。最後の項目は例外で、単一目的のバイナリではなく、完全なプロジェクトCLIですが、バージョン管理、レビュー、マージを1か所でカバーするため含められています。
Git + 仕様ファイル (ベースライン)
最も軽量なコラボレーションツールは、すでに持っているものです。OpenAPIファイルをコードの隣のリポジトリにコミットすれば、Gitがバージョン管理、履歴、レビューを無料で処理してくれます。`openapi.yaml`に対するプルリクエストは、変更された正確な行を示し、チームメイトがそれらの行にコメントし、マージが共有された変更となります。これがGitネイティブAPIコラボレーションの背後にある全体的な考え方です。
# リポジトリ内で仕様を追跡し、他のコードと同様に変更をレビューする
git add openapi.yaml
git commit -m "GET /orders にページネーションパラメータを追加"
git diff main -- openapi.yaml
最適な用途:新しいツールを一切使わない履歴管理とレビュー。すべての開発者がすでに知っている。
正直な限界:YAMLの生のGit差分はノイズが多い。キーの並べ替えやインデントの変更は、APIが同一であっても変更として表示されます。これこそが、次に紹介するツールが埋めるギャップです。これらはファイルのテキストではなく、APIの意味を比較します。
oasdiff
oasdiffは、2つのOpenAPI仕様の差分を比較し、変更が破壊的であるかどうかを伝える単一のGoバイナリです。オープンソース(Apache 2.0)であり、数百種類の異なる変更タイプを検出し、その終了コードにより、マージのゲートを簡単に設定できます。CIで実行すれば、破壊的変更はチームメイトに到達する前にビルドを失敗させます。
# インストール (macOS)
brew install oasdiff
# 新しい仕様が既存のクライアントを破壊する場合、ビルドを失敗させる
oasdiff breaking main-spec.yaml pr-spec.yaml
# 終了コード 0 = 安全、終了コード 1 = 破壊的変更が検出された
変更されたすべての内容(破壊的か否かにかかわらず)を人間が読める形式で要約するには、`oasdiff changelog base.yaml revision.yaml`を使用します。
最適な用途:マージゲートとしての破壊的変更検出。高速、スクリプト可能、アカウント不要。
正直な限界:差分比較とレポートは行いますが、ドキュメントの公開やブランチの管理は行いません。1つの鋭い仕事をうまくこなします。
Optic
Opticは、Gitワークフローを念頭に置いてOpenAPIの変更を差分比較、リンティング、レビューを行うnpmインストール型のCLIです。MITライセンスで、`$ref`、`oneOf`、`allOf`などの、単純な差分ツールでは扱いにくいスキーマ形状を理解します。oasdiffが合否判定ゲートを提供するのに対し、Opticはレビューの会話に重点を置いています。作業中の仕様をメインブランチのバージョンと比較し、PRのAPIレベルの変更を要約できます。
# インストール
npm install -g @useoptic/optic
# 現在の仕様をメインブランチの仕様と比較する
optic diff openapi.yaml --base main --check
最適な用途:プルリクエスト内の構造化された変更レビュー。破壊的変更または禁止された変更と見なされるもののルールも含む。
正直な限界:Nodeベースであるため、単一のGoバイナリよりも重く、最大限に活用するには、その設定とチェックルールを採用する必要があります。
Bump.sh CLI
Bump.sh CLIは、ターミナルからAPIドキュメントを公開および差分比較します。ここでのコラボレーションは、共有され、常に最新のドキュメントに関するものです。仕様が変更されるたびに新しいバージョンを`deploy`し、チームメイトやコンシューマーは同じレンダリングされたリファレンスを読みます。`diff`コマンドは、公開されたバージョンとローカルファイル間の変更ログを投稿し、PRコメントに含めるのに便利です。Nodeパッケージ(`bump-cli`)であり、Node 20+が必要で、`preview`と`diff`はトークンなしで動作します。
# インストール
npm install -g bump-cli
# 共有ドキュメントの新しいバージョンを公開する
bump deploy openapi.yaml --doc my-api --token $BUMP_TOKEN
# または、バージョン間の変更ログを取得するだけ
bump diff openapi.yaml --doc my-api
最適な用途:共有された人間が読めるドキュメントを仕様と同期させ続けること、およびレビュー用のターミナルでの差分表示。
正直な限界:ホストされたドキュメントとデプロイフローは、有料のBump.sh製品です。CLIはクライアントであり、共有された表面は彼らのプラットフォーム上に存在します。
Redocly CLI
Redocly CLIは、幅広いOpenAPIツールキットです。仕様のリンティング、バンドル、そしてRedoclyレジストリ(現在はReunite)へのプッシュを行います。`push`コマンドはコラボレーションの要です。これは、組織の残りのメンバーがファイルをやり取りする代わりに、単一の正規ソースからプルできるように、仕様のバージョンを共有レジストリにアップロードします。また、バンドルも重要です。`$ref`を持つマルチファイル仕様が、チームメイトが利用できるクリーンな単一のアーティファクトになるからです。
# インストール不要; npx経由で実行
npx @redocly/cli lint openapi.yaml
npx @redocly/cli bundle openapi.yaml -o dist/openapi.yaml
# バージョンを共有レジストリにプッシュする (APIキーが必要)
npx @redocly/cli push openapi.yaml --organization "Acme" --project "orders-api"
最適な用途:ハウススタイルへのリンティングと、単一の信頼できる情報源としての仕様を共有レジストリにプッシュすること。
正直な限界:`lint`と`bundle`は無料でローカルで実行できますが、`push`とレジストリはRedoclyのホスト型プラットフォームの一部です。より深い仕様編集ワークフローについては、共同API仕様編集に関するガイドをご覧ください。
GitHub CLI (gh)
プルリクエストでレビューが行われる場合、GitHub CLIはその全体のフローをターミナルにもたらします。ブラウザを開かずに、仕様を変更するPRを開き、レビュー担当者をリクエストし、ステータスを確認できます。GitフックでoasdiffまたはOpticと組み合わせれば、仕様のレビューはコードレビューの通常でスクリプト可能な一部となります。
# 仕様変更のPRを開き、レビュー担当者をタグ付けする
gh pr create --title "/orders ページネーションを追加" --body "page + limit パラメータを追加"
gh pr review --approve
最適な用途:チームがすでにGitHubを利用している場合、シェルからレビューとマージの会話を主導すること。
正直な限界:APIのセマンティクスではなくPRを管理します。変更が破壊的であるかどうかは認識しません。それはoasdiffやOpticを連携させる目的です。
Apidog CLI
Apidog CLIは、ここでは異質な存在です。単一目的のバイナリではなく、Apidogプラットフォームと同じ設計、バージョン管理、コラボレーションデータにターミナルからアクセスできる完全なプロジェクトリソースCLI(`npm install -g apidog-cli`)です。コラボレーションにおいては、`branch`、`merge-request`、`git-connection`の3つのコマンドグループが重要です。
Apidogはオープンソースではありません。無料ティアのある商用製品です。しかし、差分ツール、ドキュメントパブリッシャー、レジストリを手動でつなぎ合わせたくない場合、無料ティアとCLIがあれば、仕様ブランチ、レビューフロー、Gitバックアップが1か所で手に入ります。
まず、独立したブランチから始めます。`--type`フラグはブランチモデルを選択します。スコープを絞った機能やリリースには`sprint`、継続的な作業には`general`、エージェントがソースを触らずにリソースを編集する独立したブランチには`ai`です。
# インストールと認証
npm install -g apidog-cli
apidog login --with-token $APIDOG_TOKEN
# 共有変更のためにスプリントブランチを作成する
apidog branch create --type sprint --name "orders-pagination"
ブランチの準備ができたら、直接マージする代わりにマージリクエストを開きます。これがレビューゲートです。メインが保護されている場合、編集者がリクエストを作成し、管理者が承認してから変更が反映されます。マージでは、指定したリソースのみが選択されるため、共有変更のスコープは維持されます。
# レビューのために変更を提案する(保護されたメインに対して安全)
apidog merge-request create --branch "orders-pagination" --endpoint-ids 1,2
そして、`git-connection`は、各モジュールのOpenAPIファイルをGitリポジトリ(GitHub、GitLab、Azure DevOpsがサポートされています)にバックアップし、コードと一緒にバージョン管理にミラーリングします。
# プロジェクトの仕様をGitリポジトリに接続してバックアップと履歴を作成する
apidog git-connection --help
出力は`agentHints.nextSteps`を含む構造化されたJSONであり、CLIをスクリプトやAIエージェントから簡単に操作できます。完全なコマンドリファレンスについては、Apidog CLI完全ガイドをご覧ください。
最適な用途:別々のツールを組み合わせることなく、統合されたバージョン管理+レビュー+マージフローを提供し、チームとエージェントのために構築されたブランチモデル。
正直な限界:プラットフォームCLIであるため、ここにあるツールの中で最もインストールが重く、生のローカルファイルではなくApidogプロジェクトと通信します。OpenAPIリンターもありません。スタイルルールにはRedoclyまたはSpectralを使用してください。チームがブランチに加えてロールベースのアクセス制御を必要とする場合は、RBACによるセキュアなAPIコラボレーションについてお読みください。
選び方
ツールをコラボレーションの仕事に合わせて選びましょう。その逆ではありません。
| ツール | 最適な用途 | インストール | オープンソース? | 備考 |
|---|---|---|---|---|
| Git + 仕様ファイル | 履歴管理とレビュー、新しいツールは不要 | すでにインストール済み | はい (Git) | YAMLではノイズが多く、セマンティックな差分ツールと組み合わせる |
| oasdiff | 破壊的変更のマージゲート | brew install oasdiff |
はい (Apache 2.0) | 終了コードで破壊的変更時にCIを失敗させる |
| Optic | PRでの構造化された変更レビュー | npm i -g @useoptic/optic |
はい (MIT) | $ref, oneOfなどを理解する |
| Bump.sh CLI | 共有ドキュメントの公開 + 差分比較 | npm i -g bump-cli |
CLIはオープン、ホスティングは有料 | Node 20+; diff/previewはトークン不要 |
| Redocly CLI | リンティング、バンドル、レジストリへのプッシュ | npx @redocly/cli |
CLIはオープン、レジストリは有料 | pushにはAPIキーが必要 |
| GitHub CLI | シェルからのPRレビューの推進 | brew install gh |
はい (MIT) | PRを管理し、APIのセマンティクスは管理しない |
| Apidog CLI | 統合されたバージョン管理 + レビュー + マージ | npm i -g apidog-cli |
いいえ (無料ティアあり) | branch / merge-request / git-connection |
ほとんどのチームはいくつかのツールを組み合わせて使用します。一般的な軽量スタックは、仕様をGitにコミットし、oasdiffまたはOpticをマージゲートとして実行し、Bump.shまたはRedoclyで公開するというものです。ブランチング、レビュー、マージを単一のCLIから実行したい場合は、Apidogがそのすべてをカバーします。スタックの選択に関するより広範な視点については、APIコラボレーションチームツールガイドが各オプションを比較しています。
まとめ
ターミナルからのコラボレーションは3つの動きから成ります。仕様のバージョン管理、差分のレビュー、共有変更のマージです。Gitが最初を処理し、oasdiffとOpticが2番目を洗練させ、Bump.shとRedoclyが結果を公開し、ghがPRを駆動します。Apidog CLIは、バージョン管理、レビュー、マージを、チームとエージェントのために構築されたブランチモデルを持つ1つのコマンドセットに統合します。
ツールを一つ一つ組み合わせるのではなく、統合された経路を望みますか?Apidogをダウンロードし、`apidog-cli`をインストールして、今使っているターミナルから最初の`apidog branch create`と`merge-request`を実行してみてください。そこからCLIをCIに組み込むのは、次の簡単なステップです。
