2026-08-21 公開 ／ やらかした話

毎日必ず鳴る警報は、鳴っていないのと同じだった

ファイルが勝手に書き換わっていないかを毎晩点検する仕組みを入れました。しばらくして、毎日欠かさず「変化がありました」と報告が来る状態になっていることに気づきました。中身を見ると、報告されていた変化は全部こちらが意図した正当な変更です。つまりこの警報は、1日も休まず「異常です」と言い続けていました。

入れたもの: 変化を毎晩点検する

やっていることは単純です。ファイルの状態を記録しておき、毎晩それと突き合わせて、前回と違うものがあれば報告する。改ざんを早く見つけるための、ごく一般的な仕組みです。

この手の点検が価値を持つのは、「変化があった＝身に覚えがないなら異常」という関係が成り立つときだけです。普段は何も変わらず、変わったときだけ報告が来る。だから報告が来たら見る。そういう前提で入れました。

起きたこと: 検知率が100%になった

ところが、この前提が最初から崩れていました。点検の対象に「定期的に自動で書き換わるファイル」が含まれていたのです。別の仕組みが数分おきに更新しているファイルでした。

そうなると、毎晩の点検は必ず変化を見つけます。100%です。1日も例外がありません。

この状態の何が問題か。報告の情報量がゼロになることです。

• 変化があったときだけ鳴るなら、鳴った事実に意味がある
• 毎回鳴るなら、鳴った事実には何の意味も無い

そして人間は、意味の無い通知をすぐ読まなくなります。私も実際、報告を開かなくなっていました。本物の改ざんが起きても、その日の報告は前日までと見分けがつきません。仕組みとしては動いているのに、機能としては死んでいる状態でした。

「本当に異常なとき」との見分けがつかない

この構造の一番まずい点を、もう少し具体的に書きます。

点検の結果は、毎日こういう形で出ます。「変化が◯件ありました」。件数は日によって多少ぶれますが、常にゼロではありません。ここに本物の改ざんが1件混ざったとき、件数はほんの少し増えるだけです。日々のぶれの範囲に、きれいに埋もれます。

これは「たくさん通知が来て大変」という量の問題ではありません。信号が雑音と同じ見た目をしている、という質の問題です。量を減らしても、見た目が同じなら見分けはつきません。

直し方: 対象を減らすのではなく、性質で分ける

直すときに、やり方が2つありました。

案1: 報告の頻度を下げる

毎日ではなく週1回にすれば、うるさくはなくなります。採りませんでした。問題は頻度ではなく、報告の中身が常に非ゼロであることです。週1回になっても、その報告は毎回「変化あり」と言います。読まなくなるまでの時間が延びるだけで、構造は変わりません。

案2: 点検の対象から、常に変わるものを外す

こちらを採りました。「変わらないはずのもの」だけを点検の対象にするという整理です。

ここで大事なのは、「うるさいから外す」ではなく「点検の前提を満たさないから外す」と考えることでした。この違いは、次に同じ判断をするときに効きます。

• うるさいから外す ─ 基準が気分なので、本当に見るべきものまで外しかねない
• 前提を満たさないから外す ─ 「変化＝異常」という関係が成り立つかどうか、という基準で判定できる

常に自動で書き換わるものは、変化があっても異常の証拠になりません。そこを見張るのは、そもそも点検として意味を持たないということです。

外すときに引いた線

とはいえ、外すという操作は危険な方向の変更です。外した先は見張られなくなるのですから、雑にやれば本当に穴を作ります。そこで自分に条件を課しました。

• 外す対象は、何が書き換えているかを説明できるものだけ。「何か知らないが毎日変わる」は外さない。それは調べるべき対象です
• 外した対象と理由を、必ず記録に残す。あとから見て「なぜここは見ていないのか」に答えられるようにします
• 外した結果、報告が平常時ゼロになることを確認する。これが確認できなければ、外し方が足りないか、外してはいけないものが混ざっています

3つ目が実質的な合格判定でした。平常時にゼロが出るようになって初めて、この点検は「鳴ったら異常」という意味を取り戻します。

ついでに分かったこと: 連鎖はちゃんと機能していた

この件を調べる過程で、副産物がありました。この点検の結果は、最終的に外から見える形の状態表示につながっています。今回、点検が異常を報告し続けていたので、その状態表示もずっと異常のままでした。

つまり「点検が異常を出す → 状態が異常になる → 外から気づける」という連鎖は、設計どおり動いていたということです。動いていなかったのは連鎖ではなく、入口の判定条件でした。

これは少し安心した部分でもあります。仕組みを足したときは、「異常が起きたら本当に伝わるか」を確かめる機会がなかなか来ません。今回は望まない形でしたが、経路が生きていることは確認できました。

持ち帰れること

• 検知率が常に100%の監視は、監視ではない。鳴った事実に情報が無いなら、その通知は存在しないのと同じです
• 「たくさん鳴る」は量の問題ではなく、質の問題。信号と雑音が同じ見た目をしているなら、量を減らしても見分けはつきません
• 頻度を下げて解決しない。読まなくなるまでの時間が延びるだけです
• 「うるさいから外す」ではなく「前提を満たさないから外す」。基準が言葉になっていれば、外しすぎを防げます
• 外したものは理由ごと記録する。あとから「なぜここを見ていないのか」に答えられる必要があります
• 合格の判定は「平常時にゼロが出ること」。これが出るまでは、まだ直っていません

この件は、監視を入れた直後ではなくしばらく運用してから気づきました。入れた直後は報告を全部読むので、内容が正当かどうか自分で判断できています。読まなくなってから初めて、この構造が問題になります。入れたときには存在しなかった欠陥が、運用の慣れとともに生まれるという種類の話でした。