Responsibility-first

原理

Responsibility-first

PCE 2.0 において、process の内部構造を決める第一の要因は responsibility である。
process は単なる作業列ではなく、責任の分解・配分・委譲・留保・再統合の体系として理解される。
したがって、context、capability、approval、evaluation、memory promotion はすべて、
「誰がいま何を担っているか」という責任条件に従って設計されなければならない。

この原理で言いたいのは、
開発の本体が「順番」そのものではなく、誰が何を引き受け、どこまでを許され、どこで止められ、何を確定できるか にある、ということです。

PCE 2.0 において process を構成するのは、単なる step の列ではありません。
本当に構成しているのは、責任の束と、その遷移です。

なぜ `responsibility-first` なのか

process-first が「主語は context ではなく process だ」と言うなら、
responsibility-first はさらに一歩進んで、その process の中身は責任構造だ と言います。

順番だけが決まっていても、次の問いに答えられなければ、プロセスは成立しません。

誰がこの仕事の goal owner なのか
誰が実行するのか
誰が承認するのか
誰が成功・失敗を判定するのか
誰が project memory を更新してよいのか
事故や逸脱が起きたとき、誰が最終的に引き受けるのか

この問いに答えないまま step を並べても、それは責任なき workflowです。
PCE 2.0 は、それを十分な process とはみなしません。

PCE 2.0 における「責任」とは何か

ここでいう責任は、日常語としての曖昧な「責任感」ではありません。
PCE 2.0 では、責任を少なくとも次の次元に分解します。

goal_ownership
何を達成すべきかを定める責任
execution
実際に作業を進める責任
capability_authority
どの tools / data / environment を使えるかに関わる権限
approval_authority
外部反映や次工程への進行を許可できる権限
evaluation_authority
成功・失敗・適合性を判定する責任
memory_write_authority
durable state を更新・昇格できる権限
incident_ownership
逸脱・失敗・事故が起きたときに最終的に引き受ける責任

PCE 2.0 では、これらをまとめて Responsibility Bundle と呼びます。

重要なのは、責任は単数ではなく、束である という点です。
ひとつの actor が bundle 全体を持つ場合もあれば、複数 actor に分散される場合もあります。

`role`・`permission`・`accountability` との違い

responsibility-first を誤読しないために、近い概念との違いを明示しておきます。

Role とは違う

role は比較的安定した肩書きや立場です。
たとえば reviewer、maintainer、agent、operator などです。

一方、responsibility は 特定の process と時点に結びついた引受け です。
同じ reviewer でも、あるプロセスでは approver であり、別のプロセスでは evaluator かもしれません。

PCE 2.0 が中心に置くのは、静的な role ではなく、動的な responsibility です。

Permission とは違う

permission は「何ができるか」です。
責任は「何を引き受けているか」です。

使える tool があることと、その tool を使って結果を出す責任を持つことは同じではありません。
PCE 2.0 では、capability は responsibility の一部条件ですが、責任そのものではありません。

Accountability とは違う

accountability は、最終的な説明責任や帰責の所在です。
これは responsibility bundle の一部ですが、bundle 全体ではありません。

ある actor が execution を担っていても、incident ownership は別 actor に残ることがあります。
この分離を明示することが、PCE 2.0 では重要です。

責任を主語にすると、何が見えるのか

responsibility-first を採用すると、普段「工程」や「権限管理」として別々に見えていたものが、同じ構造として見えるようになります。

1. handoff は責任移譲として見える

handoff は単なるメッセージ転送ではありません。
何らかの responsibility bundle、またはその一部が別 actor に移る出来事です。

2. approval は責任の留保として見える

approver が存在するということは、execution が完了しても process は終わらず、
ある責任が別 actor に留保されているということです。

3. checkpoint は責任状態の保存として見える

checkpoint は会話履歴の保存ではありません。
どの責任がどの状態で停止したかを、再開可能な形で保存するものです。

4. merge は責任行使として見える

durable state に差分を昇格させることは、単なる保存ではありません。
memory_write_authority を持つ actor が、その責任を行使した結果です。

つまり process とは、作業の列というより、
責任束が時間とともにどう移り、どう留保され、どう確定されるか の運動です。

Responsibility Bundle は process の骨格である

PCE 2.0 では、各 actor に対して bundle を明示します。
概念的には、次のように書けます。

responsibility_bundle(actor, t) = {
  goal_ownership,
  execution,
  capability_authority,
  approval_authority,
  evaluation_authority,
  memory_write_authority,
  incident_ownership
}

ここで重要なのは 3 点です。

bundle は actor ごとに異なる

同じ process でも、executor と approver と evaluator では bundle が違います。

bundle は時点ごとに変わる

同じ actor でも、着手前・実行中・承認待ち・失敗後の再計画では bundle が変化します。

bundle は部分的にしか移らないことがある

execution は AI agent に渡しても、approval や incident ownership は人間側に残す、という構成がありえます。

この点が、PCE 2.0 における
対称的 actor 性と非対称的責任
の具体形です。

process は責任遷移の体系である

responsibility-first に立つと、process の遷移も別の見え方になります。
PCE 2.0 における主要遷移は、責任の観点から読むべきです。

assign

新しい process frame に対して responsibility bundle を割り当てる。

delegate

bundle の一部を、別 actor に局所的に委ねる。
ただし ownership の一部は元 actor に残ることがある。

handoff

実行責任や作業継続責任を、別 actor に移す。

approve / reject

承認権限を持つ actor が、進行または停止を確定する。

escalate

現 actor の bundle では解決不能なとき、より上位または別系統の actor へ責任を引き上げる。

evaluate

成果物だけでなく、process の適合性を判定する責任が行使される。

promote / merge

