LLMコード補完（エルエルエムコードホカン）
LLMがプログラミング中のコードの続きを予測・提案する技術。カーソル位置の文脈を解析し、次に書くべきコードをリアルタイムで提示する。
LLMコード補完とは
LLMコード補完（LLM Code Completion）は、開発者がコードを入力している最中にLLMがその続きを予測して提案する技術である。従来のIDEのオートコンプリートが変数名やメソッド名の補完に限られていたのに対し、LLMベースの補完は複数行にわたるロジック全体を生成できる点が革新的である。
GitHub Copilot がこの分野を切り拓き、現在では Codeium、Tabnine、Amazon CodeWhisperer、Supermaven など多数のツールが競合している。これらは IDE（VS Code、JetBrains、Neovim 等）のプラグインとして動作し、開発フローを妨げることなくコード提案を行う。
技術的な仕組み
トークン化とコンテキスト収集
コード補完の第一段階として、現在編集中のファイルおよび関連ファイルの内容をトークン化してモデルに入力する。トークナイザーはコード特化のものが使用され、一般的な英語テキスト向けのトークナイザーより効率的にコードを表現できる。
| コンポーネント | 説明 | 影響 |
|---|---|---|
| カーソル位置 | 補完を開始する位置情報 | 生成の起点を決定 |
| 現在のファイル | 編集中のソースコード全体 | 直近の文脈を提供 |
| 隣接ファイル | インポート先・同ディレクトリのファイル | プロジェクト慣習を反映 |
| LSP 情報 | 型情報・定義元・参照情報 | 型安全な補完を支援 |
| 最近の編集履歴 | 直前の変更内容 | 意図の推測に活用 |
推論の最適化
コード補完はキーストロークごとにトリガーされるため、極めて低レイテンシ（50〜200ms）が求められる。以下の技術が活用されている。
- Speculative Decoding: 小型のドラフトモデルで高速に候補を生成し、大型モデルで検証する
- KV キャッシュの再利用: 前回のリクエストで計算した Key-Value を再利用し、差分のみを処理する
- モデルの量子化: INT4/INT8 量子化により推論速度を向上させる
- バッチ処理: 複数ユーザーのリクエストをバッチ化して GPU 効率を最大化する
Fill-in-the-Middle（FIM）モード
多くのコード補完モデルは FIM 学習を採用しており、カーソル位置の前後のコードを入力として中間部分を生成する。これにより、関数の途中に挿入するコードや、既存のコードブロック内への追記が自然に行える。
<fim_prefix>def calculate_total(items):
total = 0
for item in items:
<fim_suffix>
return total
<fim_middle> total += item.price * item.quantity
補完の種類と精度
行内補完（Inline Completion）
1行以内の短い補完。変数代入、条件式、関数呼び出しなどが対象で、最も高い採用率を示す。
複数行補完（Multi-line Completion）
関数本体、ループ、条件分岐ブロックなど複数行にわたる補完。コンテキストが十分であれば高い精度を発揮するが、意図と異なるロジックが生成されるリスクも高まる。
関数レベル補完
関数シグネチャやドキュメントコメントから関数全体を生成する補完。テスト関数やユーティリティ関数では特に効果的である。
| 補完タイプ | 平均採用率 | レイテンシ目標 | 主な使用場面 |
|---|---|---|---|
| 行内補完 | 30-40% | 50-100ms | 変数代入、メソッドチェーン |
| 複数行補完 | 15-25% | 100-200ms | ループ、条件分岐 |
| 関数レベル補完 | 10-20% | 200-500ms | テスト関数、ユーティリティ |
主要ツールの比較
| ツール | モデル | 価格（月額） | 特徴 |
|---|---|---|---|
| GitHub Copilot | GPT-4o / Claude 4 | $10-39 | 最大のユーザーベース、Copilot Chat 統合 |
| Cursor | 複数モデル切替 | $20-40 | IDE 一体型、チャットとの統合 |
| Codeium (Windsurf) | 独自モデル | 無料-$15 | 低レイテンシ、無料プランあり |
| Supermaven | 独自 300Kトークンモデル | $10 | 超長コンテキスト、高速 |
| Amazon CodeWhisperer | 独自モデル | 無料-$19 | AWS サービスとの統合に強い |
| Tabnine | 独自モデル + RAG | $12-39 | オンプレミスデプロイ対応 |
パフォーマンスチューニング
コード補完の品質はプロンプトのコンテキスト設計に大きく依存する。以下の戦略が効果的である。
- ファイルの冒頭にインポート文を集約し、使用ライブラリを明示する
- 型アノテーションを丁寧に記述し、モデルが型情報を参照できるようにする
- 関数のドキュメントコメントを先に書き、意図を明確にする
- プロジェクトのコーディング規約に沿ったコードを周辺に配置する
よくある質問（FAQ）
Q1: コード補完ツールのレイテンシはどの程度が許容範囲か？
研究によると、200ms 以内の応答であれば開発者の作業フローを中断しないとされている。300ms を超えると補完提案を待つよりも手動入力した方が速いと感じるユーザーが増える。GitHub Copilot は平均 100-150ms、Supermaven は 50ms 以下のレイテンシを目標としている。
Q2: コード補完の採用率（Acceptance Rate）を高めるにはどうすればよいか？
プロジェクト固有のコンテキスト（型定義、ユーティリティ関数、テストパターン）をモデルに提供することが最も効果的である。LSP 統合による型情報の活用、RAG によるリポジトリ検索、最近の編集履歴の参照なども採用率向上に寄与する。一般に採用率 25-35% が健全な目安とされる。
Q3: オフラインでコード補完は使えるか？
ローカルで動作するモデル（StarCoder2 3B、Code Llama 7B など）を利用すれば可能である。Ollama や LM Studio でモデルを起動し、Continue.dev などのオープンソースプラグインを組み合わせることでオフライン補完環境を構築できる。ただし、クラウドモデルに比べて精度は低下する傾向がある。