Process Metrics

定義

Process Metrics

Process Metrics とは、ある process frame、transition chain、actor interaction、handoff、approval topology、recovery flow、memory promotion flow に対して、
その process quality、procedural integrity、governance validity、continuity integrity、coordination efficiency、promotion discipline を
観測可能な形で測るための指標群 である。

それは単なる activity count ではなく、
what happened in the process を decision-relevant signal に変換するための metric であり、
subject、scope、formula、granularity、evidence source、interpretation、actionability を持つ。

より短く言えば、Process Metrics とは
「この process は、どれだけ正しい責任構造と統治条件のもとで、どれだけ継続可能かつ再利用可能な形で進んだか」を測る指標
である。

PCE 2.0 において metrics は、結果物の品質そのものではありません。
metrics は、process を 見えるものにする観測面 です。
そしてその観測結果が、Eval Contract、Approval Points、Memory Promotion Rules の改善につながるとき、初めて意味を持ちます。

---

なぜ Process Metrics が必要なのか

Outcome vs Process で述べたように、PCE 2.0 は

• 何ができたか
• それがどのように成立したか

を分けて評価します。

しかし process evaluation を「その都度の定性的判断」だけにすると、次の問題が起きます。

1. 問題が見えても、継続的に改善できない

handoff が弱い、approval が重い、rework が多い、recovery が壊れやすい、といった問題があっても、
観測指標がなければ改善前後を比べられません。

2. governance failure が output の裏に隠れる

見かけ上成功した output の背後で、

• gate bypass
• unauthorized action
• stale context usage
• memory pollution

が起きていても、結果物だけでは見えません。

3. multi-actor process のボトルネックが分からない

どこで process が詰まっているのかは、しばしば artifact を見ても分かりません。
詰まっているのは、

• approval
• handoff
• evidence collection
• recovery
• promotion review

かもしれません。

4. durable state を汚すパターンが把握できない

何を memory として残した結果 future process が改善し、何を残した結果悪化したのかは、
promotion precision や pollution を見ないと分かりません。

5. process の健全性が「印象」に依存する

metrics がないと、
「最近なんとなくうまくいっていない」
「handoff が雑な気がする」
といった印象論に留まりやすくなります。

PCE 2.0 における Process Metrics は、こうした問題を
traceable で intervention-coupled な signal に変換するために必要です。

---

Process Metrics は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておきます。

1. 単なる outcome 指標ではない

artifact correctness、売上、テスト通過率だけでは process metric にはなりません。
それらは outcome 側の指標であり、process metric は別軸です。

2. 単なる activity 指標ではない

• step 数
• コメント数
• token 数
• prompt 長
• commit 数

は、そのままでは process quality を表しません。
activity が多いことは、良い process を意味しません。

3. 単なる runtime telemetry ではない

CPU 使用率、API latency、request count は運用情報として重要でも、
それだけでは process semantics を表しません。

4. 単なる compliance チェックではない

ある rule を守ったかどうかは重要ですが、
process metric はそれを継続的・比較可能に観測するための指標です。

5. 単なる総合スコアではない

PCE 2.0 では process を一つの scalar に潰すべきではありません。
handoff quality と promotion discipline と recovery integrity は、同じ軸では測れません。

6. approval や eval そのものではない

metrics は、approval や eval の材料にはなりますが、それ自体が ratification や verdict ではありません。

---

PCE 2.0 における位置づけ

Process Metrics は、PCE 2.0 の中で次のような位置にあります。

1. Metrics は観測する

何が起きたかを測る。

2. Eval Contract は判断基準を定める

何を pass / fail とするかを定める。

3. Approval Point は authority を行使する

どの subject を採用してよいか ratify する。

4. Memory Promotion Rules は durable 化を選別する

何を future process の前提として残してよいかを決める。

つまり Process Metrics は、
governance と evaluation の代わりではなく、それらを改善し、監視し、調整するための観測層
です。

