TDIL

11 日動く AI と、7 分で終わる私の AI。長さを自分の記録で測り直した

読むのに約 9 分jinc.

Anthropic が、Claude が 11 日間ほぼ自律で動いてフェルマーの最終定理の証明を機械で検証できる形に書き起こした、と報告した。AI がそれだけ長く動くなら、私の環境で動いている AI は何分くらい動いているのか。気になって、残っている記録から数えた。

先に結果を書くと、私の環境でサブエージェントと呼ぶ作業役の 1 回の作業は、中央値で 7 分ほどだった。最長でも 90 分で、11 日とは 3 桁以上違う。ただ、公式の 11 日が「1 つの AI が 11 日続けて動いた」という意味ではないと分かったので、並べ方から直す必要があった。この記事では、公式が書いていること、手元で数えたこと、長さが原因で実際に壊れたこと、確かめられなかったことを順に書く。

11 日という数字は、何の長さなのか

公式の報告に書かれている範囲を整理する。

つまり 11 日は、数十本のエージェントを並べて動かした全体の経過時間である。1 本のエージェントが 11 日間途切れず考え続けたとは書かれていない。

もう 1 つ、報告の中で目を引くのは、成功の要因として挙げられている仕組みである。最初の試みは失敗していて、エージェントが「早い段階で多少の成果は出したものの、プロジェクトの状態を見失い、うまく協力できなくなった」と書かれている。うまくいった構成では、証明すべき定理の文を有向非巡回グラフ（DAG）として外部の基盤に持たせ、各エージェントがそれを見て次に取り組む証明を選んだ。公式はこれを、記憶の劣化を和らげ、複数のエージェントが並列で動けるようにする仕組みとして説明している。失敗した試みも、最終的な証明の定型文を除いた行数の約 7 パーセントを占めたという。

長く動くことが成果として報告されているが、長く動けた理由として挙げられているのは、モデルが持久力を持ったことではなく、状態をエージェントの頭の外に置く構造のほうである。

別の長時間の報告も、同じ形をしていた

同じ会社が少し前に出した、C コンパイラをエージェントに作らせた報告も見ておく。16 本のエージェントを並列に動かし、およそ 2 週間、Claude Code のセッションは 2,000 回近く、入力トークンは約 20 億、出力は約 1.4 億、費用はおよそ 2 万ドルと書かれている。

動かし方は単純で、公式の記事に載っている仕組みは、次のような無限ループである。

while true; do
    COMMIT=$(git rev-parse --short=6 HEAD)
    LOGFILE="agent_logs/agent_${COMMIT}.log"

    claude --dangerously-skip-permissions \
           -p "$(cat AGENT_PROMPT.md)" \
           --model claude-opus-X-Y &> "$LOGFILE"
done

1 つの作業が終わるたびにセッションが閉じ、次のセッションが新しく始まる。続きは、リポジトリに置かれた進捗のファイルを読んで把握する。公式は、エージェントが自分で見るための「頻繁に更新される詳しい README と進捗ファイル」を置いたこと、テストの出力に無駄なバイト数を出さないこと、そして「Claude は時間が分からず、放っておくと進捗を出すことより何時間もテストを回すことに費やす」ことを注意点として書いている。

16 本が 2 週間ほぼ止まらず動いていたと仮定して概算すると、16 × 14 日 × 24 時間で約 5,400 時間になり、これを 2,000 回弱のセッションで割ると 1 セッションは平均 2〜3 時間になる。これは私の概算であり、公式が書いた数字ではない。それでも、長時間の報告の実体は、数時間単位のセッションを、外に置いた状態でつなぎ続けた形らしいと読める。

2 つの報告に共通するのは、「長く動く」ことを 1 回の実行の長さでなく、短い実行をつなぐ構造で実現している点である。

手元の記録から数えた

自分の環境の長さを測るために、Claude Code が残している会話の記録（セッションごとのログ）を使った。記録は約 4 週間分で、ここでの数字はその範囲のものである。

数え方を決めておく。

サブエージェント 255 回

区分回数作業中のツール呼び出し回数（中央値）
5 分未満8714
5〜15 分10542
15〜30 分4361
30 分以上20約 90

全体の中央値は約 7 分、上位 1 割の境目が約 26 分、最長は約 90 分だった。15 分未満で終わったのは 255 回のうち 192 回で、4 分の 3 にあたる。1 時間を超えたのは 7 回あり、すべて継手の Web アプリの作業だった。内訳は、新しい継手の形を 1 つずつ組み立てる作業が 4 回、画面の機能を足す実装が 3 回である。

作業役の種類別に見ると、実装を担当する役の中央値が約 11 分、調べものの役が約 8.5 分、分析の役が約 8 分で、実装がいちばん長い。255 回の作業時間をすべて足すと約 51 時間になる。同時に動いていた作業役の最大は 12 本だった。公式の 11 日は 264 時間だから、4 週間分の全部を足しても 5 分の 1 に届かない。

本体とのやり取り 1,012 回

本体とのやり取りは、1,012 回を数えた。中央値は約 1 分 48 秒で、1 分未満が 318 回ある。5 分以上かかったのが 238 回、10 分以上が 124 回、30 分以上が 31 回、1 時間以上が 11 回だった。最長は 3 時間 43 分で、これはハーネスの削減を進めていた日のもので、始まりは作業役の報告が本体に届いたことだった。やり取りの長さには、本体が作業役の結果を待っている時間や、続けて処理している時間も含まれ、考え込んでいた時間とは限らない。

