毎朝5時に自動実行される AI リサーチパイプラインを前回の記事で紹介しました。Sonnet 単体で7分、Max プラン定額内でコスト0。十分に動いていました。

しかし「もっと良くできるのでは」という欲が出ました。テーマ選定の浅い日がある。リサーチの深さにムラもある。やりたかったのはエージェントチームの構築です。Opus を司令塔にし、リサーチャーとライターをサブエージェントとして並列に動かす。役割分担された複数のエージェントで1つの成果物を作る — マルチエージェントシステムの実践です。

結論から言うと、品質は上がりました。ただし9倍の時間と2倍のコストには見合わなかった。エージェント間のやりとりが想定以上にトークンを食うという現実に直面し、翌日にはチームを解散して直列のエージェントリレーへ切り替えることになります。

きっかけはポッドキャストだった

AI 系ポッドキャスト「いけとも尾原DeepなAIニュース」で、AI リサーチの自動化を極限まで推し進めている人たちの話を聞きました。

Playwright + ヘッドレス Chrome で Gemini Deep Research を1日200回自動実行
Manus のワイドリサーチで並列エージェント100体、Claude Agent Team でサブエージェント分散

桁が違う。自分のパイプラインは Sonnet 1体で順番にテーマ選定→リサーチ→執筆をやっている。並列化すれば品質と速度の両方が上がるのではないか。

Google Research のマルチエージェント研究も後押しになりました。中央集権型（オーケストレーター）は独立並列に比べてエラー増幅が大幅に低く、Plan-and-Execute（賢いモデルが計画、安いモデルが実行）パターンで大幅なコスト削減が見込めるという内容です。

理論的にはきれいな話です。Opus が「何を調べるか」を決め、Sonnet が「実際に調べて書く」。設計してみることにしました。

設計と「意図しない」構成

アーキテクチャ

Opus オーケストレーター (--model opus)
├── config.toml / past_topics.json 読み込み
├── WebSearch でトレンド調査
├── テーマ選定 (tech + personal)
├── Task: researcher (tech)     ──→ [意図: Sonnet / 実際: Haiku]
├── Task: researcher (personal) ──→ [同上]
├── Task: writer (tech)         ──→ [同上]
├── Task: writer (personal)     ──→ [同上]
├── レポート検証
└── past_topics.json 更新

Sonnet のつもりが Haiku だった

実装して動かし、コストの内訳を確認したとき、目を疑いました。サブエージェントの利用料が異常に安い。

--model opus はメインエージェントにのみ適用され、Task ツールで起動したサブエージェントには継承されない。Claude Code の Task ツールは、モデル指定がなければデフォルトの Haiku にフォールバックします。

つまり、こうなっていました。

意図: Opus (司令塔) → Sonnet (リサーチ・執筆)
実際: Opus (司令塔) → Haiku (リサーチ・執筆)

Opus が緻密にテーマを選定し、詳細な指示を出す。それを受け取るのが最軽量の Haiku。社長が入念に企画書を書いて、インターンに渡しているような構図です。

やり直すべきか、迷いました。ただ、ここで Sonnet に切り替えても「Opus オーケストレーション自体にどれだけの価値があるのか」は分からない。Haiku でこの品質なら、そもそもオーケストレーター自体が不要な可能性もある。まずはこの構成のまま評価して、データで判断することにしました。

LLM-as-Judge でブラインド評価した

「チーム版のほうが良さそうだ」という主観は危険です。自分で作ったものには無意識に甘くなる。

そこで、2日分の全12レポート（Sonnet 4本 + チーム版 8本）をブラインドで LLM に採点させました。どちらの方式で生成されたかを伏せた状態で、テーマ選定・リサーチの深さ・具体性・ソース品質・散文品質・構成・テーマの関連性の7軸（各10点、計70点）で評価します。

定量化の狙いは「なんとなく良い」「なんとなく悪い」ではなく、どの軸で差が出ていて、どの軸で差がないかを切り分けることでした。

結果: テーマ選定だけが圧倒的に違った

全12本の統合スコアです。

指標	Sonnet (n=4)	チーム版 (n=8)	差
平均合計	53.0/70	57.1/70	+4.1 (+8%)
テーマ選定	6.5/10	8.3/10	+1.8 (+28%)
順位	全4本が最下位	上位を独占	—

ブラインド評価で、Sonnet 版は全4本が各トラックの最下位でした。チーム版が上位を独占している。差は明らかです。

ただし、差の内訳を見ると景色が変わります。

テーマ選定は +28%。これは大きい。Opus は「メモリインフラの静かな転換」「瞑想×分子再プログラミング」のように、ニッチだが深掘りしがいのあるテーマを選ぶ傾向がありました。テーマ選定は「複数の候補を多軸で比較し、最も価値の高い組み合わせを選ぶ」タスクです。Opus の推論深度がそのまま効く領域でした。

一方 Sonnet は「Chrome DevTools MCP」のように、目につきやすいが表面的なテーマに流れがちでした。

