Codex 中心の開発を、検証済み変更の配送システムにする

最終更新: 2026-08-01

この章の役割

Codex は実装速度を上げられる。しかし個人開発者が収益を得るために必要なのは、生成したコード量ではなく、顧客価値を増やし、許容できない事故を増やさず、問題があれば戻せる変更である。

既存章との正本境界は次のとおり。

Web アーキテクチャ、テスト、CI/CD、SLO、AI 実装・eval: 05 章
脅威、プライバシー、供給網、法務: 06 章
顧客仮説、実験、週次判断、決定ログ: 07 章
創業者時間、完全負荷後貢献、個人キャパシティ: 09 章
配信経路、agent 委任、権限昇格、責任境界: 10 章
AI 機能の品質、完全負荷後原価、顧客価値、継続: 12 章
paid job、標準範囲、例外から製品化候補を選ぶ運用: 14 章
変更単位のコピー用書式: Codex delivery kit

本章は、それらを一件の変更について 意図 → 判断 → 実装 → 検証 → review → release → 本番観測 へ接続する。

先に結論

管理単位は prompt、chat、commit、PR のどれか一つではなく、顧客または運用上の一成果を表す change_id にする。
Codex の完了報告は証拠ではない。固定した受入条件、exact commit、実行コマンド、結果、review、release、観測を証拠にする。
永続規則は AGENTS.md、機械的な共有ゲートは test/lint/CI、作業固有の意図は task brief、重要判断は ADR に置く。
実装した agent と別の reviewer agent を使っても、完全な独立検証にはならない。決定的テスト、外部仕様、実ユーザー観測、人のリスク受容を残す。
管理強度は変更量ではなく、影響、可逆性、検知可能性、秘密・権限・金銭・顧客データへの接触で決める。
STOP > PAUSE > UNKNOWN > SHIP を veto 付きで判定する。証拠がない状態を合格へ読み替えない。
release は終点ではない。露出、価値、事故の観測期限を置き、成熟後に続行・変更・rollback を決める。

開発は創業者時間の資本配分である

個人開発では、実装時間だけでなく、調査、review、運用、問い合わせ、復旧も希少な創業者時間を使う。変更の期待値を、厳密な予測ではなく比較用の範囲として考える。

変更の期待純価値
= 採用確率 × 追加の完全負荷後貢献
+ 意思決定に得られる情報価値
- 実装・review・移行・運用の創業者時間価値
- 追加の変動費
- 事故の発生確率 × 影響額の範囲

入力が不確かなら一点推計を作らず、低・基準・高の範囲と最大損失を書く。価値が小さく可逆なら軽い証拠で早く試し、最大損失が大きい変更は、コードを書く前に範囲を狭める。

AI が短縮するのは主にコード生成・探索時間である。顧客の支払意思、受入条件、法的責任、production release、残余リスクの受容まで自動的に正しくなるわけではない。速く生成できるほど、価値の薄い変更を大量に作る機会費用も増える。

変更証拠のグラフ

一件の変更 bundle は同じ change_id で次をつなぐ。incident は原因未確定でも別の response change_id を発行し、originating change/release を参照する。

顧客・障害・実験の証拠
          ↓
TASK: 意図、非対象、受入条件、risk tier
          ├── ADR: 重要な選択と結果
          ├── TM: 脅威差分と残余リスク
          └── EVAL: case、oracle、結果
                    ↓
PR: exact SHA の差分と証拠対応
                    ↓
REL: artifact、移行、露出、rollback
                    ↓
本番観測 ──→ 続行 / 変更 / rollback / 事故検知
                               ↓
                       INC(response change_id)
                               ↓
                       AGENTS・test・runbook 更新

ファイルを作ること自体が目的ではない。判断に影響しない書式は省き、影響する事実を chat の中だけに残さない。

共通識別子