セッション全体で見ると、記録のあるセッションは 47 本で、うち 13 本は開始から最後の記録まで 1 日以上空いている。最長は約 15 日で、これは同じセッションを何度も再開した結果であり、1 回の連続した作業ではない。

1 つのセッションの中身は、圧縮で入れ替わる

長いセッションでは、会話の内容がモデルの扱える量を超えるので、途中で要約に圧縮される。記録に残っていた圧縮は 21 回、6 本のセッションに集中しており、手動が 12 回、自動が 9 回だった。圧縮の直前に会話が占めていた量は中央値で約 87 万トークン（最小で約 24 万、最大で約 97 万）、圧縮の直後は中央値で約 2.9 万トークンだった。1 本のセッションで 7 回圧縮していた例もある。

圧縮の後に残るのは要約と、直近の少しのやり取りだけである。つまり、私の環境でいちばん長く続くセッションは、連続して思考を保っているのではなく、短くなった記憶を引き継ぎながら進んでいる。公式の報告が状態を外に置いたのと、構造としては近い。違うのは規模で、こちらは進捗を自分のファイルに残す運用を後から足している段階である。

長さが原因で壊れたもの

長いこと自体が問題になった実例は、記録にいくつか残っている。

セッションの要約が 5 日連続で壊れた。 終了時にセッションを要約してメモに残す仕組みが、長大になったセッションを丸ごと要約モデルに渡し、約 23 万トークンで上限の 20 万を超えた。要約モデルは要約の代わりに「入力が長すぎる」というエラー文を返し、仕組みはそれを検証せず、そのままセッションの記録として保存していた。5 日続いて、後から検索すると要約のかわりにエラー文が出てきた。健全性の確認は「正常」を返し続けていた。直し方は、入力を末尾の約 100 キロバイトに切ること、書き込む前に中身を検査すること、検査に落ちたら書かずに失敗として起票することの 3 つだった。

作業役が上限に当たって、本番ファイルの書き換えの途中で落ちた。 実装の作業役が、約 11 分動いた時点で利用上限に当たって終了した。最後の発言は「これから本番のファイルを書き換える」だった。通知は「失敗」だったが、実際には作業はほぼ済んでいた。構文の検査、テスト（36・13・20・7 件）、発注の前に自分で作っておいた再現の実験、変更箇所の直接の確認を順に行い、すべて済んでいたと分かった。1 件しか報告されなかった異常が、3 件とも報告されるようになっていた。発注の前に、自分で再現できる実験を 1 つ作っておいたことが、中断した後に実物で判定する唯一の手段になった。

検索の上限をセッション全体で使い切った。 Web 検索はセッション全体で 200 回までで、サブエージェントも同じ枠を使う。調べの重い作業役を 2 本並行で出したところ、1 本は約 4 分で上限に当たり、何も作らずに止まってその旨を報告した。もう 1 本は約 23 分動いたところで当たり、検索の結果ページを直接読んでしのいだ。前半の調べでほとんどの枠を使い切っていたのに、残りを見積もらずに出した発注の誤りだった。

3 件とも、AI の持久力が足りなかったのではない。長く動かすほど、要約の入力が膨らむ、共有の枠が減る、利用上限に近づく、といった外側の制約に当たる。

「長い作業ほど報告に抜けが出る」は、確かめられなかった

この記事の種になったメモには、長い作業ほど完了報告に抜けが出るという見立てが書いてあった。何分あたりから信用が落ちるのかを記録から出せるのではないかと考えて確かめたが、メモにあった所要時間や抜けの件数そのものは、残っている記録から再現できなかった。

記録で確かめられたのは次の範囲までだった。

もう 1 つ、報告が通ったのに中身が誤っていた失敗も記録にある。記事を作る作業役が「数値はすべて許可リストの範囲内」と報告し、実際にその通りだったのに、付けた図は本文より強い主張をしていた。この件の原因は、作った側が自分の前提を疑えないことであり、長さとは関係がなかった。その記録には、作業役を 1 本ずつ走らせた状態で起きたと明記されている。

つまり、長いほど報告に抜けが出るかどうかは、今の記録では言えない。言えるのは、報告を受けた側が実物を自分で開く手順を置くかどうかが、長さとは別に効いている、という点までである。

長く動かさずに済ませていること

ここまでの数字から、自分の環境の特徴は次のように言える。

反対に、公式のような、数十本を何日も並べて動かす規模は、私の環境では測れていない。同時に動いていた作業役の最大が 12 本で、4 週間の合計でも約 51 時間にとどまる。公式の 11 日と私の 7 分を比べても、同じ長さの話にはならない。次に測るなら、発注の時点で依頼項目の数を残し、報告の項目数と突き合わせて、長さごとに抜けを数える必要がある。いまの記録には、その基準が残っていない。

関連する記事として、役割の分け方と運用の積み方は AI に指示ではなく環境を渡すようになるまで、記憶の仕組みは AI の記憶を 3 回作り直し、呼んだときだけ引く形に戻した に書いた。

出典

記事の一覧へ