Codexでsupport ticketを再現手順にする前に決めること

3行まとめ

Steps

手順。

Data

条件。

Evidence

証跡。

Owner

担当。

support ticketは、bugfix前に再現できる材料へ変換します。

• support ticketは、症状、環境、期待結果、実際の結果、証跡に分けてから開発へ渡します。
• Codexには、顧客情報を伏せたrepro packetを作らせ、ticket本文の丸投げを避けます。
• bugfixへ進むのは、再現手順、影響範囲、owner、証跡、未確認項目が揃ってからにします。

support ticketは、顧客の困りごとがもっとも近い形で届く入力です。ただし、そのまま開発者へ渡すと、情報が足りないことがあります。「昨日から動かない」「この画面がおかしい」「急にエラーになった」という報告だけでは、修正へ進めません。

Codexに任せるなら、まずticketを再現可能な材料へ変換します。症状、環境、期待結果、実際の結果、操作手順、証跡、顧客情報の扱い、ownerを分ける。ここまで整えると、supportとengineeringの間で会話が進みやすくなります。

この記事では、2026年6月1日時点のOpenAI公式Codex docsをもとに、support ticketをrepro packetへ変える前の整理を扱います。日次triage全体は、公開済み記事のCodexでbug reportを日次triageする前に決めることで扱っています。ここでは、1件のticketを安全に再現手順へ変える話に絞ります。

この記事でわかること

Ticket

報告。

Repro

再現。

Redact

秘匿。

Gate

判断。

顧客報告を、そのまま実装依頼にしないことが大事です。

• support ticketを5つの情報に分ける方法
• 別の人が再現できる手順へ変える方法
• 顧客情報やsecretをredactionする考え方
• bugfixへ進める条件
• Codexへ渡すticket excerpt、logs、screenshotsの範囲
• support、engineering、productのreview観点

support ticketの価値は、顧客が実際に困っていることです。一方で、開発に必要な情報は別です。この記事では、その間をつなぐrepro packetを作ります。

前提知識

項目	内容	見方
Use Cases		ticket整理。
Features		作業入口。
Permissions		権限。
Computer Use		必要時。
AGENTS.md		報告型。

顧客情報を含むticketは、読む範囲と出力先を先に決めます。

Codexは、code変更だけでなく、issue、log、docs、QA結果を整理して次の作業へ渡す用途にも使えます。Codex app features、permissions、AGENTS.mdのdocsは、作業単位、権限、報告形式を決める時に関係します。

support ticketには、顧客名、契約、画面URL、ログ、添付画像、個人情報、社内メモが混ざることがあります。Codexへ読ませる前に、読ませてよい範囲と出力してよい範囲を決めます。

Codex Use Casesで見る位置づけ

用途	この記事での扱い
Bug and QA support	報告を再現可能な材料へ変える
QA with Computer Use	必要な場合だけ画面で確認する
Run verified operations	定型確認を証跡付きで行う
Permissions	顧客情報を読む範囲を決める
AGENTS.md	報告形式と禁止操作を伝える

日次triageとの違い

日次triageは、多数の報告を分類し、severity、reproducibility、scope、ownerを整理する作業です。

repro packet作成は、1件のticketを深く整える作業です。開発者が同じ状態へ到達し、期待結果と実際の結果を比較できるようにします。

ticketを5つの情報に分ける

項目	内容	見方
Symptom		症状。
Env		環境。
Expected		期待。
Actual		実際。
Evidence		証拠。

ticket本文を、再現に必要な情報へ分けます。

ticketは、symptom、environment、expected、actual、evidenceに分けます。これが揃うと、開発側で再現しやすくなります。

symptomは症状です。environmentは発生条件です。expectedは期待結果です。actualは実際の結果です。evidenceは証拠です。

symptom

symptomは、顧客が見ている症状です。「保存できない」「一覧が空になる」「支払い画面で止まる」などです。

Codexには、ticket本文から症状を一文で抜き出させます。感情や推測ではなく、観測された現象に寄せます。

environment

environmentは、plan、role、browser、device、account type、feature flag、app version、発生時刻などです。

ただし、顧客IDやメールアドレスをそのまま共有しません。必要なら匿名化したIDやfixtureへ置き換えます。

environmentで特に抜けやすいのは、権限と状態です。同じ画面でも、admin、member、guest、trial、paid planで表示が変わることがあります。feature flagやA/B testがある場合は、対象accountだけ違うUIを見ていることもあります。

Codexには、ticket本文にある環境情報をそのまま並べるだけでなく、「再現に必要そうだが不足している環境情報」を別枠で出させます。これにより、supportが顧客へ追加確認する内容を短くできます。

expected

expectedは、顧客や仕様が期待していた結果です。期待結果が分からない場合は、supportが確認します。

期待結果がないまま修正へ進むと、仕様変更なのかbugfixなのかが曖昧になります。

actual

actualは、実際に起きた結果です。error message、status code、画面表示、失敗した操作、発生頻度を残します。