リサーチの深さや散文品質はほぼ同等。Haiku がリサーチしているにもかかわらず。これは Opus の指示精度が高いことの裏返しでもあるのですが、同時に「リサーチと執筆にはオーケストレーターの深い推論は要らない」ということでもあります。指示通りに実行するタスクでは、モデルの推論深度は差を生まなかった。

エージェント間通信のトークン消費が重すぎた

品質差は分かった。では、この差にどれだけのコストがかかっているのか。

指標	Sonnet 単体	チーム版 (Opus + Haiku)
所要時間	7分	62分（9倍）
コスト	$1.78	$3.53（2倍）
Output tokens	13,906	42,803（3倍）
月間コスト（毎日実行）	〜$54	〜$106

前回記事での Sonnet 単体コストは $2.15 でしたが、プロンプト最適化とターン数調整で $1.78 まで下がっています。

費用対効果が悪い理由は、単に「Opus が高い」だけではありませんでした。エージェントチームに固有の構造的なオーバーヘッドが積み上がっていたのです。

エージェントチームでは、オーケストレーターがサブエージェントに指示を出し、結果を受け取り、次の指示に反映します。この「エージェント間のやりとり」が全てトークンとして消費される。

Opus がサブエージェントに渡す指示プロンプト（テーマの背景、リサーチの方針、期待するフォーマット）
サブエージェントから返ってくる結果の全文が Opus のコンテキストに蓄積される。4つの Task の出力が流れ込み、コンテキストが膨張し続ける
Opus が結果を読み込んで次の判断をする際のトークン消費

Output tokens が Sonnet 単体の3倍（13,906 → 42,803）に膨らんでいたのは、リサーチの深さが3倍になったからではありません。エージェント間の委任と報告のやりとり自体がトークンを食っていたのです。

Opus のコスト（$3.31）が全体の94%。Haiku リサーチャーは $0.21 で済んでいる。コストのほぼ全てが Opus のオーケストレーションとコンテキスト蓄積に使われていたのに、テーマ選定以外の品質差は +6〜8%。

9倍の時間と2倍のコストで +8%。月額で $52 の追加投資。この投資判断は成立しません。

さらに、各 Task の起動と応答待ちのラウンドトリップが4回。並列ではなく順次実行。Opus は Sonnet よりトークン生成が遅い。司令塔自体がボトルネックでした。

Google Research の論文が想定していた Plan-and-Execute のコスト削減は、実行部隊が十分に安く、かつ並列実行できる前提です。Claude Code の Task ツールではサブエージェントのモデル指定ができず（Haiku フォールバック）、並列実行もされない。理論と現実のギャップがそのまま数字に出ていました。

判断: チームを解散し、直列リレーへ

Sonnet サブエージェントに切り替えれば品質がさらに上がる可能性はありました。しかし、コスト構造の問題はモデルを変えても解消しません。オーケストレーターがサブエージェントの結果を全てコンテキストに蓄積する構造が変わらない限り、トークン消費は減らない。

データから導かれる結論は明確でした。

Opus の価値はテーマ選定に集中している。フルオーケストレーターとしては費用対効果が悪い。得意な部分だけ切り出して使うべきだ。

エージェントチーム（オーケストレーターが複数のサブエージェントを束ねる構成）は棄却し、直列のエージェントリレー（以下、2パス方式）に切り替えました。

Pass 1: Opus がテーマ選定のみ実行（〜3分）
  ↓ テーマ JSON をファイル経由で受け渡し
Pass 2: Sonnet がリサーチ + 執筆を一括実行（〜8分）

エージェントチームとの決定的な違いは、2つのエージェントが同一コンテキストを共有しないことです。Pass 1 の出力は JSON ファイルとして書き出され、Pass 2 はそれを読み込んで独立に動く。エージェント間通信のトークン消費がゼロになります。

Opus のコストのうち、テーマ選定に使われる分だけを残し、オーケストレーションのオーバーヘッドを全て削る。理論上は、チーム版のテーマ選定品質（+28%）を、Sonnet 単体に近いコストと時間で得られるはずです。

この2パス方式の実装と、その過程でまた別の問題にぶつかった話は次の記事に書きます。

実験から得た2つのこと

1. 高いモデルは「全部やらせる」より「得意なことだけ」

Opus をオーケストレーターとして全工程に関与させるのは、Opus の推論力を薄く広く使うことになります。テーマ選定のように「多軸で比較して判断する」タスクでは圧倒的な差が出ますが、リサーチや執筆のように「指示通りに実行する」タスクでは差が小さい。

モデルの使い分けは「高い方が良いだろう」ではなく、タスクの性質とモデルの強みが一致する箇所だけに投入するのが合理的です。

2. サブエージェントのモデル継承は事前に実測せよ

--model opus がサブエージェントに継承されない仕様は、ドキュメントを読むだけでは分かりませんでした。コストの内訳を確認して初めて気づいた。

マルチエージェント構成を組むなら、各エージェントが実際にどのモデルで動いているかをログで確認するステップを最初に入れるべきです。

ソースコード

この記事で紹介したシステムの全コードは GitHub で公開しています。