弊社は自社の業務の一部を、複数のAIエージェントに無人で運転させています。AIが下した判断は1件ずつ「台帳」に追記されます。台帳は1行1件の追記専用ファイルで、管制画面のボタンも、社長の回答も、通知の送信済みの印も、すべてこの台帳の行を指しています。
その台帳が9月15日の夜に太ってきたので、もう実行することが無くなった判断を1日1回かたづける仕組みを入れました。入れた2分後にそれが走り、その時点から台帳の一覧表示は壊れていました。気づいたのは1時間50分後です。企業名・個人名は出しません。
消さずに「空の印」を残した
かたづける対象は、実行する行為が最初から無い判断です。やらないと決めた却下と、事実を確認しただけの記録の2種類で、さらに「実物の確認待ちではない」「社長への質問が未回答のまま残っていない」「最後に動いてから7日たっている」の3条件を全部満たしたものだけを選びます。
7日という刻みには理由があります。週に1回走る自己改善の工程が、直近7日ぶんの判断を読んで改善案を作るからです。7日より短く刻むと、その工程が読む前に材料が消えます。
ここで行そのものは1行も抜いていません。判断の番号が台帳の行の位置そのものだからです。管制画面で開いたままのページにあるボタンも、回答の書き戻しも、通知済みの印も、全部「上から数えて何行目」で対象を指しています。行を抜くと後ろの番号が全部ずれ、開いたままの画面で押した回答が別の判断に記録されます。
そこで中身だけを別ファイルへ移し、台帳には番号を守るための空の印を残しました。残るのは識別子・時刻・退避済みの印・退避した時刻だけで、判断の中身にあたる項目は持ちません。
9月15日20時22分に仕組みを置き、20時24分37秒に1回目が走って29件が移りました（実測。退避ファイルの記録時刻は29件とも同一）。移った29件の内訳は、承認21件・却下5件・社長判断2件・条件つき承認1件でした（実測）。本日数え直したところ、退避ファイル29行と、台帳に残った空の印29行は、識別子が29件とも一対一で一致しています（実測）。
落ちたのは、唯一なにも絞らずに全部読む場所だった
同じ日の22時14分、判断の一覧を出すコマンドが例外で止まりました。中身を持たない行から、無いはずの項目を取りに行って落ちていました。
本日、退避前のコードのバックアップを今日の台帳に当てて再現しました。結果は、3件を表示した時点で停止、終了コードは1です（自社計測）。台帳には生きた判断が257件あるので、254件がどこにも出ません。直した後の同じコマンドは257件を表示し、終了コードは0でした（実測。台帳286行＝生きた判断257＋空の印29）。
直しは表示側の3行です。中身を持たない行は表示しない、それだけ。台帳のファイルには一切触っていません。空の印を台帳から物理的に消す案も並べましたが、識別子で行を照合している他の処理を壊すおそれがあるので採りませんでした。
皮肉なのは、落ちたのがこのコマンドだったことです。これは無人の工程が使う経路ではありません。予約してある確認作業の手順書に「社長の回答が入っているかを測る」手段として名指しで書いてある、人が手で確かめるための入口です。機械のためのふるまいは全部動いていて、人が確かめに行く窓だけが閉じていました。
機械の側は1件も壊れていなかった
ここが今回いちばん確かめたかったところです。台帳を読むコードは、作業用の一時ファイルを除いて12本あります（実測）。そのうち「退避済み」という概念を書いてあるのは、退避を実装した1本だけです。残る11本は空の印の存在をまったく知りません。
それでも壊れませんでした。理由は、11本が全部「条件で絞ってから読む」作りだったからです。空の印は判断の中身を持たないので、「決まっているか」「実行待ちか」「社長の回答待ちか」「実物の確認待ちか」のどの条件にも合いません。本日、29件の空の印をこの4つの判定に通したところ、29件とも4つすべてで対象外でした（実測）。
画面の側も実際に組み立てて確かめました。管制画面が使う一式を今日その場で作らせ、案件ごとに並ぶ判断カード77件と、時系列397行を数えたところ、中身が空の行は0件でした（実測）。
設計の意図がそのまま効いた、とは言い切れません。絞り込みが結果として安全装置になっていたが正しい言い方です。落ちた1か所は、唯一なにも絞らずに全行を読んでいた場所でした。無人で回す仕組みで安全を作るのは、たいてい「正しく処理する」ではなく「そもそも対象に入らない」のほうだと、今回の実測でわかりました。
過去に公開した「183件」は、台帳だけでは154件に見える
かたづける仕組みには、記事を書く側にとって別の副作用があります。9月9日に弊社が公開した記事で、8日間の判断を183件と数えました。同じ窓（9月2日から9月9日午前11時まで）を本日数え直すと、台帳に残っているのは154件です。退避ファイルの29件を足して、ちょうど183件に戻ります（実測）。
つまり台帳だけを見た人には、過去に公表した数字より29件少なく見えます。記録を片付けると、片付けたことを知らない人には過去が縮んで見える。これは仕組みの不具合ではなく、公表した数字と手元の数え方がずれるという、記録を持つ側の責任の問題です。
対処として、記事の題材を管理している正典に「全期間の件数を数えるときは台帳と退避ファイルの両方を足す」と先に書きました。数字の出どころを1か所に固定していないと、次に数える人（それが半年後の自分でも）が静かに間違えます。
残っている宿題
正直に残しておきます。
第一に、この一覧表示を通す自動試験はありません。台帳まわりの試験はいくつかありますが、今回落ちた表示経路を通すものは無く、今回の穴は試験ではなく人が使って見つかりました。同じ形の穴は、次に「絞らずに全部読む場所」を作ったときにまた出ます。
第二に、9月16日午前0時2分の2回目は退避0件でした（実測）。7日の条件に新しく当てはまる判断が出た日に、空の印はまた増えます。増えたときに何も起きないことは、今日の実測では確かめましたが、将来足すコードについては保証していません。
第三に、退避した中身を人が読み返す導線が今のところありません。移した29件は残っていますが、管制画面からは見えません。見えない記録は無い記録に近づくので、ここは次に手を入れる場所として残しています。