Execution

定義

Execution

Execution とは、ある Actor が、ある Process Frame のある局面において、
与えられた goal slice、constraints、capability boundary、expected output のもとで、
実際に work を前進させ、必要な evidence を生成し、意味のある差分を生む責任 である。

それは単なる「手を動かすこと」ではなく、
scope-bounded action、local sequencing、evidence production、delta emission、stop / escalate judgment、handoff readiness、checkpointability を含む。

より短く言えば、Execution とは
「この actor は、この局面で、何を実際に進め、何を作り、何を返し、どこで止まるべきか」を引き受ける責任
である。

PCE 2.0 において process は Process Frame として定義される。
しかし frame に goal と scope があるだけでは、仕事は進まない。
goal を現実の遷移へ変える責任が必要になる。
それが Execution である。

この意味で Execution は、
Responsibility-first を process の実働側から具体化した責任である。

なぜ Execution が必要なのか

PCE 2.0 が Execution を独立の責任として置くのは、
「何を達成すべきか」と「実際にそれを前へ進めること」が別だからである。

少なくとも次の問題がある。

1. goal だけでは process は進まない

goal が定義されていても、

誰が調査するのか
誰が実装するのか
誰が evidence を揃えるのか
誰が delta を出すのか

が決まっていなければ、process は前へ進まない。

2. 実行は局所的な判断を必要とする

長い仕事では、実行者は毎回 global reframe をせずとも、局所的に次の一手を決める必要がある。

どの file から触るか
どの test を先に回すか
どの unresolved issue を保留して次へ進むか
どこで stop して escalate するか

この局所判断を誰が引き受けるのかが必要である。

3. AI 時代には execution が人間から分離しやすい

いまの process では execution を担うのが

human
AI agent
subagent
tool
CI / runtime

であることが普通にある。
このとき execution を独立責任にしないと、AI や tool が「何をやった責任を持つのか」が曖昧になる。

4. execution と approval / evaluation / goal ownership は別だから

実行者がそのまま approver や goal owner や memory writer だとは限らない。
この差を explicit にしないと、process はすぐに drift する。

5. 実行は artifact だけで終わらないから

実行の結果として生まれるのは code patch だけではない。

failure lesson
implementation note
unresolved issue
handoff package
checkpoint
coordination delta

も実行の産物である。
Execution を「成果物を作ること」だけに縮めると、この層が消える。

だから Execution は、
goal を process 上の実際の前進へ変える責任
として独立に扱われる必要がある。

Execution は何ではないか

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

1. 単なる Goal Ownership ではない

goal owner は「何を達成すべきか」を保持する。
executor は「それをどう前進させるか」を引き受ける。
実行者が goal を silent に書き換えてはならない。

2. 単なる Capability Authority ではない

使える tool や permission があることと、それを用いて実際に work を前進させる責任を持つことは別である。
capability は execution の条件だが、execution そのものではない。

3. 単なる Approval ではない

実装を終えた、調査を終えた、要約を返した、ということは approval ではない。
approval は authority による ratification である。

4. 単なる Evaluation ではない

自分でテストを走らせたり self-check したりすることは execution の一部になりうるが、
formal evaluation authority とは別である。

5. 単なる Memory Writing ではない

実行者は memory candidate を生成しうるが、何を durable state に昇格してよいかを最終決定するとは限らない。

6. 単なる activity 量ではない

長く働いた、多くの token を使った、多くの commit を出した、ということ自体は execution quality を保証しない。

7. 単なる output generation ではない

artifact を一つ生成しただけでは不十分なことがある。
execution には stop / escalate / checkpoint / handoff readiness も含まれる。

Execution が含む責任

PCE 2.0 では、Execution は少なくとも次の責務を含む。

1. Work Realization

実際の作業を進める。

例:

調査
実装
編集
要約
変換
test 実行
analysis の実施

2. Local Sequencing

与えられた goal slice の中で、局所的な順序や実行の刻み方を決める。

重要なのは、これは global reframe ではないという点である。
execution actor は、自分の scope の中で手順を調整できるが、frame の意味自体を勝手に変えてはならない。

3. Evidence Production

後続の evaluation、approval、promotion に必要な evidence を残す。

例:

test result
implementation note
failure reproduction
rollback note
source refs
unresolved issue list

