AI組織が止まった日にやること — 3日間の全停止で分かった「復旧順序」の設計図
自動化した業務が止まったとき、何から戻すかを決めていないと、直った日にいちばん損をする。実際に3日間止めた一次記録と、そのまま使える復旧順序テンプレート。
この記事は誰のためのものか
自動化を進めている人の多くは、止まる前提の設計をしていない。僕もそうだった。
僕は29本の定時ジョブでAI社員を動かしている。投稿を作る、返信を書く、数字を記録する、日報を出す。全部スケジュールで自動的に走る。うまく回っているときは、朝起きたら仕事が終わっている。
その全部が、3日間止まった。
原因はブラウザ側だった。ある夜を境に、ブラウザで特定のサイトの画面がまったく描画されなくなった。ページは真っ白。投稿欄そのものが存在しない。サーバー側はHTTPで正常に応答を返していたから、相手のサービス障害ではない。こちら側の環境の問題だった。
そして復旧しないまま、3日が過ぎた。
そのとき僕が最初に考えたのは、最悪の対応だった。「直ったら溜まった分を全部やろう」。これが一番損をする。
なぜなら、溜まっていないものがあるからだ。消えているものがある。それを区別しないまま「全部やる」と決めると、消えかけているものを後回しにして、すでに消えたものを取りに行くことになる。
この記事は、その失敗から作った復旧設計を、そのまま使える形で渡すものだ。読み終わると、あなたは自分の業務を2種類に仕分けて、復旧の順番を理由つきで決められるようになる。
扱わないのは、障害そのものの原因究明と、冗長化・多重化の技術論だ。それは別の話で、しかも「止まらないようにする」だけでは足りない。止まる日は来る。この記事は、来たあとの話をする。
先に完成品を渡す
理屈は後で書く。まず使えるものを置く。
保存資産1: 損失分類の判定式（3問）
止まっている業務を1つずつ、この3問に通す。
Q1. その仕事の成果物は、今この瞬間も手元に残っているか？
→ YES なら「回復可能」候補。NO なら「不可逆」。
Q2. その仕事の価値は、実行するタイミングに依存するか？
（相手の行動から◯分以内、当日中、締切前、といった条件があるか）
→ YES なら「不可逆」。NO なら「回復可能」。
Q3. その仕事には1日あたりの上限があり、
停止分をあとでまとめて実行できないか？
→ YES なら「部分的に不可逆」（上限を超える分は戻らない）。
Q1がNO、またはQ2がYESなら、それは止まった日に消える仕事だ。あとで取り返せない。
Q3がYESのものは、厄介な中間種になる。仕事自体は残っているのに、消化速度に天井があるせいで、復旧しても即日には戻らない。ここを「回復可能」に分類すると計画が狂う。
保存資産2: 復旧順序の4行テンプレート
分類が終わったら、この順に戻す。
1. 期限があるもの（腐る順。日付が切れたら価値がゼロになるもの）
2. 記録を実態に合わせ直すもの（ここがずれたまま次を動かすと後の全部がずれる）
3. 1日の上限があるもの（今日全部は消化できない。早く始めるほど早く終わる）
4. 新しく始めるもの（いちばん最後）
この4行が本体だ。以降の章は、この順番になる理由と、間違えたときに何が起きるかを説明する。
第1章 最短で使う方法
いま止まっている最中なら、次の30分でこれだけやる。
ステップ1（10分）: 止まっている業務を全部書き出す。
頭の中で数えない。定時ジョブの一覧、タスク管理ツール、日報のどれかに、動くはずだったものが必ず残っている。僕の場合は定時ジョブの設定ファイルがそれにあたり、29本のうちどれが空振りしたかを実行ログと突き合わせた。
ステップ2（10分）: 3問の判定式に通して2列に分ける。
「後で取り返せる」列と「その日に消える」列。迷ったらQ2を優先する。タイミング依存なら不可逆側に置く。分類を甘くすると、あとで自分が損をする。
ステップ3（10分）: 4行テンプレートの順に並べ替えて、上から3つだけ決める。
全部の計画を作らない。復旧のタイミングは読めないので、詳細な計画は無駄になる。「直った瞬間にこの3つをこの順でやる」だけ決めておけば十分だ。
ここまでやっておくと、復旧した瞬間に迷わない。逆に、これをやらずに復旧を待つと、直った瞬間に「何からやろう」で15分溶ける。その15分が、タイミング依存の仕事にとっては致命的になることがある。
第2章 仕組みの本質 — 損失には2種類ある
なぜ順番が要るのか。答えは単純で、止まったときの損失が均質ではないからだ。
多くの人は停止を「遅延」として捉える。3日止まったら3日分遅れた、と考える。だがこれは半分しか合っていない。
在庫が残る仕事は、遅延しただけ
僕の投稿業務がこれにあたる。止まっている間も、AI社員は投稿の本文を作り続けていた。ブラウザが動かないので投稿できないだけで、完成した本文はファイルとして手元に残っている。
3日間で、投稿できずに溜まった完成原稿は4本。ほかに、品質審査だけが未完了の原稿が3本ある。
これらは失われていない。ブラウザが直れば、そのまま出せる。順番も決まっている。遅延しただけで、損失ではない。
自動化された仕事のうち、成果物がファイルやデータとして残るものは、だいたいこの性質を持つ。書く、作る、設計する、集計する。これらは止まっても消えない。
相手のタイミングに依存する仕事は、その日に消える
問題はこちらだ。
僕の運用では、他の人の発信への返信を毎日一定数送っている。これには効果が最大化する条件があって、**相手が発信してから短時間のうちに送ったものほど読まれる。**3日前の発信に今日返信しても、届きはするが会話にはならない。文脈が切れているからだ。
止まっていた3日間で送れなかった返信は、あとから送れない。正確に言えば送信自体は可能だが、送っても価値がない。だから実質的に機会そのものが消滅している。
実際、僕は止まる直前に書き上げていた返信の下書きを5本持っていた。品質チェックも通っていた。だが3日経った時点で、これを全部廃棄にした。対象の発信が3日前になっていて、いま送ると文脈のずれた遅れ返信になるからだ。
書き上がった原稿5本を捨てる判断は、正直きつい。だが「もったいないから送る」を許すと、数字は埋まるのに成果は下がる。在庫が残っていることと、価値が残っていることは別だ。
上限がある仕事は、復旧しても即日には戻らない
3つ目の種類がある。これが一番見落とされる。
僕はフォロー関連の作業に1日あたりの上限を設けている。安全のためだ。短時間に大量の操作をすると、プラットフォーム側の制限に触れるリスクがある。だから1日の実行数に天井を置き、未達分は翌日に繰り越す設計にしている。
問題は、繰越にも上限があることだ。
僕の設計では、翌日の目標値を「基準50件＋前日の不足分」で計算し、ただし上限65件で頭打ちにしている。短期間の大量操作を防ぐための安全装置だ。