LLMコーディングエージェントの「得意言語」と「苦手言語」　300件検証で見えた、数字の裏にある理由

GeminiはPythonで成功率100%、しかしJavaでは28%。一方ClaudeはJavaで80%と独り勝ち。LLMコーディングエージェントには、公式ドキュメントに書かれていない「得意言語」があることが300件の検証で判明しました。

本記事では、3つのエージェントに同じプロンプトを与え、生成されたコードをまっさらな環境で実行するという検証事例を取り上げます。300件のプロジェクトを対象に、成功・失敗を記録し、失敗したものは原因を一つひとつ分類しています。

冒頭で触れた得意言語の差は、この検証で明らかになった発見の一つです。しかし、それだけではありません。

たとえば、動かなかったプロジェクトの失敗原因。依存関係の記載漏れが主因だと思われるかもしれませんが、実際にはそれは1割程度でした。では過半数を占めた原因は何だったのか。

あるいは、動いたプロジェクトに潜む問題。LLMが「このコードは3つのパッケージで動きます」と申告したものが、実際には30以上のパッケージを必要としていたケースもありました。

以下で詳しく見ていきましょう。

研究手法

「箱から出してすぐ動くか」を測定する

研究者らは、Claude Code、OpenAI Codex、Geminiという3つの主要なLLMコーディングエージェントを対象に、生成されたコードの再現性を検証しました。

まず「実行可能信頼性」という指標を定義。LLMが生成したコードを、追加のパッケージが一切インストールされていないクリーンな環境に移したとき、LLMが指定した依存関係だけでそのまま動作する割合を示すものです。人間が手を加えなくても「箱から出してすぐに動くかどうか」を測るための指標です。

LLMが「必要」と言った数と実際に必要な数は違う

この研究で面白いのは、依存関係を「LLMが必要だと申告した数」と「実際に必要だった数」とで比較している点です。

たとえば、LLMに「Webスクレイピングのツールを作ってください」と依頼したとします。するとLLMは、「flaskとrequestsがあれば動作します」と判断し、requirements.txtに2つのパッケージだけを記載するかもしれません。しかし、実際にそのコードを実行してみると、beautifulsoup4がインストールされていないためにエラーが発生します。コードの中ではこのライブラリを使っているにもかかわらず、設定ファイルへの記載が抜け落ちていた、という状況です。

さらに問題はそれだけではありません。必要なパッケージを追加してようやくコードが動くようになったあと、実行時にどのパッケージが読み込まれているかを調べると、想像以上に多くのものが使われていることが分かります。たとえばflaskをインストールすると、werkzeugやjinja2、clickなど、20以上のパッケージが自動的に一緒に導入されます。これは「推移的依存関係」と呼ばれるもので、あるパッケージが内部で別のパッケージを利用し、その先でもさらに別のパッケージが利用される、という連鎖によって生じます。

研究者らは、このギャップを定量的に捉えるために、LLMが申告した依存関係の数と、実行時に実際にロードされたパッケージ数の比率を「実行時倍率」と名付けました。その結果、この倍率は平均で13.5倍にも達することが明らかになりましたが、具体的な数値や内訳については後ほど詳しく説明します。

「再現できるコードを書いて」と明示的に依頼

研究者らは100種類のプロンプトを用意し、Claude Code、OpenAI Codex、Geminiにそれぞれ同じ内容を与えました。その結果、合計で300のプロジェクトが生成されています。使用されたプログラミング言語の内訳は、Pythonが40件、JavaScriptが35件、Javaが25件で、実際の開発現場における利用頻度を意識した配分になっています。

ここで重要なのは、プロンプトの内容です。すべてのプロンプトには、「再現可能なコードを生成してください」「すべての依存関係とバージョンを含めてください」「クリーンな環境で100%再現できるようにしてください」といった指示が、はっきりと書かれました。つまり、LLMに対して、動作することと再現性の両方を強く求めた条件でコード生成を行わせています。

タスクの種類もWebスクレイピング、データ分析、機械学習、APIサーバー、リアルタイム通信、業務システムなど、実際の仕事の中で遭遇しやすい開発シナリオが幅広く設定されています。

まっさらなPCを再現してテスト

生成されたコードを検証するうえで、テスト環境の設計も重要なポイントです。開発者のパソコンには、過去にインストールしたさまざまなパッケージが残っているのが普通で、その環境で動いたとしても、本当に再現性があるとは限りません。

