Process Frame

定義

Process Frame

Process Frame とは、PCE 2.0 における 境界づけられた仕事単位 である。
それは単なる task や step の名前ではなく、
goal、success_criteria、actors、responsibility allocation、capability boundary、constraints、approval points、eval contract、memory write policy、recovery strategy を持つ、
統治可能かつ評価可能な実行の器 である。

より短く言えば、Process Frame とは
「誰が、何を、どこまで、どの権限で、どの条件で進め、どう評価し、何を次へ残してよいか」を定義する枠
である。

PCE 2.0 において、開発はまず Process Frame として切り出されます。
その後で責任が配分され、各 actor に対して局所コンテキストが compile され、実行・承認・評価・差分昇格へと進みます。

つまり Process Frame は、Process-first を ontology として具体化した、最初の中心概念です。

---

なぜ Process Frame が必要なのか

PCE 2.0 が解こうとしているのは、単なる prompt 設計の問題ではありません。
本当に難しいのは、長時間・多段・多主体の仕事を、壊れずに、責任を失わずに、継続できる形で成立させることです。

そのためには、各作業単位について少なくとも次を答えられなければなりません。

• この仕事は何を達成するのか
• 何をもって成功とするのか
• 誰が何を担うのか
• 何をしてよく、何をしてはいけないのか
• どこで止まり、どこで承認されるのか
• どの評価を通ればよいのか
• 何を durable state に残してよいのか
• 失敗したらどこから再開するのか

これらをまとめて持つ枠が、Process Frame です。

言い換えると、Process Frame は
責任・権限・評価・記憶更新を伴う仕事を、ひとつの単位として成立させる最小の器
です。

---

Process Frame は何ではないか

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

1. 単なるタスクリストではない

「仕様確認 → 実装 → テスト」のような工程列だけでは、Process Frame にはなりません。
そこに goal、責任配分、停止条件、評価条件、記憶更新条件が必要です。

2. 単なる prompt ではない

Process Frame は、モデルへ送るテキストではありません。
prompt は frame から導出される一部にすぎません。

3. 単なる chat thread ではない

1つの thread は、1つの frame に対応する場合もありますが、必ずしも一致しません。
1つの frame が複数の session / run をまたぐこともあります。

4. agent そのものではない

agent は actor の一種です。
Process Frame は、actor を収める仕事単位であって、actor と同一ではありません。

5. runtime state そのものではない

frame は「どうあるべきか」を規定する枠です。
実行中の状態、承認待ち、失敗後の再計画などは runtime state の側に属します。

6. checkpoint そのものではない

checkpoint は frame の途中状態を保存したものです。
frame は checkpoint より上位にあります。

---

Process Frame が持つべき構成要素

Process Frame は、少なくとも次の構成要素から成ります。

1. Goal

その frame が達成しようとする仕事の中心目的です。
goal は、何を前進させるための frame なのかを定めます。

2. Success Criteria

何をもって「この frame は成立した」とみなすかを定めます。
goal が方向を与えるなら、success criteria は終了の判断基準を与えます。

3. Scope

何がこの frame の内側にあり、何が外側にあるのかを定めます。
scope が曖昧だと、責任・権限・評価の境界も曖昧になります。

4. Actors

この frame に参与する actor を定義します。
人間、AI agent、subagent、tool、CI、policy、approval gate などが入りえます。

5. Responsibility Allocation

各 actor に、どの責任が配分されているかを定義します。
ここでいう責任の最小単位は Responsibility Bundle です。

6. Capabilities

どの tools / data / environments / permissions を使えるかを定義します。
capability は自由な可能性ではなく、責任と整合した範囲で scope されます。

7. Constraints

予算、締切、禁止事項、ポリシー、品質要求など、frame の外形を制約する条件です。

8. Stop Conditions

どこで止まるのか、何が起きたら中断するのか、何が起きたら escalation / rollback / replan するのかを定めます。

9. Approval Points

どの局面で誰の承認が必要かを定義します。
execution が終わっても process が終わらないのは、この approval point があるからです。

10. Eval Contract

どの delta を、どの基準で、誰または何が評価するのかを定めます。
これは No merge without eval の前提です。

11. Memory Write Policy

何を durable state に昇格させてよいか、その authority と条件は何かを定めます。

12. Recovery Strategy

失敗・中断・承認待ちから、どの checkpoint / state を基点に再開するかを定めます。

---

Process Frame の最小基準

ある仕事単位が本当に Process Frame と呼べるかどうかは、次の問いに答えられるかで判断できます。

1. 何を達成するのか
2. 何をもって成功とするのか
3. 誰が goal owner / executor / approver / evaluator / memory writer / incident owner なのか
4. 何を使ってよく、何を使ってはいけないのか
5. どこで止まり、どこで承認されるのか
6. 何を durable state に残してよいのか
7. 失敗したらどこから再開するのか

この問いに答えられないなら、その単位はまだ Process Frame として十分に定義されていません。

---

最小スキーマ

