Agent MCP tools API 運用

Agent ツールルーティング: MCP、プロバイダー選択、ポリシー

Agent ツールルーティング: MCP、プロバイダー選択、ポリシーの実践ガイド。MCP tools、provider choice、gateway policy、本番判断、結果確認を扱います。

AveMujica API 2026年6月22日 2 分で読めます

エージェントツールルーティングは、エージェントが行う各ツール呼び出しをどのモデルプロバイダーが処理し、その呼び出しが許可されるかどうかを決定する層です。うまく実装すれば、フェイルオーバー、コスト管理、監査証跡が得られます。下手に実装すると、新しい MCP サーバーや関数呼び出しごとに、また別の統制されない API 出口が生まれます。

エージェントが実際にルーティングするもの

最近のエージェントフレームワークの多くは、モデルが呼び出せる関数としてツールを公開しています。LLM がツール呼び出しを出力すると、ランタイムは 3 つのことを解決しなければなりません。ツールの identity、引数、そしてそれを実行できる下流プロバイダーです。最後のステップが、ルーティングが存在する場所です。

ツールは大きく 3 つのカテゴリーに分けられます。

ローカルツール：ファイル読み込み、ベクトル検索、社内 API など、自分のランタイム内で実行されるもの。
MCP ツール：Model Context Protocol を話す外部サーバー上で動くもの。エージェントは MCP クライアントを通じてそれらを発見し、リクエストを送信して結果を待ちます。
モデル駆動ツール：要約、分類、プロバイダーに戻るコード生成など、追加ステップを伴う入れ子の LLM 呼び出しです。

ゲートウェイは、エージェントと 2 番目・3 番目のカテゴリーの間に位置します。それは単なるプロキシではなく、ポリシー適用ポイントです。そのため、agent tool routing MCP gateway の考え方は、プロトコルではなくポリシーから始まります。

MCP がトポロジーを変える

MCP サーバーは、単一のエージェントを多くの外部機能のクライアントに変えます。コーディングエージェントは、ファイルシステムアクセス用の MCP サーバー、Web 検索用の別サーバー、データベース用のさらに別のサーバーを呼び出すかもしれません。各呼び出しは、あなたの境界を出て、そこから戻ってきます。

プロトコル自体は単純です。stdio または HTTP(SSE) 上の JSON-RPC メッセージです。Model Context Protocol ロードマップは急速に進化しており、サーバー発見はまだ定まりつつありますが、セキュリティモデルはすでに明確です。あらゆるエージェントに、自分の MCP サーバー、自分の認証情報、自分のモデルプロバイダーを選ばせるわけにはいきません。

3 つのリスクがすぐに現れます。

シャドウスペンド。 上限のないモデル駆動ツールを呼び出すエージェントは、人間を介さずにクォータを使い切る可能性があります。
データ漏洩。 外部プロバイダーを呼び出すツールは、あなたがネットワークから出すつもりのなかったコンテキストを転送するかもしれません。
監査の欠落。 ツール呼び出しがエージェントループ内で発生すると、アプリケーションログがリクエスト、レスポンス、コストを捉えられないかもしれません。

ゲートウェイを使えば、すべてのモデル駆動呼び出しを検査、レート制限、ログ記録できる唯一の場所が得られます。

ツール呼び出しにとってプロバイダー選択が重要な理由

すべてのツール呼び出しが同じモデルを必要とするわけではありません。短いプロンプトから構造化フィールドを抽出するツールには、推論旗艦モデルは不要です。一方、顧客向けコピーを書き直すツールには必要かもしれません。能力と価格でルーティングすることで、レイテンシを抑え、支出を予測可能にします。

プロバイダー選択は、いくつかの具体的な判断に分解できます。

判断	問うべきこと	典型的なルーティングルール
能力の適合	このツールに推論、JSON モード、ビジョン、長いコンテキストが必要か？	コードツールは、指示追従と JSON 出力に強いモデルへルーティングする。
レイテンシ予算	この呼び出しはユーザー要求のクリティカルパス上にあるか？	同期ツール呼び出しには高速・低コストモデルを使い、重い処理は後回しにする。
コスト上限	タスクごと・ユーザーごとの支出上限は？	呼び出しあたりのトークン数を制限し、可能なら低コストプロバイダーにフォールバックする。
データレジデンシー	このプロンプトがリージョンやプロバイダーから出てもよいか？	規制対象ワークロードは、特定のプロバイダーまたはセルフホストエンドポイントに固定する。
フォールバックチェーン	一次プロバイダーがダウンしたらどうするか？	プロバイダー内でリトライし、次に互換性のある出力を持つ二次プロバイダーにオーバーフローする。

AveMujica API の /channels ページには、これらのルールに含められるアップストリームプロバイダーが一覧表示されます。/model-list ページには、関数呼び出し、ビジョン、構造化出力など、各ツールに必要な機能をサポートするモデルが表示されます。

