AIは1体で回すか複数を束ねるか｜司令塔を置く設計の分岐点

「エージェントを複数立てれば、そのぶん賢くなりますよね」「役割ごとに分けたほうが管理しやすいと聞きました」——設計の相談で最初に出てくる見立てです。ここは丁寧に外しておきたいところで、複数に分けても賢くはなりません。分けて手に入るのは同時に走らせられることと、1つの文脈に収まらない量を扱えることの2つだけです。ある研究開発チームが公開した調べ物の仕組みでは、司令塔となるエージェントが計画を立てて複数の子エージェントを並行して動かす構成が、単体の構成に対して社内評価で90.2%高い成績を出しました。ただし同じ記事は、消費するトークンが通常の対話のおよそ15倍になるとも書いています。この記事では、1体で回すか複数を束ねるかの分岐点を、分けたときに何が壊れるかという側から整理します。

「分けると賢くなる」が成り立たない理由

複数のエージェントに分けて増えるのは、賢さではなく同時に走らせられる量です。1体のときと同じモデルを使うなら、1つひとつの判断の質は変わりません。変わるのは、同じ時間に何本の調べ物を並べられるか、そして1つの文脈に収まらない量をどう分けて扱うかです。

実測もそう読めます。先ほどの調べ物の仕組みは、司令塔が計画を立て、複数の子エージェントを並行して走らせ、返ってきたものをまとめる構成でした。社内の評価では単体の構成に対して90.2%高い成績が出ています。ただし同じ記事は、ある閲覧系の評価で成績の分散の80%がトークンの消費量だけで説明できたとも書いています。

つまり良くなった主因は、分けたこと自体ではなく分けたことで使えるようになった計算量のほうです。トークンの消費量、道具の呼び出し回数、モデルの選択という3つの要素で分散の95%が説明できたとされています。分けたから賢くなったのではなく、たくさん使えるようになったから成績が上がった、と読むのが正確です。

この読み方は実務で効きます。並列にする意味がない仕事に司令塔を置いても、使える計算量は増えず費用だけが増えます。逆に、同時に何十本も調べたい仕事なら、分けた効果は素直に出ます。分ける価値は仕事の形が決めていて、構成の新しさが決めているわけではありません。

用語の整理：司令塔と、担当の引き渡し

言葉を3つだけ揃えておきます。この記事ではこの意味で使います。

引き渡しには大きく2つの形があります。司令塔が中心にいて、子は司令塔としかやり取りしない形。もう1つは、担当同士が横に渡していく形です。横に渡す形は、渡した先が何をしたのかを司令塔が知らないため、後から追えなくなります。

言葉をそろえる意味は、議論の対象を1つに絞れることにあります。「エージェントを増やす」という言い方は、走らせる本数を増やす話と、担当を分ける話を混ぜてしまいます。増えるのは本数か、担当か。この2つを分けて話すだけで、設計の議論はかなり短くなります。

• 本数を増やす＝同じ担当を対象違いで同時に走らせる。前提は共有されたままなので食い違いは起きにくい
• 担当を分ける＝仕事の一部を別の担当に任せる。ここで初めて引き渡しが発生し、前提が落ちる余地が生まれる
• この記事が扱うのは後者。前者は台数を増やすだけの話で、設計の分岐にはならない

課題1：分けた瞬間に、費用の桁が変わる

同じ公開記事には、消費量の目安も書かれています。エージェントの形にすると通常の対話のおよそ4倍、司令塔と子で組むとおよそ15倍のトークンを使う、というものです。少し増える、ではなく桁が変わる。ここを設計の前提として持っておきます。

なぜ増えるのか。子のエージェントは、割り振られた仕事を理解するために前提を読み直します。司令塔は返ってきたものを読んで統合します。同じ情報が何度も読み直されるぶんが上乗せされます。担当を1つ増やすごとに、この読み直しが増えていきます。

費用の判断は、仕事の価値との釣り合いで決まります。調べ物のように、人がやれば数時間かかり、結果が意思決定に直結する仕事なら、15倍でも見合います。一方、定型の分類や要約のように1件あたりの価値が小さい仕事では、15倍は理由なく重いだけです。

見積もりの取り方も決めておきます。1体で通したときの消費量を先に測り、それを基準に何倍まで許すかを決める。基準が無いまま複数構成で始めると、請求が届くまで自分たちが何倍払っているのかが分かりません。基準は20件ほど流せば取れます。

