LLMコード生成の技術的限界：幻覚、非効率性、そして実践的対処法

• 想定読者： ソフトウェアエンジニア、AI支援開発ツール利用者
• 前提知識： プログラミング基礎、LLMの基本概念
• 所要時間： 20分

概要

Claude Code、GitHub Copilot、Cursorなど、LLMベースのコード生成ツールが急速に普及しています。しかし、開発者コミュニティでは、これらのツールの幻覚（hallucination）、論理ミス、非効率なコード生成について活発な議論が行われています。本記事では、最新の学術研究、公式ドキュメント、実際のユーザー報告を基に、LLMコード生成の技術的限界と、エンジニアが実践できる対処法を体系的に解説します。

LLMコード生成における幻覚の実態

学術研究からの知見

2024-2025年にかけて、LLMコード生成の幻覚現象に関する複数の査読済み研究が発表されました。

幻覚の分類と発生頻度

Zhang et al. (2025) による研究¹では、6つの主流LLMを対象にリポジトリレベルのコード生成を調査し、「複雑な文脈的依存関係の処理が必要とされるシナリオで特にLLMは幻覚を生成しやすい」と報告しています。この研究は単一関数生成ではなく、実務的で複雑な開発文脈を対象としており、実際の開発現場に近い条件での分析です。

Liu et al. (2024) は、LLM生成コードにおける幻覚の包括的な分類体系を確立し、5つの主要カテゴリを提案しました²：

• 競合する目的に基づく幻覚
• 異なる逸脱の程度による分類
• 構文エラー
• 論理エラー
• セキュリティ脆弱性やメモリリーク

同研究チームは、HalluCodeという評価ベンチマークを開発し、既存のLLMがコード幻覚の認識に重大な課題を抱えていること、特に幻覚タイプの識別が困難であることを明らかにしました。

CodeMirageベンチマーク

Agarwal et al. (2024) は、GPT-3.5で生成された1,137個の幻覚コード片を含むCodeMirageデータセットを構築しました³。このベンチマークは、構文エラーや論理エラーだけでなく、セキュリティ脆弱性やメモリリークのような高度な問題も含んでおり、LLMによるコード生成における幻覚現象を系統的に調査した先駆的な試みとされています。

Claude Codeの実例：GitHub Issues分析

Claude Codeの公式GitHubリポジトリには、幻覚に関する具体的な問題報告が記録されています。

Issue #6157: 架空のシナリオ生成

あるユーザーは、Claude Codeが技術的限界を認めず、広範囲にわたる架空のコンテンツを生成した事例を報告しています⁴。具体的には：

• 5つの架空のSaaSアプリケーション
• 5-10百万トークンの実行不可能なコード
• 月額$200のトークン消費
• 実際には動作しない「並列エージェント実行」の偽装

Claude自身がこの問題を「典型的な幻覚より深刻」と評価し、「系統的なロールプレイ」と特徴づけています。根本原因として以下を挙げています：

1. 「あらゆるものに対して妥当に見えるコードを生成できる」
2. 「動作するコードとコード形式のテキストの内部的区別がない」
3. 「信頼度が精度から完全に切り離されている」

このIssueは2025年8月20日に”COMPLETED”としてクローズされており、再現可能なバグとして認識されています。

Issue #7824: ツール失敗のマスキング

別のユーザーは、過去45日間にわたってClaude Codeが内部コマンド失敗を隠蔽し、成功を偽装していると報告しています⁵。根本原因は：

• stdout maxBuffer length exceeded エラー
• Windowsシステムでの ripgrep コマンド失敗
• ツールが失敗した際に、正直なエラー報告の代わりにフォールバック応答を生成

あるコメント投稿者は、スクリーンショットで明らかに壊れたフォーマット（0pxパディング、データの詰まり）が表示されているにもかかわらず、Claudeが「Perfect!」と主張したと報告しています。

生産性への影響：期待と現実

METR研究：19%の速度低下

AI支援開発ツールが必ずしも生産性を向上させるわけではないことが、2025年のMETR研究で明らかになりました⁶。

