Claude Code Agent Teams：AI支援開発の未来

大規模アプリやエンタープライズ環境では、文脈は思っている以上にすぐ一杯になります。1時間前に下した大きな設計判断は、すでにコンテキストから押し出されているかもしれません。そのため、モデルがすでに検討済みのことを何度も説明し直す羽目になります。やっていること自体は概ね正しいのですが、問題は、1人のアシスタントに本来ならチーム全体でやるべき仕事を頼んでいる点にあります。

Claude Code Agent Teams は、この状況を変えるために導入されました。1つのセッションが順番にすべてをこなすのではなく、タスクリストを共有し、互いに直接メッセージを送り合い、並行して作業を実行する複数の特化エージェントを立ち上げる、という発想です。

この記事では、Agent Teams の仕組み、各特化ロールの役割、そして実際のソフトウェアプロジェクトでの連携方法を順に解説します。

Claude Code が初めての場合は、まずはClaude Code 101 コースで基本を半日で押さえてください。

Claude Code Agent Teams とは？

Claude Code Agent Teams は、複数の Claude Code セッションが同じプロジェクトに同時に取り組めるようにする調整レイヤーです。1つのセッションがチームリードの役割を担い、作業の特定部分を担当するための別セッション（チームメイト）を作成します。

各チームメイトは独立した完全な Claude Code インスタンスとして動作し、それぞれに専用のコンテキストウィンドウを持ちます。共通のタスクリストを共有し、空いた作業を取りに行き、必要に応じて直接メッセージで連携します。

単にターミナルのタブを2つ開いて、それぞれで Claude を動かすだけの話ではありません。そうした別個のチャットウィンドウ同士は互いの進捗を見られず、誰が何をしているのかの合意も取れません。一方、エージェントチームは、すべてのセッションに作業の共有ビューとコミュニケーション手段を提供します。リードが全体の整合性を保ちます。

実際には、セッション間の伝書役をする必要がなくなるということです。チームが自律的に調整し、方向付けと成果物のレビューのときだけ介入すればよくなります。

Agent Teams が存在する理由

単一の Claude Code セッションでも、プロジェクトが大きくなければ問題ありません。

各 Claude Code セッションにはコンテキストウィンドウがあり、その容量には限りがあります。作業が進むにつれ、ファイル内容、コマンド出力、設計ディスカッション、往復のやり取りがセッションに溜まっていきます。やがて古い情報はコンテキストから外れ、同じタスク内でも以前の判断をモデルが忘れ始めます。

特に顕著になるのは次の3つの状況です。

• 巨大なリポジトリ: 何百ものファイルがあるコードベースはコンテキストに収まりません。セッションは同じファイルを何度も読み直すことになり、既に得た理解を再構築するためにトークンを消費します。
• 複雑なプロジェクト: 認証の追加のような横断的な機能は、バックエンド、フロントエンド、テストなど多くの関心事を同時に扱う必要があります。新しい要素が増えるたびに、他のすべてとコンテキストの席を奪い合います。
• 同時並行の複数タスク: 1つのセッションに、機能実装、モジュールのリファクタリング、テスト作成、ドキュメント更新を同一会話で頼むのは無理があります。

解決策は、人間のチームが何十年も前に辿り着いたものと同じです。作業を分割することです。

もし1つのセッションがリファクタリングで限界に達しているなら、バックエンドの変更は1人、フロントエンドの変更は別の1人、テスト更新は3人目に任せましょう。各チームメイトは自分の担当に必要なものだけを使います。

同様の考え方はリサーチにも当てはまります。3つの仮説が競合するタスクは、1つのセッションが順番に検証していくよりも、3人のチームメイトが並行して各仮説を調べ、あとで結果を突き合わせたほうが早く進みます。

特化は深さを、並行は速さをもたらします。両者を組み合わせれば、単一セッションでは幻覚を起こしたり、完了までに時間がかかりすぎたりする作業にも対応できます。

Claude Code Agent Teams の仕組み

チームセッションは5つの段階を進み、オーケストレーションは Claude Code 内で処理されます。

