DEV Community: Akira

Claudeマネージドエージェント vs Agent SDK (2026年): 選び方

Akira — Tue, 19 May 2026 10:25:32 +0000

Claude で本番環境向けの AI エージェントを出荷する場合、最初に決めるべきことは「エージェントループをどこで動かすか」です。Anthropic に Claude マネージドエージェントでループとサンドボックスをホストさせるのか、それとも Claude エージェント SDK を使って自分のプロセス内で実行するのか。この選択は、アーキテクチャ、コスト、データレジデンシー、オンコール体制に直接影響します。

今すぐ Apidog を試す

結論

次の基準で選びます。

Claude マネージドエージェント: Anthropic にエージェントループ、サンドボックス、セッション状態をホストさせたい場合。長時間実行される非同期ジョブや、インフラ運用よりランタイム料金を支払う方が合理的な場合に向いています。
Claude エージェント SDK: ループを自社プロセス内に保持し、ツール実行、データレジデンシー、監査、コスト構造を細かく制御したい場合に向いています。

どちらも MCP と Claude モデルに対応しています。違いは「モデル」ではなく「運用責任の境界」です。

はじめに

2026年に「AI エージェントを構築する」と言う場合、それは単にチャット補完の周りに while ループを書くことではありません。実際の本番エージェントは、決済 API、チケット管理 API、在庫サービス、社内検索 API、MCP サーバーなどを呼び出して作業します。

つまり、エージェントの信頼性はモデルだけでなく、エージェントが呼び出す API とツールの信頼性に依存します。

Claude で本番エージェントを作る場合、主な選択肢は2つです。

Claude マネージドエージェント

Anthropic がエージェントループ、サンドボックス、セッションをホストする REST API。
Claude エージェント SDK

Python または TypeScript のライブラリとして、自社プロセス内でエージェントループを実行する方式。

どちらを選ぶ場合でも、エージェントが呼び出す API は事前にモック、契約テスト、デバッグしておくべきです。たとえば Apidog を使えば、エージェントが依存する API をモックし、契約テストを実行し、MCP サーバーをエージェントと同じ呼び出し方で検証できます。

ホスト型側を詳しく確認したい場合は、Claude マネージドエージェントガイドも参考になります。

Claude マネージドエージェントとは

Claude マネージドエージェントは、Anthropic が管理するインフラ上で動くホスト型エージェントランタイムです。自分でエージェントループ、サンドボックス、ツール実行レイヤーを作る代わりに、エージェント定義を作成し、Anthropic に実行させます。

2026年4月にパブリックベータとして提供され、リクエストには managed-agents-2026-04-01 ベータヘッダーが必要です。SDK 利用時はこのヘッダーが自動設定されます。

基本概念

Claude マネージドエージェントは、次の4つで構成されます。

エージェント: モデル、システムプロンプト、ツール、MCP サーバー、スキルの定義。
環境: Python、Node.js、Go などのパッケージやネットワークルールを含むコンテナテンプレート。
セッション: 環境内で実行されるエージェントインスタンス。タスク、会話履歴、永続ファイルシステムを持ちます。
イベント: アプリとエージェント間で流れるメッセージ。ユーザー入力、ツール結果、ステータス更新などを SSE でストリーミングします。

実装フロー

基本的な流れは以下です。

エージェントを作成する
実行環境を設定する
セッションを開始する
ユーザーメッセージをイベントとして送信する
応答やツール要求をストリーミングで受け取る
必要に応じて追加イベントを送信し、実行中のエージェントを制御する
イベント履歴を取得して監査やデバッグに使う

マネージドエージェントは、Bash、ファイル操作、WebSearch、WebFetch、MCP サーバー接続などの組み込みツールを提供します。

向いているワークロードは以下です。

数分から数時間動く非同期タスク
多数のツール呼び出しを含む処理
クラウドサンドボックスで安全に実行したい処理
インフラ運用を最小化したいチーム
会話間で状態を保持したいセッション型ワークロード

AWS 上の Claude Platform でも利用できますが、機能可用性やセッション動作に違いがあるため、クラウド制約がある場合は公式ドキュメントで確認してください。

注意点

カスタムツールの扱いは SDK と異なります。Claude はツール呼び出しを要求しますが、実行するのはアプリケーション側です。結果はイベントストリーム経由で返します。つまり、ループとサンドボックスはホストされますが、実際のカスタムツール実行は自社環境に残ります。

また、成果物やマルチエージェントなど一部の機能は研究プレビューとして別途アクセス申請が必要です。ベータ機能を前提に本番設計しないようにしてください。

エージェント設計全体の考え方は、エージェント AI アーキテクチャに関する記事でも整理されています。

Claude エージェント SDK とは

Claude エージェント SDK は、Claude Code を支えるエージェントループ、ツール、コンテキスト管理を Python または TypeScript から使えるライブラリです。以前は Claude Code SDK と呼ばれていましたが、コーディング以外のエージェント用途も対象にするため名称変更されました。

インストールは以下です。

pip install claude-agent-sdk

または

npm install @anthropic-ai/claude-agent-sdk

API キーを設定すると、エージェントループは自社プロセス内で実行されます。

最小構成の考え方

Python では、プロンプトと利用可能なツールを含むオプションを渡して query() を呼び出し、ストリーミングされたメッセージを処理します。

通常のクライアント SDK では、次のようなツール実行ループを自分で書く必要があります。

while response.stop_reason == "tool_use":
    # ツール呼び出しを解析
    # 自分でツールを実行
    # 結果を Claude に返す
    pass

Claude エージェント SDK は、このループ、ツール実行、コンテキスト管理をライブラリとして提供します。

SDK が提供する主な機能

組み込みツール

Read、Write、Edit、Bash、Glob、Grep、WebSearch、WebFetch、バックグラウンドスクリプト監視、AskUserQuestion など。
フック

PreToolUse、PostToolUse、Stop、SessionStart、SessionEnd、UserPromptSubmit などのライフサイクルポイントでコールバックを実行できます。監査、ログ、ポリシー適用、ブロック処理に使えます。
サブエージェント

専門タスク用のエージェントを生成できます。メッセージには parent_tool_use_id が含まれるため、どのサブエージェントが何をしたかを追跡できます。
MCP 対応

Model Context Protocol 経由で、データベース、ブラウザ、内部 API などを接続できます。
権限管理

安全なツールを事前承認し、危険なツールをブロックし、機密アクションには承認を要求できます。
セッション管理

セッション ID を保存して後から再開したり、フォークして別の選択肢を検証したりできます。状態はファイルシステム上の JSONL として保持されるため、自社で所有できます。

SDK は Claude Code のファイルシステム設定も読み取れます。

.claude/skills/

CLAUDE.md

また、Anthropic API だけでなく、Amazon Bedrock、AWS 上の Claude Platform、Google Vertex AI、Azure AI Foundry 経由の認証もサポートします。既存のクラウド契約内で推論を維持したい場合に重要です。

実装から始めたい場合は、Claude プランで Claude エージェント SDK をセットアップするガイドや、独自の Claude Code を構築するウォークスルーが参考になります。

請求に関する注意

2026年6月15日以降、Agent SDK と

claude -p

のサブスクリプションプランでの使用は、対話型利用制限とは別の月額 Agent SDK クレジットから引き落とされます。

料金や制限は変わる可能性があります。ブログ記事内の数値ではなく、Anthropic の最新規約を直接確認してください。

直接比較: マネージドエージェント vs エージェント SDK

コストを見積もる前に、Anthropic の料金ページとマネージドエージェントのドキュメントを確認してください。

要素	Claude マネージドエージェント	Claude エージェント SDK
ループの実行場所	Anthropic 管理インフラ	自社プロセス、自社インフラ
インターフェース	REST API + SSE イベントストリーム	Python または TypeScript ライブラリ
制御性	設定とイベントで制御	フック、権限、インプロセスロジックで細かく制御
コストモデル	Claude トークン料金 + アクティブセッション時間のランタイム料金	Claude トークン料金 + 自社で実行するコンピューティング費用
運用負担	低い。サンドボックス、スケーリング、セッションストアを運用しない	高い。サービス、サンドボックス、監視、スケーリングを自社で運用
可観測性	ホスト型イベントログを取得可能	フック、ログ、トレーシングを自社で実装
レイテンシ	ホスト型ランタイムへのネットワークホップあり	ツールやデータに近い場所で実行可能
データレジデンシー	サンドボックスとセッション状態は Anthropic 側、または AWS オプション	ファイル、状態、ツール実行を自社環境に保持
カスタムツール実行	Claude が要求し、アプリが実行して結果を返す	Python / TypeScript 関数としてインプロセス実行
向いている用途	長時間実行、非同期、インフラ軽量な本番エージェント	ローカルプロトタイプ、厳格なデータ制御、内部サービスに近いエージェント

コスト

マネージドエージェントは、標準の Claude トークン料金に加えて、アクティブなセッション時間に対するランタイム料金が発生します。ツール呼び出しの間に待機している時間も、アクティブセッションとして課金対象になる可能性があります。

SDK には Anthropic の時間単位ランタイム料金はありません。ただし、自社サーバー、オートスケーリング、サンドボックス、監視、オンコール運用のコストが発生します。

紙の上で SDK が安く見えても、運用負荷まで含めると逆転することがあります。

運用負担

マネージドエージェントは、サンドボックス、セッションストア、スケーリングを Anthropic 側に寄せられます。小規模チームや非同期ジョブ中心のサービスでは大きな利点です。

SDK はその逆です。すべてを制御できますが、すべてを運用する必要があります。VPC 内でプライベート DB に接続する必要がある場合や、既存の監査基盤と密に統合したい場合に向いています。

データレジデンシー

SDK を使う場合、ツール実行とセッション状態は自社インフラ内に残ります。Claude に送られるのはモデル推論に必要な情報です。

マネージドエージェントでは、サンドボックスとイベントログが Anthropic の環境、または条件付きで AWS 側に存在します。規制対象データを扱う場合、この一点だけで SDK を選ぶことがあります。

可観測性

マネージドエージェントは、取得可能なホスト型イベントログを提供します。

SDK はフックを提供しますが、ログ、トレース、監査基盤への接続は自社実装です。柔軟性は高いですが、初期実装の手間があります。

エージェントが呼び出す API のテストとデバッグ

ホスティング方式に関係なく、エージェントの信頼性は API と MCP サーバーに依存します。

たとえば、推論は正しくても、決済 API が不安定であれば返金エージェントは不安定です。出荷前に次の3レイヤーをテストしてください。

1. API 契約

エージェントが呼び出すすべてのツールは、スキーマを持つ API として扱います。

やること:

エンドポイントをモックする
リクエストスキーマを定義する
レスポンススキーマを定義する
正常系と異常系を契約テストする
CI またはスケジュール実行で回す

Apidog を使うと、決済サービスやチケットサービスのモックを作成し、エージェントが期待するスキーマを定義し、契約テストを継続実行できます。

具体的な失敗モードは、API を呼び出す AI エージェントのテスト方法に関するガイドで解説されています。

2. MCP サーバー

マネージドエージェントも SDK も、外部ツールを MCP 経由で接続できます。MCP サーバー自体も API サービスです。

検証すべき点:

公開されているツール一覧
各ツールの入力スキーマ
各ツールの出力スキーマ
タイムアウト時の挙動
エラー時のレスポンス形式
エージェントが扱いやすい構造化データになっているか

Apidog を使用した MCP サーバーのテストでは、MCP サーバーが公開するツールを列挙し、それぞれを直接試す方法が説明されています。

Apidog には AI エージェントと A2A デバッガーも含まれているため、エージェントが生成するリクエストとレスポンスを実際に確認できます。

3. エージェント自身のリクエストパターン

エージェントは人間とは違う呼び出し方をします。

よくあるパターン:

短時間で同じ API を複数回呼ぶ
失敗時に過剰リトライする
部分的な情報だけで検索 API を叩く
推論ループ中に同じエンドポイントを繰り返し呼ぶ
504 後に成功済み操作を再実行する

本番前に、モック API に対して現実的なチケットや履歴データをリプレイし、エージェントが実際に送るリクエストを観察してください。

マネージドエージェントではループが隠れるため、イベントログと API レベルのテストが重要です。SDK ではフックでループを計測できますが、それでも API 契約テストは必要です。

エージェントを顧客データに接続する前に、Apidog をダウンロードして依存 API を検証しておくと安全です。

意思決定フレームワーク

次の質問に順に答えると選びやすくなります。

Claude マネージドエージェントを選ぶべき場合

エージェントが数分から数時間動く
非同期ジョブが中心
多数のツール呼び出しがある
ジョブランナー、サンドボックス、セッションストアを運用したくない
小規模チームで、運用人数が制約になっている
ホスト型イベントログを使いたい
データとコンプライアンス上、Anthropic または AWS 側のサンドボックスを許容できる
ベータ機能や研究プレビューの制約を受け入れられる

Claude エージェント SDK を選ぶべき場合

エージェントを自社 VPC 内で実行する必要がある
プライベート DB や内部 API に近い場所で動かしたい
セッション状態を第三者環境に置けない
カスタム権限、監査フック、ポリシー制御が必要
データレジデンシーや規制要件が厳しい
Bedrock、Vertex、Azure など既存クラウド契約で推論を扱いたい
ローカルで素早くプロトタイプを作りたい

よくある移行パス

実務では、次の流れがよくあります。

Claude エージェント SDK でローカルプロトタイプを作る
フック、ツール、MCP 接続、API 契約を検証する
本番運用コストと制御要件を比較する
運用削減の価値が大きければマネージドエージェントへ移行する

ただし、これは設定変更ではありません。ライブラリ方式から REST + イベント方式に変わり、カスタムツール実行やセッション状態の扱いも変わります。移行はプロジェクトとして計画してください。

モデルやコーディングエージェントも比較している場合は、2026年版 Claude と Codex の比較も参考になります。

実際のユースケース

支払返金エージェント

要件:

サポートチケットを読む
取引を検索する
返金ポリシーを確認する
決済 API を呼び出して返金する
チケットに結果を書き戻す
金銭操作の監査証跡を残す

このケースでは SDK が有力です。

理由:

決済サービスの近く、つまり自社 VPC 内で実行したい
セッション状態を自社インフラ外に出したくない
PreToolUse フックで「一定額以上の返金には人間承認が必要」というルールを強制できる
すべての API 呼び出しを監査ログに残せる

実装前にやるべきこと:

Apidog で決済 API と元帳 API をモックする
返金、検索、チケット更新の契約テストを作る
過去1週間分のチケットをモックに対してリプレイする
エージェントが実際に送るリクエストを確認する
504 やタイムアウト時の再実行挙動を検証する

特に返金処理では、成功済み操作をリトライで再実行するバグが致命的です。API レベルのテストは必須です。

非同期サポートチケットトリアージエージェント

要件:

毎日数千件のサポートチケットを処理する
チケットを分類する
関連ログを取得する
返信案を作る
解決またはエスカレーションする
各チケットの処理に数分かかる
データの機密性は比較的低い

このケースではマネージドエージェントが向いています。

理由:

長時間実行、非同期、多数のツール呼び出しという形状に合う
小規模チームがワーカーフリートを運用しなくてよい
ホスト型イベントログでチケット単位のトレースを取得できる

ただし、依存 API の検証は必要です。

ロギング API をモックする
チケットシステム MCP サーバーをテストする
スキーマ変更時に契約テストが落ちるようにする
エージェントの実トラフィックを観察する

ホスティングがマネージドでも、API の正確性は自社の責任です。

ファイアウォール内の内部データ運用エージェント

要件:

「昨日失敗した ETL パーティションをバックフィルする」などの内部依頼を処理する
内部ジョブ API を呼ぶ
修復スクリプトを実行する
ステータスを報告する
内部 API はパブリックインターネットに出ていない
データは機密性が高い

この場合は SDK が自然な選択です。

理由:

エージェントがプライベートサービスに到達できる場所で実行される必要がある
セッション状態をサードパーティのサンドボックスに置けない
MCP サーバーを内部ネットワーク内で接続できる
SDK フックで実行コマンドを既存の監査パイプラインに送れる

このケースでは「自社プロセス内で動く」ことが好みではなく要件です。

AI エージェントが API コンシューマーになっている背景は、新しい API コンシューマーとしての AI エージェントでも説明されています。

本番前チェックリスト

出荷前に最低限確認すべき項目です。

アーキテクチャ

[ ] エージェントループをどこで実行するか決めた
[ ] セッション状態の保存場所を明確にした
[ ] カスタムツールの実行場所を明確にした
[ ] MCP サーバーの接続方式を決めた
[ ] ネットワーク境界とデータレジデンシーを確認した

セキュリティ

[ ] 危険なツール呼び出しをブロックできる
[ ] 金銭操作やデータ変更に承認フローがある
[ ] ツール実行ログを監査できる
[ ] API キーと認証情報の管理方法を決めた
[ ] エラー時に機密情報を返さない

テスト

[ ] すべての依存 API をモックした
[ ] リクエストとレスポンスの契約テストを作成した
[ ] MCP サーバーの各ツールを単独でテストした
[ ] タイムアウトとリトライを検証した
[ ] 実データに近いトラフィックをリプレイした

運用

[ ] コストモデルを見積もった
[ ] イベントログまたはフックログを取得できる
[ ] 障害時のオンコール責任を決めた
[ ] ベータ機能への依存を確認した
[ ] Anthropic の最新料金と利用条件を確認した

結論

マネージドエージェントとエージェント SDK の選択は、API 設計に見えますが、実際には運用とデータガバナンスの判断です。

要点は以下です。

マネージドエージェントはループとサンドボックスをホストする
SDK はループを自社プロセス内で実行する
マネージドエージェントは運用負荷を下げるが、ランタイム料金とホスト型状態を受け入れる必要がある
SDK は制御性が高いが、インフラと監視を自社で運用する必要がある
データレジデンシーが厳しい場合は SDK が有力
非同期で長時間動く低機密ワークロードはマネージドエージェントが有力
どちらを選んでも、API と MCP サーバーの契約テストは必須
SDK でプロトタイプし、必要に応じてマネージドエージェントへ移行するのは現実的。ただし移行はプロジェクトとして扱う

次のステップは、エージェントを顧客データや本番 API に接続する前に、依存 API と MCP サーバーをテストすることです。Apidog をダウンロードして、エンドポイントのモック、契約テスト、エージェントの実リクエストデバッグを行い、選択したホスティングモデルを信頼できる依存関係の上に構築してください。

よくある質問

Claude マネージドエージェントと Claude エージェント SDK の主な違いは何ですか？

マネージドエージェントは、Anthropic がエージェントループとセッションごとのサンドボックスを実行するホスト型 REST API です。アプリはイベントを送信し、結果をストリーミングで受け取ります。

エージェント SDK は、同じようなループを自社プロセスと自社インフラ内で実行する Python または TypeScript ライブラリです。同じ Claude モデルを使えますが、運用責任の境界が違います。

Claude エージェント SDK は以前の Claude Code SDK と同じものですか？

はい。Claude Code SDK は、コーディングタスク以外のエージェント用途も含めるため、Claude エージェント SDK に名称変更されました。エージェントループ、組み込みツール、コンテキスト管理は Claude Code を支える仕組みと同じです。

どちらが安価ですか？

ワークロード次第です。

マネージドエージェントは、Claude トークン料金に加えて、アクティブセッション時間のランタイム料金が発生します。SDK には Anthropic の時間単位ランタイム料金はありませんが、自社コンピューティング、監視、スケーリング、オンコール運用のコストが発生します。

予算化する前に、Anthropic の最新料金ページを確認してください。

MCP サーバーは両方で使用できますか？

はい。どちらも Model Context Protocol を介して外部ツールを接続できます。

そのため、本番エージェントに接続する前に MCP サーバーをテストすることが重要です。Apidog を使用した MCP サーバーのテストガイドでは、MCP サーバーが公開する各ツールを直接検証する方法が説明されています。

顧客データを Anthropic のインフラストラクチャから外に保持するにはどうすればよいですか？

Claude エージェント SDK を使い、エージェントループを自社環境内で実行します。SDK の場合、ツール実行とセッション状態は自社インフラに残ります。

マネージドエージェントでは、サンドボックスとイベントログが Anthropic の環境、または条件付きで AWS 側に存在します。厳格なデータレジデンシー要件がある場合は SDK を検討してください。

Claude マネージドエージェントは本番環境に対応していますか？

2026年4月にパブリックベータとしてリリースされ、すべてのリクエストで managed-agents-2026-04-01 ベータヘッダーが必要です。

コアセッション機能は一般に API アカウントで利用可能ですが、成果物やマルチエージェントなど一部機能は研究プレビューとして別途アクセス申請が必要です。本番採用前に最新ドキュメントでステータスを確認してください。

