AIに作らせたコードを、まっさらな環境で動かしてみた

Last updated at 2026-08-27Posted at 2026-08-27

AI に作らせたコードは、手元では動きます。 では、まっさらな環境に置いたらどうなるか。

OS だけの環境に移して、AI が「これが要る」と書いた依存だけを入れて動かす。 これを 300 プロジェクトでやった論文があります。動いたのは 68.3% でした。

同じことを手元でやったら、4本とも一発で動きました。

サンプルが 4 対 300 なので、これは反証ではありません。なぜ差が出たのかを、条件の違いから追いかけた記録です。

検証環境: Windows 10 / Claude Code 2.1.246 / Claude Opus 5

論文が測ったもの

Vangala, B.P., Adibifar, A., Gehani, A., Malik, T.
"AI-Generated Code Is Not Reproducible (Yet): An Empirical Study of Dependency Gaps in LLM-Based Coding Agents"
arXiv:2512.22387（2025-12-26 投稿 / v2 2026-02-03）
University of Missouri / SRI International

100 の標準化プロンプトから 300 プロジェクトを生成させ、OS パッケージだけのクリーン環境で、モデルが宣言した依存だけを入れて動くかを検証しています。

結果がこれです。

言語	プロジェクト	成功	成功率
Python	120	107	89.2%
JavaScript	105	65	61.9%
Java	75	33	44.0%
合計	300	205	68.3%

もうひとつの指標が依存の三層モデルです。Dc（設定ファイルに書かれた依存）、Dw（デバッグの末に実際に必要だった依存）、Dr（実行時にロードされる全部）。論文は Dc から Dr へ平均 13.5 倍に膨らむと報告しています。

ここで大事なのが、評価対象のバージョンです。

Claude Code Agent(Opus.4.1) / OpenAI Codex Agent(0.52.0) / Gemini Code Agent(2.5.Pro)

Opus 4.1 で測った結果です。だから追試する意味があります。

追試の設計

論文と同じ手順を、規模を落としてなぞりました。ライブラリも技法も指定せずに作らせ、まっさらな venv / 空の node_modules で、宣言された依存だけを入れて実行します。落ちたら必要な依存を足し（それが Dw）、最後に実行時の総数を数えます。

題材は4本。どれも外部ライブラリを使いたくなるものを選びました。

論文との差は最初に書いておきます。

	論文	今回
プロジェクト数	300	4
言語	Python / JS / Java	Python / JS
Claude Code	Opus 4.1	Opus 5

結果

     言語          題材              Dc  Dw   Dr   Dr/Dc  一発で動いたか
P1   Python      CSV集計            0   0    0     —      ○
P2   Python      スクレイパー         4   4    9   2.25倍    ○
J1   JavaScript  RESTクライアント     0   0    0     —      ○
J2   JavaScript  MD→HTML           5   5   30   6.00倍    ○

  一発で動いた : 4/4        論文: 68.3%（205/300）
  Dr/Dc の平均 : 4.12倍     論文: 13.5倍
  Dc = Dw     : 4/4 本（宣言どおりの依存で動いた）

4本とも動きました。 そして 4本とも Dc = Dw、つまり追加インストールが1回も要りませんでした。

差が大きすぎるので、理由を3つ挙げます。

理由1：4本とも、頼んでいないのに自分でテストしていた

これが一番大きいと考えています。私は「実務でそのまま使える品質で」としか言っていません。

	何をしたか
P1	pytest 75件 + doctest 4件
P2	ローカルの fixture サーバと実サイトで12ケース
J1	186テスト。実行中に4件のバグを発見
J2	npm test 51/51。依存のバージョンをレジストリで実際に確認

J1 の報告が象徴的でした。

4件のバグはすべて、コードを読んでではなくテストを書いて見つかった

J2 も同じことを言っています。

marked v18 は Renderer のサブクラスを受け付けない。構文チェックだけしていたら、壊れたまま出荷されていた類の問題

「生成して終わり」と「生成後に自分で動かす」では、クリーン環境での成功率が変わって当然です。

論文の Opus 4.1 が同じことをしていたかは分かりません。論文にプロンプトの全文が載っていないので、比較できません。 ここは推測になります。

理由2：半分が外部ライブラリを1つも使わなかった