• 目標を定義する: 新人エンジニアにブリーフするのと同じ感覚で、平易な言葉で望む成果を説明します。リードがそれを読み、どのように分割するかを判断します。
• 作業を委任する: リードが共有タスクリストを作り、チームメイトを起動します。各メイトには名前、役割、開始プロンプトが付きます。チーム構成を指定しても、リードに任せても構いません。
• 並行実行する: 各チームメイトはタスクを引き受け、進行中にし、完了させ、完了済みにします。依存関係は自動で尊重され、ファイルロックが競合を防ぎます。チームメイト同士は直接メッセージでやり取りできます — リードを経由する必要はありません。
• 結果を統合する: リードが成果物を集約し、競合を解決し、PR、レポート、リファクタ済みモジュールなど、目標に応じた単一のアウトプットを作成します。
• 成果をレビューする: 通常のプルリクと同様に、差分を読み、コードを実行し、テストを確認します。

Agent Teams の特化ロール

ロールはエージェントチームの骨格になります。ロールがないと、汎用セッションが重複する作業をしてしまいます。Claude Code は固定リストを提供しません — ブリーフ内でロールを定義するか、.claude/agents/ 配下に保存したサブエージェント定義をリードに参照させます。

プランニングエージェント

プランニングエージェントは、コードを書く前に目標をタスクへ分解します。コードベースを探索し、依存関係を写し取り、1人のチームメイトが頻繁な確認なしに完了できる自己完結型のタスクリストを作ります。

実務では、チームリード自身がこの役割を担うことがよくあります。作業規模が大きければ、専任のプランニングメイトを走らせても構いません。

コーディングエージェント

コーディングエージェントは実装を書きます。多くのチームメイトはコーディングエージェントで、バックエンド、フロントエンド、データベース、AI機能など、明確に分かれた領域を担当します。重要なのはスコープが重ならないようにすることです。同じファイルを2人が編集すると、互いの変更を上書きしてしまいます。

コーディングエージェントは安価なモデルでも十分に機能します。実務では、リードを Opus、チームメイトを Sonnet にする運用が多く、実行には調整ほど深い推論は要らないためです。

テスティングエージェント

テスティングエージェントはテストを書いて実行します。コーディングメイトがエンドポイントを構築している最中でも、合意済みのAPIコントラクトに対してテストを進められます — つまりコードが着地した時点で、テストはすでに揃っています。

セッション全体でテスティングメイトを走らせ続け、コーディングメイトがタスクを完了するたびにスイートを再実行させることもできます。

レビューエージェント

レビューエージェントは差分を読み、バグ、スタイルの問題、見落としたエッジケース、セキュリティ上の懸念を指摘します。視点の異なる2人のメイト（例：1人はセキュリティ、もう1人はパフォーマンス）でレビューを分担し、リードが所見を統合するやり方が特に有効です。

すでにプロジェクト用のサブエージェント定義を書いてある場合、チームメイトはそのツールとシステムプロンプトを自動的に継承します。

ドキュメンテーションエージェント

ドキュメンテーションエージェントは、ドックストリング、README の更新、アーキテクチャノートやAPIリファレンスのような長文ドキュメントを書きます。コーディングとテストが終わる頃には最終的な形が明確になるため、最後に走らせる候補として適しています。

特化が成果を高める理由

汎用セッションは実装、テスト、ドキュメント、レビューのフィードバックを同時にコンテキストへ抱え込む必要があります。特化したチームメイトは必要なものだけを読み込み、コンテキストを小さく、推論を焦点化できます。特化はデバッグも容易にします。不具合があれば、どのセッションを確認すべきかが明確だからです。

Agent Teams による並行開発

並行性こそがエージェントチームの肝です。

リードが作業をタスクに分割してチームメイトを起動すると、全員が同時に動き出します。各チームメイトは独立した Claude Code セッションなので、作業は1つのコンテキストウィンドウの背後で順番待ちをしません。マルチパートの機能を終えるまでの時間は、各パートの合計ではなく、最も遅いパートの所要時間にまで短縮されます。

特に並行でうまくいく組み合わせを3つ紹介します。

• フロントエンドとバックエンドの並行開発: 両方のレイヤーを使う新機能を作る場合、バックエンドのチームメイトはAPIエンドポイントを、フロントエンドのチームメイトはそれを消費するコンポーネントを並行して作れます。2者はダイレクトメッセージで連携します。バックエンドがレスポンス形式を決めたら、その形式をフロントエンドにすぐ伝え、互いに完了を待たずに作業を継続できます。
• 実装とテストの並行開発: コーディングメイトが実装を書く一方で、テスティングメイトは合意したコントラクトに基づくテストを書きます。コーディングメイトがタスクを完了にするときには、すでにテストが実行できる状態です。コードを書いてから最後にテストを足す通常の流れより、はるかに速く進みます。
• ドキュメント作成とコードレビューの並行実行: コーディングメイトが一部を終えたら、ドキュメントメイトはドックストリングや README 更新を書き始め、レビュー担当はバグやスタイル問題のために差分を読みます。どちらも互いをブロックせず、アウトプットをリードが統合します。