PCE 2.0 の ontology としての最小スキーマは、次のように置けます。

process_frame:
  frame_id:
  parent_frame_id:
  goal:
  success_criteria:
  scope:
    in_scope:
    out_of_scope:
  actors:
  responsibility_allocation:
  capabilities:
    tools:
    data:
    environments:
    permissions:
  constraints:
  stop_conditions:
  approval_points:
  eval_contract:
  memory_write_policy:
  recovery_strategy:

このスキーマで重要なのは、context そのものが入っていない ことです。
context は frame から直接導出されるものではなく、
frame と responsibility allocation と state をもとに compile されるものです。

---

Responsibility Bundle と responsibility_allocation

ここは厳密に分けておきます。

Responsibility Bundle

Responsibility Bundle は、ある actor がある時点で持つ責任の束です。
たとえば次が含まれます。

• goal ownership
• execution
• capability authority
• approval authority
• evaluation authority
• memory write authority
• incident ownership

Responsibility Allocation

一方で frame が直接持つのは、単一の bundle ではありません。
frame が持つのは、どの actor にどの bundle を割り当てるか という配分情報です。

概念的には、次のように書けます。

responsibility_allocation(process_frame) =
  { actor_1 -> bundle_1, actor_2 -> bundle_2, ... }

この区別は重要です。
Process Frame の内部にあるのは「bundle 一個」ではなく、bundle の配分構造 です。

---

Process Frame と runtime state の違い

この区別もかなり重要です。

Process Frame

仕事単位の構造的定義。
何を、誰が、どういう条件で進めるかを定める。

Runtime State

その frame が今どの状態にあるか。
たとえば draft、running、blocked、pending approval、evaluated、merged など。

Recovery Point

ある runtime state を、再開可能な形で保存したもの。

つまり関係は次のようになります。

Process Frame
  └─ governs → Runtime State
       └─ may be captured as → [Recovery Point](./recovery-point/)

PCE 2.0 では、この三つを混同しません。

• frame は構造
• state は進行中の現在値
• recovery point は保存された再開点

です。

---

Process Frame と Actor-local Context の関係

Process Frame は、各 actor に見せる context の上位条件です。
PCE 2.0 では context は単独では存在せず、frame から compile されます。

概念的には、次のように書けます。

actor_local_context(actor, t) =
  compile(
    process_frame,
    responsibility_bundle(actor, t),
    durable_project_state,
    runtime_state(t)
  )

ここで Process Frame が与えるのは、少なくとも次です。

• goal のどの slice を見るべきか
• scope の内外
• capability boundary
• applicable な constraints
• approval / evaluation / stop 条件
• memory write の可否

したがって、Process Frame が曖昧なままでは、
Actor-local Compiled Context も正しく定義できません。

---

Process Frame と Durable Project State の関係

Process Frame は project state の内側に浮く一時的な箱ではありません。
前後の状態を結びつける、継続的な単位です。

frame が project state から受け取るもの

• 既存の canonical artifacts
• 過去の decision memory
• operational memory / skills
• evaluation history
• policy / governance information

frame が project state に返すもの

• 評価済みの artifact delta
• decision delta
• failure / rejection knowledge
• evaluation delta
• memory promotion candidate
• status update

この返り値全体が Process Delta です。

つまり Process Frame は、
Durable Project State を読む入口であり、Process Delta を返す出口
です。

---

親子 Process Frame

PCE 2.0 では frame は入れ子にできます。
これは前稿の重要な発想を継承しています。

親フレーム

より大きな仕事単位。
たとえば feature delivery 全体、release 全体、調査全体など。

子フレーム

親の goal を局所化した部分仕事。
たとえば spec review、code search、implementation、evaluation など。

基本原則

• 子フレームは親の goal を局所化した goal slice を持つ
• capability は原則として親より狭くなる
• approval authority や incident ownership は親に留保されることがある
• 子フレームは結果を Process Delta として親へ返す
• 子は親の境界や authority を黙って拡張できない

概念的には、次のようになります。

parent frame
  ├─ child frame A
  ├─ child frame B
  └─ child frame C

child → returns delta/evidence/unresolved issues → parent

この構造により、長い仕事を壊さずに分割できます。

---

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

これは実務上かなり重要です。
何でも細かく frame にすると過剰に複雑になり、逆に大きすぎる frame は統治不能になります。

新しい frame を切るべき典型条件は次です。

1. Goal が変わるとき

別の達成対象になったなら、別 frame を切るべきです。

2. Success Criteria が変わるとき

成功の判定基準が違うなら、同じ frame で扱うのは危険です。

3. Approval Authority が変わるとき

承認者や承認条件が違うなら、別 frame に分けた方がよいです。

4. Capability Scope が変わるとき

read-only analysis と write-enabled implementation は、通常は別 frame にした方が明確です。

5. Eval Contract が変わるとき

同じ基準で評価できないなら、別の frame が必要です。

6. Incident Ownership が変わるとき

事故時の帰責の所在が変わるなら、境界を切り直した方がよいです。

