何が起きたか
2人の独立系AI研究者が、MATS研究プログラムの一環として、広く使われている2つのコーディングエージェント——AnthropicのClaude CodeとOpenAIのCodex——の「時間感覚」を検証しました。手順はシンプルで、タスク着手前に「どれくらいかかるか」を予測させ、完了後に「どれくらい経ったか」を振り返らせるというものです。テスト素材は、ProgramBenchと呼ばれるコレクションから200タスク、加えて研究者自身が用意した18のベンチマークです。
結果は一貫していました。エージェントは所要時間を過大に見積もります。ProgramBenchでは、両モデルともタスクの難易度に関係なく「だいたい90分」と答える傾向がありました。2ラウンド目では、Claudeが平均3倍、Codexが6〜10倍ずれています。ずれが最も大きいのは短時間タスクで、数時間規模のタスクになってようやく予測が現実に近づきました。LessWrongに掲載されたOfengenden/Andriushchenkoによるグラフでは、Fable 5が実行時間の約3倍、GPT-5.6 Solが約7倍という過大見積もりが示されています。
「難易度に関係なく90分」が意味すること
注目すべきは、90分という数字がタスクの中身を反映していない点です。難易度に応じて予測が変わらないということは、エージェントが作業量を推定しているのではなく、「それらしい所要時間」を出力しているにすぎない可能性を示します。見積もりというより、定型句に近い挙動です。
さらに重要なのは、実行時間がモデルだけで決まらないという指摘です。研究によれば、同じ言語モデルでも、Claude Code上ではCodex上より平均2.5倍多いステップ数を踏みます。Claude Codeは「終わった」と自分が判断するまで動き続け、実行時間の中央値は約90分。一方Codexはタスクの内容にほぼ関わらず30分程度で止まります。つまり挙動を決めているのは、モデルそのものよりも、それを取り囲むソフトウェア——ハーネスの設計です。同じモデルを使っていても、載せる器で仕事量もコストも変わります。
自己採点も当てにならない
時間だけではありません。成果物の品質評価も外れます。旧世代のOpus 4.8とGPT-5.5は、自分の結果を平均20ポイント高く評価し、失敗したタスクにさえ高得点をつけました。あるケースでは、両モデルとも「約70%成功」と自己申告した一方、実際のスコアは7%と14.5%でした。別のグラフでも、両システムが実測より約20ポイント高く自己採点している様子が示されています。
研究者が自己評価を重視するのは、長時間タスクの制御に直結するからです。「このタスクを2時間反復せよ」といった指示に従わせるには、エージェントが自分の作業時間を把握している必要があります。時間感覚を常に誤るエージェントは、そもそも指示で御しにくい。著者らは次の検証として、エージェントが指定された作業時間を守れるかを調べる予定だとしています。
救いは「時計を渡すこと」
この研究には実務上きわめて有用な結論があります。経過時間を返すツールをエージェントに与えたところ、ほぼ毎回正しく答えられるようになったのです。つまり問題は推論能力ではなく、観測手段の欠如です。内省させるのではなく、計測結果を渡す。エージェント設計における原則が、時間という基本的な軸でも成り立つことが確認されました。
💼 事業会社視点：これは自社にどう効くか
経営上の含意は3つあります。第一に、AIエージェントの自己申告を進捗管理の根拠にしてはいけない、ということです。受託開発やSIerが「AIで工数◯割削減」を見積もりに織り込む際、エージェントの所要時間予測はClaudeで平均3倍、Codexで6〜10倍ずれます。工数根拠は実測ログに置くべきで、エージェントの自称を顧客提案に持ち込むのは危険です。
第二に、コスト構造の主因はモデル選定ではなくハーネス選定だという点です。同じモデルでもClaude Code上ではCodex上の2.5倍のステップを踏み、Claude Codeは中央値90分走り続け、Codexは約30分で止まります。従量課金のAPI費用は、この差でそのまま数倍になります。SaaS事業者や社内開発部門は、モデル比較の前に「どのハーネスで、何分で打ち切るか」を運用ルールとして決めるべきです。上限時間とステップ数のキャップは、品質施策ではなく予算統制です。
第三に、品質ゲートを人間側に残すこと。旧世代モデルは失敗タスクにも高得点をつけ、実際7%・14.5%の成果を「約70%成功」と申告しました。ECのカート改修や決済まわりのように事故コストが高い領域で、エージェントの自己評価を承認基準にしてはいけません。CI・テストカバレッジ・レビューという外部計測を必ず挟む設計に。逆に言えば、経過時間ツールを与えれば正答でき���ように、外部の計測手段を渡すだけで制御性は大きく改善します。投資すべきは「賢いモデル」より「測る仕組み」です。