Actor

定義

Actor

Actor とは、ある process frame のある時点において、
その process の transition、visibility、capability boundary、evaluation outcome、delta admissibility、durable state、recovery のいずれかに
直接的または構造的に影響を与えうる存在 である。

それは人間に限られない。
human、AI agent、subagent、tool、CI/evaluator、document、policy、registry、permission system、runtime、memory service などが actor になりうる。

より短く言えば、Actor とは
「この process において、何かを行うか、何かを許すか、何かを禁じるか、何かを基準づけるか、何かを保存・再開させることで、process の意味的状態を変えうる存在」
である。

PCE 2.0 において actor は、単なる登場人物ではありません。
それは process の状態変化に参与する存在の最小単位です。

この意味で Actor は、
対称的アクター性、非対称的責任 を ontology として具体化した中心概念です。

---

なぜ Actor が必要なのか

PCE 2.0 が解こうとしているのは、人間だけの開発工程ではありません。
いまの process には少なくとも次が関わります。

• 人間が goal を定義する
• AI agent が実装や調査を進める
• tool が検索やテストや変更を実行する
• CI が評価結果を出す
• policy が scope を制限する
• approval gate が進行を止める
• document が受け入れ条件を規定する
• runtime が checkpoint を作り再開を可能にする

このとき「人間」と「AI」だけを書いても、実際の process は記述できません。
一方で、何でもかんでも actor と呼ぶと概念が拡散します。

そこで PCE 2.0 は、actor を
process に対して意味的な効果を持つ存在
として定義します。

この定義により、

• tool や policy や document も process 形成要因として扱える
• しかし actorhood と authority / responsibility は混同しない
• long-running / multi-actor process を一貫して記述できる

ようになります。

---

Actorhood は relational であり、frame-dependent である

PCE 2.0 では、actorhood は絶対的な属性ではありません。
ある存在が「actor である」かどうかは、どの frame で、どの時点に、どう組み込まれているか に依存します。

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

actorhood(x, frame, t) iff
  enrolled(x, frame, t)
  and affects_process(x, frame, t)

ここで affects_process とは、少なくとも次のいずれかを満たすことです。

• transition を開始・実行・停止・変更できる
• 他 actor の visibility を変えられる
• capability / authority boundary を変えられる
• evaluation や promotion の可否に影響を与える
• authoritative reference として解釈や admissibility を拘束する
• recovery / persistence を可能または不可能にする

この定義で重要なのは二つです。

1. actorhood は enrollment を必要とする

ある tool や document が project 内に存在していても、それだけで actor とは限りません。
その frame に組み込まれ、実際に process に効いている必要があります。

2. actorhood は関係的である

同じ存在でも、ある frame では actor であり、別の frame ではただの背景データかもしれません。
たとえば approved spec は、acceptance criteria を拘束する frame では actor 的に働きますが、別の unrelated frame では単なる参照文書に留まるかもしれません。

---

Actor は何ではないか

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

1. 人間だけではない

PCE 2.0 における actor は human-only ではありません。
非人間も、process を変えるなら actor です。

2. ただの role ではない

reviewer や maintainer のような role は比較的安定した肩書きです。
一方 actor は、frame の中で process に作用する存在そのものです。
同じ actor が frame ごとに違う role を取りえますし、同じ role を複数 actor が担うこともあります。

3. ただの Responsibility Bundle ではない

Responsibility Bundle は、その actor がその局面で引き受けている責任状態です。
actor は参加主体、bundle はその局所責任です。
両者は同じではありません。

4. ただの authority ではない

承認権限や memory write 権限は actorhood から自動的には出てきません。
actor であることと、authority を持つことは別です。

5. ただの durable item ではない

document や policy や artifact は durable state に保存されえますが、
保存されているだけでは actor ではありません。
その frame の中で process を拘束・方向づけるときに actor として機能します。

6. ただの subject ではない

コード差分や summary は eval の対象にはなりえますが、
それだけで actor とは限りません。
subject と actor は区別されます。

7. ただの event ではない

actor は出来事ではなく、出来事を起こしうる／拘束しうる存在です。

---

Actor の admission criteria

