Codexで障害ポストモーテムを下書きする前に決めること

3行まとめ

Timeline

時系列。

Impact

影響。

Cause

原因。

Actions

対策。

障害後のレポートは、きれいな文章より事実の対応関係を重視します。

• 障害ポストモーテムは、timeline、impact、detection、mitigation、root cause、action itemsを分けてからCodexへ渡します。
• Codexには、全ログを丸投げせず、alert、deploy、chat、customer signal、復旧確認の根拠をpacket化して渡します。
• 最終版では、blameではなく、事実、影響、未確認、owner付き対策、公開範囲を人間が確認します。

障害後は、記録が散らばります。monitoring alert、deploy log、Slack thread、incident channel、support ticket、customer email、PR、rollback、status page。数時間後には、誰が何を見て何を判断したのかが曖昧になります。

Codexにポストモーテムを下書きさせると、散らばった情報を短時間でまとめられます。ただし、障害後の文章は慎重に扱う必要があります。原因を急いで決める。個人を責める表現になる。影響範囲を小さく見積もる。未確認を事実として書く。こうした失敗は、AIがきれいに文章化するほど見えにくくなります。

この記事では、2026年6月1日時点のOpenAI公式Codex Use Cases、Codex app features、Permissions、AGENTS.md docsをもとに、障害ポストモーテムをCodexへ下書きさせる前の整理を扱います。障害中の定型確認やrollback運用は、公開済み記事のCodexで検証付き運用を回す前に決めることで扱っています。ここでは、障害後の事実整理と学習に絞ります。

この記事でわかること

Packet

材料。

Draft

下書き。

Review

確認。

Owners

担当。

ポストモーテムは、下書きと最終判断を分けると扱いやすくなります。

• 障害情報をtimelineに並べる方法
• impactを原因分析より先に確定する理由
• detection、mitigation、recoveryを分ける見方
• root causeを急がず、contributing factorとunknownを残す方法
• action itemをprevent、detect、respondへ分ける方法
• Codexに渡すpostmortem packetの作り方
• internal、external、customer向けで公開範囲を変える考え方

ポストモーテムの目的は、誰かを責めることではありません。次に同じ種類の障害へ強くなることです。そのためには、うまい文章より、事実と次の対策の対応関係が重要です。

前提知識

項目	内容	見方
Use Cases		調査。
Features		作業入口。
Permissions		権限。
AGENTS.md		報告型。
Automations		定期確認。

障害後の整理では、読ませるログと公開する内容を分けます。

OpenAI公式のCodex Use Casesでは、bug triage、verified operations、large codebase understanding、meeting follow-upsなど、散らばった情報を整理して次の作業へつなげる用途が示されています。障害ポストモーテムも、同じように情報源を分け、根拠を付け、actionへ落とす作業です。

Codex app features、Permissions、AGENTS.md docsは、どのprojectで作業するか、どこまでログを読ませるか、どの形式で報告させるかを決める時に関係します。

incident対応中と事後整理を分ける

incident対応中は、復旧が最優先です。調査、mitigation、rollback、customer communication、monitoring確認が動きます。

ポストモーテムは、その後の整理です。対応中の判断を邪魔しないように、復旧後にsourceを集め、時系列、impact、原因、対策へ分けます。

bug triageとの違い

bug triageは、報告を分類し、再現性や優先度を決める作業です。ポストモーテムは、起きた障害から学び、再発防止や検知改善へつなげる作業です。

bug ticketが1件でも、影響が大きければポストモーテム対象になります。逆に、多数の小さなbug reportがあっても、ポストモーテムではなく日次triageで十分なこともあります。

情報源を時系列に並べる

1. 1Alert

   検知。

2. 2Deploy

   変更。

3. 3Chat

   会話。

4. 4Signal

   顧客。

時系列を先に置くと、推測と事実を分けやすくなります。

最初にtimelineを作ります。timelineは、推測を書く場所ではありません。いつ、何が観測され、誰が何をしたかを並べます。

Codexには、alert、deploy、chat、customer signal、PR、rollback、verificationを時刻付きで並べさせます。

alert

alertは、検知の入口です。監視名、発火時刻、threshold、対象service、severityを確認します。

alertが遅かったのか、早かったが気づけなかったのかで、対策が変わります。

deploy

deployは、変更の入口です。release version、commit、feature flag、migration、config change、rollbackの有無を見ます。

deployと障害発生時刻が近い場合でも、すぐ原因と決めません。相関と原因は分けます。

chat

chatは、判断の流れを拾う場所です。誰が何を見て、どの仮説を立て、どの操作を実行したかを確認します。

ただし、chatには未確定の発言が多く含まれます。Codexには、confirmed、hypothesis、questionを分けさせます。

customer signal

customer signalは、support ticket、問い合わせ、SNS、status page reaction、CS報告などです。