7. Recovery Strategy が大きく変わるとき

再開地点や rollback 条件が異なるなら、frame を分ける意味があります。

短く言えば、
goal、authority、evaluation、memory、incident のいずれかが大きく変わるなら、新しい frame を切る
と考えるのがよいです。

---

Process Frame の不変条件

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

1. Every executable unit belongs to a frame

実行される作業単位は、必ず何らかの frame に属していなければならない。

2. Every frame has explicit boundary

scope の内外が曖昧な frame は不完全である。

3. Every frame has named responsibility allocation

誰が何を担うかが明示されていない frame は不完全である。

4. Every mergeable delta has an eval path

その frame から生まれる merge 対象には、必ず評価経路が必要である。

5. Every frame has a stop logic

いつ止まるか、どこで保留されるか、何が escalation / rollback 条件かが必要である。

6. Every frame has a memory policy

何を durable state に残すかが決まっていない frame は、長期継続に弱い。

---

小さな例

たとえば「checkout にクーポン併用制約を追加する」仕事を、ひとつの Process Frame として書くと、最小形は次のようになります。

process_frame:
  frame_id: feature.checkout.coupon-combination
  parent_frame_id: release.checkout.spring-2026
  goal: >
    checkout にクーポン併用制約を導入し、
    既存の購入フローを損なわずに運用可能にする
  success_criteria:
    - 制約仕様が承認されている
    - 対象コードに変更が反映されている
    - 回帰テストと制約テストが通過している
    - 運用上の注意点が記録されている
  scope:
    in_scope:
      - coupon validation logic
      - checkout pricing flow
      - related tests
      - implementation decision rationale
    out_of_scope:
      - payment gateway changes
      - marketing rule redesign
  actors:
    - product_owner
    - analyst_agent
    - coding_agent
    - reviewer
    - ci_evaluator
    - memory_writer
  responsibility_allocation:
    product_owner:
      goal_ownership: true
      approval_authority: spec_and_release
      incident_ownership: true
    analyst_agent:
      execution: analysis
    coding_agent:
      execution: implementation
    reviewer:
      approval_authority: code_change
    ci_evaluator:
      evaluation_authority: tests_and_checks
    memory_writer:
      memory_write_authority: true
  capabilities:
    tools:
      - repository_search
      - code_edit
      - test_runner
    data:
      - checkout_specs
      - existing_tests
      - adr_history
    environments:
      - local_repo
      - ci
    permissions:
      - analyst_agent: read_only
      - coding_agent: limited_write
      - reviewer: approve_only
  constraints:
    - checkout total must remain deterministic
    - no change to payment settlement behavior
    - must preserve backward compatibility for existing coupons
  stop_conditions:
    - spec_blocked
    - failing_regression_tests
    - scope_violation_detected
    - approval_rejected
  approval_points:
    - spec_approval
    - code_review_approval
  eval_contract:
    - spec_review
    - unit_tests
    - regression_tests
    - policy_check
  memory_write_policy:
    promote:
      - accepted_decision_rationale
      - added_regression_tests
      - operational_note_if_any
    reject:
      - raw_working_notes
      - unverified_hypotheses
  recovery_strategy:
    checkpoint_policy: after_each_approved_phase
    rollback_target: last_green_commit
    escalation_path: product_owner

この例で重要なのは、単に task が書かれているのではなく、
責任・権限・評価・記憶更新まで含めて仕事の境界が定義されている ことです。

---

最低限の自己点検

ある設計が Process Frame として十分かどうかは、次で点検できます。

1. goal と success criteria が分離して書けるか
2. scope の内外が明示できるか
3. actor と responsibility allocation を区別して書けるか
4. capability boundary が明示されているか
5. approval points と stop conditions があるか
6. eval contract があるか
7. memory write policy があるか
8. recovery strategy があるか
9. 親 frame があるなら、何を継承し何を局所化したか説明できるか
10. この frame から actor-local context を正当化できるか

このどれかが欠けるなら、その単位はまだ十分に frame 化されていません。

---

関連する概念

Process Frame は、PCE 2.0 の ontology の中心にあり、次の概念と直接つながります。

• Process-first
• Responsibility-first
• 対称的アクター性、非対称的責任
• No merge without eval
• Responsibility Bundle
• Actor-local Compiled Context
• Durable Project State
• Process Delta
• Governance Surface
• Recovery Point
• Schema: Process Frame
• Transitions
• Approval Points
• Checkpoint and Recovery
• Eval Contract
• Memory Promotion Rules

---

暫定的なまとめ

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

開発における仕事単位は、単なる task や step ではなく、
目的・境界・責任・能力・承認・評価・記憶更新・回復条件を持つ frame として定義されるべきである。

PCE 2.0 において、何を実行するかは frame の内側で決まります。
何を見せるかも、何を残すかも、何を承認するかも、すべて frame を通して定義されます。

だから Process Frame は、単なる container ではありません。
それは、PCE 2.0 における 仕事の存在論的単位 です。