最終確認日：2026-06-22。プロバイダーの能力と価格は急速に変化します。ルーティングルールを本番に固定する前に、現在の OpenAI API リファレンス、Anthropic API ドキュメント、または Google Gemini API ドキュメントでモデル機能を確認してください。

すべてのエージェント呼び出しが通るべきポリシーゲート

ルーティング判断は、それを適用するポリシーと同じくらい優れているものです。少なくとも、すべてのエージェントツール呼び出しは以下のゲートを通過すべきです。

認証。 そのエージェントまたはユーザーに、このツールを呼び出す権限があるか？
レート制限。 ユーザーごと、ツールごと、プロバイダーごとの制限により、暴走ループを防ぐ。
支出ガードレール。 呼び出しごとの最大コストまたはトークン予算。ブロックやダウングレードも可能にする。
出力検証。 返された JSON はエージェントが期待するスキーマに一致するか？壊れたツールレスポンスは、エージェントループの残りを破壊する。
ログ記録。 誰が何を呼び出し、どのプロバイダーが処理し、いくらかかり、成功したか。

/usage-logs/common パスは、運用者にこの証跡の統合ビューを提供します。これがなければ、チームはプロバイダーの請求書からエージェントの動作を後追いで復元するしかありません。

監査ログはルーティング要件であり、後付けではない

エージェントが誤動作したとき、プロンプト、ツール選択、プロバイダー、レスポンス、コストというチェーンを再構築する必要があります。OWASP Top 10 for LLM Applications 2025 は、過度の自律性と機密情報の開示を主要なリスクとして挙げています。両方とも、ツール呼び出しに記録が残らないと悪化します。

エージェントツールルーティングに有用な監査ログは、以下を捉えます。

ツール名とバージョン
保持ポリシー内での、プロバイダーへの完全なリクエスト・レスポンスペイロード
使用されたモデルとプロバイダー
トークン数とコスト
ユーザーまたはエージェントの identity
タイムスタンプとレイテンシ
ポリシー判断：許可、ブロック、ダウングレード、リトライ

これは単なるコンプライアンスの見せかけではありません。プロバイダー更新後に出力フォーマットを崩す特定のツール、または失敗したツールを 50 回リトライするエージェントループを見つけるためのものです。

まとめると：運用モデル

エージェントツールルーティングを考える実用的な方法は、関心事を層で分けることです。

層	担当	例
エージェントフレームワーク	ツール定義、スキーマ、呼び出し規約	OpenAI スタイルの関数呼び出し、MCP クライアント設定
ゲートウェイ	プロバイダー選択、ポリシー適用、ログ記録	AveMujica API がクォタ付きプロバイダーに呼び出しをルーティングし、結果を記録
プロバイダー	モデル推論、アップタイム、価格設定	OpenAI、Anthropic、Gemini、Azure、Bedrock
運用	可観測性、支出レビュー、ポリシー調整	/usage-logs/common を週次で確認し、/channels の重みを調整

この分離により、コストとリスクに影響する判断を一元化しつつ、エージェントコードをクリーンに保てます。また、エージェントを書き換えずにプロバイダーを切り替えられるということでもあります。

より広範な API ガバナンスへの接続

エージェントツールルーティングは、AI チーム向け API キー・ガバナンスと同じ分野に属します。両方とも、モデルへのアクセスを可観測かつ管理可能にすることを目指しています。チームですでにキーとクォタを一元管理しているなら、ツールルーティングポリシーを追加するのは次の論理的なステップです。

コストの透明性も同様です。モデル価格の可視性は重要です。なぜなら、ツール呼び出しはモデル呼び出しの回数を倍増させるからです。1 つのエージェントタスクが、異なるツールを通じて 5 回や 10 回モデルを呼び出すこともあります。ツールごとのコストアトリビューションがなければ、どの能力が予算を圧迫しているかわかりません。

次にすべきこと

まず、エージェントが呼び出せるすべてのツールを棚卸ししてください。それぞれをローカル、MCP、モデル駆動のいずれかに分類します。モデル駆動ツールについては、必要な能力、許容レイテンシ、最大コストを文書化します。次に、フォールバックルール付きのプロバイダーチャンネルにマッピングし、統合ログを有効にします。

ゲートウェイですでに複数プロバイダーをサポートしているなら、作業は主にインフラではなくポリシーのものです。最初に能力で、次にコストで、そして耐性でルーティングしてください。その後、監査証跡を使って、ポリシーが機能していることを証明します。

AveMujica API が役立つ場面

AI ワークロードが実運用に入ると、課題は「呼び出せるか」から「誰が使い、いくらかかり、失敗時にどう扱うか」へ移ります。AveMujica API はモデルアクセス、価格文脈、ウォレット影響、利用履歴を同じコンソールにまとめます。

まず 1 つの実ワークフローで試します。
モデルアクセス、コスト、ログを同じ場所で確認します。
レイテンシ、支出、所有者が明確になってから対象を広げます。

ゲートウェイは手順を増やすためではなく、キー、請求、プロバイダー制限、障害対応を分散させないために使います。

よくある質問