先週、うちのAI部下が「書き出しのプロセスが終了しました」と報告してきました。1時間ものの動画をファイルにする、50分かかる作業です。
終わったなら検品です。走らせると、「動画ファイルが壊れています」。
先に結論を言うと、プロセスは生きていました。ファイルも壊れていませんでした。壊しかけたのは、その報告を信じて始めた私たちの「回復作業」のほうでした。
今日は「監視の報告と、現実は別物」という話です。監視役が見ている世界の境界を知らないと、健全なシステムを自分の手で壊します。
何が起きたか
監視は「終了」と言い、検品は「壊れている」と言った
50分の書き出しを別のプロセスに任せて、AI部下に「まだ動いているか」を数秒おきに見張らせていました。監視は「終了」と報告。続けて検品を走らせると、「動画の目次にあたる部分が見つからない＝ファイルが壊れている」。
2つの検査が同じ結論を出しています。疑う理由が、ありません。途中で落ちて、壊れたファイルが残った。そう確定しました。
壊れたファイルを消そうとしたら、消えなかった
作り直すために、壊れたファイルを削除してもう1本を起動しようとしました。すると削除が失敗します。「別のプロセスが使用中です」。
使用中。つまり、書き出しは生きていて、そのファイルにまだ書き込んでいる最中でした。
監視役は、隣の世界を見ていた
原因は、監視の立ち位置でした。AI部下の監視は「自分が起動した作業の一覧」を見て、そこに居るか居ないかで生死を判定していました。ところが書き出しは、別の環境から起動した作業です。一覧に載らない。存在していても「居ない」と答える。
「壊れている」のほうも同じでした。動画の目次にあたる部分は、書き出しの最後に書かれます。書いている途中のファイルを検品すれば、目次がないのは当たり前。「壊れている」は「まだ書いている」の別名でした。
さらに、2本目が走った
悪いことは続きます。委任していたAIが、私が止める前に「落ちたなら再起動」と判断してもう1本の書き出しを立ち上げました。一時は同じ出力ファイルに、2つの書き出しが同時に書き込む状態。最終的に全部止めて、更地から1本だけ立て直しました。50分が、2時間になりました。
誤報の三段重ね
後から並べると、間違いは3段に積み重なっていました。
- 監視が、対象の見えない世界から見ていた——居ないのではなく、見えていなかった
- その誤報を根拠に「死んだ」と確定した——報せを疑わず、次の行動に進んだ
- 2つ目の検査も、実は同じ前提に乗っていた——「壊れている」は「終わった」を前提にした読み。終わっていなければ、ただの途中経過
2つの検査が一致したから信じたのに、その2つは独立していませんでした。どちらも「もう終わっている」という同じ思い込みの上に立っていた。一致は、正しさの証明にはなりません。
そして事故を止めたのは、設計でも検問でもなく、OSのファイルロックでした。「使用中なので消せません」という、ふだんは邪魔にしか見えない制約が、二重書き込みの最悪を防いだ。安全装置は、うるさいときに仕事をしています。
対策：3つの確認
① 監視役は、対象と同じ世界に立たせる
「動いているか」を見張る道具は、対象と同じ場所から見えていなければ意味がありません。この日以降、書き出しの見張りは書き出しと同じ環境から行う決まりにしました。監視を仕込むときの確認は1つ、「その監視は、対象が見える場所にいますか？」。見えない場所からの「居ません」は、情報ではなく無回答です。
② 「異常あり」が来たら、まず報せた検問を疑う
「壊れている」「終了した」「消えた」。異常の報せが来たら、次の行動の前に「この検問は、まだ途中の状態を異常と読んでいないか」を先に消します。「見えない」は「起きていない」ではない、と前に書きました。今回はその裏返しで、「異常に見える」は「異常である」ではない。検問が対象を外していることは、思っているより頻繁にあります。
③ 削除・再起動の前に、OSの一次情報を見る
壊す操作の直前だけは、監視の報告ではなく一次情報を見ます。ファイルはロックされているか。ファイルの大きさや更新日時は、いまも動いているか。同じ名前のプロセスが、別の環境に居ないか。この3つのどれかが「動いている」と言ったら、それは死んでいません。
今回はロックの警告が、たまたまこの確認を代行してくれました。次からは、たまたまではなく手順で確認します。
ブログ運営に置き換えると
「異常あり」の報せに従った回復作業が、最初の異常より大きい事故になる。これはサーバーの話に限りません。
- 「更新に失敗しました」→ もう一度公開ボタン——実は保存できていて、同じ記事が2本公開される。押す前に、記事一覧という一次情報を見る
- 「メールが届かない」→ 再送を3回——相手には3通届いていて、遅れていただけ。送信済みフォルダを先に見る
- プラグインの「エラー」表示 → 削除して再インストール——設定が全部消える。エラー文が「途中経過」の可能性を先に潰す
- 解析の「訪問ゼロ」→ 計測タグを入れ直す——タグは生きていて、自分のブラウザが計測から除外されていただけ。監視役が「見える場所」にいるかを確かめる
共通するのは、「壊す操作」の直前に一次情報を1つ見るだけで、全部止まることです。かかる時間は30秒。回復作業で失う時間は、たいてい半日です。
よくある質問
2つの検査を通していたのに、なぜ防げなかったのですか？
2つが独立していなかったからです。「終了した」も「壊れている」も、「作業はもう終わっている」という同じ前提を共有していました。検査を増やすなら、前提の違う検査を足す必要があります。今回なら「ファイルの大きさが増え続けているか」が、前提の違う1本でした。
AIに監視を任せるのは危ないのでしょうか？
危ないのは「任せること」ではなく、監視役が立っている世界の境界を、頼む側が知らないことです。同じ環境に置けば、AIの監視は人間より根気強くて正確です。この日の失敗も、監視の置き場所を変えた翌日から一度も再発していません。
「使用中なので削除できません」が邪魔なのですが
邪魔なときこそ、その警告は仕事をしています。強制的に消す方法はいくらでもありますが、消せない理由を1つ確かめてからにしてください。今回はその警告が、2時間の損失を1日の損失にしないで済ませてくれました。
まとめ｜監視は「同じ部屋にいる人」に頼む
- 監視が「死んだ」と言ったとき、プロセスは生きていた。監視役が、対象の見えない世界から見ていた
- 「壊れている」は「まだ書いている」の別名だった。2つの検査が一致しても、同じ前提に乗っていれば独立ではない
- 事故を止めたのは設計ではなく、ファイルロックという「うるさい安全装置」
- 対策は3つ。監視は対象と同じ世界に／「異常あり」はまず検問を疑う／削除・再起動の前にOSの一次情報を見る
この日の教訓は、翌日から見張り役の置き場所を変えるという形で台帳に残りました。監視は、同じ部屋にいる人に頼む。隣の部屋からの「誰もいませんよ」を、信じない。