「動かない」ではなく、「保存buttonを押すと500 errorが返り、toastに保存失敗と出る」のように具体化します。

actualには、発生頻度も入れます。毎回なのか、初回だけなのか、特定dataだけなのか、時間帯で変わるのか。頻度が分かると、再現手順の作り方が変わります。

また、顧客が見た表示と、systemが返したlogは分けます。顧客の画面では「保存できません」とだけ見えていても、logにはpermission error、validation error、timeout、rate limitのような手がかりが残る場合があります。

evidence

evidenceは、ticket URL、screenshot、log、console error、request id、時刻、関連PR、関連releaseです。

証跡は多ければよいわけではありません。再現に必要なものへ絞ります。

再現手順を作る

1. 1Start

   開始状態。

2. 2Action

   操作。

3. 3Observe

   結果。

4. 4Repeat

   確認。

再現手順は、別の人が同じ状態へ行ける粒度にします。

再現手順は、start state、steps、test dataで作ります。別の人が同じ状態へ到達できる粒度にします。

Codexには、ticket本文から不足情報を補わせるのではなく、不足しているものを質問として残させます。

start state

start stateは、どこから始めるかです。ログイン状態、role、対象画面、feature flag、test account、対象dataを含めます。

start stateが曖昧だと、再現できません。特に権限やplanで表示が変わるappでは重要です。

steps

stepsは、操作順です。クリック、入力、画面遷移、保存、reload、filter、uploadなどを順番に書きます。

一つのstepに複数操作を詰め込まないようにします。再現できない時に、どこで分岐したか分かるからです。

よい再現手順は、失敗した時にも役に立ちます。たとえば「3番目の操作までは同じだが、4番目で顧客環境と違う表示になる」と分かれば、原因はdata、permission、feature flag、環境差分のどこかに寄せられます。

Codexには、手順ごとに「観測するもの」を添えさせます。画面URL、button label、network status、toast、log idなどです。操作だけの手順より、確認しやすくなります。

test data

test dataは、再現に必要なdataです。顧客の実dataを使うのではなく、fixtureや匿名化したdataへ置き換えられるかを見ます。

実dataでしか再現しない場合は、共有範囲と権限を強めます。

顧客情報をredactionする

Name

伏せる。

ID

置換。

Secret

出さない。

Data

fixture化。

再現に必要な条件と、共有してはいけない情報を分けます。

顧客情報は、mask、fixture、share boundaryで扱います。再現に必要な条件と、共有してはいけない情報を分けます。

support ticketをCodexへ渡す時は、顧客名、メールアドレス、住所、token、contract、billing、private URL、添付画像内の個人情報を確認します。

mask

maskは、値を伏せることです。メールアドレス、token、顧客名、電話番号、社内URLなどを置き換えます。

ただし、値の形が再現に必要な場合があります。その場合は、形式だけ残して実値を伏せます。

fixture

fixtureは、再現用dataです。顧客dataをそのまま使わず、同じ条件を再現できるtest dataへ置き換えます。

Codexには、fixture化できる条件と、実dataが必要な条件を分けさせます。

share boundary

share boundaryは、誰へ共有してよいかです。supportだけ、engineeringだけ、security ownerだけ、外部vendorへ共有不可などを決めます。

ticket由来の情報をPR本文へ貼る時は、公開範囲が変わることに注意します。

特にGitHub PR、public issue、外部vendor ticketへ転記する時は注意します。社内ticketでは許される情報でも、外部の場所へ出すと公開範囲が変わります。

repro packetには、共有可能な要約と、社内限定の詳細を分けておくと安全です。Codexへ「public-safe summary」と「internal evidence」を分けて出させる運用もできます。

bugfixへ進める条件

項目	内容	見方
Repro		再現。
Impact		影響。
Owner		担当。
Evidence		証跡。

条件が揃わない場合は、追加確認へ戻します。

bugfixへ進める条件は、reproducible、impact、owner、evidenceです。

条件が揃っていない場合は、すぐ実装へ進めず、追加確認へ戻します。急ぎでも、情報が足りないbugfixは手戻りしやすいです。

reproducible

reproducibleは、再現できることです。毎回再現、時々再現、特定条件で再現、再現不可を分けます。

再現不可でも、logや証跡が強ければ調査へ進める場合があります。ただし、修正ではなく調査として扱います。

impact

impactは、顧客影響です。何人に影響するか、回避策があるか、契約や売上に関係するか、securityやdata lossがあるかを見ます。

impactが大きい場合は、bugfixだけでなくsupport responseやincident扱いも検討します。

impactは、severityと同じではありません。errorが派手でも回避策があり、影響が限定的な場合があります。逆に、見た目は小さくても、請求、権限、データ保存、外部送信に関係する場合は重く扱います。

Codexには、impactを断定させず、根拠と未確認を分けさせます。「1社から報告」「同じlogが複数accountで発生」「billing flowに関係」「回避策あり」のように、判断材料として出します。

