AIが得意な言語、苦手な言語はどれ？ AWS・GitHub・Googleの分析から読み解く：AIコーディング時代の言語選択

AIに任せる業務を増やすことでスピードが向上する一方、品質保証への不安も増大しています。そんな中、開発者の間では「AIをいかに制御、管理するか」を考える上で、「どのプログミラング言語のコードを生成するか」も注目されています。本稿では、AIが迅速かつ正確にコードを生成しやすい言語はどれか、逆に難しい言語はどれかを考えてみたいと思います。

[平田修，＠IT]

　AIコーディングやバイブコーディングの普及に伴い、自然言語で指示した要件から素早くコードを生成できるようになりました。これを受け、開発者の役割はコーディングから品質向上にシフトしつつあります。 開発プロセスの一部をAIエージェントに任せることで、人間のチェックや承認を最小限に抑える「マルチエージェントの開発プロセス」を確立することが、開発者にとって急務となっているのです。

　そうした中、AIをいかに制御、管理するかを考える上で、「どのプログミラング言語のコードを生成させるか」も注目されるようになっています。

　AIは開発者自身があまり理解していない言語でも取りあえず動くプログラムを生成できてしまいます。AIの進化によって品質面の懸念は解消されつつあるとは言われていますが、学習データとなるソースコード量は、その言語がどれぐらい人間によって使われてきたかによって変わります。また、言語の仕様によって、人の意図をいかに正確にコンピュータに伝えられるかも変わります。このため、選択した言語によって生成スピードやレビューのしやすさ、品質も大きく変わってくるというわけです。

　本稿では、AIが迅速かつ正確にコードを生成しやすい言語はどれか、逆に難しい言語はどれかを考えてみたいと思います。

AIが書くコード「エラー率はJavaがPythonの6.7倍」

　Amazon Web Services（AWS）が2026年8月28日（米国時間）にAIコーディングエージェント「Kiro」の利用データを基に、AIモデルが生成したコードの品質が、バージョンを重ねてどう改善されたかをまとめた分析を公開しました。

　本分析の対象モデルは「Claude Opus 4.5〜4.8」「Claude Sonnet 4〜4.6」の7種類。プログラミング言語は「TypeScript」「Python」「Java」「Rust」「Go」「Kotlin」「C++」「Swift」など。

　Opus 4.6について言語別の静的解析のファイルエラー率を見た結果、低い順に並べると次の通りでした。

• JavaScript（1.6％）
• Python（4.0％）
• Go（8.0％）
• Kotlin（8.5％）
• TypeScript（8.6％）
• TSX（React）（11.2％）
• C++（12.2％）
• Rust（15.1％）
• Java（26.7％）

　結果として、Javaが26.7％でトップになりました。「冗長なimport、複雑なジェネリクス、検査例外、厳格な型解決の組み合わせが、今回分析したモデルにとって、Javaを最も難しい言語にしている」とAWSでは分析しています。

　最も低いJavaScriptの1.6％は、「モデルがより良いコードを書いているのではなく、素のJavaScriptで利用できる静的解析が最小限であることを反映している」ということです。TypeScriptの型システムを上に載せると、この率は8.6％に上がり、「動的型付けで静的解析や型チェックが限定的なPythonにも同じことが当てはまる」といいます。

　AWSは「実行時エラーやロジックのバグ、性能劣化などの動的解析やテストを要するものは静的解析には表れず、今回のデータで捉えているのは問題の一部に過ぎない」と断った上で、「低い静的エラー率は編集時に捕捉できるものを反映しているのであって、Javaよりもコードが正しいことを意味するわけではない。JavaのコードベースでAIコーディングエージェントを重点的に使うチームは、PythonやTypeScriptよりも解析結果の“後始末”に時間を費やすことを見込んでおく必要がある」としています。

Opus 4.6における言語別のファイルエラー率（提供：AWS）

• 参考記事：AIが書くコード「エラー率はJavaがPythonの6.7倍」　150万「会話」データで分かったAIコーディングの盲点

AIコーディング時代にTypeScriptが台頭した意味

　型システムや動的型付けがAI生成コードの品質に関わる点については、GitHubも2026年1月8日に分析を公表していました。

　2025年の学術研究によると、大規模言語モデル（LLM）が生成したコンパイルエラーの94％が、型チェックに関連していました。この結果は、型安全性の確保がAI生成コードに伴うデバッグ負荷を軽減できる可能性を示唆しているということです。

　そもそも型システムは、曖昧なロジックや入力・出力の不一致を表面化させる役割を担います。これにより、AIが生成したコード、スキャフォールディング（足場）やボイラープレート（定型文）がプロジェクトの標準に適合しているかどうかを保証するのです。

　GitHubは「AI支援開発やエージェントによる開発が普及するにつれ、型システムは信頼性の高いソフトウェアを構築、提供するための中核的な役割を担う可能性がある」とし、静的型付けについては「コードの信頼性と保守性の向上に寄与する。開発者に予測可能な共通構造を提供することで、予期せぬエラーを減らし、開発フローをスムーズに進めることが可能になる」としています。

　GitHubは言語選定について、「AIが生成するコード量が増加する中で、開発者がリスクを低減するためにTypeScriptのような型付き言語を選択する傾向が顕著になっている」として、次のようにまとめています。

