論文レポート生成AIAIエージェントMETR

AIは数週間規模の開発タスクを完遂できるか — METRの時間軸(time horizon)研究とMirrorCode初期結果から読む「委任範囲」の動き

MirrorCodeの4月初期結果では、Claude Opus 4.6が約16,000行のgotreeを再実装し、2,001テスト中2,000件に合格。6〜7月の完全版では25対象・最強モデル56%へ拡張され、Opus 4.7がgotreeを14時間・251ドルで再実装しました。初期値と完全版を分け、AIへ任せる条件を整理します。

分析
岡崎 太
CTO / AIアーキテクト
公開日
読了時間
13分で読めます
Share

Key Findings

  • METRのTime Horizon 1.1では、50%成功率で自律完遂できるタスク長の倍増期間を、全期間の接続推定で196.5日、2024年以降の部分集合で88.6日と推定。タスク構成への感度があり、将来も同じ速度が続くという予測ではない
  • 2026年1月時点の最前線モデルの50%時間軸はClaude Opus 4.5で約320分(約5.3時間)。ただし信頼区間は170〜729分と広く、点推定を精密な値として扱うべきではない
  • MirrorCodeのgotreeではClaude Opus 4.6の1実行が2,001テスト中2,000件に合格。成功実行は280Mトークン・2,989メッセージで、4.0〜4.5の値は各3実行中の最高値

サマリ

「AIエージェントに、どこまで大きな開発タスクを任せられるのか」。この問いに対して、AI評価機関 METR は「タスクの絶対的な難しさ」ではなく、人間ならどれくらい時間がかかるタスクを、AIが自律的に完遂できるか——タスク長(time horizon)という物差しで答えを更新しています。Time Horizon 1.1では、50%時間軸の倍増期間を全期間の接続推定で196.5日、2024年以降の部分集合で88.6日と推定しました。ただし、タスク構成に敏感な回帰結果であり、88.6日が将来も続くという予測ではありません。

2026年4月、METR と Epoch AI は MirrorCode の初期結果(preliminary results) を公開しました。ソースコードを見せずに既存のCLIツールを再実装させるこのベンチマークで、Claude Opus 4.6 の1実行は約16,000行の Go 製バイオインフォマティクスツール gotree を再実装し、2,001件のテストのうち2,000件に合格しました。人間の研究者・エンジニア4名による事前見積もりは2〜17週間でした。ただし、人間ベースラインの実測ではなく、MirrorCode全体の成功率でもありません。

その後、6月29日に完全版論文が公開され、7月17日にv2へ改訂されました。完全版は25対象を評価し、最強モデルClaude Opus 4.7の全体スコアは56% でした。Opus 4.7はgotreeを14時間・251ドルで2,000/2,001まで再実装し、初期報告で未達だったPklも99%以上まで再実装しました。本稿は、4月のOpus 4.6成功実行を詳しく読みつつ、公開時点の結論は完全版で更新します。

MirrorCode は、正解となる既存プログラムを実行でき、開発中は可視テストで反復確認できる特殊条件です。隠しテストはエージェントへ見せず、提出後の採点に使います。初期報告のgotreeテストは74コマンド中48コマンド(決定的・非グラフィカルなコマンドのほぼ全て)を対象としていました。したがって本レポートでは、MirrorCodeを「AIが外注先を置き換えた証拠」とは扱いません。検証可能性が、長い自律実行と関連する可能性を示す評価として読み、time horizon研究とはタスク群と指標を分離して、委任判断へつなげます。

仕様の検証可能化、AIの反復実装、人の品質検収を示す日本語インフォグラフィック

数週間タスクを任せる前の3段階

MirrorCodeの成功条件と限界を、実務で確認できる順番へ置き換えます。

  1. 正解条件を置く期待する出力と可視テストを置き、提出後は未公開テストで最終評価する
  2. 長く反復させる途中の自己申告ではなく、検証結果を見ながら修正を続けさせる
  3. 人が検収するテスト合格後に、保守性・安全性・未評価の機能を別途確認する

委任範囲は、モデル性能と検証設計を合わせて判断します。

論文の整理: time horizon — 「タスク長」でAIの自律性を測る

