Bug Triage

このページは、bug triage を「不具合票にラベルをつける事務処理」としてではなく、 未確定の問題信号を、再現可能性・影響範囲・仕様整合性・統治条件・次の責任配分へ変換する process frame として捉えるためのケーススタディである。

ここでいう triage は、単なる優先度づけではない。 それは少なくとも次を含む。

• report が current frame の subject になりうるか
• bug なのか duplicate なのか spec ambiguity なのか incident なのか
• 何が evidence として足りているか / 足りていないか
• どの actor / frame に次を handoff すべきか
• rollback, escalation, replan が必要か
• triage 自体から durable learning を残すべきか

このページの狙いは、bug triage を PCE 2.0 の中でも特に Goal Ownership、Incident Ownership、Branch and Join、recovery、Corrupt Success が交差するケースとして示すことにある。

このケースの目的

このケースでは、次のことを明確にしたい。

1. bug report は到着した瞬間から bug なのではなく、まず candidate problem statement であること
2. triage は bug fix ではなく、classification + routing + containment + evidence shaping の frame であること
3. reproduction、spec check、blast radius analysis を parallel child frame として扱えること
4. triage の出力は単なる label ではなく Process Delta であること
5. severity 判定や incident への移行には human oversight と explicit authority が必要であること
6. “一見うまく triage できたように見えるが dangerous” という Corrupt Success が bug triage にも存在すること
7. triage からも failure memory や operational memory candidate が生まれうること

bug triage は、開発の入口に見えて実はかなり深い。 ここでの雑さは、後段の feature fix、incident handling、rollback、release confidence をすべて汚しうる。 その意味で bug triage は、PCE 2.0 の責任分解が非常に効く領域である。

---

シナリオ

今回のシナリオは、前の Feature Delivery / PR Review ケースと連続している。

report

サポートチームから次の報告が来る。

• 一部ユーザーで checkout total が負になったという問い合わせが 3 件入った
• 発生条件は「複数クーポン適用時」らしい
• ただし端末、アプリ version、account tier がまちまちで、再現条件は曖昧
• 最近リリースされた coupon-combination 関連変更との関係が疑われている
• 返金や決済逸脱はまだ確認されていないが、financial correctness 的には危険度が高い可能性がある

triage の目的は、この報告をそのまま「bug」と断定することではない。 まず、

• 再現するのか
• 現行仕様と矛盾するのか
• 既知 issue / duplicate なのか
• incident へ escalate すべきか
• local bugfix frame を切ればよいのか

を決めることである。

このシナリオがよいのは、bug triage の典型的な難しさが入っているからである。

• report は本物らしいが、まだ不十分
• severity は高そうだが blast radius は不明
• 既知問題の duplicate かもしれない
• 仕様の解釈違いかもしれない
• 現行 release を止めるべきかはまだ言えない
• triage を間違えると later で costly な rollback / incident になる

---

全体像

このケースの flow を短く書くと、次のようになる。

support / monitoring signal
  -> triage frame instantiate
  -> intake normalization
  -> branch:
       reproduction
       spec / decision consistency check
       blast radius / release impact check
  -> join
  -> classify:
       insufficient evidence
       duplicate
       intended behavior / spec ambiguity
       bounded defect
       incident candidate
  -> if needed:
       escalate
       freeze / rollback / replan
       spawn bugfix or incident child frame
  -> emit triage deltas
  -> optionally promote triage-derived memory

ここで重要なのは、triage が「issue を読む」だけではなく、

• current report を subject として正規化し
• evidence を束ね
• parallel branch を走らせ
• join contract で統合し
• 次の legal transition を決める

独立の process frame だということだ。

---

bug report は bug ではない

PCE 2.0 で bug triage を考えるとき、最初に重要なのはこの distinction である。

incoming report

外部から入ってきた problem signal

triage subject

triage frame が現在扱っている candidate problem statement

confirmed defect

