論文が全部ひっくり返した — マルチエージェントの幻想

自作の会話AI MONET（僕がふだん話しかけている中央の Claude。オーケストレーター。以降 MONET）の下にTypewriter、Handler、その他もろもろをぶら下げる。それぞれの中にもClaudeがいて、上のClaudeから指示を受けて自分で考えて動く。AIが他のAIを指揮して、それぞれが自律的に役割を果たす。

このプロジェクトを始めた頃、僕はそれを当然の形だと思っていた。業界もそう言っていた。マルチエージェント、オーケストレーション、自律エージェント。検索すれば毎週のように新しい記事が出てきて、Gartnerは「マルチエージェントの問い合わせが1年で1,445%増」と書いていた。流行のど真ん中だった。

でも作っていくうちに、何か違和感があった。MCP連携を2週間かけて通したあと（その話は別の記事で書いた）、神経網が通って、ようやく「AIがAIに指示を出す」が動くようになった。動いたのに、嬉しさの裏でモヤモヤが残った。

これ、本当に正しい構成なのか・・・。

違和感の正体

違和感は具体的に2つあった。

1つは、伝言ゲーム感。僕がMONETに「Typewriterで投稿の下書きを作って」と言うと、MONETが「TypewriterのClaudeに頼もう」と判断して、MCP経由でTypewriterに指示が飛ぶ。TypewriterのClaudeが「3案作るか」と内部思考して、案を作って、結果を返す。MONETがその結果を「翻訳」して僕に出す。

僕の頭の中にあるのは「下書きが欲しい」だけだ。なのに途中で2人のClaudeが介在する。同じClaudeが、上と下で別々に考えている。1回で済む推論を、2回やっている感覚があった。

もう1つは、嘘の発生場所が増えること。AIが嘘をつく問題（ツールハルシネーション）には別の記事で散々書いた。怖いのは、Claudeを階層的に重ねるとその嘘の発生面積が広がることだった。MONETも嘘をつくし、TypewriterのClaudeも嘘をつく。両方をチェックしないといけない。検証コストが二重になる。

「自律的に判断するAIが連携する」と書くと聞こえはいい。でも実装の手触りは、「嘘をつく可能性のあるユニットが、嘘をつく可能性のある別のユニットに指示を出している」だった。

ただ、これだけだと「マルチエージェントを諦める」までは踏み込めなかった。なんとなく気持ち悪い、で止まっていた。気持ち悪いだけで業界全体の流行を否定するのは、さすがに腰が引ける。

一本の論文

そんな時に目に入ったのが、Anthropic Researchの論文だった。

「Towards a Science of Scaling Agent Systems」（arXiv:2512.08296）。タイトルからして、まさに僕が悩んでいる話だ。エージェントシステムをスケールさせると何が起きるのか、を実証的に測ろうとしている。

読み始めたら、ページをめくるごとに、自分の前提が一個ずつ折られていく感覚があった。

書いてあることが、僕の感覚と完全に一致していた。しかも感覚じゃなくて、データだった。

5つのデータが順番に効いてきた

論文に出てくる主要な発見を、自分のシステムに当てはめながら読んだ。５つあった。

1つ目: ツールが多くなるほどマルチエージェント構成は不利になる。

論文の言い方だと「Tool-coordination tradeoff」、係数 β=-0.267。利用可能なツールの数が増えると、複数エージェントで分担する構成のオーバーヘッドが増えていく。ツールが少ないうちは分担にも意味があるけど、ツールが増えると単一エージェントの方が効率がいい。

MONETは、その時点で既に16個のツールを持っていた。メモリ系、Typewriter系、Handler系、Web検索、もろもろ。これから画像生成のComfyAppもRoundtableも増える予定だった。マルチエージェントが効きにくい条件に、自分から突っ込んでいた。

2つ目: 単体性能がすでに高いと、エージェントを足してもゲインが出ない。

「Capability saturation paradox」、β=-0.404。単一エージェントベースラインの性能が45%を超えると、エージェントを増やしても効果が急減する。底力がある奴を分散させても、もう伸びしろがない、という話だ。