PCE 2.0 では、何を actor として数えるかを曖昧にしません。
少なくとも次のいずれかを満たすなら、その存在は actor 候補です。

1. Transition initiation / execution

その存在が transition を起こす、または work を実行できる。

例:

• human reviewer
• coding agent
• test runner
• runtime checkpoint manager

2. Gate / admissibility control

その存在が、進行・承認・promotion・merge の可否を左右する。

例:

• approval gate
• policy checker
• reviewer
• CI blocking evaluator

3. Visibility shaping

その存在が、他 actor に何が見えるかを変える。

例:

• retrieval / memory service
• context compiler
• permission system
• document binding

4. Capability shaping

その存在が、他 actor に何ができるかを変える。

例:

• permission registry
• tool allowlist
• scope restriction policy
• runtime sandbox

5. Normative / documentary constraint

その存在が、解釈、受入基準、禁止事項、運用規則を拘束する。

例:

• approved specification
• ADR
• governance policy
• accepted checklist

6. Persistence / recovery support

その存在が、状態保存や再開可能性に直接関与する。

例:

• checkpoint manager
• recovery service
• durable memory store

この admission criteria があることで、actor 概念は拡散しすぎず、なおかつ人間中心にも戻りません。

---

Actor の基本型

PCE 2.0 では、actor を少なくとも次の型に分けて考えます。

1. Human Actors

人間の actor です。

例:

• product owner
• reviewer
• approver
• incident owner
• memory writer

2. AI Actors

LLM-based actor や subagent です。

例:

• analyst agent
• coding agent
• research subagent
• planner agent

3. Tool Actors

外部ツール、実行環境、機械的 evaluator です。

例:

• test runner
• repository search
• static analyzer
• CI evaluator

4. Documentary Actors

document や specification のように、規範的・参照的に process を拘束する actor です。

例:

• approved spec
• ADR
• runbook
• accepted review checklist

5. Governance Actors

権限、承認、可視性、ポリシー、監査に関わる actor です。

例:

• approval gate
• policy engine
• permission registry
• authority registry

6. Runtime / Recovery Actors

継続性・再開性・状態保持に関わる actor です。

例:

• checkpoint manager
• session runtime
• recovery orchestrator
• timeout / suspension handler

7. Hybrid Actors

複数の性質を持つ actor です。
たとえば policy checker は tool であると同時に governance actor でもあります。

この分類は排他的な taxonomy というより、
どのような仕方で process に作用するか を見やすくするためのものです。

---

Operational Actors と Structural Actors

PCE 2.0 では、もう一つ重要な区別があります。

1. Operational Actors

実際に transition を起こしたり work を実行したりする actor です。

例:

• human reviewer
• coding agent
• test runner
• checkpoint manager

2. Structural Actors

自ら work を実行しなくても、解釈・評価・許可・禁止・可視性を拘束する actor です。

例:

• approved spec
• governance policy
• authority registry
• accepted rubric

3. Hybrid Actors

両方の性質を持つ actor です。

例:

• CI evaluator
• policy engine
• runtime orchestrator

この区別は重要です。
PCE 2.0 は actor を「行動する主体」だけに限定しません。
行動条件を拘束する存在 も actor として扱います。

ただし、これがそのまま責任の対称性を意味するわけではありません。
ここで 対称的アクター性、非対称的責任 が効いてきます。

---

Actor と Responsibility Bundle の関係

Actor と Responsibility Bundle は密接に関係しますが、同一ではありません。

Actor

process に参与しうる存在の単位。

Responsibility Bundle

その actor が、その frame の、その局面で引き受けている責任状態。

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

responsibility_bundle(actor, frame, t)

ここで重要なのは、bundle は actor から自動的に導かれないことです。

• 同じ actor が別 frame では別 bundle を持つ
• 同じ actor が同じ frame でも phase によって別 bundle を持つ
• actor であることだけで approval / memory_write / incident_ownership は決まらない

したがって PCE 2.0 では、
actorhood は参加条件、
bundle は局所責任条件
として分けて扱います。

構造的 actor と sparse bundle

document や policy のような structural actor は、人間や AI のような密な bundle を持たないことがあります。
その場合でも、その actor が evaluation、approval、scope、admissibility を拘束するなら actorhood は成立します。

