Claude Code MCP実践・上級編——トランスポート設計・3スコープ管理・Boris推奨構成・Anthropic内部事例で「チームの生産性」を底上げする

はじめに

MCPを設定したけれど、「なんとなく動いている」状態から抜け出せていないことがある。

「stdioとSSEの違いを聞かれると答えられない」「チームで誰がどこに何を設定しているか把握できていない」「Context7とGitHubを入れてみたが、次に何を入れるべきか判断できない」——MCPの基本を一通り試した後に残る疑問だ。

MCPの基本（設定方法・Tool Search・.mcp.jsonのチーム共有）についてはClaude Code × MCP完全ガイド——外部ツールと連携してできることが激変するで解説しています。本記事はその先の話だ。トランスポートの仕組み・3スコープの使い分け・実績のある推奨サーバー構成・Anthropic内部の活用事例を整理して、MCPを「なんとなく使う」から「設計して使う」に切り替えるための内容だ。

トランスポートの仕組み：stdioとHTTPをいつ使い分けるか

MCPサーバーは2種類のトランスポートで通信する。どちらを選ぶかはパフォーマンスとセキュリティに直結するので、理解しておく価値がある。

stdio（標準入出力）

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["@upstash/context7-mcp"]
    }
  }
}

`command`キーがある設定はstdioとして自動判定される。ローカルプロセスとして起動し、標準入出力で通信するため、レイテンシが最も低くセキュアだ（ローカル完結）。ファイルシステム・Git・ローカルDBなどローカルツールに使う。

HTTP（SSE含む）

{
  "mcpServers": {
    "remote-service": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

`url`キーがある設定はHTTP接続として扱われる。クラウドサービス・チーム共有サーバーに対応しており、SaaS連携（Slack・Notion・GitHub API）や社内で共有するMCPサーバーに使う。

選択の判断基準

ローカル完結で済むか？
  └─ Yes → stdio（Playwright・Context7・Serena等）
  └─ No  → HTTP（Slack・Notion・社内API等）

HTTPを使う場合、通信がネットワークを経由するためAPIキーの管理に注意が必要だ。環境変数（`${SLACK_TOKEN}`）での参照が必須になる。

3スコープ設計：何をどこに書くか

MCPの設定は3つのスコープで管理できる。基本記事でProjectとUserを解説したが、Localスコープが使いこなしのカギになる。

スコープの役割

スコープファイル用途git管理
Project`.mcp.json`チーム全員が使うサーバー✅ 管理する
User`~/.claude.json`個人のグローバル設定❌ しない
Local`.claude/settings.local.json`プロジェクト単位の個人上書き❌ `.gitignore`に追加

Localスコープの使いどころ

Localスコープは「チームのProjectスコープを前提に、自分だけ追加したい設定」のために存在する。

// .claude/settings.local.json（個人のみ・gitignore）
{
  "mcpServers": {
    "my-notion": {
      "command": "npx",
      "args": ["@anthropic/mcp-server-notion"],
      "env": {
        "NOTION_API_KEY": "${MY_PERSONAL_NOTION_KEY}"
      }
    }
  }
}

チームNotionとは別の個人ワークスペースへのアクセス、開発中の自作MCPサーバーのテスト、プロジェクトでは不要だが個人作業に使うサーバー——これらはLocalスコープに置く。

実践的なスコープ設計パターン

.mcp.json（チーム全員）
├── context7        ← ライブラリドキュメント参照（全員必要）
├── github          ← PRレビュー・Issue管理（全員必要）
└── playwright      ← UI確認・テスト（全員必要）


~/.claude.json（個人グローバル） ├── brave-search    ← 個人的なWeb検索 └── obsidian        ← 個人のナレッジベース



.claude/settings.local.json（個人×プロジェクト） └── my-staging-db   ← 個人のステージングDB接続

実績のある推奨サーバー構成：Boris推奨セットと拡張

Boris Cherny（Claude Code創設者）の実際の使用構成

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["@anthropic/mcp-server-slack"],
      "env": { "SLACK_TOKEN": "${SLACK_TOKEN}" }
    },
    "bigquery": {
      "command": "npx",
      "args": ["@anthropic/mcp-server-bigquery"],
      "env": { "GOOGLE_APPLICATION_CREDENTIALS": "${GCP_CREDENTIALS}" }
    },
    "sentry": {
      "command": "npx",
      "args": ["@anthropic/mcp-server-sentry"],
      "env": { "SENTRY_AUTH_TOKEN": "${SENTRY_AUTH_TOKEN}" }
    }
  }
}

この3つを選んでいる理由がある——「外部ツールをClaudeが自律的に操作してワークフローが変わる」という体験を最もすんなり得られるからだ。

