AIエージェントに仕事を任せたら、想定の何十倍ものリソースを消費された。
そんな経験はありませんか？
先日、Redditで興味深い投稿を見つけました。
シンプルなキャンディショップのWebサイトをレビューさせただけの話です。
それなのに、Claudeが116個ものサブエージェントを生成したというのです。
投稿者はProプランを購入した初日の夜でした。
しかし、その夜のうちにクレジットを使い切ってしまいます。
結果、5時間の利用制限がかかりました。
予定していた作業は完全に崩壊したそうです。
何が起きたのか
まず、投稿者の状況を整理しましょう。
使っていたモデルはOpus 5です。
推論の強度はMediumでした。
しかも、雑な指示を投げたわけではありません。
別セッションであらかじめ設計図を作っていました。
コンテキストの肥大化を避けるための工夫です。
プロンプトも構造化されていました。
まず、オーケストレーション役のエージェントを立てます。
そして、観点ごとに役割を割り当てる指示を出しました。
観点はSEO、UI/UX、CTA改善、フロントエンドとバックエンドのバグ、そしてセキュリティです。
それでも、Claudeは116個のサブエージェントを生み出しました。
本人の説明によると、モデル自身がサイズ制限やワークフローの存在を認めていたそうです。
それなのに、大きく逸脱しました。
小さなお菓子屋さんのサイトが、大手銀行より念入りな監査を受ける事態になったわけです。
コミュニティの反応は「ユーザーエラー」寄り
コメント欄では「これはユーザー側の問題だ」という意見が優勢でした。
厳しい話に聞こえるかもしれません。
でも、その理由を読むと納得できる部分が多いんですよね。
ある人はこう例えていました。
やる気満々の新人インターンに、会社のクレジットカードを渡す。
そして「いい感じに改善しておいて」と頼む。
その後、請求書を見て驚く。
そんな状況だと。
つまり、制約がなければモデルは全力を出します。
思いつく限りの角度から問題に取り組もうとするのです。
「このサイトをレビューして」という指示は、モデルには別の意味に化けます。
「すべての観点からすべての問題を見つけろ」という意味に。
一方で、投稿者を擁護する声もありました。
構造化されたプロンプトを与えていたのに、116個は異常だという指摘です。
また、「使い方が悪い」と批判する人ほど投稿を読んでいない、という皮肉なコメントもありました。
この温度差も含めて、実に学びの多いスレッドでした。
なぜ構造化プロンプトでも防げなかったのか
スレッドの中で、特に示唆に富む分析がありました。
LLMの注意力に関するものです。
LLMは多くのことを同時に追跡するのが苦手です。
恒常的なルール、計画書、実装の詳細。
これらが混在すると、区別が曖昧になります。
ガイドラインと絶対的な制限の境界がぼやけるのです。
投稿者は計画ファイルの中に制限を書いていました。
しかし、他の情報に埋もれた制限は弱いのです。
モデルの推論の中で、確実に参照されるとは限りません。
さらに、Opus 5には特有の傾向があると指摘されていました。
サブエージェントを積極的に生成しすぎる傾向です。
コメントによると、Anthropic自身がこの傾向を認めているとのこと。
そのため、ユーザーの承認なしにサブエージェントを起動しないよう、明示的な指示を組み込んでいるそうです。
投稿者の計画には承認が含まれていました。
それが逆に、制限の効力を弱めた可能性があるわけです。
200個の細かいルールを渡したとします。
同時に「コーディング品質にも集中しろ」と要求します。
すると、モデルの注意力は分散します。
だから、絶対的な制限は他のコンテキストから分離すべきです。
これが議論から導かれた教訓でした。
実践的な対策
コメント欄で共有された対策をまとめます。
ここは箇条書きが分かりやすいので、そのまま列挙しましょう。
- スコープを具体的に絞る：「このサイトをレビューして」ではなく、「チェックアウトフローのユーザビリティ問題をレビューして」と指示する。ある人の感覚では、これだけでエージェント数が116個から3〜4個相当に収まるそうです
- CLAUDE.mdに上限を書く：「ワークフローは集中させ、エージェントは最大10〜15個まで」といった一文を入れる。設定変更よりスコープの明示のほうが節約に効く、という声もありました
- ワークフローサイズの設定を確認する：/configにDynamic workflow sizeという設定があります。デフォルトは無制限です。smallなら5未満、mediumなら15未満、largeなら50未満に抑えられます
- Proプランではautoモードを避ける：許可確認を省略するモードは危険です。気づかないうちに使用量を溶かします。何をしているか監視できる状態を保ちましょう
- 些末なタスクにサブエージェントを使わせない：ファイルを1つ探すだけで、サブエージェントが5階層も入れ子になった報告があります。「自明なタスクではサブエージェント禁止」と明記する価値があります
他のユーザーも同じ穴に落ちている
この現象は、投稿者だけの問題ではありません。
「くだらない問題がないか監査して」と頼んだ人がいました。
すると、80個近いエージェントが起動したそうです。
ただし、本人は文句を言っていません。
なぜなら、実際にくだらない問題を大量に見つけてくれたからです。
また、雑な調査指示で300万トークンを消費した人もいました。
途中で気づいたものの、止められませんでした。
サンクコストを感じて、最後まで走らせてしまったのです。
教訓は「明確な指示書を書け」の一言でした。
デフォルト設定への不満も目立ちます。
まるで予算無制限の社内エンジニア向けに調整されているようだ、という意見です。
この見方には多くの共感が集まっていました。
徹底的な仕事をすること自体は、間違っていません。
問題は別のところにあります。
その徹底ぶりが、ユーザーの予算感覚と噛み合っていないのです。
まとめ
今回の事例から得られる教訓はシンプルです。
エージェント型AIは、曖昧なスコープを「全力でやっていい」という許可として解釈します。
構造化されたプロンプトを書いたつもりでも、油断はできません。
制限事項が他の情報に埋もれていれば、モデルはそれを見落とします。
だから、絶対的な制限は分離しましょう。
明確に、そして設定ファイルという確実な場所に書くのです。
高性能なモデルほど、この制御が重要になります。
能力が上がるほど、放し飼いにしたときの消費量も跳ね上がるからです。
魔法のランプの精に願いごとをする場面を想像してください。
条件は正確に伝えなければなりません。
コメント欄には「もし人類が本物の魔神を見つけたら、普通の人は破滅するだろう」という冗談がありました。
案外、本質を突いていると思います。
あなたもAIエージェントに仕事を任せる前に、一度立ち止まってください。
スコープは十分に絞れていますか。
上限は明記しましたか。
その一手間が、クレジットと作業時間を守ってくれます。
