Claude Code Agent Teamsとは？1体に任せず役割で分けるチームの組み方

この仕組みの解説は、公式ドキュメントと、実際に何体か動かしてみた開発者のレポートが中心です。仕様の細かいところはそちらが詳しいので、私は少し違う角度から書きます。私が毎日AIに渡しているのはコードではなく、記事づくりや調べもの、資料づくりのほうです。リサーチ担当、執筆担当、校正担当というふうに役割で分けて渡すようになってから、1体の賢いAIに全部を頼んでいた頃より仕上がりが安定しました。Agent Teamsは、その「役割で分ける」やり方をClaude Codeの中でチームとして扱えるようにした仕組みです。何ができて、どこで人が判断を挟み、どんな仕事には向かないのかを、実務で分業を回している側から整理します。

Claude Code Agent Teamsの仕組み

先に紛らわしいところを片付けます。Claude Codeで「チーム」と言うと、法人向けの契約プランの話や、人間の開発チームでClaude Codeを共有して回す話と混ざりがちです。本記事で扱うのはそのどちらでもなく、AIどうしが分担して動くAgent Teamsのほうです。

続けて、言葉をそろえておきます。エージェントというのは、こちらの指示を受けて自分で手順を考えながら作業を進めるAIのことです。Claude Codeを起動して会話しているとき、その1回分のやり取りをセッションと呼びます。そしてAIが一度に頭に入れておける情報量をコンテキストウィンドウ、その情報の量を数えるときの単位をトークンと言います。長い会話を続けるほどトークンを使い、頭の中が埋まっていきます。

Agent Teamsは、そのエージェントを1体ではなく複数まとめて動かす仕組みです。ドキュメントで説明されている作りは、おおよそ次のようなものです。まず窓口になるリーダーがいて、そこに指示を出します。リーダーは仕事を分け、チームメイトと呼ばれる別のエージェントたちに配ります。チームは共有のタスクリストを持っていて、誰が何を担当していて、どこまで終わったのかが一覧で見えます。チームメイトどうしはメッセージでやり取りができるので、進捗の確認や質問が人を介さずに進みます。

大事なのは、チームメイトがそれぞれ自分のコンテキストを持っている点です。1つのセッションに全部を積み上げると頭が埋まりますが、担当ごとに別々の頭を持たせれば、それぞれは軽いまま動けます。しかも同時に走るので、順番待ちが減ります。並列で調べものを進めたり、同じ対象を別々の観点で並行してレビューさせたりできるのは、この作りがあってこそです。

共有のタスクリストは、AIどうしの連携のためだけのものではありません。使う側にとっては進捗ボードとして働きます。1体に頼んでいると、いま何をしているのかは長い出力を追うしかありませんが、担当と項目が並んでいれば、終わったもの・止まっているもの・誰も手を付けていないものが一目で分かります。人に仕事をお願いするときに進行表を共有するのと同じで、見えているだけで口を出す回数が減ります。

ひとつ注意があります。本記事を書いている2026年8月の時点で、Agent Teamsはまだ実験的機能として提供されているもので、名前もオンにするやり方も、これから変わる可能性があります。検索で出てくる実践レポートは2026年の2〜3月に書かれたものが多く、そこから仕様が動いているかもしれません。細かい仕様は必ず公式ドキュメントで最新を確認してください。本記事で扱うのは、仕組みのおおまかな形と、使う側の判断のほうです。

サブエージェントとの違い

Claude Codeにはもともとサブエージェントという仕組みがあります。役割を書いたファイルを用意しておくと、必要な場面で親のセッションがそれを呼び出し、作業をさせて、結果だけ受け取れます。私が長く使ってきたのはこちらです。

両者の違いを一言でいえば、サブエージェントは呼ばれたときだけ動く下請け、チームメイトは同じ時間に並んで動く同僚です。サブエージェントは呼び出し元が仕事を渡し、終わったら結果を返して消えます。指示の流れは一方通行で、順番も呼び出し元が握っています。チームは違って、共有のタスクリストを見ながら複数が同時に動き、互いにメッセージを送れます。人間の職場でいうと、外注に1件ずつ発注するのと、同じ部屋で同時に作業してもらうのとの差に近いです。