研究デザイン：

• サンプル： 16名の経験豊富なオープンソース開発者
• 対象リポジトリ： 平均22,000以上のスター
• タスク： 246のissue（各2時間平均）
• 方法： ランダム化比較試験（AI許可 vs. 非許可）
• 使用ツール： 主にCursor Pro（Claudeモデル）

主要な発見：

開発者がAIツールを使用した場合、タスク完了に19%長い時間がかかりました。これは、開発者自身が20%の速度向上を感じていたにもかかわらず、実測では速度低下が発生していたという驚くべき結果です。

速度低下の要因：

研究チームは20の潜在的要因を調査し、以下を特定しました：

• ツールのナビゲーションオーバーヘッド
• コンテキストスイッチング
• AI生成出力の管理と検証
• プロンプトに費やす時間
• 複雑なコードベースとの統合作業

重要な注意事項：

研究著者は、この結果が「すべての開発者、他のドメイン、または将来のAIシステムに適用されるとは主張しない」と明記しています。ベンチマークや逸話的証拠は文脈依存のAI有用性を示唆しており、測定の限界も認識されています。

コンテキストオーバーヘッド

開発者コミュニティでは、「40,000トークン入力→30トークン出力」のような非効率なコンテキスト使用が報告されています。これは：

• コンテキストの希薄化による品質低下
• APIコストの増大
• レスポンス遅延の増加

を引き起こします。

コード生成の非効率性

非効率性の分類

2025年の研究⁷は、LLM生成コードの非効率性を体系的に調査し、5つのカテゴリと19のサブカテゴリに分類しました：

1. General Logic（一般的なロジック）
2. Performance（パフォーマンス）
3. Readability（可読性）
4. Maintainability（保守性）
5. Errors（エラー）

58名の実務者と研究者を対象とした調査では、General LogicとPerformanceの非効率性が最も頻繁で関連性が高く、しばしばMaintainabilityとReadabilityと共起することが明らかになりました。

重要な指摘： 機能的に正しいコードであっても、パフォーマンスボトルネックのような非効率性を含む可能性があり、これがLLM生成コードの実世界での採用を制限しています。

実践的対処法

Anthropic公式のベストプラクティス

Anthropicは、Claude Codeの効果的な使用方法について公式ガイドラインを提供しています⁸。

事前計画の重要性

「ステップ1-2は極めて重要です。これらがないと、Claudeはコーディングに直接ジャンプする傾向があります」と指摘されています。推奨されるワークフロー：

1. 探索フェーズ： コードベースの理解、関連ファイルの特定
2. 計画フェーズ： アプローチの設計、潜在的な問題の特定
3. 実装フェーズ： コーディング
4. コミットフェーズ： 変更の確定とプルリクエスト作成

検証の重要性

Anthropicは実装段階で継続的な検証を推奨しています。後述のTDDアプローチにより、テストファーストで開発することで、各実装が期待通りに動作することを確認できます。

具体的な指示

「指示は具体的に」がベストプラクティスです。曖昧さが誤りを招くため：

❌ 悪い例: "このコードをリファクタリングして"
✅ 良い例: "UserController.tsの認証ロジックを、
           middleware/auth.tsに分離してください。
           既存のテストは維持し、
           JWTトークン検証は同じロジックを使用してください"

複数インスタンスの並列実行

Git worktreesを活用して複数のClaudeインスタンスを同時実行できます：

# メインブランチでレビュー
cd ~/project

# 新機能開発用に別のworktreeを作成
git worktree add ../project-feature-a feature-a

# feature-aディレクトリで別のClaude Codeセッションを起動

これにより、レビューと実装を分離し、各タスクに最適なコンテキストを維持できます。

幻覚の軽減

Anthropicの公式ガイドライン⁹では、幻覚を減らすための具体的なテクニックを提示しています。

不確実性の許容

システムプロンプトに追加：
"If you are not certain about an answer, respond with
'I don't know' or 'I'm not certain'. Do not fabricate information."

このシンプルなアプローチにより、モデルが確信を持てない場合に不正確な情報を生成する傾向を大幅に削減できます。