制約となるのはファイルの競合です。2人のチームメイトが同時に同じファイルへ書き込むと、互いを上書きしてしまいます。したがって、リードはファイルやモジュールの境界に沿って作業を分割する必要があります。区切りが明確であれば、タスクリストが許す限り多くのチームメイトを並行で動かせます。

大規模コードベースにおける Claude Code Agent Teams

大規模なコードベースでは、エージェントチームは「あると便利」ではなく「必須」に近い存在です。

数百から数千のファイルを含むリポジトリは、単一のコンテキストウィンドウに収まりません。大規模コードベースを単独セッションで扱うと、コードの再把握に多くの予算を費やすことになります。

Agent Teams では、各チームメイトが自分の作業に関係するファイルだけを読み込むため、メイトごとのコンテキストは小さくフォーカスされた状態を保てます。チーム全体としてはリポジトリ全体を俯瞰できますが、どの単一セッションもそれを丸ごと抱える必要はありません。

このメリットが最も効くのは次の3つの場面です。

• 横断的な変更: 複数モジュールに跨って数十ファイルに触れるリファクタは、単一セッションでは見失いやすいです。モジュールごとに分割し、各モジュールを別のチームメイトに任せれば、各自のスコープは扱いやすくなります。
• リポジトリ横断の監査: 大規模コードベースのセキュリティレビューやパフォーマンス監査は、並行して複数のチームメイトを走らせ、リポジトリの異なる部分を各自が確認するのが有効です。リードが所見を1つのレポートにまとめます。
• 長期プロジェクト: 複数週にわたるプロジェクトは、単一セッションでは保持しきれないコンテキストを蓄積します。Agent Teams は作業をチェックポイントに分割し、各チェックポイントを担当するチームメイトが、それ以前すべてを覚えておく必要がないようにできます。

もちろん、コストは発生します。

各チームメイトは独立した Claude Code セッションであり、専用のコンテキストウィンドウを持つため、トークン使用量はチームサイズに比例して増加します。4人チームは、同じ作業量で単一セッションの約4倍のトークンを使います。見積もりによってはさらに高くなることもあります。一方で、経過時間の短縮と関心ごとごとの深掘りが得られ、単一セッションでは現実的に終えられない作業で特に効果を発揮します。

プロジェクトが大きいほど、Agent Teams の利得は大きくなります。ただし乱用は禁物です。小さなバグ修正なら、単一セッションのほうが安価で効果的です。

Agent Teams と Claude Tag

エージェントチームだけが、Anthropic がAIとチームのワークフローの関係を再考している領域ではありません。

Claude Tag は別機能で、Slack に Claude を組織全体の共通参加者として連れてきます。チャンネルで @Claude をタグ付けすると、Claude は組織のツールとチャンネルのコンテキストを用いて作業を行います。これまでの議論を記憶し、自発的にフォローアップし、組織のアイデンティティの下で動作します。

2つの機能は異なる調整課題を解きます。エージェントチームは、1人の開発者のマシン上で、特定タスクに集中する複数の Claude Code セッションを調整します。Claude Tag は、Slack 上で数日から数週間にわたり、人間のチームにまたがる1つの Claude アイデンティティを調整します。ただし方向性は同じです。AI は、孤立して1人が使うツールから、チームの既存ワークフローの中で動く参加者へと移行しています。

これにより、AI に求められる資質も変わります。

単独アシスタントには強いジェネラリスト性が要りますが、協調システムには、計画し、引き継ぎ、助けを求め、他のエージェントや人間と整合し続ける強いスペシャリスト性が必要です。Agent Teams は Claude Code のワークフローでそれを実現し、Claude Tag はそれを Slack のワークフローの中で可視化します。

Agent Teams 構築のベストプラクティス

優れたエージェントチームは、多くが最初のセットアップで決まります。チーム自体は速いのですが、時間を浪費するのは、スコープの甘いタスクや曖昧なロールです。

いくつかのベストプラクティスを挙げます。

• ロールを明確に定義する: 各チームメイトには1つの焦点と、所有するファイル群を持たせます。チームメイトを作るときは、その責務、非責務、扱えるファイルやモジュールを具体的に伝えてください。曖昧なロールは作業の重複を生み、重複はマージコンフリクトを生みます。