必要なら、そうした actor には

• explicit sparse bundle
• indirect structural effect
• governance surface binding

のいずれかとして参加形態を明示すべきです。

---

Actor と Actor-local Compiled Context の関係

Actor-local Compiled Context は、actor のために compile される局所視界です。
しかし、すべての actor が同じ形で context を受け取るわけではありません。

Human actor の場合

• review view
• summary
• checklist
• unresolved issues list

AI actor の場合

• prompt / retrieved evidence / tool schema / output contract

Tool actor の場合

• structured invocation
• parameter bounds
• execution policy
• input payload

Structural actor の場合

• reference binding
• policy application
• rubric binding
• scope rule attachment

つまり、actor-local context は
actor の modality に応じて異なる形式を取る のであって、
人間や AI の prompt 的な view に限りません。

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

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

ただし structural actor では、この compile 結果が「読むための文脈」ではなく
「拘束条件としての binding」になることがあります。

---

Actor と Durable Project State の関係

ここは誤解しやすいので分けておきます。

Durable item

Durable Project State の中に保存される項目です。
artifact、decision、policy note、checklist などです。

Actor

その frame の中で process を変えうる存在です。

同じ entity が、ある時は durable item であり、別の時は actor 的に機能することがあります。
たとえば approved spec は durable state にある document ですが、
ある frame では acceptance criteria を拘束する documentary actor として振る舞います。

この意味で PCE 2.0 は、
state と actor を substance ではなく機能で区別する
と言えます。

つまり、

• 保存されているだけでは actor ではない
• しかし保存物が process を拘束するとき actor として機能する

ということです。

---

Actor と Transition の関係

PCE 2.0 において Transition は無主語ではありません。
意味のある transition には、少なくとも initiator actor または governing actor が関わります。

たとえば、

• execute は coding agent や human operator が initiator になる
• approve は approver actor が initiator になる
• checkpoint は runtime actor が initiator になる
• revoke は governance actor が initiator になる
• evaluate は evaluator actor set が関与する
• merge は memory writer または required authority actor が関与する

ここで重要なのは、
同じ transition に複数 actor が関わることがある という点です。

• initiator
• affected actor
• evaluator
• approver
• structural constraint actor

が分かれることがあります。

したがって actor は、transition の「一人の主語」ではなく、
遷移の因果と権限構造を構成する参加者集合 として捉えるべきです。

---

Actor と Governance Surface の関係

actor が process に参加すると、その actorhood はしばしば Governance Surface に露出します。

たとえば、

• permission boundary
• approval UI
• audit log
• policy binding
• tool allowlist
• visibility scope
• merge gate
• memory write surface

などです。

この surface が重要なのは、actorhood を可視化しないまま process を運用すると、

• 誰が何をしたのか追えない
• どこで authority が働いたのか分からない
• structural actors の効果が見えない
• AI や tool の中心性が governance の外に落ちる

からです。

したがって actor は ontology 上の存在であるだけでなく、
運用上は governance surface を通して観測・制御されるべきです。

---

Actor は split すべきか、それとも bundle を変えるべきか

実務上かなり重要なのは、
「別 actor に分けるべきか、同じ actor の別 bundle とみなすべきか」
の判断です。

同じ actor の別 bundle とみなしてよい場合

• identity が同じ
• interaction surface が同じ
• governance domain が同じ
• independently revoke / suspend / audit する必要がない
• 役割差が主に責任配分の差である

例:

• 同じ reviewer が phase A では evaluator、phase B では approver になる

別 actor に分けるべき場合

• identity / control surface が独立している
• capability boundary が大きく違う
• audit trail を分けたい
• independently suspend / revoke / replace したい
• modality が大きく違う
• operator / owner / security domain が違う

例:

• coding agent と policy checker
• main agent と read-only subagent
• human reviewer と automated CI evaluator
• same repository search tool と production deployment tool

短く言えば、
責任の違いだけなら bundle で表現し、
制御面・監査面・権限面・実体面の違いなら actor を分ける
のが基本です。

---

Actor のライフサイクル

actorhood は frame-dependent なので、actor には少なくとも二つの状態面があります。

