タイムアウトで強制終了したコマンドの、あの中途半端な出力。それが「確認済みの結果」としてAIの要約に記録され、再検証されないまま複数セッションにまたがって伝播していく——そんな不具合パターンを報告する論文を読む。検品文化の続編。
「ターミナルに表示された」ことと「永続化された事実」を混同するメカニズムの構造と、ログ→ローカル実物→本番実物という検品ルールに足すべき、もう1段のチェック項目。
arXivに投稿された論文「Compaction as Epistemic Failure」は、AIコーディングエージェントの長時間セッションで起きる、地味だが厄介な不具合パターンを報告している。タイムアウトで強制終了（exit code 143＝SIGTERM）されたコマンドの、途中までしか出ていない出力が、セッションの要約（compaction）処理を経ると「確認済みの結果」として記録されてしまうという現象だ。
一度この誤った"確認済み"がセッションの要約に紛れ込むと、以降はその要約を前提に会話が進む。要約はさらに要約され、時にはセッションをまたいで、モデルのバージョンが変わった後にまで、検証されないまま生き残ってしまう。
論文が分析するメカニズムを3点に分けて読み解く。
コマンドが強制終了されても、それまでの標準出力はターミナルに表示済みだ。この「表示された文字列」を、要約処理は「コマンドが正常完了して返した結果」と同じ重みで扱ってしまう。
何が起きたかを一言でまとめる要約プロセスは、しばしば「exit code」や「シグナルで強制終了された」という一次情報を省略し、表示されていた文字列だけを残す。成功・失敗の判定材料そのものが消える。
要約は圧縮のたびに、既存の要約を土台にする。最初の要約に紛れ込んだ誤りは、後続の要約生成で「すでに確認済みの前提」として扱われ、誰も元のログに遡って確認し直さない。
ここが核心。ログに文字が出ていることと、そのコマンドが実際に完了して意図した結果を返したことは別の事実だ。要約という圧縮処理は、この2つを区別する情報（exit code・シグナル）を最初に落としやすい。
以前この場で書いた検品文化（ログ→ローカル実物→本番実物の3段階）は、「ログの数字を鵜呑みにしない」ことを軸にしていた。この論文が示すのは、その手前にもう1段あるべきだということだ——検証する前に、そもそもそのコマンドが正常終了したのか、タイムアウトや強制終了で打ち切られたのかを確認するという段階。
具体的には、長時間かかる処理・自動化タスクを実行するたびに、exit code（終了コード）を明示的にログへ残す運用にする。「0以外で終わった」「シグナルで打ち切られた」という情報が要約の材料に含まれていれば、AIが誤って"確認済み"と記録するリスクをその場で断てる。
長時間セッションで自動化・委任タスクを回しているなら、同じ罠が仕込まれている可能性がある。
INCOMPLETE）を出すよう設計する。