【ITニュース解説】Beyond Green Checks: Designing Intent-Level Tests to Stop AI from Shipping Confidently Broken Code

現代のソフトウェア開発において、人工知能（AI）、特に大規模言語モデル（LLM）がコードを生成する能力は目覚ましい。しかし、この能力は新たな課題も生み出している。LLMが生成するコードは、見た目には正しく、基本的な単体テスト（ユニットテスト）を簡単にパスしてしまうことが多い。これは、コードが正しく動作していると誤解させる「グリーンチェック」の幻想を生み出す。

従来のソフトウェア開発では、コードがコンパイルされ、定義されたテストがパスすれば「正しい」と見なすことができた。これは、人間がコードを書く際には、そのコードを書いた明確な意図があるという前提に基づいていたからだ。例えば、if (user.role == "admin")というコードは、特定のセキュリティ上の問題を回避するため、という明確な目的がある。しかし、LLMにはこのような「意図」がない。LLMは訓練データに基づいて、次に続くトークン（単語や記号）の統計的な確率を最大化するようにコードを生成する。そのため、正しい入力形式を受け取り、正しい出力形式を返し、例外を発生させず、特定の「正常系」のテストケースに合致するコードを生成できたとしても、システムのより深い部分にある不変条件やビジネスルールを意図せず破ってしまうことがあるのだ。

例えば、AIが生成した支払い処理関数は、少額の整数計算では正しく動作するかもしれない。しかし、高額の取引で浮動小数点数演算を使用し、意図しない精度誤差を引き起こす可能性がある。この場合、小さな整数を使った単体テストはパスするが、本来の意図である「財務的な正確性」は損なわれていることになる。この問題に対処するため、私たちはテスト戦略をコードが単独で何を返すかという検証から、実装方法に関わらず必ず成り立つべき「プロパティ（特性）」を検証する方向にシフトする必要がある。

意図レベルのテストを設計するために、テストの「意図」を三つの明確な階層に分類することが有効だ。AIが生成するコードは通常、最初の階層はパスするが、第二、第三の階層で問題を抱えやすい。

第一階層は「構造的整合性」である。これは、コードがクラッシュせずに実行されることを目標とし、リンティング、型チェック、コンパイルなどが含まれる。LLMはこの種のチェックを非常に得意とするため、リスクは低い。

第二階層は「振る舞いの一貫性」であり、「正常系」のテストとも呼ばれる。特定の入力が特定の期待される出力を生み出すことを目標とし、標準的な単体テストや結合テストがこれにあたる。LLMはプロンプトが具体的であればこれらのテストをパスさせることが多いが、特定の解決策を「ハードコード」したり、エッジケースを見落としたりするリスクが中程度に存在する。

第三階層は「意図と不変条件」であり、「なぜそうあるべきか」を問う最も重要な部分だ。これは、コードがビジネスルール、物理法則、あるいはドメインを定義する論理的制約に適合していることを目標とする。プロパティベースドテスティング（PBT）、ステートマシン検証、差分テスト、不変条件チェックなどがこの階層のテスト方法だ。LLMは意図を明示的に検証するよう強制されない限り、不変条件を「理解」することは稀であるため、この階層のリスクは高い。この第三階層のテストを自動化し、「局所的には正しくても全体として間違った」コードが生産環境に出荷されるのを防ぐことが、AI時代のシステムを安全に保つための核心となる。

では、どのようにして技術的に意図を強制するのか。私たちは固定された期待値ではなく、動的なプロパティへと焦点を移す。

その一つが「プロパティベースドテスティング（PBT）」だ。これは、「この入力がこの出力を返すか？」と問う代わりに、「ドメインX内の全ての入力に対して、このプロパティが成り立つか？」と問う方法である。例えば、AIが生成した税金計算関数をテストする際に、calculateTax(100)が20を返すかを確認するだけでなく、次のプロパティを検証する。金額Aが金額Bよりも大きい場合、税金(A)は税金(B)以上でなければならない（単調性）。また、税金(0)は常に0でなければならない（境界条件）。PBTは、AIが「推測」で数式を生成することを防ぎ、普遍的に成り立つロジックの生成を強制するのに優れている。