1. Project-level existence

その project に actor として登録・認識されているか。

例:

• known tool
• approved policy engine
• registered reviewer
• available subagent

2. Frame-level enrollment

その actor が今この frame に参加しているか。

例:

• enrolled
• active
• suspended
• revoked
• archived

概念的には、次のように分けられます。

actor identity
  + frame-local enrollment
  + optional responsibility bundle

この区別があることで、

• actor は project には存在するが frame には未参加
• frame に参加していたが現在は suspended
• actor は同じだが別 frame で別 bundle を持つ

といった状態を自然に扱えます。

---

Actor の最小スキーマ

PCE 2.0 では、actor そのものと frame-local enrollment を分けて持つのが自然です。

Actor identity

actor:
  actor_id:
  kind:
  mode:
    # operational | structural | hybrid
  modality:
    # human_ui | llm | tool_api | document_ref | policy_engine | runtime_service
  label:
  identity_ref:
  offered_interfaces:
  provenance:

Frame-local enrollment

actor_enrollment:
  enrollment_id:
  actor_ref:
  frame_id:
  enrollment_state:
    # enrolled | active | suspended | revoked | archived
  participation_mode:
  active_when:
  affects:
    transitions:
    visibility:
    capabilities:
    evaluation:
    promotion:
    recovery:
  governance_refs:
  notes:

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

1. actor identity と frame-local participation を分けている
2. kind と mode がある
3. offered interface と authority を分けている
4. 何に影響を与える actor なのかが明示される
5. actorhood が enrollment と結びついている

必要なら、frame 内で別途 Responsibility Bundle が actor_ref に割り当てられます。

---

小さな例

「checkout にクーポン併用制約を追加する」frame での actor 例です。

Actor identities

actors:
  - actor_id: product_owner
    kind: human
    mode: operational
    modality: human_ui
    label: Product Owner
    identity_ref: user.po.checkout
    offered_interfaces:
      - define_goal
      - approve_spec
      - accept_escalation

  - actor_id: coding_agent
    kind: ai_agent
    mode: operational
    modality: llm
    label: Coding Agent
    identity_ref: agent.coding.main
    offered_interfaces:
      - analyze_code
      - edit_code
      - produce_diff
      - run_tests

  - actor_id: reviewer
    kind: human
    mode: operational
    modality: human_ui
    label: Reviewer
    identity_ref: user.reviewer.checkout
    offered_interfaces:
      - review_diff
      - approve_or_reject

  - actor_id: ci_evaluator
    kind: tool
    mode: hybrid
    modality: tool_api
    label: CI Evaluator
    identity_ref: tool.ci.checkout
    offered_interfaces:
      - run_regression_suite
      - emit_evaluation_report

  - actor_id: approved_spec_v1
    kind: document
    mode: structural
    modality: document_ref
    label: Approved Coupon Combination Spec v1
    identity_ref: artifact.spec.coupon-combination.v1
    offered_interfaces:
      - constrain_scope
      - define_acceptance_reference

  - actor_id: scope_policy
    kind: policy
    mode: structural
    modality: policy_engine
    label: Checkout Scope Policy
    identity_ref: policy.checkout.scope
    offered_interfaces:
      - block_scope_violation
      - constrain_capability

  - actor_id: checkpoint_manager
    kind: runtime
    mode: hybrid
    modality: runtime_service
    label: Checkpoint Manager
    identity_ref: runtime.checkpoint.main
    offered_interfaces:
      - create_checkpoint
      - restore_checkpoint

Frame enrollments