顧客影響は、内部monitoringだけでは分からないことがあります。最初に顧客が気づいたなら、detection改善の材料になります。

impactを先に確定する

項目	内容	見方
Users		対象。
Duration		時間。
Data		影響。
Money		課金。

原因分析より先に、誰にどの程度影響したかを確定します。

原因分析より先に、impactを確定します。誰に、どの程度、どの時間帯、どの機能で影響したかです。

impactが曖昧なままだと、対策の優先度も外れます。

user impact

user impactでは、影響を受けたuser数、account数、plan、region、role、機能を見ます。

「一部ユーザー」だけでは弱いです。可能なら、対象条件と件数を出します。

duration

durationは、開始、検知、mitigation、復旧、完全確認を分けます。

ユーザー影響が始まった時刻と、社内が気づいた時刻は違うことがあります。復旧操作をした時刻と、ユーザー影響が消えた時刻も違います。

data and money

data loss、data corruption、billing、payment、notification、permissionに関わる障害は別扱いにします。

影響が疑われるが未確認の場合は、未確認として残します。軽く見積もらないようにします。

detectionとmitigationを分ける

項目	内容	見方
Detect		気づく。
Mitigate		止血。
Recover		復旧。
Verify		確認。

早く気づけたか、早く止血できたか、別々に振り返ります。

detection、mitigation、recoveryは別です。早く気づくこと、影響を止めること、元の状態へ戻すことは、それぞれ違う能力です。

Codexには、対応中の操作をこの3つに分類させます。

detection

detectionは、障害に気づいた経路です。monitoring、log、synthetic check、customer report、internal user、QA、supportなどです。

検知が顧客報告だけだったなら、監視改善がaction itemになります。

mitigation

mitigationは、影響を止める操作です。rollback、feature flag off、traffic shift、rate limit、queue pause、manual fixなどです。

mitigationは、根本原因の解決ではない場合があります。止血と恒久対応を分けます。

recovery

recoveryは、正常状態へ戻ったことの確認です。monitoring、user flow、data correction、support確認、post-deploy checkを見ます。

復旧宣言の前に、何をもって復旧としたかを明記します。

root causeを急がない

Direct

直接。

Contrib

要因。

Unknown

不明。

Evidence

根拠。

原因は単語で決めず、根拠と不明点を一緒に残します。

root causeは、急いで決めるほど雑になります。直接原因、contributing factor、unknownを分けます。

直接原因は、障害を起こした近い原因です。contributing factorは、障害が起きやすくなった背景です。unknownは、まだ分かっていないことです。

direct cause

direct causeは、観測できる事実に基づきます。特定deploy、config、query、dependency、permission、schema mismatchなどです。

「Aさんが変更したから」ではなく、「この変更により、この条件で、この処理が失敗した」と書きます。

contributing factor

contributing factorは、検知遅れ、test不足、runbook不足、review不足、feature flag不足、rollbackしづらさなどです。

ここを丁寧に書くと、再発防止が個人の注意ではなく仕組みの改善になります。

unknown

unknownを残すことは大事です。分からないことを無理に埋めると、対策も外れます。

Codexには、未確認の仮説を「unknown / needs follow-up」として出させます。

blameを避ける書き方

ポストモーテムでは、人ではなく仕組みに寄せます。個人名やチーム名を責めるのではなく、検知、確認、review、rollback、communicationの仕組みを見ます。

責任を曖昧にするという意味ではありません。ownerは必要です。ただし、ownerは次の対策の担当であり、障害の犯人ではありません。

action itemを3種類に分ける

項目	内容	見方
Prevent		防ぐ。
Detect		見つける。
Respond		対応。
Owner		担当。

対策は、予防、検知、対応を混ぜずにownerを付けます。

action itemは、prevent、detect、respondに分けます。

preventは、同じ障害を起こしにくくする対策です。detectは、早く気づく対策です。respondは、起きた時に早く止血する対策です。

prevent

preventには、test追加、schema validation、review checklist、feature flag、migration guard、permission checkなどがあります。

preventだけに寄せると、起きた時の対応が弱いままになります。

detect

detectには、monitoring、alert、synthetic check、log field、dashboard、customer signalの拾い方があります。

検知改善は、復旧時間を短くします。根本原因を直しても、別の原因で似た影響が出ることがあるからです。

respond

respondには、runbook、rollback command、status page template、support brief、owner escalation、manual verificationがあります。

次に起きた時、誰が何を見て何をするかが分かる状態にします。

Codexに渡すpostmortem packet

項目	内容	見方
Logs		ログ。
Timeline		時系列。
Impact		影響。
Open		未確認。
Format		型。

Codexには、全ログではなく下書きに必要な材料へ絞って渡します。

Codexには、postmortem packetを渡します。全ログを貼るのではなく、必要なsourceと質問を絞ります。

packetには、sources、timeline候補、impact候補、open questions、出力形式、書いてはいけない情報を含めます。

