画面いっぱいに、通過の文字が並んだ。二十八件、失敗ゼロ。利用者が画像を送り、AIが立体のデータを組み立て、手元に届くまでの道筋が、ひととおり動いた。それでも、公開の手を止めた。動くことは確かめた。けれど、動かなかったときにどうなるかを、まだ何も確かめていなかった。
通ったのは、うまくいく道だけだった
このサービスは、利用者が代金を払い、その裏で計算資源が数分間まわり、成果物が返る。つまり、途中で転んだときに損をするのは、待っていた利用者のほうだ。うまくいく道を二十八通り確かめたところで、それは「晴れた日に車が走った」という話でしかない。雨の日と、坂道と、途中でガス欠になったときの挙動が分からなければ、人を乗せる気になれなかった。特に怖かったのは、失敗したのに代金だけが残る形と、記録が中途半端に残って、あとから何が起きたのか説明できなくなる形だった。
お金と計算資源が、先に動いてしまう順番
危ないのは順番だった。受け付けて、記録を書いて、計算をまわして、仕上げる。この途中の「記録を書く」でつまずいたとき、素直に作ると、記録だけ失敗して計算はそのまま走り出す。走ってしまえば資源は消費され、代金の話が残る。だから順番を裏返した。記録が書けなかったら、その先へ一歩も進まない。受け付け自体を断り、計算は一度もまわさず、預かった分は戻す。当たり前のようだが、当たり前を仕組みとして確かめておかないと、いざというときに当たり前は起きない。
十九通りの壊し方
そこで、壊し方のほうを設計した。記録の書き込みが失敗する。証跡の保存が失敗する。仕上げに必要な記録が欠けている。同じ仕事を二回仕上げようとする。仕上がったデータを一バイトだけ書き換える。途中で機械が再起動する。用途の判定が食い違ったまま流れてくる。使った道具の版が申告と違う。十九の場面を用意し、それぞれについて、計算が一度もまわらないこと、預かった分が戻ること、仕上げ扱いにならないことを、一つずつ確かめていった。確認項目は七十七になった。
なかでも効いたのは、再起動を挟む場面だった。途中まで進んだ仕事は、機械が立ち上がり直したあと、うっかり完了として復元されがちだ。そうならないこと、そして戻す処理が二度走らないことを、確かめておく必要があった。データを一バイト書き換える試験も同じで、正しいものは通り、たった一文字違うものは受け取り口で断られる、という両方を見て初めて意味を持つ。片側だけを見て安心すると、実は何でも通していた、という結末になりかねない。
断るなら、計算をまわす前に断る
書いているうちに、断る場所にも順番があることに気づいた。仕上げの段階で断れば、たしかに不正な成果物は出ていかない。けれど、そこに至るまでに数分ぶんの計算資源はもう使っている。断ると決まっているものなら、受け付けた直後に断ったほうがいい。そこで、受け入れの可否がその時点で判断できるものについては、計算をまわす前の段階でも同じ判定を通すようにした。同じ判定を二箇所に置くのは重複に見えるが、狙いが違う。手前の判定は資源を守るためのもので、仕上げの判定は成果物を守るためのものだ。試験でも、手前で断られること、仮に手前をすり抜けても仕上げで断られること、そして普通の依頼は両方とも素通りすること、の三点を別々に確かめた。
通らないことを、確かめる仕事
出来上がった一覧を眺めると、正常に通ることを見る試験より、通らないことを見る試験のほうがずっと多くなっていた。開発の時間配分としては歪に見える。けれど、有料で他人の時間と資源を預かるものを世に出す以上、正しく動く証明より、間違ったときに被害が広がらない証明のほうが重い。ここまで来て、ようやく次の点検に進む気になった。
次は、いったん仕上げた記録そのものを、あとから書き換えられないようにした話を書く。