弊社は自社の業務の一部を、複数のAIエージェントに無人で運転させています。会議の前日にAIが事前資料を作り、決まった時刻に自己検査（システムが自分の状態を点検する仕組み）を回し、ずれがあれば管制画面に赤で出します。
今回は、9月8日の1日のあいだに機械の見張りを2本足し、その日の午後までに2本とも穴が見つかった記録です。企業名・個人名は出しません。
先に気づいたのは、どちらも人の目だった
発端は2つあります。
1つ目は、会議の事前資料に書かれた曜日です。9月7日、翌日の資料2本が「2026年9月8日（月）」と書いていました。正しくは火曜日です。資料を作るAIが、日付から曜日を自分で計算していたのが原因でした。そこで手順書に「曜日は自分で作らず、渡された値をそのまま貼る」と書き足し、曜日つきの日付を渡す仕組みも作りました。
ところが翌朝、6本中3本がまた「9月8日（月）」と書いていました（自社計測。当日生成された資料の実測）。書いて頼む方式では守られないと、ここで確定しました。
2つ目は、予定の重なりです。同じ9月8日の10時に、相手のいる会議が2件入っていました。気づいたのは9時52分、開始8分前で、それも人がカレンダーを目で見て気づいたものです（実測。実行記録の時刻）。
前の晩、カレンダーの取得が50件で黙って打ち切られていた不具合を直し、予定が248件見えるようになっていました（実測）。機械には重なりが見えていたはずです。それでも止められなかった理由は単純で、自己検査にあった31項目はすべて決裁・実行・資料を見ており、予定そのものの矛盾を見る項目が1つも無かったからです。
1本目：曜日の検査は、ハイフン区切りの日付を素通りしていた
朝6時台に、資料を保存した後で曜日を実際の暦と照合する検査を足しました。足した直後、検査そのものが仕事をするかを確かめるため、退避してあった過去の資料6本に通しました。結果は4本が不合格です。9月8日を「月」とした既知の3本に加えて、それまで誰も気づいていなかった曜日の誤りが3か所見つかりました（実測）。
7時台には一歩進めて、見つけるだけでなく保存後に機械で曜日を書き換える方式にしました。直した件数も毎回出すようにしています。直した件数が1以上なら、「資料は正しくなったが、書き手のAIはまだ手計算している」という意味になるからです。この回の実測は、誤り3件→0件、機械で直した件数3件でした（自社計測）。
穴が見つかったのは13時50分です。実行役のAIが、この件を「実装済み」の申告だけで閉じる前に、試験用の資料を作って当ててみました。「2026年9月8日（月）」の形と「9/6（土）」の形は正しく引っかかり、書き換えも成立しました。しかし「2026-09-08(月)」というハイフン区切りの形だけは、曜日が間違っていても素通りでした。
これは机上の心配ではありませんでした。その日に資料を作ったプログラムのうち2本が、実際にこの形で日付を書いていました（実測）。その日はたまたま曜日が正しかっただけで、間違えていても誰も気づけない状態でした。
直したのは照合の型1本の追加です。再試験は8通りの書き方で全数が期待どおり（誤りのある3形式はすべて不合格、正しい3形式はすべて合格、書き換えも成立）。その日の本物の資料6本を通し直して、誤検出は0件でした（実測）。
翌9月9日朝の本番では、資料3本・誤り0件・機械で直した件数0件でした（自社計測。予約作業の実行結果）。
2本目：重なりの検査は、終わった会議に「重大」を出し続けた
10時25分、自己検査の32項目目として、今日から3日間に相手のいる会議が同じ時刻に2件以上ないかを見る検査を足しました。「作業」「移動」のような相手のいない枠は数えません。開発作業の枠と定例が重なるのは日常なので、それまで赤にすると本物が埋もれるからです。
実装の途中で1つ判断がありました。管制画面の内部からはカレンダーを取りに行けない作りだったため、最初は「画面の中では黙って緑を出す」実装にしていました。しかしそれでは、重なりが社長の見る画面に一生出ません。以前、AIが書いた「次にやること」が1件も読まれていなかったのと同じ道です。そこで、外側の定期実行が測った結果をファイルに置き、画面はそれを読む形に直しました。3時間より古い測定値は緑にせず、「いまの予定を見ていない」と出します。
穴が見つかったのは14時13分です。自己検査がまだ「重大：本日10:00に2件」を出していました。その重なりは10時25分の判断で処理済みで、しかも開始から4時間以上たっています。
原因は、検査が日付だけで範囲を切り、時刻を見ていなかったことでした。過ぎた予定はもう動かせません。 そこで赤を出しても打つ手が無く、赤が常態化して、本物の赤が埋もれます。当日で開始時刻が現在より前の枠を外す3行を足し、14時19分の再実行で重大0件になりました（実測）。
「当日を丸ごと外す」案は捨てました。朝の時点で当日の重なりが見えなくなり、前日までに見つけるという本来の目的より弱くなるからです。
翌日の検証では、カレンダーに実際の重なりが無かったため「合格」とは書きませんでした。代わりに、本物の重なり・除外枠だけ・除外枠と本物の混在・過ぎた枠・3件重なりの5通りを検査に食わせ、5通りとも期待どおりの判定になることを確かめました（実測）。
5日後、初めて本物を拾った
9月13日の朝6時台、本物の重なりが判断台帳に上がり、同じ日の自己検査にも「重大」として出ていました。2日後の9月15日16時に、月1回の顧客との定例と、週次の作業会が同じ時刻に入っていました。台帳に上がったのは開始の約58時間前です（実測。判断記録の時刻）。
調べると、同じ重なりは8月18日にも起きていました。片方が「毎月第3火曜」、もう片方が「毎週」の定例なので、毎月1回、構造的にぶつかる組み合わせでした。
どちらを動かすかは先方への連絡を伴うため、AIは決めずに社長の判断に上げました。9月14日9時04分に回答が返り、9時26分には作業会の側が17時に移っていました。9時46分、AIがカレンダーを取り直して重なりが消えたことを確かめ、この件を閉じています（実測。判断台帳の記録）。
8分前に人が気づいた日から数えて、2日前に機械が気づくところまでは来ました。
残っている穴も書いておく
直した後にも、分かっている穴があります。
- 重なりの検査は、開始時刻がまったく同じ枠しか数えていません。 10時〜11時の会議と10時30分開始の会議は拾いません。これはプログラムを読んで確かめたもので、実例ではまだ実測していません
- 曜日の検査で、ハイフン区切りの日付が本番の資料作成で実際にこの経路を通ったかは、記録が残っておらず未確認です
- 機械で曜日を直した件数の、9月10日以降の推移は追えていません（未確認）
見張りを足すときに決めたこと
この1日から、検査を足すときの手順を3つに固めました。
- 足したら、その検査に落ちるべきものを食わせて、本当に落ちるかを見る。 過去の資料で4本落ちたのも、ハイフン区切りの穴が見つかったのも、この試験をしたからでした
- 「実装済み」の申告で閉じない。 13時50分の穴は、閉じる直前に試験した回で見つかりました
- 消えない赤は、無いのと同じとして扱う。 打つ手の無い警報を出し続ける検査は、本物の警報を読まれなくします
見張りを1本足すことは、見張りが間違える箇所を1つ増やすことでもあります。足した日にまず見張りを疑う。この日の記録で、それを手順に入れました。