Auditable Acceptance of LLM-Generated Code:An Evidence-Based Testing Architecture and Multi-Source Evaluation

現代のソフトウェアの世界では、コンピュータが自らコードを書くことがますます増えています。メールの草案を作成したりニュースを要約したりできるものと同じ種類の人工知能である大規模言語モデルは、今やアプリケーションを動かす複雑な指示を書くよう求められています。この変化は驚異的なスピードをもたらしますが、根本的な問題を引き起こします。それは、そのコードが本当に正しいとどうやって判断するかという問題です。コンピュータプログラムは、特定のテストセットに合格したとしても、それらのテストが想像もしなかった方法で失敗することがあります。橋が軽い荷重には耐えられても、重いトラックの下では崩落してしまう可能性があるのと同様に、基本的なチェックを通過したコードであっても、依然として隠れたエラーを含んでいる可能性があります。エンジニアにとっての課題は、単にテストを実行することではなく、それらのテストが実際に何を証明しているのかを理解し、単に「まだ見つかっていないだけ」のコードと、真に安全なコードを区別することなのです。

この問いは、サウスウェスト・ジャオトン大学、ブリストル大学、および四川農業大学の研究者による新しい研究の核心にあります。彼らは、単に「合格」か「不合格」かを伝えるのではなく、なぜあるコードが受理されたのか、拒絶されたのか、あるいはさらなるレビューに回されたのかについて、詳細で監査可能な記録を作成するシステムを構築しようとしました。彼らはこのシステムを「インテリジェント・テスティング・インフラストラクチャ（ITI）」と呼んでいます。コード生成を魔法のブラックボックスとして扱うのではなく、研究者たちは検証という泥臭い現実に焦点を当てました。つまり、どのテストが実行され、それが何をカバーし、それらのテストがどれほどの信頼性を本当に与えるべきかを正確に記録することに注力したのです。彼らの研究は、テストをより厳格にすることはできても、単にテストを追加するだけでは、最終的なコードの選択を必ずしも安全にするわけではないことを明らかにしています。実際、彼らの実験によれば、ルールを厳しくすると、悪いコードを捕まえるのと同様に、良いコードも拒絶してしまうことが多く、結果として欠陥のあるプログラムを受け入れてしまうリスク自体は変わらないことが示唆されています。

研究者たちは、慎重な門番として機能するワークフローを設計することで、この問題に取り組みました。コードが届くと、それは単なる素早いチェックを受けるのではなく、制御された条件下での一連の検証にさらされます。システムは、コードの特定のバージョン、使用されたテストツール、および実行された正確な環境を含むあらゆる詳細を記録します。決定的なのは、システムが3つの結果を区別している点です。テストが明確なエラーを見つけた場合、そのコードは拒絶されます。テストで何も問題が見つからなかったとしても、証拠が不完全であると感じられたり、テストが十分に強力でなかったりした場合は、さらなる精査のためにエスカレーションされます。証拠が完全かつ肯定的である場合にのみ、コードは受理されます。このプロセスは「意思決定の凍結（decision freeze）」、つまり、コードが真に正しいかどうかに関する外部知識が開示される前に、証拠を固定する瞬間を作り出します。これにより、決定はあくまでその時点で判明していた事実にのみ基づいて行われることになり、プロセス全体が透明性を持ち、後でレビュー可能になります。

このアプローチが機能するかどうかを確認するため、チームは2つの異なるタイプの実験を行いました。第一の実験は、研究者自身が特定の既知のエラーを含むように構築した80個のコードを用いた、厳密に制御された研究でした。これらを基本的なチェックセットと、より徹底的な第2のチェックセットの両方に対してテストしました。結果は示唆に富むものでした。第2のテストセットは、第1のセットが見逃した16個の不良コードを捕捉し、強力なテストが実際にエラーをより多く発見できることを証明しました。しかし、研究者が厳格な「受理・エスカレーション・拒絶」のルールを適用したとき、結果はそれほど楽観的なものではありませんでした。厳格なルールは、不適切なコードの数を減らすことには成功しましたが、同時に同等の割合で良質なコードも拒絶してしまいました。その結果、最終的に受理されたコードのグループには、以前と全く同じ割合でエラーが含まれていました。言い換えれば、より注意深くすることで、最終的なバッチをより安全にしたのではなく、単にバッチの規模を小さくしただけだったのです。

研究者たちは、その後、2つの異なる人工知能モデル（QwenおよびDeepSeek）によって生成された200個のコードを用い、50の異なるプログラミングタスクにわたって、より大規模で現実的なスケールでこのシステムをテストしました。ここでは、システムは異なる種類の価値を示しました。スマートなエスカレーション戦略を使用することで、システムは、全200個の候補すべてに対して最も高価で強力なテストを実行した場合と同じ最終決定に到達することができましたが、それを実現したのは、強力なテストを200個のうちわずか132個に対してのみ実行することによってでした。これにより、計算時間とリソースを大幅に節約できました。しかし、受理されたコードの質に目を向けると、システムは同サイズのランダムな選択と比較して、優れたパフォーマンスを示しませんでした。「スマート」なシステムは、明らかに悪いコードや明らかに良いコードに対する不要なチェックを回避することで、単にお金を節約しただけであり、偶然よりも優れたコードを選び出すことはできなかったのです。

また、研究ではテスト自体の構造についても調査し、異なるテストが実際に異なる種類のエラーを見つけているのか、それとも単に同じチェックを繰り返しているだけなのかを検討しました。その結果、多くの大規模なテストコレクションにおいて、かなりの部分が冗長であり、つまり全く同じ間違いを探していることが判明しました。また、「ゼロ検出（zero-detection）」テスト、すなわち、捕まえるべき既知の不良コードに対してエラーを一つも見つけられなかったテストも存在しました。さらに、多くのエラーは単一のテストによってのみ捕捉されていることも発見されました。もしその一つのテストが失敗したり削除されたりすれば、そのエラーは見過ごされることになります。この脆弱性は、テストの数が膨大であっても、テストが多様で堅牢でなければ、安全性は保証されないことを示唆しています。

最終的に、論文は、インテリジェント・テスティング・インフラストラクチャは、意思決定がどのように行われたかについての明確で監査可能な記録を正常に作成できるものの、最適なコードを選択するという問題はまだ解決できていないと結論付けています。このシステムは、プロセスの文書化を行い、不要なチェックをスキップすることでリソースを節約することには長けていますが、ランダムな選択よりも確実に良質なコードと判別できることはまだ証明されていません。研究者たちは、これらの知見が特定の制御された実験に基づいていること、そしてコードの「正しさ」が独立した人間の専門家ではなく、他の人工知能モデルによって判断されることが多かったことを強調しています。彼らは、次のステップは、このシステムを真に独立した検証と、システムが一度も見たことのないタスクに対してテストすることであると考えています。それまでは、このシステムが提供する最も価値のあるものは、安全性の保証ではなく、その過程のあらゆる段階で何が知られ、何が決定されたかという、明確で誠実な記録なのです。