結論を先に

熟練エンジニアで2〜17週と見積もられた約16,905行のツールキット再実装を、最新モデルがE2Eテスト2,000/2,001件（99.95%）で完遂しました。ただし約61,461行の課題では10億トークン（約550ドル相当）の約9割を消費して可視テスト256/733件（35%）で未解決。規模が数倍になると崩れます。暫定結果であり、詳細分析は24本中4本のみです。

（出典：Epoch AI（MirrorCodeの開発はMETRからの助成で支援され、チームにはEpoch AIとMETR双方のメンバーが含まれる）、2026-04-10、https://epoch.ai/publications/mirrorcode-preliminary-results/）

まず、数字の出どころを明かします

読み進める前に、二つの利害関係を先に置いておきます。

一つ目は発表側です。この記事は Epoch AI 自身によるベンチマークの発表であり、同社は当該ベンチマーク（MirrorCode）の開発者・提供者であるという点です。さらに MirrorCode の開発は METR からの助成で支援されており、チームには Epoch AI と METR 双方のメンバーが含まれます。つまり「ベンチマークを作った側が、そのベンチマークの結果を発表している」構図です。これは不正を意味しませんが、読者が数字の性質を判断するために必要な情報です。なお、本文にはモデル開発元との利害関係や他の資金源に関する記述はありません。

二つ目は当メディア側です。この記事を書いている株式会社TOEは、中小企業向けにAI導入支援を行う会社であり、「AIを使いましょう」と提案して対価を得る立場にあります。そのうえで、TOEはこのベンチマークを自社で再現していません。後半の読み筋は、すべてTOE未実施の前提で書いています。

MirrorCodeは何を測っているのか

MirrorCode が課すのは、コード補完でもバグ修正でもありません。既存のオープンソースプログラムを、仕様に沿って別言語でゼロから作り直すという課題です。元の実装のテストスイートを判定基準に使い、機械的に合否を出します。

対象範囲は次のとおりです。

  • ベンチマークとして選ばれたプログラムは24本。「評価しやすいもの」を基準に手動で選定されている
  • 今回の暫定結果（preliminary results）で詳細に分析されたのは、そのうち4本のみ
  • 評価対象モデルは Claude Opus の4世代（4.0 / 4.1 / 4.5 / 4.6）
  • 推論予算は1タスクあたり10億トークンが上限。同社の設定で約550ドル相当

つまり「AIの開発能力全般」を測った調査ではなく、選び抜かれた24本のうち4本について、1社4世代のモデルで試した暫定的な速報です。ここを外すと、後の数字を読み違えます。

実測値 ― 1.7万行は通り、6.1万行は通らなかった

中心となるのは2本です。1本目が gotree（バイオインフォマティクス用ツールキット、元コードベース約16,905行のGo）、2本目が Pkl（設定記述言語、元コードベース約61,461行のJava/Kotlin）。

gotree では、世代が進むにつれて通過数がはっきり伸びました。

モデル gotree E2Eテスト通過（分母2,001件） 通過率
Opus 4.0 307/2,001 15%
Opus 4.1 471/2,001 24%
Opus 4.5 1,265/2,001 63%
Opus 4.6 2,000/2,001 99.95%

分母の2,001件には隠しテスト102件が含まれます。これは gotree 1本の結果であり、ベンチマーク24本中の1本にすぎません。

一方の Pkl は様相が違います。Opus 4.6 の結果は 256/733（35%） で未解決扱い。この733件は「可視テスト」であり、隠しテストを含む gotree の2,001件とは分母の性質が異なります。Opus 4.0 / 4.1 / 4.5 はいずれも未解決で、個別の通過率は本文に記載がありません。

生成された成果物の規模も並べておきます。

  • gotree：元は約16,905行（Go）。Opus 4.6 の再実装は 7,644行（Rust）。言語が異なるため行数は直接比較できません
  • Pkl：元は約61,461行（Java/Kotlin）。Opus 4.6 の再実装は 17,600行で未完（未解決）

そして消費量です。

  • gotree 完遂に要したのは 2.8億トークン／2,989メッセージ（上限10億トークン以内、gotree1本の値）
  • Pkl では 10億トークンの約90%／約9,300メッセージを使って、なお未解決

規模が約3.6倍（16,905行→61,461行）になったところで、トークン消費は約3.2倍に膨らみ、それでも完遂しませんでした。線形には伸びていないということです。

「人間なら2〜17週」の数字は、どこまで信用できるか

見出しに使われやすいのが、gotree を熟練エンジニアがAIなしで実装した場合の所要期間見積り「2〜17週」です。ここは慎重に扱う必要があります。

  • この値は AIエンジニア／研究者4名が独立に見積もったもの
  • n=4 と非常に小さい
  • 幅が8倍以上（2週と17週では別の話になります）
  • 実測ではなく主観的見積り

「AIが数週間分の仕事を数時間で終えた」という要約は、この n=4 の主観見積りに乗っています。方向性としては意味がありますが、工数見積りの根拠として社内資料に転記できる精度ではありません。自己申告や見積りが実測とずれる問題そのものはAIコーディングツールで開発は本当に速くなるのかで扱ったランダム化比較試験が示しています。

本文が認めている限界

