AIコーディングエージェント 2026.05.31 更新: 2026.06.01

Codexでバグ報告を整理する前に決めること

3行まとめ

Visualbug triageの入口修正前に分類と証拠を揃えます。

Input

報告。

Classify

分類。

Evidence

根拠。

Owner

担当。

次の一手。

triageは修正を急ぐ作業ではなく、判断できる材料を揃える作業です。

Codexのbug triageは、修正前に報告を分類し、優先度と証拠を揃える作業として使います。
support ticket、GitHub issue、Slack report、logを同じ箱に入れず、入力元ごとに扱いを分けます。
自動修正へ直行せず、daily sweepで人間が採用できる一覧にしてから次の対応を決めます。

不具合報告は、形が揃っていません。support ticketには顧客の困りごとがあり、GitHub issueには開発taskがあり、Slackには速報があり、logには事実があります。これを人間だけで毎日整理すると、地味に時間を取られます。

Codexに任せるなら、いきなりbugfixへ進めるより、まずtriageから始めるほうが安定します。報告を読み、重複をまとめ、再現性を見て、影響範囲を仮置きし、ownerへ渡せる形にする。ここまでならread中心で始めやすく、失敗しても戻しやすいからです。

この記事では、OpenAI公式のCodex Use Cases、Codex app features、Permissions、Worktrees、AGENTS.md docsをもとに、2026年6月1日時点の情報として整理します。Codexのuse casesや接続機能は更新され得るため、導入時は最新docsと自社のsupport運用を確認してください。

この記事でわかること

Visual先に決める項目日次運用に必要な判断軸です。

Source

入力元。

Priority

優先度。

Owner

判断者。

Gate

修正条件。

分類軸を固定すると、毎日の判断がぶれにくくなります。

Codexにbug triageを任せる範囲
support ticket、GitHub issue、Slack report、logの扱い分け
severity、reproducibility、scope、frequency、ownerの分類軸
AIのpriority候補を人間判断へ変える方法
triageからbugfixへ進める条件
日次sweepとして続けるための小さな運用

ここで扱うのは、bugfixそのものではありません。Codexに修正PRを作らせる前の段階です。報告が曖昧なまま実装へ進むと、修正対象を間違えたり、重要度を読み違えたり、再現できない不具合に時間を使ったりします。

bugfixの評価タスクを作る場合は、公開済み記事のAI Coding Benchmark Kitの作り方が近いです。この記事では、その手前にある「どの報告を、どの順番で、誰が見るか」を扱います。

前提知識

Visual見る公式情報Codex運用に関係するdocsです。

項目	内容	見方
Use Cases		triage用途。
Features		作業入口。
Permissions		権限。
Worktrees		修正分離。
AGENTS.md		repo指示。

triageはread中心で始め、修正へ進む時だけ権限を広げます。

OpenAI公式のCodex Use Casesでは、bug triageやcollaboration寄りの用途が紹介されています。Codexはcodeを読むだけでなく、issue、thread、PR、docsといった周辺情報を材料にして作業できます。だからこそ、triageでは「どの情報を読ませるか」を決める必要があります。

Codex app featuresは、projectやthread、worktreeなどの作業単位を扱います。Permissions docsは、read、write、networkなどの権限境界を考える時に関係します。Worktrees docsは、triage後に修正へ進む場合、既存作業から変更を分ける時に使えます。AGENTS.md docsは、repo固有の優先順位、禁止操作、test手順をCodexへ渡す土台です。

公式情報で見る範囲

公式情報	この記事で見ること
Codex Use Cases	bug triageをuse caseとして扱う考え方
Codex app features	project、thread、taskの扱い
Codex Permissions	read、write、networkの分け方
Codex Worktrees	triage後の修正を分ける方法
AGENTS.md	repo固有の判断ルール

修正記事との違い

実装前レビューやbugfix記事は、「どう直すか」「どのriskを見るか」に寄ります。この記事は、「直す前に、報告をどう見るか」です。

triageの成果物は、PRではなく一覧やメモです。重要度、再現性、影響範囲、owner、次の対応が揃っていれば十分です。逆に、報告の根拠が薄い時は、修正へ進まず、追加確認へ戻します。

入力元を先に分ける

Visual入力元の分類報告の性質で扱いを変えます。

項目	内容	見方
Support		顧客影響。
Issue		開発task。
Slack		速報。
Log		証拠。

入力元を混ぜると、重要度と対応先が曖昧になります。