memory write authority を持つ actor が、評価済み差分を durable state に昇格させる。

rollback

誤った進行や不適合な差分に対して、すでに行使された bundle の結果を取り消し、前段へ責任を戻す。

これらは単なる制御フローではありません。
責任の移動・行使・留保・回収 です。

この原理から導かれる規則

responsibility-first を採用するなら、少なくとも次の規則が必要です。

1. No orphan process

どの process にも、少なくとも次は明示されていなければなりません。

goal owner
executor
approver または承認不要である条件
evaluator
memory writer
incident owner

誰も引き受けていない責任があるなら、その process は未完成です。

2. No execution without named responsibility

「AI がやった」「システムがやった」だけでは不十分です。
実行主体だけでなく、その行為がどの責任のもとで行われたかが明示される必要があります。

3. No approval without explicit authority

誰でも承認してよいわけではありません。
approval は、明示的な authority を持つ actor にしか行えません。

4. No memory promotion without memory writer

durable state の更新は自動的に起きてはなりません。
何を昇格させるか、誰の authority で昇格したかが追跡可能である必要があります。

5. No incident ownership vacuum

失敗や逸脱が起きたときに、最終的に誰が引き受けるかが空白であってはなりません。

6. Responsibility must precede context

どの context を見せるかは、その actor が担う責任が定義されたあとで決まります。
責任より先に context を組むと、局所視界の正当性が説明できません。

`responsibility-first` が含意する設計上の帰結

この原理を採用すると、PCE 2.0 の各概念の位置づけがはっきりします。

1. Process Frame は責任の器になる

Process Frame は、単なる task container ではありません。
責任を配分するための境界です。

2. Actor-local Compiled Context は bundle から導出される

Actor-local Compiled Context は、
「関係ありそうな情報」を集めたものではなく、
その actor の responsibility bundle を遂行可能にする view です。

3. Capability Scope は責任と整合しなければならない

何をできるかは、何を担っているかに従属します。
bundle に含まれない責任のための capability は、原則として過剰です。

4. Evaluation は authority の一部になる

評価は単なる後処理ではありません。
誰が何をもって適合と判断するのか、という責任です。

5. Memory は責任の制度になる

何を durable state に残すかは、memory write authority の行使として理解されます。
そのため memory は保存領域ではなく、責任行為の結果です。

`responsibility-first` は何を否定しないか

この原理は強いですが、いくつかの誤読を避ける必要があります。

role 設計を否定しない

role は有用です。
ただし PCE 2.0 は、role をそのまま process の単位にしません。
role の上に、時点依存の responsibility bundle を置きます。

automation を否定しない

責任を明示することは、必ずしも人間の手作業を増やすことではありません。
execution や一部 evaluation は自動化できます。
ただし、その自動化が何の責任のもとで行われているかは明示されるべきです。

AI に重要な役割を与えないわけではない

AI は execution の中心になり得ますし、場合によっては候補評価や再計画にも深く関与できます。
responsibility-first は AI を周辺化する原理ではありません。
むしろ AI を actor として真面目に扱うための原理です。

すべてを人間承認に戻すわけではない

承認や留保の位置は process ごとに違ってよいです。
重要なのは、人間承認を増やすことではなく、責任境界を明示することです。

逆に、`responsibility-first` が拒否するもの

PCE 2.0 は、次のような設計を拒否します。

「うまく回れば誰が担っているかは問わない」

これは process の見かけ上の成功に依存しすぎています。
PCE 2.0 では、成功して見えても責任の所在が不明なら健全とはみなしません。

「tool permission があるなら、その actor が責任も持つ」

できることと、引き受けていることは別です。
権限だけで責任を推定してはなりません。

「承認は最後に誰かがざっと見ればよい」

approval は漠然とした確認ではなく、明示的 authority の行使です。
誰が、何に対して、どの条件で承認するのかが必要です。

「memory は生成されたものを全部残せばよい」

残すこと自体が責任行為です。
無差別な保存は、memory write authority を不在化させます。

「incident は起きたら考える」

incident ownership は事後ではなく事前に定義されていなければなりません。

小さな例

ある feature delivery を考えます。

同じ仕事でも、少なくとも次の actor が存在し得ます。

product owner
coding agent
reviewer
evaluator
memory writer

ここで responsibility-first が問うのは、
「誰にどんな情報を全部見せるか」ではありません。
先に問うのは次です。

誰が goal owner か
誰が execution を担うか
誰が approval authority を持つか
誰が evaluation authority を持つか
誰が memory write authority を持つか
誰が incident owner か

この bundle が決まったあとで、はじめて context を compile できます。

coding agent には execution に必要な局所視界
reviewer には approval に必要な diff と根拠
evaluator には eval contract と証拠
memory writer には昇格候補と評価結果

この例で重要なのは、
責任の配分が先で、context の編集は後
だという点です。

最低限の自己点検

ある設計が responsibility-first かどうかを点検するには、次を問います。

その process には goal owner / executor / approver / evaluator / memory writer / incident owner がいるか
各 actor の responsibility bundle が言語化されているか
capability と authority が責任と整合しているか
handoff / approval / escalation / merge が責任遷移として説明できるか
durable state の更新が memory write authority と評価結果に結びついているか
failure 時に、誰がどこから bundle を引き受け直すかが決まっているか

このどれかが欠けるなら、その設計はまだ responsibility-first ではありません。

暫定的なまとめ

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

process を本当に動かしているのは step の順番ではない。
誰が何を引き受け、どこまでを許され、どこで止められ、何を確定できるか、という責任構造である。

PCE 2.0 において、工程は責任の外側にはありません。
工程とは、責任が時間方向に配分され、委譲され、留保され、再統合される形そのものです。

この順序を崩さないことが、responsibility-first の意味です。