最低限、同じ変更 bundle の全書式に change_id / risk_tier / evidence_as_of / decision_state / owner を持たせる。commit、artifact、config が存在する証拠では、それぞれの full fingerprint も持たせる。該当しない書式へ偽の digest を作らず、N/A — 理由 とする。

項目	意味
`change_id`	顧客または運用上の一成果。例 `CHG-20260801-billing-grace`
`risk_tier`	変更量でなく最大影響と可逆性による `R0`〜`R3`
`evidence_as_of`	どの時点までの証拠か
`commit_sha`	review・test 対象の exact commit。実装前の判断は `N/A — 理由`
`artifact_digest`	production へ出す build がある場合の固定 fingerprint
`config_versions`	該当する schema、prompt、model、policy、feature flag 等
`decision_state`	`STOP / PAUSE / UNKNOWN / SHIP`
`owner`	判断・release・rollback の責任者

文書の draft / active / superseded と出荷判断を混ぜない。完成した文書でも判断は STOP になり得る。

Codex の各面へ責任を置き分ける

OpenAI の Codex best practices は、作業 prompt に Goal、Context、Constraints、Done when を含め、永続的なリポジトリ規則を AGENTS.md に置き、test と review まで行うことを勧めている。Codex best practices

面	置くもの	置かないもの
prompt / task	今回の成果、対象、非対象、入力、期限	全 repo に永続する規則
`AGENTS.md`	正確な command、repo invariant、verification、review rules	一時的な要件、長い背景資料、秘密
nested `AGENTS.md`	その subtree 固有の command と invariant	repo 全体の重複コピー
`.codex/config.toml`	trusted repo の実行・tool 設定	顧客要件や設計判断
skill	反復可能な作業方法	live data や認可の強制
MCP / connector	変動する外部データと認可された action	永続的な業務判断の代替
hook	agent lifecycle 内の補助検査	共有 CI の唯一の代替
test / lint / CI	決定的に検査できる共有 gate	曖昧な事業判断
automation	手順が安定した後の schedule	まだ人の補正を要する workflow

Codex は global から project root、作業 directory まで AGENTS.md を連結し、近い instruction を後から適用する。root は共通 invariant、nested は局所差分にする。規則が大きすぎると重要情報が埋もれるため、実行可能で短い規則と参照文書へ分ける。Custom instructions with AGENTS.md

instruction と hard gate を分ける

AGENTS.md は agent へ期待を伝える interface であり、認可や branch protection そのものではない。

書式、型、生成物の同期: formatter、typecheck、codegen check
tenant scope、状態遷移、課金冪等性: test、DB constraint、policy
秘密・依存脆弱性: secret/dependency scan
build・migration・artifact: CI と deploy gate
production write: server-side authorization と人の release 権限

Codex の custom review rules は、diff だけでは分からない互換性・データ境界を root または nested AGENTS.md に置ける。ただし機械的な検査は CI に残し、rule には 何が不変か / どこに適用するか / 安全な代替 を書く。Custom Code Review rules for Codex

Risk tier を先に決める

R0 — 挙動を変えない

例: 誤字、内部メモ、生成物でない説明だけ。

必要証拠: task、diff review、リンク・format 等の該当検査。

R1 — 可逆で限定された挙動

例: feature flag 配下の UI、低影響な集計表示、内部 refactor。

必要証拠: 受入条件、該当 test、preview、主要失敗状態、基本 release/rollback。

R2 — 重要な業務・信頼境界

例: 認証・認可、tenant、課金、個人情報、schema migration、外部 write、重要依存、AI の tool action、顧客向け API。

必要証拠: task、必要な ADR、脅威差分、negative test、eval、独立 review、観測、検証済み rollback、人の明示承認。

R3 — 高損害・不可逆・規制判断

例: 人身・医療・雇用・信用等の判断、資金移動、広範な削除、秘密の一括出力、戻せない migration、法的通知を伴い得る変更。