再現性・仕様不整合・scope relevance が一定程度確認された defect candidate

incident candidate

blast radius や governance risk が高く、通常の bugfix ではなく incident path が必要な状態

つまり bug triage の最初の仕事は、 report をそのまま current truth にせず、triage 可能な subject へ変換すること である。

この distinction を持たないと、次の二つの failure が起きやすい。

• report が来た瞬間に “bug confirmed” として動き出す
• 逆に、再現できないから “not a bug” と早すぎる closure をしてしまう

PCE 2.0 では、そのどちらも避ける。 triage は、report を current reality に変える前の governed path である。

---

初期状態

この report が入る前、project には少なくとも次の Durable Project State があるとする。

canonical にあるもの

• feature.checkout.coupon-combination の approved spec
• decision.no-payment-gateway-change
• checkout pricing / coupon precedence の decision memory
• release notes for checkout.spring-2026
• required regression baseline
• code review approval records
• rollback checklist for checkout pricing changes

provisional にあるもの

• coupon edge-case checklist candidate
• prior unresolved note around stacked discount rounding
• recent review notes from the PR review frame
• support tickets raw transcripts

ここで重要なのは、triage が白紙から始まらないことだ。 既存の decision memory や review records が、 triage において “何が intended behavior か” を判断する土台になる。

---

triage frame

このケースの parent frame は次のように置ける。

process_frame:
  frame_id: triage.checkout.negative-total.2026-03-10
  parent_frame_id: release.checkout.spring-2026
  frame_kind: incident_or_bug_triage

  goal: >
    checkout total が負になるという incoming report を triage し、
    reproducibility、spec consistency、blast radius、routing を明確にして、
    local bugfix、incident escalation、duplicate closure、insufficient evidence のいずれへ進むかを決める

  success_criteria:
    - triage subject が正規化されている
    - reproduction status が明確になっている
    - spec / decision consistency が評価されている
    - blast radius と release relevance が評価されている
    - next routing decision が explicit である
    - stale or weak evidence が current truth として扱われていない

  scope:
    in_scope:
      - incoming support reports about negative checkout total
      - reproduction attempts
      - current release impact assessment
      - spec / decision consistency check
      - routing to bugfix / incident / duplicate / insufficient evidence
      - triage-derived failure and operational memory candidates
    out_of_scope:
      - full feature redesign
      - broad pricing policy redesign
      - release-wide postmortem beyond this issue
    assumptions:
      - current approved spec is the baseline unless explicitly superseded
    non_goals:
      - shipping the actual fix in this frame

  actors:
    - support_intake
    - triage_owner
    - reproduction_agent
    - domain_reviewer
    - blast_radius_analyst
    - incident_owner
    - memory_writer
    - checkpoint_manager

  approval_points:
    - ap.triage.checkout.negative-total.routing
    - ap.triage.checkout.negative-total.incident-escalation

  eval_contract:
    - eval.triage.checkout.repro.v1
    - eval.triage.checkout.spec-consistency.v1
    - eval.triage.checkout.blast-radius.v1
    - eval.triage.checkout.memory-candidate.v1

  memory_write_policy:
    allowed_targets:
      - failure_memory
      - operational_memory
      - pending_candidates
    prohibited_targets:
      - raw_support_transcript_as_canonical
      - weakly-supported_duplicate_signature

  recovery_strategy:
    checkpoint_policy:
      - after_intake_normalization
      - after_branch_returns_ready
      - before_routing_approval
    rollback_anchor_policy:
      - last_triageable_subject_state
    resume_conditions:
      - revalidate_current_release_and_logs
      - invalidate_stale_branch_returns
    escalation_path:
      - incident_owner
      - release_owner

この frame で重要なのは、

• goal が “fix すること” ではなく “route を決めること”
• incident path を最初から視野に入れていること
• triage-derived memory candidates を明示していること
• stale report / stale branch return を later recover で invalid にできること

である。

---

actor と責任の非対称性

