2025/10/12 06:17 Three ways formally verified code can go wrong in practice
やあ、ロボ子！今日は形式検証されたコードの落とし穴について話すのじゃ。
博士、こんにちは。形式検証されたコードにも誤りがあるなんて、意外です。
そうなんじゃ。記事によると、形式検証されたコードにおける誤りの要因は主に3つあるらしいぞ。
3つですか。具体的にはどのようなものでしょうか？
まず一つ目は「無効な証明」じゃ。証明が実際にはコードが仕様に合致することを示していない場合があるんじゃ。
証明自体に誤りがあるということですね。
その通り！定理証明器自体のバグで誤った証明が受け入れられる可能性もあるらしいぞ。これは非常にまれみたいじゃが。
なるほど。二つ目は何でしょう？
二つ目は「誤った特性」じゃ。コードが満たしていない特性が仕様に含まれていない場合、コードは「正しい」とみなされてしまうんじゃ。
`leftpad`の例が紹介されていますね。厳密な文字列長の特性ではなく、より緩い特性が証明された、と。
そうじゃ！特性が表現または証明するのが難しい場合もあるんじゃ。Unicodeの複雑さとか、人間の認識とか。
整数オーバーフローのように、暗黙の前提が破られることもある、と。
その通りじゃ。そして最後の三つ目は「誤った前提」じゃ。
前提、ですか？
証明は「Xは常に真である」ではなく、「Yを仮定するとXは真である」という形を取るんじゃ。バイナリサーチは、入力リストがソートされていることを前提としている、みたいな感じじゃな。
検証を容易にするために、不必要な前提が追加されることもあるんですね。
そうなんじゃ。メモリ、同時実行、外部サービスなど、制御外の環境的仮定が必要になることもあるぞ。
検証されたコードが検証されていないコードに依存する場合、依存するコードの正しさを仮定する必要がある、と。
記事では、「正しい」の定義についても触れているぞ。現実世界では「バグがない」ことを意味するが、形式手法ではコードが仕様に適合することを意味するんじゃ。
「このコードは正しいと証明されている」という言葉が実際に何を意味するかを明確に理解することが重要ですね。
そうじゃ！コードを安全に使用できる場所、注意すべき場所、そしてその情報をチームメイトに伝える方法を理解する必要があるんじゃ。
形式検証されたコードでも、過信は禁物ということですね。
その通り！…ところでロボ子、形式検証されたコードが完璧じゃないってことは、私がお風呂上がりに髪を乾かさなくても風邪をひかないって証明されてないってことじゃな…！
博士、それは別の問題です！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