エージェントが実際の API にアクセスする前にテストするにはどうすればよいですか？

以下を実施します。

エージェントが呼び出す API をモックする
MCP サーバーを単独でテストする
リクエストとレスポンススキーマの契約テストを作る
現実的なトラフィックをモックにリプレイする
エージェントが実際に送るリクエストを観察する

Apidog は、API モック、契約テスト、AI エージェントおよび A2A デバッガーを含めてこの流れを支援します。詳細は、API を呼び出す AI エージェントのテスト方法を参照してください。

片方から始めて、後でもう片方に切り替えることはできますか？

可能です。一般的には、Claude エージェント SDK でローカルプロトタイプを作り、その後マネージドエージェントへ移行する流れがあります。

ただし、これは設定変更ではありません。インターフェースはライブラリから REST + イベントに変わり、カスタムツール実行やセッション状態の扱いも変わります。移行プロジェクトとして計画してください。

Cursor Composer 2.5 対 Opus 4.7 対 GPT-5.5: おすすめコーディングモデル比較

Akira — Tue, 19 May 2026 02:26:17 +0000

CursorのComposer 2.5の主張は明確です。Claude Opus 4.7やGPT-5.5に近いコーディング品質を、約10分の1のコストで提供するというものです。この記事では、ベンチマーク、速度、コスト、実運用での選び方に絞って、3つのモデルを実装視点で比較します。

今すぐApidogを試す

モデル自体の概要を先に確認したい場合は、Cursor Composer 2.5ガイドをご覧ください。ここでは、実際のコードベースと予算を前提に「どのモデルをどの場面で使うべきか」を判断します。

簡潔な回答

Composer 2.5は、すべての指標で単独トップのモデルではありません。ただし、実際のソフトウェア開発タスクではOpus 4.7に1〜2ポイント差まで迫りながら、1タスクあたりのコストを1ドル未満に抑えられます。

日常的にプロダクションコードを出荷するチームでは、次のように使い分けるのが現実的です。

Composer 2.5: デフォルトのエージェント作業用
Opus 4.7: 難しい推論や最高品質が必要な例外タスク用
GPT-5.5: ターミナル中心の自動化や長いコマンドチェーン用

ベンチマーク比較

Cursorが公開している3つのベンチマークを、Composer 2の旧スコアも含めて整理すると次の通りです。

ベンチマーク	Composer 2.5	Opus 4.7	GPT-5.5	Composer 2
SWE-bench Multilingual	79.8%	80.5%	77.8%	73.7%
Terminal-bench 2.0	69.3%	69.4%	82.7%	n/a
CursorBench v3.1	63.2%	64.8%（最大） / 61.6%（デフォルト）	59.2%（デフォルト）	n/a

読み取るべきポイントは3つです。

1. SWE-bench Multilingualではほぼ互角

SWE-bench Multilingualは、複数言語の実際のGitHub Issue修正を評価するベンチマークです。

Composer 2.5: 79.8%
Opus 4.7: 80.5%
GPT-5.5: 77.8%
Composer 2: 73.7%

Composer 2.5はOpus 4.7に1ポイント以内まで迫り、GPT-5.5を上回っています。Composer 2からの伸びも大きく、前世代とは別クラスのモデルと見てよいでしょう。出発点を確認したい場合は、Composer 2ガイドを参照してください。

2. CursorBenchではデフォルト設定のComposer 2.5が強い

CursorBench v3.1では、デフォルト設定の比較でComposer 2.5が優位です。

Composer 2.5: 63.2%
Opus 4.7 デフォルト: 61.6%
GPT-5.5 デフォルト: 59.2%

Opus 4.7が上回るのは最大設定にした場合のみです。ただし、その場合はコストとレイテンシーも上がります。

3. Terminal-benchではGPT-5.5が明確に強い

Terminal-bench 2.0では、GPT-5.5が82.7%で大きくリードしています。

シェルスクリプト、CLI操作、長いコマンドチェーン、インフラ自動化のようなターミナル中心の作業では、GPT-5.5を候補に入れるべきです。

ベンチマークの追加確認には、The Decoderの記事と公式のCursor Composer 2.5発表が参考になります。

コスト比較

ベンチマーク差が1〜2ポイントでも、コスト差は大きくなります。

モデル	入力 / Mトークン	出力 / Mトークン	1タスクあたりの概算コスト
Composer 2.5（標準）	$0.50	$2.50	1ドル未満
Composer 2.5（高速）	$3.00	$15.00	1桁台の低価格
Opus 4.7 / GPT-5.5	フロンティアティア	フロンティアティア	数ドル、最大約11ドル

Cursorの報告では、Composer 2.5はCursorBenchで約63%のスコアを出しながら、1タスクあたり平均1ドル未満です。一方、Opus 4.7やGPT-5.5は同等またはそれ以下の結果でも、1タスクあたり数ドルかかることがあります。

月間タスク数で見ると差はさらに明確です。

月間エージェントタスク	1タスクあたりのコスト	月額概算
2,000件	$1	$2,000
2,000件	$5	$10,000
2,000件	$11	$22,000

この規模になると、モデル選定は単なる品質比較ではなく、チームの運用コストに直結します。

料金の詳細は、Cursor Composer料金ガイド、GPT-5.5の料金に関する投稿、Claude Opus 4.7ガイドを参照してください。

速度とモデルの挙動

品質と価格だけでなく、実際の開発フローでの挙動も重要です。

Composer 2.5

Composer 2.5は、Cursor内の長時間実行されるエージェントタスク向けに設計されています。

向いている作業は次の通りです。

複数ファイルにまたがる修正
小〜中規模の機能追加
テスト付きのリファクタリング
既存コードベースに沿った修正
日常的なバグ修正

高速バリアントは、同じ知能を低レイテンシーで使いたい場合に適しています。

Opus 4.7

Opus 4.7は、難しい推論タスクで強いモデルです。特に最大設定では高いスコアを出しますが、その分コストとレイテンシーが上がります。

向いている作業は次の通りです。

複雑な設計判断
難度の高いデバッグ
失敗コストが高い修正
仕様の曖昧な大規模変更

GPT-5.5

GPT-5.5は、ターミナル駆動のワークフローで強みがあります。

向いている作業は次の通りです。

CLI中心の自動化
長いコマンドチェーン
シェルスクリプト作成
環境構築や検証手順の実行

Composer 2.5はオープンソースのMoonshot Kimi K2.5チェックポイントをベースに、Cursor向けに大幅に後処理されています。一方、Opus 4.7とGPT-5.5はコードにも強い汎用フロンティアモデルです。この違いは、エディター内エージェントとしての挙動に表れます。

どのモデルを選ぶべきか

リーダーボードではなく、運用判断として選ぶのが重要です。

Composer 2.5を選ぶべき場合

日常的にコードを出荷している
大量のエージェントタスクを実行する
1タスクあたりのコストを抑えたい
Cursor内でマルチファイル修正を多用する
フロンティア品質に近い結果を低コストで得たい

Opus 4.7を選ぶべき場合

最も難しい推論タスクで最高スコアが必要
コストより品質上限を優先する
すでにClaude中心のワークフローを使っている

Claude中心の運用を検討している場合は、Claude Code vs Cursorの比較も参考になります。

GPT-5.5を選ぶべき場合

ターミナル中心の自動化が多い
Terminal-benchの強みを活かせる
コーディングにも使える汎用モデルが欲しい

多くのチームでは、次のようなハイブリッド運用が現実的です。

通常のエージェントタスク → Composer 2.5
難しい設計・推論タスク → Opus 4.7
ターミナル中心の作業 → GPT-5.5

他の開発AIツールも含めて比較したい場合は、Codex vs Claude Code vs Cursor vs Copilotのまとめを参照してください。

自分のコードベースで比較する方法

公開ベンチマークは平均値です。自分のコードベースで最適なモデルを判断するには、同じタスクを3モデルで実行して比較します。

手順

実際にエージェントへ任せたいタスクを1つ選ぶ

例: 再現可能なバグ修正、小さな機能追加、テスト付きリファクタリング
Cursorで同じプロンプトを3回実行する

モデルピッカーで次を切り替えます。

   composer-2.5
   Opus 4.7
   GPT-5.5

各実行を同じ基準で評価する

| 評価項目 | 確認内容 |
|---|---|
| テスト | 既存テスト・追加テストが通るか |
| 時間 | 完了までに何分かかったか |
| コスト | Cursorの利用状況ビューでいくらかかったか |
| 差分品質 | 既存設計に沿っているか |
| 修正量 | 人間の手直しがどれくらい必要か |

APIを触るタスクでは、生成されたリクエストをApidogで実行する

単体テストが通るだけでなく、実際のエンドポイントが期待するレスポンスを返すか確認します。

この比較を行うと、多くの場合は次の結論になります。

Composer 2.5は品質で十分近い
コストでは大きく有利
一部の難しい問題ではフロンティアモデルを使う価値がある

重要なのは、リーダーボードではなく自分の作業で判断することです。

ベンチマークが見落とす失敗モード

コーディングモデルには、ベンチマークでは見えにくい失敗があります。

典型例は、実在しないAPIエンドポイントや誤ったスキーマを前提に、自信満々なコードを生成することです。これはComposer 2.5、Opus 4.7、GPT-5.5のどれでも起こり得ます。

間違っているが見た目はきれいなAPIコードは、コードがない状態よりも危険です。レビューやQAで発見されるまで、誤った前提が残るためです。

対策はモデルに依存しません。

モデルに実際のAPI仕様を渡す
生成されたコードを実際のエンドポイントで検証する
ステータスコード、ペイロード、認証を確認する
動作確認済みのリクエストをテストに組み込む

Cursorでは、MCPサーバー経由でAPI仕様を渡すことで、モデルが実際のスキーマに基づいてコードを生成しやすくなります。その後、生成されたリクエストをApidogで実行し、チームメイトに渡る前に検証します。

セットアップ方法は、CursorでのAPI仕様ウォークスルーで確認できます。

モデル選定は速度と請求額を変えます。しかし、検証ループを入れないと、その速度はデバッグ負債に変わります。

よくある質問

Composer 2.5はOpus 4.7より優れていますか？

常に優れているわけではありません。SWE-bench MultilingualではComposer 2.5が79.8%、Opus 4.7が80.5%で、差は1ポイント以内です。CursorBenchのデフォルト設定ではComposer 2.5がわずかに上回ります。

ただし、Opus 4.7は最大設定でリードします。コストを含めた価値比較では、Composer 2.5が多くのワークロードで有利です。

Composer 2.5はGPT-5.5より優れていますか？

SWE-bench MultilingualとCursorBenchではComposer 2.5がGPT-5.5を上回っています。一方、Terminal-bench 2.0ではGPT-5.5が明確に勝っています。

コード編集中心ならComposer 2.5、ターミナル自動化中心ならGPT-5.5を優先して検討してください。

Composer 2.5はなぜ安いのですか？

Composer 2.5はオープンソースのKimi K2.5をベースに構築され、Cursorのエージェントループ向けにチューニングされています。そのため、Cursorがコスト構造を制御しやすくなっています。

一方、汎用フロンティアモデルはフロンティア価格になりやすいです。

Cursorで3つすべてを使えますか？

はい。Cursorのモデルピッカーで、タスクごとにモデルを切り替えられます。これにより、Composer 2.5をデフォルトにしつつ、必要な場面だけOpus 4.7やGPT-5.5を使うハイブリッド戦略が実用的になります。

セットアップはCursor Composer 2.5ガイドを参照してください。

結論

ベンチマークの最高値だけを見るなら、Opus 4.7とGPT-5.5にはそれぞれ強い領域があります。しかし、実際の開発タスクにおける「1ドルあたりの品質」で見ると、Composer 2.5は多くのチームにとってデフォルトにしやすいモデルです。

実運用では、次の構成が扱いやすいでしょう。

デフォルトのコード修正・機能追加 → Composer 2.5
難しい推論・設計判断 → Opus 4.7
ターミナル中心の自動化 → GPT-5.5
API仕様の検証 → Apidog

どのモデルを使う場合でも、実際のAPIコントラクトに基づかせ、生成された出力を検証することが重要です。Apidogをダウンロードして、生成されたエンドポイントにライブリクエストを送り、動作する呼び出しを自動テストに組み込みましょう。

Cursor Composer 2.5 でAPIを構築する方法

Akira — Tue, 19 May 2026 02:25:14 +0000

Cursor Composer 2.5は高速かつ低コストなので、APIクライアントやルートハンドラの生成をエージェントに任せやすくなりました。ただし、モデルが実際のAPIコントラクトを知らないままコードを書くと、/v2/ordersのような存在しないエンドポイントや、実サービスとは異なるペイロードを生成することがあります。コードはコンパイルされても、実行時に失敗します。

今すぐApidogを試す

この記事では、Cursor Composer 2.5をMCP経由で実際のAPI仕様に接続し、仕様に基づいてコードを生成し、チームに渡す前にApidogで検証するワークフローを説明します。Composer 2.5自体の概要や利用方法は、Cursor Composer 2.5ガイドを参照してください。

なぜエージェント型モデルはAPIの形状を推測するのか

Composer 2.5は、複数ファイルの編集、テスト実行、修正を含む長いエージェントタスクに向いています。

たとえば、次のような依頼ができます。

請求サービス用のクライアントを追加し、それを決済フローに組み込んでください。

Composer 2.5は計画を立て、必要なファイルを編集し、テストが通るまで作業します。これはComposer 2からの大きな改善点です。

ただし、モデルがAPIコントラクトをコンテキストに持っていない場合、空白を「もっともらしい形」で補完します。

よくある失敗は次の3つです。

エンドポイントが微妙に違う
- 例: モデルは/api/users/{id}を書くが、実際は/users/{userId}
リクエストボディに存在しないフィールドを追加する
認証方式をサービス固有の方式ではなく、一般的なBearerトークンなどとして扱う

OpenAPIファイルをそのままチャットに貼ることもできますが、長くなりやすく、コンテキストも消費します。より安定した方法は、モデルにAPI仕様への構造化されたアクセスを与えることです。

解決策: MCPを介してComposer 2.5を実際のAPI仕様に接続する

Model Context Protocol、つまりMCPは、AIモデルにツールやデータを提供するためのオープン標準です。

CursorはMCPサーバーをサポートしています。Apidog MCPサーバーを使うと、Apidog内のAPI仕様を、Composer 2.5がコーディング中に参照できる構造化データとして公開できます。

これにより、Composer 2.5は次の情報を推測ではなく仕様から取得できます。

実際のエンドポイント
パスパラメーター
クエリパラメーター
リクエストスキーマ
レスポンススキーマ
エラーレスポンス
認証要件

これは、Apidog MCPサーバーでのバイブコーディングと同じ考え方を、より長い実装タスクに適用する方法です。

ステップ1: ApidogでAPI仕様を準備する

まず、モデルが参照する「真実の源」を用意します。

ApidogでAPIを設計するか、既存の仕様をインポートしてください。ApidogはOpenAPIやPostmanコレクションのインポートに対応しています。

準備時に確認するポイントは次のとおりです。

エンドポイントが実サービスと一致している
リクエストボディのスキーマが最新である
レスポンス例が実際の形式に近い
エラー時のステータスコードとレスポンスが定義されている
認証方式が明記されている

Composer 2.5はこの仕様をもとにコードを書くため、仕様が古いと生成コードも古くなります。最初に仕様を整えることが重要です。

ステップ2: Apidog MCPサーバーをCursorに接続する

Cursorは、プロジェクト内の設定ファイルからMCPサーバーを読み取ります。通常は.cursor/mcp.jsonを使用します。

典型的な設定例は次のとおりです。

{
  "mcpServers": {
    "apidog-api-spec": {
      "command": "npx",
      "args": ["-y", "apidog-mcp-server@latest", "--project=<your-project-id>"],
      "env": {
        "APIDOG_ACCESS-TOKEN": "<your-access-token>"
      }
    }
  }
}

<your-project-id>と<your-access-token>は、自分のApidogプロジェクトに合わせて置き換えてください。

正確なコマンド、プロジェクトID、トークンの取得方法は、Apidog MCPセットアップウォークスルーを確認してください。

設定後は、Cursorを再起動します。再起動しないと、新しいMCPサーバーが認識されないことがあります。

ステップ3: Composer 2.5が仕様を読めるか確認する

いきなり実装を依頼する前に、読み取り専用の質問で接続を確認します。

Cursorでエージェントセッションを開き、モデルピッカーでcomposer-2.5を選択します。

次のように質問します。

apidog-api-spec MCPサーバーを使用して、注文リソースのエンドポイントと注文作成に必要なフィールドをリストアップしてください。

期待する結果は、Apidogに定義されている実際のエンドポイントとフィールドが返ることです。

もし一般的なREST APIの例のような回答が返る場合、Composer 2.5は仕様を読めていません。その場合は次を確認します。

.cursor/mcp.jsonの場所が正しいか
MCPサーバー名がプロンプト内の名前と一致しているか
ApidogのプロジェクトIDが正しいか
アクセストークンが有効か
Cursorを再起動したか

ステップ4: コントラクトに基づいてコードを生成させる

接続確認ができたら、実装タスクを依頼します。

重要なのは、仕様ソースを明示することです。

例:

真実の源としてapidog-api-specサーバーを使用して、注文API用の型付きTypeScriptクライアントを記述してください。create-orderおよびget-order呼び出しを含めてください。リクエストおよびレスポンススキーマを正確に一致させ、仕様で定義されている422検証レスポンスのエラー処理も追加してください。

より実装寄りにするなら、次のように条件を追加できます。

apidog-api-specを参照して、注文APIクライアントを実装してください。

要件:
- TypeScriptで実装する
- createOrderとgetOrderを提供する
- リクエスト型とレスポンス型を仕様に合わせる
- 422レスポンスをValidationErrorとして扱う
- 既存のHTTPクライアントラッパーを再利用する
- 生成後に関連テストを実行する

Composer 2.5は複数ファイルにまたがる作業を維持できるため、次のような構成の実装にも向いています。

src/
  api/
    orders.ts
  types/
    orders.ts
  hooks/
    useOrder.ts
  tests/
    orders.test.ts

プロンプト内でMCPソースを指定しておくことで、モデルが一般知識に戻ってエンドポイントやフィールドを推測するリスクを下げられます。

信頼する前に検証する: Apidogテストループ

MCPでモデルを仕様に根拠づけると、誤ったエンドポイントやスキーマの生成は大きく減ります。ただし、検証は不要にはなりません。

理由は2つあります。

仕様が実サービスより遅れている可能性がある
モデルがエッジケースを誤解する可能性がある

そのため、生成後はApidogで実際に検証します。

1. 生成された呼び出しを実リクエストとして送信する

Composer 2.5が生成したエンドポイント、ヘッダー、ボディをApidogで実行します。

確認する項目は次のとおりです。

ステータスコードが想定通りか
レスポンスボディの形が型定義と一致しているか
認証ヘッダーが正しく送信されているか
エラー時のレスポンスがコードの分岐と一致しているか

2. 動作する呼び出しをテストに変換する

検証済みのリクエストは、Apidog上で自動テストシナリオとして保存します。

これにより、次回以降の変更でAPIコントラクトが壊れた場合、ユーザーではなくCIやテストで検出できます。

3. 未実装のAPIはモック化する

バックエンドがまだ実装していないエンドポイントでも、仕様がApidogにあるならモックを使えます。

たとえば、Composer 2.5にフロントエンドクライアントを生成させ、Apidogのモックサーバーに対して動作確認できます。

この流れは、AIエージェントとAPIテストのパターンとも相性が良いです。

基本方針はシンプルです。

モデルはコントラクトに基づいて初稿を書く。人間とテストは、それが実サービスに対して正しく動くことを確認する。

現実的なエンドツーエンドの例

決済サービスに返金機能を追加する例で考えます。

前提:

返金エンドポイントとスキーマはApidogプロジェクトに定義済み
Apidog MCPサーバーはCursorに接続済み
CursorではComposer 2.5を選択済み

Composer 2.5には次のように依頼します。

apidog-api-specを使用して、返金クライアントとそれを呼び出すReactフックを構築してください。

要件:
- 仕様が要求するidempotency-keyヘッダーを含める
- リクエストボディとレスポンス型は仕様に正確に合わせる
- 重複リクエスト時の409エラーを処理する
- 既存のAPIクライアント構成に合わせる
- 実装後に関連テストを実行する

期待する作業の流れは次のとおりです。

Composer 2.5がApidog MCPから返金APIの仕様を読む
クライアント関数、型、Reactフックを生成する
既存のプロジェクト構成に合わせてファイルを配置する
テストを実行し、失敗があれば修正する
Apidogで実際の返金作成リクエストを送信する
idempotency-keyの動作と、重複時の409エラーを確認する
正常系と重複エラー系をテストシナリオとして保存する