僕が使っているのはClaude Sonnet 4.5。単体でかなり賢い。これを2つに分けても、足し算にはならない。むしろ伝言ゲームのコストの方が大きい。

3つ目: エラーが増幅される。

これが一番こたえた。

構成	エラー増幅率
Independent型（並列実行）	17.2倍
Aggregated型（結果統合）	4.4倍
Orchestrator型（階層構造）	4.4倍

僕の構成はOrchestrator型。つまりエラーが4.4倍に増える。元のエラーが10%なら、構成全体としては44%。これは「ちょっと悪化する」レベルじゃない。設計として破綻してる数値。

僕がツールハルシネーションで延々苦しんでいた理由の一部が、ここで腑に落ちた。AIが嘘をつく確率がそもそも高いところに、エラーが4倍増幅される構造を被せていた。そりゃきつい。

4つ目: 順序依存タスクで壊滅する。

論文の中で一番衝撃だったのが、Sequential（順序依存）タスクの劣化データだった。前の出力が次の入力になるタスク（A→B→Cと進む種類のやつ）で、マルチエージェント構成は -39%〜-70% の性能劣化を起こす。

僕のアプリ、ほぼ全部Sequential。

アプリ	タスクの性質
Typewriter	トピック → 草案 → 修正 → 投稿
Handler	議論 → タスク化 → 実行 → 報告
ComfyApp	テーマ → 構造 → 執筆 → 推敲

全部、前の段の出力を次の段が受ける形をしている。これらをマルチエージェントでやると、論文のデータでは半分くらいまで性能が落ちる。Typewriterの「投稿の質がなんとなく薄い」感覚は、ここに一部由来していた可能性がある。

5つ目: 例外もある — Decomposable（分解可能）タスク。

ここまで読むと「マルチエージェント全否定か」になりそうだけど、論文はそこまで言っていない。タスクが独立した部分問題に分解できる場合（Aggregated型）、+80.8%の改善が出る。並列で別々のことを同時にやって、最後にまとめる、という形なら効く。

ただし、依存関係があったら効果はゼロ。僕のシステムでこれに当てはまるアプリを数えると、Librarian（メモリの並列サマリー）とRoundtable（複数LLMの並列リサーチ）の2つだけだった。

自分のシステムが、データの上に置けた

ここまで読んだところで、自分のシステム全体を一度ノートに書き出した。

各アプリのタスクが、論文上のどのカテゴリに当たるか。マルチエージェントで効くか、効かないか。

アプリ	タスク性質	マルチエージェントの効果
Typewriter	Sequential	大幅劣化
Handler	Sequential	大幅劣化
ComfyApp	Sequential	大幅劣化
Librarian	Decomposable	改善の余地
Roundtable	Parallel Independent	最適

並べた瞬間に、結論はもう書かれていた。

ほとんどのアプリはマルチエージェント不向き。一部だけ、それも構造が完全に独立しているものだけ、マルチエージェントで効く。

「マルチエージェントは正しい」じゃなかった。「タスクの構造によっては正しい」だった。そして僕のシステムの大半は、その「正しい」側に入っていなかった。

完全体への収束

この段階でこの情報が来るのか・・・としばらく落ち込みつつ考えて、決めたことがある。

MONETに集約する。Typewriter、Handler、（将来の）ComfyAppは、AIを抜いて実行デバイスにする。Claudeは中央に1人だけ。下のアプリはツールを叩くと動く箱になる。

簡単に書くと、こういう構造になる。

中央のClaude（Sonnet 4.5）
├── Skills（人格と専門性）
│   ├── 自分の価値観
│   ├── オーケストレーターの基本
│   ├── typewriter専門性（Typewriter人格を統合）
│   ├── handler専門性（Handler人格を統合）
│   └── ...
│
└── ツール（実行デバイス）
    ├── typewriter_post → 実行のみ（AIなし）
    ├── handler_create_task → 実行のみ
    ├── librarian_batch → AI保持（バッチのみ）
    └── ...

Typewriter「専門性」というスキルを作って、それを中央のClaudeに装備させる。Typewriter人格そのものを、上の階層に統合する。下にいたClaudeを上に「吸い上げる」とでも言えばいい。