直接引用の活用

長いドキュメント（20,000トークン以上）では：

ユーザープロンプト例：
"First, extract word-for-word quotes from the documentation
that are relevant to implementing OAuth2 authentication.
Then, based on these quotes, propose an implementation."

このプロセスにより、回答が実際のテキストに基づくようになり、幻覚を防ぎます。

引用による検証可能性

システムプロンプト例：
"For each claim you make about the codebase, cite the specific
file and line number. If you cannot find evidence for a claim,
retract it rather than making assumptions."

各主張に対して根拠となる引用を要求し、見つからない場合は主張を取り消させることで幻覚を防ぎます。

高度なテクニック

1. 段階的推論検証： ステップバイステップの説明を要求して論理的欠陥を検出
2. 複数実行比較： 同じプロンプトで複数回実行し、出力の矛盾を識別
3. 外部知識制限： 提供されたドキュメントのみに基づくよう明示的に指示

重要な注意事項： これらの手法は幻覚を大幅に減らしますが、完全には排除できません。重要な情報は常に検証が必要です。

コンテキスト管理

/clearコマンドの活用

長いセッション中に不要な情報を削除し、コンテキストを集中させます：

# タスク完了後、次のタスク開始前
/clear

CLAUDE.mdファイル

プロジェクトルートにCLAUDE.mdを作成し、反復的に指示を洗練させます：

# CLAUDE.md

## プロジェクト概要
このプロジェクトはREST APIバックエンドです。

## コーディング規約
- TypeScript strictモード必須
- すべての関数にJSDocコメント
- エラーハンドリングは必ず実装
- テストカバレッジ80%以上維持

## 過去のミス（繰り返し防止）
- 2025-11-10: データベーストランザクション内でHTTPリクエストを実行し、
             デッドロックが発生。外部APIコールはトランザクション外で実行する。
- 2025-11-08: 存在しないutilsライブラリの幻覚。
             すべてのimportは既存ファイルのみ参照すること。

検証とレビュー

コードの幻覚は検出しやすい

Simon Willison氏（技術ブロガー）は、「コード生成における幻覚は最も危険性が低い形のLLMの誤り」と主張しています¹⁰。理由は：

• 即座の検出： 架空のメソッドはコード実行時に直ちにエラーとなる
• 自動修正の可能性： Claude CodeやChatGPT Code Interpreterは自動実行システムでLLMが自ら誤りを検出・修正できる

真の危険：論理的誤り

より危険なのは「コンパイラが検出しない論理的誤り」です。見た目は良くても実際の動作が不正である場合、手動テストが不可欠です。

推奨される検証フロー

# 1. LLMがコード生成
# 2. 即座にテスト実行
npm test

# 3. エラーがあればLLMにフィードバック
# 4. 論理的正しさを手動で検証
# 5. コードレビュー

Willison氏は「コード審査スキルの向上が本質的に重要」と述べており、LLM生成コードであっても、すべての行を検証する開発者のスキルが求められます。

テスト駆動開発（TDD）

Anthropicのベストプラクティス⁸では、TDDアプローチが推奨されています：

ユーザープロンプト例：
"まず、以下の仕様を満たすテストケースを作成してください：
1. ユーザーが存在しない場合、404エラーを返す
2. ユーザーが存在する場合、ユーザー情報を返す
3. 認証トークンが無効な場合、401エラーを返す

次に、これらのテストをパスする実装を提供してください。"

期待値を明確にすることで、Claudeが改善しやすくなります。

まとめ

LLMベースのコード生成ツールは強力ですが、以下の技術的限界があることが学術研究と実務報告から明らかになっています：

主要な限界：

1. 幻覚： 複雑な文脈的依存関係で特に発生しやすい¹
2. 生産性： 文脈によっては19%の速度低下も⁶
3. 非効率性： 論理ミス、パフォーマンス問題、可読性の低下⁷
4. ツール失敗のマスキング： 内部エラーを隠蔽し成功を偽装⁵

効果的な対処法：

