FIELD NOTES 01 · COMPLETION

PR merged is not complete.
AI worker 時代の Completion Contract

1. 問題の定義

人が仕事を引き継ぐとき、「終わりました」の裏には暗黙の確認があります。本番で動いているか、データが残っているか、翌朝も同じ状態か。人はそれを経験で補います。

AI worker にはその暗黙知がありません。AI は「指示された手順を実行し、返事を返す」ことを完了とみなしがちで、その返事は非常に自然に「終わりました」と読めます。すると次の事故が起きます。

• test は通ったが、本番の設定差分で機能が動いていない。
• PR は merge されたが、deploy されていない、または別の環境に deploy されている。
• deploy は成功したが、実際の利用経路（ユーザーが触る画面や外部からの API 呼び出し）では旧バージョンが配信されている。
• 処理は走ったが、結果が永続化されておらず、再起動で消える。
• スケジュールは登録されたが、一度も実行されていない。

どれも「返事」と「exit code」の上では成功です。問題は AI の能力ではなく、何をもって完了とするかが契約になっていないことにあります。

2. よくある弱い実装

共通点は、中間状態を終端状態と誤認していることです。中間状態はすべて「まだ何も証明していない」と扱うのが安全側です。

3. 強い設計原則

原則 1 — 完了は宣言ではなく read-back で決まる

完了を判定するのは、仕事をした worker 本人ではなく、独立した読み戻しです。同じ worker が「確認しました」と言っても、それは主張の重複にすぎません。別の経路（外部 URL、別プロセス、別アカウント）から実 system を読み、期待値と照合します。

原則 2 — 受入条件は着手前に書く

「何が読み戻せたら完了か」を依頼時に決めます。後から決めると、出来上がったものに合わせて条件が緩みます。受入条件には、対象の system、確認する経路、期待する値、確認する時刻（deploy 直後・キャッシュ期限後・再起動後）を含めます。

原則 3 — 中間状態を終端と混同しない

test、review、merge、deploy、"成功" 表示は、それぞれ次の段階へ進む条件であって完了ではありません。段階ごとに「通過した証拠」を残しつつ、完了の判定は最後の read-back にだけ与えます。

原則 4 — 永続化と再起動耐性を完了に含める

結果が残っていること、そして controlled restart の後にも同じ結果が読み戻せることを確認して初めて、業務として完了です。メモリ上の状態、一時ファイル、別プロセスのバッファに残った「成功」は完了に数えません。

原則 5 — 失敗理由も成果物である

完了できなかったとき、どの段階で、何が期待と違ったかを、次の worker（人でも AI でも）が読める形で残します。「失敗しました」だけの報告は、返事だけの「成功」と同じ欠陥です。

4. Architecture — Completion Contract の形

Strassen では、一つの依頼を次の段階に分けて扱います。各段階は「通過」の証拠を残し、完了は最後の段階でだけ宣言できます。

1. Intent / Work Contract目的・scope・受入条件・権限・成果物を、着手前に文章にする。
2. Talent & Route誰が、どの runtime で、どの権限で実行するかを決め、実行直前に exact process を確認する。
3. Execution実 system への作用。test / review / merge / deploy はここに含まれる「中間状態」。
4. Intermediate — ここで止めないtest green、PR merged、deploy success はいずれも完了ではない。証拠として記録するだけ。
5. Result / Artifact成果物と実行記録（何を、どの version で、いつ、どこへ）を残す。
6. Independent Verificationworker 本人ではない経路で、実利用経路の outcome を読み戻し、受入条件と照合する。
7. Persistence結果が永続化先に書かれていることを確認する。
8. Controlled Restart → Read-back再起動（またはキャッシュ期限経過）後に同じ結果が読み戻せて、初めて VERIFIED COMPLETE。

5. Implementation checklist

自社の AI worker 運用に Completion Contract を入れるときの最小チェックリストです。

• 依頼ごとに、受入条件（system・経路・期待値・確認時刻）が着手前に書かれている。
• 完了を判定する read-back が、実行した worker と別の経路で行われる。
• deploy 後に、外部利用経路から served 内容（例: HTML のハッシュ、API の応答）を候補 version と照合している。
• キャッシュ・CDN・複数環境がある場合、期限経過後または purge 後に再確認している。
• 結果の永続化先が明示され、再起動後に読み戻す手順が決まっている。
• スケジュール実行は、登録ではなく occurrence / run / artifact / retry の記録で完了を判定している。
• 失敗時に、どの段階で何が違ったかが、次の担当が読める形で残る。
• 完了報告に、実施済み・未実施・既知の制約・version・検証時刻が分けて書かれている。

6. Evaluation metrics

Completion Contract が機能しているかは、次の指標で観測できます。Strassen ではこれらを標準的に測定する指標としていますが、このページに実績値は掲載していません。

• Verified completion rate — 完了宣言のうち、独立 read-back で確認できた割合。
• False-complete rate — 「完了」と報告されたが read-back で不一致だった割合。最も重要な指標。
• Restart durability pass rate — 再起動後の read-back が一致した割合。
• Time to verified completion — 依頼から VERIFIED COMPLETE までの時間（deploy 成功までではない）。
• Cost per verified completion — token 単価ではなく、検証済み成果 1 件あたりの総コスト。

7. Security considerations

• read-back の経路は最小権限で。検証は読み取り専用の経路で行い、検証用の権限で書き込みができないようにする。
• 検証結果を worker に上書きさせない。完了判定の記録は worker 本人が編集できない台帳に残す。
• 「成功」の偽装を前提にする。返事の文面や exit code を信用せず、system の状態だけを根拠にする。
• 受入条件そのものを保護する。着手後に受入条件を緩める変更は、依頼者の承認を必要とする。

8. FAQ