AgentCore RuntimeのStateful MCPを理解するための前提知識——MCPとAIエージェントの関係

Amazon BedrockがAgentCore RuntimeのStateful MCPに対応した。このアップデートを正しく理解するには、まず「MCPとは何か」「なぜStatefulが必要なのか」を押さえておく必要がある。

この記事はその前提知識を整理することを目的としている。読み終えたらStateful MCPの解説記事に進んでほしい。

MCPとは何か

MCP（Model Context Protocol）はAIが外部のツールやサービスと通信するための共通規格。

LLM単体でできることはテキストの生成だけで、「ファイルを読む」「データベースを検索する」「APIを叩く」といった操作はできない。MCPはこのギャップを埋めるために、AIと外部ツールをつなぐ通信プロトコルとして機能する。

【MCPの基本構造】

AIクライアント（Claude等）
  ↕ MCPプロトコル
MCPサーバー（外部ツール）
  ↕
実際のサービス（DB・API・ファイルシステム等）

MCPを使うとAIが「ツールを呼び出す」という形で外部の機能を使えるようになる。例えば「Slackのメッセージを検索して」という指示を受けたAIが、Slack用のMCPサーバーにツール呼び出しを送り、結果を受け取って回答する。

AIエージェントとMCPの関係

「AIエージェント」とは、LLMが自律的にツールを組み合わせてタスクをこなす仕組みのことを指すことが多い。

【エージェントの動き方】

ユーザー: 「先月の売上レポートを分析して要約して」

エージェント（LLM）:
  1. DBからデータを取得（MCPツール呼び出し）
  2. データを分析（LLMが考える）
  3. グラフを生成（MCPツール呼び出し）
  4. 要約を作成（LLMが生成）
  5. レポートを返す

この流れで鍵になるのがMCPによるツール呼び出し。エージェントが「何を・いつ・どんな引数で」ツールを呼ぶかを判断し、MCPを通じて実行する。

Stateless MCPの限界

MCPの仕様はもともとシンプルな設計で、1回のやり取りで完結する。

クライアント → リクエスト → MCPサーバー
MCPサーバー → レスポンス → クライアント
（終わり。次のリクエストには前回の文脈がない）

これがStateless（ステートレス）な状態で、シンプルなツール呼び出しには十分機能する。

ただし、エージェントが複雑なタスクをこなそうとすると限界が見えてくる。

例1：複数ターンの情報収集

ユーザー: 「出張の交通手段を予約して」

MCPサーバーがやりたいこと:
  「出発地はどこですか？」→ ユーザー「東京」
  「目的地は？」→ ユーザー「大阪」
  「日程は？」→ ユーザー「来週月曜」

Stateless MCPの問題:
  サーバーはユーザーへ質問を投げ返せない。
  必要な情報を一度に受け取るか、クライアント側が毎回情報を送り直すしかない。

例2：長時間処理の進捗通知

「10万件のデータを解析して」という処理を開始

Stateless MCPの問題:
  処理が完了するまでクライアントは待つだけ。
  途中経過を知ることができない。
  タイムアウトになる可能性がある。

例3：MCPサーバーからのLLM利用

MCPサーバーが処理の途中でLLMに判断を求めたい

Stateless MCPの問題:
  サーバーからクライアントへの「依頼」という通信ができない。
  サーバーが自前でLLMを呼ぶしかなく、コスト・権限管理が複雑になる。

これらの課題が「Stateful MCPが必要な理由」に直結する。

AgentCore Runtimeとは

Amazon Bedrock AgentCore Runtimeは、AIエージェントをサーバーレスで動かすためのマネージドサービス。

コードをS3にアップロードするだけでデプロイでき、スケーリングや実行環境の管理はAWSが担う。エージェントが使うMCPサーバーを自前で管理するインフラを持たずに動かせる。

【AgentCore Runtimeの位置づけ】

AIクライアント（Bedrock Agent等）
  ↕ MCPプロトコル
AgentCore Runtime（MCPサーバーの実行基盤）
  ↕
MCPサーバーのコード（Python等）
  ↕
実際の処理（DB・API・外部サービス等）

重要なのは、AgentCore RuntimeはMCPサーバーを動かす基盤であって、AIクライアント（エージェント）そのものではない点。AIクライアント（例：Bedrock Agent）がAgentCore Runtime上のMCPサーバーを呼び出すという構図になる。

なぜAgentCore RuntimeにStatefulが必要だったか

AgentCore Runtimeの用途はエージェントのためのツール実行基盤。エージェントが複雑なタスクをこなすには、先ほど挙げた「複数ターンの情報収集」「長時間処理の進捗通知」「MCPサーバーからのLLM利用」が必要になる場面が多い。

Stateless MCPではこれらを実現するために、アプリ側でセッション管理のコードを独自に実装する必要があった。

【Stateless MCPでの対応（従来）】
アプリ側でセッションIDを管理
→ リクエストごとに前回の文脈をDBから取得して渡す
→ タイムアウト処理・エラーハンドリングも独自実装
→ 管理コストが高い

Stateful MCPでは、セッション管理がMCPのプロトコル層に組み込まれる。Mcp-Session-Id ヘッダーで同一セッションのやり取りが紐づき、サーバー側がコンテキストを保持したまま複数ターンのやり取りができる。

【Stateful MCPでの対応（今回）】
Mcp-Session-Idでセッションが自動管理
→ サーバー側がコンテキストを保持
→ 複数ターンの会話・進捗通知・LLM依頼がプロトコルレベルで実現
→ アプリ側の実装がシンプルになる

各セッションは専用のmicroVMで実行されるため、複数ユーザーが同時に使っても互いのデータが混入しない。

次に読む記事

シリーズまとめページから全記事を確認できる。前提知識が整ったところで、以下の3記事で詳細を確認できる。

概念を理解したい
→ AgentCore RuntimeがStateful MCPに対応——1セッション内で複数回やり取りできるMCPサーバーとは

Elicitation・Sampling・Progress notificationsの3機能とセッション分離の仕組みを解説している。

実際に動かしたい
→ AgentCore RuntimeにMCPサーバーをデプロイしてElicitation・Sampling・Progress notificationsを試す

デプロイからクライアント実装まで、東京リージョンで動作確認したコードと手順をまとめている。

プロトコルレベルで理解したい
→ AgentCore Runtime Stateful MCPをゼロから理解する——プロトコルの仕組みから実装まで

JSON-RPC・SSE・SigV4署名の仕組みから解説している。エラーが出たときに何が起きているか判断できるレベルの理解を目指す。