AIエージェント（自律的にタスクを実行するAIの仕組み）に社内システムを操作させたいという相談は、インフラ担当の現場でも増えています。
DB接続情報を渡すのか、管理者権限を渡すのか、判断に迷う場面に心当たりがあるなら、この記事が整理の参考になるはずです。
扱うのはModel Context Protocol（略称MCP）です。AnthropicがOSS（オープンソースソフトウェア）として公開した、AIエージェントが外部ツールを呼び出すための標準プロトコルです。SREの視点では「AIをどう賢くするか」より「AIに何をどこまで実行させ、どう権限を絞り、障害時にどう追跡するか」が本題になります。この記事ではその観点から仕組みと確認ポイントを整理します。
なぜ工具呼び出しの標準化が必要になったのか
AIエージェントが「注文を調べて」「メールを送って」と頼まれても、モデル単体では外部システムに触れません。
そこで各社が独自にツール連携の仕組みを作ってきました。OpenAIのFunction Calling、AnthropicのTool Use、LangChainのBaseToolクラス、AutoGenの@toolデコレータなどです。
同じ「注文照会ツール」を作っても、フレームワークが変わるたびに書き直しが必要になります。これは車輪の再発明であり、ツールの再利用性がほぼゼロという状態でした。
さらに深刻なのが権限管理です。エージェントにDB照会をさせるためDBアカウントを渡し、メール送信のためSMTPパスワードを渡し、GitHub操作のためPersonal Access Tokenを渡す。こうした運用が積み重なると、プロンプトインジェクション（悪意ある入力でAIの挙動を乗っ取る攻撃）一つで本番DBが露出するリスクを抱えることになります。
MCPはこの状況に対して、ツール・データ・プロンプトテンプレートを標準サーバーとして公開し、対応するクライアントなら誰でも呼び出せる形に統一しました。エディタの世界でLSP（Language Server Protocol）が言語サーバーとエディタを疎結合にしたのと同じ発想です。VSCodeでもVimでも同じ言語サーバーが使えるように、MCPはClaude DesktopでもCursorでも同じツールサーバーが使える構造を作ります。
MCPの構成要素とアーキテクチャ
MCPは3つの要素で構成されます。
- Tools（工具）: 実行可能な関数。例えばquery_order(orderId)やsend_email(to, subject, body)
- Resources（資源）: 読み取り可能なデータ。file:///path/to/doc.mdやdb://users/123のような形式
- Prompts（プロンプトテンプレート）: 再利用可能な指示文。summarize_meeting(transcript)のような定型プロンプト
通信はJSON-RPC over stdio/SSEで行われます。stdioは標準入出力、SSEはServer-Sent Eventsで、いずれもプロセス間通信の方式です。
典型的な構成では、AIエージェント（LangGraphなどでオーケストレーションされる）がMCP Clientを通じて、MCP Server Registry（工具登録センター）に問い合わせます。Registryが権限チェックとルーティングを行い、実際のMCP Server（社内DB、GitHub、Slack、サンドボックスコード実行環境など）に処理を振り分けます。
重要なのは、各MCP Serverが独立したプロセスとして動く点です。エージェントは標準プロトコル経由でしか通信せず、ツールの実装とエージェント本体が疎結合になります。
実装例として、注文照会用のMCP Serverは@modelcontextprotocol/sdkを使い、query_orderとlist_recent_ordersという2つのツールをJSON Schemaで定義します。権限チェックはツール内部のロジックとして書かれ、order.userIdとリクエストのuserIdが一致しない場合はエラーを返す実装になっています。
ここがSREとして注目すべき設計です。権限チェックをエージェント側の判断に委ねず、ツール実装内部で強制しているため、プロンプト操作で権限を迂回することが構造的に難しくなります。
既存のRBAC・シークレット管理との比較
MCPは新しい認可の仕組みを発明したわけではありません。既存のインフラ運用資産とどう組み合わせるかが実務上の論点になります。
KubernetesのRBAC（ロールベースアクセス制御）やHashiCorp Vaultのようなシークレット管理基盤を使っている環境なら、MCP Serverプロセスにも同じ最小権限の原則を適用できます。DBアカウントをエージェントに直接渡すのではなく、MCP Server専用のサービスアカウントを発行し、そのアカウントの権限をVaultのポリシーで絞る構成が現実的です。
また各MCP Serverが独立プロセスであることは、コンテナ運用と相性が良い設計です。GitHub操作用サーバー、Slack連携用サーバー、社内DB照会用サーバーをそれぞれ別コンテナに分離し、ネットワークポリシーで通信範囲を制限すれば、1つのサーバーが侵害されても被害範囲を局所化できます。
コード実行系のツール（サンドボックスでのeval実行など）は特に注意が必要です。任意コード実行機能を持つMCP Serverは、gVisorやFirecrackerのような軽量VM分離、あるいは最低限seccompプロファイルを絞ったコンテナで動かすことを検討する価値があります。本番のホスト上で直接evalするような構成は、MCPを導入してもリスクの根本解決にはなりません。
導入前に確認すべきポイント
実際に社内でMCPの採用を検討する、あるいはすでに動いているMCP Serverの棚卸しをするなら、次の点を確認しておくと安心です。
- 使用中のAgentフレームワーク（LangGraph、AutoGenなど）がMCP Clientに対応しているか、公式リポジトリのREADMEやcompatibilityの記載を確認する
- 各MCP Serverがどのプロセス・コンテナで動いているか、権限（DBアカウント、APIトークン）が何にひも付いているかを棚卸しする
- ツール呼び出しのログがどこに残るか。JSON-RPCのリクエスト・レスポンスを監視基盤（Prometheus、Datadogなど）で追跡できる構成になっているか
- コード実行系ツールがサンドボックス化されているか、していない場合はどの分離手段が使えるか（コンテナのseccomp、VM分離など）
- 障害発生時、どのMCP Serverが原因だったかを特定できるトレーシングの仕組みがあるか（OpenTelemetryでの計装など）
オブザーバビリティの観点では、MCP Serverの呼び出しをブラックボックスにしないことが肝心です。JSON-RPCのやり取りは構造化ログとして残しやすい形式なので、既存のログ基盤に取り込む設計は難しくありません。
コスト面では、MCP Server自体は薄いプロセスですが、複数のツールサーバーを常時稼働させる構成になると、コンテナの数だけリソース消費が増えます。オートスケールやコールドスタート方式(必要時のみ起動する構成)を組み合わせて、常時起動が必要なサーバーとオンデマンドで十分なサーバーを仕分けると、無駄なコストを抑えやすくなります。
まとめ
MCPはAIエージェントとツールの間の呼び出し規約を標準化する仕組みで、LSPがエディタと言語サーバーを疎結合にしたのと同じ発想で設計されています。
導入を検討する際は、まず自社で使っているエージェントフレームワークがMCP Clientに対応しているかを確認してください。
そのうえで、各MCP Serverの権限がどのアカウントにひも付いているか棚卸しし、コード実行系ツールがサンドボックス化されているかを点検することが実務上の出発点になります。
ログとトレーシングの整備を後回しにすると、障害時にどのツール呼び出しが原因だったか特定できなくなるため、導入初期の段階で計装しておく価値があります。