bug reportを整理する時は、入力元を先に分けます。support ticket、GitHub issue、Slack report、logやmonitoringは、同じ「不具合っぽいもの」でも意味が違います。

support ticketは、顧客影響が強く出ます。GitHub issueは、開発taskとして扱いやすい反面、顧客影響が薄く書かれていることがあります。Slack reportは早いですが、情報が欠けがちです。logは客観的ですが、ユーザーの困りごとまでは書いてくれません。

Codexへ渡す前に、入力元ごとの役割を決めます。これだけで、priorityの誤読が減ります。

support ticket

support ticketでは、顧客影響を読みます。誰が困っているか、どのplanや環境で起きているか、回避策があるか、契約や売上に影響するか。これらはcodeだけを読んでもわかりません。

Codexには、ticket本文から「ユーザー影響」「発生条件」「不足情報」「開発へ渡す質問」を抜き出させます。ここで修正案まで出させる必要はありません。

GitHub issue

GitHub issueは、開発taskへ変えやすい入力元です。再現手順、期待結果、実際の結果、対象version、関連PR、関連logが揃っているほど、triageしやすくなります。

Codexには、重複issueの候補、既存labelとの対応、追加で必要な情報、owner候補を出させます。issue本文が曖昧なら、勝手に補完せず、質問として残します。

Slack report

Slack reportは速報に向いています。「この画面が変」「さっきから落ちている」「顧客から連絡が来た」のように、温度感が早く届きます。一方で、再現手順や対象versionが抜けやすい入力元です。

Slack起点でCodexへ投げる場合は、thread URL、発言者、時刻、関連画面、期待結果、実際の結果を抜き出す型を作ります。Slackから直接修正へ行くのではなく、issueかtriage listへ変換します。

Slack起点のtask化は、公開済み記事のSlackからCodexへタスクを投げる前に決めることでも扱っています。

logとmonitoring

logやmonitoringは、事実確認に使います。発生時刻、error message、対象service、頻度、影響範囲、直近deployとの関係を見ます。

ただし、logだけでpriorityを決めると、ユーザー影響を見落とすことがあります。error件数が少なくても、重要顧客に直撃している場合があります。逆に、件数が多くても既知のnoiseである場合もあります。

分類軸を固定する

Visualtriage軸毎回同じ項目で見ます。

項目	内容	見方
Severity		影響。
Repro		再現性。
Scope		範囲。
Frequency		頻度。
Owner		担当。

分類軸が決まると、Codexの出力を人間が採用しやすくなります。

Codexにtriageを任せるなら、分類軸を固定します。毎回違う見方をさせると、一覧は作れても、前日との比較ができません。

おすすめは、severity、reproducibility、scope、frequency、ownerの5つです。severityは影響の重さ。reproducibilityは再現性。scopeは影響範囲。frequencyは発生頻度。ownerは次に見る人です。

severity

severityは、件数だけで決めません。ユーザーが作業を完了できない、課金や認証に触れる、データ損失があり得る、securityに関係する。このようなものは、件数が少なくても高く扱います。

Codexには、報告本文やlogからseverity候補を出させます。ただし、最終判断はownerが持ちます。AIのpriorityは候補であって、決裁ではありません。

reproducibility

再現性は、bugfixへ進めるかどうかを分けます。再現手順がある。特定versionで起きる。特定dataで起きる。logと時刻が一致する。ここまで揃うと、修正へ進みやすくなります。

再現性が低い報告は、捨てるのではなく、追加確認へ戻します。Codexには「何が足りないか」を書かせます。これがsupportやQAへの依頼になります。

scope

scopeは、影響範囲です。単一画面なのか、特定APIなのか、全ユーザーなのか、特定planなのか、特定regionなのか。scopeが広いほど、ownerや対応速度が変わります。

scopeが読めない報告は、危険です。小さく見える不具合が実は広いこともあります。Codexには、判断できるscopeと、まだ判断できないscopeを分けて出させます。

誤分類を残す

triageでは、誤分類を消さないほうがよいです。なぜ間違えたのか、どの情報が足りなかったのか、どのlabelが紛らわしかったのか。これを残すと、次の依頼文や分類軸を直せます。

「AIが間違えた」で終わらせると、運用が育ちません。誤分類は、分類軸の改善材料です。

Codexに作らせる成果物

Visual成果物の型曖昧な報告をreviewできる形へ変えます。

List

一覧。

Memo

根拠。

Ticket

起票。

Question

追加確認。

成果物を名詞で決めると、日次triageが続きます。

Codexに作らせる成果物は、triage list、evidence memo、follow-up ticketの3つに分けます。全部を一つの長い報告にすると、日次で読みづらくなります。

