コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第206回　Google社内での大規模言語モデルによるコード修正事例

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes

第206回　Google社内での大規模言語モデルによるコード修正事例 (中井悦司) 2025年9月

はじめに

　今回は、2024年に公開された技術レポート「AI-powered patching: the future of automated vulnerability fixes」に基づいて、Google社内における、大規模言語モデル（LLM）を用いたソフトウェアの自動修正の事例を解説します。このレポートでは、C、C++、Java、Go言語のコードに内在する、メモリ安全性に関するバグを修正するコードをLLMで自動生成する事例が紹介されています。

修正コードを自動生成する流れ

　Google社内のソフトウェア開発では、C/C++、Java、Go言語などのプログラミング言語が使用されていますが、これらの言語ではメモリリークなど、メモリ安全性に関するバグが混入することがあります。Googleでは、メモリ安全性に関するバグを自動的に発見するテストツールを用いて、リポジトリ内のコードを定期的に検査しています。発見されたバグは、開発者が内容を確認して修正する必要がありますが、新しく開発されるコードの量が増えると、それに伴って発見されるバグの数も増えることになり、バグの修正が追いつかなくなることがあります。
　そこで、Google社内では、発見されたバグに対する修正コードをLLMで自動生成することで、バグ修正を効率化する試みが行われています。これは、次のステップを自動実行するパイプラインによって行われます。

・ステップ1. 自動化テストツールがメモリ安全性に関するバグを発見する
・ステップ2. 問題がある箇所を絞り込む
・ステップ3. LLMを用いて修正コードを生成する
・ステップ4. 修正をテストする
・ステップ5. 開発者に修正コードのレビューを依頼する

　ここからは、それぞれのステップを順番に説明します。

ステップ1～2：問題の発見と絞り込み

　メモリ安全性の問題を発見するツールは、さまざまなテストを自動実行することで問題点を発見します。テスト実行時のスタックトレースなどのログ情報は、LLMで修正コードを生成するのに役立つ情報ですので、まずは、問題が発生したテストコードと関連するログ情報を収集します。
　次のステップとして、テスト対象のコードの中で実際に修正が必要な箇所を絞り込みます。テスト時に実行されたすべてのコードをLLMに入力すると、LLMに入力可能なトークン数の上限を超えるなどの問題が発生するためです。当初はLLMを用いて修正が必要なファイルを特定することを試みましたが、これはうまく機能しませんでした。最終的には、類似の問題を含むコードを教師データとして、修正箇所を含むファイルを特定する専用の機械学習モデルを作成したということです。

ステップ3～4：修正コードの自動生成と修正のテスト

　LLMで修正コードを生成する際は、修正が必要な箇所を含むファイルとテストツールが出力したスタックトレースを入力データとします。さまざまな種類のバグに対応する必要があるので、特定のバグに特化したプロンプトチューニングは行わずに、図1のようなシンプルなプロンプトを使用しています。ここでは、スタックトレースがエラー発生箇所として示した部分をコード内にコメントとして示していますが、コードとスタックトレースを別々に入力するよりもよい結果が得られたということです。

fig01

図1 修正コードを生成するプロンプトの例（技術レポートより抜粋）

　また、生成された修正箇所を元のコードに適用した上で、再度、テストツールを実行して、実際にバグが修正されたことを確認する必要があります。ただし、LLMが出力するコードは、通常のコーディング規約に従っておらず、そのままでは実際のコードにマージできないケースがあります。そこで、Few-shotプロンプティングで実際の利用に即したコードを生成するようにしています。
　実際にバグが修正されたと確認されるケースの割合は、使用するLLMのモデルによって変わりますが、このレポートが作成された時点では、Geminiベースのモデルを用いた場合に最善の結果が得られており、発見されたバグの約15%の自動修正に成功しています。修正対象のバグは、大きくは次の4種類に分かれます。

・初期化していない変数へのアクセス
・メモリアクセスの競合
・バッファオーバーフロー
・スコープ外変数へのアクセス

ステップ5：コードレビューの依頼

　LLMが生成した修正を適用したコードは、コードオーナーの開発者にレビューを依頼して、レビュー完了後にリポジトリへのマージが行われます。この際、自動修正ツールの開発チームメンバーが事前にレビューを行い、明らかな修正ミスや品質の低いコードを除外します。実績的には、10～20%の修正がこの時点で除外されます。そして、事前レビューを通過して開発チームのレビューに回されたコードの約95%はそのままの形で受け入れられて、リポジトリにマージされるということです。

次回予告

　今回は、2024年に公開された技術レポート「AI-powered patching: the future of automated vulnerability fixes」に基づいて、Google社内における、大規模言語モデル（LLM）を用いたソフトウェアの自動修正の事例を解説しました。本文で説明したように、自動修正に成功する割合は15%に留まっていますが、これは、2024年の1月に発表されたレポートである点に注意が必要です。近年のLLMは著しい性能向上が続いていますので、現在は、より多くのバグが修正されていると思われます。
　次回は、データセンター内のストレージシステムのオブザーバビリティに関する話題をお届けします。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡

IT研修はCTC教育サービス

AWS　Microsoft Azure　生成AI

Python　Power Platform

コンテナ　その他（研修を分野から探す）

前回のコラム
「第205回　ホットリンクを回避するコンテナスケジューラーの活用（パート3）」