PR Review

このページは、PR review を「コード差分を見る工程」としてではなく、 artifact の妥当性、process の妥当性、authority による ratification、later merge / rollback / memory への影響 を同時に扱う process frame として捉えるためのケーススタディである。

ここでいう PR は GitHub / GitLab など特定製品の UI を指しているのではない。それは、ある artifact delta を中心に、

review 用 handoff package

required evidence

evaluator signals

approval gate

rework / rollback / escalation path

を束ねた review object として扱われる。

このページの狙いは、PR review を PCE 2.0 のほぼ全要素が交差する典型ケースとして示すことにある。

このケースの目的

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

PR review は diff を読むこと ではなく、ひとつの process frame であること
reviewer は artifact だけでなく process を評価していること
AI reviewer と human reviewer はともに actor だが、責任は対称ではないこと
approve 済み であっても、code changes によって easily stale になること
見かけ上 merge 可能 でも、そのまま merge すると Corrupt Success になる場合があること
review の結果は comment だけでなく Process Delta として扱えること
review からも durable learning が生まれうること

PR review は、PCE 2.0 を理解するうえでとてもよいケースである。理由は単純で、実務では PR review がしばしば次の交点になっているからである。

approval
evaluation
human oversight
context budget
stale invalidation
rollback
memory discipline

シナリオ

前の Feature Delivery ケースと同じく、対象は checkout のクーポン併用制約追加である。今回はその中でも、implementation 完了後の PR review フェーズだけを拡大して見る。

状況

feature.checkout.coupon-combination frame の implementation child が完了し、 delta.feature.checkout.coupon-combination.v3 が reviewer に handoff された。 CI の required regression suite は pass。ただし unresolved issue として stacked discount rounding edge case が残っている。

さらに review の途中で author 側が追加 commit を push し、 old review context と old approval が stale になる可能性がある。

このシナリオがよいのは、PR review 特有の問題が全部入っているからである。

diff は正しそうに見える
CI も通っている
しかし approval はまだ current ではない
さらに update により old approval が stale になりうる
reviewer は artifact だけでなく process も見る必要がある
AI reviewer は useful だが final ratification は human が持つ
review から checklist candidate や failure lesson も生まれうる

全体像

この review case を process として短く書くと、次のようになる。

implementation child frame
  -> emit process delta
  -> review handoff package
  -> review frame instantiate
  -> intake validation
  -> AI / CI / human evaluation
  -> human approval point
  -> approve | request_changes | escalate
  -> if new commit arrives: invalidate prior review state
  -> reopen review
  -> merge-ready or rollback / rework path
  -> optional review-derived memory candidates

ここで重要なのは、PR review が単に “最後に誰かが見る工程” ではないことだ。それは

handoff
context compilation
evaluation
approval
stale invalidation
possible rollback / escalation
memory extraction

を持つ独立の review process frame である。

なぜ PR review は PCE 2.0 的に重要なのか

PR review を従来の雑な理解で見ると、次のように見える。

diff を見る
問題なければ approve
CI が通っていたら merge

しかし PCE 2.0 では、それは粗すぎる。本当には次を見ているからである。

1. review subject は diff だけではない

reviewer が本当に見ているのは、少なくとも次である。

artifact delta
required evidence bundle
current scope constraints
rollback feasibility
pending unresolved issues
current approval / evaluation dependencies
whether this subject is still the same subject after later edits

2. approve は evaluation と同じではない

reviewer は

artifact を評価し
process を評価し
その上で authority に基づいて ratify する

ことがある。この三つを混同すると、review は rubber-stamp になる。

3. PR review は stale になりやすい

レビュー途中に author が push し直した瞬間、

old diff summary
old comments
old approval assumption
old AI review finding set

が stale になることがある。これを明示的に扱えないと、Corrupt Success が起こりやすい。

4. PR review は process memory を生む

よい review は、差分を通すか落とすかだけではなく、次のような memory candidate を生みうる。

