MCPリソースとツール：違いと使い分けは？

Model Context Protocol（MCP）は、AIアプリケーションがモデルを外部のコンテキストや機能と接続するための標準的な方法を提供します。MCPサーバーを構築する開発者にとって、最も重要な設計上の決定は、一見すると単純なことが多いです。機能をリソースとして公開すべきか、それともツールとして公開すべきか、という点です。

この区別は、エージェントが情報をどのように発見するか、いつトークンを消費するか、何を変更できるか、そしてユーザーがリスクをどのように評価するかを左右します。不適切にモデル化された機能は、統合を理解しにくくする可能性があります。静的な参照データが不要な関数呼び出しになったり、重大なアクションが無害なコンテキストであるかのように見えたりします。

実用的には、MCPリソースは、アプリケーションがAIシステムに提供できる読み取り専用の情報を提供します。MCPツールは、モデルが要求できる実行可能な操作を公開します。この境界を理解することは、信頼性が高く、安全で、トークン効率のよいMCPサーバー開発の基礎です。

MCPでリソースとツールの区別が重要な理由

AIエージェントには、情報と行動する能力の両方が必要です。ただし、情報の取得とアクションの実行では、信頼モデルが異なります。

モデルは、どのクエリが可能かを理解するためにデータベーススキーマを必要とする場合があります。その後、承認済みのクエリを実行するための別の機能が必要になることがあります。両者を同じ種類の統合として扱うと、意図が不明確になり、権限管理が複雑になり、過剰なコンテキスト使用につながる可能性があります。

リソースとツールの区別が重要なのは、次の点を明確にするためです。

• エージェントの動作： モデルは、操作を要求することとは別に、安定したコンテキストを調査できます。
• セキュリティ境界： 読み取りアクセスと書き込みアクセスは、それぞれ異なる方法でレビュー、範囲設定、管理できます。
• ユーザーの信頼： ユーザーは、エージェントがシステムについて学習しているのか、そのシステムを変更しているのかを区別できます。
• トークン効率： 関連するコンテキストは、すべてのプロンプトに無差別に挿入するのではなく、必要なときに取得できます。
• サーバー設計： 機能の命名、文書化、テスト、保守が容易になります。

MCPは、利用可能なすべてのリソースが自動的にモデルコンテキストに配置されることを意味するわけではありません。リソースはMCPの機能モデルを通じて利用可能ですが、それらをいつどのように提示または読み取るかはホストアプリケーションが決定します。利用可能な情報が広範囲、機密性が高い、または読み込みコストが高い場合、このホスト制御のアプローチは不可欠です。

MCPリソースとは？

MCPリソースは、MCPサーバーによって公開される、URIベースの読み取り専用コンテキストです。AIシステムがタスクを完了する際に、調査、要約、推論、または引用する必要がある情報のために設計されています。

リソースは、単なる任意のファイルや汎用APIエンドポイントではありません。Model Context Protocolでは、これは発見可能なコンテキストデータの単位であり、通常はURIで識別されます。サーバーは、ドキュメント、構成、スキーマ、プロジェクトメタデータ、ナレッジベースのページ、または生成されたステータス情報を表すリソースを公開できます。

一般的な例としては、リポジトリのアーキテクチャガイド、`README`ファイル、OpenAPIスキーマ、データベースのテーブル定義、デプロイメント環境の現在の構成などがあります。これらは、エージェントが作業を提案または実行する前に、システムの状態とルールを理解する助けとなるため有用です。

プロトコルレベルでは、サーバーは`resources/list`で利用可能なコンテキストを通知できます。クライアントはその後、`resources/read`を通じて特定の項目を取得できます。この分離により、ホストとエージェントは、コンテンツ自体を読み込む前に何が利用可能かを確認できます。

リソースは、既存の安定した情報から回答を導き出すべき場合に特に有用です。たとえば、未知のサービスをレビューするエージェントは、統合を提案する前に、そのサービスのAPI契約を含むリソースを読み取ることがあります。リソースは証拠とコンテキストを提供しますが、変更を実行するものではありません。

MCPツールとは？

MCPツールは、モデルがMCPサーバーを介して発見し、呼び出すことができる実行可能な機能です。これらは操作、つまりエージェントが接続先のシステムに実行を依頼できるタスクを表します。

ツールは、APIリクエストの実行、課題の作成、デプロイメントチェックの実行、レポートの生成、メッセージの送信、データベースへの書き込みなどを行うことができます。多くのツールには副作用がありますが、副作用は必須ではありません。たとえば、読み取り専用のデータベースクエリであっても、入力、実行ロジック、構造化された結果を持つ操作である場合は、ツールとして正しくモデル化できます。