個人の agent workflow だけで自律出荷しない。専門家または権限者の review、段階的露出、代替手段、残余リスク受容が用意できなければ範囲を縮小するか作らない。

tier を上げる trigger

新しい trust boundary、データ分類、権限、tenant 間経路
金銭、契約、外部送信、公開、削除
新しい production dependency、build action、秘密
schema/backfill または旧 client 互換性
model、prompt、retrieval、tool、grader、policy の変更
kill switch、rollback、監視を弱くする変更

変更行数が少なくても tier は上がる。認可条件の一文字、外部 action の default、migration の NOT NULL は小さい diff でも高影響になり得る。

risk_tier と agent の delegation level は別軸である。risk tier は変更が失敗したときの最大影響、可逆性、検知可能性を表し、delegation level は agent に許す読取・下書き・実行・送信等の権限を表す。R1 でも広い production 権限は許さず、R2/R3 を人が実装しただけで低 risk にしない。委任と権限昇格の正本は 10 章とする。

自己申告だけで tier を下げない。semantic diff/path/consumer/manifest から auth、tenant、billing、個人情報、migration、privileged CI、重要 dependency、AI tool write/send/pay/delete、rollback 弱体化を検出したら最低 R2 とし、必要な threat/eval/release evidence を導出する。applicable trigger の minimum は waiver 不可で、positive evidence による false-positive 反証または triggering scope 除去後の scan 再実行だけが再分類を許す。R3 の専門 review は N/A にできない。trigger classification の未判定は UNKNOWN とし、provisional tier を最低 R2 に置いて出荷を止める。

一件の変更を運ぶ手順

1. Task brief で intent oracle を凍結する

実装前に、Goal、Context、Constraints、Done when に加え、非対象、失敗例、最大損失、必要証拠を書く。受入条件には AC-01 の ID を付ける。

良い条件:

AC-03: 同一 webhook event_id を 3 回受信しても invoice は 1 件だけ増える。
Evidence: integration test名、DB unique constraint、exact SHA。

悪い条件:

支払処理が正しく動く。

Codex に task、実装、test、合否解釈をすべて自由に作らせると、同じ誤解を互いに証明する循環が起きる。高影響な受入条件、外部仕様、expected output は、実装前に人または独立した一次情報で固定する。

2. Unknown と stop condition を先に書く

不明点を埋めず、次へ分ける。

実装中に安全に仮定できる
調査・顧客確認が必要で PAUSE
test/観測期限まで UNKNOWN
真なら実装を止める STOP

「たぶん既存 client は使っていない」「provider は同じ順序で送る」は、証拠のない仮定である。

3. ADR は選択で将来を拘束するときだけ作る

ADR の trigger:

public contract、data model、provider、security boundary の選択
戻す費用が大きい migration
複数の妥当な選択肢と重要な trade-off
後から「なぜ」と問われる例外

単なる実装手順を ADR にしない。Context / Drivers / Options / Decision / Consequences / Revisit / Rollback を残す。

4. 脅威モデルは baseline の差分を見る

毎回全システムを書き直さず、今回増えた asset、actor、entry point、trust boundary、source-to-sink、権限、failure mode を見る。予防 / 検知 / 封じ込め / 復旧 / 残余リスク の証拠を threat ごとに結ぶ。

高頻度の確認:

tenant ID、object ID、role を変えた negative test
webhook の偽造、重複、逆順、遅延
untrusted text が HTML、SQL、shell、URL、tool action へ届く経路
preview/CI/agent から production secret への経路
dependency install script、build action、artifact provenance
AI の prompt injection、過剰権限、無制限消費

セキュリティ要件の正本は 06 章。OWASP Top 10 は入口であり、検証項目には ASVS 等をリスクに応じて使う。OWASP ASVS

5. 実装は一成果・一所有範囲に切る