サーバーワークフロー変化
Slack「昨日の障害議論を要約して修正案を作って」がSlack直参照で完結
BigQuery「このデータ傾向を確認して実装に反映して」がワンフローで完結
Sentry「本番エラーを確認して原因を特定して」がエラーログ直参照で完結

追加で価値が高いサーバー

開発・デバッグ系（.mcp.jsonに追加推奨）

サーバー特徴効果
Context7人気ライブラリの最新ドキュメント取得「Next.js 15の最新APIで」が正確に動く
Serena高速コードベースシンボル検索大規模コードベースで関連コードを即座に発見
Playwrightブラウザ自動操作・スクリーンショット自作UIをClaudeが直接確認してバグ修正できる
Chrome DevToolsコンソール・ネットワーク情報取得ブラウザエラーをClaudeが直接読んでデバッグ

データ・ドキュメント系

サーバー特徴
PostgreSQLローカルDB直接クエリ
Notionドキュメント参照・更新

Anthropic内部の活用事例：MCP × ドキュメント管理

「MCPは実際のところどれだけ使えるのか」という疑問に答える事例として、Anthropic内部の活用が参考になる。

Inferenceチームの事例

課題: 技術ドキュメントがwiki・コードコメント・チームメンバーの頭の中に散在しており、MLバックグラウンドを持たないメンバーがモデル固有の関数を理解するのに時間がかかっていた。

解決策: MCPで複数ドキュメントソースを統合し、CLAUDE.mdでコードベース固有の知識を管理。

結果: 通常1時間のGoogle検索が10〜20分に短縮し、研究時間が80%削減された。

Security Engineeringチームの事例

複数ドキュメントソースをClaude Codeに取り込ませ、マークダウンのランブック（障害対応手順書）とトラブルシューティングガイドを自動生成している。

MCPで複数ソースを統合
    ↓
「この障害のランブックをMarkdownで生成して」
    ↓
凝縮されたドキュメントを生成
    ↓
本番問題のデバッグ時にClaude Codeへの入力として活用
    ↓
フルナレッジベース検索より効率的なデバッグが実現

この事例が示すのは「MCP = 外部ツール操作」だけでなく「MCP = 組織の知識をClaudeに接続する基盤」としての活用価値だ。自分のチームのwikiやランブックをMCPで繋いでみる、という発想の転換が起きた事例でもある。

トラブルシューティング：よくある問題と対処法

サーバーが起動しない場合

# デバッグモードで詳細を確認
claude --debug


# Claude Code外でサーバーを手動テスト npx @modelcontextprotocol/server-github  # 直接実行して動作確認

確認すること：`command`が存在し実行可能か、環境変数が正しく設定されているか。

ツールがClaudeに表示されない場合

# 設定確認
claude mcp list


# /mcp でインタラクティブUIで状態確認 /mcp

コンテキストが重い場合

不要なサーバーを`/mcp` → Disableで無効化する。または、そのサーバーで実行していた処理がCLIコマンドで代替できないか検討する（GitHub操作を`gh`コマンドに置き換えるなど）。

ビフォーアフター

Before（基本設定のみ）

全員が`~/.claude.json`に個別でMCPを設定している。新メンバーがMCPを設定するまでに時間がかかり、スコープ設計なしで設定が混在する。「なぜこのサーバーを入れたのか分からない」状態になっていく。

After（3スコープ設計＋推奨構成）

`.mcp.json`にチーム共有サーバーを定義してgit管理する。新メンバーがcloneした瞬間にClaude Code＋MCPが使える状態になる。`~/.claude.json`は個人グローバル・Localは個人×プロジェクト上書き用と役割が明確だ。Boris推奨（Slack・BigQuery・Sentry）＋Context7＋Playwrightを稼働させると「Slackの議論を見て → BigQueryでデータ確認 → 実装」がワンフローで回る。

まとめ：今日からできること

  1. 今すぐ（5分）: `.mcp.json`のトップレベルキーが`mcpServers`になっているか確認し、`context7`と`github`をチーム共有設定に追加する
  2. 今日中: `.claude/settings.local.json`に個人用サーバーを移し、スコープを整理する
  3. 今週: Boris推奨のSlack＋Sentryを追加し「本番エラーをClaudeが直接確認する」体験をする
  4. チーム展開: `.mcp.json`を`git add`してチーム全員が同じMCP環境を持てるようにする

MCPは「入れた数」より「設計の質」で効果が変わる。3スコープを正しく使い分けてチームの共通基盤を作る——それがこの記事で伝えたかったことだ。

コメント

タイトルとURLをコピーしました