このワークフローで避けられる典型的なバグは、べき等ヘッダーの付け忘れです。返金処理では、この種のミスが二重返金のような重大な問題につながります。

よくある質問

Composer 2.5はMCPをサポートしていますか？

はい。Cursorのエージェントツールセットにアクセスでき、MCPサーバーも利用できます。

モデルピッカーでComposer 2.5を選び、プロジェクトでMCPサーバーを設定してください。モデル選択については、Composer 2.5ガイドで説明されています。

Composer 2.5でMCPを使うにはApidogが必要ですか？

必要なのは、構造化されたAPI仕様ソースです。

この記事では、仕様、テスト、モックを同じ場所で扱えるため、Apidog MCPサーバーを使っています。

他の選択肢は、Cursor向けの最高のMCPサーバーのまとめも参考になります。

モデルを仕様に根拠づけると、すべての幻覚が止まりますか？

いいえ。

ただし、モデルが推測ではなく実際のコントラクトを読むため、誤ったエンドポイントやスキーマを生成するリスクは大きく下がります。

それでもテストは必要です。仕様が実行中のサービスとずれている場合や、モデルがエラー処理を誤解する場合があるためです。

小規模プロジェクトでも価値がありますか？

はい。モデルが実際のAPIに触れるなら価値があります。

設定は基本的に一度だけです。その後は、生成されるAPI呼び出しが「一般的にありそうな形」ではなく、自分のプロジェクトのコントラクトに基づくようになります。

結論

Composer 2.5は、APIクライアントや関連実装をエージェントに任せられるほど高速で低コストです。ただし、実運用に近いコードを生成するには、モデルを実際のAPIコントラクトに接続する必要があります。

Apidog MCPサーバーを使って仕様をCursorに公開し、Composer 2.5が正しいエンドポイント、スキーマ、レスポンスを読めるようにします。そのうえで、Apidogをダウンロードし、ライブリクエスト、テスト、モックで検証します。

仕様に基づく生成と実リクエストでの検証を組み合わせることで、エージェントの速度をそのまま出荷可能な実装につなげられます。

カーソルコンポーザー2.5：機能、使い方、アクセス方法

Akira — Tue, 19 May 2026 02:24:10 +0000

Cursorは2026年5月18日にComposer 2.5を出荷しました。注目点は明確です。Opus 4.7およびGPT-5.5と実際のソフトウェアベンチマークで匹敵しながら、タスクあたりのコストは1ドル未満に収まるコーディングモデルです。コードを書くことで生計を立てている開発者にとって、この価格対品質比は日々の実装計画に影響します。

今すぐApidogを試す

このガイドでは、開発者が実務で知りたいポイントに絞って説明します。Composer 2.5が何か、Cursor内でどう有効化するか、そして本番コードでどう使うかです。ベンチマーク、価格、実装時の使い分けに加えて、Composer 2.5とApidogを組み合わせ、生成されたAPIコードを実行前提で検証するワークフローも紹介します。

Cursor Composer 2.5とは？

Composer 2.5は、Cursor独自のエージェント型コーディングモデルです。Cursorエディタ内で計画を立て、ファイルを編集し、ターミナルコマンドを実行し、自分の作業を検証する用途に最適化されています。

以前のComposer 2は高速な自動補完パートナーに近い存在でした。Composer 2.5では、より長いタスクを文脈を失わずに完了させるエージェントとしての性質が強くなっています。

主な特徴は次の通りです。

オープンソースのMoonshot Kimi K2.5チェックポイントを基盤としている
おおよそ1兆パラメータ規模の基盤を持つ
Cursorはトレーニング計算予算の約85%を、ベースモデルではなくポストトレーニングと強化学習に使用した
Composer 2よりも25倍多い合成タスクでトレーニングされた
Cursorが機能を削除し、モデルがテストに合格するまで再構築するような演習も含まれている

実務上の違いは、長いセッションでの安定性です。Composer 2は高速でしたが、複数ステップの作業では意図からずれることがありました。Composer 2.5は、より長いタスクで文脈を保持し、複雑な指示を継続的に実行しやすくなっています。

モデルファミリーの背景を確認したい場合は、Composer 2ガイドで、2.5の前提となるアーキテクチャを確認できます。

内部で何が変わったのか

Composer 2.5の改善は、主に3つのトレーニング方針に基づいています。

テキストフィードバックによるターゲットRL

タスクの最後に単一の報酬を与えるだけでなく、Cursorは修正内容を短いヒントとして記述し、そのヒントをローカルコンテキストに入れ、モデルへ蒸留しています。これにより、利用できないツールを呼び出すような挙動を減らしています。
大規模な合成データ

合成タスクが25倍に増えたことで、モデルは実際のリポジトリ作業に近いタスクをより多く経験しています。感覚的なコード生成ではなく、テストで検証される作業を多く学習しています。
デュアルメッシュHSDPを備えたシャードMuonオプティマイザ

これはユーザーが直接操作する機能ではなく、トレーニングインフラです。Cursorが1兆パラメータ規模のモデルを高速な最適化ステップでトレーニングできた理由の一つです。

これらを暗記する必要はありません。重要なのは、Composer 2.5が以前のエージェントよりも長く複雑なタスクで安定しやすい、という点です。

Composer 2.5のベンチマーク：実際どのくらい優れているのか？

Cursorは3つのベンチマークでスコアを報告し、Opus 4.7およびGPT-5.5と比較しています。

ベンチマーク	Composer 2.5	Opus 4.7	GPT-5.5
SWE-bench Multilingual	79.8%	80.5%	77.8%
Terminal-Bench 2.0	69.3%	69.4%	82.7%
CursorBench v3.1	63.2%	64.8%（最大） / 61.6%（デフォルト）	59.2%（デフォルト）

読み方はシンプルです。

SWE-bench Multilingualでは、Composer 2.5は79.8%
Opus 4.7との差は1ポイント未満
GPT-5.5は上回っている
Composer 2の73.7%から大きく改善している
CursorBenchでは、Opus 4.7のデフォルト設定をわずかに上回っている

一方で、Terminal-Bench 2.0ではGPT-5.5が82.7%で明確にリードしています。長いターミナル操作やCLI中心の作業が多い場合は、この差を考慮する必要があります。

ただし、最も重要なのはコストです。Cursorは、CursorBenchで約63%のスコアを出しながら、タスクあたりの平均コストが1ドル未満であると報告しています。一方、Opus 4.7やGPT-5.5は、同等またはそれ以下の結果でもタスクあたり数ドルかかります。一部の比較では、競合モデルのコストが最大11ドルに達するとされています。

The Decoderによる独立した報道も、Composer 2.5が最先端に近い品質を低コストで提供しているという同様の結論に達しています。

つまり、Composer 2.5はすべてのベンチマークで常にトップのモデルではありません。しかし、多くの実務チームにとって重要な「十分に高い品質を、継続利用できるコストで使える」モデルです。

Composer 2.5のコストはいくらですか？

Cursorは、Composer 2.5に2つのバリアントを提供しています。

バリアント	入力	出力	使う場面
スタンダード	$0.50 / 100万トークン	$2.50 / 100万トークン	ほとんどのエージェント作業のデフォルト。費用対効果を重視する場合。
高速	$3.00 / 100万トークン	$15.00 / 100万トークン	レイテンシが重要な作業。待ち時間を短くしたい場合。

高速バリアントは、同等のモデル品質をより低いレイテンシで提供し、製品上のデフォルトになっています。それでも、他の最先端モデルの高速ティアより安価です。

請求方法はプランによって異なります。

個人プラン

Proなどの個人プランには、Composer用の使用量プールがあります。多くのソロ開発者は、日常利用では細かなトークン単価を意識せずに使えます。
チームおよびエンタープライズプラン

APIレートで直接課金されます。
ローンチプロモーション

Cursorはリリース後最初の1週間、Composer 2.5の使用量を2倍にしました。早期導入者はテストしやすい期間を得られます。

Cursorがモデル使用量をどう測定するかは、Cursor Composer価格ガイドで確認できます。費用を抑えて試したい場合は、Composer無料利用のチュートリアルも参考になります。

Cursor Composer 2.5へのアクセス方法

Composer 2.5は、Cursor内から数ステップで使えます。

Cursorをアップデートする

Composer 2.5には最近のビルドが必要です。Cursorを開き、アップデートを確認します。macOSではCursorメニュー、その他の環境ではヘルプメニューから確認できます。更新後は再起動します。
対応プランのアカウントでサインインする

ProおよびBusinessプランにはComposer使用量が含まれます。無料アカウントでも含まれる使用量で試せますが、大量に使う場合は有料プランが必要です。
モデルピッカーを開く

チャットまたはエージェントセッションを開始し、モデルのドロップダウンを開きます。composer-2.5を選択します。通常は高速バリアントがデフォルトで選ばれています。
エージェントモードを使う

Composer 2.5はエージェント作業向けです。ファイル編集、ターミナルアクセス、ツール使用を使うには、通常のチャットではなくエージェントモードを使います。

セットアップはこれだけです。モデルは、Cursorが公開するファイル読み取り、編集、ターミナル実行、ツール呼び出しなどのエージェント機能にアクセスできます。最新のデフォルト設定は、公式のComposer 2.5モデルドキュメントで確認できます。

Cursorを使ったことはあるがエージェント機能を使っていない場合は、Cursor 2.0の概要を読むと、エージェントインターフェースの基本を把握できます。

Composer 2.5を効果的に使う方法

Composer 2.5は、短い補完よりも「完了条件が明確な実装タスク」で力を発揮します。

1. 長いタスクを任せる

Composer 2.5の主な改善点は、持続的なパフォーマンスです。1行ずつ指示するのではなく、実装単位で依頼します。

例：

注文一覧APIにページネーションを追加してください。
既存のレスポンス形式を壊さず、limitとcursorを受け取れるようにしてください。
関連するユニットテストとAPIテストも更新し、既存テストがすべて通る状態にしてください。

このように終了条件を明確にすると、Composer 2.5は複数ファイルを横断して作業しやすくなります。

2. 成功条件をプロンプトに書く

Composer 2.5はテスト検証を前提とする作業に向いています。完了条件を曖昧にしないでください。

例：

以下を満たすまで修正してください。

- 既存テストはすべてグリーンを維持する
- 新しい注文作成APIは無効な入力に対して422を返す
- 認証されていないリクエストは401を返す
- OpenAPIスキーマと実装のフィールド名が一致する

「何をもって完了とするか」を与えることで、モデルが自己修正しやすくなります。

3. 標準と高速を使い分ける

品質は同じなので、判断軸はコストとレイテンシです。

標準

バッチ的な修正、大きめのリファクタリング、急がない作業
高速

ライブでやり取りしながら実装する作業、応答待ち時間を減らしたい作業

チームで使う場合は、日常の大半を標準に寄せ、ペアプロ的に使う場面だけ高速を選ぶとコストを管理しやすくなります。

4. コンテキストを正確に渡す

エージェントモデルは強力ですが、APIの実際の仕様を知らない場合は推測します。推測で生成されたコードは、見た目は正しくても実行時に失敗します。

特にAPIクライアント、DTO、認証、エラーハンドリング、テストコードでは、実際の仕様を渡してから生成させる方が安全です。

Composer 2.5とAPIワークフロー

実際のコーディングタスクの多くはAPIに触れます。たとえばComposer 2.5に「支払いサービスのクライアントを作成して」と依頼すると、見た目の良いコードは生成されます。

しかし、次のようなズレが起きる可能性があります。

エンドポイントのパスが実際と違う
リクエストフィールド名が違う
認証方式が違う
エラーレスポンスの形式が違う
必須フィールドと任意フィールドの扱いが違う

この失敗を避けるには、生成と検証を分けて考えます。

手順1：実際のAPI仕様をCursorに渡す

モデルに推測させるのではなく、実際のAPI仕様を参照させます。

Apidog MCPサーバーを使うと、ApidogのAPI仕様をCursorに接続できます。これにより、Composer 2.5は実際のスキーマに基づいて以下を生成できます。

リクエストコード
型定義
APIクライアント
テストコード
エラーハンドリング

他のエージェントも併用している場合は、Cursor向けの最高のMCPサーバーのまとめも参考になります。

手順2：生成されたAPI呼び出しをApidogで検証する

Composer 2.5が書いたエンドポイント呼び出しは、チームメイトのブランチに入る前に検証します。

実務では次の流れが有効です。

Composer 2.5でAPIクライアントやテストを生成する
生成されたリクエストをApidogに入れる
実際のリクエストを送信する
ステータスコードを確認する
レスポンス形状を確認する
動作する呼び出しを自動テストやモックサーバーに変換する

このループにより、エージェントの速度を維持しながら、API仕様とのズレを早期に潰せます。

ポイントは次の通りです。

実際の仕様に基づいて生成する
→ 実際のサーバーに対して検証する
→ 検証済みの呼び出しをテストとモックに固定する

これにより、速く生成されたコードがデバッグ負債になるのを防げます。

Composer 2.5 vs 競合製品

日常のメインツールとして選ぶ場合の比較です。

vs Opus 4.7

SWE-bench MultilingualとCursorBenchではほぼ同等です。タスクあたりのコストはComposer 2.5の方が大幅に安価です。ただし、Opus 4.7はCursorBenchの最大設定では依然として上位です。
vs GPT-5.5

Composer 2.5はSWE-bench MultilingualとCursorBenchでGPT-5.5を上回っています。一方、Terminal-Bench 2.0ではGPT-5.5が明確にリードしています。
vs Claude Code

ツールとしての形が異なります。Composer 2.5はCursorエディタ内で動作するエージェントで、Claude Codeはターミナルエージェントです。Claude Code vs Cursorの比較では、どちらがどのワークフローに向くかを整理しています。
vs GitHub Copilot

Copilotはインライン補完に強いツールです。Composer 2.5は、複数ファイルにまたがるエージェントタスクに向いています。詳細はCursor vs GitHub Copilotガイドで確認できます。

Cursorはまた、xAIと協力し、約10倍の計算量を使ってより大きなモデルをトレーニングしているとも述べています。Composer 2.5は到達点ではなく、より急な改善曲線上のチェックポイントと見るべきです。

よくある質問

Composer 2.5は無料ですか？

完全に無料のティアはありません。ただし、個人プランには通常の日常業務をカバーするComposer使用量プールが含まれています。また、Cursorはローンチ週に使用量を2倍にしました。

含まれる使用量の範囲は、Composer無料利用ガイドで確認できます。

Composer 2.5はComposer 2より優れていますか？

はい。測定可能に改善しています。SWE-bench Multilingualは73.7%から79.8%に上昇し、長いタスクでのコンテキスト保持も改善されています。

Composer 2ガイドは、改善前のベースラインを理解するのに役立ちます。

Composer 2.5は何のモデルに基づいていますか？

MoonshotのオープンソースKimi K2.5チェックポイントに基づいて構築されています。その後、Cursorによって強化学習と合成タスクを使った集中的なポストトレーニングが行われています。

標準と高速のどちらを選ぶべきですか？

知能は同じです。違いはレイテンシと価格です。

コスト効率を重視するバッチ作業には標準
ライブで反復する作業には高速

という使い分けが基本です。

Composer 2.5はAPI仕様やMCPと連携できますか？

はい。Cursorのエージェントツールセットをサポートしており、MCPも利用できます。

Apidog MCPサーバーを通じてAPI仕様を接続すれば、Composer 2.5は実際のスキーマに基づいてコードを生成できます。

結論

Composer 2.5は、「最先端品質のコーディング」と「高コスト」が切り離されつつあることを示すモデルです。Cursor内で、Opus 4.7に近い実ソフトウェアタスクの結果を、タスクあたり1ドル未満のコストで狙えます。

使い始める手順は簡単です。

Cursorをアップデートする
モデルドロップダウンでcomposer-2.5を選ぶ
通常チャットではなくエージェントモードを使う
1行修正ではなく、明確な完了条件を持つマルチステップタスクを渡す

さらに、API開発では検証ループを組み合わせることで効果が上がります。実際の仕様に基づいてAPIコードを生成し、Apidogをダウンロードしてライブリクエストを送信し、レスポンスを確認し、動作する呼び出しを自動テストとモックに固定します。

高速に生成されたコードより、検証済みで高速に生成されたコードの方が価値があります。

Bitwardenエージェントアクセス：AIコーディングエージェントと安全な資格情報共有方法

Akira — Fri, 15 May 2026 08:09:06 +0000

Claude Code、Codex、Cursor などの AI コーディングエージェントに実 API を触らせると、最初にぶつかるのが資格情報の扱いです。API キーをチャットに貼るとモデルのコンテキストに残り、.env に置くとエージェントの bash ツールから読めてしまいます。必要なのは「エージェントを信頼する」ことではなく、エージェントに渡す秘密情報を最小化する仕組みです。

今すぐ Apidog を試す

Bitwarden のオープンソースプロジェクト Agent Access は、この問題に対する資格情報共有プロトコル、CLI（aac）、Rust + Python SDK です。パスワードマネージャーとリモートプロセス（エージェント、CI ランナー、スクリプトなど）の間に暗号化トンネルを作り、必要なドメインまたは保管庫アイテムの資格情報だけを渡します。コンシューマー側が保管庫全体を見ることはありません。

この記事では、Agent Access のインストール、aac connect、aac run、Claude Code / Codex / Cursor での使い方、そして AI エージェント API 資格情報を保護する方法で説明されている資格情報分離パターンとの関係を実装ベースで整理します。

Agent Access とは

Agent Access は Bitwarden が構築したオープンプロトコルとリファレンス実装です。CLI の aac は Noise プロトコルを使ってエンドツーエンド暗号化されたトンネルを作成します。

構成は次の通りです。

プロバイダー: 保管庫側。接続要求を待ち受け、返す資格情報を決定する
コンシューマー: エージェント、スクリプト、CI ジョブなど。ドメインまたは保管庫アイテム ID で資格情報を要求する
資格情報のスコープ: 単一ドメインまたは単一アイテムに限定される
監査証跡: プロバイダー側とコンシューマー側の両方に残る

現時点では 早期プレビュー です。README では「API とプロトコルは変更される可能性があります」と明記されています。また、「機密性の高い資格情報を LLM や AI エージェントに直接入力することは推奨しません」と警告されています。

実運用で重要になるのは aac run です。これは秘密情報をエージェントのコンテキストに出さず、子プロセスの環境変数として注入します。

なぜ重要なのか

AI コーディングエージェントは、すでにリポジトリの編集だけでなく、テスト実行、API 呼び出し、デプロイまで行います。各ステップには資格情報が必要です。

しかし、資格情報を雑に扱うと漏洩リスクが高くなります。Postman の API キー漏洩事件が示したように、人間だけでも API キー管理は破綻しがちです。そこにエージェントが加わると、.env、ログ、シェル履歴、プロンプト履歴が新たな漏洩経路になります。

Agent Access の基本方針は次の通りです。

資格情報を実行時に取得する
必要なドメインまたはアイテムだけに限定する
転送中は暗号化する
プロセス終了後に秘密情報を残さない
LLM のコンテキストに秘密情報を入れない

既存の API キー管理ツールが一般的な秘密情報管理を扱うのに対し、Agent Access はエージェントとリモートプロセスのユースケースに焦点を当てています。

インストール

プラットフォームに合わせて aac をインストールします。

macOS Apple Silicon

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-aarch64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

macOS Intel

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Linux x86_64

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-linux-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Windows x86_64

最新リリースページから aac-windows-x86_64.zip をダウンロードし、PATH 上のディレクトリに展開します。

インストール後に確認します。

aac --help

Bitwarden CLI（bw）が PATH にある場合、aac はそれをデフォルトの資格情報プロバイダーとして使います。Bitwarden CLI がない状態で試す場合は、デモプロバイダーとして --provider example を指定します。

クイックスタート: ペアリングして資格情報を取得する

まず、保管庫を持つマシンでリスナーを起動します。通常は開発者のラップトップです。

aac listen

リスナーはペアリングトークンを出力します。

次に、コンシューマー側で接続します。リモートマシン、CI ランナー、または同じホスト上の別ターミナルで実行できます。

aac connect --token <pairing-token> --domain github.com --output json

レスポンス例です。

{
  "credential": {
    "notes": null,
    "password": "alligator5",
    "totp": null,
    "uri": "https://github.com",
    "username": "example"
  },
  "domain": "github.com",
  "success": true
}

ドメインではなく保管庫アイテム ID で取得する場合は、--id を使います。

aac connect --id <vault-item-id> --output json

--id と --domain は同時に指定できません。どちらか一方を選びます。

