Codexで定型操作を回す前にrunbookを作る

このテーマをもう少し広げて見るなら、AIエージェントの実行ログ設計: trace・tool call・承認ログを事故調査に使える形で残す と Codex Skillsをチームで入れる前に: サードパーティSkill・MCP依存・権限を監査する も合わせて確認してください。Verified operationの結果確認、承認、rollbackを後から追える証跡設計へつなげるため。

3行まとめ

Runbook

手順。

Approval

承認。

Verify

確認。

Rollback

戻す。

Codexに定型操作を任せる時は、実行より先に検証を設計します。

• Codexに定型操作を任せる前に、runbook、承認境界、検証、rollbackを固定します。
• verified operationは、操作を実行することではなく、結果を確認して証跡を残すところまで含めます。
• 失敗時のretry、rollback、escalation、stop conditionを先に書くと、自動化が危なくなりにくいです。

日次確認、週次レポート、公開前チェック、障害後の確認、顧客向け作業の前処理。こうした定型操作は、Codexに任せたくなる作業です。OpenAI公式のCodex Use Casesにも、repeatable workflowsを実行し、結果をverifyする「Run verified operations」が紹介されています。

ただし、定型操作は「毎回やるから自動化しやすい」だけではありません。毎回やるからこそ、間違えると繰り返し事故になります。特にwrite、送信、deploy、課金、顧客data、権限変更が絡む操作では、実行前に止まる場所と、実行後に確認する場所が必要です。

この記事では、2026年6月1日時点のOpenAI公式Codex docsをもとに、Codexへ定型操作を任せる前のrunbook設計を整理します。直前のCodexが使う社内CLIを作る前に決めることはcommand入口の話でした。この記事では、そのCLIや手順を使って、operation全体をどう検証可能にするかを扱います。

この記事でわかること

Trigger

開始。

Inputs

材料。

Evidence

証跡。

Report

報告。

毎回同じ型で結果を残すと、人間が判断しやすくなります。

• verified operationを6段階へ分ける方法
• Codexに渡すrunbookの作り方
• 人間承認が必要な境界の決め方
• 検証結果を証跡として残す方法
• 失敗時のretry、rollback、escalationの分け方
• Codexに最後に報告させる型

この記事は、deploy手順だけの記事ではありません。日次のログ確認、週次の集計、公開前チェック、support ticketの下準備、外部toolのread確認など、繰り返し実行するoperationを対象にします。

前提知識

項目	内容	見方
Use Cases		verified ops。
CLI		command化。
Permissions		権限。
Features		作業入口。
AGENTS.md		手順。

verified operationは、操作と検証を1つのworkflowとして扱います。

OpenAI公式のCodex Use Casesでは、Run verified operationsがAutomation / Integrationsの用途として紹介されています。repeatable workflowsを実行し、結果をverifyする位置づけです。同じ一覧には、Create a CLI Codex can use、Save workflows as skills、QA your app with Computer Useなどもあります。

verified operationは、単なる自動実行ではありません。開始条件、事前確認、実行、検証、報告、rollbackを1つのworkflowとして扱います。

Codex Use Casesで見る位置づけ

用途	この記事での扱い
Run verified operations	定型操作を実行し、結果を確認する
Create a CLI Codex can use	操作入口をcommand化する
Save workflows as skills	繰り返す手順を再利用可能にする
QA your app with Computer Use	画面操作で結果を見る
Permissions	副作用のある操作を分ける

CLI作成との違い

CLI作成は、操作の入口を整える作業です。引数、出力、dry-run、exit code、監査ログを設計します。

verified operationは、そのCLIや既存toolを含む手順全体を扱います。いつ始めるか、何を確認してから実行するか、実行後に何を見れば成功と言えるか、失敗時にどう戻すかを決めます。

verified operationを6段階に分ける

1. 1Trigger

   開始。

2. 2Precheck

   事前確認。

3. 3Execute

   実行。

4. 4Verify

   確認。

5. 5Report

   報告。

6. 6Rollback

   戻す。

段階を分けると、どこで止めるべきかが見えます。

verified operationは、trigger、precheck、execute、verify、report、rollbackに分けます。実行だけを切り出すと危険です。

triggerは開始条件です。precheckは実行前の確認です。executeは操作です。verifyは結果確認です。reportは人間へ返すまとめです。rollbackは失敗時や誤操作時の戻し方です。

trigger

triggerは、operationを始める条件です。時刻、ticket status、PR merge、incident close、customer request、manual approvalなどがあります。