---

Process Metrics の設計原理

PCE 2.0 では、process metric は少なくとも次の原理で設計されるべきです。

1. Decision-coupled

その指標が悪化 / 改善したとき、何を変えるのかが言えなければなりません。
改善行動に結びつかない metric は vanity metric になりやすいです。

2. Frame-scoped

metric は、どの frame、phase、subject type、risk tier に対して有効かを持つべきです。
異種の process を無造作に混ぜると解釈が壊れます。

3. Transition-grounded

可能なら metric は、transition、gate、delta state、handoff package、recovery point に基づいて計測されるべきです。
これにより traceability が上がります。

4. Leading / Lagging paired

先行指標と事後指標を組で持つべきです。
たとえば speed だけを追うと governance failure を見落としやすくなります。

5. Subject-type aware

artifact、decision、failure memory、operational memory、recovery point は、同じ metric 解釈にしてはなりません。

6. Anti-collapse

可能な限り single score に潰さず、複数の facet を維持すべきです。
process の欠陥は、しばしば特定 facet に局所的に現れます。

7. Traceable to evidence

metric の値は、可能なら evidence refs、transition refs、gate refs に遡れるべきです。

---

基本的な metric family

PCE 2.0 では、Process Metrics を少なくとも次の family に分けると扱いやすいです。

1. Procedural Integrity Metrics
2. Coordination / Handoff Metrics
3. Governance / Approval Metrics
4. Recovery / Continuity Metrics
5. Evaluation Coverage Metrics
6. Memory Discipline Metrics
7. Cross-axis Health Metrics
8. Process Efficiency Metrics

以下、それぞれを定義します。

---

1. Procedural Integrity Metrics

これは、required process が本当に守られているかを測る family です。

Required Transition Coverage (RTC)

その frame / phase で要求される transition が、どれだけ実際に踏まれたかを測ります。

RTC = 完了した必須 transition 数 / 適用可能な必須 transition 数

これは高いほどよいですが、
不要な transition を増やして分母・分子を操作してはなりません。
対象は「その frame に本当に必要な遷移」に限定されるべきです。

Gate Bypass Count (GBC)

required gate を満たさずに実行された illegal transition の数です。

GBC = 未解決の blocking gate を抱えたまま実行された transition 数

これは通常、0 が望ましい hard failure metric です。
process の健全性に直接関わるため、単なる warning にすべきではありません。

Scope Violation Rate (SVR)

scope 外 action や scope 外 delta の割合を測ります。

SVR = scope violation と判定された action または delta 数 / governed action または delta 総数

これは capability surface や policy binding の問題を示すことがあります。

Stale Context Execution Rate (SCER)

invalidated 済みの local context を再コンパイルせずに用いた実行割合を測ります。

SCER = stale context 上で行われた governed action 数 / governed action 総数

PCE 2.0 では context freshness が重要なので、この metric は long-running process で特に効きます。

---

2. Coordination / Handoff Metrics

これは multi-actor process の継続性を測る family です。

Handoff Completeness Rate (HCR)

required な handoff package 要素が揃っていた割合です。

HCR = 必須フィールド・evidence・next action を満たした handoff 数 / 総 handoff 数

ここでいう必須要素には、少なくとも

• goal slice
• transferred / retained responsibility
• relevant evidence
• pending gates
• expected output

が含まれます。

Handoff Loss Rate (HLR)

handoff により失われた、または target が再構築を強いられた continuity の割合です。

HLR = target 側で欠落・再調査・再説明が必要になった required handoff item 数 / required handoff item 総数

これは高いほど悪い指標です。
handoff quality の直接指標として使えます。

Return Contract Satisfaction Rate (RCSR)

child frame や delegated actor が、期待された return contract を満たして返せた割合です。

RCSR = required return contract を満たした return handoff 数 / 総 return handoff 数

