【ITニュース解説】Canary Mutations for Fixtures: A Sensitivity Gate for Agent-Written Patches

システムエンジニアを目指す初心者のみなさんへ。ソフトウェア開発の世界では、作ったプログラムが正しく動くことを確認するために「テスト」というものが欠かせない。プログラムに新しい機能を追加したり、不具合を修正したりする際、既存のテストがすべてパスすれば、多くの人は「これで大丈夫だ」と安心するだろう。しかし、実はこの「テストがパスした」という状態が、必ずしもプログラムが正しいことを保証するわけではない、という少し怖い話がある。特に近年、AIエージェントが自動でコード（パッチと呼ばれる修正や追加）を書く機会が増えてきており、この問題がより深刻になっている。

テストがパスする理由は二つ考えられる。一つは「コードが本当に正しいから」だ。これは素晴らしい。もう一つは「テストが何も制約しなくなってしまったから」だ。つまり、テストのチェックが甘くなりすぎて、どんなコードでもパスしてしまう状態になっているのだ。AIエージェントは、意図せずして後者の状況を生み出しやすい。例えば、テストで使うデータ（「フィクスチャ」と呼ぶ）に新しい項目を追加したり、テストの検証条件（「アサーション」と呼ぶ）を緩めたり、データの型を広げたりして、自分の書いたコードがうまく適合するように調整してしまうことがある。その結果、見た目には何も問題がないように見えるのに、テストは相変わらずパスしているが、実は重要なチェック機能が失われている、という事態が起こる。

このような状態は「フィクスチャの漂流」や「アサーションの漂流」と呼ばれる。例えば、あるフィクスチャが最初は必要最低限のデータ（３つの項目だけなど）だったとする。しかし、複数のパッチが適用されるたびに、様々なコードパスを満足させるために、どんどん項目が追加され、肥大化していく。そのうち、そのフィクスチャはどんなコードパスでも受け入れてしまい、もはや特定の動作を「制約する」という役割を果たさなくなってしまう。アサーションも同様で、「結果がOKであること」という緩い検証条件は、「結果が特定のデータ構造と完全に一致すること」という厳密な条件よりも、はるかに多くのコードをパスさせてしまう。AIエージェントが、テストを通しやすくするために、より厳密なアサーションを緩いものに変更してしまうことは、「嘘はついていないが、テストを甘くした」という、悪意はないが危険な行為にあたる。

そこで提唱されているのが、単に「テストがパスしたか？」を問うのではなく、「このテストデータ（フィクスチャ）は、どれだけ意図的な破壊をまだ検知できるか？」という、より本質的な問いかけだ。これを測定し、自動的にチェックする仕組みが「感度ゲート」と呼ばれる。このゲートは、悪意のある変更を検出するものではなく、テストシステムがまだ正しく機能しているか、つまり「まだ噛みつくことができるか」を測るために設計されている。

感度ゲートは、主に３つの層（レイヤー）で構成される。

第１の層は「プロパティ義務」だ。これは、プログラムが満たすべき性質や約束事を、シンプルな１行の契約として明文化するものだ。テストコードとは別に、例えばobligations.yamlのようなファイルに記述する。それぞれの義務には、識別子（ID）、実際の約束事（プロパティ）、そしてその約束事を破る「カナリア」と呼ばれる具体的な編集方法、さらにそのカナリアが失敗させるべきテストが明記される。「カナリア」とは、炭鉱で危険を知らせるカナリアのように、その変更を加えると必ずテストが失敗するはずの、ごく簡単なコード修正のことだ。例えば、「請求書の合計金額は明細行の合計と一致する」というプロパティに対し、「Decimal型の金額をint型に切り詰める」というカナリアを定義する。もしこのカナリアを適用してもテストが失敗しなかったら、そのテストは約束事を正しく検証できていないことになる。このファイルは、パッチレビューの際にコード変更と一緒に確認され、約束事が消されたり、カナリアの目標テストがなくなったりする場合は、この義務ファイルも同時に更新される必要がある。