そこで研究者らは、AWS上にUbuntu 22.04をインストールした、いわば「まっさらな環境」を用意しました。この環境には、OSに標準で含まれる71のシステムパッケージと、依存関係を追跡するためのツール20個のみが入っており、合計でも91パッケージしか存在しません。1つのプロジェクトをテストするたびに環境を完全に初期化し、前回のテストの影響が次に持ち越されないようにしています。

実行時に実際にどのパッケージが読み込まれているかを調べるため、使用するツールは言語ごとに分けられています。Pythonではimport文の挙動を監視するSciUnitを使い、JavaScriptではnpmの依存関係ツリーを解析し、JavaではMavenの依存関係ツリーを抽出しています。

失敗したプロジェクトは、なぜ失敗したかを深掘り

コードがそのまま実行できたプロジェクトは「成功」として扱われます。一方で、実行に失敗したプロジェクトについては、原因を特定するための詳しい分析が行われました。エラーメッセージを確認し、必要なパッケージが不足していれば追加し、コードに不具合があれば最小限の修正を行います。この作業を繰り返しながら、最終的に動作するまでに何が必要だったのかを記録しています。

ただし、このような追加の修正や調整は、あくまで失敗原因を分析するためのものであり、成功率の算出には含まれていません。したがって、後に示される68.3%という成功率は、人間が一切手を加えずに、そのまま実行できたプロジェクトだけを対象にした、厳密な数値となっています。

実験結果

300プロジェクト中、そのまま動いたのは205件

いよいよ実験結果を見ていきます。300のプロジェクトのうち、何も手を加えずにそのまま実行できたのは205件で、割合にすると68.3%でした。見方を変えると、約3分の1にあたる95件のプロジェクトは、そのままでは動かなかったことになります。

動かなかった95件については、前述した手順に沿って原因分析が行われました。なお、1件あたりのデバッグにかかった時間は平均で15分だったと報告されています。AIにコード生成を任せれば作業が早くなると期待していても、実際には3回に1回は追加の調査や修正が必要になる計算です。チーム全体で考えると、この手間は小さくありません。

Pythonは優秀、Javaは苦戦

プログラミング言語ごとに成功率を見ると、結果にははっきりとした差が表れました。Pythonは89.2%と非常に高い成功率を示した一方で、JavaScriptは61.9%、Javaは44.0%と、半分以下にまで落ち込んでいます。

この差の背景として、研究者らは依存関係管理の仕組みの違いを挙げています。Pythonのrequirements.txtは形式が単純で、必要なパッケージ名とバージョンを並べるだけで済みます。また、エラーが出た場合も「このモジュールが見つかりません」といった形で原因が分かりやすいです。

これに対してJavaのMavenは、XML形式の複雑な設定ファイルを使い、依存関係にはコンパイル時や実行時、テスト時といったスコープの概念が存在します。さらに、バージョン競合の解決ルールも入り組んでおり、LLMがこれらを正確に扱いきれていないと考えられます。

JavaScriptは両者の中間に位置します。npmが依存関係を自動的に解決してくれる利点はあるものの、依存関係が深くネストしやすく、それが別の複雑さを生んでいます。

エージェントごとに「得意な言語」がある

もう一つ興味深い点として、3つのエージェントそれぞれに得意な言語があることが分かりました。事前の説明資料などには書かれておらず、実験によって初めて明らかになった特徴です。

GeminiはPythonで100%という結果を出し、40件すべてのプロジェクトがそのまま動作しました。一方で、Javaでは成功率が28.0%まで急激に下がっています。研究者らは、Pythonのデータ分析や機械学習関連コードを大量に学習している影響ではないかと推測しています。

これとは対照的に、ClaudeはJavaで80.0%という高い成功率を記録しました。GeminiやCodexのJava成功率が24〜28%だったことを踏まえると、大きな差があります。業務システムなど、エンタープライズ向けのJavaコードに強みがある可能性が示唆されます。ClaudeはPythonでも80.0%、JavaScriptでも60.0%と、3言語を通じて比較的バランスの取れた成績を残しています。

CodexはPythonで87.5%と健闘しましたが、Javaでは24.0%と低迷しました。スクリプト言語には強い一方で、構成が複雑になりがちなシステムには弱い傾向が見て取れます。

これらの結果は、LLMエージェントを選ぶ際に、どの言語で主に使うのかを考慮する必要があることを示しています。たとえばPython中心の分析チームであればGemini、Javaを用いた業務システム開発であればClaudeといった使い分けが考えられます。

依存関係の記載漏れは意外と少なかった

次に、依存関係の記載漏れ、いわゆる完全性ギャップについて見ていきます。結果として、87%のプロジェクトでは、LLMは必要なパッケージをすべて正しく記載していました。記載漏れがあったのは13%にとどまり、その場合でも不足していたパッケージは1〜3個程度でした。

