第8章 — アーキテクチャ的デプロイメント・レイアウト
LLM Primer IV: MCPで設計するAI認知 のウォークスルー第8回です。同じオーケストレーション・ロジックの2つのシステムが、本番では大きく違うふるまいを示すことになります。「モデルが実際にどこで走るか」という問いに3通りの答え方があり、それぞれが違うレイテンシ、コスト、セキュリティの天井を設定するからです。
なぜこの章があるのか
第6章と第7章はエージェントの協調を規定しました。同じくらいシステムの実世界の挙動を決める問いには触れていません: 各エージェントはどこで走り、言語モデル・MCPサーバー・ツールはネットワーク上でどう配置されるか。本章のアーキテクチャ的判断は、すべてのリクエストとすべてのドルに触れます。2025年から2026年にかけてMCPエコシステムには3つの大きく異なるレイアウトが現れ、3つのうちのどれも普遍的には正しくありません。それぞれは違う制約の組み合わせに最適化されていて、選択にはエンジニアが選ぶ前に言語化できるべき帰結があります。
8.1 再利用可能AIエージェント: モデルをサーバーに同梱
1つ目のレイアウトは、言語モデルをMCPサーバーと一緒に同梱し、その組み合わせをひとつのブラックボックス能力として公開します。クライアントは「このプルリクをレビューして」とツールを呼ぶように呼び、舞台裏ではエージェント・ループ全体がサーバー側で走り、モデルを呼び、内部ツールを呼び、最終出力だけを返します。組織が専門化されたエージェント — リサーチ、コードレビュー、財務分析 — を作り、それぞれの内部を理解せずに多くのホスト・アプリケーションへ公開したくなったところから現れたパターンです。
強みは本物です。カプセル化により、エージェントの作者はクライアントから見える変化なしにモデルを差し替えたりオーケストレーションを再構成したりできます。ホスト・アプリケーション間の再利用性で、ひとつのエージェントが同じインターフェースを通してClaude Code、エンタープライズ・アプリ、顧客向けチャットボットに対応する。コストも同じくらい本物です。不透明さはデバッグを難しくします: エージェントが間違った判断をしたとき、クライアントには理由が見えません。レイテンシは積み上がります — サーバー側ループが各呼び出しで走るから。そして二重予算が構造的: エージェントの運営者は自分のモデル呼び出しを払い、クライアントは自分のものを払い、対話あたりの総コストは双方が最初に思うより高くなりえます。
マルチテナント版 — ひとつのエージェント・プロセスが多くのクライアント組織に提供する — は、固定費をテナント間で按分することで運用経済を大きく改善します。同時に、クロステナント・データ漏洩が第一級の失敗モードとして入ります。2025年に公表されたインシデントのいくつかはまさにこれで、運営者はリクエスト間の漏洩をコードレビューで捕まえることに頼らず、テナント分離をランタイムに組み込むべきです。
8.2 厳格MCP純粋: モデルはクライアントに
2つ目のレイアウトは、言語モデルを厳密にクライアント側に置きます。MCPサーバーが公開するのはデータとツールだけ — 推論は持たない。ホストがモデルを走らせ、オーケストレーション判断を行い、サーバーをコンテキスト取得とアクション実行のために呼びます。動機はプロトコル本来の設計理由: MCPは、モデルとツールのあいだに一様なインターフェースを与えることでN×Mの統合問題を解くために存在し、自前のモデルを走らせるサーバーは、プロトコルが解こうとした問題を再導入してしまう、というもの。
強みは制御と透明性です。すべてのモデル呼び出しはクライアントの計装に観測可能。クライアントはリクエストごとにモデルを選べ、プロバイダ間でフォールバックでき、モデル・コストを直接負担します — 鎖の中に2つ目のモデルがいないので二重予算はありません。クライアント側の監査ログが完全な推論連鎖を捉える必要のある規制業界では、厳格純粋は要件を曖昧さなく満たします。
コストも同じく明確です。すべての知能をすべてのクライアントが再実装する必要があり、多くのホスト・アプリを抱える組織には本物の負担。一部の能力 — マルチステップのリサーチ、反復的精錬 — はワンショットのツールに因数分解しにくく、それらを公開すると、複雑なオーケストレーションをクライアントへ押し込むか、サーバーに自前モデルを走らせて静かに純粋性を破るかになります。そしてクライアントはオーケストレーションを走らせられないといけない — 実務上はゼロから書くのではなくStrands、LangChain、Semantic Kernel、Microsoft Agent Frameworkに乗ることを意味します。
8.3 ハイブリッド: クライアント側オーケストレーションとサーバー側実行
3つ目のレイアウトは中間を取ります。クライアントがオーケストレーションし、主たる推論を走らせる; 一部のMCPサーバーは専門化された下位タスクのために自前モデル呼び出しを走らせる。最も明確な例は長時間走るディープ・リサーチ・ツールです。リサーチ結果をより広いワークフローへ畳み込みたいクライアントは、リサーチの各ステップを自分で管理したくはありません。「Xを調べて見つけたことを教えて」と呼んで合成を受け取りたい。リサーチはマルチステップ、マルチソースで、自前の内部オーケストレーションから恩恵を得ます。
ハイブリッド・パターンが効くのは、境界が意味のある縫い目に引かれているとき — 明確な入出力を持つ下位タスクで、クライアント協調なしにサーバー側知能で完結でき、ブラックボックスとして走るほうが汎用オーケストレータを通すより優れるほど専門化されているとき。リサーチ、コード解析、文書合成はこのプロファイルに合います。一般会話は合いません。
コストはアーキテクチャの複雑性です。知能が走る場所が2つになり、可観測性が境界をまたぐ必要があり、コスト帰属は純粋な2型の間に座ります。役立つ規律は、知的サーバーの数を制限し、それぞれを明確に定義された能力に集中させること。2〜3個は運用可能、12個は誰も理解できない連邦になります。ハイブリッド配備は時間とともに純粋な両端のどちらかへ進化する傾向もあり、アーキテクトは自分のハイブリッドが安定設計か遷移状態かを正直に判断すべきです。
この章を踏まえて
第III部の3章は、機構の視点からマルチ・エージェント・システムの設計空間を歩きました。まだ扱っていないのは、その下の基盤です — 各モデル呼び出しが受け取るコンテキストと、呼び出しをまたいで残るメモリ。エージェントの効きは、行動時に何が見えていて、自分が前に何をしたかをどれだけ呼び戻せるかに依存します。コンテキスト・ウィンドウは有限。メモリ・アーキテクチャは設計が必要。注意予算管理、スクラッチパッド使用、エピソード/意味記憶のパターンは、協調されたエージェントの集まりを「数時間・数日にわたって有用な仕事をするシステム」に変える基盤です。
次回 — 第9章: 注意の予算管理。 100万トークンのウィンドウが運用点ではなく天井値である理由、予算を何が食べるか、そしてMCP・RAG・ファインチューニングがそれぞれ違う形のギャップに合う場面。
