【ITニュース解説】Understanding MCP Servers: How AI Hosts Reliably Connect to Domain Systems

近年、AI、特に大規模言語モデル（LLM）の進化は目覚ましい。しかし、これらのAIアプリケーションを実際のビジネスシステムやデータベースと連携させる際には、多くの課題がある。AIが最新のデータにアクセスし、許可された操作を行うには、そのための安全で効率的な仕組みが必要となる。Model Context Protocol（MCP）は、まさにこの課題を解決するために考案されたオープンなプロトコルである。

これまで、AIアプリケーションが既存のシステムと連携するには、個別の対応が必要だった。例えば、チャットクライアントがチケットシステムと連携する場合、専用のプラグインを開発し、IDE（統合開発環境）がファイルシステムと連携する場合、直接REST APIを叩くといった具合である。このような「点と点の統合」は、それぞれが個別に動作する分には問題ないが、複数のAIアプリケーションが同じシステムと連携しようとすると、ツール記述の重複、認証経路の乱立、再利用が困難なセキュリティ設定など、保守が非常に難しい複雑な網状構造を生み出していた。チケットシステムを例にとると、顧客オンボーディングに関連するチケットの「リスク、未解決の決定、次のステップ」をAIに質問したい場合、それぞれのAIホスト（チャットクライアント、IDE、エージェントツールなど）が、チケットの検索や詳細取得のために異なる接続方法やセキュリティ処理を持つことになり、システム側での変更があった場合には全ての連携部分を修正する必要があった。

MCPは、この問題に対処するために、LLMアプリケーションを外部データソースやツールに接続するための共通の標準を提供する。その核となるのは、ホスト・クライアント・サーバーというアーキテクチャである。ホストはAIアプリケーション（チャットクライアント、IDE、エージェントツールなど）を指し、ユーザーのリクエスト、モデルのコンテキスト、ツールの選択、承認、そして最終的な回答の出力を統括する役割を担う。つまり、ホストはユーザーとモデル、そしてドメインシステムとの間の「制御境界」となる。MCPクライアントはホスト内に存在し、MCPサーバーとの間でプロトコルメッセージの仲介を行う。一方、MCPサーバーは、特定の機能を提供する専門の役割を担い、リソース、プロンプト、ツールといった形で機能を公開し、それらの呼び出しを対象システム（実際のチケットシステム、データベースなど）への操作に変換する。LLMはホスト内に組み込まれ、応答を生成したり、必要なツール呼び出しを提案したりするが、対象システムに直接アクセスすることはない。この分離こそが、MCPアーキテクチャの核心である。

MCPのリクエストの流れは、例えば「顧客オンボーディングに関連するチケットから、リスク、未解決の決定、次のステップを教えてください」というユーザーの質問から始まる。まずホストは、この質問、セキュリティ要件などのアプリケーションルール、選択されたMCPの機能などを組み合わせて、LLMが作業するためのコンテキストを構築する。この時点では、まだチケットのデータは読み込まれていない。次にLLMは、既存のコンテキストで十分であれば直接回答するか、より詳細な情報が必要な場合は、例えば「search_tickets」のような適切なツール呼び出しを提案する。この提案はまだ実行されていない。次にホストが、そのツール呼び出しを許可するかどうかを判断する。ホストのポリシーによって、どのツールが利用可能で、どの引数が受け入れられ、ユーザーの承認が必要かどうかが決まる。許可された場合、MCPクライアントはJSON-RPCメッセージとしてMCPサーバーにその呼び出しを送信する。

MCPサーバーは、受信した呼び出しに基づいてドメイン操作を実行する。この際、サーバーは自身の認証、認可、ドメイン境界、レート制限などを厳格に適用し、対象システムに対して必要な処理を行う。そして、その結果を構造化された形でホストに返す。最後にホストは、返された結果をモデルのコンテキストに戻すかどうかを決定する。これにより、LLMは許可されたチケットデータを評価し、必要であればさらに別の呼び出しを提案したり、最終的な回答を生成したりする。このように、MCPはLLMと対象システムを直接つなぐ「トンネル」ではなく、ホストがモデルの提案を制御し、サーバーがドメインとセキュリティの境界を強制する、明確に管理された情報経路を提供する。

