「ディープサーチしてくれ」。
そのひと言だけで、AIが70個のエージェントを自力で立ち上げました。
これはRedditに投稿された体験談をベースにした話です。
コミュニティの反応も含めて、マルチエージェント型ワークフローの本質をよく突いています。
すごい話であると同時に、怖い話でもあります。
何が起きたのか
Claude CodeのUltracodeモードでディープサーチを指示したところ、
Claude Codeはシングルセッションで処理する代わりに、4フェーズのパイプラインを組みました。
構成はDiscovery → Benchmark → Enrich → Verifyで、各フェーズに複数のサブエージェントを並列展開しています。
合計70個近くのエージェントが独立して動き、それぞれ情報をフェッチしてクロスチェックした形です。
進捗は /workflows でリアルタイムに確認でき、完了後には自動通知も届きました。
これが「すごい」と感じられる理由は直感的です。
同じリサーチ作業を1エージェントで直列処理しようとすれば、コンテキストウィンドウはあっという間に埋まります。
でも、70エージェントが並列で動けば、その制約を超えられます。
なぜコンテキストが溢れないのか
ここが技術的な核心です。
通常のセッションでは、会話履歴・中間結果・エラーログなど、あらゆる情報がひとつのコンテキストウィンドウに積み重なっていきます。
10エージェントも動かせば、オーケストレーター自身のコンテキストが限界を迎えます。
Ultracodeはその問題を構造で解決します。
オーケストレーション用のスクリプト（ループや中間状態）をモデルのコンテキスト外に置くのです。
各エージェントは独立した新鮮なコンテキストで起動し、最終的な答えだけが会話に戻ってきます。
だから、オーケストレーターは70エージェントを束ねても溺れません。
「オーケストレーションをコンテキストの外に追い出す」という発想は正しい方向性だと、コミュニティも概ね認めています。
ただ、問題は別のところにあります。
コストという壁
70エージェント = 70個のコンテキスト起動。
つまり、1セッション分のオーバーヘッドが70回かかります。
投稿者自身もこう振り返っています。
5時間分の使用上限を約10分で使い切りました。
従量課金を有効にしていなかったおかげで追加請求はありませんでした。
しかし、上限に即座にぶつかりました。
もし従量課金が入っていたら、眠っている間に数千ドルの請求が来ていた可能性もあります。
実際にコミュニティでは、こんな報告もあります。
「113エージェントを起動させたが、通常チャットより悪いレポートが出てきた」。
コストと品質がトレードオフになるどころか、コストだけ増えて品質が下がるケースも十分ありえます。
別の事例もあります。
「シンプルな中規模コードベースのコード検証に、47個ものOpus 4.8インスタンスが起動した」というものです。
その後、その人はガードレールなしではワークフローを動かさないようにしたといいます。
「ドライラン」がない問題
コミュニティが繰り返し求めているのが、事前見積もりと予算キャップです。
現状、エージェントが何個展開されるかは、ワークフローが始まってからわかります。
エージェントは「自分が何を知らないか」をスタート時点では把握できません。
そのため、正確な事前見積もりは難しいです。
それでも「小・中・大の規模感」「想定エージェント数」「早期停止の条件」くらいは表示できるはずです。
それだけで「気づいたら超高額になっていた」という事態の多くは防げます。
多くのユーザーが共感しているのは、こんなシンプルな仕組みです。
- 推定コストを事前に表示する（例：10〜15ドル）
- 上限（例：20ドル）を超えたら中断し、承認を求める
セッションをまたぐと記憶が消える
もうひとつ、見落とされがちな問題があります。
クロスセッションのコンテキスト喪失です。
「なぜこのアプローチをやめたのか」「この設計判断の背景は何か」。
そういった意思決定の文脈は、セッションが終わると消えます。
次のセッションでは同じ文脈を再導出するところから始まります。
つまり、同じコストを何度も払い続けることになります。
この問題に実践的に対処している人もいます。
「共通エラー」「技術的負債」といったテーマで永続的なMarkdownドキュメントを用意し、エージェントが毎セッション参照する形にするのです。
また、タスクの種類でモデルをルーティングする方法も有効です。
- ファイル読み込みや軽いタスク → Haiku
- コード生成 → Sonnet
- アーキテクチャ判断 → Opus
このように振り分けると、同じ成果で大幅にコストを抑えられるといいます。
結局、使う価値はあるのか
投稿者本人が出した結論は、「正直わからない」に近いものです。
見ていて圧倒されるほど印象的でした。
でも、結果の品質を検証する前に使用上限に達してしまいました。
今後は手動でエージェントを呼び出しながら、人間が途中でチェックを入れる形に戻すつもりだとも書いています。
経験豊富なユーザーが出した判断基準は、シンプルで実用的です。
- 30分未満の手作業 → 単一エージェントで対応
- 並列化が本当にターンアラウンドタイムを縮める場合のみ → ワークフローを使う
ワークフローはデフォルトではなく、専門道具として扱う。
これが現時点での現実的な使い方です。
アーキテクチャの一発監査のような、一回きりで深い調査が必要なタスクなら話は別です。
エンジニアの数時間分の工数を節約できると考えれば、数百〜数千円のトークンコストは十分ペイします。
逆に、日常の小さなバグ修正に使うのは完全にオーバーキルです。
まとめ
マルチエージェントのアーキテクチャとしての方向性は正しいです。
コンテキストウィンドウの制限を構造で解決するアプローチは、スケールの大きなタスクに対して本質的な突破口になりえます。
ただし現時点では、コスト可視化の仕組みが追いついていません。
「ドライランモード」「段階的な予算承認」「モデルルーティング」。
こういった機能が揃って初めて、一般のユーザーが安心して使えるツールになります。
今の段階では、タスクの規模に対して本当にマルチエージェントが必要かを自分で判断できる人向けのツールです。
その判断ができないまま動かすのは、白紙委任状を渡すようなものだとコミュニティは言います。
それは言い過ぎでもないと思います。
