MCPサーバー、AWSのどこに置く？

Transcript

1. MCPサーバー、AWSのどこに置く？ JAWS-UG AI/ML支部 LT大会 — 2026-03-23 1
3. 今日話すこと MCPサーバーをリモートにホスティングするとき、AWSの選択肢はどれが適切か？ パート1 — MCPトランスポート仕様の整理 パート2 — AWSホスティング5選択肢の比較 3
4. パート 1：MCPトランスポート仕様 2つの通信方式を整理する 4
5. MCPには2つのトランスポートがある MCPサーバーとクライアントの間の通信方式として、仕様上2つ定義されている 1. stdio — ローカル向け 2. Streamable HTTP — リモート向け それぞれどんな仕組みか見ていきます 5
6. stdio ローカルのOSの機能（プロセス間パイプ）を使って通信する方式 JSON-RPCメッセージのやり取り（同じPC内のみ） クライアント （Claude Desktop等） MCPサーバー （サブプロセス） FD0/stdin FD1/stdout パイプA（カーネル内バッファ） クライアント → サーバー⽅向 パイプB（カーネル内バッファ） サーバー → クライアント⽅向 stderr（ログ専⽤） ⚠ stdoutにデバッグ⽂字列を書くとJSONパースエラーになる！ デバッグ出⼒は必ずstderrへ 6
7. Streamable HTTP HTTPのPOST / GET / DELETEを使って通信する方式。それぞれの役割は後ほど説明し ます。 POST / GET / DELETE クライアント MCPサーバー POST （必須） ツール呼び出しリクエスト パターンA: JSON即時応答（シンプル） パターンB: SSEストリーム（途中経過付き） GET （任意） サーバーからの通知を待ち受ける リソース変更通知・Push（⻑時間接続） DELETE （任意） セッション明⽰的終了 200 OK または 405 Not Allowed 7
8. 2つのトランスポートの比較 項目 stdio Streamable HTTP 通信の仕組み OSのプロセス間パイプ HTTP 接続形態 1対1 N対1 通信範囲 ローカルのみ ネットワーク越しも可 MCPサーバーをリモートに置くなら Streamable HTTP 一択 8
9. Streamable HTTPをもう少し詳しく Streamable HTTPは1つのエンドポイントURLに対して、3つのHTTPメソッドを使い分 ける POST / GET / DELETE クライアント MCPサーバー POST （必須） ツール呼び出しリクエスト パターンA: JSON即時応答（シンプル） パターンB: SSEストリーム（途中経過付き） GET （任意） サーバーからの通知を待ち受ける リソース変更通知・Push（⻑時間接続） DELETE （任意） セッション明⽰的終了 200 OK または 405 Not Allowed 9
10. ホスティング要件を4つのレベルで整理する ※ MCP公式仕様の定義ではなく、ホスティング要件を整理するために勝手に分類 レベル 何を使うか どんな場面で必要か L1 POST → JSON単発応答 即座に結果を返せるとき L2 POST → SSEストリーム応答 処理に時間がかかる、途中経過を返したいとき L3 GET → SSEストリーム サーバーから能動的に通知を送りたいとき L4 L1〜L3 + セッション管理 クライアントごとの状態を保持したいとき 現状はほぼL1で動いているが、今後L2以上が必要になるケースは増えていく見込み。 10
11. L1: POST → JSON単発応答（パターンA） 普通のWeb APIと同じ ツールの実行が一瞬で終わるケース（API変換、データ取得など）で使う サーバーレス環境（Lambda等）でそのまま動かしやすい SSEもセッション管理も不要で、ホスティング先への要求が最も低い構成 11
12. L2: POST → SSEストリーム応答（パターンB） SSE（Server-Sent Events）= 1つのHTTP接続を維持したままデータを逐次送信する仕 組み ツール実行に時間がかかるケース（外部API呼び出し、重い処理など）で使う 途中経過をクライアントに届けたいときに使う HTTP接続を維持する必要があるため、ホスティング先のタイムアウト制限が重要 になる 12
13. L3: GET → SSEストリーム（サーバー起点の通知） クライアントがGETで接続を張り、サーバーが能動的に通知を送信する MCPサーバーが管理するリソースが外部から変更されたとき、クライアントに通 知するための仕組み L2との違い: L2: POSTで送って、SSEストリームでクライアントに返す L3: GETで接続した後、クライアントが待ち受けている接続に対して、サーバ ーが好きなタイミングで通知を送る サーバーが常駐している必要があり、サーバーレス環境では困難 13
14. L4: セッション管理 Mcp-Session-Id ヘッダーでクライアントごとの状態を管理する MCPサーバーが前のやり取りの文脈を保持したいとき、クライアント固有の状態 を管理したいときに使う L4はL1〜L3のどれとも組み合わせて使える（L1+L4、L2+L4、L3+L4） セッション状態の保存先（Redis、DynamoDB等）が必要 スケールアウト時はスティッキーセッションまたは共有ストアが必要になる 14
15. レベルのまとめ レベル 要件 ホスティングへの要求 L1 HTTPリクエスト/レスポンス 低い（普通のWeb API） L2 SSEストリーミング 中（HTTP接続の長時間維持） L3 サーバー起点の通知 高（常駐プロセス必要） L4 セッション管理 L1〜L3と組み合わせ（外部ストア必要） レベルが上がるほど、ホスティング先に求められる要件が増える。 15
16. ただし、現状のエコシステムは... 2026年3月時点では、実用的なMCPサーバーのほぼすべてがL1で動いている L2: MCP公式仕様やMCP SDKにAPIは存在するが、実際に使われている例はまだ少 ない L3: Claudeの公式ドキュメントで、この機能に未対応と明記されている（参照） L4: MCPサーバーはステートレスを前提に設計されていることがほとんどで、実例 はまだ少ない 今はまだ急いで必要になるものではないが、今後エコシステムが成熟するにつれてL2 以上の重要性は増していくと考えている。 16
17. パート 2：AWSホスティング選択肢の比較 4つの選択肢を比較する 17
18. 比較対象 # 選択肢 特徴 1 Lambda + Function URL サーバーレス、ゼロスケール 2 ECS Fargate コンテナ常駐、柔軟性高 3 EC2 制約なし、運用負荷最大 4 AgentCore Runtime MCP特化のマネージド環境 18
19. 比較軸 1. MCP SDK互換性 — MCPサーバーの開発キットがそのまま動くか 2. SSE/ストリーミング対応 — MCPのレベル別にどこまで対応できるか 3. コスト — 月1,000リクエスト想定での月額目安 19
20. 比較軸 1：MCP SDK互換性 20
21. MCP SDK互換性 — MCP SDKとは Anthropic（MCPの仕様策定元）が公式に提供しているサーバー開発キット Python SDK（ modelcontextprotocol/python-sdk ） TypeScript SDK（ modelcontextprotocol/typescript-sdk ） MCPサーバーを作るとき、ほとんどの開発者はこのSDKを使うと思われる。 このSDKで作ったサーバーがそのままデプロイできるかがホスティング先選びのポイ ントになる。 21
22. MCP SDK互換性 — 内部的な仕組み MCP SDKは内部でHTTPサーバーを起動して、リクエストを待ち受け続ける設計 mcp = FastMCP("MyServer") mcp.run(transport="streamable-http", host="0.0.0.0", port=8000) # → ポート8000 でHTTP サーバーが起動し、ずっと動き続ける ECS / EC2 / AgentCore → プロセスを常駐させられるのでそのまま動く Lambda → サーバーレスなのでHTTPサーバーを常駐させられない 22
23. MCP SDK互換性 — サービス別の対応状況 選択肢 そのまま動 くか 備考 ECS Fargate ◦ SDKが使うポートに合わせたタスク定義の設定が必要 EC2 ◦ SDKが使うポートに合わせたセキュリティグループ等の設定 が必要 AgentCore Runtime ◦ SDKのデフォルト設定（ポート8000、パス /mcp ）と一致す るため設定不要 Lambda + Function URL × 変換ツールが必要 23
24. Lambda + Function URLでMCPサーバーを動かすには Lambda用の変換ツールがAWS公式等から複数提供されている 変換ツール 提供元 Lambda Web Adapter AWS公式 run-mcp-servers-with-aws-lambda AWS Labs MCPLambdaHandler AWS Labs middy-mcp コミュニティ これらの変換ツールなしにはLambdaでMCPサーバーは動かせず、構成の複雑性が増 す。 24
25. 比較軸 2：SSE/ストリーミング対応 25
26. パート1で整理したレベル別の対応状況 ※ L1〜L4はパート1で整理したホスティング要件のレベル分け 選択肢 L1 L2 L3 L4 Lambda + Function URL ◦ ※ 変換ツール必要 ◦ 最大15分 △ △ ECS Fargate ◦ ◦ ALB最大4,000秒 ◦ △ 外部ストア推奨 EC2 ◦ ◦ ◦ ◦ AgentCore Runtime ◦ ◦ 最大60分 ◦ ◦ マネージド ◦ = 対応可 / △ = 条件付き 26
27. 比較軸 3：コスト 27
28. コスト比較（月1,000 MCPリクエスト想定） 選択肢 月額 コールドスタート Lambda + Function URL $0 発生する可能性がある（3〜5秒） Lambda + Provisioned Concurrency $6.85 なし AgentCore Runtime $0.01 ほぼなし（microVM起動1秒未満） EC2 (t4g.nano) $8.36 なし（常時起動） ECS Fargate + ALB $26.74 なし（常時起動） 28
29. AgentCore Runtimeの注意点 MCPプロトコル仕様にはバージョンがあり、クライアントとサーバーは同じバージョ ンの仕様に基づいて実装されている必要がある MCPプロトコル仕様の最新バージョンは 2025-11-25 主要なMCPクライアント（Claude等）は 2025-11-25 への移行が進んでいる しかしAgentCore Runtimeは 2025-06-18 までしか対応していない クライアントが新しい仕様で接続すると、AgentCore Runtime上のMCPサーバーとの 通信が失敗するリスクがある。 29
30. ユースケース別の選択肢 基本的にはAgentCore Runtimeが最もバランスが良い → SDK互換性◎、コスト最安クラス、コールドスタートほぼなし、インフラ管理不要 ただしMCPプロトコル最新バージョンが必要な場合は他の選択肢を検討： コスト最優先 → Lambda + Function URL 本番環境・長時間接続 → ECS Fargate 制約なし・フルコントロール → EC2 30
31. まとめ MCPサーバーのホスティング先は、SDK互換性とMCPで実現したいことから考える MCP SDKは常駐サーバー前提 → ECS/EC2/AgentCoreはそのまま動く、Lambdaは 変換ツール必要 AgentCore Runtimeが総合的に最もバランスが良いが、MCPプロトコルバージョン の追従に注意 コスト最優先なら Lambda + Function URL 本番環境・長時間接続なら ECS Fargate 選択肢を知った上で、自分のユースケースに合ったものを選びましょう。 31
32. ありがとうございました 32