COLUMN 技術コラム

エラーも出ず、ログにも残らず、ただ静かに止まる。「動いているように見えて動いていない」障害はアラートを待っても見つからない——AIラボの実測で分かった沈黙故障の正体と、監視設計そのものを点検する方法を解説します。

今日、私たちのAIラボは、15分間まったく何も起きていないことに気づかなかった。

10件の作業をAIの担当者たちに割り当てた。管理画面には「担当者：割り当て済み」と表示されている。誰が何をやるかは決まっている。あとは順に片づいていくはずだった。

15分後に中身を確認したところ、1件も着手されていなかった。

エラーは出ていない。ログにも何も残っていない。管理画面は正常そのもので、10件すべてが「割り当て済み」と表示され続けていた。実際、記録を見ると作成時刻と最終更新時刻が1秒も違わなかった。誰も触っていない。

原因は単純だった。作業を「待機列」に入れただけで、実行の合図を出していなかった。仕様上そうなっていた。だが問題は、その状態が「正常」と見分けがつかなかったことにある。

なぜ沈黙故障は見つからないのか

障害には二種類ある。鳴るものと、鳴らないものだ。

鳴る障害は、実は扱いやすい。アラートが飛び、担当者が動き、復旧し、報告書が残る。手順が回る。

厄介なのは後者だ。監視の設定から漏れている、あるいは「動いているように見えて止まっている」種類の不具合は、アラートを待っていても永久に気づけない。鳴らないのだから、当然だ。

そして人は、鳴らないことを「異常がない証拠」だと解釈してしまう。設定した瞬間に安心し、「これは本当に鳴るのか」を確かめない。

私たちのラボは1日でこれを6回踏んだ。

• 担当を割り当てたのに動いていなかった（冒頭の話）
• AIが仕事を終えたのに、その結果を人に届ける経路が存在しなかった。作業は完了しているのに、誰も知らないまま溜まっていた
• AIの成果物が一時的な作業領域に書き込まれていた。保存したつもりで、消える寸前だった（4回）
• AIが一度も実行しないまま「この道具は使えない」と判定を出した。報告書の体裁は完璧で、採点表も結論も揃っていた
• 判断を伴う仕事を、軽量な処理向けの担当に流していた。結果、実測していない効果を「60%削減」と断定する報告が出た
• 費用を集計していたつもりが、同じ記録を二重に数えていた

いずれも、警告は一度も出ていない。

もっと怖い話——「測れているつもり」

最後の一件が、いちばん背筋が寒くなった。

AIの稼働費用を集計するスクリプトを書き、1日あたりの金額を出した。数字はきれいに出た。表も整った。その金額を前提に、商品の値付けを検討しはじめていた。

ところが実測ログを数えると、記録2,282行のうち1,095行が同じ内容の重複だった。48%を二重に数えていたことになる。修正すると金額は3分の1以下になった。

もし気づかなければ、実際の3倍近い原価を前提に値段を決めていた。そしてその誤りは、どこにも警告として現れなかった。スクリプトは最後まで正常に動作していたのだから。

「測れている」と「正しく測れている」は違う。そして両者は、画面上ではまったく同じ顔をしている。

ラボの答え——データではなく、設計を疑う

ここから導かれる結論は、直感に反する。

沈黙故障は、監視の頻度を上げても見つからない。

当たり前だ。見るべき信号が存在しないのだから、1時間おきに見ようが1分おきに見ようが、見えないものは見えない。監視を強化するという発想そのものが、この問題には効かない。

見つける方法はひとつしかない。監視設定そのものを、定期的に点検することだ。

私たちは週に一度、こう問い直すことにした。

1. この項目は、どういう状態になったら鳴るのか
2. その状態に、実際にしてみたら鳴るのか
3. 鳴ってほしいのに、監視項目がそもそも存在しないものは何か

3つ目が本丸だ。既存の監視項目をいくら眺めても、そこに無いものは見えない。「何を見ていないか」は、一覧を見ても分からない。業務の流れを追って、「ここが静かに壊れたら誰が気づくのか」と一箇所ずつ問うしかない。

地味な作業だ。だが、この点検で見つかるものは、アラートでは一生見つからない。

数字で言うと

• 沈黙故障の検出件数：1日で6件（いずれもエラー表示・警告ゼロ）
• 気づくまでの時間：最短15分、最長は2日以上（誰も見ていない場所に成果物が溜まっていた件）
• 費用集計の誤差：48%の二重計上（修正前後で金額は3分の1以下に）
• これらのうち、既存の監視・警告の仕組みが教えてくれたもの：0件

最後の行が、この記事で一番言いたいことだ。

動かす設計と、鳴らないことを確かめる設計は別物

システムを組むとき、私たちは「動くこと」に集中する。動いたら監視をつける。監視をつけたら安心する。

だが監視をつけた瞬間に生まれるのが、「鳴らないから正常だ」という思い込みだ。そしてこの思い込みは、鳴らない限り訂正されない。永久に。

止まったことに気づける仕組みと、気づけないことに気づく仕組みは、別々に作る必要がある。前者は監視ツールの仕事だが、後者は設計を疑う人間（あるいはAI）の仕事だ。

もし気になったら、御社の監視設定を一度棚卸ししてみてほしい。「これは、どうなったら鳴るのか」を一項目ずつ確かめるだけでいい。一つも見つからなければ、それは素晴らしいことだ。

よくある質問

Q. 監視ツールを高機能なものに替えれば解決しますか。
A. 解決しません。沈黙故障は「監視項目が存在しない」ことから生まれるため、ツールの性能ではなく設計の網羅性の問題です。高機能なツールでも、設定していない項目は鳴りません。

Q. どのくらいの頻度で点検すべきですか。
A. 私たちは週1回で運用しています。沈黙故障は急に増えるものではなく、変更のたびに少しずつ溜まるため、高頻度である必要はありません。むしろシステム変更・機能追加の直後に必ず行うことが重要です。

Q. AIを使えば自動で見つけられますか。
A. 部分的には可能ですが、AI自身も沈黙故障を起こします。本記事の6件はすべて、AIを使った自動化の内部で起きたものです。自動化を増やすほど「動いているように見えて動いていない」箇所は増えるため、点検の必要性はむしろ高まります。

Q. 自社でやる場合、どこから手をつければいいですか。
A. 「この処理が静かに止まったら、誰がいつ気づくか」を、主要な業務の流れごとに1つずつ書き出すことをお勧めします。答えられない箇所が、そのまま沈黙故障の候補です。