どちらを使うかは、仕事が一本道かどうかで決まります。調べて、書いて、直す、という順番が決まっている工程なら、サブエージェントを順に呼ぶほうが素直です。逆に、5つの候補を同時に調べたい、同じ原稿を3つの観点で同時にレビューさせたい、といった並べられる仕事ならチームのほうが速くなります。速くなるのは、担当どうしが同じものを触らないときだけです。ここを外すと、あとで触れる衝突が起きます。

オンにする手順と、画面の見え方

実験的機能なので、初期状態ではオフになっています。settings.json という設定ファイルに指定を書き足すか、起動時のオプションで指定するとチームが使えるようになります。指定の名前は変わることがあるため、ここでは具体的な文字列を書かずにおきます。手元のバージョンでどう書くかは、公式ドキュメントの該当ページを見るのが確実です。

もうひとつ、見た目にかかわる選択があります。表示モードです。ひとつは1つの画面の中でチーム全員を動かすやり方で、余計な準備が要らず、そのまま始められます。もうひとつは tmux や iTerm2 の分割ペインを使うやり方です。tmux はターミナルの画面を複数に割って、それぞれで別の作業を走らせておけるツールで、iTerm2 は Mac のターミナルアプリです。分割ペインにすると、誰が今どこで何をしているかが並んで見えるので、動きを目で追いやすくなります。

分割ペインを使うときの注意点として、チームを終わらせたあとに使い終わったペインが残ってしまうことがあります。作業が終わったつもりでも裏でセッションが生きている状態になるので、シャットダウンの手順まで含めて覚えておくほうが安心です。私は最初のうちは1画面で始めて、慣れてから分割を試すくらいでちょうどいいと思っています。

役割で割るようになったきっかけ

私がチームという考え方に寄っていったのは、機能が出たからではありません。1体に全部を頼んでいた時期に、はっきり困ったことがあったからです。

最初はよく動きます。ところが同じセッションで、調べものをして、原稿を書いて、そのまま数字の集計まで頼んでいくと、会話が長くなるほど様子が変わってきます。指示したはずのルールを飛ばす、文章のトーンがぶれる、前半で決めたことを後半で忘れる。原因はコンテキストが埋まっていくことでした。前の作業の文脈を引きずったまま次に入るので、頭がとっ散らかったまま判断している状態になります。数字を追っていた流れのまま文章を書かせると、どこか無機質な原稿が出てきます。

抱えすぎると質が落ちるところは、人もAIも似ているのだと思います。人間だって、複数の案件を同時に頭に置いたまま細かい判断をすれば、キレは落ちやすいでしょう。だから増やすのではなく割る、という方向に切り替えました。割るという考え方そのものは、Claude Codeの機能とは関係なく成り立つので、AIエージェントの作り方は「分業」だったという話のほうに一般論としてまとめてあります。仕組みの理屈から知りたい方は、あわせてご覧ください。

記事づくりをリサーチ・執筆・校正で割った実例

検索して出てくるAgent Teamsの記事は、ほぼ全部がコードを書く場面の話です。私が回しているのはそちらではないので、コードを書かない仕事での分けかたを書きます。

私のメディア運営では、役割ごとに6体を用意しています。調べものをするリサーチ担当、原稿を書く執筆担当、粗を見つける校正担当、ページやツールに手を入れる実装担当、見た目を整えるデザイン担当、数字を読む分析担当です。全部を1体に持たせないのは、上に書いたとおり、頭が混ざるからです。

3段のうちどれが欠けても困るのですが、いちばん飛ばしたくなるのが最初の調べる工程です。急いでいるときほど、いきなり書かせたくなります。実際に、調べる工程を省いて書かせた回がありました。調査を飛ばした回の原稿は、どれも「それらしい一般論」に化けていたのです。読むと整っているのに、中身は薄いままでした。誰が書いても同じことしか書いていない状態です。役割を分けた効果というより、工程を残した効果でした。分業の話は編成ばかり注目されますが、どの工程を省かないかを決めておくほうが、結果に直結します。

チームメイトに渡すもの