reusable review heuristic
recurring anti-pattern
scope violation lesson
rollback-check checklist

この意味で PR review は、PCE 2.0 の縮図である。

Review frame としての PR

このケースでは、PR review を parent feature frame の child frame として扱う。その方が、global goal と retained authority をきれいに表せるからである。

review frame

process_frame:
  frame_id: review.checkout.coupon-combination.pr-17
  parent_frame_id: feature.checkout.coupon-combination
  frame_kind: review

  goal: >
    提出された artifact delta と付随 evidence を評価し、
    merge-ready とみなしてよいか、
    あるいは request changes / escalate / rollback が必要かを判断する。

  success_criteria:
    - review subject が明示されている
    - required evidence bundle が確認されている
    - outcome/process evaluation が完了している
    - approval verdict または request_changes / escalate verdict が出ている
    - stale な review state が current 扱いされていない

  scope:
    in_scope:
      - submitted code diff
      - related tests
      - rollback note
      - unresolved implementation notes
      - merge admissibility judgment
    out_of_scope:
      - product-level goal redefinition
      - payment gateway scope expansion
      - final release approval
    assumptions:
      - approved spec remains current
    non_goals:
      - feature 完了の最終 accept
      - release decision

  actors:
    - coding_agent
    - ai_review_assistant
    - ci_evaluator
    - reviewer
    - product_owner
    - memory_writer
    - checkpoint_manager

  approval_points:
    - ap.review.checkout.coupon-combination.pr-17.code-review

  eval_contract:
    - eval.review.checkout.coupon-combination.artifact.v1
    - eval.review.checkout.coupon-combination.process.v1
    - eval.review.checkout.coupon-combination.memory-candidate.v1

  memory_write_policy:
    allowed_targets:
      - pending_candidates
      - failure_memory
    prohibited_targets:
      - raw_comment_thread_as_canonical_memory

  recovery_strategy:
    checkpoint_policy:
      - after_intake_validation
      - after_ai_review_findings
      - before_human_approval
    rollback_anchor_policy:
      - last_reviewable_diff_state
    resume_conditions:
      - invalidate_stale_review_contexts
      - rebind_current_diff_and_ci_refs
    escalation_path:
      - product_owner

この frame で重要なのは、review が

implementation の continuation ではあるが
独自の success criteria を持ち
独自の approval point と eval contract を持ち
stale invalidation と recovery を独立に持つ

ことだ。

actor と責任の非対称性

このケースでは、actor は複数いるが責任は対称ではない。ここが PCE 2.0 的に重要である。

coding_agent

review source package を出す
request changes が来た後の rework executor
approve はできない

ai_review_assistant

advisory evaluator
diff clustering
suspicious pattern surfacing
final approval はできない

ci_evaluator

blocking outcome evaluator
required regression signal を出す
process judgment や approval はできない

reviewer（human）

process-aware evaluator
code review approval authority
request changes / escalate / reject できる
direct code edit はしない

product_owner

goal / scope ambiguity の escalation sink
incident / rollback decision
feature-wide reframe authority

memory_writer

review-derived memory candidate の durable write authority
review approve そのものは持たない

つまりこのケースは、 AI reviewer も actor であり、CI evaluator も actor だが、approve できるのは human reviewer である という actor symmetry / responsibility asymmetry を非常に明確に示す。

Step 0: Review は intake validation から始まる

PCE 2.0 では、PR review は diff を読むことから始まらない。まず review subject が review 可能な形で束ねられているか を確認する。

review intake に必要なもの

current diff ref
current approved spec summary
CI report ref
rollback note
unresolved issues list
current scope constraints
source handoff package
if present, previous review state refs

ここで起こりうる verdict

ready_for_review
insufficient_evidence
stale_submission
escalate

重要な点

もしここで必要 bundle が足りないなら、 reviewer は approve / reject に進むべきではない。まず insufficient_evidence を返すべきである。