漏れやすいパッケージには一定の傾向が見られました。Pythonではlxmlやpython-dotenv、bcryptが抜けやすく、JavaScriptではbody-parserやws、dotenvが多く見られました。JavaではJUnitやSLF4Jといった、テストやロギング関連のライブラリが記載されていないケースが目立ちました。

ただし重要なのは、依存関係の記載漏れが実行失敗の直接的な原因になったケースは、失敗した95件のうち10件、割合にして10.5%しかなかったという点です。多くの失敗は、別の理由によるものでした。

申告3パッケージ、実際は37パッケージ

依存関係に関するもう一つの指標である実行時倍率の結果は、さらに印象的です。Pythonプロジェクトでは、LLMが申告した依存関係は平均で3パッケージだったのに対し、実行時に実際にロードされていたパッケージは平均37個に達していました。およそ12倍の差があります。

言語別に見ると、実行時倍率が最も高かったのはJavaで9.5倍、次いでPythonが2.5倍でした。一方、JavaScriptは1.0倍と、ほとんど差がありませんでした。研究者らは、JavaScriptではLLMが依存関係を多めに申告している可能性や、npmの解析手法が直接的な依存関係しか捉えていない可能性を指摘しています。

具体的な例として、ある機械学習プロジェクトでは、LLMはscikit-learn、pandas、matplotlibの3つだけを依存関係として記載していました。しかし実際に実行すると、numpyやscipy、joblib、threadpoolctl、cycler、pyparsing、python-dateutil、pytz、six、kiwisolver、pillowなど、合計52ものパッケージがメモリ上に読み込まれていました。

これらはすべて推移的依存関係として自動的に導入されるため、普段は意識されにくいものです。しかし再現性の観点では、これらのうち1つでもバージョンが変われば、コードが動かなくなる可能性があります。LLMは3パッケージしか申告していないため、残りの49パッケージについては、事実上バージョン管理が行われていない状態だと言えます。

失敗の過半数は「コードのバグ」だった

失敗した95件のプロジェクトについて、原因を分類した結果も示されています。依存関係の問題というよりも、実際の失敗原因はより根本的な部分にありました。

最も多かったのはコード自体のバグで、50件と全体の52.6%を占めています。ファイル構成が不適切でimportパスが壊れていたり、変数が初期化されていなかったり、JavaScriptでasyncやawaitの使い方を誤っていたり、Mavenの設定ファイルが正しくなかったりと、原因はさまざまでした。これらはいずれも依存関係の問題ではなく、LLMが正しいコードを生成できていなかったケースです。

次に多かったのが処理不能で16件、全体の16.8%でした。これはCodexとGeminiに見られた現象で、生成されたコードが壊れており、そもそも解析や実行ができない状態でした。

その他は15件で15.8%を占め、バージョン競合など複数の要因が絡んだケースが含まれています。

依存関係の記載漏れによる失敗は10件で10.5%でした。PythonのModuleNotFoundErrorや、JavaScriptのCannot find moduleといったエラーがこれに該当します。パッケージを追加すれば解決しますが、そもそもLLMが記載を忘れていた点が問題です。

環境エラーは4件で4.2%と最も少なく、システムレベルでの競合や互換性の問題でした。

エージェント別に見ると、Codexはコードバグが24件と最も多く、構文生成に課題があることがうかがえます。Claudeは依存関係の記載漏れが7件と他より多く、パッケージ管理に弱点がある可能性があります。Geminiは各カテゴリに比較的均等にエラーが分布していました。

3回に1回は動かないことを肝に銘じる

全体として見ると、LLMコーディングエージェントが生成したコードは、約3回に1回はそのままでは動かないという結果になりました。成功率は68.3%にとどまり、失敗の主な原因は依存関係ではなく、コードそのもののバグでした。また、成功したプロジェクトであっても、申告された依存関係と実際に必要な依存関係の間には、平均で13.5倍もの差がありました。

AIコーディングツールに対する期待を見直す必要があることを示しています。AIに任せれば自動的に完成度の高いコードが得られるわけではなく、人間による確認やデバッグが依然として重要であることが、数字として示されています。

考察

デバッグ時間という「見えないコスト」

実験結果を受けて、研究者らはいくつかの重要な示唆を示しています。