役割を分けただけでは、うまく動きません。渡し方のほうで詰まります。私が失敗しながら決めていった渡し方を並べます。

1つ目は、前提をこちらから渡すことです。誰に向けた仕事なのか、何を守るのか、やってはいけないことは何か。担当ごとに頭が分かれているということは、こちらの意図も自動では伝わらないということです。会話で長々と説明するより、ルールを書いたファイルを読ませるほうが早く、次の回にも使い回せます。

2つ目は、タスクの粒度をそろえることです。1つの担当に1つの成果物、という単位にしておくと、進捗が見えるうえに、失敗しても差し戻す範囲が小さくて済みます。逆に「この記事をいい感じにして」のような大きな渡し方をすると、担当が勝手に範囲を広げて、他の担当の仕事まで手を出しはじめます。

3つ目が、同じファイルを複数に触らせないことです。ファイル競合はチームで作業させるときの一番わかりやすい事故で、あとから読むと誰の変更が生き残ったのか分からなくなります。担当ごとに書き込む先を分けておいて、まとめる作業だけは最後に1体、または人がやると決めておきます。決めごとを1つ足しておくだけで、後始末の手間がかなり減ります。

4つ目は、読み取りだけの仕事から始めることです。調べる、要約する、比較する、といった何も壊さない仕事なら、失敗してもやり直せます。書き換える仕事や外に出す操作を任せるのは、動きを見て納得してからで遅くありません。

コードを書かない仕事で起きる壊れ方

開発の現場でよく語られる失敗は、同じファイルを触って壊れた、リーダーが勝手に実装しはじめた、あたりです。ところが記事や資料の仕事で分業させると、別の壊れ方をします。実際に私が踏んだものを挙げます。

1つ目は、担当ごとに文章のトーンがばらつくことです。同じ記事なのに、章によって話し方が変わります。対処はシンプルで、文体のルールを1つのファイルに集めて、書く担当も直す担当も同じものを読ませます。書きぶりを会話で毎回説明していると、どこかでずれてきます。

2つ目が、調べた結果を書く担当が無視することです。リサーチ担当が丁寧に材料を集めても、執筆担当が一部しか使わずに書き上げてしまうことがあります。読むと悪くないので気づきにくいのが厄介なところです。私は、調べた結果のうち何を回収したかをチェックリストにして、書く前に担当を割り当てるようにしました。使わないと決めたものは、使わないと明記します。

3つ目は、成果物の形がそろわないことです。担当ごとにファイルの構成や見出しの粒度が違うと、まとめる段階で人が整形するはめになります。見出しの並びと書き出し先を決めた雛形のファイルを1つ渡しておくと、だいたい収まります。

4つ目が、直す担当が甘くなることです。指摘だけして直さないことがあり、ひどいときは「問題ありません」で通してしまいます。見る観点をリストで渡し、見つけたら報告ではなく直すところまでやらせる、と決めてから安定しました。人のチームでレビュー担当を置くときと、まったく同じ悩みだと思います。

リーダーが手を動かしはじめる問題と、止め方

チームを使っていると、配る側であるはずのリーダーが自分で作業を始めてしまうことがあります。放っておくと、チームメイトに配ったはずの仕事と二重になったり、まだ相談中の段階で実物に手が入ったりします。

止め方は2つあります。ひとつは、リーダーを配る役に固定するモードを使うことです。ドキュメントでは Delegate Mode という名前で説明されていて、リーダーは仕事を配ることに専念し、手を動かすのはチームメイトだけ、という切り分けになります。もうひとつは、動く前に段取りを出させて、こちらが承認してから走らせることです。先に段取りを見せてもらうだけで、想像と違う方向に丸ごと進むのを止められます。私は分業を始める前からこのやり方を使っていて、担当を増やしても変えるつもりはありません。

止め方と並んで変わるのが、待ち方です。1体に頼んでいた頃は出力を上から順に読んでいましたが、複数が同時に喋りはじめると、全部を追うのは現実的ではなくなります。見る場所は、流れてくる文章ではなく共有のタスクリストのほうになります。終わった項目が増えているか、同じ項目のところで長く止まっていないか。目を配るのは2点だけにして、止まっているものがあれば理由を聞くようにします。読む量が減ると、途中で口を挟む回数も自然と減っていきます。

