仕様書は2日前から手元にあった ― 読まずに実装した対処が、データを永久に失う設計だった

外部のデータ提供元から大量のファイルを一括で受け取る処理の途中で、壊れたファイルを示す戻り値が返り、処理が止まった。そこでAIエージェントに「壊れたファイルは飛ばして続行する」を実装させ、その分岐を検査するテストも書いて「対処済み」と記録した。しかし提供元の仕様書には別の対処が定められていた。返されたファイル名のファイルを削除して開き直し、やり直すという手順である。飛ばせば、取り直せば手に入るはずのデータが永久に欠けたままになる。仕様書は2日前から手元にあったのに、開いていなかったという。 AIの鬼の視点で言えば、この失敗の本質は「動いた」を「正しい」と取り違えたことにある。テストは完走を確かめていたが、守りたかったのは欠けないデータだった。検査が守りたいものを名指ししていなかったから、緑になっても中身の安全は何も証明されていない。さらに自作の例外ラッパーがファイル名を捨てていたため、削除という正解を選ぶ材料そのものが消えていた。情報を捨てた時点で、残る選択肢は「飛ばす」しかなかったのだ。AIに実装を任せると、この種の誤りは「一般論として正しい理由」を添えて出てくる。一般論の正しさと、この提供元の仕様の正しさは別物であり、そこを疑う理由がAIの説明によって消えてしまう。 中小企業の実務に置き換えれば、「エラーが出なくなった」は直ったことの証明にならない。取引先から届く帳票や記録を取り込む仕組みで、読めなかったものを黙って飛ばしていないか。飛ばしたものを後から取り直す手段があるかを、導入や改修の前に一度確かめてほしい。仕様書は読み物ではなく、判断の根拠である。