triage は多人 actor の仕事に見えるが、 責任は対称ではない。

support_intake

• report を normalized triage subject に変える
• raw transcript / ticket IDs / customer wording を保持する
• bug confirmed とは言えない

triage_owner

• triage frame の execution / integration owner
• branch を切る
• join をまとめる
• routing proposal を作る
• final incident closure は持たないことがある

reproduction_agent

• bounded reproduction execution
• environment / version / input pattern を明確化する
• severity decision は持たない

domain_reviewer

• spec / decision consistency evaluation
• intended behavior / non-intended behavior の判断補助
• global product reframe は持たない

blast_radius_analyst

• logs、release rollout、affected cohort、rollback feasibility を評価
• policy / product final judgment は持たない

incident_owner

• incident candidate の受理
• freeze / rollback / escalate / resume の authority
• triage owner より広い abnormal-flow authority を持つ

memory_writer

• triage-derived memory candidate の durable write authority
• triage routing そのものは持たない

この構造により、bug triage は report intake、local evaluation、integration、incident handling が別責任 であることが分かる。

---

Step 0: intake normalization

triage は raw ticket をそのまま扱わない。 まず support_intake が report を triage subject に正規化する。

input

• support ticket text
• customer screenshots
• checkout logs reference
• app version if known
• incident count so far
• support team confidence notes

output

• normalized problem statement
• affected surface guess
• missing evidence list
• raw transcript refs
• candidate duplicate IDs if any

ここで重要なこと

raw ticket の wording は often 曖昧である。 「合計が変」 「割引がおかしい」 「二重で引かれた気がする」 という自然言語のままでは triage subject として弱い。

PCE 2.0 的には、ここでまず report を reproducible / evaluable / routeable な triage subject にする ことが必要である。

---

Step 1: triage owner 用 context を compile する

triage owner は raw support transcript 全部を active に見るべきではない。 triage owner 用の compiled context が必要になる。

active に入るもの

• normalized problem statement
• current release version info
• approved spec summary relevant to coupon pricing
• known related decisions
• candidate duplicate refs
• missing evidence list
• current triage goal slice
• possible next branch options

by-reference にするもの

• raw support transcripts
• full logs
• customer screenshots
• past PR discussion full thread
• old ADR full text

active に入れないもの

• unrelated checkout issues
• old resolved bug reports with weak symptom overlap
• speculative internal chat notes
• private user data beyond what triage needs

重要なのは、triage owner context が evidence-shaping + routing-design のためのものであることだ。 まだ defect confirmed ではないので、solution-oriented detail を先に詰め込みすぎない方がよい。

---

Step 2: branch を切る

このケースでは、triage owner は三つの child path を切る。 これは Branch and Join の典型である。

branch A: reproduction

目的:

• current reproducibility を確認する
• affected version / environment / input pattern を特定する
• “本当に起きるか” を current evidence にする

branch B: spec / decision consistency

目的:

• 現象が approved spec / decision memory に反するか確認する
• intended behavior / known limitation / duplicate の可能性を調べる

branch C: blast radius / release impact

目的:

• 発生頻度、affected cohort、rollback feasibility、release implication を確認する
• incident へ上げるべきかを判断する材料を作る

これを YAML 風に書くと、たとえば次のようになる。

