0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Model Context Protocol完全解説 30日間シリーズ- Day 3【MCP入門 #3】MCPの仕組みを図解で理解:Client-Server通信の基本フロー

Posted at

Day 3【MCP入門 #3】MCPの仕組みを図解で理解!Client-Server通信の基本フロー

この記事は、Model Context Protocol(以下、MCP)解説シリーズの第3回です。前回は、なぜMCPが従来のAPI連携よりも優れているのかを学びました。今回は、MCPが実際にどのように動いているのか、その通信フローを図解でわかりやすく解説します。

🗺️ MCPの登場人物を知ろう

MCPの通信には、主に3つの重要な要素があります。

1. Client(LLM側)

  • LLM本体(Claude、ChatGPTなど)
  • ユーザーからの指示を受け取り、MCPサーバーと通信してタスクを解決
  • 能動的に外部リソースを探索・活用する

2. Server(MCPサーバー)

  • 外部データやツールを管理する専用サーバー
  • Clientからの要求に応じて情報を提供したり、処理を実行
  • Resources、Tools、Promptsを統一的に管理

3. User(利用者)

  • LLMに質問や指示を送る人
  • MCPの存在を意識することなく、高度な外部連携を利用可能

🔄 MCPの通信フロー:2つの重要なステップ

MCPの通信は、ClientとServerがインタラクティブに情報をやり取りしながら進みます。まるで、ClientがServerに「その部屋には何がある?」と聞き、Serverが「〇〇と〇〇が使えますよ」と答える会話のようです。

ステップ1:初期ハンドシェイク(発見フェーズ)

[User] → [Client] → [Server]
         「何が利用できるか教えて」

[Server] → [Client]
「これらのResourcesとToolsが使えます」
- sales_report.pdf
- customer_database
- send_email_tool
- generate_chart_tool

詳細な流れ:

  1. Client → Server: 「利用可能なリソースとツールを教えてください」
  2. Server → Client: 管理しているResources(例:sales_report.pdfcustomer_db)とTools(例:search_databasesend_email)のリストを返す
  3. Client: この情報を受け取り、自分が利用可能な「外部の世界」を把握

この時点で、Clientは従来の知識に加えて、Serverが提供する外部リソースも認識した状態になります。

ステップ2:タスク実行フェーズ(探索・活用)

[User] → [Client]: 「最新の売上レポートを見て、第2四半期の成長率を教えて」

[Client]の思考プロセス:
「タスク解決には sales_report.pdf が必要だな...」
↓
[Client] → [Server]: 「sales_report.pdf の目次情報をください」
↓
[Server] → [Client]: 「第1章:概要、第2章:Q2分析、第3章:予測...」
↓
[Client]の判断:「成長率の情報は第2章にありそうだ」
↓
[Client] → [Server]: 「第2章のQ2分析部分を取得してください」
↓
[Server] → [Client]: 「Q2の売上は前年同期比15%増加...」
↓
[Client] → [User]: 「第2四半期の成長率は15%でした」

このフェーズの特徴:

  • 動的な情報取得: 必要な部分だけを段階的に取得
  • 自律的な判断: LLMが自ら最適なリソースやアプローチを選択
  • 効率的な処理: コンテキストウィンドウを有効活用

🔍 具体的な通信例:データ分析タスク

より具体的な例で、MCPの通信フローを見てみましょう。

シナリオ:「顧客満足度の傾向を分析して、改善提案を作成してほしい」

Phase 1: リソース発見

Client  Server: list_resources()
Server  Client: {
  "resources": [
    {"name": "customer_surveys.csv", "type": "file"},
    {"name": "support_tickets.db", "type": "database"},
    {"name": "product_feedback.json", "type": "file"}
  ],
  "tools": [
    {"name": "analyze_data", "description": "データ分析を実行"},
    {"name": "create_chart", "description": "グラフを生成"},
    {"name": "send_report", "description": "レポートを送信"}
  ]
}

Phase 2: 段階的なタスク実行

1. Client  Server: get_resource("顧客アンケート.csv", "metadata")
   Server  Client: {
     "columns": ["日付", "満足度スコア", "カテゴリ"], 
     "rows": 1250,
     "description": "過去1年間の顧客満足度調査データ"
   }