まず土台となる研究です。METR が2025年3月に公開した「Measuring AI Ability to Complete Long Software Tasks」(Kwa, West, Becker ほか。arXiv 2503.14499)は、AIエージェントの能力を時間軸(time horizon) という単一の指標に集約する手法を提案しました。

定義はこうです。さまざまな長さのソフトウェアタスクをAIに解かせ、人間が成功したベースライン実行の所要時間の幾何平均(成功実行がない場合は手動見積もり)を横軸に、AIの成功率を縦軸にとってロジスティック曲線を当てはめます。その曲線が成功率50%と交差する点のタスク長が、そのモデルの「50%時間軸」です。つまり「人間なら◯時間かかるタスクを、五分五分で自律完遂できる」という水準を表します。

この物差しで2019年以降のモデルを並べたとき、METR が見出したのが有名なトレンドです。

  • 最前線モデルの50%時間軸は、約7ヶ月ごとに倍増している(過去6年間)
  • 公開時点(2025年3月)の最前線モデル Claude 3.7 Sonnet の時間軸は約1時間

METR は limitations として、この推定がタスクの選定と人間ベースラインの測り方に依存すること、ベンチマークタスクの分布が実世界のタスク分布と同一ではないことを明記しています。「時間軸1時間」は「1時間の仕事なら何でもできる」という意味ではありません。

Time Horizon 1.1 — 更新値と「加速」

METR は2026年1月に更新版「Time Horizon 1.1」を公開しました。タスクスイートを170件から228件に拡充し(8時間以上の長時間タスクは14件から31件に増加)、評価基盤を英国 AI Security Institute のオープンソースフレームワーク Inspect に移行したうえでの再推定です。