owner

ownerは、次に見る人です。support owner、engineering owner、product owner、security ownerを分けます。

ownerがいないticketは、再現手順があっても止まりやすいです。

再現できない時の扱い

再現できない場合は、仮説、追加で必要な情報、次の確認、期限を残します。

「再現できないので終了」ではなく、「この条件では再現しない」「この情報があれば再確認できる」と書きます。

Codexに渡す入力

項目	内容	見方
Excerpt		抜粋。
Logs		伏せたログ。
Shot		画像。
Scope		対象。

ticket全量ではなく、必要な抜粋と証跡へ絞ります。

Codexに渡す入力は、ticket excerpt、logs、screenshots、scopeです。ticket全文を丸ごと渡さず、必要な範囲へ絞ります。

入力には、redaction済みであること、推測で埋めないこと、未確認を残すことを明示します。

ticket excerpt

ticket excerptは、必要な抜粋です。顧客の主張、発生条件、期待結果、実際の結果、時刻、添付の有無を含めます。

社内メモや個人情報が混ざる場合は、抜粋を作ってから渡します。

logs

logsは、必要な範囲だけ渡します。request id、timestamp、status code、error code、service名、masked user idなどです。

raw logを丸ごと渡すと、secretや個人情報が混ざることがあります。

logを渡す時は、ticketの発生時刻と合わせます。時間帯がずれると、別のerrorを見てしまうことがあります。timezoneも明示します。

また、logは顧客体験そのものではありません。logにerrorがあっても、顧客が見た症状と一致するとは限りません。Codexには、ticket symptomとlog evidenceが対応しているかを分けて書かせます。

screenshots

screenshotsは、画面の証跡です。個人情報や顧客名が写る場合は加工します。

screenshotだけでは再現手順になりません。操作順、期待結果、実際の結果と合わせて扱います。

reviewerが見る観点

項目	内容	見方
Support		顧客文脈。
Eng		再現性。
Product		影響。
Security		秘匿。

supportとengineeringの間で、見る観点を分けます。

reviewerは、support、engineering、product、securityで観点を分けます。

supportは顧客文脈を見ます。engineeringは再現性を見ます。productは影響と仕様判断を見ます。securityは情報の扱いを見ます。

support

supportは、顧客の困りごと、期待結果、回避策、返信に必要な情報を見ます。

ticketの言葉を開発用語へ変換しすぎると、顧客文脈が消えます。症状の原文も短く残します。

engineering

engineeringは、再現手順、log、対象version、関連component、仮説を見ます。

実装へ進める前に、再現できるか、調査だけか、追加情報が必要かを判断します。

product

productは、仕様かbugか、影響範囲、優先度、顧客への説明を見ます。

期待結果が仕様とズレている場合は、bugfixではなく仕様判断になります。

product reviewでは、同じ報告が改善要望なのか、不具合なのかも見ます。顧客が期待した挙動が現行仕様と違う場合、修正ではなくdocs、UI copy、onboarding、plan制限の説明が必要なこともあります。

その場合でもticketを捨てません。repro packetの中で「仕様判断」「docs候補」「UI改善候補」「bugfix候補」を分けると、次のactionへつなげやすくなります。

よくある失敗

Raw ticket

丸投げ。

No repro

手順なし。

PII

情報漏れ。

No owner

担当なし。

ticketを急いで渡すほど、再現と秘匿が抜けやすくなります。

よくある失敗は、ticket本文をそのまま開発へ投げる、再現手順がない、期待結果と実際の結果が分かれていない、顧客情報を伏せない、ownerがいない、再現不可を隠すことです。

もう1つは、support ticketをすぐbugfixへ変えることです。顧客が困っていることは事実ですが、原因がbugとは限りません。仕様、設定、権限、外部連携、データ状態の可能性があります。

Codexには、修正案より先にrepro packetを作らせると、supportとengineeringの会話が短くなります。

FAQ

項目	内容	見方
再現不可?		仮説化。
ログ?		伏せる。
画像?		加工。
緊急?		別経路。

迷ったら、開発者が安全に再現できるかへ戻します。

再現できないticketはどう扱いますか？

仮説と追加確認へ分けます。再現不可、再現条件不明、logあり、顧客影響ありを分け、次に必要な情報を明確にします。

顧客ログはそのまま渡してよいですか？

原則として必要な範囲へ絞り、redactionします。secret、個人情報、契約情報、顧客名、private URLが混ざらないか確認します。

screenshotは必須ですか？

必須ではありません。ただし、UI問題では強い証跡になります。共有前に個人情報や顧客名を伏せます。

緊急ticketならすぐ実装してよいですか？

緊急でも、最低限の症状、影響、証跡、ownerは必要です。security、data loss、課金影響がある場合はincidentやescalationとして扱います。

参照した主な情報源

• 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のsupport/QA周辺の使い方は、導入時に公式docsで見直します。

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