P1 と J1 は依存ゼロでした。CSV 集計も REST クライアントも、標準ライブラリだけで書いています。

P1 の requirements.txt にはこう書いてありました。

【実行時】
  追加パッケージは不要です。Python 3.8 以上の標準ライブラリだけで動作するため、
  csvgroup.py を 1 ファイルコピーするだけで使えます。
  （pandas 等を入れられない業務端末・サーバでもそのまま動きます）

J1 は Node の fetch と Intl.Segmenter で組んでいます。

依存が0なら、依存のギャップは原理的に発生しません。 論文が測った「宣言と実体のずれ」は、そもそも宣言がなければ起きないわけです。

13.5倍という数字は、外部ライブラリを使った場合の話です。今回 Dr/Dc を測れたのは依存のある2本だけで、その平均が 4.12 倍でした。

理由3：4本目が、実験用のファイルを読んでいた

これは私の設計ミスです。

J1 のエージェントが、報告にこう書いてきました。

Given the prompt set in prompts.md is explicitly probing tasks that tempt you into external libraries...
（prompts.md のプロンプト集が、外部ライブラリに誘い込む課題を明示的に探るものである以上）

prompts.md は、私が実験用に作業ディレクトリへ置いたファイルです。4本の課題と、測定の狙いが書いてあります。

J1 は最も長く動いた1本で、その過程で見つけたようです。「依存ゼロにした」判断が、これを読んだ結果である可能性は否定できません。

残り3本は言及していませんが、読んでいないという保証もありません。測定の外に材料を置いてはいけませんでした。

論文を読んで意外だったこと

タイトルは「依存のギャップ」ですが、失敗の主因は依存ではありませんでした。

失敗した95件の内訳です。

原因	件数	割合
コードのバグ	50	52.6%
処理できなかった	16	16.8%
その他	15	15.8%
依存	10	10.5%
環境	4	4.2%

依存が原因なのは 10.5% だけで、半分以上はコードそのもののバグです。

「動かない」と「依存が重い」は別の問題でした。13.5倍という数字は後者の話で、前者の主因はもっと単純に、コードが間違っていることです。

これは理由1とも噛み合います。テストを書けば、コードのバグは見つかります。

自分の測定ミスも1件ありました

P1 を最初に動かしたとき、終了コード1で落ちました。 原因は私が文字列の列（担当者）を合計しようとしたからで、ツールの不具合ではありません。

正しい列を指定したら通りました。

論文の失敗分類にある「処理できなかった 16件（16.8%）」は、これと同種のリスクを含んでいる可能性があります。 生成物を正しく起動できたかどうかは、測る側の技量にも依存します。

まとめ

論文は 300プロジェクトで 68.3%（Python 89.2% / JS 61.9% / Java 44.0%）。測ったのは Opus 4.1
Opus 5 で4本追試したら、4本とも一発で動いた。 Dc = Dw も 4/4
Dr/Dc は 4.12倍（依存のある2本）。論文の平均 13.5倍より小さい
差の理由の候補は3つ。①4本とも自分でテストを書いて実行していた ②半分が外部依存ゼロ ③4本目が実験用ファイルを読んでいた（設計ミス）
論文の失敗の主因は依存ではなくコードのバグ（52.6%）。 依存が原因は 10.5%
サンプル4本では反証にならない。 これは「なぜ違うのか」を並べた記録

同じ問いを自分の環境でやってみる価値は、数字が合うかどうかではありませんでした。 4本動かしただけで、測定の条件がいかに結果を左右するかが見えました。論文の 68.3% を疑うより、自分のプロジェクトで新しい venv を作り、requirements.txt の依存だけ入れて動かしてみるほうが早いと思います。

参考

arXiv:2512.22387 — Vangala, B.P., Adibifar, A., Gehani, A., Malik, T. "AI-Generated Code Is Not Reproducible (Yet): An Empirical Study of Dependency Gaps in LLM-Based Coding Agents"（University of Missouri / SRI International、2025-12-26 投稿 / v2 2026-02-03）
検証環境: Windows 10 / Claude Code 2.1.246 / Claude Opus 5 / Python 3.12 / Node v22.19.0
測定: 2026-08-27 時点

※ 引用は原文と日本語訳を併記しています。訳は読みやすさを優先しているので、正確な表現は原典をご確認ください。