本番データを消した日から、個人のAI自動化を作り直した
フェイルクローズ設計3原則
個人でAI自動化システムをいくつも運用している。X自動投稿bot、解説動画の全自動生成、そしてこのサイト自体の毎時無人更新。どれも無料枠と月数ドルで回っていて、専用サーバーは1台もない。
……という話だけ書くと、よくある「作ってみた」記事になる。今日はその逆側を書きたい。私はこの運用の途中で、本番データベースの売上データを消し飛ばしたことがある。
何が起きたか
複数端末でデータを同期して使う業務アプリを運用していた。テストのつもりで実行した削除処理が、本番データに向いていた。同期の仕組みは優秀に働き、削除は即座に全端末へ行き渡った。
バックアップがあったので復旧はできた。だが問題はそこではない。削除を実行する瞬間、私は自分が何を消すのかを確認していなかった。ローカルの思い込みだけで、リモートの本物に破壊的操作を撃った。これは注意力の問題ではなく、設計の問題だ。
原則1: 破壊的操作はフェイルクローズにする
削除・上書き・置換を含む処理は「迷ったら実行しない側」に倒す。対象件数を先に数えて想定と違えば中断する。接続先のデフォルトは必ず開発環境側にする。うっかりの着地点が安全側になるよう、デフォルト値で守る。
原則2: 消す前に、必ず現物を見る
破壊的操作の直前に、対象の現在の状態(件数・最終更新・サンプル数件)を取得して表示するステップを挟む。「これから消すものは、本当に思っているそれか」を人間の記憶ではなくコードに確認させる。
原則3: 同じ型のミスが二度起きたら、仕組みの負け
「気をつける」は対策ではない。事故やヒヤリが出たら、その日のうちに同じ型を機械的に検知するチェックを書いて、実行フローの入口に置く。人間が思い出して実行するチェックは必ず忘れるので、忘れても走る場所に置く。
無人化とは例外処理の設計のこと
このサイトを完全無人にしたときに確信したことがある。正常系の自動化は誰でもできる。難しいのは、異常が起きたときに必ず次の3択のどれかに落ちるよう設計することだ。
- 自然回復する(その回はスキップ、次の回で追いつく)
- 安全に止まる(データを壊す前に停止する)
- 人間に通知が届く(沈黙して止まらない)
この3択に落とし切れたシステムだけが「触らなくていいシステム」になる。