Actor

定義

Actor（アクター） とは、状態を観測し、判断し、遷移に関与し、投影を残し、他の投影に依拠しうる主体です。

人間だけではありません。AI、ツール、CI、制度、運用手順も、遷移の成立に能動的に影響するならアクターとして扱います。

ただし、状態を保持するだけのものは、まず State / Projection Surface（状態面 / 投影面）として扱います。Issue、PR、Slack thread、ADR、memory store は、通常は状態や投影を保持する面です。そこに自動判定、通知、権限行使、状態変更が組み込まれている場合、その機能にアクター性があります。

状態面の総体は Context Pool（コンテキストプール） を構成します。アクターはプールから断面を受け取り、結果をプールへ書き戻します。

アクターとして扱う条件

ある存在をアクターとして扱うのは、次のどれかを満たすときです。

• 状態を観測する。
• 遷移候補を作る。
• 遷移を実行する。
• 評価や承認に関与する。
• 記録や投影を残す。
• 他の投影に依拠して動く。
• 後続アクターの判断を変える。

依拠の対称性と責任の非対称性

PCE 3.0 では、人間、AI、ツール、制度、評価系を同じ遷移モデルで扱います。これが可能なのは、依拠がアクターの種類を問わない からです。コンパイラは不変条件に依拠し、AI は記憶に依拠し、CI はビルド環境に依拠し、人間は仕様に依拠します。

ただし、責任、権限、リスク引受は対称ではありません。AI が実行できても、残るリスクを引き受けられるとは限りません。ツールが評価できても、正規状態への反映を承認できるとは限りません。

誰でも依拠はできる。しかし、依拠が裏切られたときに支払える者は限られている。

この非対称の固定点が Accountability Anchor（最終引受点） です。

アクターの種類

PCE 3.0 では、アクターを同じ能力として扱いません。遷移に対して何を形成するかで分けます。

種類	主に形成するもの	例
Execution Actor（実行アクター）	候補、差分、仮説、実装	AI coder、developer、tool runner
Evidence Actor（証拠アクター）	証拠、検査結果、再現可能な観測	CI、test runner、linter、eval system
Governance Actor（統治アクター）	意図、権限、リスク受容、承認	owner、reviewer、domain expert、policy
Control Actor（制御アクター）	分岐、合流、停止、再開、昇格判定	orchestrator、workflow controller、PCE

証拠アクターが形成するものは再導出できます。統治アクターが形成するものは遂行的行為であり、再導出できません。この違いは Warrant の証拠条件と規範条件の区別に対応します。

PCE 自体は、単なる参加者ではなく制御層です。必要に応じて Control Actor（制御アクター）として振る舞い、どの出力を候補に留め、どの根拠が揃ったら正規状態へ進めるかを扱います。

Multi-Actor Continuation

PCE 3.0 は、複数 AI の分業ではなく、複数アクターによる継続制御としてアクターを扱います。

AI が作る差分、人間が形成する意図、CI が出す証拠、Policy（ポリシー）が示す禁止範囲、状態面に残る投影は、それぞれ性質が違います。PCE はそれらを同じ成果物に押し込まず、Warrant（進行根拠）として合流させます。

詳しくは Multi-Actor Continuation を参照してください。

状況パッケージとの関係

アクターには、必要な状態だけでなく、許可操作、禁止操作、証跡、停止条件をまとめた Actor-local Situation Package（アクター別状況パッケージ）を渡します。

これにより、アクターは「何を知っているか」だけでなく、「何をしてよいか」「何に依拠してよいか」「どこで止まるか」まで含めて遷移に参加できます。