変更前に working tree と base を確認する
同じファイルを複数 agent が同時編集しない
探索、test 設計、security review のような bounded subtask を並列化する
書込が並列なら別 worktree/branch と所有ファイルを割り当てる
worktree を資格情報・network・host のセキュリティ境界と考えない
生成差分へ無関係な refactor、dependency、format 変更を混ぜない

Codex worktree は checkout の競合を減らすが、host や資格情報を隔離する仕組みではない。sandbox、approval、短命な test credentials、network 制限を別に使う。Codex worktrees / Agent approvals & security

5.5 依存・CI・artifact も生成差分として review する

AI が提案した package、GitHub Action、install command を名前だけで採用しない。

package が実在し、意図した publisher・repository か
保守状態、license、install/lifecycle script、transitive dependency、権限
既存標準機能や小さな自作で代替できないか
lockfile が変更理由と一致し、再現可能な install ができるか
CI が untrusted PR を秘密・write token・network・self-hosted runner と組み合わせないか
workflow token は read-only を既定にし、write/OIDC は必要な job と ref へ限定したか
第三者 Action を immutable ref へ固定し、固定先の監査と更新も行うか

変更または特権を持つ workflow job ごとに、trigger と actor trust、checkout ref、runner、token permissions、secret/OIDC、network/write target、artifact の producer/consumer を source-to-sink で記録する。pull_request_target や workflow_run の名前だけで安全と判断せず、untrusted code/artifact と特権 context が交差する経路は veto にする。

GitHub の secure-use guide は、GITHUB_TOKEN の最小権限、untrusted checkout と特権 trigger の分離、workflow dependency review を勧める。GitHub Actions secure use

配布・deploy する artifact は source SHA、builder/workflow、dependency lock、artifact digest を release record へ固定する。SLSA v1.2 は supply-chain guarantee を段階的に記述し provenance を扱うが、由来が追跡できることは、ソースの業務的正しさや悪性コード不在の証明ではない。SLSA v1.2

6. 検証は主張でなく snapshot にする

commit_sha:
environment / dependency lock hash:
command:
started_at / completed_at:
exit_code:
tested cases:
failed / skipped / flaky / unknown:
artifact or log location:

all tests pass だけでは、どの commit、どの command、何件、skip が何件か分からない。test 後に変更したら証拠は stale であり、再実行する。

実行結果は一つの immutable EVID run manifest を正本にする。TASK は claim と予定、EVAL は plan/case/result、PR と RELEASE は manifest の ID/hash を参照する。同じ PASS を複数文書へ手で写すと、古い値と循環参照を作る。manifest には plan/case、code/config、environment、runner/command、時刻、exit/skip/unknown、raw artifact hash を含める。

証拠フィールドの利用監査

書式を増やした後は、各フィールドを「あるか」でなく「何に使ったか」で監査する。

区分	判定	処置
`decision-used`	scope、実装、停止、承認、rollback のいずれかを実際に変えた	意思決定記録として維持する
`evidence-used`	runner、linter、reviewer が gate 判定または再現に消費した	schema と fingerprint を固定する
`duplicate-result`	同じ可変な実行結果を複数の正本へ手で転記した	manifest 一つへ集約し、他文書は ID/hash だけを参照する
`unused`	複数変更を通じて人・gate・event のどれにも使われない	削除・任意化・risk tier 限定の候補にする
`missing-or-stale`	frozen contract が要求するが欠損、未追跡、古い fingerprint、未成熟である	`unused` とみなさず `UNKNOWN` または veto にする

change_id のような外部キーの反復、一つの CASE を複数の EVID から参照すること、適用外理由を持つ N/A は duplicate-result ではない。一変更で使わなかっただけの欄もすぐ削らず、少なくとも数変更で利用履歴を取り、risk tier ごとの必要性を見直す。反対に、test 件数や PASS を event、PR、RELEASE へ転記すると、後から case を一件追加しただけで値が分岐する。結果値は machine manifest、判断理由は文書、状態遷移は append-only event と役割を分ける。

検査を層に分ける。