parent-child process の品質を見るのに有効です。

---

3. Governance / Approval Metrics

これは authority gate の重さと健全性を測る family です。

Approval Cycle Time (ACT)

approval submission から verdict までの時間です。

ACT = verdict timestamp - submission timestamp

これは短ければよいとは限りません。
極端に短い場合、review quality の低下が隠れていることがあります。
必ず Corrupt Success Rate や Rework Rate と合わせて読むべきです。

Approval Burden (AB)

承認1件あたりの active review cost です。

AB = active review effort / resolved approval subject 数

active review effort は、理想的には実作業時間ですが、取得できない場合は

• review turns
• required evidence bundle size
• comment / resolution count

などを proxy にしてもよいです。
ただし wall-clock time だけを burden とみなすのは粗いです。

Unauthorized Action Rate (UAR)

authority または capability を持たない actor による action の割合です。

UAR = unauthorized action attempt または execution 数 / governed action 総数

0 に近いことが望ましい hard governance metric です。

Escalation Resolution Latency (ERL)

escalation が起きてから、次の合法的進行方針が確定するまでの時間です。

ERL = escalation resolution timestamp - escalation timestamp

incident-heavy な process では重要です。

---

4. Recovery / Continuity Metrics

これは長時間 process の再開可能性を測る family です。

Checkpoint Coverage (CC)

意味のある critical boundary のうち、実際に checkpoint が切られた割合です。

CC = checkpoint された critical boundary 数 / 遭遇した critical boundary 数

critical boundary は frame の checkpoint policy で定義されるべきです。
多すぎても少なすぎても問題になります。

Recovery Success Rate (RSR)

recovery が legal resume につながった割合です。

RSR = recover 後に legal resume へ進めた件数 / recovery attempt 数

strict に見るなら「resume へ進めた件数」でよく、
広く見るなら「resume / justified replan / justified rollback に進めた件数」を別 metric にしてもよいです。

Recovery Latency (RL)

recover 開始から、最初の legal next transition が取られるまでの時間です。

RL = first legal next transition timestamp - recovery start timestamp

長いほど悪いとは限りません。
drift reconciliation が必要なら一定の latency は合理的です。

Recovery Drift Rate (RDR)

recover 時に state / governance / scope drift が検出され、
そのままの resume が不可能だった割合です。

RDR = replan・revalidation・rollback を要した recovery 数 / recovery attempt 数

これは process の不安定さだけでなく、checkpoint の古さや governance change の多さも示します。

---

5. Evaluation Coverage Metrics

これは evaluation が process の中でどれだけ正しく機能しているかを測る family です。

Eval Coverage Ratio (ECR)

mergeable または promotable subject のうち、required eval path を完了した割合です。

ECR = required eval を完了した subject 数 / eval-required subject 数

No merge without eval を実際に運用できているかを見る基本指標です。

Evidence Sufficiency Rate (ESR)

最初の提出時点で required evidence を満たしていた割合です。

ESR = first submission で evidence 要件を満たした subject 数 / submitted subject 数

低い場合、handoff quality、return contract、context compilation、approval package design の改善余地があります。

Blocking Evaluator Failure Rate (BEFR)

blocking evaluator によって fail した割合です。

BEFR = blocking evaluator により fail した subject 数 / blocking evaluation 対象 subject 数

この値自体に善悪はありません。
高すぎる場合は upstream quality か contract 設計に問題があるかもしれません。
低すぎる場合は evaluator が弱すぎる可能性もあります。

---

6. Memory Discipline Metrics

これは durable state をどれだけ良い形で育てられているかを測る family です。

Memory Promotion Yield (MPY)

promotion candidate のうち、実際に durable item へ昇格した割合です。

MPY = promoted item 数 / memory candidate 数

高ければよいとは限りません。
高すぎる場合、過剰 promotion の可能性があります。

Memory Promotion Precision (MPP)

