AIエージェントのPASSだけでは学習を証明できない。次の実行を残す5つの記録

• 現在の入力がPASSしたことと、過去の失敗が次の実行を変えたことは別です。
• 最低限残すのは、失敗したbytes、1件の限定した編集、保留データの結果、現在のhash、次回のread statusです。
• 固定版SkillOpt-Sleepのmock実験は、保留評価を0.3333から1.0へ上げ、有害な編集を止めました。
• これは固定されたmockの受入契約のreceiptであり、実運用の品質・収益・知能の向上を測った数字ではありません。

夜間ループのログがPASSで終わった。そこで運用を終えると、翌朝に一つだけ分からないことが残ります。昨日の失敗に合わせた変更を、明日の実行が本当に読んだのか。

対象は、夜間に定型調査エージェントを運用し、前夜の修正が翌朝の入力に読まれた証拠を持てない人です。

PASSだけでは学習を証明できない3つの状態

書き換えは、文書や設定のbytesが変わった状態です。変化が起きたことだけを示します。

現在のPASSは、現在の入力がチェックを通った状態です。そのbytesに対する今回の判定だけを示します。

監査できる学習は、失敗、編集、評価、hash、次回のread receiptを一緒に残した状態です。採用した変更が後の実行へ届いた経路を追えます。

最初の2つしかない段階で、「学習した」と呼ばないことが出発点です。

次の実行へのread receiptを証明する5項目

1. 失敗したbytesを残す

失敗した入力、質問、評価値、または実行後の測定値を保存します。その判定を生んだ文書や設定のbytesも残します。失敗の分類と、それらを結ぶrun identityを加えます。

入力のない評価値は、何を直すための数字だったかを教えてくれません。入力と出力のhashを同じreceiptに置き、失敗の原文を要約で置き換えないようにします。

2. 編集は1件に限定する

追加、削除、置換のどれか1件にします。プロンプト、評価器、データ、ルーターを同じ受入試験で一度に変えません。そうしないと、次の判定がどの変更から生じたのかを記録から切り分けられません。

SkillOptのREADMEは、スキル文書を固定したエージェントの「学習可能な状態」と説明し、保留評価を厳密に改善した候補を受け入れる方法と、却下した編集を残すバッファを説明しています。ここで使う原則は、採否の因果を追える大きさまで編集を狭くすることです。

3. 保留データで再評価する

編集のきっかけになった例だけで再試験しません。編集を作るために使わなかった仕事を、採否の境界に残します。

評価器が判定を返さない、または差がノイズと区別できないなら、結果はunknownです。却下された編集も境界を知る証拠なので、黙って削除しません。

4. hashで記録を結ぶ

次の欄をreceiptの鎖にします。

• failure: 失敗の原文、分類、入力hash
• edit: 変更対象、変更後のbytes、変更hash
• evaluation: 初回と保留評価の結果、タスク版
• decision: 採用、却下、またはunknownと理由
• consume: 次回のrun identity、読み込んだ識別子、current hash、read status

現在のbytesとreceiptのhashが一致しないなら、古いPASSを新しい文書に貼りません。hashは、どのbytesが評価されたかを固定する境界です。

5. 次回のread receiptを必須にする

採用版を台帳へ書くだけでは足りません。次の実行が何を読み込んだかを返します。

```mermaid flowchart TD A[Failure bytes] --> B[Bounded edit] B --> C[Held-out evaluation] C --> D[Current hash] D --> E[Next-run read receipt] C --> F{Accepted?} F -->|No or unknown| G[Keep rejected edit] G --> B ```

read receiptには少なくとも4つ必要です。次回のrun identity、読み込んだファイルや設定の識別子、読み込み時点のcurrent hash、機械判定できるread statusです。評価器がAを通したのに、消費側が古いBを読めば、評価だけPASSして教訓は届きません。