AIエージェントに頼めば仕事が形になる場面は、この1年で一気に増えました。

一方で、頼む量が増えるほど、1つのモデルに全てをやらせることの限界も見えてきます。たとえば、設計とコードは見事に組み上げたモデルが、画面に表示する言葉(UXコピー)になると、どうもしっくりこない出力ばかりしてしまうなどです。

今回は、複数のAIモデルに役割を分けて仕事を任せる「分業」のやり方を紹介します。秘書役が1体、プロジェクトごとに現場監督、その下に作業係という構成で、私が毎日実際に使っているものです。

実はこの分業の形は、「Claudeの『リサーチ』機能(いわゆるディープリサーチや高度なリサーチ機能)の中で1年以上前から動いているものです。

公式ブログの図解:
右側が複数モデルによる分業(マルチエージェントリサーチシステム)の様子です。Leadエージェント(オーケストレーター)がサブエージェントに作業を依頼します。

出典:Anthropic「How we built our multi-agent research system」(2025年6月)

Anthropicは2025年6月にその内部構造(指揮役+調査係)を公開し、社内評価では当時の単体の最上位モデル(Claude Opus 4)を90.2%上回ったと報告しています。リサーチで実績のある形を、日常の仕事に広げていきます。

本記事では、分業の仕組みを図解で説明したあと、実際に使っている指示テンプレート10本を、コピペで使える形で紹介します。

そもそもモデルの分業とは?

これは、今に始まったトレンドではありません。
1年以上前の2025年6月、AnthropicはClaudeの「リサーチ」機能の内部構造を公開し、公式ブログでこう説明しています。

Our Research system uses a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.
(Researchシステムは、オーケストレーター・ワーカー型のマルチエージェント構成です。指揮役のエージェントが全体を調整しながら、並列で動く専門のサブエージェントへ作業を委任します)

出典:Anthropic「How we built our multi-agent research system」(2025年6月)


同じ2025年6月ごろから、tmuxという開発ツールで複数のClaude Codeを並列で立ち上げ、「CEO・Manager・Developer」のチームを組む方法が話題になり(AGIラボでも紹介しました)、リサーチだけでなく開発でも、複数のモデルをまとめて指揮するやり方が広まったタイミングです。

そして今日では、Claude CodeやCodexに「サブエージェント」が標準機能として搭載され、分業したモデルたちが数時間にわたって動き続けることも珍しくなくなりました。

AIが自律でこなせるタスクの長さは約7ヶ月ごとに倍増しているというMETRの研究報告もあります。協調のさせ方も、各社が公式ガイドとして型を整理する段階に入っています

METRのグラフ: 縦軸は「人間がやると何時間かかる仕事を、AIが5割の確率でやり切れるか」
2020年は数分だったものが、右端の2026年のモデルでは16時間分の仕事に届きつつあります。


一言で言えば、モデルの分業とは複数のモデルを組織のように動作させるための考え方です。役割を分けるほど、それぞれのモデルの得意分野を使うことができるようになります。


本記事の分業のかたち

本記事で紹介するのは、Chief → Lead → Worker の3段階に分けることです。図にすると以下のようになります。

それぞれの役割はこうです:

  • Chief(秘書役):1体だけ。全プロジェクトの状況を把握していて、各Leadに一斉連絡できる。人間との窓口

  • Lead(プロジェクト監督):プロジェクトごとに1体。そのプロジェクトの文脈を全部持っていて、作業を分解し、Workerに委任し、上がってきたものを検品する

  • Worker(作業係):調査、実装、検証などの単発作業を実行する。終わったら報告して消える

人間が直接会話するのはChiefとLeadだけで、作業をするWorkerとは会話しません。何か処理をしたいときは、Leadに伝えるようにします。

著者が現時点で使っているモデルは、ChiefとLeadにFable 5、WorkerにCodexやGrok、Geminiです。


トークンの使用量や各モデルの性能は数週間単位で変わるため、割り当てはその時々で見直しますが、原則は変わりません:

  • 判断と検品は、その時点で最も賢いモデルに任せる

  • ChiefとLeadに手を動かす作業をさせない:調査・実装・大量処理はSonnet 5などのWorkerへ。上位の役ほどコンテキストを「全体を見る」ことに使う

  • 人間がやるのは4つだけ——任せる(雑に話してOK。誤解されたら一言直すほうが、完璧な指示文を練るより速い)・選ぶ・直す・検品する。例外として、外部へ出す最後の送信だけは必ず人間が行う


