Process-first

原理

Process-first

PCE 2.0 において、開発の第一級オブジェクトは process である。
context は process と独立に存在する主語ではなく、process frame、responsibility bundle、durable project state、runtime state から compile される局所視界である。

この原理は、context の重要性を下げるためのものではありません。
言いたいのは、context を単独で最適化しても、開発の継続性、責任構造、評価、記憶更新は成立しない、ということです。

PCE 2.0 では、まず process を定義し、その内部で context を扱います。
順序は逆ではありません。

なぜ `process-first` なのか

開発を AI とともに進めるとき、本当に設計しなければならないのは、単に「何を見せるか」ではありません。

設計すべきなのは、むしろ次のことです。

仕事をどの単位で成立させるか
誰が何を担うか
何をしてよく、何をしてはいけないか
どこで承認し、どこで停止するか
何を評価し、何を次へ残すか

これらは、すべて process に属する問いです。
context は、その問いに答えたあとで初めて、適切な形に編集できます。

この意味で、PCE 2.0 において context は重要ですが、主語ではありません。
主語は process です。

PCE 2.0 における `process` とは何か

ここでいう process は、単なる工程順ではありません。
単に「1→2→3 の順に進む作業列」を指しているのではありません。

PCE 2.0 における process は、少なくとも次を持つ仕事単位です。

goal
success_criteria
actors
responsibility_bundle
capabilities
constraints
approval_points
eval_contract
memory_write_policy
recovery_strategy

このまとまりを、PCE 2.0 では Process Frame と呼びます。

つまり process とは、
目的・責任・能力・制約・承認・評価・記憶更新・再開条件を持つ、境界づけられた実行単位
です。

context は process の従属物である

PCE 2.0 では、context を単独の箱としては扱いません。
context は、ある actor が、ある時点で、ある責任を果たすために compile されるものです。

最小限の関係を式のように書くと、次のイメージになります。

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

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

1. context は actor ごとに異なる

実装する actor と、承認する actor と、評価する actor は、同じ情報を必要としません。
したがって「ひとつの Active Context」で全体を表すことはできません。

2. context は時点ごとに異なる

同じ actor であっても、着手前、実行中、承認待ち、失敗後の再計画では必要な view が変わります。

3. context は責任に従属する

何を見せるかは、「その actor が今どの責任を担っているか」によって決まります。
責任が変われば、compile される context も変わります。

この意味で、PCE 2.0 の context は Actor-local Compiled Context です。

`context-first` との違い

process-first をはっきりさせるために、順序の違いを置いておきます。

context-first 的な順序

関連情報を集める
プロンプトや context を組み立てる
出力を得る
必要なら調整する

この順序では、「何を見せるか」は考えられます。
しかし、次の点が曖昧なまま残りやすいです。

誰が goal owner なのか
誰が approver なのか
どの capability を許可するのか
何を durable に残してよいのか
どこで再開できるのか

process-first 的な順序

Process Frame を定義する
Responsibility Bundle を配分する
capability と visibility を scope する
actor ごとに local context を compile する
execute / handoff / approve / evaluate を進める
Process Delta を評価する
評価を通った差分だけを durable state に昇格させる

この順序では、context は process の内部要素になります。
そのため、責任、権限、評価、記憶更新が context の外に取り残されません。

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

process-first を採用するなら、少なくとも次の規則を置く必要があります。

1. 実行可能な作業単位は、必ず process frame に属する

ある task が実行されるなら、それは何らかの process frame に属していなければなりません。
「とりあえずこの prompt を投げる」は、PCE 2.0 では十分な単位ではありません。

2. actor に見せる context は、責任に結びついていなければならない

context は、単に「関係ありそうな情報の寄せ集め」であってはなりません。
その actor が今果たすべき責任に対して必要であることが説明できる必要があります。

3. handoff はテキストの受け渡しではなく、process の継承である

ある actor から別の actor に引き継ぐとき、渡すべきなのはメッセージの断片だけではありません。
引き継ぐべきなのは、少なくとも次です。

どの process frame に属するか
どの責任が移るのか
何が完了し、何が未完了か
何が禁止されているか
次に何を評価すべきか

4. durable state の更新は、process delta と評価結果に結びついていなければならない

長期的に残す情報は、「出力があったから残す」のではなく、
どの process から生まれ、どの評価を通過したか が分かる形で昇格されるべきです。