Epoch AI 自身が挙げている制約は、実務者にとってむしろ本体です。

  • 暫定結果である。完全な結果は後続の公表で示されるとされ、より大規模な実験と対象プログラムの追加が予告されている
  • 対象範囲が極小。選定24本のうち詳細分析は4本のみ。中心的な数値は gotree 1本と Pkl 1本に依存している
  • 選定バイアスがある。対象プログラムは「評価しやすいもの」を基準に手動選定されている
  • タスク構造が現場と違う。精密で機械的に検証可能な仕様に対して実装する形式は、本文の言葉を借りれば「実際のソフトウェア開発で一般的なやり方ではない」。仕様が曖昧な現場の開発には外挿しにくい
  • 記憶（memorization）の影響を排除しきれていない。除外した対象では記憶の証拠が見つかっており、著者は「記憶が全く関与していないとは断言できない」と述べている
  • カバーしていない領域が広い。ネットワーク、データベース、グラフィックス、OSなど多くのソフトウェア領域は結果の対象外
  • 単一ベンダーのモデルのみ。評価対象は Claude Opus の4世代で、他社モデルとの比較は本文の該当箇所に示されていない

とくに重いのは4つ目です。gotree の 99.95% が成立したのは、判定基準となるテストスイートが2,001件も用意されていたからです。仕様が言葉のままの案件に、この数字は移りません。

中小企業にとっての意味 ― 使えるのは「99.95%」ではなく境界線

自社に関係あるのか。持ち帰るべきは通過率ではなく、成功した条件と崩れた条件の差です。

この結果から読み取れる実務上の分水嶺は、規模と仕様の2点に集約されます。

  • 規模：約16,905行の再実装は完遂、約61,461行は35%で未解決。数万行以内に切り出せるかが一つの目安になる
  • 仕様：合否を機械的に判定できるテストが揃っていた課題だけが通った。「良い感じにして」では成立しない
  • 費用：gotree 1本で2.8億トークン。10億トークンが約550ドル相当という同社の設定に照らせば、1案件で3桁ドル規模の推論費用が現実に発生しうる

外注見積りと比較する際、人件費だけを並べるのは不正確です。API費用を計上したうえで比べる必要があります。コストの構造そのものはAI導入のコスト構造に整理があります。

社内で先に確かめるべきは、モデルの性能ではなく自社側の準備です。

  • 対象業務の仕様を、人の判断なしに合否が出る形（テスト・チェックリスト・入出力例）に落とせるか
  • 案件を数万行以内の単位に切り分けられるか
  • 切り分けた単位ごとに、受け入れ基準を先に書けるか
  • 失敗したときに何トークン使ったかを記録できるか
  • 生成物のレビューを誰が行うのかが決まっているか

「仕様を機械的に検証できる形に書ける社内能力があるかどうか」が、AI開発活用の分水嶺になります。評価基準の作り方は自社の評価基準を持つという話、開発業務の成功率の測り方はAIエンジニアリング作業の成功率が近い論点を扱っています。

TOEの読み筋（TOEでは未実施）

先に明記します。TOEはこのベンチマークを再現していません。以下は実測ではなく解釈です。

Opus 4.0 の 307/2,001（15%）から Opus 4.6 の 2,000/2,001（99.95%）までの推移は、世代交代で能力が伸びたことを示しています。ただし同じ Opus 4.6 が Pkl では 256/733（35%）で止まりました。同一モデルの中に、通る規模と通らない規模の境目が存在するということです。

ここから読み筋を一つ立てるなら、実務で先に効くのは「AIに任せられるか」ではなく「AIに任せられる形に切れるか」だと考えています。gotree が通ったのは、モデルが賢かったからだけでなく、2,001件のテストという判定装置が先にあったからです。判定装置のない仕事は、AIが速く終えたとしても、正しく終えたかを誰も言えません。

そのうえで、この結果を根拠に社内の開発方針を変えるのは時期尚早だと見ています。詳細分析は24本中4本、人間側の見積りは n=4、対象は単一ベンダーの4世代、そして著者自身が暫定と明記しています。判断材料として使うなら「規模と仕様の境界に注意する」までで、工数削減率の根拠には使えません。

まとめ

  • Epoch AI の暫定結果では、約16,905行（Go）の gotree 再実装で Opus 4.6 が E2Eテスト 2,000/2,001件（99.95%）を通過した。同一課題で Opus 4.0 は 307/2,001（15%）、4.1 は 471/2,001（24%）、4.5 は 1,265/2,001（63%）（出典：Epoch AI、2026-04-10）
  • 一方、約61,461行（Java/Kotlin）の Pkl では 10億トークンの約90%・約9,300メッセージを消費して可視テスト 256/733件（35%）で未解決。分母の性質が gotree と異なる点に注意が必要
  • gotree の完遂に要したのは 2.8億トークン／2,989メッセージ。1タスク上限の10億トークンが約550ドル相当という設定であり、外注比較ではAPI費用の計上が要る
  • 限界は大きい。詳細分析は選定24本中4本のみ、人間の「2〜17週」見積りは n=4 の主観で幅が8倍以上、対象は「評価しやすいもの」の手動選定、記憶の影響も排除しきれていないと著者が認めている。本文自身がタスク構造を「実際のソフトウェア開発で一般的なやり方ではない」としている
  • この記事の一次資料は Epoch AI 自身による発表で、同社は当該ベンチマークの開発者・提供者。開発は METR の助成で支援され、チームには双方のメンバーが含まれる
  • TOEはこのベンチマークを未実施。実務で使える示唆は「数万行以内に切り出せ、合否を機械的に判定できる仕様が書けるか」という自社側の準備の話に尽きる