format、type、lint、schema、generated diff
domain unit/property test
DB、provider、queue、webhook の integration test
収益・権限・削除等の E2E と negative test
threat/secret/dependency/supply-chain check
AI の offline eval、tool effect、attack set、cost/latency
preview/canary と本番観測

すべての変更に全 test を強制するのでなく、影響表から該当検査を選び、選ばなかった理由を残す。

7. AI eval は test の代用にしない

AI を含む変更では次を固定する。

decision と eligible unit
case provenance、segment、risk tier
development / holdout / attack / production audit の分離
prompt、model、retrieval、tool、policy、grader version
critical veto と rubric
run 数、timeout、abort、unknown、judged coverage
aggregate に隠れる重大失敗と case-level result
人間 judge の校正と disagreement

正しい API status や高い平均 score を、顧客価値・安全な tool effect・継続へ読み替えない。詳しい計測は 12 章を使う。

AI/agent が write、send、pay、delete、publish、権限変更を行う場合、action 単位で proposal payload hash / tool・target・args・policy・effect class / approval ID / actor と権限根拠・scope・expiry / commit 直前の precondition / idempotency key / external receipt / verification due・status / compensation を append-only に残す。approval はその exact payload にだけ有効であり、API 2xx は最終 effect の証明ではない。12 章の権限付き actionと10 章の委任を正本にする。

8. PR は exact SHA の evidence index にする

PR の本文は作業日記でなく、reviewer が次を短時間で検証する索引にする。

なぜ今この変更をするか
AC-* と変更・test の対応
意図的に変えないもの
data/auth/billing/AI/cost/compatibility の影響
ADR、TM、EVAL、migration、screenshot、trace
exact reviewed SHA と base
source tree、config/model/tool-policy、intended IaC/runtime authority/credential/egress、evidence manifest をまとめた review binding tuple
release、feature flag、rollback
未解決・反証・reviewer に見てほしい箇所

authoring agent と別の Codex review を使うのは有用だが、同じ欠けた context や相関した誤りを持ち得る。/review は prioritized finding を得る追加 review とし、hard gate や人の出荷責任を置換しない。Codex code review

review round は append-only にし、head、tree、schema/config/flag、model/prompt/tool-policy、intended IaC/runtime identity/IAM/DB role/RLS/grants/credential scope/egress、evidence manifest、review criteria のどれかが変われば prior approval を stale にする。時系列を逆転させない。stage 0 の deploy 承認は reviewed tuple → merge/source tree → build provenance → artifact digest と intended target/config/authority を結ぶ deploy manifest、trusted upstream fence、suspended mode に束縛する。authority には適用分の IaC、runtime identity/IAM、DB role/RLS/grants、secret/credential ID-version-scope、external credential/egress policy を含め、値そのものは記録しない。suspended deploy 後に actual runtime/authority receipt を照合し、その receipt を含む promotion manifest と stage、target/cohort/blast radius、enabled traffic/webhook/queue/cron/tool-effect capability、expiry へ fresh release/exposure approval を結ぶ。trusted activation receipt で actual cohort/capability/residual fence が approval と一致して初めて stage を active にする。runtime identity が変われば new manifest、stage/cohort/effect scope/expiry だけなら unchanged manifest に fresh gate snapshot/approval/activation receipt を結ぶ。

生成コードでは、とくに hallucinated API/package、無視された制約、削除・skip された失敗 test、見た目だけ整った誤ロジックを確認する。GitHub の公式 guide も、自動 test・静的解析を先に行い、intent、architecture、dependency、license を人が確認するよう勧めている。GitHub: Review AI-generated code

9. deploy、release、exposure を分ける

deploy: artifact を環境へ置いた
release: 利用可能にした
exposure: 対象利用者が実際に変更へ到達した
value maturity: 成果を評価できる期限に達した
incident maturity: 遅れて発見される事故の観測期限に達した

