請負業者を雇って、家の鍵、クレジットカード、そして何の指示も渡さないと想像してみてください。業務範囲（スコープ）なし。支出の上限なし。触れてよいもののリストなし。
それが、ほとんどのエージェントがツールに対してやっていることです。
post 1では、AIエージェントが失敗する仕組みを見ました。post 2では、Agentic RAGで知識の問題を修正しました。しかし、まだ対処できていない別の失敗のクラスがあります。エージェントが現実世界でやってしまうこと、つまりフライトの検索、APIへの問い合わせ、クレジットカードへの課金などを、構造も境界も説明責任もないまま実行したらどうなるのか、という問題です。
それを直しましょう。
問題：チェックされない強い権限を持つエージェント
旅行計画エージェント（4日間のハイキング旅行、予算重視、ちょっと豪華なディナー1回）は、ただ考えるだけではありません。行動します。フライト検索APIを呼びます。天気サービスにアクセスします。レストランのデータベースを照会します。さらには、何かを予約してしまうかもしれません。
そして、構造がないと、実際に起きるのはこうです：
間違ったツール、間違ったパラメータ、ガードレールなし。 エージェントは「それっぽい」ツールを何でも選び、幻覚したパラメータを何でも渡し、うまくいくことを祈ります。フライト検索APIに、日付の形式が間違った状態でリクエストするかもしれません。ユーザーのメールを、必要としていない天気エンドポイントに送るかもしれません。期待していたレスポンス形式が得られなかったからといって予約呼び出しを5回リトライしてしまい、結果として5件のフライトを予約してしまうかもしれません。
ツール呼び出しは分散システム呼び出しだ。 ここは人が見落としがちな部分です。ツールを一度呼び出すたびに、外部システムへのネットワーク呼び出しが発生します。失敗します。タイムアウトします。部分的な結果を返します。レート制限があります。単純な関数呼び出しだと思って扱うと、痛い目を見ることになります。
推論と実行の分離がない。 エージェントの「考える」とツールの「やる」が同じプロセス内に同居していると、すべてが絡み合います。別々にテストすることができません。別々にスケールすることもできません。別々のチームに所有させることもできません。そして、境界でセキュリティを強制することは特にできません。境界がないからです。
ツールが隔離されていないと、統治できない。 誰が何を呼んだのか？何回呼んだのか？どんな権限で？もし、すべてのツールが「エージェントが自由に呼べる単なる関数」だとしたら、可視性も制御もゼロです。
解決策：MCP（Model Context Protocol）
MCP（Model Context Protocol）は、エージェントと外部システムの間で、安全で一貫した、構造化されたやり取りを可能にするプロトコル層です。エージェントの推論と、実際のツールの間に入る「仲介者」と考えてください。ルールを強制する翻訳者です。
エージェントはツールを直接呼びません。MCP経由で構造化されたリクエストを送ります。MCPサーバーがツールを実行し、結果が同じ経路で返ってきます。きれいで、監査可能で、制御されています。
アーキテクチャは次のようになります：
エージェントは片側に存在します。ツールはもう片側に存在します。MCPはその間にある「契約（コントラクト）」です。
関心の分離
これは重要な原則です。MCPでは：
- ツールの実装は、別々のMCPサーバープロセスで動作します。 ライフサイクルも、デプロイも、担当チームもそれぞれ独立したサービスです。
- エージェントの推論はクライアント側で行われます。つまり、あなたのアプリケーション内です。LLMが考え、計画し、次に何をするかを決めます。
- エージェントは、ツールが「どう動くか」を知る必要はありません。必要なのはインターフェースだけです。どんな入力を受け付けるのか？どんな出力を返すのか？それが契約です。
エージェントはリクエストを送ります。「シアトルからデンバーまで、3月15日に出発し、3月19日に帰る、予算クラスのフライトを検索して」。MCPサーバーが残りを担当します。どのAPIを呼ぶか、どのように認証するか、リトライをどう扱うか、レスポンスをどう整形するか。エージェントは、きれいで型付けされた結果を受け取ります。
これは、マイクロサービスが機能するようにしたのと同じ原則です。インターフェースを定義し、実装を隠す。違うのは、今それをAIエージェントに適用している点です。
モジュール性とスケーラビリティ
ツールがエージェントのロジックから切り離されているため、実際のモジュール性が得られます：
- 異なるチームが異なるツールを担当する。 フライト予約チームがフライトのMCPサーバーを管理します。天気チームが天気のMCPサーバーを管理します。彼らはそれぞれ独立して開発し、テストし、デプロイします。
- プラグ＆プレイのツール。 ツールがMCPのインターフェース（入力スキーマと出力スキーマ）に準拠していれば差し替え可能です。天気プロバイダを別のものに切り替えたいですか？MCPサーバーの実装を変更します。エージェントは違いを知る必要がありません。
- 独立してスケールできる。 休暇シーズンでフライト検索ツールが過負荷になっているなら、そのMCPサーバーをスケールさせます。天気サーバーは小さなままで構いません。モノリスをスケールするのではなく、必要な部分だけをスケールするのです。
これは、エージェントのツール群に適用されたマイクロサービスのアーキテクチャです。そして、すでにコンテナのオーケストレーション（Kubernetes、AKS）に投資しているなら、MCPサーバーのデプロイは、その世界観にそのまま組み込まれます。
セキュリティ：エージェントを決して信用しない。境界を信用する
ここから本番です。エージェントがAPIを呼び出し、データにアクセスしたり、副作用を引き起こしたりできるようになると、それはあなたの攻撃対象領域の一部になります。そしてLLMはセキュリティの基盤（プリミティブ）ではありません。プロンプトインジェクションによって操作され得る、敵対的な入力に混乱させられる、あるいは単純にミスをする確率的な文章生成器です。
つまり、エージェントを信頼しない。信頼するのは境界だ。
MCPでは、セキュリティはモデルの外側に存在します：
- ツールは、あなたが管理するサーバー上で実行されます。
- アクセスは、エージェントが「アクセスすべきだと判断したかどうか」ではなく、アイデンティティによって制御（ゲーティング）されます。
- 権限は、エージェントが行動する前に強制されます（後ではありません）。
移動（旅行）のシナリオで言えば、これはこういうことです。エージェントはフライト予約を提案することはできます。しかし、それを実行できるのは、適切なアイデンティティと権限で認証された、MCPサーバー上で動作するツールだけです。エージェントが提案する。システムが処理する。
ルールは、セキュリティの世界のあらゆる場所と同じです：
- 最小権限。 エージェントには、必要なツールだけに正確にアクセスを与え、それ以上は与えません。
- 明示的な契約（コンテラクト）。 ツールとのやり取りには定義済みのスキーマがあります。自由形式のAPI呼び出しは行いません。
- 監査された実行。 すべてのツール呼び出しはMCPを通過するため、すべての呼び出しがログに記録されます。
- プロンプト経由のツールアクセスを禁止。 うまいプロンプトなら新しい機能を付与できません。文脈に隠し資格情報を埋め込まない。 「モデルが何かを試そうと決めた」なんてこともありません。
大規模なアイデンティティおよび権限管理には、Azure AI Gateway のようなものを使うとよいでしょう。これはあなたのMCPサーバーの前に配置され、認証・認可・レート制限を一元的に処理します。
エンタープライズのガバナンス
本番環境でエージェントを運用している組織にとって、MCPが提供する重要なものがあります。それは、強制のための単一の取り締まりポイント（チョークポイント）です。
すべてのツールとのやり取りはMCPを通過します。つまり、次のことができます：
- スロットリングでツールの過負荷を防ぐ。エージェントがAPIを叩き始めたとしても、MCPは下流のサービスが気づく前にレート制限できます。 返却形式: {"translated": "翻訳されたHTML"}
- 組織のポリシーを一元的に強制する。 データのプライバシー規則？ 利用制限？ コンプライアンス要件？ それらは、個々のツール実装に散らばるのではなく、MCPレイヤー上に存在します。
- すべてを監視する。 すべてのツール呼び出し、すべての応答、すべての失敗を、ひとつの場所にまとめて記録します。
これが、「本番環境にエージェントがいる」と「本番環境にいるエージェントを、実際に統治できる状態になっている」との違いです。
コスト管理
実用的な例をひとつ。各ツールはそれぞれ独自のMCPサーバーとして動作するため、コストを独立して監視し、制限できます。
- ツールごとのトークン使用量を追跡する。 たとえばフライト検索は、天気の参照よりも10倍多くトークンを消費するかもしれません。いま、それが見えるようになります。
- ツール呼び出しとリトライを監視する。 ツールが失敗して繰り返しリトライしているなら、それが分かり、制限も設定できます。
- ツールごとの総実行時間を測定する リクエストごと、ユーザーごと。予算に合わせて調整しましょう。
すべてが単一のエージェントプロセスを通って動く場合、コストの割り当ては推測ゲームになります。MCPでは、それは会計です。
次にやるべきこと
外部システムと連携するエージェントを構築しているなら、そして多くの有用なエージェントはそうであるなら、最初に着手すべきポイントはここです。
- エージェントの推論とツール実行を分離する。 ツールがエージェントコード内の関数であるなら、それらを取り出します。MCPのインターフェースの背後に置いてください。
- すべてのツールに対して明確な契約（コントラクト）を定義する。 入力スキーマ、出力スキーマ、エラーの種類。契約にないものは存在しないものとします。
- モデルではなく、MCPの境界でセキュリティを強制する。 身元（アイデンティティ）、権限、監査ログは、インフラストラクチャ層に属します。
- MCPサーバーを独立したサービスとしてデプロイする。 コンテナを使い、Kubernetesを使い、チームがすでに知っているものを使ってください。重要なのは、ライフサイクルとスケーリングを独立させることです。
- MCPを通じて統治（ガバナンス）を一元化する。 レート制限、ポリシーの強制、コストの追跡。ひとつのレイヤー、ひとつの参照場所。
- エージェントに自己認可をさせない。 エージェントは提案します。実行するのは、（適切なアイデンティティと権限を備えた）システムです。
参考文献
- Workload IdentityでAzure AKSにMCPサーバーをデプロイする — Paul Yuによる、AKS上で本番環境向けにMCPサーバーを実行するためのガイド。
- 安全でスケーラブルなリモートMCPサーバーを構築する方法 — GitHubによる、デフォルトで安全なMCPサーバーを構築するためのガイド。
次は？
MCPは、安全で構造化されたツールアクセスを提供します。しかし、エージェントそのものをどのように組織化すればよいのでしょうか？ 複数ステップのワークフロー（旅程を計画する、フライトを予約する、レストランを探す、行程表を作る）を扱うとき、そこにあるすべてを、混乱に崩れてしまうことなくどう連携させるのでしょうか？
次の記事では、複数ステップのエージェントを実際に信頼できるものにする4つの設計パターンを取り上げます。今日から使い始められます。
あなたはエージェントシステムで、ツールアクセスと統治（ガバナンス）をどのように管理していますか？ 下のコメント欄であなたの考えを共有してください！