MCPサーバーが提供する主な要素は次の五つである。まず「ディスカバリ」により、ホストはサーバーがどのような機能を提供しているか（リソース、プロンプト、ツール）を知ることができる。これにより、ホストはサーバーの機能を正しく理解し、利用を開始できる。次に「リソース」は、ファイル、データベーススキーマ、アプリケーション固有の情報といったコンテキストオブジェクトを指す。各リソースはURI（統一資源識別子）で識別され、ホストはこれらを読み取り、モデルに提供するかどうかを決定する。これにより、必要な情報を適切にモデルに提示できる。

三つ目は「プロンプト」である。これは再利用可能でパラメータ化された作業指示テンプレートを意味する。例えば「{トピック}に関するチケットを分析し、リスク、未解決の決定、次のステップにまとめてください」といったテンプレートをサーバーが提供し、ホストが取得してモデルコンテキストに追加できる。これは単なるテキストではなく、安定した名前、期待されるパラメータを持つことで、異なるAIホストが同じドメイン固有のテンプレートを利用できるようになる。ただし、プロンプト自体が分析を実行するわけではなく、あくまで「指示」を提供するものだ。

四つ目は「ツール」で、これは実行可能なドメイン機能である。データベースの照会、APIの呼び出し、計算など、特定の操作を行うための関数である。LLMは利用可能なツールを発見し、コンテキストに基づいて適切なツールとその引数を提案する。例えば「search_tickets」「get_ticket」「list_ticket_comments」のようなツールが考えられる。ツールは、その目的や期待されるパラメータが明確に記述されているため、ホストとLLMの両方が何ができるかを理解できる。しかし、ツールの実行はモデルの提案に基づき、ホストとサーバーの制御下で行われる。特に、読み取り専用のツールから開始し、書き込み操作を行うツールについては、明確なスコープ、プレビュー、承認、監査などのセキュリティ対策が不可欠である。

最後に「伝送（トランスポート）」は、ホストとサーバーがメッセージを交換するための技術的経路を指す。現在の仕様では、主に二つの方法がある。一つは「stdio」で、ホストがMCPサーバーをローカルプロセスとして起動し、標準入出力を通じてメッセージをやり取りする方法である。これはローカル開発ツールなどに適している。もう一つは「Streamable HTTP」で、MCPサーバーがネットワーク上で到達可能なサービスとして動作し、ホストとサーバーがウェブ接続を通じて通信する方法である。これはSaaSやエンタープライズアプリケーションなどのリモートシステムに適している。

MCPは非常に強力なプロトコルであるが、それが全てを解決するわけではない。「MCPではないもの」も明確にしておく必要がある。MCPは既存の製品APIを置き換えるものではなく、エージェントフレームワークやワークフローエンジン、データベースでもない。また、完全なプラグインシステムやAIそのものでもない。MCPはあくまで既存のレイヤーに「共有の統合契約」を追加するものである。そして、最も重要な点として、MCPはドメインシステムのセキュリティ自体を標準化するものではない。AIホストは承認、データ共有、コンテキストへのコンテンツの受け入れを適切に設計する責任があり、本番環境のMCPサーバーは、認証、ドメイン権限、データの最小化、監査などを独自に実装する責任がある。プロトコルは境界と推奨事項を提供するが、すぐに使えるセキュリティアーキテクチャを提供するわけではない。

このように、MCPはAIアプリケーションが既存のビジネスシステムと安全かつ効率的に連携するための、共通の言語とアーキテクチャを提供する。ホストとサーバーがそれぞれの責任を果たすことで、AIは単に話すだけでなく、システムの最新データと許可された機能を使って「仕事をする」ことが可能になる。