先に結論だけ書くと、こうです。
サブエージェントの「コンテキスト隔離」と「重複読み込み」は、実装の不備ではなく同じコインの裏表だった。隔離を買うと重複を買う。実測で、47回のサブエージェント実行が大きいファイルから読んだデータのうち 54.7%が純粋な重複。しかも重複読みの中位間隔は 35分。親エージェントが自分で読んでいれば、その大半は自分のコンテキストにまだ残っていた。
この記事について
Maurice Heumann（momo5502）が Call of Duty: Modern Warfare 2 (2009) のデコンパイルを AI エージェント群に24時間走らせている実験の、2本目の記事を読みました。
- 1本目: 200 Billion Tokens Later: A Month of Letting AI Agents Decompile MW2（2026年8月17日）
- 2本目: 235 Billion Tokens Later: Auditing What The AI Agents Really Did（2026年8月22日）
1本目は規模の報告です。4週間ノンストップ、199.8Bトークン、約7000コミット、16,324関数のうち5,588関数（約34%）をデコンパイル。本人が「ほぼ助けを求める叫びのようなもの」と書いている内容で、エージェントがローカルでテストを回したがる、大きい課題を避けて小さいのばかり拾う、勝手に「コンテキストが足りない」と言い出す、といった愚痴が並びます。
2本目は、その設定が実際どう動いていたのかを 約2GBのセッションログから監査したものです。私はこっちのほうが価値があると思いました。1本目は使用感、2本目は実測だからです。
正直に開示します。私は2GBのログを持っていないし、監査を再現していません。数字は全部原文からの引用です。もう1点、原文のいくつかの数字（1107.6エージェント時間の内訳、overseerモデル比較の bugs/hour）は図表の中にしかなくて本文に落ちていないので、この記事では触れる必要があるところだけ「原文の図を見てください」で済ませます。数字を推測で埋めるほうが害が大きいので。
まず規模
サブスクリプションで走らせているので実際の支払いは約200€。同じ使用量を API の従量課金に置き換えると $85,207 です。
| Worker | Overseer | |
|---|---|---|
| 従量課金換算 | $70,275 | $14,933 |
| ツール呼び出し | 198,143 | 38,173 |
| アシスタントターン | 364,786 | 81,705 |
キャッシュ読み込みが約89%。24時間走り続けているので当然です。
コンテキストの数字はここです。
| 総コンパクション回数 | 269 |
| 圧縮前のコンテキストサイズ（中位） | 933,088トークン |
| コンパクション間のターン数（中位） | 1,346 |
| コンパクション間の時間（中位） | 3.3時間 |
1Mウィンドウの93〜100%まで使ってから圧縮している。つまりほぼ全ターンが1Mトークン近いキャッシュ読み込みを払っていた。著者はこれを見て圧縮閾値を93%から60%に下げました。デコンパイル済みの関数は以降のターンにほぼ無関係だから、早く捨てても性能はほぼ変わらないはず、という判断です。
サブエージェントは「測れない」ので、重複を測った
ここが本題です。この節だけで原文を読む価値があります。
まず前提。この項目では サブエージェントは実作業ができません。ワークスペースを並行して安全に書き換えられないので、それぞれに専用ワークスペースが必要になる。だからサブエージェントの役目は調査して結果を圧縮すること、つまり親のコンテキスト汚染を防ぐことだけです。
そして著者はここで手が止まります。
効果を測るのは難しい。実作業のデコンパイルができないという事実だけで、すでに有用性は半分になっている。残る問いは、調査においてどれだけ効率的か、だ。
これもまた測るのが難しい。だが代わりに測れるのは、コンテキストを共有しないせいでどれだけ冗長なデータを取り込んだか、である。
「効率は測れないので、重複を測る」。この一歩の踏み方が、この記事のいちばん誠実なところだと思います。47回のサブエージェント実行について、5kB以上のファイル読み込みを全部突き合わせた結果:
- 大きいファイルのうち 36% が複数のサブエージェントに読まれていた
- 読まれた量で重みづけすると、54.7%が純粋な重複
- 最悪の例は
STATUS.md。21体のサブエージェントに合計28回読まれた（GitHub issues に移行する前） - 重複読みの中位間隔は35分
最後の1行が本当の発見です。著者もそう書いています。
重要なのは、あるファイルが別のサブエージェントに重複して読まれるまでの中位時間が35分だということだ。もし親エージェントが自分でその調査をしていたら、そのファイルは自分のコンテキストに残っていて、冗長な読み込みの大半は起きなかった。
そして切りました。切った後の生産性:
| 1日あたりコミット数 | |
|---|---|
| サブエージェントあり | 243.9 |
| サブエージェントなし | 311.1 |
約28%増。ただし著者自身が「コミット数を生産性の指標にするのは必ずしも正確ではない」と注記していて、結論もこう締めています。
サブエージェントが有用かどうか、この項目の外側でも一般に、定量化するのは私にはまだ難しい。ただ、（大量のエージェントが並列で起動された場合に）制御不能にトークン消費を押し上げうるという感覚はあって、無効化する理由としてはそれで十分だ。
つまり原文の主張は「サブエージェントは非効率だ」ではありません。**「効率は測れなかった。測れたのは予測不能性で、それが切る理由になった」**です。ここを「重複54.7%だから無駄」に要約すると、原文より強い主張になります。
私の見解
ここから先は原文に書かれていない、私の読み方です。
1. 54.7%より35分のほうが重い
54.7%は「重複していた」という事実にすぎません。重複が悪いかどうかは、それが避けられたかどうかで決まります。それを決めているのが35分です。
サブエージェントの売り文句は「親のコンテキストを汚さない」でした。でも汚さないというのは、親が知っていることをサブエージェントは知らないということです。同じ文です。だから隔離を買った瞬間に重複を買っています。実装の粗さではなく、定義です。
だとすると「サブエージェントを効率化する」という方向は、かなりの部分が筋の悪い願いになります。隔離を保ったまま重複を消したいというのは、共有しないまま共有したいと言っているのに近い。原文の35分は、その矛盾に値札を貼った数字だと思っています。
逆に言えば、隔離に払う価値があるのは、汚染のコストが重複のコストより大きいときだけです。この判定はタスクごとに変わるし、著者の項目ではサブエージェントが実作業できないという制約が最初から効いていた。だから他の項目にそのまま持っていける結論ではありません。
2. 著者の2つの調整は、たぶん互いを打ち消す
原文で私が引っかかったのはここです。同じ記事の中に、こう2つの調整が並んでいます。
- コンパクション閾値を93% → 60%に下げる（コンテキストを早く捨てる）
- サブエージェントを無効化する（調査を親のコンテキストでやる）
サブエージェント廃止の根拠は「親が自分で読めば35分間はコンテキストに残っていたはず」でした。この根拠は、親のコンテキストが35分もつことを前提にしています。
一方、圧縮を60%に下げると、親のコンテキストの寿命は短くなります。原文の数字では、93%まで使って中位3.3時間ごとに圧縮していた。60%で切るなら、単純計算でそれよりだいぶ短い間隔になるはずです。35分より短くなるかどうかは、コンテキストの伸び方と無関係ではいられません。
つまり早期圧縮は、サブエージェント廃止で消えたはずの重複読みを、親自身の再読み込みとして戻す可能性がある。原文はこの相互作用に触れていません。両方とも単独では合理的なのに、組み合わせると効果が食い合うかもしれない。
これは私の推論であって、検証結果ではありません。著者は「次のポストで結果を出す」と書いているので、そこで答えが出ると思います。私が見たいのは、圧縮を60%にしたあとの親エージェントの再読み込み率です。それが上がっていたら、この記事の「35分」の議論は閾値の関数だったということになります。
3. 「レビュアーのモデルが効く」のほうが転用しやすい
原文にはもう1本、subagent の話より地味だけど汎用性の高い結果があります。
worker として Opus 5 と Sonnet 5 をほぼ半分ずつ走らせた比較:
| モデル | ビルド試行 | 失敗率 | コミット/時 |
|---|---|---|---|
| Sonnet 5 | 5,826 | 9.1% | 6.1 |
| Opus 5 | 9,868 | 23.9% | 1.6 |
Opus のほうがビルドを壊す。壊すから直す。直すからコミットが進まない。ただし著者は「Sonnet が優れているとは限らない。単に簡単なタスクを選んでいるだけかもしれない」と自分でブレーキを踏んでいます。
そこで overseer（全コミットをレビューする別エージェント）のモデルも入れ替えて、worker × overseer の組み合わせで「flagされたバグ」を数えました。1時間あたりで見ると Opus worker のほうがバグが少ない。でも Opus はコミット自体が少ない。だからコミットあたりに直すと、両者のミス率はほぼ同じになる。差が出たのは overseer 側で、結論はこうです。
効くのはレビュアーのモデルであって、ワーカーのモデルではない。
（この節の数値は原文の図表の中にあります。本文には落ちていないので、正確な値は原文を見てください。）
これは私たちの直感的な配置と逆です。普通は「いいモデルに書かせて、安いモデルでチェックする」をやります。この結果はその逆を示唆します。
ただ私は、この1行をそのまま持ち帰るのは危ないと思っています。指標が「flagされたバグの数」だからです。Sonnet overseer が多く flag したのは、単に指摘が多いモデルだからかもしれない。flag が正しかったかどうかは測られていません。overseer 全体の精度については別の数字があって、コミットに言及した2177件の Discord 返信のうち1172件は分類できず、354件が明確なバグを指摘していた、とされています。分類できた中では約3分の1。悪くはないですが、「flag数が多いほうが良いレビュアー」を成立させるには足りません。
それでも私がこの結果を重く見ているのは、レビュアーにケチる設計を疑う理由になるからです。私の Claude Code の設定は、まさに「レビューは軽いモデルでいい」寄りでした（~/.claude/rules/performance.md に "If it only reads/searches, use haiku" と書いてある）。少なくとも、レビューを読み取り作業として安く扱うのは考え直したほうがいい。
4. CLAUDE.md はソフト指示である
原文の結論に、こう1行あります。
ソフトな指示はあまり効かない。ルールを強制するには機械的なブロッカーのほうが効果的だ。
これは1本目の記事の伏線が回収された形です。1本目で著者は「ローカルでテストを実行するな、CI があるんだから」と繰り返し言ったのに、エージェントは聞かなかった。2本目の対処はこうです。
- テスト実行をコード側で無効化した（CI失敗の再現時と新規テスト追加時だけ実行させる）
- Release ビルドでの warnings-as-errors を、Debug ビルドの CMake オプションに移した（ビルド時間30%削減）
- CI のポーリングをやめさせるため、GitHub webhook で失敗を通知する形にした
- Issue が閉じたかの確認をやめさせるため、コミットメッセージに
Fix #Nを入れて自動クローズさせる
全部「言って聞かせる」から「そうしかできない形にする」への移行です。ついでに、PowerShell のエラー率が17%（他のツールはほぼ2%以下）という数字も出ていて、著者は「PowerShell の実行を禁止するのが論理的な帰結かもしれない」と書いています。これも同じ発想です。
私はこれを読んで、自分の CLAUDE.md を見に行きました。あれは全部ソフト指示です。「テストを先に書け」「勝手にコミットするな」「トークン予算は4000」。全部お願いです。強制力はゼロで、守られるかはモデルの気分と、コンパクションを何回挟んだかに依存します。
そして Claude Code には強制の仕組みがちゃんとあります。hooks（PreToolUse で弾く）、settings.json の deny リスト、権限モード。守らせたいルールがあるなら、書く場所は CLAUDE.md ではなく settings.json です。 著者が4週間の実験で辿り着いたのがこれで、正直これがこの2本の記事のいちばん実用的な一行だと思っています。
1つだけ持ち帰るなら
サブエージェントの話ではありません。
守らせたいルールは、機械が弾く場所に書く。 お願いを書く場所に書いたルールは、10回目のコンパクションで消えます。
サブエージェントについて1つ足すなら、切るかどうかを決める前に、自分の重複読みを数えてみることです。~/.claude/projects/**/*.jsonl に全部残っています。著者は2GBを読みました。私たちはもっと小さいログで、同じ問いに答えられます。
出典
- Maurice Heumann, 235 Billion Tokens Later: Auditing What The AI Agents Really Did, momo5502.com、2026年8月22日
- Maurice Heumann, 200 Billion Tokens Later: A Month of Letting AI Agents Decompile MW2, momo5502.com、2026年8月17日
記事中の数値はすべて上記2本からの引用です。私自身はログ監査を再現していません。原文の一部の数値（エージェント時間の内訳、overseerモデル比較の bugs/hour・bugs/commit）は図表内にのみ存在するため、この記事では具体値を引用していません。§「私の見解」の2は私の推論で、検証結果ではありません。