また、著者はこの構成を、AGIラボ開発の環境「AGI Cockpit」で運用しています。Claude CodeやCodexのサブエージェント機能を使ったり、複数のチャットを役割ごとに分けたりする形でも同じ考え方で構築できますが、複数のモデルを自在に組み合わせられるのがAGI Cockpitの特徴です。

実際の画面はこんな感じです。本記事についても「新規記事Lead」を立て、その下にレビュワーWorkerや図解作成Workerを配置しています。上から3つ目の箇所です:


ChiefとLead、どちらに指示を出すか

では実際に始めると、ChiefとLeadのどちらに指示を出すべきか迷う場面が出てくると思います。

シンプルに言えば、全体の計画や時間の管理はChiefと、個別の作業はLeadと会話する、という区別です。

深い作業までChiefに頼むと、Chiefのコンテキストがすぐに溢れてしまいます。できるだけ長く管理役を続けてもらうために、Chiefには全プロジェクトの計画と進捗の管理だけを頼みます。


例えば1日の終わりに、Chiefから各プロジェクトのLeadへ一斉に連絡させ、止まっている作業をまとめてもらう。全体を把握した上で、翌日の計画を立てます。実際に作業を進めるときは、そのプロジェクトのLeadと密に会話をしていきます。

ちなみに、この「管理の予定を1日の端に寄せる」という考え方の参考になるのが、ポール・グレアムのエッセイ「メーカーの時間割、マネージャーの時間割」です。気になる方はこちらから読んでみてください。


では、実際にどのような指示を送っているのか。実例を10個用意しました。見ていきましょう。どれも【 】の部分を自分の状況に置き換えれば、そのまま使えます。

テンプレ1:全体の状況同期【Chiefへ】

作業の始めに、今日やることをChiefに組み立ててもらいます。ポイントは、指示を整えてから送ろうとしないことです。音声入力などでやりたいことの雑なイメージさえ渡せば、整理はChiefの仕事です。

プロンプト:

今日のオリエンテーションをお願いします。
やりたい候補は【候補タスク2〜4個】です。
各Leadの状況を確認して、
・私の確認待ちのもの
・止まっているもの(理由つき)
・今日私が判断しないと進まないもの
を優先順で一覧にしてください。最重要【2】個に絞る提案も添えてください。

これで各レーンの状況が優先順の表になって返ってきます。
土日を挟んだ月曜は「先週の振り返り→現状把握→今週の狙い」まで一気に頼むこともあります。

必要なもの:Chief役のタスク(各Leadの報告が集まる場所)/今日やりたいことの雑なイメージ

テンプレ2:1日のまとめ【Chiefへ】

作業の区切りでは、Chiefに戻ってそれまでの作業をまとめるようにします。例えば、「明日やる3つのタスクなんだっけ。そこだけ明確にしてから終わりにします」のように短く伝えます。

型として整えるとこうなります。

今日はここまでにします。
①各Leadに一斉送信して、今日の進捗と止まっているものを回収してください。
②完走済みで成果物も回収済みの子タスクだけ、作業フォルダを残して閉じるよう指示してください。
③回収結果をふまえて、明日やるタスクを【3】つだけ提案してください。私が選んで帰ります。

プロンプト

②が意外に大事です。
ある夕方、PCの重さを感じて「終わった子タスクを整理するよう各Leadに一斉指示を送って」と頼んだら、Chiefは1分後に9つのLeadへ整理指示を送っていました。まとめの作業こそ一斉送信の出番です。

必要なもの:Chiefと各Leadの親子関係ができていること/明日の数を絞る意思

テンプレ3:新プロジェクトのLead起票【Chiefへ】

新しい仕事が始まったら、Chiefに頼んで専属のLeadを立ててもらいます。

プロンプト

新しく【プロジェクト名】を始めます。【資料のパスやリンク】にコンテキストがあるので、Leadを立てて、まず読んでもらってください。
読み終わったら、Leadの解釈を1枚にまとめて見せてもらえますか。作業はそれを私が確認してから。

ポイントは、作業より先に「解釈の確認」を挟むことです。委任の細かい決まりごと(承認が要る操作、報告の形式など)は、一度Chiefに伝えておけば、起票のたびにChiefが指示へ含めてくれます。

必要なもの:プロジェクトの資料(散らばっていてもいい。読むのはLead)

テンプレ4:複数モデル意見会議【Leadへ】