目次を表示する

Claude Code：エージェントプラットフォーム

第6章 MCP・Agent Teams ── 外部連携と並列実行

第6章 MCP・Agent Teams ── 外部連携と並列実行

Claude Code の能力はローカルのファイル操作とコマンド実行にとどまらない。外部サービスと接続し、複数のインスタンスが協調して動くことで、一人の開発者では捌ききれない規模のタスクを処理できるようになる。この章では MCP（Model Context Protocol）による外部連携と、Agent Teams による並列実行という二つの拡張機能を深掘りする。

Section 1: MCP（Model Context Protocol）とは何か

JSON 設定ファイルを書くだけで接続できる革命性

MCP は Anthropic が策定したオープン標準プロトコルで、外部ツールやサービスを Claude Code に接続するための共通インターフェースを定義する。重要なのは「コードを書かなくていい」という点だ。MCP サーバーを提供しているサービスに接続するには、~/.claude/settings.json に数行の JSON を追記するだけでよい。

従来、AI アシスタントに外部サービスを使わせるには、API ラッパーを書き、プロンプトにツール定義を埋め込み、レスポンスのパースを実装する必要があった。MCP はこの複雑さを抽象化し、「接続の設定」と「使い方の学習」を切り離した。設定さえすれば、Claude Code は MCP サーバーの持つツールを自然に使いこなす。

アーキテクチャの全体像

graph LR
    subgraph ユーザー環境
        U[開発者] -->|自然言語| CC[Claude Code]
        CC <-->|MCP Protocol| MS1[Perplexity MCP Server]
        CC <-->|MCP Protocol| MS2[GitHub MCP Server]
        CC <-->|MCP Protocol| MS3[Jira MCP Server]
        CC <-->|MCP Protocol| MS4[社内API MCP Server]
    end

    MS1 <-->|HTTPS| PX[Perplexity AI\nWeb検索]
    MS2 <-->|GitHub API| GH[GitHub\nPR・Issue・Code]
    MS3 <-->|Jira REST API| JR[Jira\nスプリント・タスク]
    MS4 <-->|Internal REST| IA[社内サービス\nDB・認証・ログ]

    style CC fill:#4A90D9,color:#fff
    style MS1 fill:#27AE60,color:#fff
    style MS2 fill:#27AE60,color:#fff
    style MS3 fill:#27AE60,color:#fff
    style MS4 fill:#27AE60,color:#fff

2026年3月の Lazy Loading 対応が変えたこと

2026年3月以前の MCP は、設定に書いた全サーバーがセッション開始時に一括接続される仕様だった。接続に時間がかかる、コンテキストにツール定義が大量に追加される、めったに使わないサーバーがコンテキストを圧迫する──これらの問題があった。

Lazy Loading 対応以降は、MCP サーバーへの接続はタスクが実際に必要とするまで遅延される。10個の MCP サーバーを設定しても、そのセッションで Perplexity 検索しか使わなければ Perplexity サーバーとだけ接続する。起動速度が向上し、コンテキストの使用効率も上がった。多くの MCP サーバーを設定することへの心理的ハードルが下がった変更と言える。

Section 2: 優先度別 MCP サーバーリスト

Priority 1：即効性が高い（今すぐ導入する価値がある）

Perplexity：コードを書きながらドキュメントを調べる

ライブラリの API 仕様が不確かなとき、Claude Code は学習データに含まれる古い情報で回答することがある。Perplexity MCP を設定すると、Claude Code がリアルタイムで Web 検索しながらコーディングを支援する。「この関数の第3引数の型は？」という疑問をその場で最新ドキュメントで解決しながら実装が進む。

設定例：

{
  "mcpServers": {
    "perplexity": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-perplexity"],
      "env": {
        "PERPLEXITY_API_KEY": "pplx-xxxxxxxxxxxx"
      }
    }
  }
}

GitHub：PR・Issue 操作を自然言語で

「先週マージされた認証周りの PR を全部見せて」「このバグレポートに関連する Issue を検索して」といった操作が自然言語で行える。PR のコメントを読みながら修正方針を立て、コードを直して、PR を更新するまでを Claude Code が一気通貫で処理する。