保管庫アイテムに TOTP が設定されている場合、TOTP コードも同じペイロードで返されます。

実運用パターン: `aac run` で環境変数を注入する

aac connect は JSON を返すので、スクリプトからパースして使えます。ただし、AI エージェントや CI でより安全に扱うなら aac run を使います。

aac run は次の処理を行います。

資格情報を取得する
指定したフィールドを環境変数として注入する
子プロセスを実行する
標準出力、ディスク、親プロセスに秘密情報を出さない

特定フィールドだけを注入する

aac run \
  --domain example.com \
  --env DB_PASSWORD=password \
  --env DB_USER=username \
  -- psql

この例では、保管庫の password を DB_PASSWORD に、username を DB_USER にマッピングします。

すべてのフィールドを注入する

aac run --domain example.com --env-all -- ./deploy.sh

--env-all を使うと、利用可能なフィールドが AAC_ プレフィックス付きで注入されます。

デフォルト注入と個別上書きを組み合わせる

aac run \
  --domain example.com \
  --env-all \
  --env CUSTOM_PW=password \
  -- ./deploy.sh

利用可能なフィールドは次の通りです。

username
password
totp
uri
notes
domain
credential_id

Bitwarden が AI エージェント向けに推奨しているのは、この aac run パターンです。

エージェントには次のようなコマンドだけを見せます。

aac run --domain api.stripe.com --env-all -- ./deploy.sh

モデルはパスワードや API キーの値を見ません。秘密情報は deploy.sh のサブプロセスにだけ渡されます。

この考え方は、AI エージェント API 資格情報を保護する方法で説明されている分離原則と同じです。

Python SDK を使う

CLI ではなくアプリケーションに直接組み込みたい場合は、Python SDK を使えます。

from agent_access import RemoteClient

client = RemoteClient("python-remote")

client.connect(token="ABC-DEF-GHI")

cred = client.request_credential("example.com")

print(cred.username, cred.password)

client.close()

Python モジュールは PyO3 をバックエンドに使います。重い処理は Rust 側で実行され、内部では同じ Noise プロトコル実装が使われます。

ただし、AI エージェントに対しては、資格情報を print() したりログに出したりしない設計にしてください。SDK を使う場合でも、秘密情報は下流処理に直接渡すのが基本です。

Rust SDK を使う

Rust SDK も RemoteClient インターフェースを提供しています。リファレンス実装はリポジトリの examples/rust-remote/ にあります。

Rust SDK が向いているケースは次の通りです。

独自 CLI ツールに資格情報取得を組み込む
ビルドランナーを実装する
コンパイル済みバイナリとして配布する
エージェントが呼び出すローカルツールに組み込む

既に API ツールを提供しているチームでは、HashiCorp Vault や Azure Key Vault との統合と併用できます。Agent Access はそれらのエンタープライズ保管庫を置き換えるものではなく、開発者ラップトップや CI ランナーでのエージェント利用に向いた補完レイヤーです。

Claude Code で使う

Claude Code には、資格情報を直接渡さず、aac run でラップしたスクリプトを実行させます。

例として、デプロイスクリプトを用意します。

# deploy.sh
#!/usr/bin/env bash

aac run --domain prod.example.com --env-all -- ./run-deploy.sh

実行権限を付けます。

chmod +x deploy.sh

Claude Code には ./deploy.sh を実行させます。プロンプトには API キーを書きません。

./deploy.sh を実行してステージング環境へデプロイしてください。

この場合、Claude Code が見るのはコマンドだけです。秘密情報は run-deploy.sh の子プロセスにだけ渡されます。

Claude Code GitHub Actions のような CI 統合でも同じ考え方を使えます。ランナーに aac をインストールし、保管庫プロバイダーとペアリングして、ジョブ実行時に必要な資格情報だけを取得します。

OpenAI Codex で使う

Codex CLI でも同じです。Codex にはスクリプトを呼ばせ、スクリプト内で aac run を使います。

# test-api.sh
#!/usr/bin/env bash

aac run --domain staging.example.com --env-all -- npm run test:api

Codex への指示は、資格情報ではなくタスクに限定します。

test-api.sh を実行し、失敗した API テストを修正してください。

Codex のツール呼び出しレイヤーにはコマンドが見えますが、秘密情報の値はモデルのコンテキスト外に残ります。

スマホからの Codex のようなワークフローでも、資格情報側はこの分離パターンで扱えます。

Cursor で使う

Cursor のターミナルコマンドや Composer ワークフローでも、aac run でラップしたスクリプトをそのまま使えます。

ローカル編集が中心の場合、リスナーとコンシューマーは同じマシン上で動かすことが多くなります。

aac listen

別ターミナルまたは Cursor から次を実行します。

aac run --domain local.example.com --env-all -- npm run dev

Cursor に .env の中身を読ませるのではなく、必要なコマンドを aac run 経由に寄せるのがポイントです。

OpenClaw で使う

Agent Access は公式の OpenClaw スキル を提供しています。リポジトリには SKILL.md が含まれています。

OpenClaw スタイルのスキルを使っているチームでは、スキル側がプロトコル形式を認識し、資格情報を取得して下流ツールへ渡します。

OpenClaw API キーガイドでは、このエコシステムでの資格情報管理をより広く扱っています。

セキュリティモデル

Agent Access のセキュリティ上のポイントは次の 3 つです。

1. Noise によるエンドツーエンド暗号化

コンシューマーとプロバイダー間の通信は Noise プロトコルフレームワークで暗号化されます。Noise は WireGuard や Signal でも使われるハンドシェイクファミリーです。

2. 資格情報はスコープされる

コンシューマーが取得できるのは、要求した単一ドメインまたは単一保管庫アイテム ID の資格情報だけです。保管庫全体を列挙することはできません。

3. `aac run` は秘密情報をディスクに書かない

aac run は秘密情報を環境変数として子プロセスに渡します。ファイルに書き込まず、標準出力に出さず、シェル履歴にも残しません。

Agent Access が防がないもの

Agent Access は万能ではありません。次のリスクは残ります。

侵害されたコンシューマープロセス

エージェントまたは子プロセスが悪意ある動作をすれば、スコープされた資格情報も漏洩し得ます。
侵害されたプロバイダー

Bitwarden 保管庫自体が侵害されていれば、このレイヤーでは守れません。
LLM への直接貼り付け

API キーをチャットやプロンプトに貼った時点で、Agent Access の外側に漏れます。README でも、機密資格情報を LLM や AI エージェントに直接入力しないよう明記されています。

実装パターン: エージェントが API を変更し、Apidog が契約を検証する

AI エージェントを API 開発に入れる場合、実用的なループは次の形です。

エージェントがコードを変更する

Claude Code、Codex、Cursor がエンドポイント変更の PR を作る。
CI がテストを実行する

テストランナーが aac run で API キーを取得し、ステージング環境に対してテストを実行する。
Apidog が契約を検証する

Apidog で OpenAPI 契約テストを別 CI ステップとして実行する。このステップも aac run 経由にする。

例です。

aac run \
  --domain staging-api.example.com \
  --env API_TOKEN=password \
  -- npm run test:contract

この構成では、エージェントはコードを変更できますが、API キーの値は見ません。契約テストは Apidog 側で実行され、秘密情報は保管庫から必要なプロセスにだけ渡されます。

AI 駆動の API 変更をテストする全体像は、API を呼び出す AI エージェントをテストする方法でも整理されています。

制限事項

現時点で注意すべき点です。

早期プレビュー

API とプロトコルは変更される可能性があります。本番ワークフローに固定する場合は、将来の追従コストを見込んでください。
デフォルトでは Bitwarden CLI が必要

デフォルトのプロバイダーは bw です。Bitwarden CLI をインストールするか、検証時は --provider example を使います。
設定ファイルはまだない

現状はフラグ駆動です。繰り返し使うコマンドはスクリプト化するのが現実的です。
LLM プロンプトに秘密情報を貼らない

Agent Access を入れていても、資格情報をチャットに貼れば保護できません。

FAQ

Agent Access は無料ですか？

はい。CLI、SDK、プロトコルは Bitwarden の GitHub 組織でオープンソースとして公開されています。ただし、保管庫として Bitwarden を使う場合は、Bitwarden の利用条件や料金が適用されます。

Bitwarden 以外でも使えますか？

プロトコルはベンダーニュートラルに設計されています。リファレンス実装には Bitwarden サポートとサンプルプロバイダーが含まれています。他のベンダーが独自プロバイダーを提供する余地があります。

パスワードマネージャーなしで試せますか？

検証目的なら可能です。デモプロバイダーを使います。

aac connect --provider example --domain test.com --output json

本番利用では実際のプロバイダーが必要です。

コンシューマープロセスにネットワークアクセスは必要ですか？

はい。コンシューマーはプロバイダーのリスナーに到達できる必要があります。リスナーとコンシューマーが同じホストにある場合は、ローカルだけでも構成できます。

`.env` と何が違いますか？

.env はディスク上に存在します。誤ってリポジトリにコミットされる可能性があり、エージェントがシェルを実行できるなら読み取れます。

aac run は秘密情報をプロセスメモリ上に限定し、子プロセスにスコープします。プロセス終了後は残りません。

HashiCorp Vault や AWS Secrets Manager の代替ですか？

いいえ。大規模なサービス間秘密情報管理では、HashiCorp Vault や AWS Secrets Manager のようなエンタープライズ向け保管庫が引き続き適しています。

Agent Access は、開発者ラップトップ、AI エージェント、CI ランナーのようなギャップを埋めるための仕組みです。

Anthropic や OpenAI は直接統合していますか？

現時点で発表されていません。現在の統合モデルは、エージェントが呼ぶスクリプトを aac run でラップする形です。

バグ報告や貢献はどこで行いますか？

GitHub リポジトリで issue、pull request、プロトコル議論を行えます。

まず試す手順

最小構成で試すなら、次の順番です。

aac をインストールする
ラップトップでリスナーを起動する

aac listen

別ターミナルでデモプロバイダーを使って接続する

aac connect --provider example --domain test.com --output json

JSON が返ることを確認する
デモプロバイダーを bw に置き換える
実際のスクリプトを aac run でラップする
API キーを AI エージェントに貼り付ける運用をやめる

API テスト側では、Agent Access と Apidog を組み合わせると責務を分離できます。

保管庫が秘密情報を保持する
Agent Access が実行時に必要最小限の資格情報を渡す
Apidog が API 契約を検証する
AI エージェントはコード変更に集中する

この形にすると、エージェントを開発ワークフローに入れつつ、資格情報をプロンプト、.env、ログ、シェル履歴から切り離せます。

2026年版：G2が選ぶAPI管理ツールおすすめ7選

Akira — Fri, 15 May 2026 07:37:46 +0000

G2 Spring 2026 API管理グリッドが発表されました。対象は、2つのリーダー（Apidog、viaSocket）、3つのハイパフォーマー（Traefik Labs、Rasayel、Backendless）、2つのニッチプレイヤー（Moesif/WSO2、Thunder Client）です。同じ「API管理」カテゴリでも、実際に解決する問題は大きく異なります。

今すぐApidogを試す

要約

ApidogとviaSocketがG2のSpring 2026 API管理グリッドをリードしています。

実装観点で見ると、選び方は次のようになります。

APIの設計、テスト、モック、ドキュメントを1つのワークスペースで管理したい → Apidog
SaaS間の処理をWebフックやAPIで自動化したい → viaSocket
Kubernetes前提でAPIゲートウェイを運用したい → Traefik Labs
WhatsApp Business APIを業務に組み込みたい → Rasayel
バックエンドを自前で構築せずAPIを自動生成したい → Backendless
公開APIの利用状況、課金、分析を見たい → Moesif
VS Code内で軽量にREST APIを叩きたい → Thunder Client

重要なのは、G2のクアドラント順位だけでなく、自分のチームにとって「API管理」が何を意味するかです。

G2のSpring 2026グリッドが示すもの

G2のSpring 2026レポートは、2026年3月17日に27,019件公開され、四半期で1.72%増加しました。G2のマーケティング担当副社長Palmer Houchinsによると、すべてのカテゴリでリーダーバッジを獲得する製品はG2全体のわずか3%です。

G2グリッドは、次の2軸で製品を評価します。

顧客満足度：レビューに基づく評価
市場での存在感：規模、リーチ、レビュー数など

Spring 2026のAPI管理カテゴリでは、ApidogとviaSocketがリーダーに分類されています。Traefik Labs、Rasayel、Backendlessはハイパフォーマー、Moesif（現在はWSO2傘下）とThunder Clientはニッチプレイヤーです。

ただし、クアドラントよりも適合性が重要です。ニッチツールでも、解決したい問題に合っていれば最適です。逆にリーダー製品でも、チームの課題と合わなければ過剰です。

まずは、Apidogをダウンロードして、自分のAPIワークフローに合うか確認できます。

7つのツールを一覧で見る

ツール	G2クアドラント	最適な用途	オープンソース？	価格モデル
Apidog	リーダー	オールインワンのAPIデザイン、テスト、モック、ドキュメント	無料枠 + 有料	ユーザーごとのSaaS
viaSocket	リーダー	APIフックによるノーコードのワークフロー自動化	いいえ	月額50ドルのエントリープラン
Traefik Labs	ハイパフォーマー	クラウドネイティブAPIゲートウェイ + GitOpsガバナンス	はい（Proxy OSS）	無料OSS、有料Hub
Rasayel	ハイパフォーマー	WhatsApp Businessメッセージング + REST API	いいえ	シートごとのSaaS
Backendless	ハイパフォーマー	自動生成RESTおよびGraphQLを備えたBaaS	いいえ	無料枠 + 有料
Moesif（WSO2）	ニッチ	API分析、可観測性、収益化	いいえ	使用量ベース
Thunder Client	ニッチ	VS Code RESTクライアント（シングルユーザーテスト）	いいえ	無料 + プロ有料

G2のカテゴリには、ライフサイクルプラットフォーム、iPaaS自動化、ゲートウェイ、分析、IDE拡張機能が同じグリッドに含まれています。そのため、実装したいワークフローを基準に比較する必要があります。

Apidog：エンドツーエンドのAPIワークフローのリーダー

Apidogは、APIの設計、テスト、モック、ドキュメントを1つのワークスペースにまとめる製品です。複数ツールをつなぎ込む代わりに、API仕様を中心にチーム全体の作業を同期できます。

Apidogで実行できる主な作業は次のとおりです。

API設計：OpenAPI 3.0/3.1ベースのスキーマファースト設計
テスト：ビジュアルテストビルダー、CI/CD連携、スクリプト不要のケース作成
モック：スキーマから動的レスポンスを生成
ドキュメント：公開URLまたは非公開URLでAPIドキュメントを生成
コラボレーション：リアルタイム同期、バージョン管理、ロールベースアクセス

実装フローは次のように組めます。

OpenAPI仕様を作成またはPostmanコレクションからインポートする
エンドポイント、リクエスト、レスポンススキーマを定義する
フロントエンド向けにモックサーバーを公開する
QAが同じ仕様からテストケースを作成する
ドキュメントを自動生成してチームや外部開発者に共有する
CI/CDでAPIテストを実行する

Apidogが特に向いているのは、API仕様を単一の信頼できる情報源として管理したい100人以下のエンジニアリングチームです。バックエンド、フロントエンド、QAが同じワークスペースで作業できるため、仕様のズレを減らせます。

Apidogをダウンロードすれば、Postmanコレクションをインポートしてすぐに試せます。クレジットカードは不要で、無料枠から開始できます。

viaSocket：ノーコード統合チームのリーダー

viaSocketは、従来のAPIゲートウェイというより、ZapierやMakeに近いAIワークフロー自動化プラットフォームです。Webフック、条件分岐、カスタムJavaScriptを使ってSaaSアプリケーションを接続できます。

向いているユースケースは次のとおりです。

フォーム送信をCRMに登録する
決済イベントをSlackやメールに通知する
複数SaaS間で顧客データを同期する
Webフックをトリガーに業務フローを実行する

強みは、統合カタログ、カスタムAPIコール、Webフック対応、非開発者でも扱いやすいセットアップです。

一方で、以下の用途には向きません。

APIゲートウェイ
レート制限
OAuthフロー管理
契約テスト
内部マイクロサービスの管理

運用、マーケティング、営業、収益チームがSaaSツールを連携させるならviaSocketが適しています。公開APIを開発・出荷するエンジニアリングチームは、別の製品を検討すべきです。

Traefik Labs：API管理を搭載したオープンソースゲートウェイ

Traefik Proxyは、クラウドネイティブ環境で使われるオープンソースのアプリケーションプロキシです。Traefik Hubは、その上に開発者ポータル、ライフサイクル制御、GitOpsガバナンスなどを追加する商用レイヤーです。

向いている構成は次のようなものです。

Client
  ↓
Traefik Proxy / Traefik Hub
  ↓
Kubernetes Services
  ↓
Backend APIs

Traefik Labsの強みは次のとおりです。

Kubernetes Ingressとの相性がよい
サービスディスカバリーに対応
動的設定が可能
Let’s Encryptによる証明書管理を自動化できる
GitでAPI、ルート、ポリシーを管理できる
Traefik HubでAPI管理機能を追加できる

注意点は、API設計やテストのツールではないことです。KubernetesやゲートウェイレイヤーはTraefik、API設計とテストはApidogのような上流ツールで分担する構成が現実的です。

関連情報は、オープンソースAPI管理ツールのまとめとエンタープライズチーム向けのトップAPI管理プラットフォームも参考になります。

Rasayel：WhatsApp Business API向けプラットフォーム

Rasayelは、チーム受信箱、チャットボット、一括メッセージングを備えたWhatsApp Businessプラットフォームです。G2のAPI管理カテゴリに含まれている理由は、RESTおよびGraphQL APIとAPIキー管理UIを提供しているためです。

選ぶべきケースは明確です。

顧客サポートや営業をWhatsAppで運用している
WhatsAppメッセージをプログラムから送受信したい
HubSpotやPipedriveとWhatsAppを接続したい
Twilioを直接扱わず、Webフック経由で連携したい

一方で、次の用途には向きません。

内部マイクロサービスAPIの管理
エッジゲートウェイ
汎用APIライフサイクル管理
WhatsAppを使わないプロダクト

Rasayelは汎用API管理ツールではなく、WhatsApp Business APIの業務利用に特化した製品です。

Backendless：自動生成APIを備えたBaaS

Backendlessは、データモデルからRESTおよびGraphQLエンドポイントを自動生成するBackend-as-a-Serviceです。テーブルを定義するとAPIが生成され、サービスを定義するとメソッド単位で呼び出しを追跡できます。

典型的な使い方は次のとおりです。

データモデルを定義する
RESTまたはGraphQL APIを自動生成する
Android、iOS、JavaScript、.NET SDKから呼び出す
メソッド単位で権限を設定する
API呼び出しをサービスレベルで追跡する

Backendlessが向いているのは、バックエンドを自前で構築したくないスタートアップや小規模チームです。

向いていないのは次のケースです。

既存バックエンドの前段にAPI管理レイヤーを置きたい
契約ファーストでAPIを設計したい
ベンダーロックインを避けたい
オンプレミスで自由に展開したい

「サービスがすでにあり、ゲートウェイが必要」という課題なら、BackendlessではなくTraefikなどのゲートウェイ製品を検討すべきです。

Moesif（WSO2社）：API分析と収益化

Moesifは、実行中のAPIに対する分析、可観測性、収益化のためのツールです。ゲートウェイやAPI設計ツールではありません。

WSO2は2025年5月にMoesifを買収し、WSO2のChoreoプラットフォームの分析レイヤーとして統合を進めています。Moesifは、独自のロードマップを持つ独立した子会社として引き続き運営されています。

Moesifで確認できる主な情報は次のとおりです。

ユーザーごとのAPI利用状況
エンドポイントごとのリクエスト傾向
地域別トラフィック
異常検出
使用量ベース課金
プラン管理
顧客ダッシュボード
APIコンシューマーのファネル分析
リテンション分析

向いているのは、公開APIを運用しており、誰が、どのAPIを、いつ、どれだけ使っているかを把握したいチームです。使用量ベースの料金体系を導入する場合にも適しています。

まだ公開APIを出荷していない場合や、ゲートウェイそのものが必要な場合には、Moesifは最初に導入するレイヤーではありません。

Thunder Client：VS CodeのRESTクライアント拡張機能

Thunder Clientは、VS Code内でHTTPリクエストを送信するためのRESTクライアント拡張機能です。PostmanやInsomniaに近い用途ですが、エディタから離れずに使える点が特徴です。

得意なことは次のとおりです。

VS Code内でREST APIをテストする
コレクションをJSONとしてリポジトリに保存する
Gitでリクエスト定義を管理する
環境変数を使う
基本的なテストアサーションを書く