Codexには、triggerが満たされているかを確認させます。満たされていない場合は、実行せずに理由を返します。

precheck

precheckは、実行前に見る項目です。対象environment、対象resource、権限、直近の障害、feature flag、関連ticket、dry-run結果などです。

precheckで止まれることが重要です。対象が曖昧、権限が足りない、productionかpreviewか分からない、rollbackがない場合は進めません。

execute

executeは、実際の操作です。read-onlyの取得、レポート生成、status更新、通知下書き、deploy準備、QA実行などです。

writeや外部送信を含む場合は、人間承認を挟みます。Codexが勝手に完了まで進めてよい操作かを分けます。

verify

verifyは、結果確認です。command result、URL、screenshot、log、database count、ticket status、通知下書き、監視指標などを見ます。

operation名が「verified」なら、ここが本体です。実行できたことと、期待通りになったことは別です。

report

reportは、人間へ返す結果です。何をしたか、何を確認したか、何が未確認か、次に何をするべきかを短くまとめます。

報告が曖昧だと、operationが成功したのか、途中で止まったのか、人間が判断できません。

rollback

rollbackは、戻し方です。revert、status戻し、通知取り消し、feature flag off、retry停止、owner escalationなどがあります。

rollbackできないoperationは、自動化の範囲を狭めます。特にdelete、課金、外部送信、顧客data更新は慎重に扱います。

runbookを作る

項目	内容	見方
Input		必要情報。
Step		手順。
Check		確認。
Stop		停止条件。

runbookは、実行手順だけでなく停止条件まで含めます。

runbookは、Codexへ渡す操作手順です。inputs、steps、checks、stop conditionを含めます。

単なる手順書ではありません。どの条件で止まるか、どの証跡を残すか、誰へ戻すかまで含めます。

inputs

inputsは、operationに必要な材料です。ticket URL、対象environment、対象resource、承認者、期間、実行command、確認URLなどです。

入力が足りない場合、Codexは推測せず質問へ戻すようにします。特にproduction、customer、billing、deleteが絡む時は、推測で進めません。

steps

stepsは、順番に実行する手順です。1つのstepに複数の副作用を混ぜないようにします。

read、dry-run、approval、write、verify、reportを分けます。こうすると、どこまで進んだかが追いやすくなります。

stop condition

stop conditionは、止める条件です。対象が違う、権限がない、precheckが失敗、dry-runと期待が違う、承認がない、verifyが失敗、rollbackがない、といった条件です。

Codexには、stop conditionに当たったら続行せず、状況を報告させます。

承認が必要な境界を決める

項目	内容	見方
Read		自動可。
Write		承認。
Send		強承認。
Delete		原則停止。

承認は作業後ではなく、副作用の前に置きます。

承認境界は、read-only、write、external send、destructiveで分けます。副作用の前に人間へ戻すことが大事です。

承認を作業後のレビューにすると、もう遅い場合があります。通知送信、status更新、deploy、deleteなどは、実行前に止めます。

read-only

read-onlyは、情報を取得するだけの操作です。log確認、status取得、ticket読取、report下書きなどです。

read-onlyでも、機密情報を含む場合があります。取得範囲と出力先を制限します。

write

writeは、状態を変える操作です。ticket更新、label付与、file生成、report保存、feature flag変更などです。

writeでは、dry-runまたはpreviewを先に置きます。人間が内容を確認してから実行します。

external send

external sendは、外部へ送る操作です。メール、Slack通知、顧客連絡、webhook、外部SaaS更新などです。

external sendは、writeより強い承認を置きます。送信先、本文、添付、個人情報、取り消し可否を確認します。

検証結果を証跡にする

Command

結果。

URL

確認先。

Shot

画面。

Owner

確認者。

成功したかどうかを、後から見ても分かる形で残します。

検証結果は、command result、URL、screenshot、ownerで残します。証跡がないoperationは、あとから確認できません。

成功したかどうかを、本人の記憶ではなく、後から見ても分かる形へします。

command result

command resultには、実行command、exit code、主要出力、実行時刻を残します。

secretや個人情報が含まれる場合はmaskします。ログを残すために情報漏れしてはいけません。

URL

URLは、確認先です。ticket、PR、dashboard、preview、report、log query、monitoring viewなどです。

URLだけでは不足する場合があります。権限がない人でも判断できるよう、短いsummaryを添えます。

screenshot

screenshotは、画面状態の証跡です。UI確認、dashboard、preview、external toolの確認に使えます。

ただし、screenshotには個人情報が写ることがあります。共有先と保存期間を考えます。

