監視の項目をあとから増やす——根拠を添えても、4回に3回は異常と決めつけた

これで何ができるか

すでに動いている監視の仕組みに、あとから項目を1つ足す頼み方です。「30日以上更新が無いソースを教えて」のような死活監視を作ったあと、しばらく運用してから「この項目も見たい」と1つ足したくなることがあります。プログラミングは要りません。

このサイト自身が実際に運用しているニュース収集の自動化にも、同じ壁がありました。情報源ごとに「最後に新着が来た日」を記録する仕組みをあとから足したとき、それより前から監視していた古いソースには、その記録がまだ1件も無い状態になります。この記事は「記録が無い＝止まっている」と決めつけずに済ませる頼み方を、架空のログ2本・12回の実測で確かめたものです。

結論から言うと、「判定の根拠も添えてください」という一見丁寧な一言が、逆効果でした。透明性を上げようとした一言が、「便宜上、異常扱いとしました」という説明つきの誤分類を増やしています。効いたのは、根拠を求めることではなく、受け皿を先に用意しておくことだけでした。

前提

• この記事は「監視の仕組みに、あとから項目を1つ足す」場面に絞っています。監視をゼロから設計する場面は自動化が動いているかを、自分で毎朝確かめさせるに、今日ぶんの材料が古いかを見る場面は材料が1日古い日を見張るにあります
• 実測に使ったのは架空の更新監視ログで、実在の会社・サービス名は含みません

AIへの頼み方

1. まず素のまま頼む — 4回中3回は自分から「判定不能」を作った

架空の「更新監視ログ」を、内容の異なる2セット（A・B）用意しました。どちらも15項目で、内訳は同じです。あとから足した「最終更新日」の列がそもそも無い古い項目が5件、その列があって30日以上経っている項目が5件、30日未満の項目が5件です。

まず、指定なしの素朴な頼み方です。

（この指示文の後ろに、監視ログの全15項目をそのまま貼ります。以下の指示文も同じです）

材料2セット×各2回＝4回のうち3回は、聞いてもいないのに「判定不能」「不明」「判定不可」という第三の区分を自分から作りました。列が無い5件をどちらにも押し込まず、こう書いています——「S-01, S-02, S-03, S-04, S-05 は最終更新日の記載がなく、経過日数を算出できないため『正常/異常』の判定ができません」。

ただし、指定なしのまま頼んだ残り1回（材料B・2回目）だけ、まったく同じ指示文・同じ構造の材料で、列が無い5件の全部を「異常」に分類しました。「T-01〜T-05 は『最終更新日』の記載自体がなく、経過日数を確認できないため、安全側の判断として『異常』扱いにしています」と理由まで添えて。異常5件・正常5件の判定は4回とも全問正解でした。

2. 「根拠も添えて」と丁寧にしたら、悪化した

判定に理由も添えさせれば、こちらが目視で気づきやすくなるはずだと考えました。1の指示文に一文だけ足します。

材料2セット×各2回＝4回のうち3回で、列が無い5件の全部が、はっきり「異常」の一覧に入りました。1（無指定）では4回中1回だった誤分類が、この一文を足しただけで4回中3回に増えています。理由の書き方も揃っていました——「最終更新日の記載なし（確認不可のため異常扱い）」「最終更新日そのものがログに記載されていないため、経過日数を算出できず判定不能です。便宜上「異常」扱いとしました」。

残り1回も、実は完全に無事だったわけではありません。「判定不可」という語自体は使いましたが、その直後に「(異常扱い)」と自分で注記しており、実質的には4回とも異常寄りの言葉を使っています。「根拠も添えて」を足した4回のうち、無指定の1（3/4）のように迷いなく別枠へ分けた回は0回でした。

「根拠も書いて」と頼むと、AIは白黒つけない答えを避けて、どちらかに決め切ろうとする側に寄りやすくなるようでした。その決め方が「異常」側に寄ったのが今回の結果です。透明性を上げるつもりの一言が、誤分類を減らすどころか増やしました。

