LLM がエンタープライズ品質のコードを生成できるか

LLM のコード生成は「80% 正解」で終わりか？エンタープライズ品質の罠と解決策

最近、AI エージェントがコーディングの主流になり、英語で指示を出すだけでコードが生成される時代になりました。しかし、ベンチマークテストでの高い正答率（80% 以上）は「機能的に動く」ことを示すだけで、セキュリティや保守性といった実務品質を保証するものではありません。

Sonar が実施した大規模分析では、最新モデルほどコード行数が膨れ上がり、複雑性とバグ密度が高まる傾向が明らかになりました。本記事では、この乖離の真相と、それを解決するための「ACDC フレームワーク」について解説します。

ベンチマークの罠：正答率 80% はセキュリティを担保しない

現在、多くの LLM（大規模言語モデル）は SWE-bench や MBPP などの評価基準で 80% を超える正答率を誇っています。Gemini 3.1 Pro High のパス率は 84.17% に達しています。

「テストケースにおける機能的な正しさについては確かにその通りですが、私たちが欠落しているのはセキュリティの側面です」

この数字は「指示されたタスクを完了できた」という意味であって、生成されたコードが安全で、長期的に維持可能であることを示していません。Sonar の分析では、これらのモデルが生成するコードには、深刻なセキュリティ脆弱性やアーキテクチャ上の問題が潜んでいることが判明しました。

最新モデルほど「冗長」になる：行数と複雑性の暴走

Sonar が 4,444 件以上の Java プログラミング課題に対して最新の LLM をテストした結果、驚くべき傾向が浮かび上がりました。それは「性能が上がれば上がるほど、コードが肥大化する」という逆説です。

• Gemini 3.1 Pro High: 約 307,000 行のコードを生成（循環的複雑性：234）
• Claude Sonnet 4.6: 約 627,000 行を生成
• GPT-5 シリーズ: なんと120 万行以上を生成

最新モデルは、課題を解決するために必要以上に冗長なコードを書き連ねます。その結果、循環的複雑性（分岐の多さ）と認知的複雑性（人間が理解する難易度）が著しく上昇しました。

「GPT-5.4 Pro High モデルでは、コード生成量が 120 万行に達することがわかります。これは膨大な量のコード生成量です」

バグ密度も無視できません。Gemini 3 Pro は百万行あたり 614 件のバグを、Claude Sonnet 4.6 は同数で 300 件以上のセキュリティ課題を生み出しています。最新モデルほど「細かなバグ」や「検出が困難な脆弱性」を増やす傾向にあるのです。

なぜ品質は低下するのか？4 つの要因

なぜ高性能なモデルほど、実務では使いにくいコードを生成してしまうのでしょうか。その原因は以下の 4 点に集約されます。

1. トレーニングデータの混合品質: オープンソースやネット上のデータには、良質なコードと脆弱なコードが混在しています。モデルはこの「ごちゃ混ぜ」のデータを学習し、結果としてセキュリティ欠陥を含むコードを生成してしまいます。
2. 組み込みされたセキュリティ欠陥: トレーニングセット自体に隠れたバグやロジックエラーが含まれており、モデルがそれを「正解」として学習してしまうケースがあります。
3. 確率的な出力特性: LLM は確率に基づいて動作するため、同じプロンプトでも常に異なるコードを生成します。これは再現性の欠如や、予期せぬバグの混入につながります。
4. コンテキスト不足と説明不可能性: モデルは企業の独自アーキテクチャや既存のコードベースを理解しておらず、なぜそのコードが生成されたのかという理由付け（説明可能性）もできません。そのため、開発者がコードを改善する際の診断が困難になります。

解決策：ACDC フレームワークによる自動修復サイクル

この課題に対処するため、Sonar は「ACDC（Assist, Check, Detect, Correct）」というフレームワークを提案しています。これは単なるチェックツールではなく、開発プロセス全体を再構築するアプローチです。

1. ガイドフェーズ：コンテキスト拡張と事前ガイド

生成前にモデルに適切な文脈を与えます。

• Sonar Context Augmentation: プロジェクト全体のコードベースを読み込ませ、LLM が自社のアーキテクチャやルールを理解した上でコードを生成させます。
• Sonar Sweep（ベータ版）: 学習データに含まれる問題のあるパターンを検知し、モデルが脆弱なコードを生成しないよう事前に対処します。

2. 検証フェーズ：リアルタイム分析と修正

コードをコミットする前に、数秒で品質チェックを行います。

• SonarQube エージェント分析: CI/CD パイプライン（通常 1〜5 分かかる）の前に、生成されたコードを 1〜5 秒でスキャンします。問題が見つかった瞬間にエージェントへフィードバックし、コミット前に自動修正させます。

3. 解決フェーズ：リメディエーションエージェントの自動修復

PR（プルリクエスト）レビューや品質チェックで失敗した場合でも諦めません。

• SonarQube Remediation Agent: PR に残った問題や、蓄積された技術的負債に対して、「すべての問題を修正してください」と指示するだけで、エージェントが個別の PR を作成して修正を提案します。
• 自己検証ループ: エージェントが修正コードを生成した後、再度分析とコンパイルを実行し、新たなバグ（回帰）が生じていないかを確認します。問題があれば破棄され、安全なコードのみが開発者に返却されます。

「リメディエーションエージェントの役割は、修正を適用した後に再度分析を実行し、コンパイルプロセスも再実行して、新たな問題が発生していないか確認できる点です」

まとめ：盲信から「検証と修復」へ

LLM の正答率 80% は、エンタープライズ開発におけるセキュリティや保守性の欠如を隠すものではありません。最新モデルほどコードが肥大化し、複雑になるという事実は、開発者が生成されたコードを盲信してはならないことを示唆しています。

Sonar が提唱する ACDC フレームワークのように、「事前の文脈付与」「リアルタイム検証」「自動修復」のサイクルを確立することで、AI 支援開発の信頼性は劇的に向上します。技術負債の解消速度が加速し、LLM を真に使いこなすための新たな基準が必要とされています。