actor_enrollments:
  - actor_ref: product_owner
    frame_id: feature.checkout.coupon-combination
    enrollment_state: active
    affects:
      transitions:
        - instantiate
        - approve
        - escalate
      visibility: []
      capabilities: []
      evaluation: []
      promotion:
        - decision_memory
      recovery: []

  - actor_ref: coding_agent
    frame_id: feature.checkout.coupon-combination
    enrollment_state: active
    affects:
      transitions:
        - execute
        - emit-delta
      visibility: []
      capabilities:
        - limited_write_scope
      evaluation: []
      promotion: []
      recovery: []

  - actor_ref: approved_spec_v1
    frame_id: feature.checkout.coupon-combination
    enrollment_state: active
    affects:
      transitions: []
      visibility:
        - spec_binding_for_context_compile
      capabilities:
        - out_of_scope_payment_gateway
      evaluation:
        - acceptance_reference
      promotion: []
      recovery: []

  - actor_ref: checkpoint_manager
    frame_id: feature.checkout.coupon-combination
    enrollment_state: active
    affects:
      transitions:
        - checkpoint
        - recover
      visibility: []
      capabilities: []
      evaluation: []
      promotion: []
      recovery:
        - create_recovery_point
        - restore_runtime_state

この例で重要なのは、approved spec や checkpoint manager も actor として明示されていることです。
一方で、actor であることだけでは authority や bundle は決まりません。

---

Actor の不変条件

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

1. Actorhood is frame-dependent

ある存在が actor とみなされるのは、特定 frame への enrollment と process への効果に基づく。

2. No authority by mere actorhood

actor であることだけでは approval / memory_write / incident_ownership は得られない。

3. Every meaningful initiator traces to an actor

意味のある transition には、少なくとも initiator actor または governing actor が追跡可能であるべき。

4. Not every durable item is an actor

durable item は、frame 内で process を拘束するときに限って actor 的に機能する。

5. Actor and bundle must remain distinguishable

actor identity と responsibility bundle を混同してはならない。

6. Structural actors must not disappear from the model

document、policy、registry のような structural actor を暗黙化してはならない。

7. Actor split should follow control and governance boundaries

責任の違いだけで actor を無闇に増やしてはならない。
ただし独立した control surface や audit surface があるなら分けるべきである。

---

いつ何を actor としてモデリングすべきか

実務上は、すべてを actor にすると重くなります。
逆に actor を減らしすぎると process の本質が消えます。

次の条件が揃うなら、actor として明示する価値が高いです。

1. Transition を起こすか止めるかする

例: reviewer、policy gate、runtime

2. Visibility や capability を変える

例: permission system、retrieval service、approved spec binding

3. Evaluation や promotion の可否に効く

例: CI evaluator、review rubric、memory writer

4. 独立して監査したい

例: human reviewer と CI evaluator を分ける

5. 独立して revoke / suspend したい

例: subagent、deployment tool、policy engine

逆に、単なる raw data fragment や再利用性の低い一時メモは、通常 actor として扱う必要はありません。

---

最低限の自己点検

ある process モデルが actor-aware かどうかは、次で点検できます。

1. その process を変えている存在を、人間だけでなく列挙できるか
2. actor と role を区別できるか
3. actor と responsibility bundle を区別できるか
4. document / policy / registry が structural actor として必要か判断できるか
5. actorhood と authority を混同していないか
6. actor identity と frame-local enrollment を分けて考えられるか
7. 同じ entity を別 actor に分けるべきか bundle 差で済むか判断できるか
8. transition initiator が actor に紐づいているか
9. actor-local context の modality が actor に応じて変わることを説明できるか
10. durable item がいつ actor 的に機能するか説明できるか

このどれかが欠けるなら、その model はまだ actor 概念を十分に使いこなせていません。

---

関連する概念

Actor は、PCE 2.0 の存在論の入口として、次の概念と強く結びつきます。

• 対称的アクター性、非対称的責任
• Process-first
• Responsibility-first
• Process Frame
• Responsibility Bundle
• Actor-local Compiled Context
• Durable Project State
• Process Delta
• Governance Surface
• Recovery Point
• Transitions
• Handoff
• Approval Points
• Checkpoint and Recovery

---

暫定的なまとめ

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

process を形づくるのは、人間だけではない。
しかし、何でも actor と呼べばよいわけでもない。
ある frame の中で transition、visibility、capability、evaluation、promotion、recovery に意味的な効果を持つ存在だけを、actor として明示すべきである。

PCE 2.0 において actor は、単なる登場人物ではありません。
それは、process の状態変化を可能にし、拘束し、記録可能にする参加単位です。

だから Actor は、単なる概念上の背景ではなく、
PCE 2.0 において 責任・文脈・統治・継続性を支える存在論的な参加単位 です。