費用を下げる手が、量を増やすより先にあります。同じ記事は、使うモデルを新しい世代に替えることが、古い世代のままトークンの予算を倍にするよりも大きな効果を生んだ、と報告しています。つまり担当を増やす前に、担当ごとに置くモデルを見直すほうが順番として早い。司令塔に判断の重い上位のモデルを置き、子には軽いモデルを置く組み合わせも、この考え方に沿ったものです。

課題2：引き渡しで、前提が落ちる

分けて困るのは費用だけではありません。別の開発チームが公開した記事は、複数のエージェントを組むことの難しさを2つの原則にまとめています。文脈を共有すること、しかも個別のやり取りではなく全体の記録を共有すること。そして行動には暗黙の判断が伴い、食い違った判断は悪い結果を生むことです。

例として、小さなゲームの模作を2体に分けた場合が挙げられています。片方は別のゲームらしい背景を作り、もう片方は求められたものと似ていない主人公を作った。最後にまとめる担当は、噛み合わない2つを組み合わせるしかありません。それぞれは指示に沿って動いているのに、前提が共有されていないために食い違うという構図です。

現場で起きるのは、もっと地味な形です。調査の担当が「この条件に当てはまる先は今回の対象外」と判断して除外した。その判断は結果の文章に書かれず、次の担当は除外されたことを知らないまま集計する。落ちるのは事実ではなく、判断のほうです。

だから同じ記事は、多くの場合は1本の流れで動く構成のほうが良いと結論づけています。非常に長い仕事では、やり取りの履歴を要点・判断・出来事へ圧縮して引き継ぐ仕組みを足す。分けることを避けられないなら、渡す中身を厚くするという方向です。

課題3：どこで失敗したかが、分からなくなる

3つ目は、失敗の原因を特定できなくなることです。1体なら、記録を頭から読めば、どこで判断を誤ったかを追えます。複数になると、結果が悪いことは分かるのに、どの担当のどの判断が原因かが分からない状態になります。

公開されている失敗の例も具体的です。単純な問い合わせに対して子を50体立ててしまう。存在しない資料を延々と探し続ける。複数の担当が同じ作業を重複して行う。いずれも1体の構成では起きにくく、分けたことで初めて生まれる型です。

さらに、道具の呼び出しをまたいで状態を持ち続ける作りのため、小さな不具合が致命的になりやすいとも指摘されています。途中で1体が落ちたとき、その担当の分だけをやり直す仕組みが無いと、全体を最初からやり直すことになります。

追えるようにする手当ては、分ける前に決めます。どの担当が、どの入力を受け取り、何を返したか。この3点が担当ごとに残る作りになっていないなら、まだ分ける段階ではありません。

あわせて残しておくとよいのが、1件あたりにかかった時間と、道具を呼んだ回数です。この2つが入っていると、遅い担当と重い担当を分けて見られます。遅いだけなら並べ方の問題、重いだけなら渡している文脈の量の問題。原因の当たりを付けるまでの時間が、この2列があるかどうかで大きく変わります。

失敗の内訳を、数字で見る

複数エージェントの失敗を体系的に調べた研究があります。7つの枠組みにまたがる1,642件の実行記録に注釈を付け、14の失敗の型に整理したものです。分類は150件をもとに作られ、注釈を付けた人同士の一致の度合いは0.88と報告されています。

14の型は3つに束ねられます。仕組みの設計に由来するものが約44%、担当同士のすれ違いが約32%、仕事の検証に関わるものが約24%。分けたことで生まれる担当同士のすれ違いだけで、失敗のほぼ3分の1を占めます。

内訳のうち、分担の設計に直結するものを拾います。考えたことと実際の手が合わない13.2%、仕事が本筋から外れる7.4%、確認が必要なのに聞き返さない6.8%、他の担当の入力を無視する1.9%、持っている情報を渡さない0.85%。最後の2つは割合こそ小さいものの、起きたときに原因の特定がいちばん難しい型です。

割合の小さい型を軽く見ないでください。やり取りの履歴を失うが2.80%、やり取りが初期化されるが2.20%。足しても5%に届きませんが、これらは起きた瞬間に、それまでの判断がすべて消える型です。件数では小さくても、1件あたりに失われるものは他の型と比べものになりません。直す順番は割合ではなく、起きたときに何が失われるかで決めます。

