AIDiveイントロ: 同じチェック、2倍のメーター、5つの上限
ultracodeは、Claude Codeに入力する1つの依頼をエージェントのチーム全体に変えるキーワード、またはトグルです。同じ仕様で行ったペアテストでは、2つの実行が同じ隠しチェックに通り、ultracode実行はセッションメーターを2倍以上使いました。理由はモデルが賢くなったからではありません。ハーネスが注入する一文と、オフになる3つのガードです。
この記事では4つのことを扱います。
- プランのメーターで読むペアテスト。
- 複数のペアで見たトークンの倍率。
- 単独のエージェントが14個のバグを見つけた一方で、チームが仕込まれた66個を見つけた、ある種類の仕事。
- 実行があなたの1週間を食い潰す前に上限をかける5つの設定。そのうち1つは、usage limit そのもので実行を止めます。
ultracodeが切り替えるもの: キーワード、トグル、エージェントのworkflow
ultracodeには2つのスイッチがあります。1つのプロンプトの中に ultracode と入力すると、セッションのeffortレベルには触れずに、そのタスクだけをworkflowとして走らせます。/effort コマンドからトグルを入れると、Claudeはすべての実質的なタスクでworkflowを計画するようになり、1つの依頼が続けて複数のworkflowになることがあります。
workflowとは、Claudeが自分のために書くスクリプトで、そのスクリプトがエージェントのチームをフェーズごとに動かします。小さなサンドボックス(promiseの扱いが雑なファイルが2つ、読み取り専用のレビューを依頼)では、Claudeはファイルを偵察し、「unhandled promise audit」と名付けたworkflowを展開しました。プロンプト欄の下にはタスク行が現れ、進捗バー、エージェント数、経過時間、増え続けるトークン合計が表示されました。/workflows コマンドは、エージェントごとに1行とそれぞれのトークン数を一覧にし、一時停止、停止、再開のキーも備えています。
その実行では、検証役が動き出す前の時点で、各finderがすでに約45,000トークンを読んでいました。対象はわずか数行のコードです。
どのセッションにもサイズの目安があり、Claudeが超えないよう勧められるエージェント数を示します。
| サイズの目安 | 推奨されるエージェント数 |
|---|---|
| small(Proのデフォルト) | 5未満 |
| medium | 10未満 |
各エージェントは、あなたの会話の上に自分のリクエストを送ります。workflowの請求は1回分ではなく、エージェントの数だけあり、メーターはそのすべてを数えます。
ペアテスト: 同じ136のチェック、8パーセント対18パーセント、止まらない
ある開発者が、最上位のサブスクリプションプランで、きれいな条件でコストを測りました。小さな表計算アプリの同じ仕様、同じモデルと同じeffortで、通常実行を1回、ultracode実行を1回行いました。どちらも隠しチェック、つまりモデルが見ないテストで採点され、2つとも136個すべてに通りました。
| 実行 | 終了 | 使ったセッション上限 | 通ったチェック |
|---|---|---|---|
| 通常 | 自力で終了、25分 | 8 % | 136 / 136 |
| Ultracode | 76分で時間切れ、まだ確認中 | 18 % | 136 / 136 |
ultracode実行の中で、Claudeはチームを動かすことだけが仕事のスクリプトを書きました。数えられたエージェントは12で、テスター、数人の審査役、そのあとページを壊すのが仕事の「breaker」たちです。breakerの1人が、数式バーの実際のバグを見つけました。別のセルをクリックしたあとも、古いテキストが表示され続けるというものです。
1分あたりで見ると、ultracode実行は通常実行とほぼ同じ速さで上限を使い、平均ではむしろ少し遅いくらいでした。燃え方が速かったのではなく、止まらなかったのです。ultracodeはClaudeを賢くするのではなく、Claudeに確認させるものであり、その確認のたびにあなたが払います。これは小さな仕様での1つのペアで、2回目の実行は時計で打ち切られましたが、形ははっきりしています。答えは同じで、セッション枠は2倍以上、増えた時間はすべて確認でした。
なぜ高いのか: 一文と、外れた3つのガード
モデルは同じです。変わるのは、ハーネスがモデルに渡すテキストです。ハーネスとは、Claude Code自体、そのツール、モデルのまわりの指示のことです。
ultracodeがオンのとき、Claude Codeはworkflowを書く前にリファレンスを読み込みます。そのテキストは、実質的なタスクのたびにデフォルトでworkflowを走らせるようモデルに伝え、請求を説明する一文を含んでいます。「The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint.」これはハーネス自身のテキストで、公開のGitHub issueにも同じ行が引用されています。
同時に3つのガードがオフになります。
- 実行が多すぎるエージェントをスケジュールしたときに通常出る、大規模workflowの警告が出なくなります。
- 同時に動かせるエージェント数というセッションの制限が、Claudeが生み出すエージェントには適用されません。
- autoモードでは、最初の起動が承認に回されません。
サイズの目安は助言であり、上限ではありません。サンドボックスでsmall(5エージェント未満)に設定しても、ultracode実行は9つを生み出しました。公平のために言えば、その一文はモデルがまだ天秤にかけられるデフォルトであり、ガードは非常に大きな仕事のために意図的に外されています。答えは一行に収まります。ultracodeはモデルを変えず、指示を「すべてにチームを、コストは制約ではない」に変えるのです。
倍率: 3組のペア、effortの段階、30倍のペア
2人目の開発者が、Proプランで、単独エージェントとworkflowのペアを複数回走らせました。レビュー形式のスクリプトで、毎回、前後で使用量メーターを読んでいます。
| 指標 | 単独エージェント | Workflow |
|---|---|---|
| 1つのレビュースクリプトのトークン | 約115,000 | 972,000 |
| ペア全体のトークン倍率 | 1x | 最大18x、発見はほぼ同じ |
| メーターの動き | 1x | 最大3x |
| 実時間 | ほぼ同じ | ほぼ同じ |
workflowは速く終わりませんでした。待つ時間は同じなのに、使う量は増えたのです。並列が元を取った唯一の場面は独立した調査ジョブのバッチで、エージェントは速く終わりましたが、それでもトークンは2倍以上でした。
3つ目のテストでは、APIの価格で、すべてのeffortレベルでいくつかの小さなアプリを作りました。段階を1つ上げるごとに請求はおよそ2倍になり、ultracodeは max の数倍の費用になったのに、一度も首位に立ちませんでした。それらのトークンの大半はキャッシュ読み取りという安いものでしたが、出力トークンのごくわずかな部分が費用のほぼ半分を占めました。
もう1つのペアは都市のシーンです。単独エージェントは約1時間で、APIの価格で数ドル。ultracode実行はほぼ丸1日かかり、数十のサブエージェントを使い、費用は約30倍でした。
これらは整数単位のメーター読み取り、APIの価格で作ったゼロからのアプリ、1つの都市シーンなので、どれも単独ではスコアボードになりません。ただ、並べるとパターンはいつも同じです。ファンアウトが買うのは確認とカバー範囲であり、仕事が独立した部分に分かれない限り、より良い答えではありません。
ファンアウトが報われる場面: 判定役のテストスイートと一行のルール
この形の仕事は確かにあります。移行、監査、コードベース全体への一括処理です。
Bunは、Claude Codeで約50の動的workflowを11日間連続で走らせ、ZigからRustに書き直されました。Zigのソースは50万行を超え、着手から、同じ期間内にすべてのプラットフォームでテストスイート全体が通るところまで到達しました。うまくいった理由はエージェントの数ではなく、判定役です。既存の巨大なテストスイートが、誰の意見も介さずに合格か不合格かを示しました。
Anthropicのバグ探しも同じことを示しています。大きなコードベースに70個のバグを仕込み、単独エージェントを複数回走らせました。
| エージェント | 70個のうち見つけたバグ |
|---|---|
| 単独エージェント(3回) | 14、15、27 |
| Workflow(3回) | 毎回66 |
注意点が1つあります。このテストはClaude Managed Agents、つまりAPIの製品で行われ、Claude Codeではありません。コストも示されていません。
ローンチのスレッドには、報告されている他の成功例が載っていて、どれも似ています。ルールファイルに対するレビュー、コードベース全体の翻訳、スキャンされたページの山の整理です。ローンチのブログははっきり書いています。従来のコーディングタスクの大半には、5人のレビュアーのパネルは要りません。
ルールはこうです。テストスイートまたはルールセットが出力を判定し、仕事が独立した部分に分かれるときだけ、ファンアウトする。それ以外はhighで普通に走らせる。ペアテストをした人も、自分の言葉で同じことを言いました。確認そのものが仕事である場面、たとえば何百ものファイルにまたがる移行のために取っておく、と。
実行を抑える5つの設定
それぞれの上限は、すでに知っている場所にあります。
| # | 設定 | 場所 | 効果 |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config のDynamic workflow size、またはsettings.json |
助言(5エージェント未満)で、大規模workflow警告のしきい値も下がる |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
環境変数、起動前にexport | デフォルトで最大16エージェントが同時に動く。4にすると残りは待ち行列に入り、実行を殺さずに燃える速度が落ちる |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
環境変数 | 他のサブエージェントはそのままで、すべてのworkflowエージェントを選んだ1つのモデルで動かす。安いモデルなら確認も安くなる |
| 4 | ultracode キーワード、トグルは使わない |
プロンプトの中。settingsの ultracode キーは使わない |
キーワードは1つのタスクをworkflowとして走らせて終わる。トグルは切るまで常時になる |
| 5 | autoContinueAtUsageLimit |
settings | オン: 上限に当たった実行は一時停止し、リセットを待って続き、これを複数回行う。オフ: エージェントは壁で失敗し、実行はそこで終わる |
3つの習慣がこれに加わります。ローンチのブログによると、「use 10k tokens」のようにプロンプトに書いた予算が上限になります。実行のあとは、/usage で最近の使用量のうちサブエージェントとworkflowにどれだけ回ったかが分かり、それらが支配的なときは警告が出ます。実行中におかしいと感じたら、/workflows ペインと x キーで止められ、ここまでの作業は通常残ります。
どれもエージェントを安くするわけではありません。実行が使えるエージェントの数と、使い続けられる時間に上限をかけるものです。
暴走した実行、上限、結論
公開されたある報告は、1週間がどう消えるかを示しています。最大のプランで、モデルが書いたスクリプトが1時間足らずで221のエージェントを起動しました。最初のセッション上限エラーのあとも、スクリプトは配布を続け、次の数分でさらに189のエージェントが始まりました。報告者自身の表では、壁に当たるまでの各フェーズで数千万トークンが数えられています。
| フェーズ | トークン(キャッシュ込み) |
|---|---|
| Ground | 11,063,801 |
| Find | 35,885,272 |
| Merge | 516,226 |
| 合計 | 47,465,299 |
原因は、生成されたスクリプトの1行でした。エージェントが何も返さなかったら、生のリストを使って続ける、というフォールバックです。mergeは失敗したのに、実行は進み続けました。このバージョンは、usage limitでの一時停止より前のものであり、報告者によれば、それらのトークンは失敗したエージェントのものではありません。同時実行の上限があればこの実行は薄まり、auto-continueをオフにしていれば壁で終わっていたはずです。
結論です。同じタスクで、同じチェックに通りながら、ultracodeは通常実行の2倍以上のメーターを使いました。賢いからではなく、注入された一文と、外されたガードのせいです。元が取れるのは、テストスイートまたはルールセットが出力を判定し、各部分が互いを待たないときです。それ以外の場面では、入力して、確認の代金を払うことになります。実行が使えるものに上限をかける設定は5つです。サイズの目安、同時実行の上限、workflowのモデル、トグルよりキーワード、そして上限で止めること。