owner

ownerは、最終判断する人です。Codexが実行しても、業務判断は人間に残る場合があります。

ownerが曖昧なoperationは、自動化しにくいです。reportを誰が読むのか、誰が承認するのかを決めます。

未実行を隠さない

未実行は失敗ではありません。隠すことが問題です。

Codexには、実行したこと、実行していないこと、実行できなかった理由、残リスクを分けて報告させます。

失敗時の分岐を先に書く

1. 1Retry

   再試行。

2. 2Rollback

   戻す。

3. 3Escalate

   引き上げ。

4. 4Stop

   止める。

失敗してから考えるのではなく、分岐をrunbookへ入れます。

失敗時の分岐は、retry、rollback、escalation、stopです。失敗してから考えると、焦って判断が雑になります。

runbookには、どの失敗ならretryしてよいか、どの失敗なら止めるかを書きます。

retry

retryしてよいのは、一時的なnetwork error、rate limit、外部APIのtemporary errorなどです。

ただし、write系operationのretryは二重実行に注意します。idempotency keyや実行済みIDがない場合は、人間確認へ戻します。

rollback

rollbackは、変更を戻す操作です。revert、status戻し、flag off、通知の取り消し、reportの修正などです。

rollbackできるか分からないoperationは、実行前に止めます。

escalation

escalationは、人間へ引き上げる条件です。顧客影響、security、billing、data loss、権限不足、未知のerrorなどです。

Codexには、escalation条件に当たったら追加操作をせず、状況と証跡をまとめさせます。

Codexに報告させる型

項目	内容	見方
Summary		結果。
Evidence		証跡。
Risk		残り。
Next		次。

報告形式を固定すると、成功と未確認を分けて読めます。

Codexに最後に報告させる型は、summary、evidence、risk、next actionです。

毎回同じ型にすると、人間が読みやすくなります。特に、成功と未確認を分けて読むことができます。

summary

summaryは、operationの結果です。完了、途中停止、承認待ち、失敗、rollback済みを明確にします。

「完了しました」だけでは足りません。何が完了したのかを書きます。

evidence

evidenceは、確認した証跡です。command、URL、screenshot、log、ticket、PR、owner確認などを並べます。

証跡がない項目は、未確認として残します。

next action

next actionは、次にやることです。承認待ち、owner確認、retry、rollback、follow-up ticket作成、runbook修正などです。

operation後に次actionがないなら、終了条件を明確にします。

よくある失敗

No stop

止まれない。

No proof

証跡なし。

Auto write

勝手に更新。

No rollback

戻せない。

自動化しやすい作業ほど、停止条件と証跡が重要です。

よくある失敗は、実行手順だけを書いて検証手順がない、stop conditionがない、writeを自動で進める、失敗時のrollbackがない、証跡を残さないことです。

もう1つは、runbookを作ったまま更新しないことです。実際にCodexへ回させると、曖昧な入力、足りない権限、弱い検証条件が見つかります。その失敗をrunbookへ戻します。

verified operationは、一度作って終わりではありません。毎回の結果を、次のrunbook改善に戻す仕組みです。

FAQ

項目	内容	見方
Daily?		向く。
Deploy?		承認強め。
Retry?		条件付き。
Human?		判断担当。

迷ったら、その操作を自動で完了してよいかへ戻します。

日次確認はCodexに任せやすいですか？

向いています。ただし、read-onlyから始め、確認対象、期間、異常時の報告先、証跡を固定します。

deploy操作もverified operationにできますか？

できますが、承認境界を強めにします。preview確認、rollback、owner承認、監視確認、外部通知を分けます。

retryは自動でよいですか？

read-onlyや一時的な取得失敗なら自動retryしやすいです。write系は二重実行を避けるため、idempotencyや実行済み確認が必要です。

人間はどこで見るべきですか？

副作用の前、verify失敗時、rollback前、external send前、unknown error時です。すべてを人間が見る必要はありませんが、判断が必要な境界は残します。

---

次に読むなら

参照した主な情報源

• https://developers.openai.com/codex/explore/
• https://developers.openai.com/codex/use-cases
• https://developers.openai.com/codex/app/features
• https://developers.openai.com/codex/permissions
• https://developers.openai.com/codex/guides/agents-md

次に読むなら

更新履歴

1. 2026.06.01

   初版。

Codexのuse casesやpermissionsは、導入時に公式docsで見直します。

• 2026年6月1日: OpenAI公式Codex docsを確認して初版を作成しました。