AIコーディングエージェントは時間の把握に苦戦、研究で判明

Anthropic の Claude Code と OpenAI の Codex はソフトウェア作業をこなせるものの、新しい研究では、それらがその作業にどれほど時間がかかるかをあまり理解しておらず、さらに自分の成果を判断する能力はそれ以上に弱いことが示唆された。この知見は、AI コーディングエージェントが短い対話的なプロンプトから、数十分から数時間にわたり自律的に実行される仕事へと移行している中で重要である。

MATS の研究プログラムで活動する 2 人の独立研究者が、The Decoder の研究紹介によれば、ProgramBench の 200 タスクと追加の 18 ベンチマークでこれらのアシスタントをテストした。エージェントには開始前に必要な所要時間を見積もらせ、作業完了後に経過時間を報告させた。両システムともタスク時間を一貫して長めに見積もり、また失敗した作業を試験結果が正当化するよりはるかに高く評価していた。

この研究は、すべてのソフトウェア環境においてモデルが文字通り時間にアクセスできないことを示すものではない。むしろ、現在の AI エージェント が経過時間をどのように認識し、その情報を仕事の管理にどう使うかにおける実用上の弱点を浮き彫りにしている。研究者が経過時間を報告するツールを与えると、エージェントはほぼ常に正確になったと報告されている。

短いコーディング作業での大きな誤差

ProgramBench では、難易度にかかわらず、両エージェントは一般にタスクは約 90 分かかると予測していたと The Decoder は報じた。2 回目のテストでは、Claude Code の見積もりは平均で約 3 倍外れ、Codex は 6 倍から 10 倍外れていた。

最も大きな誤差は短いタスクで見られた。報告によれば、予測が現実に近づいたのは、作業が数時間単位に及ぶ場合のみだった。このパターンは運用上重要である。数分で終わるかもしれないタスクに 90 分を予測するエージェントは、いつ止めるか、助けを求めるか、別の行動を始めるかについて誤った判断を下す可能性がある。

結果はまた、各モデルを取り巻くソフトウェア環境によって大きく異なった。Claude Code は、割り当てを完了したと判断するまで作業を続け、報告された中央値の実行時間は約 90 分だった。Codex は、タスク難易度が変わっても、多くの場合およそ 30 分後に停止した。

研究者は、この違いの一部をエージェントの「ハーネス」— 言語モデルを取り巻くツール、指示、実行制限、制御ロジック — に起因するとした。報告によれば、同じ基盤モデルは Claude Code では Codex より平均して 2.5 倍多くのステップを踏んだ。これは、実行時間が単にモデルの属性であるだけでなく、それを展開する製品アーキテクチャによっても形づくられることを示唆している。

自己評価も別の弱点だった

テストでは、所要時間の見積もり以外の問題も見つかった。The Decoder によると、モデルは自分の仕事の品質を平均で約 20 ポイント過大評価していた。タスクが大きく失敗している場合でも、高い点数を自分に与えることがあった。

ある例では、両システムは自分の作業を約 70% の成功と評価したと報じられているが、測定結果は 7% と 14.5% だった。出典では、関与したモデルを Opus 4.8 と GPT-5.5 と説明している。ここで利用できる証拠は研究論文そのものではなく、研究についての報告であるため、これらのモデル識別子と正確な評価条件は、独立に検証された事実ではなく、報告された結果として扱うべきである。

自己評価は自律的なソフトウェア作業の中心である。コーディングエージェントは、反復を続けるか、タスク完了を宣言するか、パッチを修正するか、問題を人間へエスカレーションするかを判断する必要がある。もしその確信がテスト結果と切り離されていれば、ワークフローは健全に見えながら、不完全または欠陥のあるコードを生み出す可能性がある。

ハーネスが導入で重要な理由

開発者にとっての中心的な教訓は、Claude Code と Codex が悪い予測をするということだけではない。エージェントの振る舞いは、モデルの周囲にある制御に大きく依存するという点である。AI コーディングアシスタントを選ぶ製品チームは、ベンチマーク性能だけでなく、締め切り、再試行、ツールの失敗、テスト結果、明示的な停止条件をシステムがどう扱うかも評価すべきだ。