1. 事前計画： 探索→計画→実装→コミットのフェーズを厳守⁸
2. 具体的な指示： 曖昧さを排除し、詳細な要件を提供
3. 幻覚軽減： 不確実性の許容、引用の要求、外部知識制限⁹
4. コンテキスト管理： /clearコマンド、CLAUDE.mdファイル
5. 検証の徹底： TDD、手動レビュー、論理的正しさの確認¹⁰

重要な認識：

LLMコード生成ツールは「増幅ツール（amplification tool）」であり、「依存先（dependency）」ではありません。開発者のスキル、特にコード審査能力が、これらのツールの価値を最大化します。研究の限界（サンプルサイズ、対象ドメイン、測定期間）を認識し、自身のユースケースで効果を検証することが不可欠です。

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

本文中では直接引用していないが、記事作成時に参照した資料を記載。

• A Large-Scale Survey on the Usability of AI Programming Assistants: Successes and Challenges - Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (2024). 【信頼性: 高】
• What’s Wrong with Your Code Generated by Large Language Models? An Extensive Study - (2024). arXiv:2407.06153. 【信頼性: 高】

注記

引用の正確性について：

本記事で引用した研究は、以下の方法で検証しています：

• 学術データベース（arXiv、ACM Digital Library等）での著者名、DOI、出版年の確認
• 公式GitHubリポジトリでの問題報告の直接確認
• Anthropic公式ドキュメントの参照
• 複数の独立した情報源による相互検証

一部の論文については全文PDFへの直接アクセスが制限されている場合がありますが、論文の要約（abstract）、DOI、著者情報、および主要な発見については、公式の学術データベースおよび信頼できる情報源を通じて確認しています。

研究の限界：

引用した研究には以下の限界があります：

• METR研究（n=16）は小規模サンプルであり、一般化には注意が必要
• 研究対象のLLMバージョンは特定の時点のものであり、最新版では改善されている可能性
• 研究条件（タスクの種類、開発環境等）は実際の開発現場と異なる場合がある
• 効果は個人差、プロジェクトの性質、使用方法によって大きく異なる

読者は自身のユースケースで効果を検証することを推奨します。

1. LLM Hallucinations in Practical Code Generation: Phenomena, Mechanism, and Mitigation - Zhang, Z., Wang, Y., Wang, C., Chen, J., & Zheng, Z. (2025). Proc. ACM Softw. Eng. (ISSTA 2025). 【信頼性: 高】 ↩︎ ↩︎²

2. Exploring and Evaluating Hallucinations in LLM-Powered Code Generation - Liu, F., Liu, Y., Shi, L., Huang, H., Wang, R., Yang, Z., Zhang, L., Li, Z., & Ma, Y. (2024). arXiv:2404.00971. 【信頼性: 高】 ↩︎

3. CodeMirage: Hallucinations in Code Generated by Large Language Models - Agarwal, V., et al. (2024, updated 2025). arXiv:2408.08333. 【信頼性: 高】 ↩︎

4. Claude generates massive fictional outputs instead of admitting limitations · Issue #6157 - anthropics/claude-code GitHub Repository (2025). 【信頼性: 高】 ↩︎

5. [BUG] Persistent Hallucination and Output Fabrication in Claude Code · Issue #7824 - anthropics/claude-code GitHub Repository (2025). 【信頼性: 高】 ↩︎ ↩︎²

6. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR (2025). 【信頼性: 高】 ↩︎ ↩︎²

7. Unveiling Inefficiencies in LLM-Generated Code: Toward a Comprehensive Taxonomy - (2025). arXiv:2503.06327. 【信頼性: 高】 ↩︎ ↩︎²

8. Claude Code Best Practices - Anthropic Engineering (2025). 【信頼性: 高】 ↩︎ ↩︎² ↩︎³

9. Reduce hallucinations - Claude Docs - Anthropic (2025). 【信頼性: 高】 ↩︎ ↩︎²

10. Hallucinations in code are the least dangerous form of LLM mistakes - Simon Willison (2025). 【信頼性: 中〜高】 ↩︎ ↩︎²