Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis

本論文は、テストと静的解析からのフィードバックを活用することで、オープンソースの LLM が生成したコードの品質評価や自己改善（特に修正能力）が可能であることを示し、LLM によるコード生成の安全性向上への有望な道筋を提示しています。

要約

🍳 物語：AI 料理人と「味見・チェック」のチーム

この研究では、4 人の有名な「AI 料理人（LLM：Llama, Gemma, Mixtral など）」を雇いました。彼らの仕事は、注文された「料理（プログラミングの課題）」を、C という言語でレシピ（コード）として作ることです。

しかし、AI 料理人には 2 つの大きな弱点がありました。

1. 味がおかしい（バグがある）： 注文した料理と全然違う味が出たり、食べられなかったりする。
2. 危険な食材を使っている（セキュリティの穴）： 毒が入っていたり、火傷するリスクがある。

そこで研究者たちは、AI 料理人をただ放置するのではなく、**「味見係（テスト）」と「安全検査員（静的解析）」という 2 人のプロを付け、AI を「自分で反省して直す」**というトレーニングを行いました。

---

🔄 3 つのトレーニング段階

この研究は、以下の 3 つのステップで進みました。

1. 料理を作る（コード生成）

まず、AI 料理人に「この食材で料理を作って」と注文します。

• 結果： 100 個の料理を作ってもらいましたが、半分以下（約 46%〜65%）しか「正解の味」になっていませんでした。 残りは、火が通ってなかったり、具材が足りなかったりしました。
• 安全チェック： さらに、毒や危険な食材がないか専門の検査員（Infer というツール）にチェックさせました。
• 結果： 幸いにも、**9 割以上は「毒なし」**でしたが、それでもいくつかの料理に「危険な食材（メモリ漏れや空ポインタなど）」が混入していました。

2. 自分で味見をする（自己評価）

次に、「さっき作った料理が、本当に注文通りで安全か？」を、AI 料理人自身に聞いてみました。

• 結果： AI は自分の料理の味をほとんど判断できませんでした。
  • 味がおかしい料理を「美味しい（正解）」と褒めちぎったり、
  • 安全な料理を「まずい（危険）」と誤解したり。
  • 自分自身が作った料理を特別に褒める傾向（自己愛）も見られませんでした。
  • 結論： 「AI は自分のミスを自分で見つけるのが、実はものすごく苦手」なのです。

3. 直してもらう（修復）

ここが最も重要な部分です。
「この料理、味が違うよ（テスト失敗）」や「ここに毒があるよ（検査結果）」という具体的なアドバイスを AI 料理人に渡しました。そして、「直して！」と頼みます。

• 結果： 驚くほど上手に直せました！
  • 味がおかしかった料理の約 6 割が、アドバイスを与えたら正解になりました。
  • 毒が入っていた料理の約 9 割が、アドバイスを与えたら安全になりました。
  • 特に、大きなモデル（Llama 70B など）は、他の AI が作った失敗作も上手に直しました。

---

💡 この研究からわかったこと（結論）

1. AI 単独では不完全： AI に任せて「とりあえずコードを作らせる」だけだと、バグや危険なコードが混ざりやすいです。
2. 自己診断は苦手： AI に「自分のコードにミスがあるか？」と聞いても、ほとんど当てられません。
3. フィードバックが魔法： しかし、「どこが間違っているか（テスト結果）」や「何が危険か（検査結果）」という具体的な情報を教えてあげれば、AI は「あ、そうだったのか！」と理解して、コードを劇的に改善できます。

🚀 今後の展望

この研究は、**「AI が作ったコードを、人間がチェックするのではなく、自動でテストと検査を行い、その結果を AI に返して直させる」**という仕組み（パイプライン）の提案です。

まるで、**「AI 料理人が失敗したら、すぐに味見係が『塩が足りないよ』と教えて、AI が自分で味を調整する」**ようなシステムです。