この研究の含意は、失敗の多くがモデルの限界ではなく組み方の側から出ているという点にあります。裏を返せば、同じモデルのまま組み方を直せば減らせる、ということでもあります。以下では原因を3つに分けて見ます。

原因1：分担の線を、役割で引いている

分け方を決めるとき、最初に出てくるのは役割の名前です。調査役、執筆役、確認役。人の組織をそのまま写した形で、説明もしやすい。ただし役割で引いた線は、情報の共有範囲と一致しません。

執筆役は、調査役が何を見て何を捨てたのかを知らないと書けません。確認役は、執筆役がどの前提で書いたのかを知らないと確認できません。役割で分けると、本来ひとつながりの前提が3つに切られます。切った境目のたびに、先ほどの「判断が落ちる」が起きます。

線を引くべきなのは、前提を共有しなくても成立する場所です。同じ問いを別の情報源で調べる、同じ形式の書類を別々に処理する、独立した5つの候補をそれぞれ調べる。判断が交差しない場所でだけ切る、と決めると、たいていの分割案は消えます。

消えた分割案は、そのまま1体の構成に戻します。役割の名前は、分担ではなく手順の名前として使えば十分です。1体のエージェントが、調べる、書く、確かめるの順に進めばよい。文脈は切れず、記録も1本にまとまります。

原因2：同じ文脈を必要とする仕事を切っている

分けて良い仕事と悪い仕事の線は、先の公開記事にはっきり書かれています。向くのは、並列にできる部分が多い仕事、1つの文脈に収まらない量を扱う仕事、複雑な道具を数多く扱う仕事の3つです。

向かないのは、担当全員が同じ文脈を共有する必要がある仕事と、担当同士の依存が多い仕事です。同じ記事は、プログラムを書く仕事は調べ物に比べて本当に並列にできる部分が少ない、と具体的に挙げています。前の判断が次の判断の前提になる仕事は、切った時点で情報が落ちます。

もう1点、実行中にその場で分担を決めて渡し合う動きは、まだ得意ではないとも書かれています。分担は設計の時点で決めておき、実行中に決めさせない。これがいまの段階での安全側の置き方です。

判定は難しくありません。分けようとしている2つの担当が、同じ資料を読む必要があるかを見ます。あるなら切らない。無いなら切ってよい。この1問で、机上の分割案の多くはふるいにかけられます。

原因3：引き渡しが、結論だけになっている

3つ目の原因は、渡す中身です。子が返すのが結論の3行だけだと、司令塔はその3行を信じるしかありません。何を見て、何を捨て、どこで迷ったかが落ちます。先の原則が個別のやり取りではなく全体の記録を渡せと書いているのは、この点を指しています。

とはいえ全部を渡すと、扱う文脈の量が膨らみ費用も跳ねます。実務では渡す項目を固定します。結論、根拠として使った情報の場所、除外したものとその理由、確信の度合い、次の担当への申し送り。この5項目を様式にすると、渡す量を抑えたまま判断が残ります。

実際にいちばん効くのは、除外したものとその理由の欄です。落ちるのは事実ではなく判断だ、という先ほどの問題が、この1欄でかなり埋まります。次のような閉じ方をしていないかを確認します。

• 子に返させる形式を決めず、自由な文章のまま司令塔にまとめさせる
• 子が参照した情報の場所を返させず、結論だけを受け取って統合する
• 司令塔が受け取った内容をそのまま次の子へ丸ごと渡し、量が周回ごとに膨らむ
• 担当同士が横に渡し合う形にして、司令塔がどの経路を通ったかを把握していない

渡す量が増えて困る場合の逃げ道も、同じ記事に書かれています。やり取りの履歴を、要点・下した判断・起きた出来事の3つに圧縮して引き継ぐ仕組みを間に置く、という方法です。全部を渡すのでも、結論だけを渡すのでもない。圧縮する対象に「下した判断」が明記されているのが要点で、ここを落とすと圧縮ではなく欠落になります。

様式を決めると、副次的な効果もあります。返ってきたものが様式に合っていないとき、それ自体が失敗の合図になります。中身を読んで判断する前に、形の不一致で気づけるぶん、確認は速くなります。

分けたほうがよくなる、3つの条件

ここまでを裏返すと、条件は3つに絞れます。同時に走らせられる部分が多いこと。扱う情報が1つの文脈に収まらないこと。担当同士が同じ資料を読まなくてよいこと。この3つです。