4. Delta Emission

意味のある境界で Process Delta を出す。

例:

artifact delta
failure delta
status delta
coordination delta
candidate memory delta

5. Boundary Observance

scope、policy、capability boundary を守る。
Execution は「何でもやって前へ進めること」ではない。

6. Stop / Escalate Judgment

続けるべきでない局面で止まることも execution に含まれる。

例:

scope ambiguity
missing authority
policy conflict
failing required checks
unsafe drift

7. Handoff Readiness

次の actor が継続できるように package を整える。
良い execution は、後続 actor の再構築コストを減らす。

8. Checkpointability

後で recover できるように、切るべき場所で切れる状態を作る。
実行者は単に前へ走るだけでなく、継続可能性に責任を持つ。

Execution は局所的で境界づけられている

PCE 2.0 において Execution は global な万能権限ではない。
それは常に frame、time、bundle に依存する。

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

execution(actor, process_frame, t)

この書き方で重要なのは三つある。

1. frame 依存

同じ actor でも、別の frame では execution responsibility が違う。

2. time 依存

同じ frame の中でも、implementation phase と review phase では execution の中身が違う。
また suspend / recover / replan の後には、execution の合法範囲が変わりうる。

3. scope 依存

同じ actor でも、local goal slice によって execution 範囲は変わる。
「checkout coupon validation に対する write execution」と
「pricing architecture 全体に対する reframe execution」は別物である。

したがって Execution は、常に bounded execution として理解されるべきである。

Execution と Capability の関係

Execution は capability を必要とするが、capability と同一ではない。

Capability があるだけでは足りない

たとえば code edit 権限があることは、
その actor が今この frame で code を編集すべき責任を持つことを意味しない。

Execution には十分な capability が必要である

逆に execution を持つなら、少なくともその責任を果たすために必要な capability がなければならない。
必要 capability が足りないなら、execution は nominal でしかない。

典型的な関係

execution without sufficient capability
→ 実質的に仕事が進まない
capability without execution responsibility
→ 過剰権限の危険がある

PCE 2.0 では、この両方を避ける。
Execution は、責任としての実働 であり、
Capability Authority はその 実働を可能にする条件 である。

Execution と Actor-local Compiled Context の関係

Actor-local Compiled Context は、execution にとって最も重要な working interface である。

実行者向け context には少なくとも次が入る。

goal slice
relevant state
allowed actions
prohibited actions
expected output
required evidence
stop conditions
handoff contract
escalation path

execution の質は、しばしばこの context の質に依存する。

典型的な failure

goal slice が曖昧
stop condition がない
evidence expectation がない
visibility が過剰
prohibited scope が見えていない

この場合、execution は簡単に

local optimization
scope drift
weak evidence
rework
poor handoff

へ向かう。

したがって execution design は、actor-local context design と強く結びついている。

Execution は Process Delta を生む

Execution の結果は、単なる artifact に限らない。
PCE 2.0 では少なくとも次のような delta が execution から生まれうる。

Artifact Delta

code patch
spec draft
test update
runbook edit

Failure / Rejection Delta

failed attempt
rejected implementation path
anti-pattern note

Coordination Delta

ready for review
blocked by ambiguity
request for clarification

Recovery Delta

checkpoint candidate
resumable summary
rollback anchor note

Operational Candidate Delta

checklist candidate
playbook note
repeatable procedure candidate

つまり Execution は、
state-changing candidate を生み出す責任
でもある。

Execution は stop する責任も含む

PCE 2.0 で特に重要なのは、
Execution が「進め続ける責任」だけではなく、
止まる責任 も含むことだ。

止まるべき典型条件

scope ambiguity がある
required authority が欠けている
policy conflict が出た
evidence が著しく不足している
required evaluator を飛ばしそうになっている
old context が stale である
higher-level trade-off judgment が必要である

ここで実行者が止まらずに進むと、
見かけ上の outcome は良くても process は壊れる。
つまり Corrupt Success が起こりやすくなる。

したがって Execution は、
適切に停止し、handoff や escalation に切り替える責任
でもある。

Execution と Handoff の関係

Handoff は、execution continuity の移送である。
良い handoff は良い execution の一部として理解されるべきだ。

execution actor は handoff の前に少なくとも次を整えるべきである。