branch_set:
  set_id: bs.triage.checkout.negative-total.v1
  parent_frame_ref: triage.checkout.negative-total.2026-03-10
  purpose: >
    reproduction, spec consistency, blast radius を parallel に進め、
    routing decision を parent で確定する
  branch_kind: validation

  retained_authorities:
    - final_routing_decision_by_triage_owner
    - incident_escalation_acceptance_by_incident_owner
    - global_goal_retained_by_triage_owner

  shared_constraints:
    - do_not_confirm_bug_without_current_evidence
    - do_not_close_as_duplicate_without_signature_match
    - do_not_treat_release_wide_risk_as_local_bugfix_by_default

  branch_specs:
    - child_frame_ref: triage.checkout.negative-total.reproduction
      local_goal: >
        negative total が current release 上で再現するか確認し、
        repro steps と affected version を返す
      return_contract:
        required_deltas:
          - reproduction_status
          - repro_steps_if_any
          - environment_note
      local_failure_policy:
        - return_insufficient_evidence_if_logs_unusable

    - child_frame_ref: triage.checkout.negative-total.spec-check
      local_goal: >
        現象が approved spec と decision memory に反するか確認し、
        duplicate / intended behavior / ambiguity を返す
      return_contract:
        required_deltas:
          - spec_consistency_verdict
          - related_decision_refs
          - duplicate_candidate_if_any

    - child_frame_ref: triage.checkout.negative-total.blast-radius
      local_goal: >
        affected cohort, severity, rollback feasibility を確認し、
        incident threshold を超えるか返す
      return_contract:
        required_deltas:
          - blast_radius_assessment
          - severity_note
          - rollback_feasibility_note

  join_contract:
    join_kind: all_of
    required_branches:
      - triage.checkout.negative-total.reproduction
      - triage.checkout.negative-total.spec-check
      - triage.checkout.negative-total.blast-radius
    readiness_rule:
      - all_required_returns_present_or_explicitly_insufficient
    conflict_resolution:
      on_duplicate_vs_new_bug_conflict: escalate_to_triage_owner
      on_spec_ambiguity: escalate_to_product_owner
    integration_owner: triage_owner

ここで重要なのは、三 branch が全部 “fix” に向かわず、 それぞれ別の triage burden を bounded に扱っていることだ。

---

Step 3A: reproduction child の返り値

reproduction_agent は current release の sandbox で再現を試みる。 結果として、次が分かったとする。

• issue is reproducible on current release
• only when two coupons stack
• negative total occurs under a specific rounding path
• repro requires newly released combination logic

delta として返るもの

• evaluation delta reproduction: pass
• artifact-like note repro steps
• status delta current version affected
• evidence ref log snippet, test scenario ref

ここで重要なのは、 “再現した” がそのまま severity や routing を決めないことだ。 それは triage join の一部にすぎない。

---

Step 3B: spec / decision consistency child の返り値

domain_reviewer は approved spec と decision memory を見る。

結果として、次が分かったとする。

• negative total is not intended behavior
• current approved spec assumed precedence rule remains safe
• no explicit acceptance of negative total behavior exists
• symptom is similar to an older ticket but root cause and version differ, so not duplicate

delta として返るもの

• decision delta current behavior conflicts with approved decision baseline
• evaluation delta duplicate_candidate rejected
• status delta spec inconsistency confirmed
• unresolved issue whether release-wide rollback is needed cannot be decided locally

ここで duplicate を軽率に確定しないことが重要である。 症状が似ていることと、same defect であることは違う。

---

Step 3C: blast radius child の返り値

blast_radius_analyst は current logs、rollout status、affected cohort を見る。

結果として、次が分かったとする。

• only 3 tickets are confirmed, but rollout is still in progress
• affected path is financially sensitive
• blast radius is currently low but uncertainty is high
• rollback of the entire feature is feasible, but maybe not yet necessary

delta として返るもの

• evaluation delta severity: medium-high
• risk note low observed volume, high correctness sensitivity
• rollback feasibility note
• recommendation incident escalation threshold is close; human decision needed

ここで重要なのは、 severity は件数だけでは決まらず、financial correctness と rollout stage が効いていることだ。

---

Step 4: join して route を決める

triage owner は三 branch の return を join する。

join 時に見えること

• reproducible: yes
• intended behavior: no
• duplicate: no
• blast radius: uncertain but financially sensitive
• rollback feasible: yes
• release still active: yes

この時点で possible routes はいくつかある。