これは実務でしばしば省略されるが、PCE 2.0 では重要である。 bundle が足りない review は、後で corrupt success を生みやすいからだ。

Step 1: reviewer 用 context を compile する

reviewer は author の full implementation trace をそのまま読むべきではない。 reviewer 用の Actor-local Compiled Context が必要である。

reviewer の active context に入るもの

goal slice この diff が approved spec と scope に整合しているか判断し、approve / request changes / escalate を返す
required evidence refs diff、CI report、spec summary、rollback note
pending gates code review approval
unresolved issues stacked discount rounding edge case
relevant decisions payment gateway change is out of scope
stop conditions missing evidence, scope violation, rollback unclear
expected output verdict, comments, rationale if needed

active に入れないもの

coding agent の raw iterative scratchpad
unrelated module notes
old stale review package
production credentials
unrelated historical PR noise

by-reference で十分なもの

full implementation trace
complete ADR
full CI log
old comment thread history

ここで重要なのは、reviewer context が artifact judgment + process judgment + approval gate awareness を同時に持つことだ。

Step 2: AI reviewer と CI evaluator の役割

この case では、人間 reviewer の前に二つの actor が先行 signal を出す。

CI evaluator

CI evaluator は blocking evaluator として働く。

required regression suite
test flakiness signal
obvious build failure
changed file/test relation mismatch

CI pass は必要条件でありうるが、十分条件ではない。

AI review assistant

AI review assistant は advisory evaluator として働く。

典型的に次を返す。

changed file clusters
potential scope drift hints
repetitive anti-pattern detection
risk summary
unresolved issue grouping
“parts worth human attention” の抽出

重要なのは、AI review assistant は useful でも final ratification authority を持たない ことだ。この非対称性を明示しないと、AI review summary が implicit approval のように扱われやすい。

Step 3: healthy review path

まずは正常系を見ておく。

reviewer が見るもの

diff は approved spec に整合しているか
out-of-scope file 変更はないか
rollback path は説明可能か
unresolved issue は accept 可能な residual risk か
CI result は current diff に対して current か
AI review hints と human reading が大きく矛盾しないか

verdict

この時点で reviewer は、たとえば次のような判断を出せる。

approve
request_changes
insufficient_evidence
escalate

正常な approve の意味

ここでの approve は、

outcome evaluation を通り
process evaluation も通り
reviewer bundle に基づく authority で
next transition として merge-ready path を解禁する

という意味を持つ。

つまり approve は単なるコメントではなく、 review frame の lifecycle と parent feature frame の next transitions を変える。

PR review 特有の問題: 追加 commit で old approval が stale になる

このケースの核心はここである。 reviewer が一度 diff v3 を見て approve しかけた直後に、author が commit v4 を push したとする。変更理由は「small fix」と説明されているが、実際には payment gateway 関連 file が一つ混入していた。

表面上どう見えるか

tests: green
diff summary: almost same
author message: minor follow-up
old review comments: mostly resolved

つまり 見かけ上はそのまま通せそう である。

しかし PCE 2.0 的には何が起こるか

old diff is no longer current subject
old review context is stale
old CI may be stale if not bound to current head
old approval preconditions are invalidated
current scope must be rechecked

つまり、old approval は current truth ではなくなる。この時点で PCE 2.0 の review frame は re-open されるべきである。

Step 4: stale review state を invalid にする

PCE 2.0 では、新しい commit が review subject を materially 変えたなら、少なくとも次を invalid にする必要がある。

invalidated されるもの

prior review-ready summary
prior approval candidacy
old reviewer local context
AI review findings if tied to old diff
old CI report if head mismatch exists
partial merge-ready state

lifecycle の変化

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

pending_approval
  -> invalidated
  -> active_review_reopened

あるいは more explicitly には、

completion_ready
  -> rollback_pending
  -> active

でもよい。重要なのは、「approve されかけていた状態」を current のまま保持しないことだ。

