第13章 — フレームワークとクラウド統合

LLM Primer IV: MCPで設計するAI認知 のウォークスルー第13回です。誰も本番MCPを素のプロトコルから作らない。2025〜2026年の正直な問いは「どのフレームワークで標準化するか」になり、答えは機能ではなく、システムの残りがどのクラウドに住んでいるかにほとんど依存する、という話です。

なぜこの章があるのか

チームが認証、トランスポート、セッション状態、エラー・リトライ、構造化ロギング、その他デモを運用可能サービスから分けるたくさんの小さなディテールを配線し終わるころには、「MCPをHTTPで話すだけ」が、自前の小さなフレームワーク — 普通、既にあるフレームワークより劣るもの — になっています。工学的な問いは、公開フレームワークのどれで標準化するか、それぞれが何を正しく扱うか、状態を保つクラウドサービスとどう接続するか。この章ではランドスケープを系統立てて歩きます: Amazon Bedrock とともに Strands、その周りでステートと検索を支えるAWSサービス、Microsoft Agent Framework・LangChain・Semantic Kernel というもう一方の本番選択肢、そしてリファレンス・アーキテクチャが収束した統合パターン。狙いは勝者を戴くことではなく、各フレームワークが実際に何のためのものかを記述することです。

13.1 Strands Agents と Amazon Bedrock

Strands は2025年にAWSがリリースし、現在 Amazon Q、AWS Support、AWS Glue アシスタント内で動いているオープンソースのエージェント・フレームワークです。枠付けは意図的: Strands は モデル駆動、つまり次に何をするかを決めるループはモデル自身のツール呼び出しループで、フレームワークが上から押し付ける plannerグラフではありません。フレームワークの仕事は、そのループを本番で信頼できるものにすること — ツール起動を扱い、セッション状態を管理し、MCPClient を通じてMCPサーバーをファースト・クラスのツール源として差し込み、すべてを Bedrock のホスト型モデル・カタログ経由でルーティングすること。モデル層は差し替え可能 — Anthropic API、OpenAI、Ollama、LiteLLM — ですが、Bedrock が既定であり監査の話の出発点です。

マルチ・エージェントの話は Strands が本番での評判を稼ぐ場所です。3つの構成パターンが、前章のオーケストレーション形にきれいに対応します: Agents-as-Tools(最も単純な形、別のエージェントが呼べるツールとしてエージェントを包む)、Swarm(共有作業メモリを持つピア・ツー・ピア)、Graph(モデルが各ノードを埋める決定的トポロジ)。パターンは本番で入れ子になります。運用税は可観測性で払われ、Strands は OpenTelemetry スパンをすべてのエージェント起動・ツール呼び出し・モデル呼び出しで放出するので、4層の構成も層ごとの計装なしにログから再構築できます。Bedrock はアクセス境界の話を足します: IAMがあるエージェントが起動できるモデルを制御し、CloudTrailが使用をログします。Bedrock Guardrails はゲートウェイでコンテンツ・フィルタリングを扱い、Knowledge Bases は管理型の検索を与え、AgentCore — AWSの2025年のプリミティブ集合 — は、自前ホスティングではなく完全管理ランタイムを望むチーム向けに、メモリ・アイデンティティ・ランタイムの関心事を形式化します。

13.2 ステート層としての AWS

数時間走り、昨日何があったかを覚えるエージェントには、プロセスより長く生き延びるストレージが要ります。本番に落ち着いたパターン: ランタイム状態(現在のセッション、タスク台帳、進行中のツール呼び出し)は高速キー・アクセスのため DynamoDB に; 成果物の状態(生成された文書、中間作業物)は、セッション接頭辞のキー構造で自然なIAM境界と無償のバージョニングを得る S3 に; 意味の状態(長期記憶、過去の会話)はベクトル・ストア — 熱い作業メモリには OpenSearch Service、冷たい/アーカイブには新しい S3 Vectors — に。S3 と DynamoDB の2層分離は、早すぎる最適化ではありません。DynamoDB の項目を400KB以下に保ち、ステップごとの読み増幅を避け、各層が独立にスケールできるようにします。

ステート層の選択がシステム全体の失敗モードを決めます。状態がプロセス・メモリにしかないエージェントは再起動ですべてを失います。記憶が永続でもインデックスが同期していないエージェントは、もう見つけられない文書への参照を呼び戻します。本番配備は、これらを別々の整合性契約として扱います: 状態の原子性のためのDynamoDBトランザクション、成果物契約のためのS3 strong-read-after-write、検索がまだない文書を指せないよう、ベクトルを upsert する 前 に文書を S3 に発行するインデックス・パイプライン。セキュリティ境界も同じ配慮に値します。AWS 自身の Strands ガイダンスは、エンドユーザー・データを扱うツール呼び出しでランタイム・ロールを再利用するのではなく、STS でセッションごとの認証情報を発行するよう推奨しており — AgentCore Identity が自動化します — 破壊的アクションの背後のAWSレベルのアイデンティティが共有エージェント・ロールではなく実エンドユーザーになるようにします。規制環境では、これが唯一の許容できる答えです。

