## MCPの土台を理解する：LLMの知識を拡張する「リソース」と「プロンプト」の役割
はじめに
こんにちは。
本記事では、Web開発の知識を土台として、MCPサーバーの基本機能である**『リソース』と『プロンプト』の役割を解説します。
さらに、これらの機能と共通点を持つRAGの知識を深掘りし、学習を進めているGNNに関連して、最新のGraphRAG**の概念についても整理します。
Web開発におけるクライアント・サーバーモデルやプロトコルの知識が、MCPのアーキテクチャを理解する上で非常に役立つことを実感しています。
本記事では、MCPサーバーの基本的な機能であるプリミティブのうち、特に**「リソース (Resource)」と「プロンプト (Prompt)」に焦点を当て、その役割と、データ拡張技術であるRAG**との共通点や違いについて解説します。
1. LLMを「補助」するプリミティブ：リソースとプロンプト
MCPは、AIエージェントに自律的な機能（ツール呼び出しなど）を提供するプロトコルですが、今回学習した「リソース」と「プロンプト」は、よりLLMの推論を補助するためのコンテキスト提供に特化した機能です。
これは、外部の情報を検索・活用してLLMの生成を強化する**RAG（Retrieval-Augmented Generation）**のアプローチと多くの共通点を持っています。
1.1. リソース（Resource）：固定情報の知識拡張
リソースは、MCPサーバーがクライアント（LLM）に対して公開している読み取り専用のコンテンツです。
| 項目 | 特徴 | Web技術との類似点 |
|---|---|---|
| 役割 | 社内マニュアルや特定のドキュメントなど、LLMの知識外の固定情報をコンテキストとして提供し、LLMの回答範囲を拡張します。 | |
| 構造 | URI (Uniform Resource Identifier) 形式で定義され、LLMは必要なリソースを自己判断でリクエストします。 | Web上のファイルやAPIへのアクセスに使うURL/URIと同じ仕組みです。 |
| RAGとの違い | リソースは「固定の構造化されたデータ」を提供します。対して、一般的なRAGは検索によってコンテキストを「動的に変更」するケースを指すことが多いです。 | リソースは、静的コンテンツ（例：事前に用意されたドキュメント）の提供に近いと言えます。 |
リソースは、Webにおける静的なリポジトリ（ドキュメント保管庫）のような役割を果たし、LLMが自分で必要な情報を探しに行けるようにするための仕組みなのです。
1.2. プロンプト（Prompt）：入力の標準化と効率化
プロンプトは、MCPサーバーにて定義された、再利用可能な入力テンプレートを提供するプリミティブです。
| 項目 | 特徴 | Web技術との類似点 |
|---|---|---|
| 役割 | ユーザーが毎回入力する「以下の文章を英訳して」といった枕詞や指示文をショートカットし、LLMへの入力効率を高めます。 | |
| 効果 | ユーザーの入力体験を標準化し、LLMに毎回正確な指示を与えることで、安定した応答品質を担保します。 | Webアプリのフォームにおける、入力補助やテンプレート機能に相当します。 |
2. RAGをさらに強化する構造化データ：GraphRAGの基本
前のセクションでは、LLMの推論を補助するために、外部の知識ベースを活用するRAG（Retrieval-Augmented Generation）は、固定された構造化コンテンツ提供の役割に共通点があることを確認しました。
ここでは、最近のポストで学習を進めているGNNに関連して、この構造化データの力を最大限に引き出し、RAGの性能と説明可能性を劇的に向上させる技術である「GraphRAG（Knowledge Graph-Enhanced RAG）」の基本について解説します。
2.1. 知識グラフ（Knowledge Graph）とは
GraphRAGの中核となるのが**知識グラフ（KG）**です。知識グラフは、エンティティ（実体）とその属性、そしてそれらの間のリレーションシップ（関係）を構造的に表現したデータ構造です。
KGは、顧客サポートのトランスクリプトのような非構造化データと、製品カタログやユーザーデータベースのような構造化データの双方を格納できる、高い汎用性を持っています。これにより、KGは、構造化データと非構造化データの両方に対応するセマンティックなフレームワークを提供します。
ノード（エンティティ）とリレーションシップ（関係）を用いてデータを表現することで、LLMに対してより正確でコンテキスト豊かな、相互に関連付けられた情報検索を可能にします。
2.2. GraphRAGがLLMの制限を克服する仕組み
RAGは、LLMが抱える「知識カットオフ」や「ハルシネーション（嘘の生成）」、「古い情報」といった制限を克服するために、外部の知識ベースから関連情報を取り出し、それをコンテキストとしてLLMのプロンプトに提供するワークフローです。これにより、LLMの回答が事実に根拠づけられ、精度が向上します。
GraphRAGは、このRAGの知識ベースとして知識グラフを統合するアプローチであり、RAGシステムに対し、精度、パフォーマンス、追跡可能性を向上させるという目的を持ちます。
特に、知識グラフが役立つのは、以下のような、従来のRAG（主に非構造化データに焦点を当てたもの）では対応が困難な構造的かつ複雑なクエリです。
• 構造的クエリへの対応: 質問の回答に、データのフィルタリング、カウント、または集計といった操作が必要な場合、テキスト埋め込みによる検索（ベクトル検索）だけでは不十分です。知識グラフの構造を利用することで、これらの操作を正確かつ効率的に実行できます。
• 文脈豊かなデータの提供: 知識グラフは、テキスト内のエンティティをグラフノードにリンクしたり、構造化された検索結果にソースの文章を付加したりするなど、構造化データと非構造化データを同じフレームワーク内で融合させます。これにより、幅広い種類の質問に対して効率的かつ正確に回答できるようになります。
LLMを知識外の情報で補助するという点において、GraphRAGは、MCPのリソースプリミティブが持つ「固定の構造化された知識をURIで提供する」役割を、より動的で複雑なデータ構造を扱えるレベルに拡張したものだと言えるでしょう。GraphRAGは、LLMを構造化データで根拠づけるための包括的なガイドを提供することを目的としています。
| 技術 | 知識ベースの特性 | 主な役割 |
|---|---|---|
| RAG | 主に非構造化テキスト（ドキュメント、Web検索結果など） | LLMのハルシネーションや知識の古さを克服 |
| GraphRAG | 知識グラフ（構造化データと非構造化データの両方） | 構造的クエリへの対応、回答の精度、説明可能性の向上 |
| MCP リソース | 固定の構造化コンテンツ（ドキュメント、マニュアルなど） | LLMの知識外の固定情報をURIで提供し、知識を拡張 |
3. Webアプリの知識がMCP理解を加速させる
現在、Webアプリの学習で得ている知識は、MCPを理解するための非常に強力な土台となっています。
- クライアント・サーバーモデル: Webでいうブラウザ（クライアント）とWebサーバー（サーバー）の関係は、MCPのホスト・クライアントとMCPサーバーの関係と構造的に共通しています。
- プロトコル（HTTP）: Webの通信を支えるHTTPは、MCPの通信（トランスポート）においてもStreamable HTTPとして採用されています。リソースのURI形式も、このWebの標準規格に則っています。
LLMを補助するリソースやプロンプトといった機能も、結局は**Web技術をベースとした統一された規格（プロトコル）**の上で成り立っていると捉えると、MCPが目指す「標準化」の意図が明確に見えてきます。
まとめ
「やさしいMCP入門」を通じて、MCPサーバーのプリミティブであるリソースとプロンプトが、LLMの知識を拡張し、ユーザーの入力効率を高めるための重要な役割を担っていることが分かりました。
特に、これらがRAGと類似しつつも、「固定の構造化データ」をURIで提供するという点でWeb技術と深く結びついていることが、大きな学びでした。
今後もWeb開発の知識とMCPの知識を組み合わせ、それぞれの理解を相乗的に深めていきたいと思います。
参考文献
- やさしいMCP入門
Discussion