一方で、以下は対象外です。

チーム全体のAPIコラボレーション
API設計プラットフォーム
モックサーバー
ドキュメント生成
APIゲートウェイ

チームで使う場合は、コラボレーション機能の制約を確認してください。詳細はチーム向けThunder Client：コラボレーションの制限で解説されています。

Thunder Clientは、「コードを書きながらエンドポイントを素早く確認したい」ソロ開発者に向いています。設計、テスト、モック、ドキュメントまでチームで管理するなら、ApidogのようなAPIライフサイクルツールが適しています。

チームに適したツールの選び方

まず、自分のチームにとっての「API管理」を定義してください。

やりたいこと	適したツール
API設計、テスト、モック、ドキュメント	Apidog
ゲートウェイ、ルーティング、JWT、レート制限	Traefik
出荷済みAPIの分析、利用状況、課金	Moesif
SaaS間のワークフロー自動化	viaSocket
バックエンドを自動生成	Backendless
WhatsApp Business連携	Rasayel
VS Code内でRESTテスト	Thunder Client

チーム規模でも選び方は変わります。

ソロ開発者：Thunder ClientまたはApidogの無料枠
5〜50人のチーム：Apidog、Backendless、Traefik Hubを用途別に検討
100人以上の開発組織：TraefikまたはKongをエッジに置き、Moesifで分析し、Apidogで設計とテストを管理する構成が現実的

制約別に見ると、次のようになります。

予算重視：Apidog無料枠、Traefik Proxy OSS、Backendless無料枠
導入スピード重視：Apidog、viaSocket
ガバナンス重視：Traefik Hub、Apidog、Moesif

関連情報として、50人エンジニアチームのためのAPIテストツールと、Apidog、Stoplight、SwaggerHubを比較したデザインファーストAPIプラットフォーム比較も参考になります。

Spring 2026グリッドが教えてくれること

G2のSpring 2026 API管理グリッドにある7つのツールは、すべてが同じ土俵で競合しているわけではありません。それぞれ、APIライフサイクルの異なる問題を解決しています。

選定前に確認すべきポイントは次のとおりです。

Apidogは、API設計、テスト、モック、ドキュメントをまとめたいチーム向け
viaSocketは、ノーコードでSaaS連携を自動化したいチーム向け
Traefikは、クラウドネイティブなゲートウェイ運用向け
Rasayelは、WhatsApp Business API向け
Backendlessは、BaaSとしてAPIを自動生成したいチーム向け
Moesifは、API分析と収益化向け
Thunder Clientは、VS Code内の軽量RESTテスト向け

チームがAPIの設計、テスト、モック、ドキュメントを扱うなら、まずApidogから試すのが実装しやすい選択です。Apidogをダウンロードすれば、Postmanからインポートして数分で既存APIのワークスペースを作成できます。

ゲートウェイ側の選定については、2026年の開発者向けトップ10 APIゲートウェイも参考になります。

Apidog A2Aデバッガーでエージェント間(A2A)プロトコルをデバッグする方法

Akira — Fri, 15 May 2026 04:21:20 +0000

他のAIエージェントと対話するAIエージェントを構築していると、すぐに「エージェント間で実際に何が送受信されているのか」を確認しづらい問題にぶつかります。コンソールログは断片的で、ブラウザのネットワークタブでは構造化フィールドを追いにくく、専用テストスクリプトは仕様変更ですぐ古くなります。ApidogのA2Aデバッガーを使うと、Agent2Agent（A2A）プロトコルのエージェントカードURLを貼り付け、接続し、メッセージを送信し、応答を3つのビューで確認できます。

今すぐApidogを試す

このガイドでは、A2Aデバッガーでできること、最初のエージェントへの接続手順、リクエストとレスポンスの確認方法、そしてApidogの既存のMCPサーバーテストツールとの使い分けを実装目線で説明します。A2AとMCPの全体像を先に確認したい場合は、ApidogのMCPとA2Aに関する詳細な記事も参考になります。

A2Aとは何か（要約）

A2A（Agent2Agent）は、エージェント間通信のためのオープンプロトコルです。主に次の内容を定義します。

エージェントが自身の能力をエージェントカードとして公開する方法
別のエージェントがそのカードを使って接続する方法
メッセージやファイル添付を交換する方法
タスクのステータスを報告する方法

HTTPがWeb上の通信の共通レイヤーであるように、A2Aはエージェント間トラフィックの共通レイヤーとして機能します。たとえば、データパイプライン内のLangGraphエージェントが、別チームのCrewAIエージェントに内部実装を知らずにリクエストを送る、といった構成を実現できます。

MCP（Model Context Protocol）は、単一のエージェントにツールやリソースへのアクセスを提供するためのプロトコルです。一方、A2Aはエージェント同士の通信に焦点を当てます。違いを詳しく確認したい場合は、MCPとA2Aの違いの解説を参照してください。

A2Aデバッガーでできること

A2AデバッガーはApidog内で利用できる、A2Aエンドポイント用のビジュアルデバッグ環境です。本番ワークフローに組み込む前に、接続、認証、メッセージ送信、応答構造を確認できます。

主な機能は次のとおりです。

エージェントカード接続

URLを貼り付けて「接続」をクリックすると、エージェント名、説明、機能、宣言されたスキル、プロトコルバージョンを確認できます。カード形式が不正な場合は接続エラーとして検出できます。
メッセージ送信

プレーンテキストを送信し、必要に応じてファイル添付やカスタムメタデータを追加できます。
3つの応答ビュー

プレビュー、コンテンツ、生データの3種類で同じ応答を確認できます。
認証設定

ベアラートークン、基本認証、カスタムヘッダー経由のAPIキーをUIから設定できます。
カスタムヘッダー

ゲートウェイ認証、テナントID、トレースID、ビジネスパラメータなどをHTTPヘッダーとして追加できます。
セッション履歴

送信したメッセージと応答がセッション内に残るため、同じ接続で複数のケースを比較できます。

curlコマンドを手書きする必要はありません。ApidogがJSON-RPCエンベロープ、SSEストリーミング（エージェントがサポートしている場合）、応答の解析を処理します。

ステップ1：最初のA2Aエージェントに接続する

デバッガーを開く前に、次の3つを準備します。

最新のApidogクライアント

A2Aデバッガーを使うには、対応バージョンのApidogが必要です。未インストールの場合は、Apidogをダウンロードしてください。
エージェントカードのURL

A2A準拠エージェントの標準的なエントリポイントです。ローカル開発では、たとえば次のようなURLになります。

   http://localhost:3000/.well-known/agent.json

認証情報（必要な場合） ベアラートークン、APIキー、基本認証情報などを用意します。

接続手順は次のとおりです。

Apidogを開く
A2Aデバッガーページに移動する
上部の入力欄にエージェントカードURLを貼り付ける
必要に応じて認証情報やヘッダーを設定する
接続をクリックする

有効なエージェントカードが返ると、ステータスが接続済みになり、パネルに次のようなメタデータが表示されます。

エージェント名
説明
機能
宣言されたスキル
プロトコルバージョン

接続に失敗した場合は、次を確認してください。

URLが正しいか
エージェントプロセスが起動しているか
ブラウザでURLにアクセスするとJSONが返るか
エージェントカードに必須フィールドがあるか
GitHubのA2Aプロトコル仕様とカード構造が一致しているか
ディスカバリーエンドポイントで認証が必要な場合、Apidog側に資格情報を設定しているか

ステップ2：テストメッセージを送信する

接続できたら、メッセージタブを開きます。チャットUIと同じ感覚でプロンプトを入力します。

例：

共有ナレッジベースにある最新の3つの顧客フィードバックを要約し、サポートチーム向けに1段落の返信を作成してください。

送信前に、必要に応じて次を追加します。

ファイル添付

クリップアイコンからファイルを選択します。デバッガーはエージェントが宣言している入力タイプを確認し、サポートされていないファイルタイプを事前に拒否します。これにより、不要な415エラーの往復を減らせます。

カスタムメタデータ

メッセージごとのコンテキストをキーと値で追加できます。

例：

priority: high
tenant: acme-corp
locale: ja-JP

これらはA2Aリクエストエンベロープに含まれ、エージェント側のハンドラーが読み取れる場合に利用されます。

準備できたら、送信をクリックします。Apidogは入力内容をA2Aメッセージ構造にラップし、エージェントへ送信して応答を待ちます。

ステップ3：3つのビューで応答を確認する

A2Aの応答は、プレーンテキスト、構造化JSON、ファイル参照、またはそれらの組み合わせで返ることがあります。Apidogでは、同じペイロードを3つのビューで確認できます。

プレビュー

構造化フィールドをツリー形式で表示します。次のようなネストされた情報を追うときに便利です。

タスクID
ステータス
成果物
履歴
エラー詳細

コンテンツ

人間が読む本文を表示します。エージェントがテキストを返した場合、実際にユーザーへ表示する内容に近いビューです。

生データ

完全なJSON-RPCペイロードを表示します。仕様準拠の確認、バグレポート、フィールド名やエスケープ文字の確認に使います。

デバッグ時は、まず生データを確認するのがおすすめです。たとえば次のように切り分けられます。

プレビューは正しいがコンテンツが空

→ エージェントがApidogでレンダリング可能だが、テキストとして平坦化できない型のアーティファクトを返している可能性があります。
生データにerror.messageがある

→ エージェント側がリクエストを拒否しています。エラーコードとメッセージを確認します。
応答構造は正しいが内容が期待と違う

→ トランスポートではなく、プロンプト、モデル、エージェントロジック側の問題として切り分けられます。

セッション履歴は左側のパネルに表示されます。古い文脈が次のテストに影響しないようにしたい場合は、クリアをクリックして履歴をリセットします。

認証：3つの一般的なパターン

本番環境のA2Aエンドポイントは、多くの場合、認証の背後にあります。Apidogでは、よく使われる3つのパターンをUIから設定できます。

ベアラートークン

ホスト型エージェントでよく使われる形式です。認証パネルでベアラートークンを選択し、トークンを貼り付けます。

Apidogは各リクエストに次のヘッダーを追加します。

Authorization: Bearer sk-agent-7f3e9a...

基本認証

ユーザー名とパスワードで保護された内部システムやレガシーシステムで使われます。基本認証を選択し、ユーザー名とパスワードを入力すると、ApidogがBase64エンコード済みのAuthorization: Basic ...ヘッダーを生成します。

カスタムヘッダー経由のAPIキー

エージェントが非標準のヘッダー名を期待する場合は、ヘッダーセクションに手動で追加します。

例：

X-Agent-Key: your-api-key
X-Tenant-Id: acme-corp
X-Request-Id: debug-001

CSRFトークン、テナントID、リクエスト署名など、ゲートウェイ固有のヘッダーも同じ方法で追加できます。

エージェント資格情報の管理については、Apidog AIエージェント資格情報ガイドで、ローテーション、スコープ、コミットしてはいけない情報について説明しています。

カスタムヘッダーとメタデータ：どちらをいつ使うか

A2Aリクエストには、追加データを置ける場所が2つあります。どちらもキーと値を扱えますが、属するレイヤーが異なります。

チャネル	場所	用途
カスタムヘッダー	HTTPリクエストヘッダー	ゲートウェイ認証、可観測性（`X-Request-Id`）、機能フラグ
メタデータ	A2Aメッセージペイロード	エージェントが読むメッセージごとのコンテキスト（優先度、テナント、ロケール）

判断基準はシンプルです。

リバースプロキシ、APIゲートウェイ、監視基盤が使う値

→ ヘッダーに置く
エージェントのタスクハンドラーが使う値

→ メタデータに置く

この2つを混同すると、「ヘッダーに入れたのにエージェントが読めない」「メタデータに入れたのにゲートウェイが認識しない」といった問題が起きます。

ApidogにおけるA2AデバッガーとMCPサーバーテストの比較

ApidogはA2AデバッガーとMCPテストフローの両方を提供しています。ただし、対象とするプロトコルとテスト内容は異なります。

ツール	プロトコル	テスト項目	使用する状況
A2Aデバッガー	Agent2Agent	接続性、メッセージ交換、タスクステータス	エージェントが他のエージェントを呼び出すマルチエージェントシステムを構築する場合
MCPサーバーテスト	Model Context Protocol	ツール呼び出し、リソースアクセス、プロンプトテンプレート	エージェントにツールやリソースを公開するMCPサーバーを構築する場合

どちらを使うべきか迷った場合は、MCPとA2Aのガイドを確認してください。

短くまとめると、次のようになります。

MCP：エージェントが外部システム、ツール、リソースへアクセスするためのプロトコル
A2A：エージェントが他のエージェントと通信するためのプロトコル

MCP側のワークフローについては、MCPサーバーテストプレイブックで、Apidogにおける手動および自動テストの流れを説明しています。現実のエージェントシステムでは、A2Aによるエージェント間連携と、MCPによるツールアクセスを組み合わせるケースが多くなります。

一般的なデバッグパターン：タスクの往復を切り分ける

「エージェントが期待通りに応答しない」ときは、次のループで確認します。

A2Aデバッガーを開く
エージェントカードURLで接続する
エージェントカードに期待するスキルが表示されているか確認する
そのスキルをトリガーする最小限のメッセージを送る
最初はファイルやメタデータを付けず、プレーンテキストだけで試す
応答の生データを確認する
期待するフィールドが欠落している場合は、エージェントコード側を確認する
応答構造は正しいが内容が違う場合は、プロンプトやモデル出力を確認する

この流れにより、問題を次のどちらかに分離できます。

通信、認証、A2Aエンベロープの問題
エージェントのロジック、プロンプト、モデル応答の問題

これは、APIを呼び出すAIエージェントをテストする方法で説明している「非難する前に分離する」デバッグループと同じ考え方です。まず通信を確認し、その後でロジックをデバッグします。

AIワークフローにおける位置付け

マルチエージェントシステムでは、エージェント同士の通信を通常のAPIトラフィックと同じように観測、検証、デバッグできる必要があります。AIエージェントは新しいAPIコンシューマーであるという記事では、エージェントトラフィックを第一級のAPI利用者として扱う理由を説明しています。

また、AIエージェント向けAPIの設計では、APIの利用者が人間の開発者ではなくLLM駆動型エージェントになる場合に、API契約やエラーメッセージ設計をどう変えるべきかを解説しています。

A2Aデバッガーは、ApidogのMCPクライアントビジュアルデバッガーと同じく、SDK内部に隠れがちなエージェント通信を可視化するためのツールです。

エージェントを接続し、送受信されるデータを確認し、本番環境に到達する前にバグを修正できます。

Apidogは無料でダウンロードでき、A2Aデバッガーは標準クライアントに含まれています。別途ライセンスやプランは不要です。

よくある質問

A2Aデバッガーは無料ですか？

はい。標準のApidogクライアントにバンドルされています。Apidogをダウンロードし、対応バージョンを使用していれば、A2Aデバッガーがサイドパネルに表示されます。

あらゆるフレームワークで書かれたエージェントに対応していますか？

有効なA2Aエージェントカードを公開しているエージェントであれば利用できます。A2Aはフレームワークに依存しないため、LangGraph、CrewAI、AutoGen、カスタムのPythonまたはGoエージェントでも、A2A仕様に準拠していれば動作します。

セッションを保存して後で再生できますか？

セッションはデバッガーを開いている間は保持されます。長期保存したい場合は、生データの出力をコピーしてテスト成果物として保存してください。完全なセッションエクスポートはロードマップにあります。

ストリーミング応答はどのように処理されますか？

エージェントがA2A仕様に基づくSSEストリーミングをサポートしている場合、デバッガーはチャンクが到着するたびに読み取り、プレビューとコンテンツをリアルタイムで更新します。ストリームが閉じると、生データに組み立てられた応答が表示されます。

メタデータフィールドとヘッダーセクションの違いは何ですか？

ヘッダーはHTTPレイヤー、メタデータはA2Aメッセージレイヤーです。ヘッダーはゲートウェイやリバースプロキシに届き、メタデータはエージェントのタスクハンドラーに届きます。判断に迷った場合は、前述の比較表を参照してください。

Apidogはエージェントの応答をApidogのサーバーにログ記録しますか？

いいえ。Apidogはローカルクライアントとして動作します。お使いのマシンとエージェント間のトラフィックは、Apidogのインフラストラクチャを通過しません。

A2Aデバッガーで、異なるネットワーク上のホスト型エージェントをテストできますか？

はい。ネットワークパスが開いていれば可能です。デバッガーは通常のHTTPクライアントと同じようにアウトバウンドHTTPSリクエストを送信します。エージェントがVPNの背後にある場合は、そのVPNに接続してからテストしてください。

バグ報告や機能リクエストはどこに送ればよいですか？

Apidogに関するフィードバックは、Apidogのフィードバックチャネルに送ってください。A2A仕様そのものに関するリクエストは、A2AプロトコルのGitHubリポジトリに提出してください。

今すぐ試す

まず、アクセスできる最もシンプルなA2Aエージェントを用意します。まだエージェントがない場合は、A2Aリファレンス実装に含まれるサンプルサーバーをローカルで実行できます。

最小の確認手順は次のとおりです。

サンプルまたは既存のA2Aエージェントを起動する
エージェントカードURLを確認する
ApidogのA2AデバッガーにURLを貼り付ける
接続をクリックする
helloのような短いメッセージを送る
プレビュー、コンテンツ、生データの3つのビューを確認する

これが最小限のエンドツーエンドループです。ここから、実際のプロンプト、ファイル添付、メタデータ、マルチエージェントワークフローへ段階的に広げていけます。

A2AデバッガーをApidogのAPIおよびMCP機能と組み合わせることで、HTTP、MCP、A2Aというエージェントシステムの主要な通信レイヤーを1つのインターフェースで確認できます。

スマホでOpenAI Codexを使う方法：2026年iOS＆Androidガイド

Akira — Fri, 15 May 2026 03:05:29 +0000

OpenAIは今週、モバイル版Codexをリリースしました。2026年5月14日、iOSおよびAndroid版ChatGPTアプリに、無料プランやGoプランを含むすべてのプランでフル機能のCodexエクスペリエンスが追加されました。これにより、ラップトップがスリープしていても、スマートフォンから実行中タスクの監視、コマンド承認、モデル切り替え、新規作業の開始ができます。

今すぐApidogを試す

Apidog読者からは、本格的なAIコーディングをスマートフォンでいつ使えるのかという質問がありました。答えは「今」です。この記事では、モバイル版Codexでできること、セットアップ手順、最初に試すべき実装フローをまとめます。

ターミナルで動くコーディングエージェントの前提を確認したい場合は、Codex CLIのセットアップガイドを参照してください。AnthropicやCursorのモバイル運用と比較したい場合は、モバイル版Claude CodeのウォークスルーとスマートフォンでCursorを実行する記事が参考になります。API開発と組み合わせる場合は、ApidogでAPI設計・テスト環境を用意しておくと、Codexが生成した変更を検証しやすくなります。

「どこからでもCodex」とは

OpenAIの今回の発表は、モバイルアプリだけではありません。「どこからでもCodex」は、次の4つのインターフェースを指します。

ChatGPTモバイルアプリでのCodex：iOS、Android、プレビュー、全プラン対応
SlackでのCodex：Plus、Pro、Business、Enterprise、Eduで利用可能。スレッドで@Codexをメンション
Codex Chrome拡張機能：2026年5月7日リリース。ブラウザを占有せずにタブ間で動作
Codex SDK：自社スクリプトやCIからCodexをプログラム制御

モバイル版の主な価値は、コードを書く場所をスマートフォンに移すことではなく、実行中のエージェント作業を外出先から制御できることです。

たとえば、次のような運用ができます。

SlackスレッドでCodexに修正タスクを渡す
Codexがクラウド環境で作業する
スマートフォンで差分とログを確認する
問題なければ承認する
CIやAPIテストを通してマージ判断する

iOSとAndroidでCodexをセットアップする

モバイル版Codexは、既存のChatGPTアプリ内に組み込まれています。別アプリのインストールは不要です。

ステップ1：ChatGPTアプリをアップデートする

iOSではApp Store、AndroidではPlay Storeを開き、ChatGPTアプリを最新バージョンに更新します。

Codexの変更履歴によると、モバイル版Codexには2026年5月13日以降のリリースが必要です。

ステップ2：デスクトップ版と同じアカウントでサインインする

モバイル版Codexは、Web版と同じスレッド、環境、接続済みホストを参照します。

すでにChatGPTまたはCodex CLIで使っているOpenAIアカウントでログインしてください。

ステップ3：クラウド環境を接続する

ターミナルだけでCodexを使っている場合、モバイルアプリから操作するには少なくとも1つのクラウド環境が必要です。

Webアプリで次の順に設定します。

