あなたは、完璧な料理を作るために、非常に才能はあるが少し混沌とした副料理長に教えようとしているマスターシェフだと想像してください。あなたは副料理長にレシピ（コード）を与え、その料理が正しく機能することを証明するための「味見」（ユニットテスト）を書くよう求めます。ソフトウェアの世界では、これらの「味見」は、特定のコードが意図した通りに動作するかどうかをチェックする小さなプログラムです。長年、人間は手作業でこれらのテストを書いてきましたが、それは退屈な作業でした。最近では、人工知能、特に大規模言語モデル（LLM）を使用して、私たちの代わりにこれらのテストを書かせ始めています。LLMを、世界中のほぼすべての料理本を読み、新しいレシピを即座に書くことができる超スマートなロボットだと考えてください。

しかし、落とし穴があります。これらのAIシェフは「味見のストーリー」を書くことは得意ですが、しばしば「キッチンのルール」を忘れてしまいます。彼らは正しい材料（インポート）を取り込むのを忘れたり、間違った種類のフライパン（フレームワーク）を使ったり、あるいは火をつけずに調理しようとしたりします（セットアップの欠如）。現実の世界では、もしテストがコンパイルできない（つまり、小さなミスによって実行すらできない）場合、そのロジックがいかに巧妙であっても、それは役に立ちません。この論文は、なぜAIが生成したテストが、乱雑な現実世界のキッチンで失敗するのかを探求し、AIを成功させるための新しい方法を提案しています。

問題点：フライパンを忘れるAIシェフ

この論文の著者である天津大学とHuawei Cloudのチームは、大規模な産業用ソフトウェアプロジェクトに取り組む中で、ある苛立ましい現象に気づきました。彼らは最新のAIツールを使用してユニットテストを自動生成しようと試みましたが、AIは巧妙なテストのアイデアを生み出すことはできるものの、実用面では結果がしば在り得ないものになることが多かったのです。

ロボットにレゴのお城を作るよう頼む場面を想像してみてください。ロボットは塔や旗の素晴らしいデザインを考案するかもしれませんが、もしベースプレートを含めるのを忘れたり、適合しない別のセットのパーツを使おうとしたりすれば、全体が崩壊してしまいます。ソフトウェアの観点で言えば、AIはしばしばテストの「コンパイル」に失敗しました。これは、現実世界のソフトウェアが巨大で相互に接続された都市のようなものであるために起こります。単一のコード片（「フォーカルメソッド」）は、ライブラリ、他のファイル、および特定のフレームワークに依存していることがありますが、AIはテスト対象として求められたその一つのコード片しか見ていなかったため、それらを知らなかったのです。

研究者たちは、AIが失敗し続ける主な理由を3つ発見しました。

1. コンテキストの不一致（Context Mismatch）: AIは、指示される代わりに、キッチンのルール（どのテストフレームワークを使用するかなど）を推測していました。AIは間違った材料を推測してしまい、それが即座にエラーにつながりました。
2. 脆弱な足場（Fragile Scaffolding）: AIは、セットアップやインポートを含むテスト構造全体をゼロから構築しようとしました。これは、ロボットにベースプレートと城の両方を同時に作らせるようなものでした。ロボットはしばしばベースプレートを間違え、その結果、城全体が崩れてしまったのです。
3. コストのかかる修理（Costly Repairs）: テストが失敗した際、通常の方法はAIにもう一度、何度もやり直させることでした。これは、ネジ一本が足りないために、ロボットを何度も設計図の段階に戻すようなものです。これには時間がかかり、多くの計算資源（トークン）を消費し、多くの場合、ロボットは同じ間違いを繰り返すだけでした。

解決策：スマートなキッチン助手、CATGen

これを解決するために、チームはCATGenと呼ばれる新しいワークフローを構築しました。AIにすべてを推測させるのではなく、シェフが調理を開始する前に、ステーションを完璧に整える厳格だが親切なキッチンマネージャーとして振る舞うことにしたのです。

彼らのアプローチには、4つの主要なステップがあり、彼らはこれを「コンテキスト認識ワークフロー」と呼んでいます。

