PCE in 5 minutes

このページで分かること

PCE 3.0 の全体が、なぜ一つの問いに還元されるのか
最初に理解するための三語
PCE の正式語彙へどう接続するか
明日から AI への指示やレビューで何を変えればよいか

一つの問い

仕事は、一人のアクターでは終わりません。あなたの成果の上に、次の開発者、次の AI、CI、明日の自分が作業を積み上げます。

そして後続アクターは、先行するすべてを再検証できません。時間も、注意も、権限も足りないからです。これは怠慢ではなく、継続する仕事の構造です。

だから後続は、必ず何かに Reliance（依拠） します。再検証なしに、前提として使うということです。

PCE 3.0 の問いは一つだけです。

次のアクターは、これに依拠してよいか。

AI の出力を完成品として扱えないのは、この問いにまだ答えていないからです。答える前のものが候補で、答えた根拠が進行根拠で、答えたあとのものが正規状態です。

最初に覚える三語

Rough Candidate
  -> compare / warrant
  -> Canonical State

Candidate（候補）

AI、人間、CI、ツールが出したものは、まず候補です。

コード差分、仕様解釈、テスト結果、レビューコメント、Slack の合意、記憶に残す要約は、どれも重要です。ただし、それらはまだ依拠してよいものではありません。比較し、磨き、必要なら組み合わせる素材です。

Warrant（進行根拠）

候補に依拠してよいと言える根拠の束です。

進行根拠には、証拠、権限、範囲適合、リスク、戻し方、責任の引受が含まれます。さらに、なぜその候補が他の候補よりよいのか、いつこの根拠が失効するのかも含めます。

Canonical State（正規状態）

後続アクターが再検証なしに依拠してよい状態です。

正規状態に入ったものは、次の開発者、AI、CI、ドキュメント、運用判断が前提にします。よい正規状態は、次の判断を速くし、次の実装を楽にし、次の学習を深くします。

六つの基本ルール

1. AI の出力は、まず候補である

AI が作ったコード、説明、要約、判断は、すぐに依拠の対象にしません。それは「比較し、磨き、採用するかもしれない候補」です。

2. 候補は無料である。恐れず出させる

生成はほぼ無料になりました。候補を一つに絞って祈るのではなく、複数出して、保存される構造、失われる構造、リスク、必要な証拠を比べます。統治するのは生成ではなく昇格です。

3. 候補を正規状態に入れるには、根拠が必要である

根拠には、少なくとも次を含めます。

何を確認したか。
誰が進める権限を持つか。
変更範囲は契約内か。
失敗したとき戻せるか。
残るリスクを誰が引き受けるか。
なぜこの候補がよりよいと言えるか。
この根拠はいつ失効するか。

4. してよいことと、してはいけないことを分ける

AI に「実装して」とだけ渡すと、仕様解釈、設計判断、リファクタリング、フォールバック追加が混ざります。

PCE では、Allowed（許可操作）と Forbidden（禁止操作）を分けます。これは AI を弱くするためではなく、依頼側が「この範囲は変わらない」と依拠できる境界を作り、AI の能力を採用済み候補の実行に集中させるためです。

5. 後続が依拠してよい形で残す

作業ログや推測を、そのまま記憶や仕様に入れません。

後続が依拠してよい範囲と、依拠してはいけない範囲を分け、判断理由、残った不明点、採用しなかった候補まで必要に応じて Projection（投影）として残します。

6. 根拠が足りなければ止める

止まることは失敗ではありません。根拠のないまま進むと、後続に不当な依拠を積ませることになります。

契約外の変更が必要になった、不明点が実装判断に影響した、必要な証拠が出せない。そういう場合は Obstruction（阻害要因）として止めます。

PCE の正式語彙に接続する

最初の語	PCE の正式語彙	意味
依拠してよいか	Reliance	再検証なしに前提として使ってよいかという関係
候補	Continuation Candidate / Transition	まだ依拠してはいけない、改善可能な素材
根拠	Warrant	候補に依拠してよいと言える根拠の束
正規状態	State / Canonical State	後続が再検証なしに依拠してよい状態
してよい範囲	Contract	許可操作、禁止操作、不変条件、停止条件
残すもの	Projection	依拠してよい範囲を明示して残す状態

正式な Core Model は次です。

State
  -> Transition
  -> Contract
  -> Warrant
  -> Projection
  -> State

この循環を満たす遷移が Responsible Continuation（責任ある継続）です。

明日から変えること

AI に依頼するときは、次のように変えます。

悪い依頼:
  この Issue を実装して。

よい依頼:
  まず候補を2つ出し、保存される構造とリスクを比較して。
  採用候補を選んだら、Presentation 層だけを変更してよい。
  Domain 層、API 仕様、AuthError 型は変更しない。
  不明点が実装判断に影響する場合は止める。
  変更ファイル、テスト結果、採用理由、残った不明点を返す。

レビューするときは、「次のアクターはこれに依拠してよいか」を先に見ます。

候補は比較され、よりよい理由が示されているか。
採用しなかった候補の理由が残っているか。
候補を正規状態にしてよい根拠があるか。
禁止された変更が混ざっていないか。
テスト結果だけで完了扱いしていないか。
未確認の推測が仕様や記憶に混ざっていないか。