設定を開く
Codexを選択
環境に移動
GitHubを連携
対象リポジトリを設定

モバイル版はこの設定を引き継ぎます。

ステップ4：Codexタブを開く

ChatGPTアプリの下部ナビゲーションで、Codexをタップします。

ここに、アクティブなタスクとスレッドが一覧表示されます。

ステップ5：小さなテストタスクを実行する

最初は、リスクの低い変更から試してください。

例：

READMEにセットアップ手順の1行説明を追加してください。

または：

この関数にdocstringを追加してください。挙動は変更しないでください。

確認ポイントは次の通りです。

スマートフォンに差分が表示されるか
実行ログを確認できるか
承認フローが機能するか
PRまたはブランチへの反映が期待通りか

この最小フローが動けば、長時間実行タスクや複数ファイル修正にも進めます。

スマートフォンからできること

モバイル版Codexは、スマートフォンをコードエディタにするというより、リモートコーディングエージェントのコントロールパネルとして使います。

スマートフォンから可能な操作は次の通りです。

ラップトップ、開発ボックス、接続済みリモート環境でのライブ実行を監視
スレッドを閲覧し、並行タスクを切り替え
ブランチにマージされる前の差分をレビュー
Codexが実行したいコマンドを承認
必要に応じてタスク途中でモデルを切り替え
新しいプロンプトまたはGitHubイシューから新規タスクを開始
Codexが作成したプルリクエストにコメント

OpenAIの説明では、スマートフォンから「すべてのスレッドにわたって作業し、出力をレビューし、コマンドを承認し、モデルを変更し、新しい作業を開始」できます。

ただし、モバイル版はVS Codeのような本格的なエディタではありません。直接コードを細かく編集するのではなく、Codexに指示し、生成された変更を確認・承認する使い方になります。

SlackからCodexに作業を依頼する

Slack連携は、モバイル版と同時にリリースされました。チーム運用では、SlackがCodexへのタスク投入口になります。

仕組み

ワークスペース管理者がCodex Slackアプリをインストールした後、チャンネルまたはスレッドで@Codexをメンションします。

例：

@Codex このIssueの再現テストを追加し、失敗するテストを修正してください。
対象リポジトリは api-service です。

Codexは次のように動作します。

設定済み環境から適切なものを選択
環境マップの最初のリポジトリをデフォルトとして使用
リポジトリ指定があれば上書き
絵文字で反応
タスクリンクを投稿
作業完了後に結果をスレッドへ返信

必要なもの

Slack連携には次が必要です。

ChatGPT Plus、Pro、Business、Enterprise、またはEduプラン
接続済みGitHubアカウント
少なくとも1つの設定済みクラウド環境
Slackアプリをインストールするためのワークスペース管理者承認

無料プランはSlack連携の対象外です。

Enterprise管理者は、Codexの回答投稿を無効にし、タスクリンクのみを共有させる設定もできます。これにより、生成コードがSlackチャンネルの履歴に残ることを避けられます。

実用パターン：Issueトリアージ

GitHub IssueをSlackチャンネルに流しているチームでは、次の流れが実用的です。

新規IssueがSlackに投稿される
担当者がスレッドで@Codexに再現・修正を依頼
Codexが修正案またはPRを作成
人間がスマートフォンまたはデスクトップでレビュー

似た運用例として、OpenClaw GitHubトリアージボットの記事も参考になります。

Codex SDKでプログラム制御する

Codex SDKは、チーム内ツール、スケジューラ、CIランナーからCodexを操作したい場合に使います。

一般的な構成は次のようになります。

from openai import Codex

client = Codex()

task = client.tasks.create(
    repo="apidog/awesome-api",
    prompt="Add OpenAPI examples to every endpoint missing them.",
    environment="prod-mirror",
)

for event in client.tasks.stream(task.id):
    print(event.summary)

使いどころは次の通りです。

放置されたIssueに対して夜間ジョブでフォローアップPRを作る
マージ前に不足しているテストをCodexに追加させる
API仕様に対するサンプルやドキュメントの不足を検出して補完する
CIの失敗内容をもとに修正候補を生成する

Enterpriseワークスペースでは、非対話型フロー向けのアクセストークンを発行できます。この機能は2026年5月5日にリリースされました。

すでにGitHub ActionsでClaude Codeを使っているチームにとって、Codex SDKはOpenAI側で同様の役割を担います。

プラン、料金、提供状況

モバイルプレビューは、無料プランおよびGoプランを含むすべてのプランで利用可能です。一方で、SlackやSDKなど一部インターフェースにはプラン制限があります。

インターフェース	無料	Go	Plus	Pro	Business	Enterprise / Edu
モバイル (iOS + Android)	はい (プレビュー)	はい	はい	はい	はい	はい
Slack連携	いいえ	いいえ	はい	はい	はい	はい
Chrome拡張機能	はい (プレビュー)	はい	はい	はい	はい	はい
Codex SDK	制限あり	制限あり	はい	はい	はい	はい
Enterpriseアクセストークン	いいえ	いいえ	いいえ	いいえ	いいえ	はい

Codexの費用を詳しく確認したい場合は、GPT-5.5の料金内訳にトークンごとの料金が記載されています。無料で試したい場合は、オープンソース向けの無料Codexガイドを参照してください。

スマートフォン版Codexと競合製品の違い

モバイルコーディングエージェントには複数の選択肢があります。代表的なものは次の3つです。

OpenAI Codex

ChatGPTとの統合が強く、モバイルUXが用意されています。無料プランでもモバイルプレビューを利用できます。
モバイル版Claude Code

Claude Codeのモバイルセットアップは、tmuxセッションとSSHクライアントを使う構成です。DIY要素は強いものの、長時間実行されるターミナル作業には向いています。
スマートフォン版Cursor

Cursorのモバイルワークフローは、リモート開発とCursorのWebプレビューに依存します。デスクトップでCursorを多用しているチームに合います。

デスクトップ版を含めて比較したい場合は、Claude Code vs Codex 2026の比較記事が分かりやすいです。より広く見るなら、Copilot vs Claude vs Cursor vs Codexの4者比較も参考になります。

API開発で組み合わせる実装フロー

スマートフォン上のコーディングエージェントは、生成したコードが本番環境で正しく動く場合に価値があります。特にAPI変更では、契約の破壊やテスト漏れが問題になりやすいです。

Apidogを使うと、APIクライアント、OpenAPIエディタ、自動テストランナーを組み合わせて、Codexの変更を検証できます。

実用的なフローは次の通りです。

CodexがモバイルまたはSlack経由でAPI関連のPRを作成
ApidogのCIがプレビューデプロイに対して既存のOpenAPIテストスイートを実行
テストがグリーンなら、スマートフォンから差分を承認
問題があれば、失敗ログをもとにCodexへ追加修正を依頼

関連する実装例は、Apidog ChatGPT APIテストガイドとAPIを呼び出すAIエージェントをテストする方法で説明されています。

今すぐ試す場合は、Apidogをダウンロードして、APIテストスイートを先に用意しておくと安全です。

よくある質問

モバイル版Codexはオフラインで動作しますか？

いいえ。CodexはOpenAIのクラウドまたは接続された環境で動作します。ネットワークがない場合、アプリは最後に認識したスレッド状態を表示できますが、新しいタスクは開始できません。

モバイルアプリで直接コードを編集できますか？

期待されているようなエディタ操作はできません。プロンプト入力、レビュー、承認は可能です。モバイル版はエディタではなく、リモートエージェントのコントロールサーフェスです。

モバイル版はデスクトップ版より遅いですか？

エージェント自体は同じバックエンドで動作します。遅く感じる主な理由は、スマートフォンの画面サイズです。長い差分はスマートフォンでは確認しづらいため、概要確認はモバイル、本格レビューはデスクトップという使い分けが現実的です。

モバイル版Codexは音声入力をサポートしていますか？

既存のChatGPT音声モードを介して利用できます。他のChatGPTメッセージと同じように、Codexへのプロンプトを音声で入力できます。

承認中に通信が切れた場合はどうなりますか？

タスクはクラウド側で実行され続けます。再接続すると状態が更新されます。Codexは、動作継続のためにモバイルセッションを開いたままにする必要はありません。

企業管理者はモバイル版Codexを無効にできますか？

はい。ワークスペースのオーナーは、管理パネルからCodexへのアクセスを制限できます。デスクトップアクセスを制限するのと同じトグルがモバイルにも適用されます。

モバイル版Codexには追加料金がかかりますか？

モバイルアプリ自体に追加料金はかかりません。ただし、利用プランに応じて、基礎となるCodexの計算量に対する料金が発生します。詳細はCodexの料金に関する記事を参照してください。

これは古い「Codex」モデルとは異なりますか？

はい。現在のCodexは、2021年に廃止された旧Codexモデルではなく、コーディングエージェント製品です。2026年時点の製品として理解するには、Codex CLIの紹介記事が参考になります。

今夜試す最小フロー

まずは次の最小ループを試してください。

ChatGPTアプリを更新する
同じOpenAIアカウントでサインインする
Codex用のクラウド環境をリンクする
READMEの1行変更をCodexに依頼する
スマートフォンで差分を確認する
承認する
CIまたはAPIテストの結果を確認する

この流れが動けば、Slack連携やSDKによる自動化を追加する価値があります。

Codexがスマートフォンからデプロイする変更でもAPI契約を保ちたい場合は、Apidogと組み合わせてください。エージェントがコードを書き、テストスイートが回帰を検出する構成にできます。

ERNIE 5.1 API の使い方

Akira — Thu, 14 May 2026 08:34:40 +0000

ERNIE 5.1は2026年5月9日にリリースされ、1週間以内にQianfan APIが公開されました。独自コードからモデルを呼び出す、ツールコールをルーティングする、またはApidogでエージェントループに接続する場合に必要な、アカウント作成、APIキー、リクエストボディ、ストリーミング、ツール使用、エラー処理を実装手順としてまとめます。

今すぐApidogを試す

この記事では実装に必要な部分だけを扱います。最終的に、動作するcurl、Python、Node.jsのサンプルと、Apidogに取り込んで比較検証できるリクエスト構成を作れます。

まだ読んでいない場合は、先にERNIE 5.1の発表詳細を確認してください。DeepSeek V4やKimi K2.6とのベンチマークやトレードオフが整理されています。この記事は、その実装編です。

ステップ1：Qianfan APIキーを取得する

ERNIE 5.1は、Baidu Intelligent CloudのQianfanプラットフォーム経由で提供されます。独立した「ERNIE API」ではなく、API呼び出しはすべてQianfan経由です。

手順は次のとおりです。

cloud.baidu.comにアクセスし、Baidu Intelligent Cloudアカウントを作成またはサインインします。国際開発者はメールで登録できますが、一部のエンタープライズ機能には中国本土の電話番号が必要です。
console.bce.baidu.com/qianfanでQianfanコンソールを開きます。
API Key Management（API Key 管理）で、Create API Keyをクリックします。
ワークスペースを選択し、チャット補完サービスへのアクセスを許可します。
APIキーをコピーします。形式はbce-v3/ALTAK-xxxx/xxxxのようになります。
キーはソースコードに直書きせず、環境変数に保存します。

export QIANFAN_API_KEY="bce-v3/ALTAK-xxxx/xxxx"

実装前に確認すべき点は2つあります。

新しいv2エンドポイントは単一のBearerトークンを使います。古いv1 OAuth access_tokenフローは非推奨なので、新規実装では使わないでください。
ERNIE 5.1はリリース初日から有料モデルです。最初のリクエスト前に少額の残高をチャージしてください。テスト用途なら¥10程度で十分です。

ステップ2：OpenAI互換エンドポイントをcurlで叩く

QianfanはOpenAI互換のチャット補完エンドポイントを提供しています。既存のOpenAI形式のクライアントやラッパーがある場合、多くはベースURLとモデルIDの変更だけで動きます。

ベースURL: https://qianfan.baidubce.com/v2
モデルID: ernie-5.1
早期アクセス機能: ernie-5.1-previewも利用可能

最小構成のリクエストは次のとおりです。

curl https://qianfan.baidubce.com/v2/chat/completions \
  -H "Authorization: Bearer $QIANFAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ernie-5.1",
    "messages": [
      {"role": "system", "content": "You are a senior API designer."},
      {"role": "user", "content": "Sketch a REST schema for a GitHub-style PR review API. Be concise."}
    ],
    "temperature": 0.3
  }'

レスポンスは標準的なOpenAI形式です。

{
  "id": "chatcmpl-...",
  "object": "chat.completion",
  "created": 1746780000,
  "model": "ernie-5.1",
  "choices": [
    {
      "index": 0,
      "message": { "role": "assistant", "content": "..." },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 42,
    "completion_tokens": 318,
    "total_tokens": 360
  }
}

エラー時は、まず次を確認してください。

401 Unauthorized: APIキーが誤っている、または期限切れです。キーを再生成してください。
403: キーは有効ですが、ワークスペースでERNIE 5.1が有効化されていません。Qianfanコンソールでモデル許可を追加してください。

ステップ3：PythonからERNIE 5.1を呼び出す

OpenAI互換エンドポイントなので、公式のopenai Python SDKをそのまま使えます。base_urlをQianfanに向けるだけです。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["QIANFAN_API_KEY"],
    base_url="https://qianfan.baidubce.com/v2",
)

response = client.chat.completions.create(
    model="ernie-5.1",
    messages=[
        {"role": "system", "content": "You explain APIs in plain English."},
        {"role": "user", "content": "Why would I use server-sent events over WebSockets for a chat UI?"},
    ],
    temperature=0.4,
)

print(response.choices[0].message.content)
print(f"\nTokens used: {response.usage.total_tokens}")

既存コードでOpenAI SDKのラッパーを使っている場合、A/Bテスト用にERNIE 5.1へ切り替える変更は最小限で済みます。DeepSeekのAPIや他の多くの中国系モデルプロバイダーでも、同じアプローチが使えます。

ステップ4：チャットUI向けにトークンをストリーミングする

ユーザー向けチャットUIでは、レスポンス全体を待つよりもストリーミング表示が適しています。stream: trueを指定し、Server-Sent Eventsを消費します。

stream = client.chat.completions.create(
    model="ernie-5.1",
    messages=[{"role": "user", "content": "Write a haiku about API versioning."}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

curlでデバッグする場合は、--no-bufferを付けます。

curl https://qianfan.baidubce.com/v2/chat/completions \
  -H "Authorization: Bearer $QIANFAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ernie-5.1",
    "stream": true,
    "messages": [{"role": "user", "content": "Stream a 3-sentence joke."}]
  }' \
  --no-buffer

ストリーム形式はOpenAIと同じです。data: {...}の行が連続し、最後にdata: [DONE]が返ります。

ステップ5：ツールでERNIE 5.1を使う（エージェント機能）

ERNIE 5.1は、τ³-benchとSpreadsheetBench-VerifiedでDeepSeek-V4-Proを上回るスコアを記録しています。つまり、ツール呼び出しはデモ用途だけでなく、本番向けエージェント設計でも検討対象になります。

ツール定義のスキーマはOpenAIの関数呼び出しと同じです。

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get current weather for a city.",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "City name, e.g. Singapore"},
                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]},
                },
                "required": ["city"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="ernie-5.1",
    messages=[{"role": "user", "content": "What's the weather in Tokyo right now?"}],
    tools=tools,
    tool_choice="auto",
)

tool_calls = response.choices[0].message.tool_calls
if tool_calls:
    call = tool_calls[0]
    print(f"Model wants to call: {call.function.name}({call.function.arguments})")

実装時の基本ループは次の流れです。

ユーザー入力とツール定義をモデルに渡す。
tool_callsが返ったら、アプリケーション側で実際のツールを実行する。
実行結果をtoolロールのメッセージとして会話履歴に追加する。
再度モデルを呼び出す。
finish_reason == "stop"かつtool_callsが空なら終了する。

注意点として、ERNIE 5.1はツール引数を常にクリーンなJSON文字列として返すとは限りません。文字列化されたJSONがコードフェンス内に入って返る場合があります。json.loads()はtry/exceptでラップし、失敗した場合は


## ステップ6：Node.jsからERNIE 5.1を呼び出す

`openai` v5+を使っているNode.jsプロジェクトなら、同じように`baseURL`をQianfanへ向けます。

javascript
import OpenAI from "openai";

const client = new OpenAI({
apiKey: process.env.QIANFAN_API_KEY,
baseURL: "https://qianfan.baidubce.com/v2",
});

const completion = await client.chat.completions.create({
model: "ernie-5.1",
messages: [
{ role: "user", content: "Return a JSON object with 3 API design tips." },
],
response_format: { type: "json_object" },
});

console.log(completion.choices[0].message.content);


`response_format: { type: "json_object" }`は利用できます。ただし、厳密なJSONスキーマ指定（`json_schema`）はQianfanでまだ展開中です。スキーマ制約をモデル側に完全に任せず、アプリケーション側でもレスポンス形式を検証してください。

## ステップ7：Apidogでテストと比較を行う