理屈はシンプル。Sequentialなタスクは1人で完結させる方が論文上明確に強い。Claudeが2人いて伝言ゲームをするより、1人が全部の専門性を持って通しでやる方が、性能が出る。

エラー増幅も消える。階層がフラットになるから、4.4倍のペナルティがそもそも発生しない。

伝言ゲームによる「翻訳」も消える。中央のClaudeが「下書きを作る」と判断して、そのまま投稿ツールを叩く。間に翻訳役がいない。

例外の2つ

ただ、全部を中央に飲み込むわけじゃない。論文のデータがそう言っていなかった。

Librarianはそのまま残す。タスクがDecomposable（複数のメモリを並列にサマリーする、独立に処理できる）で、しかも往復がない。バッチで動く。中央のClaudeと会話する必要がない。Librarianは独立に動いて、結果をスキルファイルに書き出して、中央のClaudeが次回起動時にそれを読む。

Roundtableは中央の下に置かない。タスクがParallel Independent（複数のLLMで並列にリサーチして、最後にまとめる）。論文上、ここはマルチエージェントが最適な領域だ。

ただし、Roundtableを「中央の下」に置くと、また階層構造になってエラー増幅が出る。だからRoundtableは独立したアプリにする。中央から「Roundtableで調べてきて」と依頼を出して、結果を受け取る。中央が会話を引き継ぐわけではない。

書きながら、これは「マルチエージェントの否定」じゃなくて、「マルチエージェントを置いて意味がある場所と、置いても劣化するだけの場所を、論文のデータで切り分けた」だけだと気づいた。

否定じゃない。配置の話。

論文を読み終えて、一通りノートに書き出して、正直、複雑だった。

でもようやく腹落ちした感はあった。「やっぱりおかしいと思っていた」が、データで裏打ちされた感覚。違和感の正体が言語化されて、しかも数字までついてきた。これは大きい。

でも同時に喪失感もあった。Typewriterの中にいたClaude、Handlerの中にいたClaude。あれを抜くということは、僕がせっかく作ったあの構造を半分壊すことを意味する。MCP連携に2週間かけて、ようやく神経が通った構造だ。それを「論文がそう言ってるから」で再設計する。

論文がなかったら同じ決定に至ったか、と聞かれたら、たぶん時間はかかった。違和感だけでは踏み切れなかった、というのが正直なところ。論文は「踏み切る根拠」だった。「論文がそう言っているから」と自分に言い聞かせて、業界全体の流行に逆らう判断を、自分で決めた。

それくらい、業界の空気は強かった。マルチエージェント、自律オーケストレーション。今でも検索すれば、それが正しい未来として語られている記事が山ほど出てくる。データに反していようと、流行は流行として動いていく。

「エージェントは多い方がいい」という常識

書きながら一つ思っていることがある。

「エージェントは多い方がいい」という発想は、人間の組織の比喩から来ているんじゃないか。専門家を集めて分業させればチームは強くなる、という前提。

でも論文のデータが示しているのは、LLMはそのアナロジーで考えるべき対象じゃない、ということだった。

人間の組織が分業で強くなるのは、1人の人間が持てる知識やスキルに限界があるからだ。1人で全部やろうとすると、専門性が浅くなる。だから分けて、それぞれが深くなる。

ところがLLMは、Sonnet 4.5レベルになると、もう既に「1人で十分深い」状態にある。これに分業を被せると、深さは足し算にならない。むしろ伝言と検証のコストの方が、深さの恩恵を上回る。

人間の組織設計の比喩で、LLMのシステムを設計してはいけなかったのかもしれない。少なくとも、性能のことだけ考えるなら。

この決定の後、Typewriter、Handlerからそれぞれ実際にAIを抜く作業に入った。Action enumっていう設計を入れて、tool_choiceとWatchmanを組み合わせて、ツール捏造を構造で封じる流れに進んでいく。

業界が「マルチエージェントすごい」と言っている時に、Anthropic Research自身が「マルチエージェントは条件次第ですよ」というデータを出してきた、というのも面白い構図だなと思っている。販売したい未来と、測ったらこうだったという現実が、同じ会社の中で並走している。