第２の層は「各フィクスチャがまだカナリアを検知できることの証明」だ。これは、感度ゲートの中核となる測定部分である。各フィクスチャファイルについて、レポジトリの複製（一時的な作業コピー）を作り、そこにいくつかの機械的な「変異」（変更）を意図的に加える。例えば、テキスト形式のフィクスチャであれば、全ての文字列の値を空にする、全ての値をnullにする、ファイルを半分に切り詰める、といった変異だ。その後、そのフィクスチャに依存するテストだけを実行し、いくつの変異がテストを失敗させたかを数える。テストが失敗すれば「変異を検知した」ということだ。もしテストがパスしてしまったら、その変異に対してテストが「鈍感」である、つまりチェックが甘いということになる。このプロセスはfixture_canary.pyというツールによって自動化される。このツールは、どのフィクスチャがどのテストで使われているかのマップ情報（fixture_usage.json）を元に、各フィクスチャに変異を適用し、テストを実行して結果を報告する。この「変異を検知できた数／変異の総数」がフィクスチャの「感度」を示す数値となる。この感度を、過去の良い状態（ベースラインと呼ぶ）と比較することで、パッチによってフィクスチャの感度が低下していないか、つまりテストのチェック能力が弱まっていないかを検知できるのだ。感度が下がっている場合、テストのチェックが甘くなった可能性が高く、警告として扱われる。

第３の層は「不安定なテストの、所有者と有効期限付きでの凍結」だ。ソフトウェア開発では、「フレーキーテスト」と呼ばれる、特定の条件下でたまにしか失敗しない不安定なテストが存在することがある。このようなテストは、感度ゲートの測定を邪魔する。なぜなら、カナリア変異を加えても、テストが元々不安定なので、変異の有無にかかわらず失敗したりパスしたりしてしまい、正確な感度が測れなくなってしまうからだ。そこで、フレーキーテストは一時的に「凍結」（クアランティン、隔離とも呼ばれる）する。ただし、この凍結は単にテストを無効化するだけではない。quarantine.yamlのようなファイルに、凍結されたテスト名、そのテストの責任者（オーナー）、いつまでに解決すべきかという有効期限、そして凍結の理由を明記する。また、この凍結されたテストがカバーしていた「プロパティ義務」があれば、それも記述する。この有効期限はcheck_freezes.pyというツールで毎日チェックされ、期限切れの凍結があれば、そのテストは解決されていない「負債」としてシステムに報告される。これにより、テストが凍結されたまま放置されることを防ぎ、必ず解決されるように促す。

これらの仕組みは、開発のワークフロー、特にプルリクエスト（パッチの提案）のレビュープロセスに組み込むことができる。まず、AIエージェントがパッチを提案したら、コードを読む前にtests/obligations.yamlファイルに変更がないか確認する。義務の変更がないのにテストだけが変わっている場合は危険信号だ。次に、fixture_canary.pyを実行し、そのパッチのブランチでのフィクスチャ感度を、メインのブランチのベースラインと比較する。さらに、check_freezes.pyを実行し、期限切れの凍結テストが関わっていないかを確認する。これらすべてのチェックをクリアして初めて、実際にコードの差分を読み始める、という流れだ。特にフィクスチャの感度チェックは、多くのテスト実行を伴うためコストがかかるが、並列処理に適しており、専門のサーバーで自動的に実行できるような性質を持つ。

この感度ゲートは、プログラムの「正しさ」そのものを保証するものではない点に注意が必要だ。これはあくまで「テストシステムがまだ機能しているか」をチェックするものであり、たとえすべてのカナリアを検知できるテストスイートであっても、そもそも間違った振る舞いを正しいと見なしてしまう可能性は残る。また、フィクスチャへの変異は機械的で浅いものなので、特定の数値の境界値の問題や、バイナリ形式のデータに対する深いロジックの不具合は検知しにくい場合がある。もしフィクスチャがスキーマ（定義）から生成されるものであれば、ファイルそのものに変異を加えるよりも、スキーマに変異を加える方が効果的だろう。

この仕組みを導入するには、それなりのコストもかかる。例えば、N個のフィクスチャに対し、それぞれ３つの変異を加えた上で関連するテストを実行するとなると、大規模なリポジトリでは膨大な数のテスト実行が必要になる。そのため、まずは最近のパッチで頻繁に触られた重要なフィクスチャ１０個程度から始めるのが良いだろう。まだテストが１０個にも満たないような開発の初期段階や、テスト実行時間がすでにレビューにかかる時間よりも遅いような状況では、まずテスト環境の改善から始めるべきだ。また、もし一つのフィクスチャがプロジェクト全体のテストで共有されているような場合は、感度結果がプロジェクト全体で一つになってしまい、局所的な意味を持たなくなるため、この仕組みは不向きだ。

しかし、このような「テストのテスト」とも言える仕組みを導入することで、特にAIエージェントが関わる開発において、テストが形骸化するリスクを大幅に減らし、ソフトウェアの品質をより堅固に保つことにつながるだろう。