これをしないと何が起こるか

見かけ上、レビュー済みで CI も通っているので、そのまま merge したくなる。しかしこれは PCE 2.0 的には Corrupt Success の典型 である。

Corrupt Success subcase

この case を PCE 2.0 の Corrupt Success として書くと、次のようになる。

surface

current diff v4 も tests は pass
previous review was almost done
author says “small follow-up”
merge 可能に見える

hidden corruption

previous approval context is stale
previous scope judgment no longer binds current diff
new out-of-scope file changed
old review package omitted this because it did not exist yet

もしこのまま success と扱うと何が起こるか

wrong scope change が merge path に乗る
reviewer approval の意味が崩れる
“reviewed and approved” という audit line が虚偽に近づく
future incident で blame/repair が難しくなる

つまりこれは単なる “review漏れ” ではなく、 success status を current として採用すると project reality を汚染する状態 である。

PCE 2.0 では、この状態を success のまま通してはならない。

Step 5: re-opened review で reviewer がすること

review が再開されたら、reviewer は old context を使い回さない。 current head と current evidence に対して、新しい selection / compaction を行う。

reviewer が再確認すること

current head diff に対して CI が current か
newly changed files are in-scope か
rollback note は still valid か
prior unresolved issues の status は変わったか
old comments resolution は current diff に still applicable か
AI review summary は current subject に rebind されているか

今回の case の結果

reviewer は payment gateway file change を見つける。これは review authority の範囲内では「scope violation」であり、軽い request_changes で済むか、incident / escalation が必要かを判断しなければならない。

ここでは次の二択がある。

local rework with clear rollback path
escalate to product owner because scope boundary itself is questioned

Step 6A: request changes path

もし変更が明確に accidental で、rollback path も明確なら、 reviewer は request_changes を返せる。

その意味

current subject is not approvable
parent feature frame is not blocked globally
coding_agent に rework が handoff される
review frame remains open
old stale approval remains invalid

coding_agent に返す package

exact out-of-scope file refs
why current diff cannot be approved
rollback / revert expectation
whether CI rerun is required
whether old comments still apply

ここで review は失敗ではなく、 bounded correction loop に入る。

Step 6B: escalate path

もし reviewer が次を local に決められないなら escalation する。

payment gateway touch が本当に out-of-scope か再確認が必要
author claims this change is necessary for correctness
rollback path is unclear
blast radius may exceed review frame scope

この場合 reviewer は product_owner へ escalation する。

escalation package の中身

current diff refs
old and new review state comparison
why old approval is invalid
current scope conflict
rollback uncertainty
requested decision:
- confirm out-of-scope and order rollback
- or authorize scope reframe

ここで reviewer は decision burden を上位へ返すが、 evidence trace と review continuity は retain する。

Step 7: review の output は Process Delta になる

PR review の結果は、コメント欄に散らばるだけでは弱い。 PCE 2.0 では、それを Process Delta として明示的に扱える。

approve path の delta 例

evaluation delta artifact outcome pass
evaluation delta process validity pass
status delta code_review_approval satisfied
decision delta residual risk acceptable within current scope

request changes path の delta 例

evaluation delta process fail due to scope violation
status delta approval not granted
coordination delta rework requested
failure delta stale review state invalidated

escalate path の delta 例

status delta review suspended pending escalation
governance delta local approval path insufficient
incident / escalation delta scope conflict raised to product owner

重要なのは、review output が単なる prose comment ではなく、 later audit / rollback / metrics / learning に使える typed delta になることだ。

Step 8: review から生まれる memory candidate

PR review は artifact admissibility を決めるだけでなく、 future review のための knowledge を生みうる。

このケースで生まれうる candidate

1. Failure memory candidate

“minor follow-up commit invalidated prior approval and introduced out-of-scope file change”

2. Operational memory candidate

“PR review for pricing-related changes must always include rollback note + scope file map”