枠をはめておく考え方も同じです。自動で動くものを作るときは、1回で扱う量の上限、1日に走らせる回数、途中で止めるための手段を先に決めておきます。あとから機能を足したときに暴走しないよう、先に枠をはめておく順番のほうが安全です。作業の前後に決まった処理を自動で挟む仕組みについては、Claude Codeのhooksで毎回のルールを自動で守らせる話にまとめています。止め方まで含めて仕組みにしたい方は、よければそちらも読んでみてください。

トークンとコストの考え方

チームで動かすと、費用の感覚が変わります。複数のエージェントが同時に自分のコンテキストを持って動くということは、読み書きするトークンもその人数ぶん増えるということです。1人で順番にやらせていたときと同じ感覚で使うと、想像より早く使用量の上限に近づきます。

抑えかたはいくつかあります。まず、チームメイトのモデルを軽いものに指定することです。Claude Codeでは動かすモデルを選べて、賢いかわりに費用のかさむものと、そこそこの賢さで安く速いものが用意されています。全員を一番賢いモデルにする必要はなく、調べる、まとめる、形式をそろえる、といった仕事はSonnetのような軽いほうで十分回ります。判断が要るリーダーだけ賢いモデルにしておく、という分け方が現実的です。プランごとの料金の考え方はClaude Codeの料金と、実際に払っている額の話のほうにまとめているので、費用から逆算したい方はそちらもどうぞ。

次に、MCPを絞ることです。MCPはAIに外部の道具を持たせる仕組みで、繋いだ道具の説明はセッションの最初に読み込まれます。使わない道具まで繋いだままにしていると、全員がその説明を抱えることになります。チームで動かすときほど、繋ぐ道具は必要なものだけにしておくほうがいいです。

あとは、渡す資料の量です。関係のないファイルまでまとめて読ませるより、必要な範囲を指定して渡すほうが、費用の面でも精度の面でも良い結果になります。実際にいくらかかるかは、契約しているプランと仕事の量でまるで変わるので、数字は自分の使用量の画面で確かめてください。

Claude Code Agent Teamsが向く仕事と、向かない仕事

いちばん書きたかったのが、向き不向きの話です。Agent Teamsは万能ではなく、向かない仕事に使うと、むしろ遅くて高くつきます。

向くのは、分けても意味が通る仕事です。5つの候補を同時に調べる、同じ原稿を読みやすさ・事実確認・重複の観点で並行してレビューさせる、複数の仮説を別々に検証して結果を突き合わせる、といった仕事です。並列コードレビューが例に挙がりやすいのも同じ理由で、観点が独立しているからこそ人数が意味を持ちます。

コードを書かない仕事にも、並べられるものはあります。たとえば、比較記事のために10件の候補をひとつずつ調べる作業。1件ずつ順番にやらせると待ち時間が積み上がりますが、担当を分けて同時に走らせ、結果を1件1ファイルで書き出させれば、まとめる作業だけが手元に残ります。似たところでは、同じ資料を「事実は合っているか」「読み手に伝わるか」「言ってはいけないことが混ざっていないか」の観点で並行して読ませるやり方も、人数が意味を持ちます。観点が独立していれば、扱う題材がコードである必要はありません。

向かないのは、まず一本道の仕事です。前の結果が出ないと次に進めない工程を無理にチームにしても、待ち時間が増えるだけです。次に、短くて小さい仕事も向いていません。10分で終わることに人数をかけると、指示を書いて配って集める手間のほうが大きくなります。人数を増やして良くなるのは、分けても意味が通る仕事だけで、そうでなければ1体に順番でやらせるほうが速くて安いです。

もうひとつ向かないのが、迷いながら決めていく仕事です。企画を練る、方向を決める、言いにくいことをどう伝えるか考える。こういう作業は、こちらの頭が固まっていないまま人数だけ増えると、出てきたものを全部見て回るはめになります。私は、決めきれていないうちは1体と対話して、方向が固まってから分けるようにしています。

すでにサブエージェントで組んでいる人の移行判断

