はじめに
この記事は、QiitaのModel Context Protocol(以下、MCP)解説シリーズの第4回です。
前回は、MCPの通信フローを図解で理解しました。今回は、MCPの中核をなす3つの機能、Resources、Tools、そしてPromptsが、具体的にどのように活用されるかを実例とともに学びます。
📚 Resources(リソース):構造化されたデータアクセスを提供する
Resourcesは、MCPサーバーが管理するデータへの統一的なアクセス方法を提供する機能です。ファイル、データベースレコード、API応答など、様々な形式のデータを抽象化してLLMクライアントに提供します。
従来の課題
従来のLLM活用では、以下のような問題がありました:
- ファイル全体をプロンプトに含める必要があり、トークン制限に達しやすい
- データの一部だけが必要な場合でも、全体を処理するため非効率
- データソースごとに異なるアクセス方法を実装する必要がある
MCPでの解決
MCPのResourcesは以下の特徴を持ちます:
- 統一されたインターフェース:異なるデータソースを同じ方法でアクセス
- メタデータのサポート:データの構造や内容の説明を提供
- 効率的なアクセス:必要な部分のみを取得可能
実例:ドキュメント管理システムとの連携
シナリオ: 複数のプロジェクト文書から特定の情報を抽出
ユーザー: 「Q3のプロジェクト進捗から、遅延しているタスクをリストアップして」
MCPの動作フロー:
-
Resource一覧の取得
- MCPサーバーは利用可能なResourcesのリストを提供
- 例:
project/q3/status.json
,project/q3/tasks.csv
,project/q3/reports/*
-
メタデータの確認
{ "uri": "project/q3/tasks.csv", "name": "Q3 Task List", "description": "Third quarter task tracking data", "mimeType": "text/csv" }
-
選択的なデータ取得
- LLMクライアントは
tasks.csv
のResourceを要求 - MCPサーバーはCSVデータを構造化された形式で返却
- LLMクライアントは
-
結果の処理
- LLMは取得したデータから遅延タスクを識別し、回答を生成
🛠️ Tools(ツール):外部システムとの動的な相互作用
Toolsは、LLMが外部システムに対してアクションを実行するための機能です。単なるデータ取得を超えて、システムの状態を変更したり、計算を実行したりできます。
従来の課題
Function Callingでは以下の制限がありました:
- 各LLMプロバイダーごとに異なる実装が必要
- ツールの発見と管理が複雑
- エラーハンドリングが統一されていない
MCPでの解決
MCPのToolsは以下を提供します:
- 標準化されたツール定義:JSON Schemaベースの統一フォーマット
- 動的なツール発見:実行時に利用可能なツールを確認
- 型安全な実行:入力/出力の型が明確に定義される
実例:データベース操作の自動化
シナリオ: 在庫管理システムとの連携
ユーザー: 「商品コードABC-123の在庫を確認し、10個以下なら自動発注して」
MCPの動作フロー:
-
利用可能なToolsの確認
{ "name": "check_inventory", "description": "Check current inventory level", "inputSchema": { "type": "object", "properties": { "product_code": {"type": "string"} } } }
-
在庫確認の実行
// Tool呼び出し { "tool": "check_inventory", "arguments": {"product_code": "ABC-123"} } // 結果 { "current_stock": 7, "location": "Warehouse A" }
-
条件に基づく次のアクション
// 自動発注Tool呼び出し { "tool": "create_purchase_order", "arguments": { "product_code": "ABC-123", "quantity": 50, "priority": "normal" } }
-
結果の報告
- LLMは実行結果を整理してユーザーに報告
💬 Prompts(プロンプト):再利用可能なタスクテンプレート
Promptsは、MCPにおけるタスクテンプレート機能です。よく使うプロンプトをパラメータ化して保存し、動的に値を埋め込んで実行できます。
従来の課題
プロンプト管理における問題:
- 同じようなプロンプトを何度も書き直す必要がある
- プロンプトのバージョン管理が困難
- チーム間でのプロンプト共有が難しい
MCPでの解決
MCPのPromptsは以下を実現:
- テンプレート化:変数部分をパラメータとして定義
- 中央管理:MCPサーバーでプロンプトを一元管理
- コンテキスト連携:ResourcesやToolsの結果を自動的に組み込み
実例:定型レポート生成の自動化
シナリオ: 週次売上レポートの作成
ユーザー: 「今週の売上サマリーを作成して」
MCPの動作フロー:
-
Promptテンプレートの取得
{ "name": "weekly_sales_summary", "description": "Generate weekly sales report", "arguments": [ {"name": "week_start", "description": "Start date of the week"}, {"name": "week_end", "description": "End date of the week"} ] }
-
テンプレートの内容
以下のデータを基に週次売上レポートを作成してください: 期間: {week_start} から {week_end} 売上データ: {sales_data} 前週比較: {week_over_week} 以下の項目を含めてください: 1. 売上高の推移 2. トップ5商品 3. 改善提案
-
動的なデータ取得と組み込み
-
sales_data
: Toolを使って売上データベースから取得 -
week_over_week
: 前週データとの比較計算結果 - パラメータを埋め込んで完全なプロンプトを生成
-
-
レポート生成
- 完成したプロンプトでLLMが構造化されたレポートを生成
🔄 3つの機能の連携例:顧客サポートの自動化
実際のユースケースでは、これら3つの機能が連携して動作します。
シナリオ: 顧客からの技術的な問い合わせへの対応
顧客: 「注文番号ORD-2024-789の配送状況を教えてください。また、商品の設定方法も知りたいです。」
統合された処理フロー:
-
Promptの活用
-
customer_inquiry_handler
プロンプトテンプレートを使用 - 顧客対応の基本フォーマットを適用
-
-
Toolの実行
-
order_tracking
Toolで配送状況を確認 - 注文情報と配送業者の追跡情報を取得
-
-
Resourceの参照
-
manuals/product_setup.pdf
Resourceから設定手順を取得 - 該当する商品の設定ガイドセクションを抽出
-
-
統合された回答の生成
お問い合わせありがとうございます。 【配送状況】 注文番号: ORD-2024-789 現在のステータス: 配送中 予定到着日: 2024年10月15日 【商品の設定方法】 1. 電源を接続します 2. 初期設定ボタンを3秒間押します 3. スマートフォンアプリで設定を完了します (詳細な手順書を添付しました)
🎯 まとめ
MCPの3つのコア機能は、それぞれが独立した役割を持ちながら、シームレスに連携します:
機能 | 役割 | 使用場面 |
---|---|---|
Resources | データへの統一的アクセス | ファイル、DB、APIからのデータ取得 |
Tools | 外部システムの操作 | データ更新、計算実行、API呼び出し |
Prompts | タスクテンプレート | 定型処理、レポート生成、ワークフロー |
これらの組み合わせにより、LLMは単なる対話エージェントから、実際の業務システムと連携して価値を生み出すインテリジェントなアシスタントへと進化します。
こちらの記事が役に立ったと思ったらいいね👍かストックをお願いします。励みになります。
次回予告
Day 5では、いよいよMCP開発の実践に入ります。開発環境のセットアップから、最初のMCPサーバーの実装まで、ハンズオン形式で解説します。Node.jsとPythonの両方のサンプルコードを用意していますので、お楽しみに!