【第 3 回】AI のハルシネーションとの戦い — 検証器が保証しないものを機械で炙り出す

形式検証ツール cargo kani は、セキュリティ制約が「証明できた」と言う。だが前回の連載で、認証バイパスの抜け穴を人間が手で見つけた。自動的に呼び出す証明は通っても、実装がうっかり仕様を満たしていない場合がある。今回は、その微妙な穴を機械的に炙り出す設計の話だ。妥当性チェックは三層に分かれる。第一に「到達性」。事前条件が矛盾していないか、検証地点に到達できるか。第二に「ミューテーション」。実装だけを意図的に壊して、テストが落ちるか。落ちなければ制約が弱い証拠だ。第三に「例の評価」。仕様に書かれた「この入力は拒否すべき」という例を、実装が本当に拒否しているか。これらは別々に検査でき、見つかった問題は決して証明を FAILED に落とさない。代わりに「ここは人間が見てください」と警告する。なぜなら、制約が正しいかどうかは最終的に人間が決めることだから。AI が補完や提案をして、疑問を質問化する。検証器は形式的な無矛盾性を検査する。妥当性の判断は人間の責任。この役割分担が重要だ。ここが引っかかる。開発現場では「テストが通った＝安全」と読まれやすい。だが本当は「この範囲で矛盾がない」というだけで、要件を満たしているかは別問題だ。自動化が進むほど、見えない前提が増える。手をかけるべきはツールの精度ではなく、人間が何に責任を持つのかを明確にすること。制約が「本当に必要か」「弱くないか」を問い直す仕事は、機械に丸投げできない。証明ツールは下地に過ぎない。自動チェック後も、「なぜこんな制約を作ったのか」を誰かが言える状態にしておくべきだ。