1. コンテキストの収集: AIがコードを一行も書く前に、CATGenはプロジェクト全体をスキャンして、必要な「材料」を見つけ出します。ビルドファイルを確認し、どのテストフレームワーク（JUnitなど）やモッキングライブラリ（Mockitoなど）が使用されているかを調べます。また、そのコードがどの他のファイルと通信しているかもチェックします。これにより、AIがどのようなツールを利用可能であるかを正確に把握できます。
2. スケルトンの構築: AIにテストクラス全体をゼロから作らせるのではなく、CATGenはまず「スケルトン（骨組み）」を構築します。これは、レゴのベースプレートと城のフレームを事前に組み立てておくようなものです。厳格なルールを用いて、インポート、クラス名、およびセットアップメソッドが100%正しいことを保証します。その後、AIにはこのあらかじめ構築された安全な構造の中で、テストの「肉（実際のロジック）」を埋めることだけを求められます。
3. ギャップを埋める: AIはテストメソッドを記述しますが、完璧なスケルトンの中で作業しているため、構造的なエラーを起こす可能性が大幅に低くなります。AIは純粋にテストのロジックに集中できます。
4. セーフティネット（静的解析）: もしAIが依然として小さなミス（セミコロンの欠落や変数名の誤りなど）を犯した場合、CATGenはAIに再試行を求める代わりに、「静的解析」ツールを使用します。これは、プロジェクトのルールに基づいて一般的なエラーを即座に修正する、コードのスペルチェッカーのようなものです。これは高速で決定論的であり、AIに推測させるために時間を浪費することはありません。

結果：より速く、より賢く、そして実際に動作する

チームは、非常に複雑な実世界の産業プロジェクト、およびDefects4Jと呼ばれる有名なオープンソースのベンチマークを用いてCATGenをテストしました。彼らは、従来の探索ベースのツールや他のAIアプローチを含む、6つのトップメソッドと比較しました。

結果は目覚ましいものでした。産業環境において、CATGenは**91.83%のコンパイル成功率を達成しました。これは、生成された100個のテストのうち、91個以上がすぐに動作したことを意味します。比較として、次に優れたAI手法は約67%しか達成できず、従来のツール（EvoSuite）は75.80%**でした。

しかし、単に動作するだけでなく、品質についても優れていました。CATGenは、他の手法よりも多くのコード行（70.10%のラインカバレッジ）と、より多くのロジック分岐（63.92%のブランチカバレッジ）をカバーしました。おそらく最も重要なのは、驚異的な効率性です。他の手法がテストの生成と修正に数千秒と数百万の「トークン」（AI計算の通貨）を費やした一方で、CATGenはわずか1,836秒で全工程を完了し、使用したトークンもわずか203,000でした。これは、他の手法と比較して50%から80%減少という、大幅な時間とコストの削減です。

研究者たちは、どの部分がどのような役割を果たしているかを確認するために、機械を分解するような「アブレーション研究（切除研究）」も行いました。彼らは、もし「スケルトン」のステップを取り除けば、成功率は大幅に低下することを発見しました。もし「静的解析」による修理ステップを取り除けば、成功率はさらに激しく崩壊しました。これは、彼らの新しいシステムのすべての部分が不可欠であることを証明しています。

教訓

この論文からの大きな教訓は、AIを現実世界でうまく機能させるためには、単に優れた「プロンプト」（AIへの指示）を書くだけでは不十分だということです。AIの周囲により優れたシステムを構築する必要があります。AIに適切なコンテキストを与え、作業のための強固な土台を築き、小さなミスを修正するために高速な非AIツールを使用することで、AIが生成したテストを真に有用なものにできるのです。

著者たちは、AIが真にソフトウェアエンジニアリングに役立つためには、AIをすべてを解決する魔法の杖として扱うのではなく、より大規模で高度に設計されたシステムにおける強力なコンポーネントとして扱う必要があると示唆しています。彼らが述べているように、信頼できるテスト生成は、「プロンプトエンジニアリング」単独よりも、「体系的なエンジニアリングサポート」に依存しています。結局のところ、CATGenは、AIシェフに適切なキッチンと明確なレシピを与えれば、本当に素晴らしいテストを調理できることを示しています。