feature flag で deploy 済みでも exposure 0 なら、顧客価値の成功ではない。さらに customer exposure 0 は webhook/queue/cron/tool effect 0 を意味しない。candidate 起動前に trusted upstream fence receipt を取り、suspended deploy → runtime/authority receipt 検証 → ingress ごとの fresh enable approval の順にする。release record には deploy/promotion manifest digest、artifact、schema/config/flag、IaC/runtime authority/credential/egress、対象 cohort と effect ingress、開始時刻、監視、停止条件、approval scope/expiry、rollback owner を持つ。

観測の 0 failures は、telemetry が生きているときだけ意味がある。stage ごとに expected/eligible denominator、observed event count、event-time watermark/max lag、producer/schema/monitor version、collection heartbeat、missing/coverage を照合する。欠損・stale はゼロでなく UNKNOWN とし、次の stage へ広げない。open incident が manifest、control、観測を無効化した場合も prior approval を再利用しない。

10. rollback を文書でなく実行可能な能力にする

rollback 証拠:

戻す artifact/config/schema の version
command または runbook
production 同等環境での最終検証日
data の後方互換性、backup、補償処理
rollback 前の ingress fence、in-flight request/queue/webhook/job の drain・cancel・quarantine・replay
旧 code × 新 schema/data/config/runtime authority の compatibility と partial rollback。現在の IaC/identity/IAM/DB grants/RLS、rotated credential version/scope、egress で旧 artifact が動く証拠を含む
最大 event/cache lag 後の再検証
所要時間と owner
rollback 後の verification query

DB 変更は code だけ戻しても data が戻らないことがある。expand/contract、dual read/write、backfill checkpoint、補償 event を設計する。migration rehearsal は empty table だけで終えず、production-shaped な件数・skew・境界量、並行 write、old/new app 共存、lock/replica/disk、pre/post checksum、partial restart、restore/forward repair を該当範囲で検証する。戻せない場合は reversible / forward-only / externally irreversible を分け、rollbackable: false、影響を限定する段階展開、停止条件、補償権限を強くする。

出荷判定

STOP

forward の deploy/release/exposure/expansion をしない。例:

重大な tenant 越境、秘密漏えい、無承認の送信・削除・課金
critical eval / negative test の失敗
法令・契約・non-negotiable invariant への不適合
rollback 不能で最大損失を受容できない

平均 score、売上見込、他 test の合格で相殺しない。

STOP は containment や rollback を止める意味ではない。事故時の fence / rollback / quarantine / compensate / forward-repair は、事前定義した緊急権限、対象 scope、runbook、non-waivable constraint、post-condition verification を使う別 decision event として実行する。回復できたことは再出荷許可ではなく、forward gate と fresh approval を取り直す。

PAUSE

既知の blocker を解消するまで止める。例: owner approval、migration rehearsal、provider 契約、security fix、顧客確認待ち。

UNKNOWN

required evidence が欠損、stale、未成熟、分母 0、coverage 不足。failure = 0 ではない。

SHIP

次をすべて満たすときだけ採る。

exact fingerprint に対する required gate が肯定証拠を持つ
Required=yes の gate はすべて PASS で、N/A がない
release manifest と approval の stage/target/scope/expiry が current
STOP/PAUSE がない
required UNKNOWN がない
残余リスクと非対象を owner が理解した
release、monitor、rollback、post-release review が実行可能

SHIP with monitoring を、release 前の必須証拠がない言い訳にしない。すべての不確実性を消す必要はないが、残す不確実性と最大損失を明示する。

本番後の閉ループ

release 直後、自然な価値周期、incident 観測期限で別々に確認する。

時点	見るもの	判断
直後	deploy health、error、権限、課金、主要 journey	stop / rollback / continue
canary 終了	cohort exposure、latency、cost、support、guardrail	expand / hold / change
価値成熟	初回・反復価値、独立利用、人手、貢献	keep / redesign / remove
incident 成熟	late complaint、訂正、security/privacy 事象	residual risk 更新