これによって、将来的には AI が作るソフトウェアが、より安全で信頼できるものになることが期待されています。特に、メモリ管理が難しい C 言語のような分野でも、このアプローチが有効であることが示されました。

---

一言で言うと：
「AI にコードを書かせるのは便利だけど、そのまま使うと危険。でも、『どこがダメだったか』を具体的に教えてあげれば、AI は自分で上手に直せる！ だから、AI と検査ツールのチームワークが重要だよ」というお話です。

技術概要

論文「Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis」の技術的サマリー

この論文は、大規模言語モデル（LLM）が生成するコードの品質、特に正しさ（Correctness）と安全性（Safety）を評価し、テストと静的解析からのフィードバックを活用してモデルの自己改善を促すためのフレームワークを提案・検証した研究です。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳細にまとめます。

---

1. 問題定義 (Problem)

近年、LLM はソフトウェア開発ライフサイクルにおいてコード生成に広く利用されていますが、生成されたコードには以下の重大な課題が存在します。

• 安全性と信頼性の欠如: 生成されたコードには脆弱性（バグ、メモリリーク、バッファオーバーフローなど）や論理的な誤りが含まれる可能性が高い。
• 自己評価能力の限界: LLM が自身の生成したコードの誤りや脆弱性を検知し、修正する能力が不十分である。
• 自己好意バイアス: モデルが自身の生成したコードを他モデルのコードよりも高く評価する傾向（Self-preference）があるかどうかの不明確さ。

既存の研究の多くは生成コードの評価に焦点を当てていますが、テストと静的解析の結果をフィードバックとして与え、LLM を反復的に改善させるプロセスを体系的に検証した研究は限られています。

2. 手法 (Methodology)

著者らは、コード生成、自己評価、修復の 3 つのフェーズからなる自動化されたフレームワークを構築しました。

実験設定

• 対象モデル: オープンソースで高性能な 4 つの LLM（Llama 3 8B/70B, Gemma 7B, Mixtral 8x7B）。
• タスク: Mostly Basic Python Problems (MBPP) データセットから 100 件のタスクを抽出し、C 言語向けに手動で再構成（JSON 構造の維持、C 固有のテストケースへの変換）。
• ツール:
  • コンパイル/実行: Clang 15.0.0。
  • 静的解析: Meta 社が開発した静的解析ツール「Infer」。メモリ管理、リソースリーク、アクセス制御などの脆弱性を検出。
  • プロンプトエンジニアリング: 各フェーズで最適なプロンプト（Chain-of-Thought、例示、指示など）を探索。

3 つのフェーズ

1. コード生成フェーズ:

   • LLM に自然言語の仕様に基づき C コードを生成させる。
   • 生成されたコードを自動スクリプトでクリーニング（バックスラッシュ除去、標準ライブラリの追加など）し、コンパイル可能な状態にする。
   • 正しさの評価: 単体テスト（Ground-truth）を実行し、通過/失敗/実行エラー/コンパイルエラーを判定。
   • 安全性の評価: Infer を用いて脆弱性を検出。

2. **自己評価フェーズ **(Self-Evaluation):

   • 各 LLM に、自身が生成したコードおよび他モデルが生成したコードの「正しさ」と「安全性」を判定させる（YES/NO の分類タスク）。
   • モデルが自身のコードを過信する傾向（Self-preference）があるか、あるいは他モデルのコードを正しく評価できるかを検証。

3. **修復フェーズ **(Repair):

   • 正しくない、または脆弱性を含むコードに対して、失敗したテスト結果や Infer の解析レポート（脆弱性の種類と位置）をフィードバックとして提示。
   • LLM にコードの修正を依頼し、最大 6 回まで反復的に修正を試行させる。
   • 修正後のコードに対して再度テストと静的解析を行い、改善度を測定。

3. 主要な貢献 (Key Contributions)

