大規模言語モデル（LLM）を用いてプログラムのソースコードを自動的に生成する技術。自然言語による指示やコメントからコードを出力し、開発生産性を飛躍的に向上させる。
LLMコード生成（LLM Code Generation）とは、大規模言語モデルを活用してソースコードを自動的に生成する技術である。開発者が自然言語で意図や仕様を記述すると、モデルが対応するプログラムコードを出力する。GitHub Copilot、Amazon CodeWhisperer、Cursor、Codeium など多数の商用製品が登場し、ソフトウェア開発の生産性を大きく変革している。
従来のコード生成はテンプレートベースや規則ベースのアプローチが主流であったが、LLMの登場により文脈を理解した柔軟なコード生成が可能になった。Transformer アーキテクチャの自己回帰的な特性を活かし、トークン単位でコードを逐次生成する仕組みが基盤となっている。
コード生成に特化した LLM は急速に進化しており、汎用モデルとコード特化モデルの両方が存在する。
| モデル名 | 開発元 | パラメータ数 | 特徴 |
|---|---|---|---|
| GPT-4o | OpenAI | 非公開 | 汎用性が高くマルチモーダル対応 |
| Claude 4 Opus | Anthropic | 非公開 | 長文コンテキストに強い |
| Codex | OpenAI | 12B | GitHub Copilot の基盤モデル |
| StarCoder2 | BigCode | 3B/7B/15B | オープンソースのコード特化モデル |
| DeepSeek-Coder-V2 | DeepSeek | 16B/236B | MoE アーキテクチャで高効率 |
| Code Llama | Meta | 7B/13B/34B/70B | Llama 2 ベースのコード特化版 |
| Qwen2.5-Coder | Alibaba | 1.5B/7B/32B | 多言語対応のコード生成モデル |
| Gemini 2.5 Pro | 非公開 | 100万トークンのコンテキスト長 |
各モデルは学習データの違いにより得意なプログラミング言語や生成品質が異なる。Python、JavaScript、TypeScript は多くのモデルで高精度な生成が可能だが、Rust や Haskell のような言語では精度にばらつきが見られる。
LLM によるコード生成にはいくつかの主要なアプローチが存在する。
最も一般的なアプローチで、自然言語の指示文をプログラムコードに変換する。プロンプトに要件を記述し、モデルが対応するコードを生成する。
入出力の例をプロンプトに含めることで、期待するコードスタイルやパターンをモデルに示す手法。特にドメイン固有のコーディング規約に準拠したコードを生成する際に有効である。
コードの前後の文脈を与えて中間部分を補完する手法。コード補完やインフィリングで中核となるテクニックで、StarCoder や Code Llama は FIM 学習を明示的に取り入れている。
リポジトリ内の既存コードや API ドキュメントを検索し、その情報をプロンプトに含めてコードを生成する手法。プロジェクト固有のコーディングパターンに合致したコードを生成できる。
コード生成モデルの性能を測定するための標準的なベンチマークが複数存在する。
| ベンチマーク | 評価対象 | 指標 | 特徴 |
|---|---|---|---|
| HumanEval | Python関数生成 | pass@k | 164問の手作り問題 |
| HumanEval+ | 拡張テスト | pass@k | HumanEvalの80倍のテストケース |
| MBPP | Python基本問題 | pass@k | 974問の初級〜中級問題 |
| SWE-bench | 実プロジェクトバグ修正 | 解決率 | GitHub Issue 実問題 |
| LiveCodeBench | 競プロ問題 | pass@k | 汚染回避の時系列ベンチ |
| MultiPL-E | 多言語生成 | pass@k | 18言語のHumanEval翻訳 |
| BigCodeBench | 関数呼び出し | pass@k | ライブラリ API 使用を含む |
pass@k は k 回の生成試行中に少なくとも1つの正解コードが含まれる確率を示す。pass@1 が最も厳密な指標であり、実用性に直結する。
LLM が存在しない API や関数を生成する問題。RAG による実コードの参照や、型チェッカーとの統合による検証が有効な対策である。
生成されたコードに SQL インジェクションや XSS などの脆弱性が含まれるリスクがある。静的解析ツール（SAST）との統合や、セキュリティ特化のファインチューニングが対策として研究されている。
学習データに含まれるオープンソースコードのライセンス問題。コピーレフトライセンスのコードが生成物に含まれる可能性があり、企業利用では注意が必要である。
大規模リポジトリ全体をコンテキストに収めることが困難なため、適切なファイル選択やチャンキング戦略が必要となる。
複数の実証研究により、LLM支援のコーディングツールは開発者の生産性を25〜55%向上させることが示されている。特にボイラープレートコードの生成、テストコードの作成、ドキュメント化のタスクで効果が大きい。ただし、複雑なアルゴリズム設計やアーキテクチャ決定では人間の判断が依然として重要である。
Python が最も高精度で、続いて JavaScript/TypeScript、Java、C++ の順に精度が高い傾向がある。これは学習データにおける各言語の割合に起因する。Rust、Go、Kotlin なども近年のモデルでは精度が向上しているが、マイナー言語やドメイン特化言語（DSL）では精度が低下する。
そのままの利用は推奨されない。生成されたコードは必ずレビュー、テスト、静的解析を経てから本番環境に適用すべきである。ハルシネーション、セキュリティ脆弱性、パフォーマンス問題のリスクがあるため、人間による検証プロセスが不可欠である。