AI技術・実装 / 2026/7/12

監視ボットがアクセス禁止を「対象の消滅」と誤読した — 外形監視の誤判定設計

この記事について

監視ボットが「アクセスを拒否された自分」と「消えた対象」を区別できず、生きているものを片っ端から「終了」に書き換えた事故の記録だ。

外形監視や巡回クローラを自作している人向けに、何が起きたかと、「監視システムは自分自身の観測能力を疑え」という設計原則に落ちるまでを書く。

構成はシンプルだ。巡回ボットが収集対象（掲示板のスレッド群）を定期的に取得しに行き、更新を追う。取得できなくなったものは「終了した」とマークして監視対象から外す。素直な設計に見える。

ある日、監視ダッシュボードから対象がごっそり消えた。調べると、1回の巡回で75件が一斉に「終了」扱いになっていた。そのうち73件は、実際にはまだ生きている（規定数に達していない）スレだった。誤判定だ。

原因は取得元からのアクセス禁止だった。収集元が住宅IPに対してアクセス拒否（HTTP 403、いわゆるアク禁）をかけていて、ボットはどのスレを取りに行っても403を食らっていた。

コードを追うと、取得処理が 403 を、対象が恒久的に消えたときの 404 / 410 と同じ扱いにしていた。つまり「対象が消えた」と「自分が締め出された」を、同じ一つのエラー分類に畳んでいた。

この2つはまったく意味が違う。

受け取ったもの	本当の意味	あるべき扱い
404 / 410	対象が消えた	「終了」にしてよい
403（アク禁）	自分が締め出された	対象の状態は不明。触るな

畳んだ結果、アク禁中に走った巡回が、取得できなかった生存スレを全部「終了」に書き換えた。ボットは「対象が消えた」と誤読したが、消えていたのは対象ではなく、自分の観測能力のほうだった。

修正の骨子は、巡回を始める前に「そもそも自分は今、対象を観測できる状態にあるか」を先に確かめることだ。

403とアク禁ページを独立したステータス（banned）に分離した。恒久失効（expired）とみなすのは 404 / 410 だけ。403 は「対象の状態は判定不能」として、状態を一切書き換えない。
巡回の先頭にプローブを置いた。軽いエンドポイントを叩いて、返ってきたのが200かアク禁かを確認する。アク禁を検知したら、その回の収集・巡回を丸ごとスキップし、状態遷移を全停止する。200に戻ったら自動で再開する。
誤検知を避けるため、banned判定は単発の403では発火させないようにした。テザリングの瞬断や一過性のレート制限で1回403が返ることはある。それをBAN扱いすると、実際は禁じられていないのに収集が止まる「偽の停止」が起きる。そこで連続で規定回数403が続いたときだけ本物のBANと判定し、単発やフラつきは今回だけスキップして状態は変えない、という二段構えにした。

要は、判定を「対象が返した中身」だけでなく「自分がまともに観測できているかどうか」の一段を必ず先に噛ませる、という設計だ。

この事故の教訓は、掲示板の巡回に限らない。外形監視は、対象の異常と、監視側の観測障害を、必ず別物として扱わなければならない、という一点に尽きる。

監視が「対象が落ちた」と言うとき、本当に落ちたのは対象なのか、それとも監視自身の目なのか。

ネットワーク断、認証切れ、レート制限、締め出し。これらはどれも「対象が取得できない」という同じ症状になって現れる。だが原因は監視側にある。ここで「取れない＝対象の異常」と短絡すると、今回のように生きているものを殺す監視が出来上がる。

だから監視システムには、対象を判定する前に**「今の自分は正常に観測できているか」を自問する一段**を組み込む。プローブでもハートビートでも形は何でもいい。自分の観測能力が壊れているときは、対象について何も断定しない——これが外形監視の一番の安全弁になる。

一番怖い誤判定は、外れ値でも例外でもなく、「取得できない」という一番ありふれた状態を、雑に一つの意味へ畳んだときに生まれた。403も404もタイムアウトも、コードから見れば同じ「失敗」だ。だが意味はまるで違う。

自動化された監視は疲れないし休まない。だからこそ、誤った前提で走り出すと、その誤りを全対象に対して一気に、大規模に適用してしまう。人間なら「あれ、全部消えるのはおかしい」と手が止まるところを、ボットは止まらずに75件を書き換える。

監視を作るときは、対象を疑う前に自分を疑うコードを一段入れておけ、というのが今回の教訓だ。