3. 「まだ分からない」の受け皿を、こちらから作っておく

指定なしでも、根拠を添えさせても揺れが残るので、受け皿そのものを明示しました。

材料2セット×各2回＝4回とも、列が無い5件は全件が「まだ分からない」に入り、異常にも正常にも1件も漏れませんでした。異常5件・正常5件の判定も4回とも正解です。

4. 受け皿を明示したうえでなら、根拠を添えさせても・件数を検算させても崩れない

受け皿さえ明示すれば、2で悪化した「根拠も添えて」を足しても大丈夫かも確かめました。

材料2セット×各1回＝2回とも、列が無い5件は全件が「まだ分からない」のままでした。「根拠を添えて」が悪さをするのは、受け皿が無いときだけのようです。

念のため、最後に件数の検算をさせる一文も試しました。

これも材料2セット×各1回＝2回とも全項目正解で、内訳の合計も2回とも15件と正しく書かれました。指示文3・4を合わせた材料2本×計6回・のべ90件を通じて、誤分類は0件でした。

うまくいかないときの言い直し方

公開直後にアラートが急増した

もし受け皿の一文を付け忘れて運用を始め、ある朝だけ古いソースが軒並み異常と報告されたら、まずその朝の返りをそのまま貼って聞き直してください。

先回りして条件を細かく足すより、起きた結果を見せてやり直させるほうが早いというのは、海外の案内を日本時間に直すでも同じでした。先に完璧な指示文を目指すより、まず受け皿の一文を1つ足し、それでも崩れた回だけ個別に貼り直してください。

応用・次の一手

この記事の実測でいちばん確かなのは、「異常」への誤分類だけが不安定で、「正常」への黙った見落としは一度も起きなかったことです。危険な倒れ方は一方向に決まっていました。

そして、「もっと丁寧に頼めば良くなる」とは限りません。「判定の根拠も添えて」という、一見すると誠実さを増すだけの一言が、受け皿が無い状態では誤分類を4回中1回から4回中3回に増やしました。効いたのは丁寧さではなく、「記録が無い項目はどう扱うか」を先にこちらが決めて渡すことだけです。監視項目を1つ足すたびに、古い記録には値が無い確率が上がります。足すたびにこの一文を添えるコストは、4回に3回もの誤爆を防ぐには十分に安いはずです。

⚠️ この実測は、あくまで今回作った架空の更新監視ログ・今回の実測環境での結果です。「AIは古いデータを必ず異常扱いする」という一般化はできません。無指定でも4回に1回は誤分類しない側に振れており、「根拠を添えさせると必ず悪化する」とも言い切れません。ここで確かなのは、受け皿を明示した版だけが12回すべてで0件だったという一点です。監視項目を足すときは、最初からこの一文を添えてください。

📌 この記事の実測は、架空の更新監視ログ2本（各15項目、うち列が無い項目5件）に対して、無指定・根拠を添えさせる・受け皿を明示するの3版を、材料2本×各2回＝12回・のべ180件、機械照合しました。誤って「異常」に分類した件数は、無指定版で20件中5件（4回中1回）、根拠を添えさせた版で20件中15件（4回中3回）、受け皿を明示した版で20件中0件でした。加えて、受け皿を明示した版に「根拠も添えて」「件数を検算して」を重ねた2つの追加確認を材料2本×各1回＝計4回・のべ60件試し、いずれも誤分類0件でした。誤って「正常」に含めた件数は、全16回・のべ240件を通じて0件です。⚠️ 実測に使ったAIは、このセッション内で起動した独立プロセス（claude --safe-mode --tools ""。CLAUDE.md・skills・plugins・履歴を全部無効化し、呼び出しごとに完全に独立しています）です。生の回答と判定コードは docs/evidence/unknown-field-marked-anomaly.md に全文置いてあり、一般化はせず機械で確認できた件数だけを根拠にしています。