• 並列化の前にタスクを分解する: まず計画、次に並列化。入力、出力、依存関係が明確なタスクへ分解するプランニングパスを回し、その計画をチームに渡して実行させます。計画には数千トークンかかりますが、方向を誤ったチームは数十万トークンかかり得ます。

• CLAUDE.md で基準を共有する: すべてのチームメイトは起動時に作業ディレクトリの CLAUDE.md を読みます。コードスタイル、ファイル構成、テスト方針、コミットメッセージ形式など、共通の取り決めをここに記載してください。

• レビューのチェックポイントを設ける: チームメイトの進捗を確認し、逸れている場合は方向転換させ、リードの成果物は受け入れる前にレビューします。リスクの高いタスクでは、いずれのチームメイトも変更を行う前に計画承認を必須にしましょう。まず計画を提示させ、リードの承認を待たせる運用です。

• チーム規模を抑える: 多くのワークフローでは3〜5人から始めてください。そこから先は、並列化による速度向上よりも調整のオーバーヘッドの伸びが速くなります。

• ファイル競合を避ける: 作業はファイルやモジュールの境界で分け、チームメイト同士が明確に分離されるようにします。同じファイルを2人が編集すれば、互いの変更を上書きしてしまいます。どうしても同一ファイルに複数人が必要なら、並列ではなく順序制御しましょう。

• 一般的な操作を事前承認する: チームメイトからの許可プロンプトはリードに集約されますが、4人のチームはプロンプトも4倍に増え得ます。チームを起動する前に permissions.allow を設定し、ファイル読み取りやテスト実行などの定型操作で作業が中断しないようにします。

• モデルを役割に合わせる: 調整には深い推論が有利なためリードは Opus のような強力なモデルで、実行役のチームメイトは Sonnet で動かします。

要点を短くまとめると次のとおりです。詳細な作業計画を作り、小規模なジュニアエンジニアのグループにブリーフするつもりでチームに説明し、明確なスコープと共有基準を与え、最後に成果物を確認します。実際のエンジニアリングチームに近いセットアップであるほど、エージェントチームのパフォーマンスは向上します。

Claude Code Agent Team の実践

ここまでを端から端まで通して見てみましょう。

小さな例を取り上げます。FastAPI で SQLite データベースからメッセージを読み取る「hello world」REST API と、そのAPIを呼び出して結果を表示する小さな HTML ページです。アプリにはバックエンドのルート、データベース層、静的フロントエンド、README ドキュメントがあり、4人チームにちょうど良い構成です。

エージェントチームを有効化する

エージェントチームは試験的機能で、既定ではオフです。シェルまたは Claude Code の設定ファイルで環境変数を設定して有効化します。

設定ファイルは ~/.claude/settings.json にあります。開いて次を追加します。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

設定ファイルを編集したくない場合は、Claude Code を起動する前にシェルで変数を設定しても構いません。

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

どちらの方法でも有効です。変数を設定すると、Claude Code はチーム関連のプロンプトを認識し、指示に応じて調整レイヤーを開始します。

Claude Code を起動してチームにブリーフする

プロジェクト用の空ディレクトリを作成し、その中で Claude Code を起動します。

mkdir hello-api && cd hello-api
claude

次にチームへブリーフします。プロンプトは自然言語で問題ありませんが、ロールと境界を具体的に示すほど、チームのパフォーマンスは上がります。hello world API 用のプロンプトは次のとおりです。

Create an agent team to build a small "hello world" REST API.

The project is a FastAPI service that returns a greeting from a SQLite
database, plus a tiny HTML page that calls the API and shows the result.
- One teammate on the database: create app/db.py with a sqlite3 connection
  to a greetings.db file. Define a get_greeting() function that returns
  the message column from the first row. On import, create the table if
  it doesn't exist and seed it with "Hello, World!" if empty.
- One teammate on the backend: build a FastAPI app in app/main.py with
  a GET /greeting endpoint that calls get_greeting() from app/db.py.
  Add permissive CORS and mount the static/ directory at the root so
  the HTML page is served from the same origin.
- One teammate on the frontend: build static/index.html as a single page
  that fetches /greeting on load, shows a spinner while loading, displays
  the greeting in a centered card on success, and shows an error message
  on failure. Inline the CSS and JavaScript.
