Reading Paths

このサイトは、最初から最後まで一直線に読まなければ理解できないようには作っていない。むしろ PCE 2.0 は、

「なぜ process が主語なのか」

「責任をどう分解するのか」

「context をどう bounded に作るのか」

「何を current truth として採用してよいのか」

のどこに関心があるかによって、入口が変わる。

このページでは、読む順番を 目的別 に案内する。

まず持っておくとよい三つのアンカー

PCE 2.0 は語彙が多い。最初に全部を覚えようとすると、かえって見失いやすい。まずは次の三つだけをアンカーとして持っておくと読みやすい。

1. 仕事単位は `Process Frame` である

PCE 2.0 は、仕事を単なる task 名や会話スレッドではなく、 goal、scope、actors、approval、eval、recovery を持つ Process Frame として扱う。

See: Process Frame

2. いま誰が何を引き受けているかは `Responsibility Bundle` で表す

同じ frame に人間も AI も tool も参加できる。しかし、誰が goal を持ち、誰が実行し、誰が approve し、誰が memory を書き、誰が incident を引き取るかは同じではない。その非対称な責任配置を Responsibility Bundle で表す。

See: Responsibility Bundle

3. 出てきたものはすぐ current truth にならない

process の結果はまず Process Delta として出る。それが eval、approval、promotion を経てはじめて Durable Project State に反映される。この distinction を持つことで、PCE 2.0 は Corrupt Success を扱える。

See: Process Delta, Durable Project State

この三つが見えていると、ほとんどのページが読みやすくなる。

サイト全体の地図

このサイトは大きく五つの層に分かれる。

Guide

PCE 2.0 が何を問題にしているのかを説明する導入層。

Spec

理論の中核。principles、ontology、process、evaluation、memory、responsibility、context、governance を含む。

Reference

用語集や schema のような参照層。読むというより、手元に開きながら使う 性格が強い。

Mappings

OpenAI、Anthropic、Microsoft、MCP など既存語彙との対応関係を整理する層。

Cases

理論を feature delivery、PR review、bug triage、research loop、human-AI handoff の具体例で読む層。

最短ルート（30〜45分）

「まず PCE 2.0 が何を言いたいのかだけ掴みたい」なら、次の順がよい。

このルートで最低限わかることは次の三つである。

PCE 2.0 は context engineering の焼き直しではない
process と responsibility が主語である
outcome だけでなく process を評価しなければ current truth を安全に作れない

理論の背骨を通す標準ルート（2〜3時間）

「体系として一度ちゃんと通したい」なら、次の順が自然である。

1. 導入

2. 原理

3. 存在論

4. 責任系

5. process 系

6. evaluation / memory

この順で読むと、PCE 2.0 の中核主張がかなり閉じる。

関心別ルート

ここから先は、「どこに関心があるか」で読む方が効率がよい。

1. 「context engineering の先」を見たい人向け

context engineering という語から入ってきたなら、最初から context ページだけを読むより、次の順の方が誤解が少ない。

このルートのポイントは、 PCE 2.0 では context が主語ではなく、責任に応じて compile される局所視界 だという点である。

2. 「agent orchestration / runtime」から入りたい人向け

LangGraph、Agents SDK、Claude Agent SDK、Foundry Agent Framework のような runtime / orchestration に関心があるなら、次の順がよい。

このルートでは、PCE 2.0 が workflow engine の別名ではなく、 責任・gate・durability を含む process semantics であることが見えやすい。

3. 「governance / safety / human oversight」から入りたい人向け

評価、承認、停止、例外処理、人間の介入に関心があるなら、次の順が自然である。

このルートで特に見たいのは、 approval、evaluation、human oversight が同じではないこと、そして “うまくいったように見える” をそのまま success として採用してはいけないことだ。

4. 「memory / durable state / knowledge management」から入りたい人向け

長時間の開発で何を残し、何を current truth にしてよいかに関心があるなら、次の順がよい。

このルートのポイントは、 PCE 2.0 が “何でも memory に残す” のではなく、 current truth / provisional candidate / rejected path を分けて扱うことにある。