サーバーは`tools/list`を通じてツール定義を公開します。各定義では、明確な名前、説明、入力スキーマを伝える必要があります。モデルは、ツールが想定する入力に一致する引数を指定して、`tools/call`を通じて選択した機能を呼び出します。

主要な設計原則は、ツールがサーバーに作業の実行を依頼するということです。その出力はデータの場合もありますが、そのデータは直接アドレス指定可能なコンテキスト成果物ではなく、実行の結果です。

たとえば、`create_linear_ticket`は、外部ワークフローに新しいチケットを作成させるため、ツールです。サーバーが指定された環境およびサービスパラメータを使用してライブシステムを照会する必要がある場合、`get_deployment_status`もツールになり得ます。どちらの操作にも明示的な呼び出しが必要ですが、状態を変更するのが必ずしも一方だけとは限りません。

MCPリソースとツール：主な違い

この表は実用的な境界を捉えています。リソースは情報を記述または公開し、ツールは動作を実行します。適切に設計されたMCPサーバーでは、両方の機能が同じ広範なワークフローをサポートしている場合でも、この区別は明確に保たれます。

リソースとツールの選び方

まず1つの質問から始めましょう。エージェントは情報を参照する必要があるのか、それともサーバーに操作を実行してもらう必要があるのか。

情報が読み取り専用で、自然にアドレス指定でき、コンテキストとして有用である場合は、リソースを使用します。設定ファイル、製品仕様、ポリシー文書、データベーススキーマは、通常このモデルに適しています。クライアントは項目を検出し、関連性があるかどうかを判断し、ビジネスロジックをトリガーせずに読み取ることができます。

タスクに入力、実行、または静的コンテキストとして表現できない結果が必要な場合は、ツールを使用します。サポートチケットの作成、フィルタリングされたレポートの取得、ビルドの開始、レコードの更新は、ツールとして提供するべきです。

一部のワークフローでは、両方のプリミティブが必要です。リリース管理の統合を考えてみましょう。

1. リリースポリシーと環境定義をリソースとして公開する。2. 選択したサービスのライブデプロイメントステータスを取得するツールを提供する。3. 承認済みのデプロイメントをトリガーする別のツールを提供する。

この設計により、エージェントはまずポリシーと環境の制約を理解し、次に現在の運用データを要求し、その後で影響のあるアクションをリクエストできます。この分離により、ユーザーは監査しやすくなり、プロダクトチームはセキュリティを確保しやすくなります。

すべてのクエリをリソースにしないでください。情報が動的、パラメーター化されている、または計算コストが高い場合は、通常ツールの方が適切です。逆に、URIベースのリソースの方が目的を明確にできる場合、単純で安定した参照コンテンツをツールでラップすることは避けてください。

実践的なMCPサーバー設計の例

リポジトリのドキュメントサーバーは、コーディング標準、アーキテクチャ決定記録、サービス所有者マップをリソースとして公開できます。これらの項目は、予測可能なアドレスを持つ有用な参照資料です。`search_repository_docs` 機能は、キーワードを受け取り、大規模なドキュメントコーパス全体に対して対象を絞った検索を実行する場合、ツールにできます。

データベース統合では、テーブルスキーマと承認済みデータディクショナリがリソースとして適しています。`run_readonly_query` 機能は、クエリまたは構造化フィルターを受け取り、それらを検証し、ライブシステムに対して実行して結果を返すため、ツールとしてモデル化する方が適切です。別個の書き込みツールを、同じ曖昧なインターフェースの背後に隠してはなりません。

プロジェクト管理の統合も同じパターンに従います。リソースは、スプリントボードのワークフロー定義や課題ラベルの分類体系を提供できます。ツールは、チケットの作成、ステータスの更新、担当者の割り当てを行えます。この情報はエージェントが十分な情報に基づくリクエストを行うのに役立ち、ツールはリクエストされた変更を実行します。

レポート生成も有用なエッジケースです。固定の四半期レポートテンプレートはリソースにできます。`generate_quarterly_report` 操作は、期間を受け取り、ライブデータを選択し、ビジネスロジックを適用して出力を作成するため、ツールです。生成されたレポートは、他のエージェントが参照すべき安定した成果物になった場合、後でリソースとして公開できます。

技術作業からプレゼンテーションへのワークフローにPi MCPを活用する

