※本記事は、下記の記事で述べた思想的・感情的な内容を
技術的な観点から整理・具体化した解説版です。背景となる思想や文脈を先に理解したい方は、こちらをご覧ください。
👉 MCPはデータ触るためのチューブじゃねぇ。世界を定義するプロトコルだ。
はじめに
Anthropic が提唱する Model Context Protocol（MCP） は、
AI モデルが外部のデータやツールと安全にやり取りするための新しい標準プロトコルです。
このプロトコルでは、サーバーがクライアント（たとえば Claude や Cursor など）に対して
以下の3つの要素を提供します。
- Resources：参照可能なデータや文脈を表す読み取り専用エンティティ
- Tools：外部システムやリソースに対する操作（副作用を伴う処理）
- Prompts：モデルが活用できるプロンプトテンプレート（操作や対話の定型）
これらを組み合わせることで、AIモデルが「どんな情報にアクセスでき、どんな行為が可能か」を
明示的に把握できるようになります。
MCPの基本構成はシンプルに見えますが、特に Resource の設計 は抽象的で理解しづらい部分です。
本稿では、その Resource を「操作対象オブジェクト」として扱う設計手法と、
その技術的な意義を丁寧に解説します。
Tool 指向設計の限界
多くのMCPサーバー実装はまず「Tool（関数呼び出し）」から始まります。
たとえば、Obsidianノートにアクセスする場合、次のようなToolを定義します。
{
"name": "read_note",
"description": "Read the content of an Obsidian note",
"input_schema": { "path": "string" },
"output_schema": { "content": "string" }
}
これはシンプルで実装しやすい方法ですが、いくつかの問題を抱えます。
- 操作対象が文字列（path）で表現されるため、意味的な構造が失われる
- クライアント側が「何を選べるか」を理解しづらい
- ファイル構造に依存してしまい、抽象化が難しい
- ドメイン固有の操作（例：予約、検索、要約）を構築しにくい
結果として、Tool群が単なるRPC関数群となり、
MCPサーバーが“AI対応のAPI集”のような構造になりがちです。
Resource を「操作対象オブジェクト」として定義する
ここで発想を変え、Resource を「操作対象」そのものとして定義します。
Tool はその Resource に対する「操作（メソッド）」、
Prompt はその「ユースケース（スクリプト）」と考えます。
構造的な対応関係
| MCP 概念 | 意味的役割 | オブジェクト指向との対応 |
|---|---|---|
| Resource | 操作対象（文脈やエンティティ） | オブジェクト（インスタンス） |
| Tool | Resource に対する動作 | メソッド |
| Prompt | 一連の操作や意思決定 | スクリプト / シナリオ |
この発想により、Tool の抽象度を引き上げ、
「どんな対象に対して何ができるか」をより自然に表現できるようになります。
具体例：会議室予約システムをMCPで構築する
ここでは、Obsidian ノートを永続化ストレージとして利用する「会議室予約システム」を例にします。
1. Resource 定義
各会議室を Resource として登録します。
{
"uri": "meetingroom:/rooms/A",
"name": "Room A",
"mimeType": "text/markdown",
"metadata": { "capacity": 6, "floor": 4 }
}
URI は論理名（meetingroom:/rooms/A）として扱います。
内部実体は Obsidian の roomA.md ですが、クライアントは実体を知らずに利用できます。
この設計によって、実際のストレージ構造を意識しなくても操作可能になります。
2. Tool 定義
次に、Resource に対する操作を Tool として定義します。
{
"name": "reserve_room",
"description": "Reserve a meeting room",
"input_schema": {
"room": "string",
"date": "string",
"start": "string",
"end": "string",
"by": "string"
},
"output_schema": { "status": "string" }
}
room フィールドには Resource の URI を指定します。
たとえば "room:/A" です。
これにより、Tool はパス文字列ではなく 意味的対象（Resource） を操作できます。
3. Prompt 定義
最後に、複数の Tool を組み合わせて実現するユースケースを Prompt として定義します。
{
"name": "available_rooms_on",
"description": "List all available rooms on the given date",
"args": { "date": "string" },
"calls": ["get_room_schedule", "filter_available"]
}
Prompt を通して LLM は、Tool を組み合わせてドメイン的な操作を実行できます。
クライアントにとっては「日付を指定して空き部屋を探す」という自然な行為として扱えます。
Resource 抽象化による技術的メリット
1. クライアント側の「発見性」向上
Resource 一覧を提供することで、クライアント（エディタやエージェント）が
選択可能な対象を明示的に把握できます。
UI 側で “Add to context” や “Select resource” といった操作が実装可能です。
2. 安全なアクセススコープの提供
Tool は自由度が高く、副作用を伴うことも多いですが、
Resource は スコープ付き読み取り専用エンティティ として扱えるため、
安全な権限境界を提供できます。
3. 実装分離と拡張性
Resource の URI を抽象化すれば、バックエンドを変更しても
上位の Tool / Prompt 層には影響を与えません。
たとえば、Obsidian から Notion に移行しても同じ URI スキームを維持できます。
4. 永続化・キャッシュ・履歴管理への応用
Resource は読み取り専用であるため、サーバー側でキャッシュ・インデックス・履歴を
保持しやすくなります。
これにより、Tool の出力や検索結果を Resource として再利用できるようになります。
Resource = “意味のあるブックマーク”
抽象化というと難しく聞こえますが、実際には Resource は「意味的なブックマーク」 です。
resource:/notes/recent
resource:/favorites/meetings
resource:/searches/last
サーバーが永続ストレージを持っていれば、これらを実体的なノート・検索結果・履歴として管理できます。
つまり Resource は、**単なるファイル参照ではなく「文脈を保存する仕組み」**でもあります。
MCP の設計思想との整合性
MCP の設計は一見折衷的ですが、
背後には以下のような明確な設計思想が流れています。
| 概念 | ルーツ | 意図 |
|---|---|---|
| Resource | REST / リソース指向設計 | 「存在」をURIで表し、文脈を共有する |
| Tool | RPC / LSP | 副作用を伴う操作を統一的に呼び出す |
| Prompt | Semantic Interface / Agentic AI | 意図をテンプレート化してモデルが理解できる形にする |
MCP はこれらを安全に統合することで、
LLM と外部世界をつなぐ「文脈の通信層」として機能します。
まとめ
- MCP の Resource は「データ」ではなく「存在」を表す。
- Resource を定義することで、Tool をより高レベルな操作（メソッド）として設計できる。
- Prompt はその操作をユースケースとして組み立てる役割を持つ。
- この3層により、MCP サーバーは単なるデータゲートウェイではなく、意味を扱うアプリケーション層となる。
MCP の真価は「データにアクセスすること」ではなく、
**「世界をどのように定義し、操作するか」**にあります。
Resource を軸に設計することで、MCP サーバーは
AI モデルと人間が共有できる “意味的宇宙” の構築装置になります。
（執筆：Nori / 2025年 ― Resource設計とMCPの抽象構造）