triage listは、毎日見る一覧です。報告ID、入力元、短い要約、severity候補、再現性、scope、owner候補、次の対応を並べます。evidence memoは、判断の根拠です。follow-up ticketは、追加確認や修正へ進むための個別taskです。

triage list

triage listは短くします。1件あたり数行で十分です。長い説明はevidence memoへ逃がします。

重要なのは、同じ列で毎日見られることです。前日よりP1が増えたのか。再現待ちが滞留しているのか。owner未定が多いのか。これが見えると、日次会議で話す順番が決まります。

evidence memo

evidence memoには、根拠を残します。どのticket、issue、Slack thread、log、PR、releaseを見たのか。何が一致し、何が未確認なのか。

Codexの要約は自然に読めますが、根拠が追えなければ採用しにくいです。evidence memoは、AIの説明を信じるためではなく、人間が確認するための場所です。

follow-up ticket

follow-up ticketは、次のactionです。追加確認、再現調査、bugfix、仕様確認、support返信、monitoring追加などに分けます。

すべてをbugfix ticketにしないことが大事です。情報が足りない報告は、まず追加確認ticketです。仕様か不具合か曖昧なものは、product ownerへ確認します。

ownerと判断権を決める

Visual判断者の分担誰が採用するかを決めます。

項目	内容	見方
Support		顧客影響。
Code		技術影響。
Product		仕様判断。
QA		再現確認。

Codexは材料を揃え、採用判断はownerが持ちます。

Codexはtriage材料を揃えますが、採用判断は人間が持ちます。ここを曖昧にすると、AIが出したpriorityがそのままチームの判断のように扱われます。

ownerは、support owner、code owner、product owner、QA ownerに分けると扱いやすくなります。すべてをtech leadに寄せると、triageは続きません。

support owner

support ownerは、顧客影響と返信方針を見ます。顧客へ追加質問をするのか、回避策を案内するのか、開発調査中として待ってもらうのかを判断します。

Codexには、support向けの質問案や、顧客へ聞くべき不足情報を作らせます。ただし、顧客へ送る文章は人間が確認します。

code owner

code ownerは、技術影響を見ます。どのmoduleが関係しそうか、直近の変更と関係があるか、既存testで守られているか、修正した場合のriskは何か。

Codexには、関連file候補や過去PR候補を出させます。いきなりpatchを作らせるのではなく、まず調査範囲を絞ります。

product owner

product ownerは、仕様判断を持ちます。不具合に見えても、実は仕様変更の要望であることがあります。逆に、仕様として許容していた挙動が、顧客には重大な問題になっていることもあります。

Codexには、仕様確認が必要な報告を分けさせます。「bug」「仕様確認」「改善要望」を混ぜないようにします。

修正へ進める条件

Visual修正前のgatetriageから実装へ進む条件です。

1再現
手順がある。
2影響
範囲が読める。
3担当
ownerがいる。
4証拠
logや画面がある。
5着手
PRへ進む。

条件が足りない報告は、追加確認へ戻します。

triageからbugfixへ進める条件を決めます。おすすめは、再現手順がある、影響範囲が読める、ownerがいる、証拠がある、戻し方がある、の5つです。

この条件が揃わない報告を、急いで修正へ回すと危険です。修正PRができても、本当に直すべきものだったかがわかりません。

再現手順がある

再現手順は、もっとも大事です。最低限、期待結果、実際の結果、対象version、操作手順、発生時刻、関連dataのどれかが必要です。

再現できない報告は、すぐ却下するのではなく、再現待ちとして残します。Codexには、再現に必要な追加質問を作らせます。

影響範囲が読める

影響範囲が読めると、priorityを決めやすくなります。全ユーザーか、特定tenantか、特定browserか、特定APIか。scopeが違えば、同じbugでも対応速度が変わります。

影響範囲が不明な場合は、monitoring、analytics、support件数、release履歴を見ます。Codexには、確認すべき情報源を列挙させます。

rollbackがある

修正へ進める前に、戻し方も見ます。設定を戻せるのか、feature flagがあるのか、PR単位でrevertできるのか、旧経路へ戻せるのか。

rollbackがない場合は、修正対象を小さくするか、まず観測を追加します。急いで直すほど、戻し方が必要になります。

日次sweepの運用

Visual1日の流れ集めて、分けて、採用します。

朝
報告を集める。
昼
分類を確認する。
夕方
採用を決める。
翌朝
残件を見直す。

日次sweepでは、全部直すより、次に動ける形へそろえます。