Presentation Intelligence（Pi）は、技術作業を明確なステークホルダー向けコミュニケーションに変換する必要があるチーム向けに、MCPワークフローをサポートします。Pi MCPは、コードエディター、ソース管理、データベース、その他のMCPサーバーの代替ではありません。Pi MCPは、デリバリープロセスにおける明確に異なる段階、つまり承認済みの技術コンテキストを構造化されたビジネス向けプレゼンテーションへ変換する工程に対応します。

1. ビジネスロジックはスライドのスタイリングより先に来る

Claude CodeのようなAIコーディングまたはエージェント環境では、チームは強力なプレゼンテーションの素材をすでに利用できることがよくあります。技術概要、プロジェクトノート、アーキテクチャの説明、リリースサマリー、コードベースから得られた知見などです。課題は、その素材を、つながりのないスライドの集まりではなく、対象者に適したストーリーへと変換することです。

Pi MCPを使用すると、エージェントワークフローは定義済みの概要または承認済みのコンテキストをPresentation Intelligenceに渡し、ロジックを優先したプレゼンテーション構造を作成できます。これは、ストーリーラインが基盤となる実装と同じくらい信頼できるものでなければならない、エンジニアリングロードマップの更新、経営層向けプロジェクトレビュー、技術営業資料、コンサルティングレポート、製品ローンチのストーリーに有用です。

2. 既存のワークフロー内で生成状況を可視化する

プレゼンテーションの作成では、開発者やプロダクトチームが作業環境を離れ、技術ノートを手作業で再編成し、別の制作プロセスを繰り返し確認する必要が生じる場合があります。Pi MCPにより、チームは既存のエージェントワークフロー内でプレゼンテーション作業を開始し、生成の進行状況を追跡できます。

この継続性は、資料が変化するプロジェクトコンテキストに依存する場合に重要です。チームは、コミュニケーションを後回しにすることなく、概要を洗練し、対象者のニーズを明確にし、プレゼンテーションワークフローを監視できます。PiのマルチエージェントAIアプローチは、チームが共有するコンテキストを制御し続けながら、複雑な入力からプロフェッショナルな構成と高品質なビジネスプレゼンテーション出力への移行をサポートします。

安全でトークン効率の高いMCP統合のベストプラクティス

優れたMCPサーバー開発は、限定的で理解しやすい機能から始まります。リソースは、エージェントが本当に必要とする情報に限定してください。大規模で区別のないナレッジダンプは、意思決定を改善せずにトークンを消費する可能性があります。意味のあるURI、明確な説明、予測可能な境界を持つ、より小さなリソースを優先してください。

ツールには、正確な名前と明示的な入力スキーマを使用してください。`create_customer_ticket` は `manage_ticket` より多くを伝え、タイトル、優先度、顧客IDを分けるスキーマは曖昧さを減らします。エージェントが同じツールを繰り返し呼び出すことなく何が起きたかを判断できるよう、構造化され実行可能な結果を返してください。

可能な限り、読み取り操作と書き込み操作を分離してください。システムの参照と変更の両方を行うツールは、権限レビューをより困難にします。レコードの削除、外部メッセージの送信、本番環境へのデプロイメントのトリガーなど、アクションが重大な影響を持つ場合は、最小権限アクセスを適用し、ホストエクスペリエンス内で適切なユーザー確認を要求してください。

最後に、段階的開示を意識して設計してください。エージェントにはまず機能を発見させ、関連するリソースのみを取得させ、操作が必要な場合にのみツールを呼び出させます。このアプローチにより、トークンの無駄を減らし、機密データの露出を制限し、エージェントの推論経路をより理解しやすくします。

実践的な結論：コンテキストはリソース、操作はツールとしてモデル化する

MCP設計における最も信頼性の高いルールは明快です。永続的で読み取り専用のコンテキストはリソースとして公開し、実行可能でパラメーター化された作業はツールとして公開します。この境界により、セキュリティレビューが改善され、エージェントの挙動が解釈しやすくなり、有用なアクセスを犠牲にすることなくチームがコンテキスト予算を管理できるようになります。

複雑なワークフローでは、最も強力な設計は両方を組み合わせることが多いです。リソースはエージェントが必要とする事実と制約を提供し、ツールはそれらに対して行動するための慎重に管理された方法を提供します。Pi MCPは、技術コミュニケーションに同じパターンを適用し、作業がすでに行われているAI環境内にとどまりながら、チームが承認済みのプロジェクトコンテキストを構造化されたプレゼンテーションに変換できるよう支援します。