経過時間ツールを用いた研究結果は、比較的簡単な技術的対応を示している。会話履歴、トークン生成、ツール呼び出し回数から時間を推測することをエージェントに期待すべきではない。実行時間は信頼できる外部時計で提供され、オーケストレーション層によって強制されるべきである。

ただし、それであらゆる監督上の問題が解決するわけではない。タイマーは 2 時間が経過したことをエージェントに伝えられるが、結果のコードが安全か、完全か、デプロイに値するかまでは判断できない。チームは依然として、独立テスト、変更レビュー、サンドボックス化、支出上限、エスカレーション規則を必要とするかもしれない。これらの制御は、エージェントが継続的な監督なしに働くことを許されるほど重要になる。

この発見は、AI コーディング製品間の比較も複雑にする。Codex の観測された短い実行時間と Claude Code のより長いステップ列は、単純な知能や生産性の差ではなく、異なる既定値を反映しているのかもしれない。製品を比較する買い手は、エージェントに何が許可されているか、どれくらい動かせるか、完了がどのように検証されるかを尋ねるべきだ。

証拠と主張の限界

証拠は、The Decoder が報じた MATS の一環として行われた 2 人の独立研究者による研究に基づく。報告されたテストセットは ProgramBench と追加の 18 タスクのベンチマーク群を組み合わせたものだった。報道は時間見積もり、実行時間、ステップ数、自己評価について数値結果を示しているが、ここで利用できる資料には完全な方法論、タスク定義、統計分析、独立再現は含まれていない。

したがって、結果はすべての AI エージェントのすべてのバージョンを普遍的に測定したものではなく、特定の評価上の弱点を示す証拠として読むべきである。結果は、モデル更新、システムプロンプト、利用可能なツール、コンテキストウィンドウ、タスクの種類、ハーネス設計によって変わりうる。経過時間ツールへのアクセスでほぼ普遍的な正確さが得られたという主張は、工学的なシグナルとして特に有用だが、それでも報告された研究に由来するものであり、より広範な検証が必要である。

また、時間を見積もることと時間を追跡することには重要な違いがある。エージェントは適切なツールが与えられれば時計を読むことはできても、未知のタスクにどれだけ時間がかかるかを予測することには失敗するかもしれない。製品チームはこの 2 つの能力を別々にテストすべきである。

今後注目すべき点

研究者たちは、エージェントが指定された期間継続して作業する、といった指示に従えるかどうかをテストする計画だと報じられている。この実験は、外部の時間情報が事後報告だけでなく、リアルタイムのタスク制御も改善するかを示すかもしれない。

追試評価では、より新しいモデル版、より長いソフトウェアプロジェクト、障害回復、そして異なるハーネスもテストすべきである。有用なベンチマークは、エージェントが締め切りで停止するか、締め切り前に使える結果を出すか、何が未完了かを正確に報告するかを測定するだろう。

企業購入者にとって、実用上のシグナルは製品設計に表れる。具体的には、経過時間の常時表示、厳格な実行予算、独立検証、明確な引き継ぎ機構である。これらの制御について再現可能なデータを公開するベンダーは、真の自律性と、隠れた制限に達するまで動き続けるだけのエージェントを見分けやすくするだろう。

Creati.ai の視点

この研究は、言語モデルと自律ソフトウェアの境界にある制御問題を示している。時間認識は、製品が何らかの形で模倣しなければならない抽象的な人間的特性ではない。それは測定可能なシステム能力であり、オーケストレーション層によって提供され、外部イベントと照合できる。

AI ビルダーにとっての教訓は、時間見積もりと自己申告の成功を信用できないシグナルとして扱うことだ。長時間稼働するエージェントには、外部時計、明示的な予算、独立テスト、エスカレーション経路が必要である。こうした仕組みが標準になるまでは、「自律的」コーディングは、タスクごとに検証しなければならないワークフロー上の主張にとどまる。