5. checkpoint は process のために切る

checkpoint は単なる会話保存ではありません。
その process を、どの責任状態から、どの前提のもとで再開できるかを保存するものです。

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

この原理を採用すると、サイト全体の概念配置も変わります。

1. `Process Frame` が中心概念になる

PCE 2.0 では、まず Process Frame を定義し、
その内部で責任、context、memory、evaluation を位置づけます。

2. `Responsibility Bundle` が process の内部構造になる

process は単なる順番ではなく、
責任の分解・配分・留保・再統合 を含むものとして理解されます。

このため process-first は、必然的に Responsibility-first と結びつきます。

3. `Actor-local Compiled Context` が context の基本形になる

context は単数ではなく、actor ごとの局所視界になります。
同じ project state から、異なる責任に応じて別々の context が compile されます。

4. `Process Delta` が成果物差分より広い概念になる

残すべき差分は、artifact だけではありません。
判断、失敗、承認、評価、記憶更新まで含めて process の差分として扱われます。

5. evaluation は output の外側に出る

何が生成されたかだけではなく、
どのような process を通ってきたのかも評価対象になります。
そのため process-first は、No merge without eval と一体です。

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

この原理は強いですが、誤読しやすい点もあります。

context engineering を否定しない

PCE 2.0 は context engineering を不要だとは考えません。
むしろ重要だと考えます。
ただし、それを process の外に置かないだけです。

単純な仕事まで過剰に複雑化しない

すべての仕事に大規模な runtime が必要だと言っているわけではありません。
非常に短い単発作業なら、process frame は極小でよいです。

workflow の価値を否定しない

定義済みの順序制御や orchestration pattern は有用です。
ただし PCE 2.0 では、それを責任構造の一部として読み替えます。

AI を process の中心から排除しない

process-first は human-first と同義ではありません。
AI は process の重要な actor です。
ただし、主語を actor 個体ではなく process 全体に置く、というだけです。

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

PCE 2.0 は、次のような考え方を拒否します。

「情報をたくさん詰めれば前に進む」

これは context を主語にしすぎています。
前に進むかどうかは、process frame、責任、停止条件、評価条件が定まっているかに依存します。

「成功した output なら手順は問わない」

これは process を無視しています。
PCE 2.0 では、生成物だけでなく、どう生成されたかも品質に含まれます。

「handoff はメッセージの引用で足りる」

これでは process identity が失われます。
handoff には、責任状態と未解決事項の継承が必要です。

「memory は会話履歴を貯めればよい」

PCE 2.0 における memory は、単なる保存ではありません。
何を durable に昇格させるかを決める制度です。

小さな例

たとえば、ある feature delivery を考えます。

同じ仕事の中に、少なくとも次の actor がいるとします。

goal owner
executor
approver
evaluator
memory writer

このとき、process-first で重要なのは、最初に
「どんな情報を全部見せるか」を決めることではありません。

先に決めるべきなのは、次です。

この仕事の process frame は何か
どの actor がどの責任を持つか
どの capability を許可するか
どこで承認するか
何をもって成功とするか
何を durable state に残すか

そのあとで、actor ごとに context を compile します。

executor には、変更対象・制約・使える tool・必要テスト
approver には、diff 要約・リスク・未解決事項・rollback 可能性
evaluator には、eval contract・期待される証拠・検証対象
memory writer には、残すべき decision と promotion 条件

この例が示しているのは、
context は process の内側で分化する ということです。

最低限の自己点検

ある設計が process-first かどうかを確かめるには、次を問うとよいです。

その作業は、明示的な process frame に属しているか
各 actor の責任が言語化されているか
actor ごとの context が、責任に紐づいているか
handoff / approval / evaluation / recovery の位置が決まっているか
durable state への更新が、process delta と評価に結びついているか

このどれかが欠けるなら、
その設計は context を持っていても、まだ process-first ではありません。

暫定的なまとめ

process-first が言っていることは、最終的には単純です。

開発において先に設計すべきなのは、
「何を見せるか」ではなく、
「どの process を成立させ、誰に何を担わせ、どこで止め、何を評価し、何を残すか」である。

PCE 2.0 において context は重要です。
しかし、それは process のあとに定義される重要性です。

まず process がある。
その中で責任が配分される。
その責任に応じて context が compile される。
この順序を崩さないことが、process-first の意味です。