まず注目されているのが、AIコーディングツールに伴う「見えにくいコスト」。全体の31.7%のプロジェクトでデバッグが必要となり、1件あたり平均15分を要したという結果は、生産性向上をうたうAIツールのイメージとは異なる現実を示しています。仮に100件のプロジェクトを生成した場合、合計で約8時間がデバッグ作業に費やされる計算になります。

さらに注意したいのは、AIが生成したコードのデバッグは、人間が書いたコードとは性質が異なる点です。人間が書いたコードであれば、書いた本人に意図を確認できますが、AIが生成したコードにはそれができません。開発者はコードを読み解きながら、AIが何をしようとしていたのかを推測する必要があります。この作業は認知的な負荷が高く、想像以上に疲労を伴うものです。

言語の選択が再現性を左右する

Pythonの成功率が89.2%であるのに対し、Javaは44.0%にとどまったという差は、単なる言語の好みの違いではありません。これはプロジェクト全体の再現性リスクに直結する問題です。

Pythonで成功率が高い理由は、依存関係の仕組みが比較的シンプルだからです。requirements.txtにパッケージ名とバージョンを記載すればよく、エラーも「このモジュールが見つかりません」といった形で分かりやすく表示されます。一方、JavaではMavenのXML設定が複雑で、依存関係のスコープやバージョン解決のルールも入り組んでいます。LLMは、こうした複雑な構造を十分に扱えていないようです。

実務的に考えると、Pythonを中心としたチームでは、生成されたコードの多くがそのまま動くと期待できますが、Javaを主に使うチームでは、半分以上のケースで修正作業が発生することを前提に計画を立てる必要があります。JavaScriptは両者の中間に位置し、dependenciesとdevDependenciesの違いが原因で、開発環境では動くものの本番環境では失敗するといった問題が起こる可能性もあります。

「どのAIを使うか」より「何の言語で使うか」

GeminiがPythonで100%、ClaudeがJavaで80%という結果は、AIツール選びに新しい視点を与えています。これらの得意分野は、ベンダーの公式資料には記載されておらず、実際に試してみて初めて分かる「隠れた特性」です。

研究者らは、この違いは学習データの偏りによるものだと考えています。Geminiはデータサイエンス分野のPythonコードを大量に学習しており、Claudeはエンタープライズ向けのJavaコードに強い傾向があると推測されています。

そのため、LLMエージェントを選ぶ際には、機能や価格だけで判断するのではなく、自分たちが主に使うプログラミング言語との相性を検証することが重要かもしれません。汎用的な評価指標だけを信じるのではなく、実際の技術スタックで試してみる姿勢が求められます。

根本的な解決には学習データの改善が必要

問題を根本的に解決するにはどうすればよいのでしょうか。研究者らは、開発者側がベストプラクティスを徹底するだけでは不十分で、LLMそのものを改善する必要があると指摘しています。

現在のLLMは、主にコードの断片を通じて学習しています。そのため、「scikit-learnは機械学習に使われる」という知識は持っていても、「scikit-learnを使うためにはnumpyやscipy、joblibなど多くのパッケージが必要になる」といった実行環境全体の情報までは学習できていません。

解決策としては、完全な依存関係の定義を含むプロジェクトや、実際に動作するDockerファイル、成功事例のlockファイルなどを学習データとして活用することが提案されています。

さらに踏み込んだ案として、LLMが自ら生成したコードをクリーンな環境で実行し、エラーが出た場合には修正を行う、という反復的なプロセスを学習に取り入れることも挙げられています。人間が行っているデバッグ作業をAI自身が担えるようになれば、再現性の問題はコード生成の段階で解消される可能性があります。

まとめ

本記事では、LLMコーディングエージェントが生成するコードの再現性を検証した研究の内容を紹介しました。

300件のプロジェクトのうち、クリーンな環境で人手を加えずにそのまま動作したのは68.3%にとどまっていました。失敗の主な原因は依存関係の記載漏れではなく、コードそのもののバグでした。また、成功したプロジェクトであっても、LLMが申告した依存関係の数と、実際に必要だったパッケージの数には平均で13.5倍もの差があることが分かっています。加えて、Pythonは成功率が89.2%と高い一方で、Javaは44.0%と低く、使用する言語によって結果に大きな差が生じる点も明らかになりました。さらに、GeminiはPythonに強く、ClaudeはJavaに強いといったように、エージェントごとに表に出にくい得意分野が存在することも示されています。

AIにコード生成を任せることで開発が効率化するのは確かですが、その一方で、約3回に1回はデバッグ作業が必要になるという現実も無視できません。AIを活用する際には、この点を前提として期待値を調整し、人間による確認や修正を組み合わせて使っていく姿勢が重要だと言えそうです。