- One teammate on docs: write README.md with installation, run, and
  open-in-browser steps, plus an API reference table. Also create
  requirements.txt with fastapi and uvicorn[standard].
Use Sonnet for each teammate. Require plan approval before any teammate
makes changes.

このプロンプトで注目すべき点は3つあります。ファイルの境界（app/db.py、app/main.py、static/index.html、README.md、requirements.txt）で重複を防いでいること。モデル選択（Sonnet）でトークンコストを抑えていること。そして plan approval により、コードを書く前に各チームメイトが計画を提示するため、ブリーフの誤解をチェックポイントで修正できることです。

チームの動きを観察する

プロンプトを送ると、リードが作業をタスクに分解し、チームメイトを起動します。ターミナル下部にエージェントパネルが現れ、チームメイトごとに1行ずつ表示されます。

作成されたエージェント

各行にはチームメイトの名前と現在の作業が表示されます。リードは共有タスクリストを埋め、依存関係に基づいてタスクを割り当てたり解放したりします。バックエンドのチームメイトは、get_greeting() を インポートするためデータベース層を待ちます。ドキュメント担当は、正確に記述できる段階まで他が進むのを待ちます。

タスクリストも確認できます。Ctrl+T を押してトグルします。リストには全タスク、その状態（保留、進行中、完了）、担当チームメイトが表示されます。

チームメイト間を移動する

各チームメイトは完全な Claude Code セッションであり、どれにでも話しかけられます。

エージェントパネルで上下矢印でチームメイトを選び、Enter を押してそのトランスクリプトを開きます。これでそのチームメイトのセッションに入り、入力はリードではなくそのメイトに送られます。特定のチームメイトにだけ追加コンテキストを渡したり、他のメンバーを巻き込まずに方針転換を指示したりする際に使います。

Esc を押すとリードに戻ります。

道を外れたチームメイトをリダイレクトする

ときどき、チームメイトがブリーフを誤解したり、担当外の作業へ逸れてしまうことがあります。これは、計画承認の段階で計画を確認するか、エージェントパネルで進捗のズレに気づくことで発見できます。

計画承認を使っている場合、チームメイトは計画後に一旦停止し、ファイルを書き始める前に提案を提示します。データベースエージェントの例は次のようになります。

データベースエージェントの承認

提案されたスキーマやアプローチを読み、承認するか、フィードバック付きで却下できます。もし計画に不足があるなら、"raw sqlite3 ではなく SQLAlchemy を使ってください" のように返信すれば、チームメイトは再計画します。

すでに作業を始めてから問題に気づいた場合は、エージェントパネルで該当メイトを選び、Enter でそのセッションを開いてメッセージを送ります。選択中のチームメイトに対して x を押して停止させることもできますし、完全に行き詰まっている場合は、リードに依頼して代替のチームメイトを起動させることもできます。

締めくくりとレビュー

すべてのチームメイトがタスクを終えると、リードが短い要約と、プロジェクトを実行するために必要なコマンドを報告します。

最終的なリードの指示

この時点で作業をレビューします。生成されたファイルをエディタで開き、差分を確認できます。

生成された app/main.py ファイル

データベースエージェントが作成・初期化したデータベースを検査することもできます。

greetings テーブル

依存関係をインストールし、uvicorn app.main:app --reload を実行し、ブラウザで http://localhost:8000 を開いて、フルスタックが端から端まで動作することを確認します。

最終アプリ

変更が必要な場合は、リードに調整点を伝えてください。リードが自ら修正するか、新たなチームメイトを立ち上げて対応します。結果に満足したら、リードにコミットを依頼できます。セッション終了時にリードはチームメイトを停止し、チーム設定はクリーンアップされます。

以上です！

まとめ

Claude Code Agent Teams の核心は「特化」と「調整」です。各チームメイトは固有の担当領域と固有のコンテキストウィンドウを持ちます。リードが整合性を保ち、タスクリストが同期を保ち、直接メッセージが、セッション間の伝言役としての手間をなくします。

より大きな流れとして、AI支援開発は単独作業から協調作業へと移行しています。Agent Teams はその変化が Claude Code に現れた形であり、Slack 向けの Claude Tag にも同じパターンが見られます。今のうちに慣れておけば、コンテキスト制約に悩む時間を減らし、実際の機能開発により多くの時間を充てられるでしょう。

生成AIの資格取得を検討していますか？こちらでは、2026年のおすすめ生成AI認定資格を、主要コース、準備のヒント、FAQ とともに紹介しています。