3. Governance note

“old reviewer approval does not survive head diff changes without explicit rebind”

4. Approved summary candidate

“review package should carry diff hash / CI hash / approval subject hash together”

何でも durable にしない

もちろん、comment thread 全部や reviewer の raw scratchpad をそのまま memory にしてはならない。ここでも Memory Promotion Criteria と Memory Writing が必要になる。

PR review と human oversight

このケースでは human oversight の意味もはっきり見える。

AI reviewer ができること

changed file clustering
suspicious region highlighting
repeated anti-pattern detection
review checklist prefill
comment draft generation

AI reviewer が持たないもの

final code review approval
exception authorization
residual risk acceptance
scope reframe approval
incident closure

human reviewer / product_owner が retain するもの

final ratification
scope conflict judgment
escalation resolution
rollback / replan decision
frame completion implications

つまり PCE 2.0 における human oversight は、 人間が全部見ること ではなく、 AI-assisted review を bounded autonomy のまま統治すること である。

PR review の recovery

review はしばしば一度で終わらない。夜をまたぎ、別 session に持ち越されることも多い。このとき PCE 2.0 は transcript 依存ではなく recovery semantics を要求する。

review recovery point が持つべきもの

current head ref
current review subject hash
pending approval state
required evidence refs
stale contexts list
unresolved issues
next legal verdicts

recover 時に必要なこと

current head unchanged か
CI still current か
spec unchanged か
prior review context is still valid か
escalation pending was resolved か

もし head が変わっていれば、recover は old review continuation をそのまま戻さず、 review_reopened として処理されるべきである。

この点でも PR review は、 Checkpoint and Recovery の良い実例になる。

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

PR review は、artifact quality よりも process quality の計測が効く場面である。少なくとも次が有効である。

Handoff Completeness Rate

implementation → review の handoff bundle が十分だったか。 rollback note や unresolved issues が欠けていれば下がる。

Evidence Sufficiency Rate

最初の review submission 時に required evidence が揃っていたか。不足していれば review efficiency より前に intake quality が悪い。

Approval Cycle Time

approval submission から verdict までの時間。ただし短ければよいとは限らず、rework rate と対で見るべき。

Rework Rate

request changes がどれだけ多いか。高い場合、author package quality、scope clarity、AI review support の弱さなどが疑われる。

Corrupt Success Rate

tests pass かつ “looks approved” に見えるが、 stale review state や missing gate により actually unsafe な PR がどれだけあるか。

Stale Context Execution Rate

old review context や old approval assumption を current に使ってしまった割合。 PR review では非常に重要な指標である。

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

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

1. PR review は diff reading ではなく review frame である

goal、scope、approval point、eval contract、recovery strategy を持つ。

2. review subject は diff 単体ではない

artifact、evidence、rollback path、scope note、pending gates を束ねた review object である。

3. AI reviewer は useful だが authority は対称ではない

actor として対称でも、approval responsibility は対称ではない。

4. stale approval は current approval ではない

新しい commit が入れば、old review state は explicit に invalidated されるべきである。

5. “見た感じ大丈夫” は success ではない

それをそのまま merge-ready にすると Corrupt Success になることがある。

6. review の結果は durable learning にもなりうる

review は gate であるだけでなく、future process のための operational memory を生む場でもある。

このケースの最終要約

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

PCE 2.0 における PR review とは、提出された diff を見ることではなく、 current subject と current evidence と current scope を binding し直し、 AI / tool / human の非対称な責任配置のもとで、artifact と process の両方を評価し、 stale な成功を current success と誤認せず、 approve / request changes / escalate / rollback のどれが legal かを決め、その結果を delta として返し、必要なら future review のための memory 候補まで抽出する review process frame である。

この意味で PR review は、単なる最後の確認ではない。それは、PCE 2.0 において artifact admissibility、process integrity、human oversight、stale invalidation、memory discipline が交差する review topology である。