何が終わったか
何が未完了か
どの delta が対象か
何が unresolved か
次の actor に何をしてほしいか
何が scope か
何を返してほしいか

これが弱いと、handoff loss が増え、
後続 actor が work を再構築しなければならなくなる。

つまり Handoff は execution の外側ではなく、
execution が continuity を次へ渡す瞬間 である。

Execution と Checkpoint / Recovery の関係

実行は長時間に及ぶことがあるため、
Checkpoint and Recovery と強く結びつく。

execution 中に必要なこと

checkpoint を切るべき boundary を認識する
later resume に必要な evidence を残す
stale context になりうるものを区別する
runtime continuity を壊さないようにする

execution から見た checkpoint

checkpoint は「保存機能」ではなく、
実行 continuity を安全に一時停止するための境界 である。

execution から見た recovery

recover 後には、execution がそのまま再開されるとは限らない。
必要なのは

context recompile
bundle confirm
gate reopening
legal next transition の確認

である。

したがって Execution は、
recoverability を無視してただ進めばよい責任ではない。

Execution のトポロジ

execution は一人一役とは限らない。
PCE 2.0 では、少なくとも次の形を取りうる。

1. Single Executor

一つの actor が execution を担う。
最も単純な形である。

2. Primary + Supporting Executors

primary executor が main work を進め、
supporting actor が analysis、test running、fact gathering などを補助する。

3. Sequential Executors

phase ごとに executor が切り替わる。

例:

analyst agent
coding agent
reviewer
memory writer

4. Parallel Executors

同じ frame 内で、scope の異なる execution が並列に進む。

例:

code change
doc update
test update

ただし parallel にするなら scope boundary を明示しないと collision が起きやすい。

5. Tool-mediated Execution

human や AI が責任を持ち、tool actor が限定的実行を担う。
test runner や search tool が典型である。

6. Hybrid Human-AI Execution

AI が draft / implementation を進め、人間が局所的に edit / fix / decide する形。
この場合、execution continuity の handoff が頻繁に起こる。

このように execution は topology を持つ。
PCE 2.0 では、その topology が goal / gate / audit に耐えるかが重要である。

Execution のライフサイクル

Execution responsibility は static ではない。
少なくとも次の状態を取りうる。

assigned
active
blocked
suspended
handed_off
completed
revoked
recovered

ここで重要なのは、
completed は artifact を一つ出したことではなく、
その局面の expected output と evidence obligation を満たしたことを意味する、という点である。

また suspended や handed_off は失敗ではない。
むしろ long-running process にとっては正常な状態である。

Execution と Goal Ownership の境界

execution actor は local choice をしてよいが、
次のことを勝手に行ってはならない。

global goal の再定義
success criteria の書き換え
in-scope / out-of-scope の変更
required approval の省略
memory promotion の自己決定
incident closure の宣言

もし execution 中にこれらが必要になったなら、
それは goal owner や approver や incident owner へ返すべきである。

この境界を保つことが、PCE 2.0 における process integrity の中核である。

Execution の最小スキーマ

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

execution_responsibility:
  actor_ref:
  frame_id:
  execution_scope:
  goal_slice:
  expected_outputs:
  required_evidence:
  allowed_actions:
  prohibited_actions:
  stop_conditions:
  escalation_path:
  handoff_expectation:
  checkpoint_expectation:
  completion_condition:
  validity:
    active_when:
    expires_when:
  provenance:

もう少し bundle の一部として書くなら、次のようにも置ける。

execution:
  scope:
  goal_slice:
  phases:
  expected_outputs:
  required_evidence:
  allowed_actions:
  required_tools:
  prohibited_actions:
  stop_conditions:
  escalation_path:
  handoff_targets:
  checkpoint_boundaries:
  completion_signal:

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

goal slice がある
expected output と required evidence がある
allowed / prohibited action がある
stop / escalate / handoff / checkpoint を含む
completion の意味がある

つまり Execution は、
単なる「実装担当」というラベルではなく、
bounded action contract として定義されるべきである。

小さな例

feature.checkout.coupon-combination frame における coding_agent の execution は、たとえば次のように書ける。