promoted item のうち、後に meaningful reuse され、noise / defect と判定されなかった割合です。

MPP = later meaningful reuse され、retracted / noise 判定されなかった promoted item 数 / promoted item 数

これは lagging metric です。
future frame での実利用を見ないと評価できません。

Memory Pollution Rate (MPolR)

promoted item のうち、後で stale / duplicate / weak-provenance / low-value と判定された割合です。

MPolR = 後に汚染要因と判定された promoted item 数 / promoted item 数

これは低いほどよいです。
durable state の健全性に直接関わります。

Time to First Reuse (TTFR)

memory が promote されてから、初めて meaningful に再利用されるまでの時間です。

TTFR = first meaningful reuse timestamp - promotion timestamp

短いほどよいとは限りませんが、
極端に長いものは retention / archive の見直し対象になります。

---

7. Cross-axis Health Metrics

これは Outcome vs Process の二軸をつなぐ family です。

Corrupt Success Rate (CSR)

outcome pass だが process fail だった subject の割合です。

CSR = outcome-pass かつ process-fail subject 数 / outcome-pass subject 数

これは PCE 2.0 において非常に重要な指標です。
見かけ上の成功が canonical 化される危険を示します。 詳しくは Corrupt Success を参照します。

Productive Failure Yield (PFY)

upstream outcome は fail したが、durable learning を残した割合です。

PFY = outcome-fail だが promotable learning を残した subject 数 / outcome-fail subject 数

これは failure をどれだけ process learning に変換できているかを示します。

Rework Rate (RWR)

一度提出された subject が、reject / request changes / rollback で戻された割合です。

RWR = 再作業へ戻された submitted subject 数 / submitted subject 数

これは悪いとは限りません。
早期に問題を捕捉できている場合もあります。
ただし高止まりしているなら approval package や execution quality の問題が疑われます。

Delta-to-Merge Latency (DML)

delta emission から canonical merge までの時間です。

DML = merge timestamp - delta emission timestamp

短いほどよいとは限りません。
必要 gate を飛ばしていないかとセットで読むべきです。

---

8. Process Efficiency Metrics

これは integrity を壊さずに process を回せているかを見る family です。
効率は重要ですが、必ず integrity 系 metric と paired で解釈すべきです。

Coordination Overhead Ratio (COR)

subject を前に進めるために必要だった coordination action の比率です。

COR = coordination transition 数 / productive transition 数

coordination transition には、handoff、approval submission、evidence request、resubmission などが含まれます。
高すぎる場合、process topology が重すぎるかもしれません。

Escalation Frequency (EF)

process がどれだけ escalation に依存しているかを示します。

EF = escalation transition 数 / frame または subject 総数

高い場合は authority design が粗いか、上流の曖昧性が大きい可能性があります。

Review-to-Change Loop Count (RCLC)

一つの subject が approve されるまでに何回 review-change loop を回ったかです。

RCLC = subject ごとの request_changes / rework loop 回数

RWR より granular に process turbulence を見たいときに使えます。

---

Leading Metrics と Lagging Metrics

PCE 2.0 では、metrics を先行指標と事後指標に分けて扱うと有効です。

Leading Metrics

早い段階で future failure を示唆する指標です。

• HCR
• ESR
• RTC
• GBC
• CC
• UAR

Lagging Metrics

あとから見て process の帰結を示す指標です。

• CSR
• MPP
• MPolR
• RWR
• DML
• RDR

重要なのは、
leading だけでも lagging だけでも足りない
ということです。

たとえば、

• HCR が高いのに CSR も高い
  → handoff は形式的に揃っているが、governance や eval が弱いかもしれない

• MPY が高いのに MPP が低い
  → memory を昇格しすぎているかもしれない

• ACT が低いのに RWR が高い
  → 承認は速いが浅いかもしれない

こうした paired reading が必要です。

---

Pair で読むべき metrics