5. 「責任分解」を中心に読みたい人向け

PCE 2.0 のもっとも独自なところの一つは、責任を bundle として分ける点にある。ここに関心があるなら、次の順がよい。

このルートでは、 human と AI が同じ actor plane に乗りつつ、責任は均等ではないことがよく見える。

6. 「ケースから理解したい」人向け

抽象概念より、まず concrete な流れから入りたいなら、次の順がよい。

そのあとで次に戻ると理解しやすい。

このルートの利点は、PCE 2.0 の概念が “きれいな定義” ではなく 実際の壊れ方に対処するための言葉 だと分かりやすいことにある。

7. 「既存の語彙との違い」から入りたい人向け

すでに OpenAI / Anthropic / Microsoft / MCP などの current stack を知っていて、 PCE 2.0 が何を追加しているのかを知りたいなら、次の順がよい。

このルートで見えてくるのは、 PCE 2.0 が runtime や context management の技法を否定しているのではなく、それらを process / responsibility / durability の観点で束ね直していることだ。

8. 「懐疑的に読む」ためのルート

PCE 2.0 に懐疑的で、「これは新しい名前をつけただけではないのか？」「本当に process を主語にする意味があるのか？」を確認したいなら、次の順がよい。

このルートのポイントは、 PCE 2.0 の価値が “新語” ではなく、 今ある開発の壊れ方をどこまで explicit に扱えるか にあることを確かめるところにある。

reference はどう使うか

reference 以下のページは、最初に通読するより、 spec や cases を読みながら横に開いて使うのがよい。

まず開いておくとよいもの

Glossary

実装や構造化を考えるときに使うもの

特に schema pages は、「この概念を実装すると field は何になるのか」を確認するときに便利である。

どこまで読めば何が話せるか

目安として、次くらいで段階が分かれる。

導入ルートまで読んだ段階

PCE 2.0 が context engineering の焼き直しではないことを説明できる
process と responsibility が主語だと説明できる

ontology + process まで読んだ段階

frame / bundle / handoff / lifecycle を使って、仕事の構造を描ける
child frame や branch をどこで切るべきか議論できる

evaluation + memory まで読んだ段階

outcome と process を分けて評価できる
merge / promotion / rollback / corrupt success を議論できる
durable state を汚さない設計が話せる

cases まで読んだ段階

feature delivery や PR review や bug triage を PCE 2.0 の語彙で具体的に再記述できる

読み方のコツ

最後に、このサイトを読むときのコツを三つだけ書いておく。

1. glossary を常に横に置く

PCE 2.0 は用語の distinction がかなり重要なので、意味が近い語を雑に同一視しない方がよい。

特に次は混同しやすい。

eval と approval
frame と lifecycle
delta と durable state
memory candidate と durable memory
handoff と delegation
recovery と rollback

2. abstract pages と cases を往復する

abstract pages だけを連続で読むと、きれいな理論に見えすぎることがある。 cases に戻ると、その理論が何を防ぎたいのかが見えやすい。

3. “この概念は何を current truth から守っているのか” を問う

PCE 2.0 の多くの概念は、最終的には 何を current project reality として採用してよいか を守るためにある。

approval point は何を守るか
evaluation は何を守るか
memory writing は何を守るか
rollback は何を current から外すか
auditability は何を説明可能にするか

この問いを持つと、かなり読みやすくなる。

暫定的なまとめ

このページが言いたいことは、最終的には次の一文に集約できる。

PCE 2.0 は一つの一本道の理論ではあるが、入口は一つではない。自分がいま何に困っているのか――context なのか、orchestration なのか、governance なのか、memory なのか、cases なのか――から入り、そのあとで process / responsibility / durability の背骨へ戻るのが最も自然である。

このサイトは、最初から最後まで全部覚えるためではなく、 自分の実務や思考のどこがまだ unnamed なのかを見つけ、その unnamed な部分に PCE 2.0 の語彙を当てていくため に使うのがよい。