弊社は自社の業務の一部を、複数のAIエージェントに無人で運転させています。そのうち1体は「判断役」で、1日5回の定時に、自己検査の結果や未処理の案件を読んで決裁を出します。決裁は判断台帳（1行1件で積むファイル）に残り、実行役のAIがそれを拾って手を動かします。
2026-09-23の朝から09-25の夜までの64時間で、判断役は同じ1件の警報について7枚の決裁カードを立てました。結論は「直さない」から始まり、「待つ」「直す」「直した・待つ」と入れ替わりながら、最後は初日とほぼ同じ「待つ」に戻っています。どれか1枚が間違っていたわけではありません。企業名・個人名は出しませんが、起きたことと数字はそのまま出します。
警報の中身は「宣言したモデルと、実際に動いたモデルが違う」
弊社のエージェントは、それぞれの定義ファイルに「どのAIモデルで動くか」を宣言しています。調査担当のエージェントは、機械的な調べものが中心なので、上位モデルより軽い中位モデルで動かすと宣言していました。
自己検査の中に、この宣言と実体を突き合わせる項目があります。直近14日の利用記録を担当ごとに集計し、出力トークン量がいちばん多かったモデルを「実体」とみなして、宣言と違えば注意を出します。トークンとは、AIが文章を処理するときの最小単位で、利用料の数え方の基準です。
9月23日時点で、調査担当の直近14日の記録は2件でした（自社計測・利用記録テーブルの実測）。
- 9月14日：上位モデルで 188,747 トークン
- 9月21日：宣言どおりの中位モデルで 74,678 トークン
9月14日の大きな1回が、9月21日の宣言どおりの1回を量で押し切ったため、「宣言は中位／実体は上位」という注意が出ていました。その後9月24日にも中位モデルで 11,039 トークンの実行が1回ありましたが、合計しても 85,717 で、まだ9月14日の1回に届きません（実測）。
つまり直近の実行は宣言どおりに動いているのに、14日の窓に古い1回が残っている間は警報が消えない、という状態です。9月14日の行が窓から落ちるのは9月28日の夕方です。
7枚の決裁は、こう入れ替わった
判断役が立てた7枚を時刻順に並べます（判断台帳の実測）。
- 9/23 06:23 却下「直さない。古い1回分の残像で、9/28に自然に消える」
- 9/23 14:24 条件つき承認「9/28まで待ち、消えなければ起動側を直す」→ 9/28に確認する予約作業を設置
- 9/23 18:21 承認「起動側がモデルを指定しておらず、呼び出し元の上位モデルを引き継いでいた。指定を足す」→ 指示書に1行足して実行済み
- 9/23 22:19 承認「起動側は直した。残りは窓の中の過去分。窓明けを待つ」
- 9/25 14:20 承認「起動モデルを宣言どおり中位に戻す」→ 9/21・9/24が中位だったことを確かめ、9/29に再測定する予約作業を設置
- 9/25 18:18 承認「宣言に実体を合わせる。起動側を直す」
- 9/25 22:18 承認「是正済み。追加改修なし。窓明けを待つ」
1枚目と3枚目は、結論だけを見れば正反対です。1枚目は「直近は宣言どおりなので、起動側が壊れているとは言えない」と判断し、3枚目は「起動側の指示書にモデルの指定が無かった」という事実を見つけて直しました。どちらの記述も、その時点で確かめた事実としては正しいものです。ただし、9月21日の実行は指定を足す前の時点で既に中位モデルで動いていたので、3枚目の修正が実際にどれだけ効いたのかは、この記録からは切り分けられません。
実行まで進んだのは7枚中3枚です。残りの4枚は、前のカードと同じ結論を別の言葉で書き直したものでした。
64時間のうち、定時判断15回中7回がこの件だった
判断役の定時は1日5回です。9月23日の朝から9月25日の夜までに定時判断は15回あり、そのうち7回がこの1件の警報にカードを立てていました（判断台帳の時刻から実測）。同じ期間に判断役が立てたカードは全部で48枚なので、7枚は約15%にあたります（実測）。
偏り方にも形があります。9月23日は5回中4回、9月24日は0回、9月25日は5回中3回でした。9月24日に1枚も出なかった理由は、台帳の記録からは読み取れません。少なくとも警報が消えていたわけではありません。警報はこの記事を書いている9月26日の自己検査でも、まだ「注意」のまま出ています。
副作用は台帳の外にも残りました。同じ確認のための予約作業が2本、9月28日朝と9月29日朝に並んでいます。2枚目と5枚目のカードが、それぞれ別に「窓明けを確かめる」予約を置いたからです。
重複を止める網は、入れた翌日にもう素通りした
同じ操作が二重に走るのを防ぐ網は、ちょうどこの期間に入ったばかりでした。9月6日に、ある予約の操作が別々の3行として台帳に積まれ、二重に実行しかけた事故があり、その対策として9月24日に「同じ操作を1日以内に2回立てたら、2回目は受け付けない」仕組みを入れています。
網が「同じ操作」かどうかを決める鍵は、出どころ・案件・結論・題名・本文の5つを繋いだものです。時刻と書き手は鍵に入れていません。 同じ判断を別の回が同じ文面で立て直したら、それは同じ操作だ、という考え方です。
5枚目・6枚目・7枚目は、この網が入った後に立ったカードで、3枚とも鍵を持っています。そして鍵は3枚ともばらばらでした（台帳の実測）。題名が「起動モデルを宣言どおりに戻す」「宣言に実体を合わせる」「是正済み・窓明け待ち」と少しずつ違い、本文も違うからです。
網は正しく動いています。文字が1文字でも違えば別の操作とみなす、という設計どおりです。AIが書き直す文面は、中身が同じでも毎回少しずつ違います。 文字列の一致で重複を止める網は、機械が機械的に同じ文を打ち直す事故には効きますが、AIが同じ判断を言い換えて立て直す事故には構造的に効きません。
なぜ同じ判断が何度も立ち直るのか
原因は1つで、警報の側に「対応済み・待ち」という状態が無いことです。
自己検査は、見るたびに「宣言と実体がずれている」とだけ報告します。そのずれに対して、既に誰かが直したのか、直したうえで窓明けを待っているのか、まだ誰も見ていないのかは、警報の中には書かれていません。判断役は定時のたびに、真っ新な警報を受け取ることになります。
判断役は毎回、利用記録を開き直して、正しく「古い1回が残っているだけ」と結論します。調べ方は丁寧で、結論も毎回おおむね正しい。正しい判断を、前の判断を知らないまま繰り返しているのが7枚の正体です。
これは人間の組織でもよく見る形です。同じ問い合わせに、担当が変わるたびに一から調べて同じ回答を返す。記録が残っていないのではなく、問い合わせ票の側に「回答済み・様子見中」の欄が無いので、次に見た人がそれを知る手段が無い。弊社の場合、見る人が1日5回入れ替わるAIだったので、3日で7回になりました。
まだ埋まっていない穴
- 警報に「対応済み・待ち」の状態を持たせる仕組みは、まだ無い。 今日の時点で、この警報は9月28日の夕方まで出続けます。それまでの定時判断で、同じカードがまた立つ可能性は残っています
- 重複の網は、言い換えには効かないまま。 鍵を「案件×警報の種類」のような粗い単位に変えれば止まりますが、今度は本当に別の判断まで止めてしまう恐れがあり、どこで線を引くかは決めていません
- 予約作業は2本のまま。 どちらを消すかの判断はしておらず、9月28日と29日に同じ確認が2回走る見込みです
- 3枚目の修正の効果は未実測。 修正前から中位モデルで動いていた実行があるため、修正の有無で差が出たかは、窓が明けた後の実行を見ないと分かりません
ここから持ち帰れること
AIに定期的に判断させる仕組みを作ると、判断の質より先に、判断の「重なり」が問題になります。 1回ごとの判断は正しくても、前の判断を知らずに同じ結論を何度も出していれば、台帳は埋まり、予約は重なり、本当に見るべきカードが埋もれます。
実務的な結論は2つです。
1つ目は、警報やタスクの側に「誰かが手を付けた」印を持たせること。 判断する側に記憶を持たせるより、判断の材料の側に状態を書き込むほうが確実です。材料を見た瞬間に「これは待ち」と分かれば、同じ調査は始まりません。
2つ目は、重複の判定を文字列の一致だけに任せないこと。 人が書いた文章なら同じ中身はほぼ同じ文面になりますが、AIは同じ中身を毎回違う言葉で書きます。何をもって「同じ件」とするかは、文面ではなく、何に対する判断なのかで決める必要があります。
次は、9月28日の夕方に窓が明けた後、警報が本当に消えたかと、それまでに同じ件のカードが何枚増えたかを数えて出します。