1. LLM 生成コードの品質評価: 生成された C コードのうち、正しさを示すのは 46%〜65% 程度であり、脆弱性は 87%〜96% のコードで検出されなかった（Infer の判定基準による）が、手動検証では偽陽性も存在することが示された。
2. 自己評価能力の限界の解明: LLM は生成コードの正しさや脆弱性を検知する能力が極めて低い（F1 スコアが 0.3 未満）。特に、脆弱性の検出においては、真陽性率が低く、モデルは「安全」と誤判定する傾向が強い。
3. フィードバックによる修復能力の実証: 誤りや脆弱性に関する具体的な情報（テスト失敗や静的解析レポート）を与えると、LLM はコードを修正する能力を大幅に向上させる。
   • 正しさの修復：最良のモデル（Llama 3 70B）で誤ったファイルの 62%（96/155）を完全に修正。
   • 安全性の修復：最良のモデルで脆弱性の 89%（39/44）を修正。
4. 自己好意バイアスの不存在: モデルが自身の生成コードを他モデルのコードよりも優先的に修正する傾向（Self-preference）は確認されなかった。むしろ、他モデル（特に Gemma）が生成したコードを修正する方が成功率が高いケースもあった。
5. 自動化パイプラインの提案: 人間の介入を最小限に抑え、静的解析ツールと LLM を組み合わせたモジュラーな修復パイプラインを構築。

4. 実験結果 (Results)

コード生成と評価

• 正しさ: 全モデルで 100 件中約 50〜60 件がテストを通過。Llama 3 70B が最も高く 65%、Gemma 7B が最も低く 46%。
• 安全性: Infer による解析では、生成コードの大部分（約 90% 以上）は脆弱性なしと判定されたが、手動検証で偽陽性が確認された。実際の脆弱性（NULL ポインタ参照、メモリリークなど）は限定的に存在した。

自己評価（Self-Evaluation）

• 正しさ判定: モデルは「YES（正しい）」または「NO（誤り）」を答えるが、精度は低く、F1 スコアは 80% 未満。Gemma はほぼ常に「YES」と回答し、Llama 3 8B はほぼ常に「NO」と回答するバイアスが確認された。
• 脆弱性検出: モデルは脆弱性をほとんど検出できない。真陽性率が極めて低く、F1 スコアは 0.3 未満。モデルは自身の生成コードであっても脆弱性を認識できていない。

修復（Repair）

• 正しさの修復: フィードバック（失敗したテストケース）を与えた場合、Llama 3 70B が最も優秀で、155 件中 92 件（59%）を修正。Gemma は 13% にとどまった。
• 安全性の修復: Infer のレポートをフィードバックした場合、Llama 3 70B と Mixtral が 89%（39/44）の脆弱性を修正した。
• 自己好意バイアス: 「自身が生成したコードを他モデルよりよく修正する」という傾向は見られなかった。むしろ、Gemma が生成したコードを他モデルが修正する成功率が高かった。

プロンプトの影響

• 修復フェーズにおいて、Chain-of-Thought（CoT）を組み合わせたプロンプトは、場合によっては誤った結果を招くことがあり、単純な指示ベース（Instruction-based）のプロンプトの方が安定して良い結果をもたらした。

5. 意義と結論 (Significance & Conclusion)

この研究は、LLM を単なるコード生成ツールとしてではなく、静的解析やテストからのフィードバックを受け取ることで自己改善するシステムとして統合する可能性を示しました。

• 実用性: 現在の LLM はゼロショット（フィードバックなし）では安全で正確なコードを生成できないが、静的解析ツールなどの外部検証ツールと連携し、その結果をフィードバックとして与えることで、コードの品質を劇的に向上させることができる。
• 将来の展望: 本研究で提案されたモジュラーなパイプラインは、他の言語（Rust や Python など）や、他の静的解析ツール（CodeQL など）との組み合わせへ拡張可能である。また、動的解析と静的解析を組み合わせたハイブリッドアプローチが今後の課題として挙げられている。

結論として、LLM によるコード生成を安全かつ信頼性の高いものにするためには、モデル単体の能力に依存するのではなく、検証ツールからのフィードバックループを構築することが不可欠であると示唆されています。