事故・逸脱・反復修正から、次のうち最小の有効な control を更新する。

コード / DB constraint / test / lint / CI / AGENTS.md
/ threat baseline / eval case / runbook / monitoring / product scope

incident を開いたら affected release manifest/stage と REL/EVAL/TM/PR gate を append-only event で invalidate し、rollout/automation を止める。closed や「fix merged」だけで旧 SHIP は復活しない。再開には新 manifest または安全な unchanged subset の肯定証明、再実行した gate、fresh scope-bound approval が必要である。active residual Critical や non-waivable veto は risk acceptance で復権させない。

「次は気をつける」だけで閉じない。人の注意より下流でしか止められない場合は、その理由と owner を残す。

個人開発者向けの最小運用

90 分で始める

0〜15 分: kitを repo へコピーし、root AGENTS.md に正しい command だけを書く。
15〜30 分: 過去に二度起きた重大ミスを 2〜3 個、invariant と safe path として書く。
30〜45 分: 一件の実変更を CHG-* にし、受入条件と非対象を固定する。
45〜60 分: risk tier と必要な ADR/TM/EVAL を選ぶ。
60〜75 分: exact SHA で test と review 証拠を記録する。
75〜90 分: release/rollback record と本番観測時刻を置く。

最初から書式を全部埋めない。R0/R1 は不要欄を N/A — 理由 とし、R2/R3 だけ証拠を深くする。

サービス工程の製品化変更では、Task Brief に 14 章の automation_candidate_id、根拠となる paid service_job_id、標準範囲内頻度、例外分類、現在の founder 分、期待する削減範囲を結ぶ。生成時間の短縮でなく、release 後の accepted outcome 当たり founder 分、rescue tail、顧客努力、完全負荷後貢献で閉ループにする。

週次に見る指標

個人の改善には絶対 benchmark より同じ repo の推移を使う。

idea/task ready から value exposure までの lead time
required evidence が UNKNOWN のまま止まった件数と理由
review 後に見つかった重大 defect と escaped defect
failed deployment、rollback、hotfix、recovery time
founder review / rescue / support 時間
release 後の価値、原価、苦情
同じ原因による再発数

PR 数、生成行数、agent turn 数を north star にしない。小さな PR に分割するのは review と rollback を容易にする手段であり、顧客価値の代用ではない。

よくある失敗

失敗	補正
長大な `AGENTS.md` に全知識を置く	短い invariant と exact command、詳説は参照文書
agent が作った曖昧な test だけで agent の実装を承認	先に `AC-*` と反例を固定し、外部 oracle を持つ
test 名だけを PR に書く	exact SHA、command、exit、skip、artifact を記録
reviewer agent が無指摘なので安全	hard gate、人の risk acceptance、本番観測を残す
全変更に同じ ceremony	risk と可逆性で required artifact を変える
security review を最後に追加	trust boundary 変更時点で threat delta と negative test
deploy 成功を release 成功とする	exposure、value、incident の時計を分ける
rollback 欄だけ埋める	command、data compatibility、verification を rehearsal
自動化を先に作る	手動で安定した workflow だけ skill/hook/automation へ昇格

根拠と限界

Codex の機能、設定、surface は変わり得る。AGENTS.md discovery、sandbox、hooks、review、worktree の実装詳細は利用時に公式文書を再確認する。
AGENTS.md、Codex review、AI eval は安全証明ではない。実行時の認可、制約、CI、監視、復旧を別に持つ。
risk tier と時間目安は本書の運用ヒューリスティックであり、法令・監査規格ではない。
高リスク、規制業務、重大な個人情報・資金・人身影響は、個人のテンプレートだけで受容可能にならない。
書式が開発時間を増やすだけなら、判断に使われなかった欄を削る。ただし UNKNOWN を削って見かけ上の完了へ変えない。