　PythonやJavaScriptのような動的型付け言語は、柔軟かつ迅速な開発を可能にする。一方で、開発者が全てのコードを自身で記述しない場合、型定義のないコードでは微細なエラーが見逃されるリスクがある。AIツールの普及により「自分が書いていないコード」の分量が増えたことで、型システムによる安全策の必要性が高まっている。

• 参考記事：LLM生成コンパイルエラーの「型チェック」関連は何％？　「AIに書かせる」言語選択をGitHubが解説

GoogleがGoを「理想的な言語」とする3つの理由

　従来人気があるPythonだけでなく、AIコーディングの普及でTypeScriptも注目される中、Googleは2026年8月11日（米国時間）に「AI支援によるソフトウェア開発においては、Goが理想的な言語」との見解を示しました。

　その理由は大きく分けて「厳格な静的型システムと高速なコンパイル性能」「標準ツール『gofmt』によるコードの完全な標準化」「充実した標準ライブラリと組み込みのセキュリティツール」の3つにあるとしています。

　1つ目については、AIエージェントが生成したコードのエラーを即座に検知でき、自らコンパイルエラーを基に試行錯誤する「自己修正ループ（Self-correction loop）」を高速で回すことができるので、高速なコンパイル性能を持つ言語の方が、人間が出力されたコードを確認する前に、バグの多くが自動で淘汰（とうた）されるということです。

　2つ目については、Goは誰が書いても同一のフォーマットに強制変換されるので、AI特有の「表記揺れ」や「不必要な凝った構文」が排除されるということです。これにより、人間がコードを読んだ際にハルシネーション（幻覚）や論理バグをひと目で見抜きやすくなり、「検証コストが劇的に低減する」としています。

　3つ目については、AIには存在しない外部ライブラリを提案したり、古い依存関係を呼び出したりするリスクがあるが、Goは「govulncheck」などの検証ツールや標準ライブラリが最初からそろっているので、サプライチェーンリスクやハルシネーションを回避し、安全なコードをAIに生成させやすいという見解です。

　GoogleはGoを単なる構文規則にとどまらない「統合プラットフォーム」と位置付けており、チーム（人間とAI）による長期的な開発を持続可能にするとしています。生成AIにコーディングだけをさせる考え方から、SDLC（ソフトウェア開発ライフサイクル）の全工程をカバーするAIエージェントとの共創へと意識が変わりつつある今、言語仕様だけでなく、「その言語を取り巻くエコシステム」も含めて言語選定を考える必要がありそうです。

• 参考記事：AI時代は「Go言語」が理想の言語に？　Googleが解説する「Goの価値」

AIによるレガシー言語のリライト用にJavaが使われる理由

　AWSの調査で「静的解析のエラー率が高い」とされたJavaですが、メインフレームシステムでよく見られる「COBOL」コードからのリライト（書き換え）用言語としてよく使われています。

　一方でAIコーディング時代になって、Javaリライトの評価軸も変わりつつあるとアクセンチュアの中野恭秀氏は見ているそうです。

従来は「Javaエンジニアが読みやすいコード」が重視されてきたが、AIに読ませることを前提にすれば「Javaらしい」「Javaらしくない」の違いにはほとんど意味がなくなっていると捉えている。その意味では、例えばCOBOLからJavaへの100％変換を可能にしているリライトツールで変換したコードについても、「AIにとって理解しやすい」という観点で評価するようになってきている。

　「COBOLからJavaへの変換時に、自動変換だけに頼らず人間が介在して、できるだけピュアJavaに近づける努力をすれば、Javaエンジニアにとってはコードを理解しやすくなり、人間による保守性も高められる。一方で、移行後のメンテナンスにAIを活用することを前提にすると、人手による最適化が増えるほどコードの構造や変換結果にばらつきが生じやすくなり、AIが一貫して理解・解析する上では不利になる場合もある」と中野氏は指摘します。

　プログラミング言語「COBOL」の構造を残したまま「Java」に書き換えるコードは「JaBOL」と呼ばれ、移行のしやすさや保守性などの観点からメリット、デメリットがありますが、中野氏によると、「ピュアJavaではないかもしれないが、全てのソースコードがJavaに変換されることに意味がある」ということです。

　また、国産のメインフレームの場合、設計が独特だったり、インターネット上でも学習データを得にくかったりと特殊な事情があります。そうした環境で動くCOBOLシステムの場合、AIがコードを正確に理解できず、ハルシネーションを招く可能性もあります。それに対してJavaはインターネット上に学習できる情報が圧倒的に多いということです。

　「Javaにリライトすることで、例えばオンライントランザクション処理の実行基盤も、『Spring』など一般的なJavaフレームワークを使った構成に置き換えることができる。人間にとっては必ずしも『ピュアJava』とは言えないコードであっても、AIが理解、解析しやすい状態を実現できることに意義がある」と中野氏は指摘しています。

• 参考記事：COBOLっぽさを残す「JaBOL」の是非を問い直す――Javaらしさはもう問題じゃない

---

　このように、AIコーディングの普及やコード生成をつかさどるLLMの進化によって、言語選定の考え方も変化しています。今後もさらなる変化があると思いますが、本稿が、「AIが得意な言語、苦手な言語」を見極め、要件に合った品質の高いシステムを素早く構築できるヒントになれば幸いです。