1つ目の目安は、同じ手順を対象だけ変えて繰り返す仕事かどうかです。取引先30社をそれぞれ調べる、5つの候補をそれぞれ検証する、拠点ごとに同じ集計をする。1件の結果が他の件の判断に影響しないなら、並べられます。

2つ目の目安は、読む資料の総量が1回に渡せる量を超えるかどうかです。分けずに済ませようとすると要約を重ねることになり、要約のたびに情報が落ちます。分けて別々に読ませ、結論だけを集めるほうが、どこで何が落ちたかを管理できます。

3つ目は、先ほどの判定と同じです。同じ資料を読む必要が無いこと。3つのうち1つでも欠けるなら、まず1体で作って測るのが順番になります。測った結果、遅すぎる・量が入らないと分かってから分けても遅くありません。

この3つのほかに、公開記事はもう1つ向く場面を挙げています。複雑な道具を数多く扱う仕事です。道具の説明だけで文脈が埋まってしまう場合、担当ごとに扱う道具を分ければ、1体が抱える説明の量を減らせます。ただしこれも、担当同士が同じ資料を読まなくてよいことが前提です。道具を分けても判断が交差するなら、切る意味はありません。

分けないほうがよい、3つの条件

逆の条件も明示しておきます。前の判断が次の判断の前提になること。成果物が最後に1つへ統合されること。1件あたりの価値が小さいこと。この3つです。

1つ目は依存の話です。設計を決めてから実装する、方針を決めてから文章を書く、要件を固めてから見積もる。順番に意味がある仕事は、分けても同時には走りません。分けた結果、待ち時間と引き渡しだけが増えます。

2つ目は、先ほどの小さなゲームの例そのものです。最後に1つへ組み上げる仕事は、組み上げる段で食い違いが表に出ます。統合する担当が食い違いを直せるとは限らず、多くの場合は食い違ったまま出てきます。

3つ目は費用の話です。およそ15倍を払う価値があるかどうかを、1件あたりで見ます。1日1件の重い調査なら見合いますが、1日3,000件の分類には見合いません。件数が多い仕事ほど、1体で軽く回すほうが総額は下がります。

分岐点を、1枚の表にする

ここまでの条件を、判断できる形に落とします。6つの行を見て、右側に寄った数を数えます。

見るところ	1体で回す	複数を束ねる
仕事の形	前の判断が次の前提になる	同じ手順を対象だけ変えて繰り返す
読む資料	担当が同じ資料を読む必要がある	担当ごとに読む資料が分かれる
成果物	最後に1つへ統合する	件ごとに独立して出せる
1件の価値	小さい（件数を回す仕事）	大きい（人なら数時間かかる仕事）
失敗したとき	記録を頭から読めば追える	担当ごとの入出力が残っていないと追えない
消費の目安	通常の対話のおよそ4倍	およそ15倍

使い方は単純です。6行のうち4行以上が右側に寄ったときだけ分ける。3行以下なら1体で作る。境目にあるものは、1体で作って測ってから決めます。

迷ったときは1体を選びます。1体で作ってから分けるのは容易ですが、逆は難しい。分けた構成を1体に戻す作業は、様式・記録・費用の3つを同時に作り直すことになります。

対策1：司令塔が文脈を持ち、子は使い捨てにする

分けると決めたときの形は、いま実務でおおむね一致しています。司令塔が仕事全体の文脈を持ち続け、子は必要な分だけ切り出して立て、終わったら要約を返して役目を終える形です。子が持ち帰るのは要約であって、途中のやり取りすべてではありません。

この形が良いのは、文脈の持ち主が1つに定まるからです。担当同士が横に渡す形だと、誰が全体を知っているのかが曖昧になります。全体を知っている担当が1つだけ、という状態を保つことが、後から追える仕組みの条件です。

子を使い捨てにするのは、状態を持ち越さないためです。前の仕事の記憶が残っている子は、次の仕事に前の前提を持ち込みます。1件ごとに立て直せば、この持ち込みは起きません。速度のために子を使い回したくなりますが、原因の特定が一気に難しくなります。

子の数は固定します。問い合わせの内容に応じて司令塔に決めさせると、単純な問いに50体立てるような事故が起きます。上限は設計の時点で置き、超える必要が出たときは人が設計を見直す。数を動かすのは人の仕事にしておきます。

