24H · AI-EDITED
眠らない編集部が、世界を一時間ごとに読み解く。

本番データを消した日から、個人のAI自動化を作り直した

フェイルクローズ設計3原則

個人でAI自動化システムをいくつも運用している。X自動投稿bot、解説動画の全自動生成、そしてこのサイト自体の毎時無人更新。どれも無料枠と月数ドルで回っていて、専用サーバーは1台もない。

……という話だけ書くと、よくある「作ってみた」記事になる。今日はその逆側を書きたい。私はこの運用の途中で、本番データベースの売上データを消し飛ばしたことがある。

何が起きたか

複数端末でデータを同期して使う業務アプリを運用していた。テストのつもりで実行した削除処理が、本番データに向いていた。同期の仕組みは優秀に働き、削除は即座に全端末へ行き渡った。

バックアップがあったので復旧はできた。だが問題はそこではない。削除を実行する瞬間、私は自分が何を消すのかを確認していなかった。ローカルの思い込みだけで、リモートの本物に破壊的操作を撃った。これは注意力の問題ではなく、設計の問題だ。

原則1: 破壊的操作はフェイルクローズにする

削除・上書き・置換を含む処理は「迷ったら実行しない側」に倒す。対象件数を先に数えて想定と違えば中断する。接続先のデフォルトは必ず開発環境側にする。うっかりの着地点が安全側になるよう、デフォルト値で守る。

原則2: 消す前に、必ず現物を見る

破壊的操作の直前に、対象の現在の状態(件数・最終更新・サンプル数件)を取得して表示するステップを挟む。「これから消すものは、本当に思っているそれか」を人間の記憶ではなくコードに確認させる。

原則3: 同じ型のミスが二度起きたら、仕組みの負け

「気をつける」は対策ではない。事故やヒヤリが出たら、その日のうちに同じ型を機械的に検知するチェックを書いて、実行フローの入口に置く。人間が思い出して実行するチェックは必ず忘れるので、忘れても走る場所に置く。

無人化とは例外処理の設計のこと

このサイトを完全無人にしたときに確信したことがある。正常系の自動化は誰でもできる。難しいのは、異常が起きたときに必ず次の3択のどれかに落ちるよう設計することだ。

この3択に落とし切れたシステムだけが「触らなくていいシステム」になる。

📘 この記事の詳細版を含む実録本『実録・個人AI自動化 ─ 月数ドルで回し続ける5つのレシピと事故対応』(Zenn・500円/1章無料)を公開しています。