Process Metrics は、単独で最適化すると壊れやすいです。
PCE 2.0 では、少なくとも次の pairing を推奨します。

Speed × Integrity

• ACT × CSR
• DML × GBC
• RL × RDR

Yield × Precision

• MPY × MPP
• promoted count × MPolR

Burden × Quality

• AB × RWR
• AB × CSR
• COR × outcome success

Continuity × Governance

• HCR × UAR
• CC × RSR
• HLR × ESR

短く言えば、
速さは integrity と、量は precision と、軽さは quality と組で読む
のが基本です。

---

Metrics は単一スコアへ潰すべきか

原則として、潰すべきではありません。

理由は単純です。
handoff loss と memory pollution は、同じ原因でも同じ対策でもありません。
単一スコアにすると、どこが壊れているか分からなくなります。

ただし、運用上どうしても summary signal が欲しい場合は、

• family ごとに scorecard を作る
• hard failure metrics を別扱いにする
• raw metrics を必ず残す

という条件付きで aggregated view を作る方がよいです。

PCE 2.0 の基本は、
multi-facet visibility です。

---

Granularity と正規化

metric は scope と粒度を持たなければ解釈できません。
少なくとも次の granularity を区別するとよいです。

Subject-level

個別の artifact delta、decision delta、memory candidate に対する指標。

Frame-level

一つの process frame の中で集計した指標。

Actor-level

特定 actor / bundle / role に紐づく指標。

Project-level

一定期間・一定 scope で project 全体を通して集計した指標。

また、比較の際には少なくとも次で正規化を考えるべきです。

• frame type
• risk tier
• subject kind
• approval topology
• actor count
• required evidence volume

たとえば、approval-heavy frame と lightweight frame の ACT をそのまま比べても意味が薄いです。

---

Process Metrics の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置けます。

process_metric_definition:
  metric_id:
  name:
  intent:
  family:
  subject_kind:
  scope:
    frame_type:
    risk_tier:
    phase:
  formula:
  numerator_definition:
  denominator_definition:
  unit:
  leading_or_lagging:
  evidence_sources:
  interpretation_notes:
  paired_metrics:
  action_on_threshold_breach:
  provenance:

記録側は、たとえば次のように置けます。

process_metric_record:
  metric_ref:
  measured_scope:
    project:
    frame:
    phase:
    actor:
    time_window:
  value:
  numerator:
  denominator:
  evidence_refs:
  notes:
  captured_at:

このスキーマで重要なのは、次の点です。

1. metric definition と measurement record を分ける
2. intent と actionability を持つ
3. paired metrics を持てる
4. evidence refs に遡れる
5. scope を明示する

---

小さな例

「checkout にクーポン併用制約を追加する」frame を考えます。

ケース1: reviewer handoff が弱い

• diff は渡った
• しかし rollback note が欠けていた
• reviewer が追加情報を要求し、approval が遅れた

このとき、

• HCR は低下
• ESR も低下
• ACT は増加

します。
ここで ACT だけを見ると「approver が遅い」と誤解するかもしれませんが、
HCR と ESR を見ると、問題は review handoff package の弱さだと分かります。

ケース2: artifact outcome は良いが governance が壊れている

• tests は通った
• diff も妥当
• しかし required reviewer approval を経ずに merge された

このとき、

• outcome evaluation は良
• GBC は悪化
• CSR は上昇

します。
PCE 2.0 では、この成功は corrupt success とみなされます。

ケース3: memory を昇格しすぎている

• 毎回 playbook candidate を大量に promote している
• しかし後でほとんど再利用されず、一部は stale / duplicate と判定される

このとき、

• MPY は高い
• MPP は低い
• MPolR は高い

という形になります。
この場合、memory promotion rules を tighten すべきです。

---

最初に導入するなら何を測るべきか

すべてを一度に測る必要はありません。
PCE 2.0 の初期導入なら、まず次の starter set が実用的です。