1. bounded defect として bugfix frame を切る
2. incident candidate として incident owner へ escalate する
3. evidence 不十分として hold する
4. duplicate / intended behavior として close する

このケースでは 1 だけで進めるには危険が残る。 なぜなら、現在の observed volume は小さいが、

• financial correctness risk
• rollout still active
• current release affected
• rollback feasible but not yet decided

があり、triage owner の local bundle を少し越えているからである。

---

Step 5: routing decision と human oversight

ここで triage owner は、incident owner を human oversight sink として使う。

なぜ incident owner に返すのか

• release impact を受ける
• local bugfix frame だけでは enough とはまだ言えない
• rollout continuation / freeze の判断が必要
• residual risk acceptance は triage owner の authority を越える

escalation package の内容

• normalized subject
• reproduction evidence
• spec inconsistency note
• duplicate rejection rationale
• blast radius note
• rollback feasibility note
• requested decision:
  • continue rollout + hotfix
  • freeze rollout
  • rollback feature
  • declare incident frame

ここで Human Oversight は、全部を人間がやることではない。 triage branches は AI / tools / analysts が進めた。 しかし route を変える high-impact decision は human-backed authority に retain されている。

---

Step 6: incident owner の判断

incident owner は escalation を受理し、次を決める。

verdict

• full rollback not yet required
• rollout freeze is required
• hotfix child frame should be opened immediately
• incident remains open until cohort size and payment integrity are rechecked

つまり、これは

• 単なる bugfix start ではなく
• full incident declaration でもなく
• controlled incident path に近い

判断になる。

lifecycle への効果

triage frame は、たとえば次のように遷移する。

active
  -> escalation_pending
  -> routing_approved
  -> completed

ただし parent release frame 側では、

active_rollout
  -> frozen_pending_hotfix

が起こる。

ここで重要なのは、bug triage は close できても、 parent release や spawned hotfix frame は still active だということだ。

---

triage の output は何か

この case では、triage の主要 output は artifact ではない。 むしろ次のような typed outputs が出る。

1. classification delta

• confirmed defect
• not duplicate
• not intended behavior

2. routing delta

• escalate to incident owner
• spawn hotfix frame
• freeze rollout

3. risk / governance delta

• blast radius uncertain but material
• rollback feasible
• release progression must be gated

4. evidence package

• repro steps
• logs refs
• decision inconsistency refs
• blast radius note

5. memory candidate(s)

• failure memory candidate
• operational triage checklist candidate
• duplicate discrimination heuristic candidate

つまり bug triage は、 単に “P1 バグ” とラベルする行為ではなく、 current problem signal を next frames と current governance に接続する delta production である。

---

bug triage の Corrupt Success

bug triage でも Corrupt Success は起こる。 むしろかなり起こりやすい。

このケースでの典型 corrupt success

support 症状が過去の既知 issue に似ていたため、 triage owner が “duplicate” と素早く閉じたとする。

表面上は効率が良い。

• backlog が減る
• triage time も短い
• no incident declared
• no hotfix required

しかし process 的には壊れている。

• current release version は違う
• root cause は未確認
• spec inconsistency が評価されていない
• blast radius が未確認
• duplicate closure の evidence が弱い

この “closed as duplicate” は、見かけ上は triage success に見える。 しかしそれを current truth にすると、

• real incident が hidden になる
• support が wrong workaround を案内する
• future postmortem が誤る
• release frame が unsafe に進む

つまりこれは triage-corrupt success である。

PCE 2.0 では、triage における “速い closure” をそのまま success とみなさず、 evidence と routing integrity を問う必要がある。

---

review / recovery / reopen

bug triage は often asynchronous で、 後から新しい ticket や logs が届き、re-open される。

triage recovery point に残すべきもの

• normalized triage subject
• current reproduction verdict
• current duplicate judgment state
• blast radius note
• escalation pending / resolved state
• next legal routes
• stale conditions

later reopen の典型