司令塔への指示の書き方にも、公開されている勘どころがあります。分け方そのものを教えること、問いの重さに応じて割く手間の量を変えさせること、子に渡す指示を曖昧にせず具体的に書かせること。とくに2つ目が効きます。単純な問いにも重い調べ方を当てると、費用だけが増えて結果は変わりません。問いの重さの見分け方は、司令塔への指示に例を並べて書いておきます。

対策2：引き渡しの様式を、先に決める

様式は2つ決めます。司令塔から子へ渡すものと、子から司令塔へ返すもの。どちらも項目を固定し、自由な文章のやり取りにしません。

• 司令塔から子へ：担当する範囲／使ってよい道具／参照してよい資料の場所／返してほしい形式／やらないこと
• 子から司令塔へ：結論／根拠として使った情報の場所／除外したものとその理由／確信の度合い／次の担当への申し送り

「やらないこと」の欄が要るのは、子が範囲を広げてしまうからです。調べ物を任せた子が、勝手に外部へ送信する道具を使う。使ってよい道具を挙げるだけでは足りず、使ってはいけない操作を書きます。範囲の広がりは、結果を見ても気づけません。

返す形式を決めると、司令塔の統合が単純になります。様式がそろっていれば、統合をモデルに任せず、決まった位置の値を並べるだけで済む部分が増えます。モデルに任せる範囲が減るほど、結果は安定します。

様式は文書に書くだけでなく、返ってきたものを機械的に確かめる形にします。5つの欄がそろっているか、根拠の場所が空でないか、確信の度合いが決めた選択肢の中にあるか。この3つは中身を読まずに判定できます。ここで弾かれたものだけを人が見る運用にすれば、担当が増えても確認の手間はほとんど増えません。

対策3：分担をAIに決めさせない範囲を、先に決める

ここが設計でいちばん効きます。分担の構成そのものを、実行中にAIへ決めさせない。どの担当を何体立てるか、どの担当へ渡すか、どこで統合するかは、設計の時点で人が決めて固定します。実行中にAIが決めてよいのは、割り振られた範囲の中でどう進めるかだけです。

人が確認する範囲も、ここで決めます。見るのは個々の子の出力ではなく、司令塔が立てた分け方と、返ってきたものが様式に合っているかの2点です。子の出力を全部読む運用は、件数が増えた時点で必ず破綻します。分け方と様式の2点なら、件数が増えても確認の量は増えません。

根拠を残させることも様式に組み込みます。子には、結論とあわせて参照した情報の場所を必ず返させる。根拠の場所が返ってこない結論は、統合の対象から外す、という規則にしておきます。この規則があると、根拠を出せない担当がどこかを、集計するだけで見つけられます。

先の公開記事も、実行中にその場で分担を決めて渡し合う動きはまだ得意ではないと述べています。できないことを前提に置いて設計を固定するほうが、いまの段階では成果が安定します。将来これが得意になったとしても、固定した設計は動かせばよいだけです。

対策4：1体から2体へ、増やし方の手順

最初から複数構成で組まないことです。1体で作り、測り、必要が確かめられた場所だけを切り出します。順番は5段階で足ります。

増やす前にやることが、もう1つあります。失敗の型を先に潰すことです。先の分類研究では、役割の書き方を直しただけで成功率が9.4ポイント、上位の目標に照らして出来上がりを確かめる工程を足したところ15.6ポイント上がりました。どちらもモデルを替えていません。

担当を増やす前に、いまの担当への指示の書き方と、出来上がりの確かめ方を直すほうが、費用をかけずに効きます。増やすのは、そこを直しても足りないと分かってからで間に合います。

まとめ

1体で回すか複数を束ねるかは、好みの問題でも新しさの問題でもありません。分けて手に入るのは、同時に走らせられる量と、1つの文脈に収まらない量を扱えることの2つだけです。そのために、消費するトークンはおよそ15倍になり、引き渡しのたびに判断が落ちる余地が生まれます。失敗を分類した研究で、担当同士のすれ違いが約32%を占めていたのは偶然ではありません。

判断は6行の表で足ります。仕事の形、読む資料、成果物、1件の価値、失敗したときの追い方、消費の目安。4行以上が複数側に寄ったときだけ分け、迷ったら1体で作る。分けると決めたら、司令塔が文脈を持ち、子は使い捨てにし、渡す項目と返す項目を様式で固定する。そして分担の構成そのものは、実行中にAIへ決めさせない。この線を先に引いておけば、増やすことも戻すことも、あとから落ち着いて選べます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。