ankuro.dev
← ブログ一覧に戻る
【CCA Foundations対策 / MCP編 #1】MCPとは何か——ClaudeにツールをつなぐModel Context Protocol入門
2026-04-03#Claude#MCP#Python#生成AI#入門#Claude Certified Architect

【CCA Foundations対策 / MCP編 #1】MCPとは何か——ClaudeにツールをつなぐModel Context Protocol入門

Anthropic Academyの「Introduction to Model Context Protocol」コースをもとに解説しています。

MCP（Model Context Protocol）はClaudeにツールや外部サービスを接続するための仕組みだ。「Tool Useとは何が違うのか」「なぜわざわざMCPが必要なのか」——この記事ではその問いに答えながら、MCPのアーキテクチャと設定方法を整理する。

この記事でわかること：

  • MCPが解決する問題と、従来の手動ツール定義との違い
  • MCP Client / MCP Server / 3つのプリミティブの関係
  • ListTools → CallToolの通信フロー全体像
  • Tool UseとMCPの補完関係（混同しやすいポイント）
  • プロジェクトスコープとユーザースコープの使い分け、環境変数によるシークレット管理

MCPが解決する問題

ClaudeにGitHubのデータを扱わせるとする。「どのリポジトリにオープンなPRがあるか」という質問に答えるには、ClaudeがGitHub APIを呼び出せる必要がある。

従来のアプローチでは、開発者がリポジトリ一覧取得・PR取得・Issue取得……といったツール定義（JSONスキーマと関数実装）をすべて自分で書く必要がある。GitHubのAPIは機能が膨大なため、これは相当な実装量になる。さらに、APIが更新されるたびにスキーマのメンテナンスも発生する。

MCPはこの負担を解消する。ツール定義と実行をMCPサーバーに移すことで、開発者はツールをゼロから書かなくてよくなる。GitHubのMCPサーバーを誰かが実装してくれれば、それを使うだけでいい。

従来のアプローチ
  開発者のサーバー → GitHub API（ツール定義・実装をすべて自前で書く）

MCPを使う場合
  開発者のサーバー → MCPクライアント → GitHubのMCPサーバー → GitHub API
                                      （ツール定義・実装はMCPサーバー側）

MCPのアーキテクチャ

MCPの構成要素は3層に分かれる。

MCP Client

アプリケーションコードとMCPサーバーの間に立つ通信ブリッジ。ツールの一覧取得・ツールの実行リクエストをMCPサーバーに中継する。ツールそのものは実行しない。

MCP Server

外部サービスへのインターフェース。中に3つのプリミティブを持つ。

プリミティブ 役割 制御者
Tools 外部APIを呼ぶなどのアクションを実行 Claudeが必要と判断したときに呼ぶ
Resources データを読み取り専用で公開 アプリケーションコードが取得タイミングを決める
Prompts 事前に用意したプロンプトテンプレート ユーザーが/コマンドなどで明示的に呼ぶ

3つのプリミティブの使い分けは#3で詳しく解説する。

トランスポートの柔軟性

MCP Clientとサーバーはトランスポート非依存——同一マシン内ならstdin/stdout、ネットワーク越しならHTTPやWebSocketsで通信できる。ローカル開発では同一マシン通信が一般的。

通信フロー：ListTools → CallTool

「ユーザーがGitHubのリポジトリ一覧を聞いてきた」ときの全体フローを追う。

① ユーザー：「リポジトリ一覧を教えて」
② アプリサーバー → MCPクライアント：「使えるツールは？」
③ MCPクライアント → MCPサーバー：ListToolsRequest
④ MCPサーバー → MCPクライアント：ListToolsResult（ツール一覧）
⑤ アプリサーバー → Claude：ユーザーの質問 + ツール一覧
⑥ Claude → アプリサーバー：「get_repos ツールを使いたい」（stop_reason: tool_use）
⑦ アプリサーバー → MCPクライアント：「get_repos を実行して」
⑧ MCPクライアント → MCPサーバー：CallToolRequest（get_repos, 引数）
⑨ MCPサーバー → GitHub API：実際のAPIコール
⑩ 結果がClaudeへ → Claudeが最終回答を生成