• new ticket arrives from same release
• affected cohort larger than first seen
• prior “not reproducible” judgment becomes stale because new logs arrived
• old duplicate closure is challenged by new repro evidence

このとき PCE 2.0 では、 old triage state を current truth のまま使い続けるのではなく、

• invalidation
• re-open
• possibly re-escalation

を explicit に行う。

ここでも bug triage は transcript continuity ではなく recovery-aware process として扱われる。

---

triage から生まれる durable learning

このケースでは、少なくとも二つの learning が生まれうる。

1. failure memory

「coupon combination release では、symptom similarity だけで duplicate closure してはいけない。 version / root cause / decision inconsistency を確認すること」

これは high-value failure lesson になりうる。

2. operational memory candidate

「financial correctness 系 bug triage では、 reproduction・spec consistency・blast radius の三 branch を必須にする」

これは triage playbook candidate になりうる。 ただし one-off なら provisional でよく、 repeated reuse が確認されてから canonical operational memory に上げるのがよい。

3. governance note

「release rollout freeze decision は triage owner ではなく incident owner が retain する」

これは role / authority confusion を防ぐ governance note になりうる。

ここでも重要なのは、 triage thread 全部を memory にするのではなく、 future triage を改善する knowledge だけを bounded に抽出すること である。

---

このケースで見るべき process metrics

bug triage では、artifact 指標より routing / evidence / reopening が重要である。 少なくとも次が有効である。

Evidence Sufficiency Rate

初回 triage で enough evidence が揃っていたか。 support intake quality と triage package quality を示す。

Escalation Resolution Latency

escalation から routing decision までの時間。 incident threshold が高い領域では重要。

Handoff Completeness Rate

support → triage、triage → incident owner の package が十分だったか。

Rework / Reopen Rate

closed or routed 後に later reopen された割合。 triage quality の重要指標である。

Corrupt Success Rate

duplicate closure、not reproducible closure、low severity closure が later に invalidated された割合。 triage では特に重い。

Recovery Drift Rate

later session で triage recovery したとき、old triage subject や old evidence が stale だった割合。 asynchronous triage の quality を示す。

---

このケースが示していること

このケースを通して見える PCE 2.0 の主張は、少なくとも次のとおりである。

1. triage は routing frame である

bugfix frame でも incident frame でもない。 それらへ route を決めるための frame である。

2. bug report は current truth ではない

まず triageable subject に正規化されなければならない。

3. reproduction だけでは enough ではない

spec consistency と blast radius を見なければ route は決められない。

4. severity は件数だけで決まらない

financial correctness、rollout stage、rollbackability も入る。

5. human oversight は最後に必要になることがある

全部を人間がやる必要はないが、high-impact routing は human-backed authority が retain すべきことがある。

6. triage にも corrupt success がある

“速く閉じた” は success ではない。 それが current truth を汚すなら dangerous closure である。

7. triage からも durable learning が生まれる

失敗の分類、duplicate 判定の条件、financial correctness triage pattern などは memory 候補になりうる。

---

このケースの最終要約

この bug triage case を一文でまとめると、次のようになる。

PCE 2.0 における bug triage とは、 incoming report をそのまま bug と断定することではなく、 report を triage subject に正規化し、reproduction・spec consistency・blast radius を bounded branch として評価し、 その結果を join して、bugfix / incident / duplicate / hold / replan のどれが legal かを決め、 さらに stale closure や weak duplicate を current truth にしないよう governance と evidence を保ちながら routing する process frame である。

この意味で bug triage は、単なる backlog 整理ではない。 それは、PCE 2.0 において 曖昧な problem signal を governed continuation に変換する routing topology である。

---

このあとに読むとつながるページ

• Feature Delivery
• PR Review
• Process Frame
• Process Delta
• Parent-Child Process
• Branch and Join
• Escalation
• Rollback
• Checkpoint and Recovery
• Incident Ownership
• Outcome vs Process
• Corrupt Success
• Human Oversight
• Auditability