ひとことで言うと
エージェントと外部機能をつなぐための標準プロトコルです。ツールをエージェントに直接登録する代わりに、MCP サーバがツールを預かり、エージェントは JSON-RPC 2.0 で発見して呼び出します。AWS のガイダンスはこれを「AI アプリケーションにとっての USB-C」と呼んでいます。AWS が作った仕様ではありませんが、AWS はプロトコルの開発と実装に貢献しています。
要するに、ツールをエージェントに溶接するのをやめて、コンセントに差す形にしたものです。溶接だと、道具を1本足すたびにエージェント本体を作り直して再デプロイすることになります。コンセントなら、差し口の規格さえ合っていれば道具側だけ差し替えられる。
だから試験でも「MCP とは何か」は問われません。問われるのは「そのコンセントをどこに立て、誰の権限で通電させるか」のほうです。
なぜ生まれたか
| 何が不便だったか | MCP が置いた答え |
|---|---|
| 同じ外部機能に対して開発者それぞれが自前のツールを書き、実装がばらつく。ライブラリで配っても中央のガバナンスがない（セキュリティポリシーの強制・利用追跡・バージョン管理・コンプライアンス確認ができない） | ツールのパッケージ・提示・呼び出し方を標準化し、MCP サーバに集約する |
| ツールをエージェントに直接埋め込むと、ツールを1つ追加・更新するたびにエージェントを再デプロイする必要がある | エージェントの開発・運用を、使うツールから分離する |
| ツール定義がコンテキストウィンドウを食う。ツール20個で、説明文だけで1回の呼び出しあたり 5,000〜10,000 トークンを消費する | サーバ側でツールを整理し、必要なものだけを提示する余地を作る |
| ツールが多すぎるとモデルが選択と順序を誤ってハルシネーションを起こし、少なすぎると文脈が足りずに推測で答える | 「ちょうどよい数」に絞るための設計対象として、ツールを独立した資産に切り出す |
なお AWS のガイダンスは、MCP がこの問題を全部解くとは書いていません。「MCP 標準はスケールとガバナンスの課題をすべて解決するわけではない」と明記した上で、ツール設計・ホスティング・エンタープライズガバナンスの3つの戦略と組み合わせる必要があるとしています。
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| 既存 API・Lambda のツール化 | Amazon Bedrock AgentCore Gateway で API・Lambda・既存サービスを MCP 互換ツールに変換する | D2 |
| ローカル開発でのツール利用 | MCP サーバをローカルのサブプロセスとして起動し、標準入出力上の JSON-RPC で通信する。クライアント・サーバ間の認証は不要 | D2 |
| リモートでの集中管理 | HTTP / HTTPS でアクセスするリモート MCP サーバ。アクセス制御・認証認可・バージョン管理を中央で行う | D2・D3 |
| 単一エンドポイント化 | MCP ゲートウェイが認証・認可・ルーティング・プロトコル変換を引き受ける。新しいサーバやツールを動的に追加して即座に使わせられる | D2・D3 |
| ツール爆発への対処 | ゲートウェイのセマンティック検索で、文脈に合うツールだけを提示してコンテキストウィンドウを節約する | D4 |
| ドメイン知識の埋め込み | 複雑な手順を LLM に組ませず、process_patient_data のようなカスタムツールに手順ごと閉じ込める（HIPAA 検証・PII 匿名化・形式変換など） | D3 |
| 組織標準の強制 | deploy_secure_infrastructure のようなゴールデンパスをツール化し、コスト・性能・セキュリティの基準を規定的に効かせる | D3 |
| 発見と配布 | 社内 MCP レジストリ（コンテナレジストリに近い形）で、利用者がサーバを検索・取得できるようにする | D3 |
試験でどう問われるか
**MCP は D1.5（検索の設計・MCP クライアントと function calling）と D2.1（エージェント型AIとツール統合）の両方にスキル文として書かれています。**特に D2.1 には **「Lambda でステートレスな MCP サーバ、ECS で複雑な MCP サーバ」**という置き場所の分岐が明示されており、ここが最も出題になりやすい形です。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| MCP サーバの置き場所 | 状態を持たない短時間のツール／リクエスト単位で完結 → Lambda | 常駐や長時間処理が要るのに Lambda を選ぶ |
| 同上（複雑な側） | 長時間の接続・重い依存・常駐が要る → ECS などのコンテナ | 「全部 Lambda で統一」する案 |
| ローカルかリモートか | ユーザー個人の資格情報でローカルのファイル・アプリを触る（IDE のコーディング支援など） → ローカルホスティング | 個人資格情報が要る用途をリモートに寄せる案 |
| 同上（リモート側） | バージョンを組織で統制したい／脆弱性のある古い版が野良で動くのを止めたい → リモートホスティング | ローカル配布のまま「利用者に更新を周知する」運用でしのぐ案 |
| サーバが増えすぎた | エージェントが個々のリモートサーバを全部登録する形が破綻 → MCP ゲートウェイで単一エンドポイント化 | エージェント側にサーバ一覧を持たせ続ける案 |
| ツールが増えてレイテンシが悪化 | 文脈に合うツールだけ渡したい → ゲートウェイのセマンティック検索 | 全ツール定義を毎回提示する案 |
| 下流リソースへの権限 | エージェント呼び出しに使ったトークンを下流で使い回さない → 用途ごとにスコープを絞った専用トークン | ユーザーの資格情報をそのまま伝播させる案 |
| トークンの取り違え防止 | aud（audience）クレームがトークンの受け手と一致することを検証する | ベアラートークンを呼び出し元から下流へそのまま渡す案 |
| ユーザー同意が要るか | ユーザー固有データにアクセスし、本人が同席していて同意できる → user-delegated access。バッチ・定期実行で人がいない → machine-to-machine | 定期実行のログ収集にユーザー同意フローを組む案 |
| 下流 API を守りたい | 主たるレート制限を MCP サーバ側に置き、バックエンドは二次防御。複数 API を叩くツールは最も低いレートに合わせる | 下流のレート制限任せにする案 |
権限設計の定番シナリオがそのまま出ます。管理者権限を持つユーザーが「本番DBを検証環境に複製して」と頼み、LLM が後片付けだと誤解して旧DBの削除を実行しようとする——このときユーザーの資格情報を使い回していれば削除は通ります。MCP サーバが READ と CREATE だけに絞った専用トークンを使っていれば、削除は失敗して安全側に倒れます。「ハルシネーションを防ぐ」ではなく「ハルシネーションしても被害が出ない」が正解の向きです。
実務でどう使うか
- ツール名は
domain_noun_verbで付けます。github_issue_create/github_issue_list/github_pullrequest_mergeのように。アルファベット順に並べたときに関連する操作がまとまるので、LLM のスキャンにも人間の閲覧にも効きます。名前衝突（別のツールが同名）の防止が本来の目的です - 1つの MCP サーバのツール数には上限を設けます。 AWS のガイダンスは 50 を超えるなら複数サーバに分割することを検討するよう明記しています。理由は「エージェントがどう使うかを仮定してはいけない」から——素朴に全ツールを列挙して LLM に渡す実装は普通にあります
- 読み取り用と書き込み用でサーバを分けるのは有効です。 その上でエージェント側にガードレールを置き、①ユーザー入力が読み取り操作だと判定されたときだけ読み取り専用サーバを読み込む（条件付きロード）②ユーザーの認可に応じてアクセスできるサーバを絞る（権限ベースのフィルタ）という二段構えにします
- ローカルホスティングの弱点は更新できないことです。 利用者が各自でサーバを取得・設定するため、脆弱性のある古い版を使い続けていても止められません。コンプライアンス要件があるなら、この一点でリモートかゲートウェイに寄ります
- Streamable HTTP トランスポートは、ステートレスな要求応答とセッションIDを持つステートフルな管理の両方に対応します。 「MCP＝ステートレス」でも「MCP＝常時接続」でもありません
- 測るべき指標は決まっています。 トークン使用量／ツール選択の正確さ／エージェントに登録されているツール数／ツールのレイテンシ。特に各ツールが返す出力トークン量に閾値を置いてアラームを張ると、コンテキストウィンドウを食い潰すツールを事前に捕まえられます。ツール選択の正確さは、過去の API 呼び出しログから合成したゴールデンデータセットで回帰テストします
ハマりどころ: レート制限情報は HTTP ヘッダ（X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset）でエージェントに返すのが有効ですが、それとは別にロードシェディングも要ります。「どの利用者もレート上限を超えていないのに、全体の負荷でシステムが劣化する」状態は、レート制限だけでは防げません。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| function calling（ツール呼び出し） | function calling はモデルがツールを呼ぶという仕組みそのもの。MCP はそのツールをどう配布・発見・呼び出すかの規約。MCP を使わなくても function calling はできます |
| A2A プロトコル | AWS の比較表では、A2A は Google が支援するクロスプラットフォームのエージェント連携向けで、MCP より新しく採用は限定的とされています。単純な要求応答も、セッションを伴う対話も、AWS は MCP 側を挙げています |
| Amazon Bedrock AgentCore Gateway | あれは MCP ゲートウェイの実装のひとつ。API・Lambda・既存サービスを MCP 互換ツールに変換し、セマンティック検索でツール発見を助けます。プロトコルと実装を混同しないこと |
| Bedrock Knowledge Bases（RAG） | RAG は文脈データを引いてくる。MCP は外部機能を呼び出す。天気予報や「DBに顧客が何人いるか」は RAG では答えられません（そこが MCP の出発点） |
| API Gateway | API Gateway は HTTP のフロント。MCP ゲートウェイはツール発見と認可の集約点で、ツール一覧の提示とセマンティック検索を担います |
| AgentCore Identity | あれは MCP の一部ではなく、MCP のトークン分離パターンを実装するための AWS 側の部品。ワークロードトークン（M2M）とユーザートークン（委譲）を分けて管理します |
| MCP レジストリ | ホスティング方式ではなく配布と発見の仕組み。ローカルでもリモートでも必要になります（コンテナレジストリに近い位置づけ） |
想起チェック
Q1. 「MCP サーバを Lambda に置くか ECS に置くか」を分ける基準は？
状態と実行時間です。リクエスト単位で完結するステートレスなツールは Lambda、長時間の接続・重い依存・常駐が要る複雑なサーバは ECS などのコンテナ。試験ガイドのスキル文にこの対比がそのまま書かれています。
Q2. ローカルホスティングを選べない要件を1つ挙げてください。
バージョンの統制が要る場合です。ローカルでは利用者が古い版を使い続けても止められず、脆弱性が残ります。逆に、利用者個人の資格情報でローカルのファイルやリポジトリを触る用途は、ローカルが素直です。
Q3. エージェント呼び出しに使われたトークンを、MCP サーバが下流リソースへそのまま渡してはいけない理由は？
LLM が誤った操作を選んだときに、それが通ってしまうからです。用途ごとにスコープを絞った専用トークンを使えば、想定外の操作は権限不足で失敗します。加えて aud クレームがトークンの受け手と一致することを検証し、サーバ間でトークンを使い回さないようにします。
Q4. 1つの MCP サーバに入れるツールの数について、AWS のガイダンスが挙げている目安は？
50 を超えるなら複数のサーバへの分割を検討する、です。エージェントが全ツールを素朴に列挙して LLM に渡す可能性があるため、サーバ側で上限を設けます。命名は domain_noun_verb を推奨。
Q5. ツールが数百に増えてレイテンシと精度が悪化しました。プロトコル側の定石は？
MCP ゲートウェイのセマンティック検索で、文脈に合うツールだけをエージェントに提示します。ツール定義はコンテキストウィンドウを消費し、20個でも説明文だけで 5,000〜10,000 トークンに達します。