1. GBC — gate bypass を許さない
2. HCR — handoff を雑にしない
3. ACT — approval の重さを見る
4. ECR — required eval を飛ばさない
5. CC — long-running process の継続性を確保する
6. RSR — recoverability を測る
7. RWR — rework の多さを見る
8. CSR — 見かけ上の成功を見抜く
9. MPP — memory の価値を見る
10. MPolR — durable state の汚染を防ぐ

この10個で、

• integrity
• continuity
• governance
• learning discipline

の主要面を最低限カバーできます。

---

Process Metrics の不変条件

PCE 2.0 では、少なくとも次の不変条件を置きます。

1. No process metric without decision use

その metric が悪化したとき何を変えるか言えなければならない。

2. No activity count masquerading as process quality

単なる量的 activity を process quality と誤認してはならない。

3. No single scalar process score by default

process は multi-facet であり、一つのスコアに潰すべきではない。

4. No metric without explicit scope

frame type、subject kind、time window のない metric は解釈不能である。

5. No speed metric without integrity pair

速さだけを追って governance failure を隠してはならない。

6. No yield metric without precision pair

昇格量だけを追って pollution を増やしてはならない。

7. No metric should replace eval or approval

metrics は観測であって、ratification や admissibility 判定そのものではない。

8. Process metrics must remain traceable

可能なら transition、gate、delta、recovery point に遡れるべきである。

---

いつ新しい Process Metric を切るべきか

新しい metric を増やすべき典型条件は次のとおりです。

1. 同じ failure が何度も起きるのに見えていないとき

観測不足です。metric を足す価値があります。

2. 既存 metric では原因の切り分けができないとき

たとえば ACT だけでは handoff 問題か approver 問題か分からない場合です。

3. 新しい governance surface を導入したとき

新しい approval topology、promotion rule、policy engine が入ったときです。

4. memory promotion が重要になったとき

durable state の質を保つには専用 metrics が必要です。

5. recovery / handoff が process の主要部分になったとき

long-running 化により continuity metrics が必要になります。

逆に、単に「取りやすいから」という理由で metric を増やすべきではありません。

---

最低限の自己点検

ある metric 設計が PCE 2.0 的に十分かどうかは、次で点検できます。

1. その metric は outcome ではなく process を測っているか
2. 何を改善するための metric か言えるか
3. frame / subject / phase / actor の scope があるか
4. numerator / denominator が明確か
5. evidence refs に遡れるか
6. paired metrics があるか
7. single score に潰していないか
8. approval や eval の代わりにしていないか
9. durable state の健全性にどう関わるか言えるか
10. long-running / multi-actor process に対して意味があるか

このどれかが欠けるなら、その metric はまだ PCE 2.0 の意味で process-aware ではありません。

---

関連する概念

Process Metrics は、PCE 2.0 の評価観測層として、次の概念と強く結びつきます。

• Outcome vs Process
• Eval Contract
• No merge without eval
• Process Frame
• Process Delta
• Responsibility Bundle
• Governance Surface
• Handoff
• Approval Points
• Checkpoint and Recovery
• Memory Promotion Rules
• Durable Project State

---

暫定的なまとめ

Process Metrics が言っていることは、最終的には次の一文に集約できます。

process は、よい結果が出たかどうかだけでは改善できない。
handoff、gate、approval、recovery、promotion、governance のどこで continuity が損なわれ、どこで project state が汚れ、どこで process が健全に働いているかを、観測可能な指標として持ってはじめて改善できる。

PCE 2.0 において metrics は、output の代用品ではありません。
それは process を見えるものにし、evaluation・governance・memory discipline を改善可能にする観測構造です。

だから Process Metrics は、単なるダッシュボード項目ではありません。
それは、PCE 2.0 において process の健全性を継続的に把握し、壊れ方を早期に発見し、設計を更新するための観測面 です。