項目 Time Horizon 1.1(2026年1月)の値
Claude Opus 4.5 の50%時間軸 320分(約5.3時間)[信頼区間 170〜729分]
GPT-5 の50%時間軸 214分
o3 の50%時間軸 121分
倍増ペース(全期間) 約196.5日(約7ヶ月、初版から変わらず)
倍増ペース(2023年以降) 約130.8日(約4.4ヶ月
倍増ペース(2024年以降) 約88.6日(約3ヶ月

2025年3月の初版ではClaude 3.7 Sonnetが約1時間、2026年1月の更新版ではClaude Opus 4.5が320分(約5.3時間) と推定されました。モデルもタスクスイートも異なるため、この2点を同一条件の経年実測とは扱えません。METR は、信頼区間がなお広いこと、8時間以上の31タスクのうち人間時間を実測したのは5件であること、推定トレンドがタスク構成に左右されることを明記しています。2024年以降の88.6日という倍増期間も、将来予測ではなく部分集合への当てはめです。

論文の整理: MirrorCode — 数週間規模の再実装はどこまでできたか

その METR が資金提供し、Epoch AI と共同開発したのが MirrorCode です。2026年4月10日に初期結果(preliminary results) が公開されました。以下では、まず4月時点の4対象・Claude Opus 4.0〜4.6の結果を整理し、その後に6〜7月の完全版で何が更新されたかを確認します。

タスク設計は独特です(Epoch AI の詳細レポートより)。

  • AIエージェントは、既存のCLIプログラムをソースコードを見ずに再実装する
  • 与えられるのは、元プログラムの実行のみ可能なアクセス、ドキュメント、可視テストケース。エージェントは入力を試しながら挙動をリバースエンジニアリングする
  • 合否は end-to-end テストの出力一致で判定。可視テストの丸暗記(ハードコード)を防ぐため、一部に概念的に対応する隠しdualテストが用意されている。著者らは隠しテストの網羅性を目標にしていない
  • 対象プログラムは Unix ユーティリティからバイオインフォマティクス、インタープリタまで24本を選定し、初期報告では4本を詳細分析

主要結果は次のとおりです。ハイライトは gotree——約16,000行の Go で書かれた、74コマンドを持つバイオインフォマティクスツールの再実装です。2,001テストはそのうち48コマンド(決定的・非グラフィカルなコマンドのほぼ全て)を対象とし、102件が提出後に採点する隠しテストでした。

対象プログラム 元の規模 Claude Opus 4.6 の結果
choose(テキスト抽出ユーティリティ) 小規模 全127テスト合格
cal(カレンダー表示) 小規模 全1,365テスト合格
gotree(バイオインフォマティクス) 約16,000行(Go) 1実行で2,000/2,001テスト合格
Pkl(設定言語) 約61,000行 可視テスト733件中256件(35%)にとどまり未達成

gotree について、研究者・ソフトウェアエンジニア4名が「熟練エンジニアが再実装したら」を独立に見積もった結果は、1.5〜2.5週間、3週間、13週間、13〜17週間でした。記事タイトルの「数週間規模」はこの見積もりに基づきますが、人間が実際に完遂した時間ではありません。

初期実験では1タスクあたり最大10億トークンを設定し、その上限を使った場合の費用目安が約550ドルと説明されています。gotreeの成功実行が使ったのは280Mトークン・2,989メッセージであり、550ドルは成功実行の実費ではありません。Pklは10億トークン予算下のOpus 4.6実行で未達成でした。

もうひとつ注目すべきはモデル世代による進歩の速さです。gotree のテスト合格数は世代ごとに次のように推移しました。

モデル gotree テスト合格率(2,001件中)
Claude Opus 4.0 15%(307件、3実行中の最高値)
Claude Opus 4.1 24%(471件、3実行中の最高値)
Claude Opus 4.5 63%(1,265件、3実行中の最高値)
Claude Opus 4.6 99.95%(2,000件、1実行)

gotreeテスト合格率の世代別最高値

2,001件のend-to-endテストに対する合格率です。

  • Opus 4.0307件
    15%
  • Opus 4.1471件
    24%
  • Opus 4.51,265件
    63%
  • Opus 4.62,000件
    99.95%

Epoch AI初期報告。4.0・4.1・4.5は各3実行中の最高値、4.6は1実行です。実行数とトークン数が異なるため、モデル世代だけの因果効果を示す比較ではありません。

表示上は15%から99.95%へ上昇していますが、旧3世代はbest-of-3、Opus 4.6は1実行で、使用トークンも7M、7M、119M、280Mと異なります。モデル世代だけの効果とは識別できません。約61,000行のPklは、4月初期報告のOpus 4.6実行では可視テスト35%でした。

完全版で更新されたこと

完全版(arXiv v2)は、初期報告の4対象から25対象へ拡張し、Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro Previewを評価しました。25対象のうち17対象で少なくとも1回の100%実行があり、さらに4対象で99%超の実行がありました。最強モデルの全体スコアは56%で、8対象は100%成功例がなく、MirrorCode全体は未解決です。

Pklも状況が変わりました。Opus 4.7が99%以上の再実装に到達したため、「Pklが未達だから大規模対象は解けない」という4月時点の読みは維持できません。一方、完全版でも最難関対象には未解決が残り、大規模対象の1実行には19日・2,600ドルを要した例もありました。完全版が示すのは、一部の長期タスクは完遂できるが、対象と実行ごとの差が大きく、コード品質や通常開発への一般化は別途検証が必要という状態です。

Epoch AI は、この結果をtime horizon研究と対比しています。MirrorCodeとは別のタスクスイートで、Claude Opus 4.6の50%時間軸は約12時間(95%信頼区間5時間19分〜66時間)と推定されています。著者らは、詳細で検証可能な仕様があるMirrorCodeでは、より長く生産的に作業できた可能性を述べています。これは異なる評価間の解釈であり、仕様の有無だけを操作した比較実験ではありません。

MirrorCodeの1成功例へ、Time Horizon 1.1の50%という成功率を当てはめることはできません。モデルもタスク群も評価方法も異なります。比較から言えるのは、自律実行の長さを単一の数字にまとめると、仕様とフィードバック信号の違いを落とす可能性があるということです。

論文の整理: limitations — この数字が意味しないこと

両研究の limitations を、実務判断に効く順に整理します。

  1. MirrorCode は「詳細で検証可能な仕様を持つ再実装」であり、通常の開発ではない。 著者ら自身が「正解の出力を返す既存プログラムが存在するという非常に特殊なセットアップに依存しており、ソフトウェアが通常開発される形ではない」と明記しています。実務の開発の大半は、仕様そのものの発見・交渉・変更に時間が使われます
  2. 初期報告の1成功例から成功率は分からない。 gotreeのOpus 4.6は1実行です。2,000/2,001はテスト合格率であり、4月初期報告の同一条件を繰り返したときのタスク成功率ではありません。完全版は複数モデル・言語・反復へ拡張しましたが、Time Horizonの50%指標は別タスク群なので代入できません
  3. 記憶混入(memorization)を完全には排除できていない。 4月初期報告では、元コードとのLevenshtein類似度が高い1対象を掲載対象から除外しました。完全版では25対象中17対象に潜在的な記憶の証拠を検出した一方、記憶の証拠が無い対象でも成功しており、記憶の証拠がある対象で失敗した例もありました。著者らは、記憶だけが結果を駆動したとは示されないものの、その影響も排除できないとしています
  4. 合格したコードの品質は保証されない。 テストに合格した実装にも「避けられたはずの重複」「詰め込みすぎたフィールド」があったと著者らは指摘しています。テスト合格と保守可能なコードは別物です
  5. 推定の不確実性が大きい。 Time Horizon 1.1 の信頼区間は広く(Opus 4.5 で170〜729分)、長時間タスクの人間ベースラインの多くは実測ではなく見積もりです。MirrorCode も初期報告では24本中4本の詳細分析にとどまります

岡崎の分析

この2つの研究を並べたとき、私が最も重要だと考えるのは「AIは数週間のタスクをできるのか、できないのか」という二値の問いを捨てることです。MirrorCodeは、正解プログラムと可視テストから反復的にフィードバックを得られる条件で、長く作業できた例を示しました。完全版でも対象間の差は大きく、Time Horizon研究は別のタスク分布で成功率を推定しています。したがって「AIに任せられる範囲」は、モデルの能力だけでなく、発注側が正解条件と検証ループをどれだけ設計できるかも関係する——これが安全な読み方だと私たちは考えます。

外注管理でも、要件と検収条件を明文化できる案件ほど進捗と完了を確認しやすくなります。MirrorCodeの条件はこの構造に似ています。そこで私たちは、外注に出せるほど整理されたタスクをAI委任の検証候補にすることを提案します。ただし、研究は人間委託との費用・品質比較を行っていません。2〜17週間は4人の見積もりで、550ドルは10億トークン上限の費用目安です。これらを使って受託開発との価格差や置換時期を断定することはできません。

「では開発の外注はもう不要か」と問われれば、この研究だけでは判断できません。4月初期報告のgotreeについて、Opus 4.6の同一条件を繰り返した場合の成功率は未推定で、実装コードの品質には重複や不自然なデータ表現がありました。また、2,001テストが存在しても26コマンドは評価対象外です。何が正解かを定義し、未評価領域と保守性を確認する仕事は残ります。実装力から仕様力・検証力へ比重を移すべきだというのは、本レポートの提言であって、研究が直接測定した結論ではありません。

内製チームでは、「検収条件まで書けるタスク」と「仕様の探索そのものが仕事のタスク」を分けて測る必要があります。前者をAI委任の検証候補にし、後者は人間主導を初期設定にする、というのが本レポートの運用仮説です。仕様を受け取って実装し、レビューを受けて直す中間工程の一部が、AI成果物を検証する仕事へ移る可能性があります。検証側にはコード読解だけでなく、仕様の穴を突くテスト設計が必要になるため、育成対象として扱うことを提案します。

Time Horizon 1.1では、全期間の接続推定が196.5日、2024年以降の部分集合が88.6日でした。ただし、後者をそのまま将来へ外挿する根拠はありません。実務では「半年で必ず陳腐化する」と決め打ちせず、同じ自社タスク・同じ合格条件で定期的に再評価することが重要です。四半期という周期は、88.6日の推定値を参考にした本レポートの運用提案です。

提言 — どう付き合っていくか

経営者・開発責任者向けに、明日から使える判断軸に落とします。基本の構えは「線引きを固定せず、見直しサイクルを持つ」ことです。

タスクの性質 現時点の委任判断 見直しの目安
検収条件・テストが明文化できる、独立した実装タスク AI委任の第一候補。人間は検収に専念 四半期ごと
仕様は書けるが、検証が人手レビューに依存するタスク 部分委任(下書き・叩き台)。完遂委任はまだ早い 半年ごと
仕様の発見・交渉・変更が主戦場のタスク 人間主導を維持。AIは調査・整理の補助 年次
  1. 委任範囲の見直しを「四半期の定例」にする。 四半期に一度、前回できなかった同じタスクを、同じ合格条件で最新モデルへ再試行します。周期は固定的な研究結論ではなく、変化を観測するための運用上の初期値です
  2. 委任の可否を「自社の検証能力」も含めて判定する。 MirrorCodeの条件——実行可能な正解、開発中の可視テスト、提出後の未公開テスト——を自社へ引き寄せ、「完了を機械的または短時間で検証できるか」を確認します。テストが対象外とする機能も明記します
  3. 成功率を自社で測る。 gotreeの1成功例や別スイートの50%時間軸を、自社タスクの成功率として使わないでください。同条件で複数回試し、成功率、検収時間、再実行コストを記録して、人間へ頼む場合と比較します
  4. 外注管理の資産を、AI委任の検証基盤として試す。 要件定義書、検収条件、受け入れテストは、AIへ期待する入出力を明確にする材料として再利用できる可能性があります。自社タスクで効果を測ってください
  5. 「仕様力・検証力」を研修対象に加える。 検証可能性が委任範囲に影響しうるなら、何が正解かを定義できる人材の重要性は高まると予測します。これは本レポートの仮説であり、MirrorCodeが人材需給を測った結果ではありません

「AIは数週間規模の開発タスクを完遂できるか」という問いへの、現時点で一次データに忠実な答えは——「MirrorCode完全版では、一部の詳細で検証可能な再実装タスクに複数の完遂例がある。ただし最難関対象は未解決で、通常開発への一般化とコード品質は未確定」です。モデルの進歩を待つだけでなく、自社で正解条件・検証ループ・人の検収点を整え、小さく反復測定することをおすすめします。


本レポートは公開データのみに基づく分析です。MirrorCodeの4月初期結果と、6月公開・7月改訂の完全版(arXiv v2)を区別して記載しています。各数値の調査設計の詳細は、末尾の出典から一次情報をご確認ください。

出典・参照データ

本レポートの分析は以下の一次情報に基づいています。統計・数値の詳細は各出典をご確認ください。

  1. MirrorCode: Evidence that AI can already do some weeks-long coding tasks
    METR

    MirrorCodeがMETRの資金提供・共同開発によるベンチマークであること、および「数週間規模のコーディングタスクを完遂できる」という位置づけ(初期結果)を引用

  2. MirrorCode: Evidence AI can already do some weeks-long coding tasks(詳細レポート)
    Epoch AI

    ベンチマーク設計、gotreeの対象範囲(74コマンド中48、隠し102テスト)、Opus 4.6の1実行(2,000/2,001、280Mトークン、2,989メッセージ)、旧世代のbest-of-3、Pkl未達成、10億トークン上限の費用目安、limitationsを引用

  3. Measuring AI Ability to Complete Long Software Tasks
    METR

    50%時間軸(time horizon)の定義、「約7ヶ月ごとの倍増」トレンド、公開時点の最前線モデル(Claude 3.7 Sonnet)の時間軸が約1時間であったことを引用

  4. Measuring AI Ability to Complete Long Tasks(論文)
    arXiv

    time horizon研究の論文版。手法(ロジスティック曲線による50%成功率タスク長の推定)とlimitations(タスク選定・ベースライン測定への依存)を参照

  5. Time Horizon 1.1
    METR

    更新版の時間軸推定。Claude Opus 4.5の50%時間軸320分(信頼区間170〜729分)、全期間と2024年以降の部分集合における倍増期間、タスク数228件への拡充、タスク構成への感度等のlimitationsを引用

  6. MirrorCode: What's the largest software project AI can complete on its own?
    Epoch AI

    完全版の25対象、最強モデル56%、Opus 4.7によるgotree再実装(14時間・251ドル・2,000/2,001)、Pklの更新、公開ベンチマークとlimitationsを引用

  7. MirrorCode: AI can rebuild entire programs from behavior alone(arXiv:2606.30182v2)
    Epoch AI / METR(arXiv)

    完全版論文。25対象の評価設計、可視・隠しテストの境界、17/25の完全成功例・追加4/25の99%超、モデル・言語・推論予算別の結果、コード品質と一般化の限界を参照