ここ数日、X の AI 界隈で「マルチエージェントはやめて、1つのループに戻せ」という話がよく流れてきます。元ネタは、Anthropic の Applied AI チームが10月22日に出した「Building agents: When to fold subagents into your main agent loop」という記事です。
ざっくり言うと、「受付係のAI、予約担当のAI、請求担当のAI……と役割ごとにエージェントを分けて、上に司令塔を置く」作り方より、「1つのエージェントに、仕事の手順（スキル）と道具（ツール）を持たせて、必要なときだけ読み込ませる」作り方のほうが、品質が良くて速くて安いことが多かった、という内容です。
「AIエージェントを何体も組み合わせて業務を自動化しましょう」という提案、最近よく見かけますよね。今回は、この記事のポイントと、中小企業やお店が AI の業務フローを組む（または頼む）ときに参考になるところを、作る側の目線で書いてみます。
01｜記事で言っていること
記事によると、Anthropic がいくつかの企業の導入事例を比べたところ、「スキルを持たせた1つのエージェント」が、「全部を1つの長いプロンプトに書く作り方」と「サブエージェントに分ける作り方」の両方より品質で上回ることが多く、1件あたりのコストや待ち時間も小さいことが多かったそうです。
具体例として挙げられているのはこんな話です。
- ある会社は、お客さん向けのAIの中に十数個の専門サブエージェントを持っていて、ブランドとして一貫した対応を保つのが難しく、待ち時間も体験を悪くしていた
- マルチエージェントの仕組みと1つのループを比べたある会社では、1つのループのほうがおおよそ2倍速く動いた
- Anthropic 自身も、Claude Code の（新しいモデル向けの）システムプロンプトを、スキルやツールを必要なときだけ読み込む形にするなどして 80%以上削った
ただし、ここに出てくる数字は Anthropic 自身の事例で、詳しいデータは記事に載っていません。「そういう傾向が見えた」くらいに受け取っておくのがよさそうです。
02｜なぜ「分けると」悪くなるのか — 伝言ゲームと組織図
記事で一番刺さったのは、エージェントの構成が組織図のコピーになっているという指摘です。チームごとに自分のエージェントを作って、最後に誰かが司令塔を上に乗せる。一見きれいなんですが、こういう問題が出ると書かれています。
- 伝言ゲーム：エージェントの間で要約を渡し合うたびに、細かい情報が抜け落ちる
- エージェントの乱立：各チームが作るので、似たようなものが増えて、誰の持ち物かわからなくなる
- 継ぎはぎのプロンプト：みんながシステムプロンプトに1文ずつ足していって、ルール同士がぶつかり、話し方もバラバラになる
- 待ち時間：エージェントがエージェントを呼ぶたびに、そのぶん待つ
これ、大企業だけの話ではないと思っています。小さい会社でも、「問い合わせ対応用」「予約用」「SNS投稿用」と、用途ごとに別々の AI ツールや GPT を作っていくと、同じことが起きます。お店のルール（営業時間や返金の扱いなど）が5か所に書いてあって、1か所だけ古い、みたいなことです。
逆に、1つのエージェントが最初から最後まで同じ文脈を見ていれば、前のステップの結果をちゃんと踏まえて次を考えられる。記事でも、要約を受け取るより、全体を見ているほうが良い答えになると書かれています。
03｜じゃあ、どう組むのか
記事が勧めている形を、かみ砕くとこうなります。
- AIは1つ、文脈も1つ。 そのAIが最初に計画を書いて、ツールを呼んだ結果を見ながら、自分で計画を直していく
- 仕事のやり方（手順・ルール・判断の勘所）はスキルに書く。 普段は短い説明だけ見せておき、必要なときに中身を読み込ませる
- 実際に何かする部分（データを読む、予約を入れるなど）はツールにする。 ツールはAPIごとに1つではなく、「やりたいこと」の単位でまとめる。記事では、ツールの定義が30〜50個を超えるとツール選びが悪くなりがちだとしています
- 絶対に破ってはいけない制限は、プロンプトではなくツールの側で止める。 上限回数や金額、承認が要る操作などは、AIへのお願いではなく仕組みで止める
- 参考資料（規約、商品仕様など）は、検索できる場所に置いて、必要なときに引かせる
たとえばお店の LINE の問い合わせ AI なら、イメージはこんな感じです。
AI（1つ）
├─ スキル：予約変更の受け方 / キャンセル規定の説明のしかた / クレームの一次対応
├─ ツール：空き枠を調べる / 予約を変更する（※当日分は店長承認がないと通らない）/ お客さん情報を見る
└─ 資料：メニューと料金表、よくある質問
「予約担当AI」と「キャンセル担当AI」を分けて、司令塔AIに振り分けさせるのではなく、1つのAIが手順書と道具を持っている形です。「当日の変更は店長の承認が要る」というルールは、プロンプトに「当日は変更しないでください」と書くのではなく、予約変更ツールの側で弾く。AIが言うことを聞くかどうかに頼らない、ということです。
04｜とはいえ、分けたほうがいい場面もある
記事は「いつでも1つが正しい」とは言っていません。サブエージェントを使うべき場面として、次の3つを挙げています。
- 1つのループに情報を詰め込みすぎて、測ってみて実際に性能が落ちているとき
- 複数の作業を並行して進めたくて、終わったら捨てていい新しい文脈が欲しいとき
- 1つのAIがツール選びを間違え続ける、またはプロンプト内の指示がぶつかっているとき
分けるにしても、「問題の種類」ではなく「文脈」で分けるのがコツだそうです。他とほとんど関係なく進められて、結果を短く返せる仕事（独立した調べもの、外から答え合わせだけする検証など）が向いている、と。
ちなみに、このブログの前の記事（Jev の使い所）では「安いモデルで先にカテゴライズして、必要な情報だけ読ませて高いモデルで答える」という作り方を書きました。これも一種の振り分けです。今回の記事を読んで、僕はこれを全部やめるべきだとは思っていません。コストが効いているなら残す価値はある。ただ、「なんとなく分けたほうが賢そうだから」で分けるのはやめて、分けた場合と分けない場合を比べてから決める、というのが今回一番持ち帰りたいところです。
05｜自分ならこう始める — まず「答え合わせ用の10問」
記事の移行手順で一番いいなと思ったのは、最初に評価用のテストを作るところです。しかも「10個くらいの正解例から始めれば十分」と書いてあります。
小さい会社やお店でも、これはすぐできます。
- よくある問い合わせを10個書き出す。 「来週の土曜に予約を変えたい」「キャンセル料はかかる？」など、実際に来たものがベスト
- それぞれに「こう答えてほしい」「これはやってはいけない」を書く。 「当日の変更は受けずに店長につなぐ」など
- AIの作りを変えるたびに、この10問を通す。 しかも1回ではなく2回以上通す
2回以上というのにも理由があって、記事の中で Anthropic がサンプルのサポート用エージェントで試したところ、サブエージェントを1つ畳んだら速くはなったけど、前は通っていた処理が壊れた。しかもその壊れ方は2回に1回しか出なかったそうです。AI は毎回同じ答えを返すとは限らないので、1回通っただけで安心しないほうがいい。
あと、点数の合計だけでなく、どの問題が「通る→通らない」に変わったかを見る。合計点が同じでも、大事な1問が落ちていたら意味がないからです。
「AIエージェントを何体も組み合わせます」という提案を受けたときも、「この構成にした理由は？」「1つで作った場合と比べました？」と聞いてみると、相手がちゃんと考えているかがわかると思います。僕らも AI を組み込むときは、この順番（テストを先に作る、1つずつ変える、比べて残す）でやっていくつもりです。