Priority 2：チーム活用に有効

Jira / Linear：タスク管理との統合

スプリントに積まれたタスクを Claude Code から直接参照できる。「今スプリントの残タスクを確認して、工数の大きいものから着手しよう」という指示で、Jira のバックログを取得し、コードの変更量推定と合わせて優先順位を提案する。タスクが完了したらステータス更新まで自動化できる。

Slack：完了通知の自動送信

長時間かかるタスク（大規模リファクタリング、マイグレーションなど）が完了したとき、指定チャンネルに自動通知する。Stop フックと組み合わせることで「処理が終わったら Slack で呼んで」という運用が実現する。Agent Teams と特に相性がいい。

Priority 3：高度な活用

カスタム社内 API：REST API を MCP サーバーとして公開

社内の認証サービス、ログ集計 API、デプロイパイプライン API などを MCP サーバーとしてラップすることで、Claude Code から直接操作できるようになる。「先月のエラーログで最頻出のエラーを調べて、対応するコードを修正して」という指示が、ログ API へのクエリからコード修正まで一連の流れとして実行される。

Database MCPs：クエリを Claude Code から実行

PostgreSQL・MySQL 向けの MCP サーバーを使うと、スキーマを理解した上でクエリを生成・実行できる。「user_events テーブルから先週の DAU を集計して」という指示にそのまま応答できる。ただし、本番データベースへの接続は読み取り専用ユーザーを使うなどの安全策が必須だ。

Section 3: Agent Teams ── 複数 Claude の協調動作

なぜ一人で抱え込まないのか

Claude Code の単一インスタンスは、コンテキストウィンドウという制約を持つ。大規模なリファクタリングで数十ファイルを同時に扱おうとすると、コンテキストが溢れてファイルの後半を「忘れた」状態で修正が走るリスクがある。また、独立した複数の作業を順番にこなすより、並列処理した方が圧倒的に速い。

Agent Teams はこの問題を解決する。複数の Claude Code インスタンスがそれぞれ担当範囲を持ち、チームリード役が全体を統括する構造だ。人間のチームと同じように、分担・並列・統合という流れで大規模タスクを処理する。

具体的なチーム構成例：大規模マイグレーション

JavaScript から TypeScript への全コードベース移行を例にとる。

チーム構成：JS → TS マイグレーション

  Team Lead（統合・コンフリクト解消・最終確認）
  ├── Agent A: src/auth/ 担当
  │   - JWT 認証ロジックの型付け
  │   - middleware の型定義追加
  ├── Agent B: src/api/ 担当
  │   - REST エンドポイントの Request/Response 型定義
  │   - エラーハンドリングの型安全化
  └── Agent C: テスト・ドキュメント担当
      - 既存テストの TypeScript 対応
      - API ドキュメントの型情報追記

各エージェントは独立したセッションで動作し、担当ディレクトリのみを修正する。Agent A が src/auth/ を書き換えている間、Agent B は src/api/ を並列処理する。全エージェントが完了したら Team Lead が差分を統合し、型の整合性と依存関係を確認する。

チーム内のコミュニケーションパターン

sequenceDiagram
    participant TL as Team Lead
    participant A as Agent A (auth/)
    participant B as Agent B (api/)
    participant C as Agent C (test/)

    TL->>A: 担当範囲・型定義規約を共有
    TL->>B: 担当範囲・型定義規約を共有
    TL->>C: 担当範囲・テスト方針を共有

    par 並列実行フェーズ
        A->>A: src/auth/ を TypeScript 化
        B->>B: src/api/ を TypeScript 化
        C->>C: テストファイルを更新
    end

    A->>TL: 完了報告（変更ファイル一覧・型定義の共有部分）
    B->>TL: 完了報告（変更ファイル一覧・API 型定義）
    C->>TL: 完了報告（テストカバレッジレポート）

    TL->>TL: 統合・型整合性チェック・コンフリクト解消
    TL->>TL: npm run build && npm run test
    TL-->>A: 追加修正依頼（あれば）
    TL-->>B: 追加修正依頼（あれば）