13.3 Microsoft Agent Framework、LangChain、Semantic Kernel

Microsoft とオープンソース側のランドスケープは違う形で落ち着きました。Microsoft Agent Framework は2025年後半に、Semantic Kernel と AutoGen の明示的な合併として到着しました — SK のプラグイン・モデルと .NET 統合に、AutoGen のマルチ・エージェント・パターンと Python-first の DX。MCP統合は MCPStdioTool と MCPStreamableHTTPTool で組み込み済み。Azure AI Foundry が AWS 世界の Bedrock に相当するホスト先です。Strands に対する特徴は、エージェント間の会話グラフが明示的・リプレイ可能なオブジェクトであること — 評価において莫大に重要で、失敗した会話を変更プロンプトで再実行し、ターンごとに比較できます。コストは Strands より構造を強いる点。成熟した配備では正しいトレード、探索的作業では誤ったトレード。

2026年の LangChain は2023年の LangChain とは別物です。元の chains 抽象は二次的になり、主たる面はオーケストレーション用 LangGraph と可観測性・評価用 LangSmith。強みは広さ — どのモデル、DB、ツールにもアダプタがあるように見える — と LangSmith の評価の成熟。実務者が正直に名指す弱みは表面積です: フレームワークの高水準抽象は仕事の最初の90%には素晴らしく、最後の10%は普通、各層が何をしているかをチームが理解するまで層を剥がすことでなされます。この移行を計画するチームは、抽象と戦うチームより速く出荷します。Semantic Kernel は .NET チーム向けに残ります。[KernelFunction] プラグイン・モデルは .NET サービス・ホストにきれいに収まる。3つ全体で現れたパターン: thin agent, thick MCP — 能力はプロトコル境界の向こうに住み、フレームワークは薄いプロキシになり、同じMCPサーバーが AWS の Strands、Azure の Microsoft Agent Framework、開発者のラップトップの LangChain で、移植作業なしに消費される。それがプロトコルが可能にすべく設計された軌跡です。

13.4 本番統合パターン

2025〜2026年のリファレンス・アーキテクチャに落ち着いた3つのパターンがあります。ゲートウェイ + ステート層 パターンは、管理型モデル・ゲートウェイ(Bedrock、AI Foundry、LiteLLM)をモデル層の前に、別の耐久ステート層を後ろに置きます。ゲートウェイが認証・レート制限・コンテンツ・フィルタ・監査の住む場所、ステート層が耐久性の住む場所。これが本番の既定で、特別な理由がない限り、新規配備はこれを採用すべきです — ゲートウェイを飛ばしてモデル・プロバイダを直接呼ぶチームは、四半期内に後悔します。MCP サービス・メッシュ パターンは、MCPサーバーをマイクロサービスとして扱い、mTLS、リトライ、サーキット・ブレーカを扱うメッシュ越しに公開する — 規模(10サーバー以上)か、ネットワーク層アテステーションを要する規制環境でだけコストに見合います。全部管理型 パターンは、ランタイム、メモリ、アイデンティティ、ツール・レジストリをクラウド管理型エージェント・サービス(Bedrock AgentCore、Azure AI Foundry Agent Service、Vertex AI Agent Builder)に渡す; エージェントが主たる製品ではない内部自動化と副操縦士で勝ち、エージェント が 製品で運用レバーが重要なチームでは負ける。負例として名指す価値のある2つは、everything-in-the-LLM-context(メモリが永遠に伸びるシステムプロンプトのエージェント)と framework-as-orchestrator(モデルがノード・パラメータを埋める硬いDAG)。両方とも第9章で歩いた理由で本番では死に、業界が吸収した教訓は、フレームワーク構造とモデル自由のあいだの正しいバランスは、モデルが能力を増すにつれてさらにモデル側へ移動する、ということ。

この章を踏まえて

フレームワークとクラウドサービスは、毎回プロトコル・スタックを書き直さずにMCPベースのエージェントを出荷させてくれます。それ自体は、結果のシステムが本当に 動く かどうか — エージェントが作られた仕事を解くか、負荷下でどう振る舞うか、性能の崖はどこにあるか、競合する2つのアーキテクチャを正直に比較する方法 — をチームに教えません。第14章はその問いを正面から扱います: MCP-Universe ベンチマーク、ベンチマークが暴いた2つの体系的な失敗モード(長文コンテキストの劣化と未知ツールの探索)、そしてセッションごとに作るパターンと共有セッション・プールの差がほぼ1桁になるスループット側の話。

次回 — 第14章: ベンチマーク、テスト、性能。 本物のサーバーに対する MCP-Universe、効く長文コンテキストと未知ツールの緩和、セッション・パー・リクエストと共有セッション・プールの10倍スループット差、そしてシリーズの次の行き先。