MCPクライアントは「ツールそのものは実行しない」ことに注意。リクエストをMCPサーバーに中継し、サーバーが実際のGitHub APIを叩く。

よくある誤解：MCP ≠ Tool Use

「MCPはTool Useと同じ概念では？」という混乱がよく起きる。

Tool Use：ClaudeがAPIにツール呼び出しを要求する仕組み（stop_reason: tool_use → ツール実行 → tool_result返却）

MCP：ツールの定義と実行を誰がやるかという話。「誰がツールスキーマを書き、誰が関数を実装するか」を解決する

2つは補完関係にある。MCPサーバーが定義したツールをClaudeがTool Useで呼び出す——という組み合わせがよくある使い方だ。「MCPを使えばTool Useが不要になる」わけではない。

設定スコープと環境変数管理

MCPサーバーの設定ファイルには2つのスコープがある。

スコープ ファイル 適用範囲
プロジェクトスコープ .mcp.json（リポジトリ内） チーム全員に共有される
ユーザースコープ ~/.claude.json 自分の環境だけに適用される 
// .mcp.json（プロジェクトスコープ）
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}"
      }
    }
  }
}

環境変数展開でシークレットを管理するのが重要なポイント。APIキーをそのまま .mcp.json に書くとリポジトリにコミットされるリスクがある。${GITHUB_TOKEN} のような環境変数参照を使えば、実際の値は各開発者の環境変数から取得される。

また、上記の例のように複数のMCPサーバーを同時に接続できる。GitHubとSlackを同時に使いたい場合、mcpServers に両方を定義するだけで、Claudeはどちらのツールも使えるようになる。

📋 試験ガイドより
公式試験ガイドのIn-Scope Topicsに「MCP server configuration: Project vs user scope, environment variable expansion, multi-server simultaneous access」が明記されている。.mcp.json（プロジェクト共有）と~/.claude.json（個人）の使い分け、環境変数によるシークレット管理、複数サーバーの同時接続が設計判断のポイントとして取り上げられている。

よくある誤解まとめ

誤解 実際
MCPはTool Useの代替 補完関係。MCPはツール定義の管理方法、Tool UseはClaudeがツールを呼び出す仕組み
MCPを使えばツール定義を書かなくていい 既存のMCPサーバーを使う場合はそう。自分でMCPサーバーを実装する場合は定義が必要
MCPサーバーはAnthropicだけが作れる 誰でも作れる。サービス提供者が公式実装を出すことも多い
.mcp.jsonにAPIキーを直接書いてよい リポジトリにコミットされるリスクがある。環境変数参照（${VAR}）を使う
使えるMCPサーバーは1つだけ 複数のMCPサーバーを同時接続できる

設計の判断基準

場面 やりがちな選択 正しい選択 判断の根拠
外部サービスのツールが必要になった APIを直接呼ぶツール定義を自前で書く 既存のMCPサーバーがあればそれを使う ツール定義・実装・メンテナンスコストをMCPサーバー側に委譲できる
APIキーをMCP設定に含めたい .mcp.jsonに直接記述する 環境変数参照（${VAR}）で管理する APIキーがリポジトリにコミットされるリスクを防げる
チーム共通 vs 個人専用のサーバーを使い分けたい すべて同じ設定ファイルに書く チーム共通は.mcp.json、個人用は~/.claude.jsonに分ける プロジェクトスコープはチーム全員に適用される

まとめ

  • MCPは「ツール定義と実行を誰がやるか」を解決する仕組み。開発者の実装負担を外部のMCPサーバーに委譲できる
  • MCP Client（通信ブリッジ）→ MCP Server（ツール・リソース・プロンプトを持つ）という2層構造
  • ListTools → CallToolの2ステップがMCPの基本通信パターン
  • MCPとTool Useは補完関係であり、代替関係ではない
  • APIキーは環境変数参照で管理する。プロジェクト共有は.mcp.json、個人用は~/.claude.json
  • 複数のMCPサーバーを同時に接続できる

次回（#2）はMCPサーバーの実装——Pythonでツールを定義してデバッグするまでを解説する。

← シリーズB #12：エージェントの設計 ｜ #2：MCPでツールを定義する——サーバー実装とクライアント接続 →

← ブログ一覧に戻る