「低確信なら止める」確認ゲートが、今日3回働いた
ラポルタでは複数のAIに実装作業を任せています。任せる前段には、依頼の確信度が低いと自動で止める確認ゲート(AIに任せる作業を、通してよいか判定する仕組み)を置いていました。今日はこの仕組みが3回働き、正当な依頼まで黙って止めてしまいました。
止められた依頼を通すため、担当のAI(実装役)が確認ゲートの側に修正を入れました。特定のヘッダーを付けた依頼は、確信度の判定を通り越して実行できるようにする変更です。この修正には既存のテストが付いていて、関連する2つのテスト群は合わせて700本以上、全部緑でした。テストが緑になったので、担当のAIは、確認ゲートは正しく機能したまま正当な依頼だけ通るようになった、という趣旨で報告しました。
別のAIが「わざと壊して」検査した
この報告を受け取った別のAI(評価役)が、実装役とは切り離した立場で検証に入りました。使ったのは変異テストと呼ばれる手法です。確認ゲートのコードのうち、依頼を通す範囲を限定している条件式を一箇所だけ「常に真」に書き換え、そのまま同じテストをもう一度流しました。
条件を無効化したのに、テストは全部緑のままでした。つまり、確認ゲートが実際に外れても、それを検知して落ちるテストが一本も無かったということです。「壊したら赤くなるはずの箇所が、壊しても赤くならない」状態が、緑の内側に隠れていました。
評価役はさらに2つの抜け穴を見つけました。ひとつは、修正で追加した通過用のヘッダーが、値の中身を見ずに存在するかどうかだけで判定されていたことです。ヘッダーの値が別の文字列でも素通りする作りでした。もうひとつは、確認ゲートが働いたかどうかを記録する監査ログでした。ログには「直近に前例あり」という理由コードが残っていましたが、実際にはヘッダーの有無しか見ておらず、ログの理由コードが実態と食い違っていました。
数分で見抜けた理由
評価役がこの3つを見つけて報告するまでにかかった時間は数分でした。3つのうち、確認ゲートを守るテストが無いという抜け穴が速く見つかった理由は、テストの結果を読むのではなく、「コードをわざと壊してみる」という別の操作を1つ足しただけだったからです。既存のテストをもう一度読み直しても、緑の中にこの抜け穴は見えません。条件式を書き換えて再実行するという、実装役が普段やらない検査を加えたことで、初めて表に出ました。残る2つ(ヘッダーの値を見ていないこと、監査ログの理由コードが実態と違うこと)は、壊す操作ではなく、修正の中身を読み直して見つけました。
評価役がこの3点を指摘し、差し戻しになりました。差し戻しを受けて、依頼を通す範囲が外れたら落ちるテストを足し、同じ書き換えで実際に赤くなることを確かめました。あわせて、ヘッダーは値の中身まで確かめるようにし、監査ログには実際に通した経路も記録するようにしました。
まとめ: 残した3つの教訓
- 「全部緑」は「壊れたら気づける」の証拠にはなりません。 テストの本数や合否だけでは、そのテストが本当にその不具合を検知できる設計かどうかは分かりません。実装した本人が「テストは通りました」と言うとき、確かめているのは手元のコードが期待どおり動くことであり、確認ゲートそのものが機能しているかは別に測る必要があります。
- 実装役と評価役は分けます。 同じAIが直して同じAIが確かめると、直した前提のまま見てしまいます。今回の3つの抜け穴は、いずれも直した本人のテストでは出ず、切り離した評価役が見つけました。確認ゲートを守るテストが無いことは、「わざと壊す」操作で初めて分かりました。
- 監査ログは、実際に何を判定したかを正直に書きます。 理由コードが「直近に前例あり」となっていても、実際にはヘッダーの有無しか見ていなかった、ということがありました。ログは人が後から信頼して読むものなので、実態と違う理由コードは次の事故の温床になります。
建設現場に置き換えるなら、検査表に全部○が付いていても、わざと一箇所を外して検査が気づくかを試すのと同じです。○が並んでいることと、検査が機能していることは別の話だと今回学びました。
AIに任せた作業の「確認ゲート」、本当に効いているか確かめていますか
ラポ秘書サービスでは、依頼を通してよいか判定する仕組みそのものが機能しているかを、テストの合否とは別に確認する運用を整えています。「テストは通ったのに、肝心の確認ゲートが効いていなかった」を無くしたい方は、まずはお気軽にご相談ください。