AIコーディングツールを使っていると、「なぜかPythonのコードはすんなり通るのに、別の言語だと的外れな提案が返ってくる」という経験をしたことはないでしょうか。この差は偶然ではなく、研究データが示す構造的な傾向です。
この差が生まれる背景には、学習データの量・言語の文法的複雑さ・ベンチマーク設計という複数の要因が絡んでいます。本記事では、Chen et al.（2021）・Cassano et al.（2023）・Nguyen & Nadi（2022）などの主要研究が示す傾向を整理します。
なお、本記事は研究の傾向をまとめたものであり、個別スコアの詳細は各論文を参照してください。言語選定やAIツール活用の判断を、なんとなくの感覚ではなく研究データに基づいて行えるよう、主要な知見を整理します。
この記事のポイント
- AIコード生成の正答率は言語によって大きく異なり、PythonやJavaScriptが高い傾向にある
- 差には言語の普及度（学習データの多さの目安）が関係するとされるが、普及度だけでは決まらない
- ベンチマークの数値を実務に当てはめる際には、測定条件の違いに注意が必要
AIコード生成の正答率とは何を指すのか？
「正答率」という言葉は直感的に理解しやすいですが、AIコード生成の評価においては、具体的な測定方法の定義が研究ごとに定められています。まずその土台を確認しておきます。
pass@kとHumanEvalの基本的な考え方
AIコード生成の評価で最もよく使われる指標が pass@k です。これは「k個のコードを生成したとき、少なくとも1つが正解になる確率」を指します。
たとえばpass@1なら「1回の生成で正解する確率」、pass@10なら「10回試したうち1回でも正解する確率」、pass@100なら「100回試したうち1回でも正解する確率」です。k値が大きくなるほど数値は上がりますが、実務では1回の生成で使えるかどうかが問われるため、pass@1が最も実態に近い指標とされています。
pass@10やpass@100は、モデル選定時の研究用途（複数候補を生成して最良を選ぶシナリオの評価）に主に用いられます。
この指標を広めたのが、OpenAIが2021年に発表したChen et al.（2021）のCodex論文です。同論文では、HumanEvalと呼ばれる164問のPythonプログラミング問題セットを使い、pass@1で約28.8%、pass@100で約72%という結果を報告しています。
HumanEvalは現在も多くの後続研究で基準として使われており、言語別比較の出発点となっています。
正答率の測定に使われる主なベンチマーク一覧
研究によって使用されるベンチマークは異なります。代表的なものを整理すると、以下のとおりです。
| ベンチマーク名 | 主な特徴 | 対応言語 | 発表年 |
|---|---|---|---|
| HumanEval | 164問のPython問題。pass@k指標を定義した基礎的ベンチマーク | Python中心 | 2021年 |
| MultiPL-E | HumanEvalとMBPPを18言語に拡張。言語別比較に特化 | 18言語 | 2023年 |
| MBPP | Python入門レベルの問題集。HumanEvalと組み合わせて使われることが多い（Austin et al., 2021 / arXiv:2108.07732） | Python中心 | 2021年 |
| GitHub Copilot評価（Nguyen & Nadi） | Java・JavaScript・Python・C言語の4言語でCopilotを独自実証評価（ACM MSR 2022） | 4言語 | 2022年 |
| SWE-bench | 実際のGitHubイシューへの対処能力を測るベンチマーク。HumanEvalよりも実務に近い難易度で評価（公式サイト: swebench.com） | Python中心（実課題） | 2024年 |
これらのベンチマークはそれぞれ設計思想が異なるため、「どのベンチマークで何%」という文脈を確認しないと、数値の比較が噛み合わないことがあります。後述する実務活用の注意点でも触れます。
言語別の正答率データ：研究が示す傾向
ここからが本題です。実際の研究データが示す、言語ごとの正答率の傾向を見ていきます。
Python・JavaScriptで高い正答率が出やすい理由
Cassano et al.（2023）はMultiPL-E（arXiv:2208.08227）を発表しました。
HumanEvalとMBPPのPython問題をJavaScript・Rustなど18言語に翻訳して拡張したフレームワークであり、この研究では、JavaScriptやTypeScriptの正答率（pass@1）が一貫して高く、Pythonを上回ることもあったと報告されています。また、正答率は言語の普及度と相関する一方、Luaのように利用の少ない言語でも高い成績が出る例があることも示されています。
また、Nguyen & Nadi（2022）によるGitHub Copilotの実証評価（ACM MSR 2022）では、LeetCodeの33問をJava・JavaScript・Python・C言語の4言語でCopilotに解かせた結果、正答率はJavaが約57%で最も高く、JavaScriptが約27%で最も低いと報告されています。
MultiPL-Eとは問題も測り方も異なるため、言語の順位は研究によって一致しません。
PythonとJavaScriptは、GitHub上のオープンソースコードやStack Overflowの質問・回答、技術ブログの豊富な蓄積によって、AIの学習データが他言語より大幅に多い状態にあります。
GitHub Octoverse 2023年次報告書によると、使用言語ランキングの1位はJavaScriptで、Pythonも上位5言語に入っており、蓄積されたコード量は低リソース言語を大きく上回ります。データが多ければ多様なパターンを学習でき、正答率が上がるという構図です。
RustやGoなど比較的新しい言語の現状
MultiPL-E（Cassano et al., 2023）は、GitHubでの利用割合とTIOBEの順位をもとに、対象言語を利用頻度の4段階（HIGH・MEDIUM・LOW・NICHE）に分けています。この分類では、GoはMEDIUM、RustはLOWです（Kotlinは対象外で、同論文にスコアはありません）。
ただし、正答率は利用頻度の順には並びません。同論文が2022年に行ったCodex（code-davinci-002）の評価では、Rustのpass@1は40%を超えた言語（C++・Java・TypeScriptなど）に入っていた一方、MEDIUMのGoはそこに入っていません。各言語の具体的な数値は原論文（arXiv:2208.08227）で確認できます。
なお、Rustは所有権・借用・ライフタイムといった規則をコンパイラが厳しく検査するため、正答率の数値だけでなく、生成されたコードがコンパイルを通るかという観点でのレビューが欠かせません。
COBOLやFortranなどレガシー言語での精度低下
COBOLやFortranは、金融・科学計算の基幹システムで現役ですが、AIコーディングの正答率という点では最も厳しい状況にあります。
理由は明確です。これらの言語のコードはオープンソースとしてほとんど公開されておらず、AIの学習データに含まれる量が極端に少ないためです。なお、Cassano et al.（2023）のMultiPL-EはCOBOLを対象言語に含んでおらず、COBOLに関しては同フレームワークの直接的なデータは存在しません。
ただし、言語の普及度と正答率の間に相関があるという同研究の知見を踏まえると、公開コードが極めて少ないCOBOLでは正答率が顕著に低くなると推定されます（MultiPL-Eの対象外であり直接データは存在しない点に注意）。
さらに、COBOLは英語の自然言語に近い独特の文法を持ち、現代の言語とは構造が大きく異なります。AIがコードのパターンを学習しにくい構造的な要因も重なっており、生成されたコードには特に慎重なレビューが求められます。レガシー言語でAIを補助的に使う場合は、コードの「たたき台を出してもらう」程度の期待値設定が現実的です。
なぜ言語によって正答率に差が出るのか？
データの傾向を確認したところで、「なぜ差が生まれるのか」という仕組みに踏み込みます。主な要因は2つです。
学習データ量（コーパス規模）の影響
AIの言語モデルは、大量のコードを学習することでパターンを習得します。
前述のとおり、GitHub Octoverse 2023年次報告書によるとPythonは使用言語ランキングの上位5言語に入っており（1位はJavaScript）、蓄積されたコードの量は多くの言語を大きく上回ります。
データが多い言語ほど、AIが多様な問題パターンを学習できるため正答率が上がりやすいと考えられます。Cassano et al.（2023）のMultiPL-Eは、言語の普及度（GitHubでの利用割合など）と正答率の相関を18言語で示しました。ただし同論文は、Luaのように利用の少ない言語でも高い正答率が出た例も挙げており、普及度だけで正答率が決まるわけではありません。
言語の特徴（静的型付けなど）の影響
学習データ量のほかに、言語の特徴が正答率に影響するかも調べられています。MultiPL-E（Cassano et al., 2023）では、静的な型検査のある言語かどうかは、正答率を上げも下げもしなかったと報告されています。
なお、AIがコードを「理解」する仕組みには、テキストとしての解析に加えて、AST（抽象構文木）やLSP（Language Server Protocol）を活用した構造的な把握も研究されています。
このリンク先の解説記事では、Codebase-Memoryプロジェクトの研究としてコードグラフを活用したアプローチが紹介されており、こうした技術の進化が今後の言語別格差を縮める可能性があります（ただし同数値の原論文URLは独立して確認できないため、参考情報として位置づけてください）。
また、同記事によると、LSPを使ったコード参照検索（find_references）はテキスト検索（grepベース）と比較して約900倍の速度差があるという計測結果（テキスト検索：約45秒、LSP：約50ミリ秒）も報告されており、AIエージェントの実装技術の革新が続いています。
AIコーディングツール別・言語ごとの正答率比較
同じプログラミング言語でも、使うAIツールによって正答率は変わります。ツール間の違いと、ベンチマーク数値の読み方を整理します。
GitHub Copilot・GPT系・Claude系の比較データ
各ツールの性能比較は、ベンチマークの種類・バージョン・測定時期によって結果が変わるため、「絶対的な順位」を断定することはできません。ただし、研究や公式評価から読み取れる傾向はあります。
Nguyen & Nadi（2022）が評価したGitHub Copilot（2022年当時）は、Python・Java・JavaScript・C言語の4言語のうち、Javaで約57%と最も高く、JavaScriptで約27%と最も低い正答率でした（ACM MSR 2022）。その後のモデル更新により現在の数値は変化している可能性があります。
最新の公式評価はGitHub公式ドキュメントで確認してください。
GPT系やClaude系については、各社がHumanEvalやSWE-bench（実際のGitHubイシューへの対処能力を測るベンチマーク）などで評価結果を公表しています。ただし各社が公表する数値は自社に有利な条件で測定されることも多く、独立した第三者評価との比較が望まれます。
この点は、EvoEval（Xia et al., 2024）など第三者ベンチマークを参照することで、ベンチマーク設計による過大評価の問題を補完できます。EvoEvalはHumanEvalを変形・難化させることでモデルの「暗記」と「汎化」を区別する研究として知られており、既存ベンチマークが正答率を過大評価している可能性を示した点で重要です。
具体的なスコアは各社の公式Model Cardやテクニカルレポートで随時更新されるため、最新情報は各社公式サイトをご参照ください。
| ツール | 評価ベンチマーク | 強みとされる言語 | 備考 |
|---|---|---|---|
| GitHub Copilot | 独自実証評価（Nguyen & Nadi, 2022） | Java（約57%、2022年時点） | GitHubのコードを大量に学習。最新スコアは公式サイトで確認 |
| GPT系（OpenAI） | HumanEval・SWE-bench等 | Python・JavaScript | OpenAI公式Model Cardで最新スコアを確認推奨 |
| Claude系（Anthropic） | SWE-bench等 | Python・JavaScript | Anthropic公式Model Cardで最新スコアを確認推奨 |
ベンチマーク結果を実務に当てはめる際の注意点
ベンチマークの数値は参考になりますが、実務と乖離する要因がいくつかあります。
ベンチマーク問題がAIの学習データに含まれている場合、「問題を解いた」のではなく「答えを記憶していた」だけという状況が起きうる、という過大評価の問題は研究者間でも議論されています。EvoEval（Xia et al., 2024）など第三者ベンチマーク研究でもこの点が指摘されており、ベンチマーク設計自体の課題として認識されています。
また、Pan et al.（2024）によるコード変換研究では、言語ペアによってバグ発生率が異なることも明らかになっており、「どの言語からどの言語へ」という変換の組み合わせも重要な研究テーマとなっています。
また、ベンチマーク問題は「関数を1つ実装する」という形式が多く、実際の業務コードとは規模・複雑さが大きく異なります。テストケースを通過するだけでなく、保守性・可読性・セキュリティまで含めた評価は、現行のベンチマークでは測定されていません。数値はあくまで「能力の一側面」として参照する姿勢が現実的です。
正答率データを学習・実務にどう活かすか
研究データを知ったうえで、学習計画やAI活用の戦略にどう落とし込むかを考えます。
AIが得意な言語から学習を始めるメリットと落とし穴
プログラミングを学び始める段階では、AIの正答率が高い言語を選ぶことに合理性があります。AIが的確なフィードバックを返してくれるため、エラーの原因を調べる時間が短縮され、学習の試行サイクルを速く回せます。
Pythonはその筆頭です。正答率が高く、文法がシンプルで、データサイエンス・Web開発・自動化と応用範囲も広い言語です。初学者がAIをペアプログラマーとして使いながら学ぶ環境として、現時点では最も整っています。
ただし、落とし穴もあります。AIが正解を出してくれるとき、「なぜそう書くのか」を理解しないまま進むと、AIが誤った提案をしたときに気づけなくなります。AIの出力を「答え」ではなく「仮説」として扱い、公式ドキュメントや教材で裏付けを取る習慣が、長期的な実力につながります。
公式ドキュメントを読む習慣の重要性（ecomottblog.com）は、AIが普及した現在でも変わりません。
正答率の低い言語でAIを使うときのレビュー戦略
業務でCOBOLやFortran、あるいはRustの複雑な機能を扱う場合、AIの正答率が低い前提でレビュー戦略を組む必要があります。
正答率の低い言語でAIを使うときの注意点
- コンパイル・型チェックを必ず通す：生成コードをそのまま使わず、まずコンパイラの検証を通す
- テストケースを先に書く：AIに実装を依頼する前に、期待する入出力を定義しておく
- 差分レビューを小さく保つ：1回のAI生成量を小さくし、レビューの負荷を分散させる
- 公式ドキュメントと照合する：AIが提案した関数・メソッドが実在するか、仕様どおりかを確認する
2026年9月に公開されたBend 2という言語は、AIが書いたコードを数学的証明（lawとproof）で検査するアプローチを採用しています。
Bend 2公式GitHubリポジトリ（bendlang/bend・Victor Taelin氏）のLimitationsセクションによると、「コンパイラ（カーネルを除く）の99%はAIが書いており、まだ完全な監査を受けていない」と記載されており、本番環境への即時採用は推奨されない段階です。
公式情報はBend 2の公式GitHubリポジトリ（bendlang/bend）を直接参照することを推奨します（参考：AIgent Labの解説記事（一次情報はBend 2公式GitHubリポジトリ））。ただし「AIの出力に機械が判定できる関門を置く」という設計思想は、正答率が低い言語でのAI活用を考えるうえで参考になります。
よくある質問
Q. HumanEvalはPython専用のベンチマークですか？
A. 元々のHumanEval（Chen et al., 2021）はPythonの164問で構成されており、Python中心のベンチマークです。ただし、Cassano et al.（2023）がMultiPL-Eとして18言語に拡張したバージョンが存在します。
対象となる18言語はBash（Shell）・C++・C#・D・Go・Java・JavaScript・Julia・Lua・Perl・PHP・R・Racket・Ruby・Rust・Scala・Swift・TypeScriptです（元のPythonを含めると19言語）。言語別の比較データを見る際は、HumanEvalとMultiPL-Eのどちらの結果かを確認することが必要です。
各言語の個別スコアはarXiv:2208.08227で参照できます。
Q. pass@1とpass@kのどちらを実務の参考にすべきですか？
A. 実務ではpass@1が最も参考になります。pass@kはk回試行した際の確率であり、k値が大きいほど数値は上がりますが、実際の開発では1回の提案で使えるかどうかが問われます。pass@10やpass@100は主にモデル選定時の研究用途（複数候補を生成して最良を選ぶシナリオ）で使われる指標です。
ツールを比較する際は、同じkの値で比較しているかを確認してください。異なるk値の数値を並べた比較は、ツールの実力差を正確に反映しません。
Q. RustはAIコーディングが苦手な言語ですか？
A. 研究データを見る限り、特に苦手な言語とはいえません。MultiPL-E（Cassano et al., 2023）が2022年に行ったCodexの評価では、Rustのpass@1は40%を超え、C++やJavaなどと同じ群に入っていました。個別スコアはarXiv:2208.08227で確認できます。
ただし、Rustは所有権・借用・ライフタイムといった規則をコンパイラが厳しく検査するため、AIの提案を使う際は、コンパイラのエラーメッセージを丁寧に確認するプロセスを組み込むことが現実的な対策です。
Q. COBOLの保守業務でAIは役に立ちますか？
A. 限定的には役立ちます。コードの意味を説明させる・コメントを生成させる・ロジックの概要を把握するといった用途では一定の効果があります。ただし、実際にCOBOLコードを生成・修正させる場合は、学習データが少ないため正答率が低い点を前提にする必要があります。
Cassano et al.（2023）のMultiPL-EはCOBOLを対象言語に含んでいないため直接的なスコアはありませんが、言語の普及度と正答率の相関という同研究の知見から、公開コードが極めて少ないCOBOLでは精度が低くなると推定されます（MultiPL-Eの対象外であり直接データは存在しない点に注意）。
生成されたコードは必ず専門家によるレビューを経てから使用することを推奨します。
Q. AIコーディングツールを選ぶとき、ベンチマーク以外に何を見ればよいですか？
A. 使用する言語のサポート状況・IDE連携の使いやすさ・コンテキスト窓の大きさ（長いコードをどこまで把握できるか）・料金体系が実用上の判断軸になります。ベンチマークは「能力の一断面」であり、実際の業務フローとの相性は別途検証が必要です。可能であれば、自分の業務で使う言語・規模のコードで試用期間を設けて評価することを勧めます。
また、プロンプトの設計次第でAIの回答精度は大きく変わるため、Chain-of-Thought・ReAct・Tree of Thoughtsなどのプロンプト設計手法を学ぶことも、ツール選定と同等に重要な投資です。
まとめ：言語選びとAI活用の判断軸
ここまで見てきた研究データは、3つの構造的な傾向に集約されます。
- 学習データが豊富な言語ほど正答率が高い：PythonやJavaScriptはMultiPL-E（Cassano et al., 2023）で高い数値を示す（ただしGitHub Copilot独自実証評価〔Nguyen & Nadi, 2022〕ではJavaScriptが最も低い）
- 低リソース言語・レガシー言語では精度が落ちる：MultiPL-Eでは利用の少ない言語ほど平均して正答率が下がる傾向が確認されており（Luaのように高い成績の例外もある）、COBOLなどはデータ不足により同様の低下が推定される（COBOLはMultiPL-Eの対象外）
- ベンチマーク数値は実務の参考値であり、過信は禁物：EvoEval（Xia et al., 2024）など第三者研究が示すようにベンチマーク設計による過大評価問題が存在し、実務との乖離に注意が必要
学習目的でAIを活用するなら、まずPythonで試行サイクルを速く回し、AIの提案を公式ドキュメントで検証する習慣をつけましょう。業務で正答率の低い言語を扱うなら、コンパイラ・テスト・レビューという複数の関門を設けてAIの出力を受け取るようにしましょう。この2つが、データに基づいた現実的な使い方です。
AIコーディングツールの能力は今後も更新されていきます。特定の数値を覚えるより、「なぜ差が生まれるのか」という構造を理解しておくことが、変化に対応する土台になります。
※本記事の情報は2026年9月時点のものです。最新情報は各公式サイトでご確認ください。
最終更新: 2026年9月29日
参考サイト
- Evaluating Large Language Models Trained on Code（Chen et al., 2021）— arXiv:2107.03374
- MultiPL-E: A Scalable and Polyglot Approach to Benchmarking Neural Code Generation（Cassano et al., 2023）— arXiv:2208.08227
- An Empirical Evaluation of GitHub Copilot’s Code Suggestions（Nguyen & Nadi, 2022）— ACM MSR 2022
- Program Synthesis with Large Language Models（Austin et al., 2021）— arXiv:2108.07732（MBPPベンチマーク）
- GitHub Octoverse 2023年次報告書 — github.blog
- SWE-bench公式サイト — swebench.com
- AIはどうやってコードを「理解」するのか — LSP・AST・コードグラフの仕組みと実践 | Atsumell Blog
- Bend 2とは｜AIのコードを証明で止める言語【2026年9月】 | AIgent Lab
- 【全ての新人エンジニアへ贈る】生成AI時代こそ「公式ドキュメント」を読むべき理由
- AIでコードドキュメントを作る方法｜README・関数説明を実装と一致させる
- AIプロンプト設計完全ガイド｜回答精度を最大化する3つの手法 | テックジム