次に、「ステートマシン検証」がある。AIが生成するエラーの多くは、多段階のプロセス（例：注文の作成、支払い、出荷）で発生することが多い。AIは、支払い確認を飛ばして「作成済み」の状態から直接「出荷済み」に遷移することを許容するコードを生成するかもしれない。これを防ぐため、有効な状態遷移を明示的に定義し、AIが生成したコードやユーザー操作が常にこれらの有効な遷移に従っているかをテストする。もしAIが、注文が「作成済み」の状態でorder.ship()を許可するコードを生成した場合、ship()の単体テストがパスしてもステートマシンテストは失敗する。

さらに、「差分テスト（ゴールデンマスター）」という手法も有効だ。これは、既知の正しい手書きの実装（これを「ゴールデンマスター」と呼ぶ）がある場合に、それを利用する方法だ。AIが生成したコードを同じ入力データセットで実行し、ゴールデンマスターの出力と比較する。もしAIコードが単体テストはパスするものの、0.1%のケースでゴールデンマスターと異なる結果を出した場合、それは丸め誤差やタイムゾーン処理など、微妙な意図の違反である可能性が高い。

これらの戦略は、具体的なプロパティベースド契約テストの形で実装できる。例えば、パスワード強度バリデーターをAIが生成した場合、単体テストでは短いパスワードを拒否することを確認するかもしれない。しかし、これは「password123」のような弱いが一般的なパスワードを許可してしまう可能性がある。意図レベルのテストでは、PBTライブラリを使って、ランダムに生成された数千もの入力に対して、最小エントロピーや特定の低エントロピーパターンを拒否するというビジネスルール（意図）が常に満たされているかを検証する。これは、AIがバリデーターとテストの両方を生成した場合に、AI自身が「強い」と知っているハードコードされたパスワードを使って、バリデーターのロジックが意図せず弱められることを防ぐ「盲目な審判」として機能する。

統合テストにおいても、具体的なAPIレスポンスのチェックから、意図レベルのアサーションへと移行すべきだ。例えば、チェックアウトフローのテストで、単にHTTPステータスが200であることを確認するだけでなく、「購入が原子的に完了すること（在庫が正確に減ること）」や「再試行しても重複して課金されないこと（べき等性）」といったシステムの振る舞いのプロパティ（意図）を検証する。これにより、AIが依存関係をモックして単にリターンコードをチェックするだけでは見つけられない、システム全体の不変条件を捉えることができる。

AIが自信満々に間違ったコードを出荷するのを防ぐためには、これらの意図レベルのチェックを継続的インテグレーション/継続的デリバリー（CI/CD）パイプラインに、機械が読み取り可能な形で組み込むことが不可欠だ。例えば、各機能にはプロパティベースドテストと不変条件チェックのみを含むIntent.spec.tsファイルを必須とし、CI/CDでこのファイルを必ず実行するようにする。さらに、AIが生成しがちなテストの品質を静的に分析し、モック設定行がアサーション行の50%を超えるテストや、ダウンストリームの状態変化を検証せずに特定のHTTPステータスコードのみをアサートするテストなどを検出する仕組みも有効だ。

結論として、AIエージェントはコードや基本的なテストを非常に高速に生成できるが、あなたのビジネスドメインにおける「正しい」という意味での「意図」を欠いている。AIは「コンパイルされるか」や「自身のテストをパスするか」は知っていても、なぜそうあるべきかは知らないのだ。テスト戦略を例ベースから意図ベース、プロパティベースへとシフトすることで、AIが簡単に迂回できない抽象的な層を築き上げることができる。AIエージェントがコードを修正する際には、プロパティテストで定義された不変条件を満たす必要がある。これらの不変条件こそが、あなたのアプリケーションにおける「物理法則」となる。

このアプローチは人間のコードレビューを置き換えるものではないが、その焦点を変える。エンジニアは、生成されたコードの細かな論理的エラーを一つ一つ確認する代わりに、不変条件が正しく定義されているか、アーキテクチャの境界が適切に保たれているかに集中できるようになる。これにより、グリーンチェックはもはや「コードが動く」という意味ではなく、「コードが定義された意図を満たしている」という意味になる。これは根本的に、より信頼性の高い開発プロセスへの道を拓くものだ。