【ITニュース解説】From REST to MCP: Building a Self-Hosted AI Agent Stack That Achieves Rapid Context Forking

大規模言語モデル（LLM）を活用したAIエージェントの構築が注目される中で、既存のITシステムとの連携には大きな課題がある。この記事では、従来のRESTやGraphQLといったAPI連携の限界を指摘し、それを解決する「Model Context Protocol（MCP）」という新しいアプローチと、AIエージェントを自己ホスト型で運用し「コンテキスト・フォーク」を実現する技術スタックについて解説する。

まず、従来のAPIとLLMの連携における問題点だが、一般的なREST APIは、特定のデータや機能にアクセスするための入り口（エンドポイント）を提供する。例えば「/users/{id}」というエンドポイントは、指定されたIDのユーザー情報を取得するための場所を示すが、この情報が「ユーザーとは何か」「どのような権限が必要か」「システム全体の中でこのユーザー情報がどのような意味を持つか」といった文脈や意味（セマンティクス）をLLMに直接伝えるわけではない。そのため、LLMが複雑なタスク、例えば「活動していないユーザーを全てアーカイブし、そのマネージャーに通知を送る」といった多段階の処理を行う場合、LLMは全てのステップを自分で記憶し、逐一APIを呼び出す必要がある。この際、LLMが一度に扱える情報の量（コンテキストウィンドウ）には限りがあり、情報が失われたり、混乱したりする「セマンティックギャップ」という問題が発生する。開発者はこの問題を回避するために、複雑なプロンプトを作成したり、脆いラッパー関数（APIの機能をLLM向けに包み込むプログラム）を書いたりするが、これらは拡張性に乏しい。

MCPはこの課題を解決するために考案されたプロトコルだ。MCPサーバーは、単なるエンドポイントではなく、「能力（Capabilities）」という形でツールをLLMに提供する。これらのツールは、その機能が自己記述的であり、入力の形式、説明、エラー処理のロジックまでが含まれる。LLMがMCPサーバーと対話する際、単に関数を呼び出すだけでなく、サーバーがエージェント（LLM）のコンテキストを能動的に管理するプロトコルに参加する。これにより、最も革新的な機能である「コンテキスト・フォーク」が可能になる。

コンテキスト・フォークとは、メインのエージェントが進行中の会話やタスクの状態（コンテキスト）を一時的に複製し、その複製された状態で別の「子エージェント」を生成してサブタスクを実行させる仕組みだ。子エージェントは親エージェントから独立してサブタスクを処理し、その結果だけを親エージェントに返す。これにより、親エージェントのコンテキストが余計な情報で汚染されることなく、複雑な処理を効率的に実行できる。例えば、ある顧客のサポート中に「この請求書がデータベースと一致するか確認して」といった要求があった場合、メインのエージェントはその時点の状況をフォークして子エージェントに「請求書検証」のタスクを任せる。子エージェントが検証を終えて結果を返せば、親エージェントはクリーンな状態で顧客との会話を続けられる。

この自己ホスト型のAIエージェントスタックを構築するには、主に三つの中心的なコンポーネントが必要となる。一つ目は「MCPサーバーアダプター」で、これは既存のRESTやGraphQLベースのコードベースとMCPプロトコルを橋渡しする役割を果たす。ビジネスロジックを書き換えるのではなく、既存の機能をMCPツールとしてラッピングする。ツールは冪等性（何度実行しても同じ結果になること）を考慮し、顧客の注文を検索するような高レベルで意味のあるツールとして公開する。二つ目は「エージェントオーケストレーター」で、これはエージェントのライフサイクル管理、ツールの呼び出し監視、そしてコンテキスト・フォークのロジックを管理する。三つ目は「ローカルベクターストア」（記事では直接言及はないが、自己ホスト型でのデータ保持に重要）だ。自己ホスト型のスタックを選ぶ利点は、データのプライバシーを確保し、ローカルでのツール呼び出しによる遅延を削減し、コンテキスト管理を細かく制御できる点にある。記事のベンチマークでは、ローカルのLLM（Llama-3-8B-Instruct）と16GBのGPUを使用した場合、コンテキスト・フォークのプロセスが約5.6秒で完了すると報告されている。この時間には、アクティブなメッセージ履歴とツール状態のシリアライズ（1.2秒）、新しいエージェントインスタンスのメモリ割り当て（0.8秒）、シリアライズされたコンテキストのLLMへの再注入（2.5秒）、子エージェントとのMCPセッション確立（1.1秒）が含まれる。

既存のREST/GraphQLエンドポイントをMCPツールへ変換するプロセスは、スキーマ抽出、ツール定義、プロトコル実装の三段階で行われる。REST APIの場合、OpenAPI（Swagger）定義を利用してリソースをツールにマッピングできる。GraphQLの場合は、その複雑さから、一般的なGraphQLクエリを実行するツールではなく、特定の目的を持つツール（例：顧客の注文を取得する）を作成し、出力はLLMが扱いやすいフラットなJSON形式に変換することが推奨される。

本システムを運用する上でのベストプラクティスとしては、エラーハンドリングと再試行機構の確立が挙げられる。LLMは時折、無効なJSONを生成したり、誤ったパラメータでツールを呼び出したりするため、厳密なバリデーションと、LLMが解釈できる構造化されたエラー応答が不可欠だ。また、コンテキストウィンドウの管理も重要であり、たとえフォーク機能があっても、古いメッセージを要約する「スライディングウィンドウ」戦略などを採用して、コンテキストの肥大化を防ぐ必要がある。セキュリティ面では、MCPツールが機密データにアクセスする可能性があるため、サーバーをサンドボックス化されたコンテナで実行し、最小限の権限を持つAPIキーを使用するなど、厳重な分離が求められる。

MCPはOpenAIのファンクション呼び出しとは異なり、特定のプロバイダに依存しないオープンなプロトコルである。ツールを標準化された方法で公開し、より豊かな意味情報（セマンティクス）を提供するため、異なるLLMバックエンド間での移植性や柔軟性が高い。

結論として、RESTやGraphQLといった既存のAPIをMCPツールに変換し、自己ホスト型のAIエージェントスタックを構築することで、システムは単なる受動的なデータソースから、AIエージェントにとってより能動的で意味のあるインターフェースへと進化する。コンテキスト・フォーク機能によって、複雑なエージェントのワークフローを、コンテキストウィンドウの制約に縛られずに管理できるようになる。これは、AIエージェントがより賢く、より堅牢で安全なシステムへと進化するための重要な一歩である。