2. Client  Server: get_resource("顧客アンケート.csv", "sample", limit=5)
   Server  Client: [
     {"日付": "2024-01-15", "満足度スコア": 4, "カテゴリ": "製品品質"},
     {"日付": "2024-01-16", "満足度スコア": 3, "カテゴリ": "サポート対応"},
     ...
   ]

3. Client  Server: use_tool("データ分析実行", {
     "データソース": "顧客アンケート.csv",
     "分析タイプ": "トレンド分析",
     "対象期間": "直近6ヶ月",
     "分析項目": ["満足度スコア", "カテゴリ別傾向"]
   })
   Server  Client: {
     "傾向": "下降気味", 
     "平均スコア": 3.2, 
     "主要課題": ["サポート対応の遅延", "製品不具合の増加"]
   }

4. Client  Server: use_tool("グラフ生成", {
     "グラフタイプ": "折れ線グラフ",
     "データ": "満足度推移",
     "期間": "6ヶ月",
     "タイトル": "顧客満足度の推移"
   })
   Server  Client: {
     "グラフURL": "satisfaction_chart.png", 
     "インサイト": ["7月以降満足度が低下", "サポート関連の問題が増加傾向"]
   }

💡 従来のAPI連携との決定的な違い

従来のFunction Calling

開発者が事前に定義:「天気APIを使え」
User → Client: 「今日の天気は?」
Client: 「天気APIを呼び出します」
Client → App → Weather API → App → Client → User

問題点:

  • ClientはAPIの存在を「教えられる」まで知らない
  • 事前定義された機能しか使えない
  • 複合的なタスクは開発者が設計する必要がある

MCPのアプローチ

Client自身が発見・探索:「何が使えるか?」→「どう組み合わせるか?」
User → Client: 「包括的な分析をしてほしい」
Client: 自律的にリソースを発見・組み合わせて最適解を構築

優位点:

  • 自律的な探索: LLMが能動的にリソースを発見
  • 動的な組み合わせ: 複数のリソース・ツールを柔軟に活用
  • 適応的な処理: タスクに応じて最適なアプローチを選択

🔒 セキュリティと効率性の両立

MCPの通信フローは、セキュリティと効率性も考慮して設計されています:

セキュリティ機能

  • 認証・認可: 各リクエストにトークンベースの認証
  • アクセス制御: リソースごとの細かい権限管理
  • 監査ログ: すべての通信を記録・追跡可能

効率性の工夫

  • 部分的データ取得: 必要な情報のみを段階的に取得
  • キャッシング: 一度取得したデータの再利用
  • ストリーミング: 大量データの効率的な処理

国際化対応

MCPは国際化対応されており、日本語を含む多言語での運用が可能です。これにより、より実用的で使いやすいシステム構築ができます。

🎯 まとめ

MCPの通信フローは、単なる 「リクエスト & レスポンス」 ではなく、ClientとServerが協力してタスクを解決する 「知的な対話」 です。

重要なポイント

  • 2段階のフロー: 発見フェーズ → 実行フェーズ
  • 自律的な探索: LLMが能動的に外部リソースを活用
  • 動的な組み合わせ: 複数のリソース・ツールを柔軟に連携
  • 効率的な処理: 必要な情報のみを段階的に取得

このインタラクティブな仕組みが、LLMが外部の世界をより賢く、効率的に利用することを可能にしています。人間が図書館で司書と相談しながら必要な情報を見つけるように、MCPではLLMが自らサーバーと「相談」しながら最適な解決策を構築します。

🔜 次回予告

Day 4【MCP入門 #4】Resources・Tools・Promptsを実例で理解!3つの機能の使い分け方では、以下を詳しく解説します:

  • Resources:どんなデータソースが対応できるか
  • Tools:実行可能な機能の具体例と設計方法
  • Prompts:効果的なプロンプトテンプレートの作成方法
  • 3つの機能を組み合わせた実践的な活用例

MCPの3つのコア機能を実例で学び、実際の開発に活かせる知識を身につけましょう!

この記事が役に立ったと思ったらいいね👍やストックをお願いします。


📚 参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?