チームリード役の重要性

Agent Teams で失敗するパターンの多くは「チームリードを省略した」ことに起因する。各エージェントが独立して作業した結果、src/auth/ が定義した型と src/api/ が期待する型が食い違う──これは人間のチームでも起きる問題だが、AI エージェントは「他のエージェントが何をやっているか」をリアルタイムには知らない。チームリードが仕様を事前に共有し、完了後に統合する責任を担うことで初めてチームが機能する。

Section 4: Agent Teams のアンチパターン

アンチパターン 1：担当範囲の重複

最も多い失敗例は、複数のエージェントが同じファイルを修正するケースだ。Agent A が src/utils/auth.ts を書き換えている間に Agent B も同じファイルを編集し、最終的にどちらの変更が正しいか誰にも判断できなくなる。

対策：ファイルレベルで担当範囲を排他的に割り当てる。曖昧なディレクトリ境界（src/shared/ など）はチームリードが一元管理する。

アンチパターン 2：エージェント数が多すぎる

「並列実行できるなら多ければ多いほどいい」という考えは間違いだ。エージェントが増えるほど、チームリードの統合コストが指数的に増加する。コンフリクトの可能性が上がり、型の整合性確認が複雑になり、デバッグが困難になる。

経験的に 3〜5 エージェントが最適とされている。大きなプロジェクトであれば、一度に全部やろうとせず、フェーズに分けて繰り返す方が安全だ。

構成の比較

graph TD
    subgraph 悪い構成：ファイルが重複・リードなし
        A1[Agent 1\nsrc/auth/ + src/shared/]
        A2[Agent 2\nsrc/api/ + src/shared/]
        A3[Agent 3\nsrc/utils/ + src/shared/]
        A1 -. 競合発生 .-> A2
        A2 -. 競合発生 .-> A3
    end

    subgraph 良い構成：排他的担当・リードあり
        TL2[Team Lead\n統合・共有型定義の管理]
        B1[Agent 1\nsrc/auth/ のみ]
        B2[Agent 2\nsrc/api/ のみ]
        B3[Agent 3\nsrc/utils/ のみ]
        TL2 --> B1
        TL2 --> B2
        TL2 --> B3
        B1 --> TL2
        B2 --> TL2
        B3 --> TL2
    end

    style A1 fill:#E74C3C,color:#fff
    style A2 fill:#E74C3C,color:#fff
    style A3 fill:#E74C3C,color:#fff
    style TL2 fill:#4A90D9,color:#fff
    style B1 fill:#27AE60,color:#fff
    style B2 fill:#27AE60,color:#fff
    style B3 fill:#27AE60,color:#fff

アンチパターン 3：タスクが並列に向かない

Agent Teams は並列処理に適したタスクにしか効果を発揮しない。強い依存関係のあるタスク──「A の実装が終わらないと B が書けない」──を無理に並列化すると、待機と手戻りが発生してむしろ遅くなる。

並列向きのタスク：独立したモジュールの修正、複数マイクロサービスへの同種の変更、テストとドキュメントの並行作業

直列向きのタスク：設計→実装→テストのような工程依存、共有インターフェースの定義が未確定な段階での実装

MCP と Agent Teams を組み合わせる

二つの機能は組み合わせると最大の効果を発揮する。たとえば、複数マイクロサービスの一斉アップデートを Agent Teams で分担し、各エージェントが Jira MCP でタスクステータスを更新しながら進捗する構成だ。全エージェントの作業が完了したタイミングで Team Lead が Slack MCP 経由で通知を送る──人間はコーヒーを飲みながら完了を待てばいい。

Claude Code を単なる「補助ツール」として使うのか、それとも「自律的に動くチームの一員」として使うのか。MCP と Agent Teams はその境界を大きく後者側に押し広げる技術だ。設定の敷居は低い。まず Perplexity MCP を一つ追加するところから始めてみることを勧める。

次章では、Claude Code を CI/CD パイプラインに統合し、コードレビューの自動化と品質ゲートとしての活用を解説する。