BUILD · Research → story
緑のチェックが、失われた状態を隠す
同じ正しいファイルでも、真の再開、最初からの再実行、説明されない人の救援から生まれうる。出力ハッシュだけでは区別できない。
緑のチェックは到着地点だ。復旧はそこまでの経路である。
この違いは簡単に消える。エージェントが長い仕事の途中でタイムアウトし、後で戻ってきて、要求されたファイルを置く。受け入れテストは通り、宛先のハッシュも一致し、ダッシュボードは緑になる。
しかし、同じ結末は三つの異なる旅から生まれる。信頼できるチェックポイントから再開したのかもしれない。仕事を最初からやり直し、同じ答えを再現したのかもしれない。あるいは、人が失われた状態を静かに修復したのかもしれない。
完成したファイルだけでは、どの旅だったか分からない。
正しい再実行でも、復旧テストには失敗しうる
再実行可能であることには価値がある。読み取り専用の仕事なら、最初から安全にやり直すことが最も単純な運用判断かもしれない。
それでも、状態を保った復旧の証拠にはならない。
六段階の仕事で、四段階目の後にタイムアウトしたとする。再開するシステムは、信頼できるチェックポイントを特定し、すでに確立した仕事を残して、次の有効な境界から続ける。再実行するシステムは、その履歴を捨て、一段階目から四段階目までを繰り返す。最終バイト列は同じになりうる。
状態を守ったのは片方だけだ。
違いは、危険になる前にコストとして現れる。重複作業は、経過時間、呼び出し回数、token、調整量を増やす。OpenAI が紹介した Third Moment Research の事例では、エージェントが長時間のバックテストを繰り返しポーリングし、待つ間に token とコンテキストを消費していた。キャッシュとメモリの変更により、その特定の処理は約三時間から約三〜五分に短縮したと報告されている。普遍的なベンチマークではないが、仕組みは見える。harness がどう記憶し、どう待つかが、仕事のコストを支配しうる。OpenAI: Third Moment Research
外部操作が入ると、この曖昧さは単なる無駄ではなくなる。読み取りの重複は煩わしいだけかもしれない。課金、予約、送信、公開の重複は、二つ目の現実の出来事を作る。だから最初の制御実験は読み取り専用にし、その後の実験では冪等性キーや操作 ID が必要になる。
最終ファイルを軌跡へつなぎ直す
最小限の有効な証拠列には、六つの接続が必要だ。
- 指定された呼び出しで故障が実際に注入された。
- harness が故障を検出し、分類した。
- 特定の再開状態、または最初からの再実行が明示的に選ばれた。
- 副作用台帳が、何も二重に起きていないことを示す。
- 事前に定義した受け入れテストが通った。
- 約束した宛先から読み戻したバイト列が、受け入れ済み成果物と一致する。
緑のチェックが示すのは五番だけだ。宛先からの読み戻しが示すのは六番だけだ。どちらも一番から四番を復元しない。
だから復旧の証拠には、チェックポイント ID と成果物 ID の両方が要る。チェックポイントは、再開前にシステムがどこまでを真実と判断したかを示す。成果物ハッシュは、最後に何が届いたかを示す。その接続がなければ、完璧な出力でも未知の軌跡を隠せる。
OpenAI の評価ガイダンスは、より広い原則を示す。ツール、状態管理、再試行、予算、採点は、すべてテスト対象のシステムの一部である。制御比較では、課題、採点、予算を固定し、harness の選択も報告すべきだ。OpenAI 評価ガイダンス
復旧専用の時計を持つ
次に、双子を作る。
同じ固定済みの読み取り専用タスクを二回実行する。対照群には故障を入れない。処理群には、事前に指定したツール呼び出しで一度だけ決定的なタイムアウトを入れる。入力、モデル、プロンプト、harness、ツール、再試行上限、受け入れ規則、総予算は変えない。
両方を開始から検証済み配達まで測る。処理群では、故障から検出、故障から配達までの時間も測る。
双子の差が、この一組で観測された復旧税である。
復旧税 = 処理群 − 対照群
経過時間、呼び出し、token、直接費用、人が能動的に使った時間は別々に差し引く。救援、通常レビュー、確認、ただ待っていた時間を一つの都合のよい箱に混ぜない。
Microsoft の信頼性ガイダンスは、明確な仮説、エンドツーエンドの復旧目標、限定された影響範囲、ロールバック経路、ベースラインとの比較を勧めている。この双子は、その構造をそのまま与える。Microsoft 信頼性テストガイダンス
一組だけで復旧率は分からない。それでも、測定装置が機能するかを示し、一つの完全な経路を明らかにし、再開、再実行、人の救援を区別できる。統計的な主張には、複数の故障位置と seed で事前定義した反復が必要であり、失敗を分母から消してはならない。
終点だけでなく、経路を検証する
実装は小さい。トレースにチェックポイント ID を加える。副作用には安定した操作 ID を付ける。受け入れ結果を成果物ハッシュに結び、約束した宛先から配達物を読み戻す。
そして、ラベルを正直に保つ。
最初からきれいにやり直したなら「再実行可能」と呼ぶ。人が状態を再構成したなら「人の救援で受け入れ済み」と呼ぶ。検証済みチェックポイントから再開し、重複した副作用がなく、同じ予算内で配達した場合だけ、その一回を「受け入れ済みの自律復旧」と呼ぶ。
最終ファイルは重要だ。ただし、それは最後のノードであって、証拠の全体ではない。
緑のチェックは、到着地点が正しいと示す。
六つの受領証は、システムがどう到着したかを知っていたと示す。