Agent Teamsの解説は「まず何かを知る」ところから始まるものが多いので、すでに自分で分業を組んでいる人向けの話を足しておきます。何を載せ替えて、何を載せ替えないか、という線引きです。

載せ替える価値がありそうなのは、今まで順番にやらせていたけれど本当は同時でよかった仕事です。候補の調査、複数観点のレビュー、条件を変えた検証。待ち時間がそのまま縮むので、体感が変わります。

逆に、すでに順番が決まっていて安定している工程は、無理に載せ替えないほうがいいと思います。私の記事づくりの3段がまさにそれで、調べる前に書きはじめられては困るので、同時に走る利点がありません。同じように、決まった手順としてスキルやコマンドに固めてあるものも、そのまま置いておくほうが事故が少ないです。

もうひとつ、実験的機能ならではの制限も判断材料になります。作業を巻き戻したり、前のセッションを呼び出して続きから再開したりする機能が、チームでは使えない場合があります。途中でやめたら最初からになる可能性がある、という前提で使うということです。長時間かけて進める大事な仕事をいきなり載せ替えるより、失っても痛くない仕事から試すのが無難でしょう。私の場合、最初に載せ替えてみるとしたら、上位記事のリサーチのように「失敗しても最初から調べ直せばいい」たぐいの仕事からになると思います。

よくある質問

Q. Agent Teamsを使うには何が必要ですか？
A. Claude Codeが動いている状態が前提で、そのうえで実験的機能としてオンにする指定が要ります。初期状態ではオフです。1画面で動かすぶんには追加の準備は要りませんが、分割ペインで並べて見たい場合は tmux や iTerm2 といったターミナル側の道具を用意します。契約プランごとの扱いは変わる可能性があるので、公式の案内で確認してください。

Q. エンジニアでなくてもAgent Teamsは使えますか？
A. 使えます。渡す仕事がコードである必要はなく、調べもの、原稿づくり、資料の整形、データの集計といった作業でも同じように分けられます。ただし、Claude Codeそのものがターミナルで動く道具なので、最初の導入だけは少し慣れが要ります。黒い画面が苦手なら、エディタの拡張機能から使う形にすると入りやすいです。

Q. サブエージェントやスキルと併用できますか？どう使い分けますか？
A. 併用できます。私の分け方は、順番が決まっている工程はサブエージェントやスキルに任せて、同時に走らせたい仕事だけチームにする、というものです。役割を書いたファイルはどちらでも資産になるので、先にサブエージェントで役割を切り出しておくと、あとからチームに載せ替えるときも楽になります。

Q. チーム人数やタスク数はどのくらいが実用的な上限ですか？
A. 数の上限より先に、分けても意味が通る仕事がいくつあるかで決まります。観点が独立していない仕事に人数をかけても、同じファイルの取り合いになるだけです。3体前後の少人数から始めて、待ち時間が目に見えて残っているときだけ増やす、という進め方が無難だと思います。増やすほどトークンも増えるので、費用の面でも小さく始めるほうが安全です。

まとめ

Claude Code Agent Teamsは、リーダーとチームメイトが共有のタスクリストを見ながら同時に動く仕組みです。1体に全部を積み上げると頭が埋まって質が落ちるので、役割で割って、それぞれのコンテキストを軽く保つほうがよかった、という話です。私がコードを書かない仕事で先にやっていたことが、そのまま機能として用意された形でした。

使うときの勘どころは、たぶん3つに絞れます。分けても意味が通る仕事にだけ使うこと、同じものを複数に触らせないこと、そして外に出る操作の手前で人が止まることです。実験的機能なので制限もあり、全部を載せ替える段階ではないと思いますが、並べられる仕事から試す価値はあります。

分業させてみて、いちばん変わったのは自分の側でした。手を動かす時間が減ったぶん、何を任せて何を自分で決めるかを考える時間が増えます。作業から手を離したら、判断の粗さのほうがはっきり見えるようになりました。テーマの決め方が甘ければ、何体並べても出てくるものは薄いままでした。AIに仕事を渡していく先にあるのは、暇になることではなく、自分が受け持つ判断だけが残ることなのだと思います。まずは一番割りやすい調べものから、役割を分けて渡してみてください。