bug triageは、完璧な会議体にしなくても始められます。おすすめは、日次sweepです。朝に集める。昼に分類する。夕方に採用する。翌朝に残件を見る。これだけでも、報告の滞留は見えます。

Codexに任せるのは、集めた報告の要約、重複候補、priority候補、不足情報、owner候補、次の対応候補です。採用と優先順位の最終判断は、人間が持ちます。

朝に集める

朝は、前日からのsupport ticket、GitHub issue、Slack thread、error logを集めます。全部を読ませるのではなく、対象期間と対象productを絞ります。

入力元ごとに、IDとURLを残します。後から根拠へ戻れない一覧は、triageとして弱いです。

昼に分類する

昼は、Codexのtriage listを人間が見ます。P1候補、再現待ち、owner未定、重複候補、仕様確認を分けます。

この時、AIの分類をそのまま採用しません。間違っているものは直し、理由を短く残します。誤分類の記録が、翌日の依頼文を良くします。

夕方に採用する

夕方は、採用するものを決めます。bugfixへ進めるもの、supportへ追加確認を返すもの、product ownerへ仕様確認するもの、monitoringを追加するものに分けます。

採用しないものも、理由を残します。既知issue、情報不足、仕様、再現不可、優先度低などです。理由が残ると、同じ報告が再度来た時に扱いやすくなります。

よくある失敗

Visual避けたい失敗triageで崩れやすい点です。

Direct fix

即実装。

Count only

件数重視。

No owner

判断者なし。

Delete miss

誤分類を消す。

失敗も残すと、次の分類精度を上げやすくなります。

bug triageの失敗は、AIの精度だけではありません。運用側の決め方が曖昧な時に起きます。

よくあるのは、報告をそのまま実装依頼にする、重要度を件数だけで決める、ownerを決めない、誤分類を消す、の4つです。

報告をそのまま実装依頼にする

「画面が壊れているらしいので直して」は、修正依頼として弱いです。再現手順、期待結果、実際の結果、影響範囲、対象versionがありません。

Codexには、まず不足情報を出させます。情報が揃ってから、bugfixへ進めます。

重要度を件数だけで決める

件数は大事ですが、件数だけではpriorityを決められません。少数でも課金、認証、データ、securityに関わるものは重い場合があります。

反対に、件数が多くても、既知のnoiseや軽微なUI崩れである場合もあります。severityは、件数、影響、回避策、顧客属性、発生範囲を合わせて見ます。

誤分類を消す

誤分類は、運用改善の材料です。なぜP2をP1と見たのか。なぜsupport ownerではなくcode ownerへ回したのか。なぜ重複を見落としたのか。

これを残すと、AGENTS.md、issue template、Slack依頼文、Codexへのpromptを直せます。誤分類を消すと、毎日同じ間違いを繰り返します。

FAQ

Visualよくある迷い運用前に決める答えです。

項目	内容	見方
Priority		候補にする。
Bugfix		条件後。
Small team		軽く回す。

Codexの分類は最終判断ではなく、判断材料として扱います。

AIにpriorityを決めさせてよいですか？

候補としてなら使えます。最終判断はownerが持ちます。Codexには、priority候補と根拠、不足情報を出させます。根拠が薄いpriorityは採用しません。

bugfixまで任せてよいですか？

条件が揃ったものだけ進めます。再現手順、影響範囲、owner、証拠、戻し方がある報告なら、小さなbugfixへ進めやすくなります。条件が足りない場合は、追加確認へ戻します。

ticketが少ないチームにも必要ですか？

必要です。ただし、重い運用にする必要はありません。週次でsupport ticketとissueを見直し、重複、未返信、owner未定、再現待ちを整理するだけでも効果があります。

security issueも同じ一覧で扱いますか？

同じ一覧へ混ぜすぎないほうがよいです。security候補は、通常のbugとはowner、公開範囲、証拠の扱いが変わります。公開済み記事のCodexにセキュリティ調査を任せる前に決めることのように、別の流れで扱います。

参照した主な情報源

次に読むなら

Codexの使い道を増やす前に決めること

bug triageを含め、use caseの導入順を決める時に読みます。

Codexに実装前レビューを頼む

triage後に修正へ進む前、bugやsecurity riskを先に見る時に使えます。

Codexにセキュリティ調査を任せる前に決めること

security候補を通常bugと分けて扱う時の参考になります。

更新履歴

Visual更新メモ公開時点の整理です。

2026.06.01
初版。

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

2026年6月1日: 初版公開。