execution_responsibility:
  actor_ref: coding_agent
  frame_id: feature.checkout.coupon-combination
  execution_scope:
    - implement_coupon_combination_logic
    - update_related_tests
  goal_slice: >
    承認済み仕様に従い、
    coupon validation / pricing flow に必要な変更を実装し、
    review-ready な diff と evidence を返す
  expected_outputs:
    - code_diff
    - updated_tests
    - implementation_note
    - rollback_note
  required_evidence:
    - local_test_results
    - changed_file_list
    - spec_alignment_note
  allowed_actions:
    - edit_target_files
    - run_local_tests
    - inspect_existing_checkout_logic
  prohibited_actions:
    - payment_gateway_edit
    - unrelated_module_edit
    - production_access
  stop_conditions:
    - unresolved_spec_conflict
    - scope_violation_detected
    - failing_required_regression_signal
  escalation_path:
    - reviewer
    - product_owner
  handoff_expectation:
    target: reviewer
    required_package:
      - diff_summary
      - test_results
      - rollback_note
      - unresolved_issues
  checkpoint_expectation:
    - after_implementation_completed
  completion_condition:
    - expected_outputs_ready_for_review
    - required_evidence_attached
  validity:
    active_when: spec_approved
    expires_when: review_handoff_completed
  provenance:
    assigned_by: feature.checkout.coupon-combination

この例で重要なのは、execution が「コードを書くこと」だけではなく、

review-ready であること
required evidence を持つこと
stop すべき条件を知っていること
handoff に耐えること

まで含んでいる点である。

Execution の不変条件

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

1. Every active work has an executor

実際に進んでいる work には、必ず execution を持つ actor がいるべきである。

2. No execution without bounded scope

scope のない execution は drift を生みやすい。
何をやってよく、何をやってはいけないかが必要である。

3. No execution without stop logic

止まる条件のない execution は、scope violation と Corrupt Success を起こしやすい。

4. Execution does not imply approval

実行した actor が、そのまま subject を ratify してよいとは限らない。

5. Execution does not imply goal redefinition

実行者は global goal を silent に変えてはならない。

6. Execution should produce attributable deltas

work の結果は、delta と evidence として追跡可能であるべきである。

7. Execution must preserve continuity

handoff や recovery に耐えない execution は、long-running process を壊しやすい。

8. Execution must remain governable

capability、scope、approval、evaluation の gate を迂回する execution は不正である。

いつ Execution を分けるべきか

次の条件があるなら、一つの execution responsibility ではなく分割を考えるべきである。

1. Capability boundary が大きく違うとき

read-only analysis と write-enabled implementation は、通常分けた方がよい。

2. Expected output が大きく違うとき

spec summary と code patch と review verdict は別 execution にした方が自然である。

3. Risk / approval topology が違うとき

low-risk local edit と high-risk migration は同じ execution surface に乗せるべきではないことが多い。

4. 並列実行が必要なとき

code、tests、docs を別 executor で進めるなら scope 分割が必要である。

5. Audit / revoke 単位を分けたいとき

同じ actor identity でも、execution surface が違うなら bundle を分けた方が安全である。

短く言えば、
scope、capability、output、risk、audit surface のいずれかが意味的に変わるなら execution を分ける
のが基本である。

最低限の自己点検

ある process が execution-aware かどうかは、次で点検できる。

その frame で誰が実際に work を進めるか言えるか
execution scope が明示されているか
expected outputs と required evidence があるか
allowed / prohibited actions を区別できるか
stop conditions があるか
escalation path があるか
handoff に耐える package を準備できるか
recover 後に context を再コンパイルすべき条件があるか
execution actor と goal owner / approver / memory writer を混同していないか
execution の結果を Process Delta として表現できるか

このどれかが欠けるなら、その process はまだ execution を十分に定義していない。

暫定的なまとめ

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

process を前へ進める責任は、goal を持つこととも、承認することとも、評価することとも違う。
ある局面で、何を実際に進め、何を作り、何を根拠として残し、どこで止まり、誰へ渡すのかを引き受ける責任が execution である。

PCE 2.0 において executor は、単なる作業者ではない。
それは、goal を bounded action へ変換し、future evaluation と future continuity に耐える差分を生み出す責任を持つ。

だから Execution は、単なる「実装担当」ではない。
それは、PCE 2.0 において process を現実に前進させる実働責任 である。