sources

sourcesには、alert URL、deploy URL、PR、incident channel抜粋、support ticket、monitoring screenshot、rollback log、verification logを入れます。

機密情報や顧客情報はredactionします。

questions

Codexへの質問は小さくします。

以下のsourceから、事実ベースのtimelineだけを作ってください。
confirmed / hypothesis / unknownを分け、原因断定はしないでください。

次に、impact、root cause、action itemsの順で分けて依頼します。

output

出力形式は固定します。summary、impact、timeline、detection、mitigation、root cause、contributing factors、action items、open questions、appendixです。

これにより、毎回reviewしやすくなります。

公開範囲とredactionを決める

Internal

社内。

External

公開。

Customer

顧客。

Private

除外。

ポストモーテムは、社内学習と外部説明で粒度が変わります。

ポストモーテムは、社内版、外部公開版、顧客向け説明で粒度が違います。

Codexには、どの版を作るのかを明記します。社内版をそのまま外部へ出さないようにします。

internal

internal版では、詳細なtimeline、技術的原因、runbook不足、action itemを残します。

ただし、個人攻撃、不要な顧客情報、secret、private channelの内容は入れません。

external

external版では、影響、復旧、再発防止を中心にします。内部実装や攻撃に使える詳細は出しすぎません。

security incidentでは、専門のreviewを通します。

customer

customer向け説明では、顧客が知る必要のある影響、復旧状況、次の対応を明確にします。

未確認の原因を断定しません。必要なら、続報の予定を出します。

reviewで見る観点

項目	内容	見方
Facts		事実。
Gaps		不足。
Tone		責任。
Owners		担当。

レビューでは、文章のうまさより事実、空白、担当を見ます。

Codexの下書きは、必ずreviewします。見るのは、factuality、completeness、tone、ownershipです。

factuality

時刻、数値、影響範囲、操作、復旧確認がsourceと合っているかを見ます。

sourceのない断定は削るか、open questionへ移します。

completeness

timelineに抜けがないか、impactが薄くないか、detectionとmitigationが混ざっていないかを見ます。

不明点があるなら、不明点として残します。

ownership

action itemにowner、期限、確認方法があるかを見ます。

「監視を改善する」だけでは弱いです。どのmonitoringを、誰が、いつまでに、どう確認するかを書きます。

よくある失敗

Blame

責める。

No data

数字なし。

Vague

曖昧。

No owner

担当なし。

ポストモーテムは、犯人探しではなく次に強くなるための記録です。

よくある失敗は、原因を急ぐ、個人を責める、impactが曖昧、action itemが抽象的、ownerなし、未確認を断定する、外部公開版に内部情報を出しすぎることです。

原因を急ぐと、対策が外れます。個人を責めると、次から情報が出にくくなります。

impactが曖昧だと、障害の重さが分かりません。action itemが抽象的だと、完了しません。

きれいな文章で安心する

Codexは、整った文章を作れます。しかし、整っていることと正しいことは違います。

ポストモーテムでは、文章の自然さより、source、数字、時刻、owner、未確認項目を見ます。

action itemが多すぎる

障害後は、直したいことが多く出ます。しかし、action itemが多すぎると、どれも終わりません。

P0/P1の再発防止、検知、対応改善に絞り、残りは別issueへ分けます。

FAQ

項目	内容	見方
誰が書く?		owner。
公開?		分ける。
AI?		下書き。
期限?		早め。

迷ったら、事実、影響、次の対策へ戻します。

誰がポストモーテムを書きますか？

incident ownerが責任を持ち、Codexは下書きや整理を補助します。最終判断は、ownerと関係者が確認します。

Codexに全部書かせてよいですか？

下書きは任せやすいです。ただし、原因断定、顧客向け説明、公開範囲、security詳細、action itemのownerは人間が確認します。

いつ書くべきですか？

復旧後、記憶とログが新しいうちに書きます。ただし、原因が未確定なら未確定として残し、follow-upで更新します。

外部公開版も作れますか？

作れますが、社内版から直接公開しません。顧客情報、内部構成、攻撃に使える情報、未確認の推測を除き、必要なら法務やsecurity reviewを通します。

action itemは何件くらいがよいですか？

少数に絞ります。prevent、detect、respondでそれぞれ1から3件程度にすると、ownerが追いやすくなります。

参照した主な情報源

• Codex Use Cases – OpenAI Developers
• Codex use cases – OpenAI Developers
• Codex app features – OpenAI Developers
• Permissions – Codex – OpenAI Developers
• Custom instructions with AGENTS.md – Codex – OpenAI Developers

次に読むなら

更新履歴

1. 2026.06.01

   初版。

Codexの運用機能は、導入時に公式docsで見直します。

• 2026年6月1日: OpenAI公式Codex Use Cases、Codex app features、Permissions、AGENTS.md docsを確認し、初版を作成しました。