弊社は自社の業務の一部を、複数のAIエージェントに無人で運転させています。誰が何を決めたかは判断台帳（決裁を1行1件で積むファイル）に残し、そのうち「まだ実行が終わっていないもの」を一覧に出して、終わったものから順に閉じていきます。
閉じるときは番号で指定します。--done 376 と打つと、376番のカードに実行済みの判子が押される。単純な仕組みです。
2026-09-20、その番号が1つずれました。閉じたのは動作確認用に作った行ではなく、実在する案件のカードでした。エラーは出ていません。企業名・個人名は出しませんが、起きたことと数字はそのまま出します。
一覧の中に、番号を出していない区分が1つだけあった
一覧は区分ごとに分かれています。「冷却期間で待機中」「次の指示書に載るもの」「申告はあるが実物未確認」「別カード待ちで保留」「機械が実行できる実行待ち」「回答は出たが社長本人しか実行できないもの」の6つです。
このうち5つ目までは、行の末尾に --done 376 のような番号つきの打ち方が印字されていました。6つ目だけ、番号が1つも出ていませんでした（コードの当該行を実測・自社計測）。
番号が無い一覧を前にして、閉じたい人間や機械が取れる手段は1つしかありません。画面の並び順を数えることです。 1行目を1番、2行目を2番と数える。その数え方が、そのまま事故になりました。
数え方が1つずれて、別のカードが閉じた
2026-09-20の工程で、台帳のファイルを直接読んで行を数え、その番号で閉じにいきました。台帳を1行目＝1番と数えたのに対し、ツール側の番号は0から始まっていました。1つずれます。
結果は2件です。動作確認のために作った「押して通るかを確かめるためだけの行」を閉じるつもりで打った番号は、その隣にあった実在案件のカードを閉じました。もう1件は、ある案件のカードを保留にするつもりで打った番号が、別の案件のカードを保留にしました。どちらも状態ファイルを手で直して復旧しています。
ずれた番号も実在するので、エラーは出ません。 存在しない番号を打てば「その番号はありません」と止まりますが、1つ隣は必ず存在します。静かに別のカードへ書き込まれて、画面は何事もなかったように更新されます。
余談ですが、閉じたかった動作確認用の行は、その本文に「通ったら決裁を取り消して消します」と自分で書いてあります。2026-09-22時点で、その行は取り消されておらず、実行済みにもなっていません（実測）。消すつもりだった行は残り、消すつもりのなかったカードが閉じられたという、そのままの結果になりました。
ずれても止まらない作りだった
今日、コードと台帳を当て直して測りました（2026-09-22・自社計測）。
閉じる指定は、渡された番号の行が存在するかどうかだけを見ています。台帳は409行あるので、409通りの番号が全部そのまま受理されます。 そのうち、いま正当に閉じられる状態にあるのは19件（機械が実行できる2件＋社長本人の手番17件）だけです。残りの390通りは、エラーも警告も出さずに別の行へ着弾します。
着弾先は空欄ではありません。台帳の409行のうち278行は既に実行済みで、279行には実行時のメモが入っています。閉じる処理はこのメモを条件なしで上書きします（コード確認）。つまり、他人が残した実行記録を、間違った番号ひとつで黙って塗り替えられる状態でした。
保留の指定だけは、事前に「指示書に載っているか」の関門を持っています。ただし今日の実測で、409行のうち299行がこの関門を通ります。9月20日にずれた先も、たまたまこの関門を通る正当な待ちカードでした。関門はあったのに、隣が同じ資格を持っていたので止まらなかったわけです。
今日同じ間違いをすると、どこへ着弾するか
番号が出るようになった今の画面で、あらためて測りました。社長本人の手番の区分に並んでいるのは17件で、番号は 100 / 203 / 204 / 219 / 264 / 270 / 275 / 312 / 319 / 356 / 372 / 373 / 374 / 385 / 386 / 388 / 391 です。
並び順（1行目＝1番）と番号が一致する行は 0件／17件。0から数え直しても 0件／17件 でした。画面を数えて指定した場合、17件すべてが別のカードに当たります。
その17通りの着弾先も見ました。1番から17番はすべて2026-09-02に積まれた古い行で、うち16行は既に閉じています。16行が持っている実行メモは合計1,446字。そして、この17行のうち、実測の手順を要求する「確認待ち」へ迂回するものは0件でした。16行分の記録が、確認を挟まずにそのまま上書きされるという意味です。
直したのは9行
2026-09-21の夕方、番号が出ていなかった区分に番号を出しました。変更はコメント5行と印字1か所だけ、差分にして9行です。なぜ出すのかを、9月20日の実害つきでコードに書き残しました。バックアップは同日付で取っています。
再実行して確かめたところ、17件すべてに番号が出ました。出てきた番号が 100、203、204…と並び順とまったく違っていたことが、そのまま裏付けになりました。この画面を数えて閉じていた者は、確実に別のカードを閉じていたということです。
誤爆の痕跡は、台帳に残っていない
ここは正直に書きます。
誤って閉じられた2件は、その後まもなく正当な手順で閉じ直されました。台帳に今残っているのは、19:43と19:46に押された真っ当な実行記録だけです。誤爆の瞬間の値は上書きされて残っていません。
台帳の控えは9月5日・7日・8日・15日・20日22時・21日・22日朝の7本ありますが、誤爆（18時台）と閉じ直し（19時台）の間に取られたものは1本もありません（実測）。つまり何がどう壊れていたかを後から読み返せる場所は、決裁カードに書かれた文章だけです。機械が読める形の記録は残っていません。
まだ埋まっていない穴
- 番号を出していない区分が、まだ2つある。 「待機中」と「次の指示書に載るもの」は今も番号なしです。今日の時点でそれぞれ4件と0件。件数が少ないだけで、構造は直っていません
- 自動試験は0件。 試験用のファイルは6本あり、うち2本はこの一覧のコードを読み込んでいますが、番号の表示や着弾先を確かめている行は1つもありません（実測）
- 上書きを止める関門は入っていない。 閉じる指定は今も「行が存在するか」だけを見ます。既に閉じた行を再度閉じられることも、メモが上書きされることも、そのままです
- 過去にどれだけずれたかは数えられない。 痕跡が残らない作りなので、9月20日の2件以外にあったかどうかを機械で数える手段がありません
ここから持ち帰れること
無人運転の仕組みでいちばん静かに壊れるのは、「どれを指したか」の受け渡しです。
弊社はこの型の事故を2回踏んでいます。1回目は9月3日で、行を時刻で照合していたために同じ時刻の隣の行にも判子が押されました。その対策として行番号で1行だけを狙う形に変えた結果、今度は数え始めの位置が1つずれました。同一性の取り方を変えると、誤り方の形が変わるだけで、誤りが消えるわけではありません。
そして実務的な結論は、拍子抜けするほど単純です。人や機械に選ばせる一覧には、必ず識別子を印字すること。 出していない列が1つあると、そこだけは必ず誰かが並び順で数えます。数えられた瞬間に、その一覧は「表示」ではなく「入力」になります。
次は、番号の出ていない残り2区分に番号を足したあとで、閉じる指定に「その行は本当に閉じられる状態か」の関門を入れます。入れたあとに、同じ409行で何通りが受理されるかを測り直して出します。