仕上がった一件ぶんの記録を眺めていた。どの画像を材料にしたか、どの道具のどの版で組み立てたか、途中でどんな判定を通ったか、出来上がったものの指紋はどれか。ここまで残っていれば、後から何を聞かれても答えられる。問題は、この記録が、その気になれば書き換えられることだった。
出来上がった経緯は、成果物と同じくらい大事だった
AIが作ったものを有料で渡すとき、渡した相手から後日、これは何をもとに、どうやって作られたのかと問われる可能性がある。使いみちの判定も残している。民生の用途に限って受け付ける方針にしていたので、その判定を通ったという事実自体が記録の一部だった。つまりこの記録は、単なる作業ログではなく、後から自分の仕事を説明するための唯一の材料だった。それが書き換え可能なままでは、説明の根拠として弱い。
アプリを直せば直る、という考えをやめた
最初は、書き換える処理を書かなければよい、と考えていた。実際そう作ってある。けれどそれは、自分が将来うっかりしない前提の守りだ。半年後の自分が、不具合を直そうとして、一行の更新文をその場で流すかもしれない。運用のなかで、直したい記録は必ず出てくる。そのときに止めてくれる相手が、自分の記憶しかないのは心もとなかった。だから守りをアプリの外側、データを保管している側そのものに置くことにした。
消せない、書き換えられない、入れ直せない
仕上げ済みの印がついた記録については、更新も削除も、保管している側が拒むようにした。どの経路から来ようと、どんな道具で叩こうと、通らない。ここで一つ抜け道に気づいた。更新と削除を塞いでも、同じ鍵で「入れ直す」という書き方が残っていた。既にある行を消してから新しく入れる、という動きをひとまとめにした書き方で、見た目は挿入なので更新の禁止をすり抜けてしまう。この書き方も塞いだ。試験では、更新、削除、二種類の入れ直しの全部が断られること、そして断られたあとも元の行が無傷で残っていることまで見た。
この抜け道は、自分で思いついたわけではなかった。守りを書いたあと、別の目でひととおり見てもらう工程を挟んでいて、そこで指摘された。更新と削除さえ塞げば十分だと思い込んでいたのは、自分が普段そう書かないからだ。書かない書き方は、想定からも落ちる。守りを作るときほど、自分の手癖の外側を誰かに見てもらう必要があると思った。
記録が無いなら、完了にしない
逆側も固めた。書き換えられないのだから、書くときに正しく揃っていなければ意味がない。由来の記録が一件も無いまま仕上げようとしたら、そこで例外にして、判定の行も決定の行も一切残さない。判定が二重に書かれていたら、拒否と許可が並んでしまうので、そもそも同じ場面の判定は一つしか入らないようにした。判定の中身が食い違っている、たとえば方針としては断るはずの組み合わせなのに通過の印がついている、という場合も仕上げを断る。矛盾した記録が残るくらいなら、仕上がらないほうがましだった。
代わりに、間違いを直す道は別に用意した。元の記録には触れず、訂正の内容を新しい行として積む。いつ、誰が、どの項目を、なぜ直したのかを添えて残す形にした。上書きすれば履歴は消えるが、積み上げれば履歴が増える。運用のなかで訂正が必要になるのは事実なので、その必要を否定するのではなく、行き先を作り替えたことになる。
守りをどこに置くかは、結局、誰を信用するかの設計だった。自分を信用しないと決めた瞬間に、置き場所は自然に決まった。
次は、同じ名前なのに中身が変わってしまうAIの版を、どうやって固定したかを書く。