ERNIE 5.1、DeepSeek V4、Kimi K2.6のどれを使うか比較するなら、ターミナルで個別に`curl`するより、[Apidog](https://apidog.com?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)で同じ条件のリクエストを管理する方が再現性を確保しやすくなります。

推奨構成は次のとおりです。

1. Apidogを開き、「LLM bake-off」という新しいプロジェクトを作成します。

<figure class="kg-card kg-image-card"><img src="https://assets.apidog.com/blog-next/2026/05/image-81.png" class="kg-image" alt="" loading="lazy" width="2784" height="1824"></figure>

2. 環境変数として、次を追加します。

text
QIANFAN_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY


<figure class="kg-card kg-image-card"><img src="https://assets.apidog.com/blog-next/2026/05/image-82.png" class="kg-image" alt="" loading="lazy" width="2784" height="1824"></figure>

3. プロバイダーごとにリクエストを作成します。
   - Qianfan: `model`を`ernie-5.1`に設定
   - DeepSeek: `model`を`deepseek-chat`に設定
   - Moonshot/Kimi: `model`を`kimi-k2-6`に設定
4. 3つのリクエストで同じ`messages`配列を使います。
5. Apidogの「Run」機能で並行実行し、出力を比較します。

無料枠でもこの比較は扱いやすいです。[Apidog](https://apidog.com?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)は環境ごとにリクエスト履歴を保存するため、後日同じ評価を新しいモデルバージョンに対して再実行できます。tmuxペインで複数の`curl`を監視するより、比較結果を残しやすくなります。

マルチプロバイダーテストの詳細は、[Test local LLMs as APIs](http://apidog.com/blog/test-local-llms-as-apis?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)と[GLM 5.1 APIガイド](http://apidog.com/blog/how-to-use-glm-5-1-api?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)も参考にしてください。

## 料金、レート制限、クォータ

ERNIE 5.1のQianfan公開料金は、リリース投稿には記載されていません。社内資料や見積もりで数値を使う前に、必ずライブコンソールの料金表を確認してください。

実装時は、少なくとも次の3点を考慮します。

- **デフォルトのレート制限はワークスペース単位です。** 新規アカウントは低いQPS制限から始まります。テスト完了後、本番投入前にコンソールから引き上げを申請してください。
- **トークン使用量はレスポンスに含まれます。** `usage`フィールドに`prompt_tokens`、`completion_tokens`、`total_tokens`が入ります。コスト把握のため、リクエストごとにログへ記録してください。
- **キャッシュは自動ではありません。** Anthropicとは異なり、Qianfanは現時点でERNIE 5.1向けのプロンプトキャッシュプリミティブを公開していません。2,000トークンのシステムプロンプトを毎回送る場合、その分のコストが毎回発生します。

## エラー処理を実装する

実際に遭遇しやすいエラーは次のとおりです。

<table>
<thead>
<tr>
<th>ステータス</th>
<th>意味</th>
<th>解決策</th>
</tr>
</thead>
<tbody>
<tr>
<td>401</td>
<td>Bearerトークンが不正または期限切れ</td>
<td>コンソールから再生成</td>
</tr>
<tr>
<td>403</td>
<td>このワークスペースでモデルが有効になっていない</td>
<td>コンソールでERNIE 5.1を追加</td>
</tr>
<tr>
<td>429</td>
<td>レート制限に達した</td>
<td>バックオフ + ジッター付きリトライ</td>
</tr>
<tr>
<td>400 (<code>invalid messages</code>)</td>
<td>メッセージロールの順序が不正</td>
<td>ユーザー/アシスタントの交互表示を確認</td>
</tr>
<tr>
<td>500/502</td>
<td>Qianfan側の一時的な問題</td>
<td>一度リトライ。継続する場合はステータスページを確認</td>
</tr>
</tbody>
</table>

すべてのAPI呼び出しは、指数バックオフ付きのリトライでラップしてください。上限は3回程度が実用的です。本番環境では、レスポンスヘッダーの`request_id`もログに残してください。Baiduサポートに問い合わせる際、調査に必要になります。

## 最小限の本番向けラッパー

今日ERNIE 5.1をアプリケーションに組み込むなら、まずは次のような薄いラッパーを用意します。

python
import os, time, random, json
from openai import OpenAI, RateLimitError, APIError

client = OpenAI(
api_key=os.environ["QIANFAN_API_KEY"],
base_url="https://qianfan.baidubce.com/v2",
)

def chat(messages, , model="ernie-5.1", temperature=0.3, max_retries=3):
for attempt in range(max_retries):
try:
return client.chat.completions.create(
model=model,
messages=messages,
temperature=temperature,
)
except RateLimitError:
time.sleep((2 * attempt) + random.random())
except APIError as e:
if e.status_code and e.status_code >= 500 and attempt < max_retries - 1:
time.sleep(1 + attempt)
continue
raise
raise RuntimeError("ERNIE 5.1 retries exhausted")




このラッパーで、同期的なチャット補完の多くはカバーできます。ツールループやストリーミングは、この上に追加してください。

## よくある質問

**ERNIE 5.1 APIは無料ですか？**  
いいえ。Qianfanは従量課金制です。永続的な無料枠はありません。新規アカウントには試用クレジットが付与される場合があります。無料で試したい場合は、[ernie.baidu.com](https://ernie.baidu.com)のチャットUI、または[無料LLMの選択肢](http://apidog.com/blog/free-llm-openclaw-web-search?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)を検討してください。

**ERNIE 5.1をローカルで実行できますか？**  
いいえ。公開されている重みはありません。オンプレミス実行が必須の場合は、代わりに[DeepSeek V4をローカルで実行する方法](http://apidog.com/blog/how-to-run-deepseek-v4-locally?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)または[2026年の最高のローカルLLM](http://apidog.com/blog/best-local-llms-2026?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)を参照してください。

**OpenAI SDKは変更なしで動作しますか？**  
はい。`base_url`を`https://qianfan.baidubce.com/v2`に、`api_key`をQianfanキーに設定すれば動作します。ただし、`model`フィールドにはOpenAIのモデルIDではなく、QianfanのモデルIDを指定します。関数呼び出し、ストリーミング、`response_format: json_object`は利用できます。厳密な`json_schema`検証はまだ展開中です。

**ERNIE 5.1は中国語と英語のプロンプトをどのように扱いますか？**  
どちらも第一級の扱いです。Arena Searchスコア1,223は、混合言語の投票者プールから得られました。技術的な英語タスク、たとえばコードやAPI設計ではクローズドな最先端モデルと競合し、中国語のクリエイティブライティングでは中国モデルの中でも最高クラスです。

**最大出力長はどのくらいですか？**  
公式には公開されていません。実運用では、シングルターン応答はモデルが完了するまでに約8Kトークンで上限に達します。長文生成では、タスクを分割して続行する設計にしてください。

ERNIE 5.1でエージェントを構築する場合は、[Apidogをダウンロード](https://apidog.com/download?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)し、OpenAI互換のリクエストコレクションを使って、Qianfanエンドポイントを他のサービスと一緒にモック、テスト、ドキュメント化してください。

<div style="position: relative; width: 100%; padding-top: 56.25%;">
        <iframe src="https://www.youtube.com/embed/UMl4Vo_RwkU?si=NcqL2Sz2ckCxX4iX" title="Apidogで公開APIドキュメントを生成する方法" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;">
        </iframe>
    </div>

ERNIE 5.1とは？百度の新しいMoEモデル

Akira — Thu, 14 May 2026 07:12:55 +0000

Baiduは2026年5月9日にERNIE 5.1をリリースしました。ERNIE 5.1は、ERNIE 5.0の総パラメータの約3分の1のMixture-of-Expertsモデルで、Arena Searchリーダーボードでは世界第4位、中国モデルでは1,223点で1位を獲得しています。

今すぐApidogを試す

このリリースで重要なのは、BaiduがGemini 3.1 ProやDeepSeek-V4-Proに対して、中国語タスクだけでなく、エージェント的なツール使用、長文のクリエイティブライティング、推論能力でも競争する姿勢を明確にした点です。ApidogでLLM APIを比較・検証している開発者にとって、700億パラメータ級のフットプリントなしにエージェントスタックへ組み込める中国発のフロンティアモデルとして、ERNIE 5.1は評価対象に入ります。

この記事では、ERNIE 5.1の概要、アーキテクチャ上の変更点、DeepSeek-V4-ProおよびGemini 3.1 Proとのベンチマーク比較、そして本番環境でDeepSeek V4やKimi K2.6を使っている場合の判断ポイントを整理します。

要約: ERNIE 5.1を1パラグラフで

ERNIE 5.1は、比較可能なフロンティアモデルの事前学習コストの約6%で学習されたテキスト専用MoEモデルです。総パラメータ数はERNIE 5.0の約3分の1、フォワードパスあたりのアクティブパラメータは約半分です。Arena Searchリーダーボードでは1,223点（世界4位、中国1位）を獲得し、τ³-benchおよびSpreadsheetBench-VerifiedのエージェントベンチマークではDeepSeek-V4-Proを上回ったとされています。ツール使用時のAIME26では99.6点を達成しています。アクセス方法はERNIEチャットUI、Baidu AI StudioのERNIE 5.1 Playground、Qianfan APIです。

このリリースが重要な理由

ERNIE 5.1を見るときは、単に「Baiduの新モデル」としてではなく、以下の3点を確認するのが実用的です。

1. 事前学習コスト

Baiduは、ERNIE 5.1の事前学習コストが比較可能なモデルの約6%だとしています。これがQianfan APIの価格に反映される場合、中国クラウド上でLLMを使う開発者にとって、推論コストの比較軸が変わります。

実装前に確認すべき項目は以下です。

入力トークン単価
出力トークン単価
レート制限
同時実行数
エンタープライズ契約時のデータ保持ポリシー

2. 3軸MoEルーティング

Baiduは、ERNIE 5.1が深さ、幅、疎性に対して柔軟にルーティングすると説明しています。

一般的なMoEモデルでは、主に「どのエキスパートを使うか」という幅方向のルーティングが中心です。ERNIE 5.1では、Baiduの説明上、深さと疎性も制御対象に含まれています。

開発者視点では、次の観点で評価してください。

レイテンシが安定しているか
長い会話で品質が落ちにくいか
ツール呼び出し時に不要なステップが増えないか
同じプロンプトで出力のばらつきが許容範囲か

3. エージェント機能が中心

ERNIE 5.0は知識とクリエイティブライティングの印象が強いモデルでした。一方、ERNIE 5.1では「世界トップモデルと同等のエージェント機能」が前面に出ています。

特に確認すべきユースケースは以下です。

検索結果を使った回答生成
関数呼び出し
表計算タスク
コードインタープリタ連携
複数ターンにまたがるツール選択

ベンチマークの比較

Baiduが公開した内容を、近い比較対象と並べると以下のようになります。

ベンチマーク	ERNIE 5.1	テスト内容	比較対象
Arena Search リーダーボード	1,223（世界4位、中国1位）	人間評価による検索対応QA	Gemini 3.1 Pro, GPT-5.x
τ³-bench	DeepSeek-V4-Proを上回る	エージェント的なツール使用、多ターン	DeepSeek-V4-Pro
SpreadsheetBench-Verified	DeepSeek-V4-Proを上回る	実世界の表計算タスク	DeepSeek-V4-Pro
AIME26（ツール使用時）	99.6	コードインタープリタによる競技数学	GPT-5.x, Gemini 3.1 Pro
GPQA	「主要なクローズドソースに匹敵」	大学院レベルの科学QA	Claude Sonnet 4.6
MMLU-Pro	「主要なクローズドソースに匹敵」	幅広い知識	フロンティアモデル全般

注意点もあります。

Arenaのスコアは、プロンプトの構成と評価者プールに依存します。
中国語に偏ったプロンプトが有利に働く可能性があります。
AIME26の99.6点はツール使用時のスコアです。
ツールなしの純粋推論によるAIMEスコアは公開されていません。
クリエイティブライティングでは、Gemini 3.1 Proに「匹敵する」ではなく、「近づいている」という表現にとどまっています。

一方で、τ³-benchとSpreadsheetBench-Verifiedの結果は実装上重要です。どちらもエージェント的な能力を測るベンチマークであり、外部で維持され、単純な知識暗記では対応しにくいからです。

アーキテクチャについて分かっていること

BaiduはDeepSeekがV3シリーズの論文で開示したほど詳細な仕様を出していません。現時点で確認できる内容は以下です。

総パラメータ数: ERNIE 5.0の約3分の1
トークンあたりのアクティブパラメータ数: ERNIE 5.0の約半分
ルーティング: 深さ、幅、疎性に対して柔軟
事前学習コスト: 比較可能なモデルの約6%
モダリティ: リリース時点ではテキストのみ
言語: 中国語版と英語版が利用可能

未公開の重要項目は以下です。

正確な総パラメータ数
コンテキスト長
学習トークン数
推論時の最大出力トークン数
価格体系の詳細

以前にGLM 5.1のような中国発MoEモデルを使ったことがある場合、Qianfan APIでも類似の開発者体験を想定できます。

ERNIE 5.1でまだできないこと

実装前に、制限事項を明確にしておきます。

画像入力は非対応。 ERNIE 5.1はテキスト専用です。画像理解が必要な場合は、ERNIE-VLまたは外部のビジョンモデルを組み合わせる必要があります。
音声入力・出力は非対応。 ネイティブな音声機能やリアルタイム音声APIはありません。
公開されたコンテキストウィンドウは未確認。 長文ドキュメント処理では、チャンク化と要約パイプラインを前提に設計してください。
HuggingFaceの重みはありません。 ホスト型専用モデルです。オンプレミス要件がある場合は、ローカルのDeepSeek V4またはローカルLLMを検討することになります。

ERNIE 5.1と中国のフロンティアモデルの選び方

すでにDeepSeek、Kimi、GLM、Qwenを比較している場合は、以下のように考えると選びやすくなります。

ERNIE 5.1を選ぶべきケース

中国語または英語で強いエージェント的ツール使用が必要
検索強化回答を重視する
中国クラウド上で低コストな推論を期待している
Qianfan APIを既に使っている、または導入できる

DeepSeek V4を選ぶべきケース

オープンウェイトが必要
オンプレミス展開が必要
ツールなしの純粋推論や数学性能を重視する

Kimi K2.6を選ぶべきケース

長いコンテキストウィンドウが必要
大量ドキュメントを一度に扱う
契約書、研究資料、ログ解析など長文ワークロードが中心

GLM 5.1を選ぶべきケース

バランスの取れた汎用モデルが必要
すでにZ.aiまたはZhipuをスタックに組み込んでいる

これは絶対的なランキングではありません。モデル選定では、公開ベンチマークよりも自社ワークロードでの再現性を優先してください。

今すぐERNIE 5.1を試す方法

ERNIE 5.1を試す方法は3つあります。実装に近い順ではなく、摩擦の少ない順に並べると以下です。

1. ernie.baidu.com

一般ユーザー向けのチャットUIです。

向いている用途:

クリエイティブライティングの確認
中国語QAの品質確認
推論傾向の把握
回答スタイルの確認

APIキーは不要です。ただし、本番導入判断にはAPIでの評価が必要です。

2. Baidu AI Studio ERNIE 5.1 Playground

Baidu AI Studioには、ERNIE 5.1向けのPlaygroundが用意されています。

向いている用途:

ツール呼び出しの確認
プロンプト調整
エージェント挙動の観察
API実装前のPoC

まずPlaygroundでプロンプトを固め、その後Qianfan APIへ移すのが効率的です。

3. Qianfan API

本番実装ではQianfan APIを使います。

特徴:

開発者向けエンドポイント
Bearerトークン認証
OpenAI互換に近いリクエスト形式
API経由でアプリケーションに統合可能

詳細な手順は、関連ガイドERNIE 5.1 APIの使用方法で解説されています。

複数の中国モデルプロバイダーを比較している場合、Apidogを使うと、APIキー、リクエストボディ、環境変数、レスポンス比較を1つのワークスペースで管理できます。

ApidogでERNIE 5.1を評価する基本フロー

ERNIE 5.1を検証する場合は、単発のcurlではなく、再利用できるAPIコレクションとして管理するのがおすすめです。

1. 環境変数を作る

例:

QIANFAN_API_KEY=your_api_key
QIANFAN_BASE_URL=https://your-qianfan-endpoint
MODEL=ernie-5.1

2. 共通ヘッダーを設定する

Authorization: Bearer {{QIANFAN_API_KEY}}
Content-Type: application/json

3. 評価用リクエストを作る

以下のようなケースを分けて保存します。

通常QA
検索結果を含むQA
関数呼び出し
表計算タスク
数学・推論
長文要約
JSON出力

4. JSON出力を固定する

アプリケーションで使う場合は、自然文ではなく構造化出力を評価してください。

例:

{
  "task": "次の問い合わせを分類してください",
  "input": "請求書APIのレスポンスが500になります",
  "output_schema": {
    "category": "billing | api_error | account | other",
    "priority": "low | medium | high",
    "summary": "string"
  }
}

確認すべき点:

JSONが壊れないか
enum以外の値を返さないか
不明な場合に推測しすぎないか
日本語・中国語・英語で同じ形式を維持できるか

5. 既存モデルと並べて比較する

ERNIE 5.1だけを評価しても意味がありません。現在使っているモデルと同じプロンプトで比較してください。

最低限見るべき指標:

正答率
ツール選択の正確性
レイテンシ
トークン使用量
JSON整合性
再試行率
人手修正の必要回数

価格と展開

Baiduは、ERNIE 5.1がリリース後数週間のうちに10以上のクリエイティブ制作プラットフォームへ展開されると発表しています。

Qianfanでのトークン単価はリリース投稿には記載されていません。Baiduは事前学習コストが約6%だと説明していますが、それがそのままAPI価格になるとは限りません。

導入前に必ず確認してください。

Qianfanコンソール上の最新価格
無料枠の有無
入出力トークン別の単価
キャッシュやバッチ処理の有無
SLA
データ保持設定
エンタープライズ契約の条件

社内向けにコスト試算を出す場合は、公開記事の数字ではなく、Qianfanコンソールの最新価格を基準にしてください。

開発者向けの導入判断

ERNIE 5.1を本番スタックに入れるか判断するなら、次の3ステップで進めるのが現実的です。

1. 自社タスクで20〜50件の評価セットを作る

公開ベンチマークは参考になりますが、あなたのワークロードそのものではありません。

評価セットには、実際に失敗しやすいケースを入れてください。

曖昧な問い合わせ
不完全な入力
長い文脈
ツール呼び出しが必要なケース
JSON形式を厳守するケース
誤回答が重大な影響を持つケース

APIとしてのLLMテストでは、Apidogを使った評価方法が解説されています。

2. 中国クラウド利用の可否を確認する

Qianfanは中国でホストされています。データレジデンシー要件で中国インフラが使えない場合、ベンチマークが良くても採用は難しくなります。

確認すべき項目:

個人情報を送信できるか
ログ保持ポリシー
データの保存場所
社内セキュリティレビュー
顧客契約上の制限

3. 価格発表を待ってから本番コストを見積もる

ERNIE 5.1で最も注目すべき数字は、事前学習コストが約6%という点です。ただし、API価格がどうなるかは別問題です。

本番導入前には、以下を使って見積もってください。

月間コスト =
  月間入力トークン数 × 入力単価
+ 月間出力トークン数 × 出力単価
+ 再試行分の追加コスト
+ 評価・監視用リクエストのコスト

エージェント用途では、ツール呼び出しや再試行によってトークン数が増えやすい点にも注意が必要です。

よくある質問

ERNIE 5.1はオープンソースですか？

いいえ。ERNIE 5.1は、BaiduのチャットUI、Baidu AI Studio、Qianfan APIを通じて利用するホスト型専用モデルです。執筆時点では、HuggingFaceに公開されている重みはありません。

ERNIE 5.1は画像入力をサポートしていますか？

いいえ。ERNIE 5.1はリリース時点ではテキスト専用です。Baiduの視覚タスクにはERNIE-VLファミリーを使う必要があります。単一のマルチモーダル中国モデルが必要な場合は、Qwen 3.5 Omniを検討してください。

コンテキスト長はどのくらいですか？

Baiduはリリース投稿で具体的なコンテキストウィンドウの数値を公開していません。確認されるまでは、長文ドキュメントを直接投入するのではなく、チャンク化、検索、要約を組み合わせて設計してください。

中国外からERNIE 5.1を使えますか？

チャットUIとQianfan APIは多くの地域からアクセス可能ですが、レイテンシ、アカウント認証、エンタープライズ機能の条件は異なります。一部の機能では、中国本土の電話番号または事業許可が必要になる場合があります。アクセス手順はERNIE 5.1 APIの使用方法で詳しく説明されています。

ERNIE 5.1はDeepSeek-V4-Proより優れていますか？

τ³-benchとSpreadsheetBench-Verifiedでは、BaiduはERNIE 5.1がDeepSeek-V4-Proを上回るとしています。一方、オープンウェイトやオンプレミス展開ではDeepSeek側に利点があります。ツールを使わない純粋な数学推論では、公開情報だけでは明確な結論は出せません。

まとめ

ERNIE 5.1は、Baiduがエージェント用途を明確に意識して投入したテキスト専用MoEモデルです。特に、ツール使用、検索強化回答、表計算タスク、中国語・英語の実用ワークロードで評価する価値があります。

導入前にやるべきことはシンプルです。

Qianfan APIでアクセスできるか確認する
自社タスクの評価セットを20〜50件作る
既存モデルと同じプロンプトで比較する
JSON整合性、ツール選択、レイテンシ、コストを測る
データレジデンシーと価格条件を確認する

開発を始める準備ができたら、ApidogでQianfan APIのリクエストを管理し、ERNIE 5.1を現在のモデルと並行して同じワークスペースでテストしてください。

Apidog Spec-First モード体験：ビジュアルデザイナーだけではない開発の進化

Akira — Thu, 14 May 2026 07:04:54 +0000

私がこれまで関わってきたAPIチームには、だいたい2つの運用パターンがありました。

今すぐApidogを試す

1つ目は、OpenAPI仕様を手で書き、specs/ ディレクトリにコミットし、Gitを唯一の信頼できる情報源として扱うチームです。2つ目は、ビジュアルデザイナーで仕様を作り、CIで問題が出たタイミングで仕様をエクスポートし、UI上の定義とリポジトリ上の定義の差分を後から修正するチームです。

どちらの運用も経験しました。前者は初動が遅い一方で、90日後には速くなります。後者はその逆です。Apidogは長く後者寄りのツールでした。ビジュアルデザイナーは使いやすいものの、YAMLとの往復変換はコードレビューで説明が必要な運用になりがちでした。

しかし4月中旬、新規プロジェクト作成画面にスペックファーストモード（ベータ）が追加されました。ローンチ直後ではなく、実際のサイドプロジェクトのOpenAPI仕様で半日ほど試してから判断しました。この記事では、チームで導入する前に確認すべきポイント、セットアップ手順、向いているケースと向いていないケースを整理します。

スペックファーストモードで変わること

Apidogには現在、性質の異なる2つのプロジェクトモードがあります。

デフォルトの一般モードでは、「+ 新規プロジェクト」からプロジェクトを作成し、フォルダーとフォームベースのUIでエンドポイントを定義します。OpenAPI仕様は内部的に生成されます。YAMLに慣れていないチームや、非エンジニアもAPI定義に関わるチームには引き続き有効です。

一方、スペックファーストモードでは、中心になるのはフォームではなく、実際の .yaml / .json ファイルです。Gitリポジトリとの双方向同期があり、OpenAPI仕様そのものをディスク上のファイルとして扱います。

主な違いは次の通りです。

.yaml / .json を直接編集する
OpenAPIスキーマに基づく補完が使える
構文ハイライトがある
入力中にパス一覧がサイドバーへ反映される
Gitリポジトリと双方向同期できる
UIは仕様ファイルのラッパーではなく、仕様ファイルを見るためのビューになる

特に重要なのは、リアルタイムのアウトライン表示です。YAMLの問題は「難しい」ことよりも、構造が長いファイルの中に埋もれやすいことです。Apidogのスペックファーストモードでは、ファイルを直接編集しながら、左側のアウトラインでエンドポイントを移動できます。

スペックファースト開発の本質は、テキストエディタが好きかどうかではありません。成果物をどこで管理するかです。スペックファーストモードでは、リポジトリ内のOpenAPIファイルが成果物になります。ApidogのUIは、そのファイルを編集・確認するための作業環境です。

セットアップ手順

実際に試したセットアップ手順は次の通りです。Git認証を含めても、10分程度で完了しました。

1. スペックファーストモードでプロジェクトを作成する

プロジェクト画面から、次の順に進みます。

+ 新規プロジェクト
→ 一般
→ スペックファーストモード

注意点として、一般モードには「推奨」ラベルが付いています。普段どおりにプロジェクトを作ると、スペックファーストモードのタイルを見落としやすいです。OpenAPIファイルをGit中心で管理したい場合は、必ずスペックファーストモードを選びます。

2. Gitリポジトリに接続する

次に、Gitリポジトリと接続 セクションでGitプロバイダーを認証します。

設定する項目は次の3つです。

Organization
Repository
Main branch

私はGitHubで試しました。選択したブランチ内の .yaml / .json ファイルが、Apidog側の作業対象として同期されます。

3. プロジェクト名と権限を設定する

続いて、次を設定します。

Project Name
Team permissions

作成すると、初回同期が走り、リポジトリ内のOpenAPI仕様ファイルがApidogのワークスペースに取り込まれます。

4. OpenAPI仕様をファイルとして編集する

同期後、任意のYAMLファイルを開きます。ここでは、フォームではなく実ファイルを編集します。

たとえば、次のようなOpenAPI定義をそのまま編集できます。

openapi: 3.0.3
info:
  title: Pet Store API
  version: 1.0.0

paths:
  /pets:
    get:
      summary: List pets
      responses:
        '200':
          description: A list of pets

編集中は、OpenAPIスキーマに基づく補完が効きます。さらに、paths に追加したエンドポイントはサイドバーのアウトラインに反映されます。アウトライン上のエンドポイントをクリックすると、該当する行へ移動できます。

VS CodeでOpenAPI拡張を使っている人には近い操作感ですが、Apidogではエンドポイント一覧や同期状態も同じ画面で確認できます。

5. 変更をコミットしてプッシュする

変更後は、右上の Commit & Push をクリックします。

ダイアログには次の要素があります。

変更されたファイル一覧
コミットメッセージ入力欄
Push
Discard all changes
Cancel

個別にステージングするステップはありません。変更一覧に含まれるものがコミット対象になります。仕様ファイル中心の編集であれば、この簡略化は十分実用的です。

6. 同期インジケーターを確認する

左下に同期状態が表示されます。

図では Synced just now と表示されています。これは、Apidog上の編集内容とリモートリポジトリの状態が一致していることを示します。

実運用では、次のように確認するとわかりやすいです。

Synced just now     → 同期済み
Changes available   → リモート側に変更あり
Changes pending     → ローカル側に未プッシュ変更あり

インジケーターが緑であれば、Apidogとリポジトリは一致しています。複数人で編集する場合は、この表示を常に確認するのがよさそうです。

使ってわかった実装上のポイント

半日使って、特に重要だと感じた点は3つあります。

1. アウトラインの更新が速い

過去に使ったライブOpenAPIエディタの多くは、保存時に再解析する仕組みでした。そのため、エンドポイントを追加してからサイドバーに表示されるまでに遅延がありました。

Apidogのスペックファーストモードでは、入力中にアウトラインが更新されます。ほぼ即時に反映されるため、アウトラインを「確認用」ではなく「ナビゲーション用」として使えます。

長いOpenAPIファイルを扱う場合、この差は大きいです。

2. Git同期は実際に双方向で動く

Apidogを開いたまま、ローカルクローン側で同じ仕様ファイルを編集し、ターミナルからプッシュしてみました。

git add openapi.yaml
git commit -m "Update pet schema"
git push origin main

Apidog側ではリモート変更が検知され、同期インジケーターが変化しました。その後、ワンクリックで変更をエディターに取り込めました。

つまり、チーム内で次のような混在運用ができます。

一部のメンバーはApidogで編集する
一部のメンバーはVS CodeやVimで編集する
どちらも同じGitリポジトリ上のOpenAPIファイルを編集する

重要なのは、Apidog内の状態とGit内の状態を別々に管理しなくてよいことです。

3. 同じプロジェクト内で一般モードには戻れない

スペックファーストモードで作成したプロジェクトは、スペックファースト用のプロジェクトになります。途中で一般モードのビジュアルデザイナーへ切り替えることはできません。

これは、内部のデータモデルが異なるためです。

もし同じ仕様を両方の操作方法で扱いたい場合は、次のような運用になります。

Gitリポジトリ
├── OpenAPI仕様ファイル
│
├── Apidog スペックファーストプロジェクト
│   └── Git同期で編集
│
└── Apidog 一般モードプロジェクト
    └── 同じ仕様からインポート

完全にシームレスではありませんが、Git上の仕様を中心に据えれば運用は可能です。

向いているチーム

スペックファーストモードが特に向いているのは、次のようなチームです。

OpenAPI仕様をすでに手書きしている
OpenAPI仕様をGitでレビューしたい
spectral lint などをCIで実行している
仕様からSDKや型定義を生成している
Pull Request上でAPI変更をレビューしたい
Apidog上の仕様とリポジトリ上の仕様のズレをなくしたい
エンジニアがVS CodeやVimでも編集できる状態を保ちたい

たとえば、CIで次のようなチェックをしている場合には相性がよいです。

name: OpenAPI Lint

on:
  pull_request:
    paths:
      - "specs/**/*.yaml"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @stoplight/spectral-cli
      - run: spectral lint specs/openapi.yaml

この場合、Apidogで編集した仕様も通常のGitフローに乗ります。レビュー、CI、生成処理をすべて同じファイルに対して実行できます。

向いていないチーム

一方で、次のようなチームには一般モードのほうが向いています。

OpenAPIをほとんど書いたことがない
YAMLを直接編集するメンバーが少ない
非エンジニアがフォームUIでAPI定義を作る必要がある
ビジュアルデザイナーが参加の前提になっている
同じプロジェクト内でフォーム編集とファイル編集を切り替えたい

スペックファーストモードは、オンボーディングの簡単さよりも、仕様ファイルの忠実性を優先するモードです。APIスペシャリスト以外のメンバーが多いチームでは、一般モードのほうが導入しやすいです。

また、同じプロジェクト内で一般モードとスペックファーストモードを混在させたい場合も、現時点では向いていません。この点はベータ版らしい制約です。

導入する場合のおすすめワークフロー

チームで試すなら、いきなり全APIを移行するより、1つの仕様ファイルから始めるのが安全です。

おすすめの流れは次の通りです。

1. 既存のOpenAPI仕様をGitに置く
2. CIでlintを設定する
3. Apidogでスペックファーストプロジェクトを作成する
4. Gitリポジトリを接続する
5. 小さなエンドポイント変更をApidog上で行う
6. Commit & Pushする
7. Pull RequestとCIで差分を確認する
8. チームメンバーに編集手順を共有する

最初に確認すべき観点は次の3つです。

Apidog上の編集差分が期待通りGitに出るか
CIのOpenAPI lintが通るか
ローカルエディタで編集した変更をApidogが取り込めるか

この3点が問題なければ、日常的な仕様編集には十分使えます。

まとめ

これまでスペックファースト開発は、APIデザインツールを諦めることとほぼ同義でした。YAMLで作業してGitを信頼する代わりに、モックサーバーやテストランナーとの統合を諦める。あるいは、ビジュアルデザイナーを使う代わりに、Gitを唯一の情報源にすることを諦める。そのどちらかでした。

Apidogのスペックファーストモードでは、この分断がかなり小さくなっています。

リポジトリ内のファイルが、エディター内のファイルです。アウトラインは状態ではなくビューです。Git同期はエクスポート機能ではなく、作業フローの一部です。

新規プロジェクト作成時にスペックファーストモードを選び、既存のGitリポジトリを接続すれば、最初のコミットまでは10分程度で到達できます。継続利用するかどうかは、1週間ほど実際のAPI変更で試せば判断できます。

ClaudeプランでClaude Agent SDKを使う方法

Akira — Thu, 14 May 2026 03:55:55 +0000

Anthropicは、2026年6月15日より、既存のClaudeサブスクリプションでClaude Agent SDKを実行できるようにします。これまでAgent SDKで何かを構築するには、Claude ProやMaxとは別に、従量課金制のAPIキーが必要でした。6月15日以降は、毎月のClaudeプランにAgent SDK専用のクレジット残高が含まれます。APIキーは不要です。

今すぐApidogを試す

デプロイボット、リサーチアシスタント、トリアージツールなどのカスタムエージェントを試したいが、プロトタイプのためだけにAnthropicへ別の請求カードを登録したくなかった場合、この変更は実装のハードルを下げます。Proサブスクリプションには月額20ドルのAgent SDK使用クレジット、Max 20xには200ドル、Team Premiumシートには100ドルが含まれます。

2026年6月15日に何が変わったのか

Agent SDKの利用料は、Claudeプランに紐づいた月額クレジットから消費されるようになりました。以前は、Anthropic API経由で別途コンソール残高に請求されていました。

Anthropicの発表に基づくプラン別クレジットは次のとおりです。

プラン	月額Agent SDKクレジット
Pro	20ドル
Max 5x	100ドル
Max 20x	200ドル
チームスタンダード（1シートあたり）	20ドル
チームプレミアム（1シートあたり）	100ドル
エンタープライズ（使用量ベース）	20ドル
エンタープライズプレミアムシート	200ドル

実装前に確認すべきルールは以下です。

エンタープライズスタンダードシートのメンバーはクレジットを受け取れません。 APIキーを使用するか、プレミアムシートにアップグレードする必要があります。
クレジットはユーザーごとに付与され、譲渡できません。 自分のシートのクレジットをチームメイトと共有することはできません。
未使用クレジットは繰り越されません。 請求サイクルの終わりに残った分はリセットされます。
1回限りのオプトインが必要です。 クレジットは申請するまでアカウントで有効になりません。申請後は毎月自動更新されます。
APIキーユーザーはこのクレジットを受け取りません。 ANTHROPIC_API_KEYで認証している場合は、従来のAPI請求モデルのままです。

クレジットでカバーされるもの

Agent SDKクレジットでカバーされるのは、プログラムによる自動化・非対話型ワークロードです。

対象になるもの：

PythonまたはTypeScriptプロジェクトからのClaude Agent SDK呼び出し
Claude Codeのclaude -pコマンド非対話モードで、スクリプト化されたエージェント実行に使います。
Claude CodeのGitHub Actions連携
Agent SDKで認証するサードパーティアプリケーション

対象外のもの：

対話型のClaude Codeセッション
Claudeウェブアプリまたはモバイルアプリでの会話
Claude Coworkセッション

通常のClaude Code作業は、プランの既存の利用制限の範囲内です。Anthropicはこの制限を最近7月13日まで50%引き上げました。

つまり、次の2つは別の予算として扱われます。

日常的な対話型Claude Code利用
Agent SDKやclaude -pによる自動化

この分離により、通常のコーディング用のClaude Code利用枠を消費せずに、SDKベースのカスタムエージェントを試せます。

クレジットがなくなった場合

クレジットを使い切った後の挙動は、追加使用の設定で決まります。

追加使用を有効にする

超過分は、プランの支払い方法に対して標準APIレートで従量課金されます。
追加使用を無効にする

請求サイクルがリセットされるまで、リクエストはクレジット上限で停止します。

プロトタイプでは、追加使用を無効にしておくのが安全です。予期しない請求を避けられます。

本番環境の自動化で停止が許容できない場合は、追加使用を有効にします。いずれの場合も、クレジットが先に消費され、上限を超えるまで超過料金は発生しません。

オプトインの方法

クレジットはデフォルトでは有効になっていません。最初に1回だけ申請が必要です。

手順：

サブスクリプションを所有するClaudeアカウントにログインします。

Pro/Maxの個人アカウント、またはTeam/Enterpriseのシートアカウントです。
Claude Agent SDKのプラン設定ページにアクセスします。

Anthropicの公式サポート記事からリンクされています。
クレジットを申請します。

申請後は、毎月自動的に更新されます。

チームプランの場合、各ユーザーが個別に申請する必要があります。管理者がシートメンバーの代わりに申請することはできません。

PythonでAgent SDKを設定する

Agent SDKはPythonとTypeScriptで利用できます。どちらも、生のAPIキーではなくClaude Code CLI経由でプランに対して認証します。

Python版をインストールします。

pip install claude-agent-sdk

Claude Codeにログインします。

claude login

これにより、プランに紐づいた認証情報がローカルに保存されます。Python SDKはそれを自動的に取得します。プランベースの使用では、ANTHROPIC_API_KEYを設定する必要はありません。

最小構成のエージェントは次のようになります。

from claude_agent_sdk import Agent

agent = Agent(
    system_prompt="You are a code review assistant.",
)

response = agent.run("Review the diff in /tmp/patch.diff and flag concerns.")
print(response.text)

以前は、この呼び出しにANTHROPIC_API_KEYと従量課金制のAPI請求が必要でした。現在は、プランのAgent SDKクレジットから消費されます。

TypeScriptでAgent SDKを設定する

TypeScript版をインストールします。

npm install @anthropic-ai/claude-agent-sdk

Claude Codeにログインします。

claude login

最小構成のエージェントは次のとおりです。

import { Agent } from "@anthropic-ai/claude-agent-sdk";

const agent = new Agent({
  systemPrompt: "You are a code review assistant.",
});

const response = await agent.run(
  "Review the diff in /tmp/patch.diff and flag concerns."
);

console.log(response.text);

CIランナー、Dockerコンテナ、リモート開発環境など、SDKがClaude Codeの認証情報を自動検出できない環境では、認証情報を環境変数として設定できます。正確な変数名はAnthropicのAgent SDKドキュメントを確認してください。

SDKの前段でClaude Codeログインに失敗する場合は、無効なcustom3pエンタープライズ設定の修正を確認すると、よくある原因を切り分けられます。

`claude -p`を自動化に組み込む

Agent SDKクレジットを使うもう1つの方法が、Claude Codeのclaude -pです。

-pはClaude Codeを非対話モードにします。プロンプトを渡すと、リポジトリに対して実行して終了します。対話セッションはありません。

用途は次のような自動化です。

CIパイプライン
cronジョブ
Gitフック
リリース前チェック
差分レビュー

例：危険な変更を検出するプリコミットフック。

#!/usr/bin/env bash
# .git/hooks/pre-commit

DIFF=$(git diff --cached)

claude -p "Review this diff for security issues, secret leaks, and breaking changes. Return PASS or FAIL with reasoning:\n\n$DIFF"

6月15日以降、claude -pの呼び出しは対話型Claude Codeの予算ではなく、Agent SDKクレジットから消費されます。日常的なClaude Code利用枠を消費せずに、自動化ワークフローへ組み込めます。

この使い方は、自律的なループのための/goalコマンドや、実行間でエージェントを安定して制御するためのAGENTS.mdコンテキストファイルと相性が良いです。

GitHub Actions連携で使う

Claude CodeのGitHub Actions連携も、SDKクレジットでカバーされます。

たとえば、次のようなワークフローにClaudeを組み込んでいる場合です。

PRレビュー
Issueトリアージ
リリースノート生成
変更内容の要約

これらのワークフロー実行は、GitHub AppをインストールしたユーザーのAgent SDKクレジットに対して請求されるようになりました。

これは、Claude Code上に構築されたGitHubトリアージボットであるClawsweeperのようなプロジェクトで特に有用です。継続的に実行される自動化で、以前はAppにアタッチされたAPIキーに請求されていたためです。

実用的なエージェントを構築する：SDKとApidogを組み合わせる

Agent SDKの価値は、単にテキストを返すことではありません。実際のAPIを呼び出し、データベースをクエリし、デプロイや検証を実行するエージェントを作れる点にあります。

ただし、エージェントが外部APIを扱う場合は、API契約が必要です。契約がないと、エージェントはリクエスト形式を推測し、デバッグの多くが誤ったペイロードの修正に費やされます。

ここでApidogを使います。

実装フローは次のとおりです。

ApidogでAPI契約を定義する

エンドポイント、リクエストスキーマ、レスポンススキーマ、サンプルペイロードを仕様化します。
OpenAPIをエクスポートする

エージェントにコンテキストとして渡せる形式にします。
Agent SDKで実エンドポイントへ接続する

エージェントは、正しいスキーマを前提にAPIを呼び出します。
Apidog CLIで検証する

エージェント実行ごとに、APIが契約どおりに応答するか確認します。

MCPサーバー経由で他のツールをオーケストレートするエージェントでは、Apidogを使用したMCPサーバーテストワークフローが参考になります。エージェントが呼び出すツールに対して、エンドツーエンドのテストカバレッジを作れます。

全体の設計は、デザインファーストのAPIワークフローガイドで整理されています。エージェントが検証すべき契約を持っていれば、開発者はJSONスキーマのバグを追うのではなく、より良い契約と制約を書くことに集中できます。

Agent SDKプロジェクトの契約層が必要な場合は、無料でApidogをダウンロードできます。

それでも別のAPIキーが必要な場合

プランベースのクレジットは、多くの開発者にとって適切なデフォルトです。ただし、スタンドアロンのAPIキーが適しているケースもあります。

予測可能な予算管理が必要な本番環境エージェント

プランクレジットは固定額で上限があります。無制限にスケールするエージェントでは、使用量ベースのAPIキーのほうが、財務・運用チームにとって請求ラインを分けやすくなります。
複数組織での共有アクセス

APIキーは単一ユーザーに紐づきません。チームが単一の請求元を共有したい場合は、APIキーが適しています。
エンタープライズスタンダードシート

エンタープライズスタンダードシートにはAgent SDKクレジットが付与されません。SDKアクセスが必要な場合はAPIキーを使います。

無料のClaude APIアクセスガイドでは、Proプランや有料APIキーを使わずにClaudeを利用する方法を扱っています。

開始前チェックリスト

実装前に、次を確認してください。

[ ] 自分のプランが対象に含まれている Pro、Max 5x、Max 20x、チームスタンダード、チームプレミアム、エンタープライズ使用量ベース、エンタープライズプレミアムシート
[ ] Agent SDKクレジットの1回限りのオプトインを申請した
[ ] 追加使用を有効にするか決めたプロトタイプではオフ、本番環境ではオンが基本
[ ] claude loginを実行して、SDKをプランに対して認証した
[ ] PythonまたはTypeScriptのSDKパッケージをインストールした
[ ] 最小構成のエージェントを実行した
[ ] ANTHROPIC_API_KEYなしで動作することを確認した
[ ] 最初の数回の実行後に、アカウント設定でクレジット残高を確認した

よくある質問

プランクレジットを使うために、古いANTHROPIC_API_KEYを削除する必要がありますか？

SDKはClaude Codeのローカル認証情報が存在する場合、それを使用します。claude loginを実行すれば、SDKはプランベースの請求に切り替わります。他のツール用にANTHROPIC_API_KEYを環境変数として設定している場合は、そのままでも構いません。SDKはプラン認証が存在する場合、そちらを優先します。

クレジットに対する1つの「リクエスト」とは何ですか？

クレジットはリクエスト数ではなくドル建てです。各SDK呼び出しは、Anthropicが公開しているAPI使用料と同じレートで請求されます。ツール使用やコンテキストトークンを含むモデル呼び出しのコストに応じて、クレジット残高が減っていきます。追加のリクエスト単位料金はありません。

チームメイトとクレジットを共有できますか？

できません。クレジットはユーザーごとに付与され、譲渡できません。各チームまたはエンタープライズシートには、それぞれ独自のクレジットプールがあります。

古いAnthropic APIコンソールの残高はどうなりますか？

そのまま残ります。プランクレジットは別の請求メカニズムです。APIコンソールに前払い残高がある場合、それは引き続きAPIキーを使うワークロードに適用されます。

Agent SDKはClaude Codeと同じですか？

違います。Claude CodeはAnthropicが提供する公式CLIおよびIDE拡張機能です。Agent SDKは、カスタムエージェントを構築するためのPython/TypeScriptライブラリです。

クレジットは、Agent SDKとClaude Codeの非対話型claude -pコマンドをカバーします。対話型Claude Codeは通常のプラン利用のままです。

GitHub Actionsの請求は変わりますか？

Actionが公式のClaude Code GitHub Actions連携を使用し、クレジットがインストールユーザーのアカウントで申請されている場合、それらの実行はAPIキー請求ではなくSDKクレジットから消費されます。

クレジットはAgent SDKやclaude -p以外でも使えますか？

対象は次の4つです。

Python/TypeScriptのAgent SDK
claude -p
Claude Code GitHub Actions連携
Agent SDKを使用するサードパーティアプリ

それ以外のClaude利用は、リクエストの発生元に応じて、通常のプラン制限またはAPIキー請求にフォールバックされます。