Mappings

Mappings は、読者がすでに持っている語彙から PCE 2.0 に入るための入口である。ここでやるのは、単純な「言い換え」ではない。むしろ、

どこが近いか

どこが似て見えるが違うか

PCE 2.0 が何を上位概念として扱うか

を整理する。

重要なのは、mapping が 1:1 対応表ではないことだ。 PCE 2.0 は runtime、framework、API、protocol をそのまま再命名する理論ではない。それらを process / responsibility / governance / durability の地図の中に再配置する。

Mappings セクションの役割

1. 既存語彙からの入口を作る

読者は最初から Process Frame や Responsibility Bundle を知っているとは限らない。むしろ、

agent
workflow
state graph
eval
MCP
handoff

のような既存語彙から入ることが多い。

Mappings は、その入口を担う。

2. 似ているが違うものを分ける

たとえば、

workflow と process frame
state と durable project state
tool call と capability scope
trace と auditability

は重なる部分があるが、同じではない。

3. PCE 2.0 の主語を見失わないようにする

各 mapping ページの目的は、 OpenAI や Anthropic や LangGraph を中心に読むことではない。むしろ、 それらを使ってもなお、PCE 2.0 が process-first / responsibility-first である ことを保つためにある。

現在の mapping 一覧

特定ベンダー以前に、 workflow、agent、orchestration、prompt engineering、state などの一般語彙との関係を整理するページ。

向いている読者:

まず概念差分を大づかみに見たい
vendor 固有語彙に入る前に全体比較したい

OpenAI

Responses API、Agents SDK、Agent Builder、guardrails、HITL、MCP、skills、shell、tracing、agent evals などを、 PCE 2.0 の地図の中でどう位置づけるかを整理するページ。

向いている読者:

OpenAI の current stack から PCE 2.0 に入りたい
agent runtime と process theory の差を見たい

Anthropic

workflows vs agents、context engineering、Claude Code / Agent SDK、subagents、hooks、memory、skills、evals を、 PCE 2.0 の責任地図と照合するページ。

向いている読者:

context engineering との違いを見たい
Claude 系の実務語彙から入りたい

LangGraph

StateGraph、shared state、reducers、durable execution、interrupts、time travel、subgraphs、memory、LangSmith observability を、 process semantics と runtime substrate の違いとして整理するページ。

向いている読者:

orchestration runtime の語彙から入りたい
graph / state / persistence と PCE 2.0 の差を見たい

Microsoft

Microsoft Agent Framework、Foundry Agent Service、Control Plane、Entra Agent ID、Semantic Kernel lineage、hosted MCP tools、Foundry evals / observability を、 build / run / govern / observe の層で再配置するページ。

向いている読者:

enterprise / control plane 的な観点から入りたい
governance / identity / hosted runtime を強く意識している

MCP

host-client-server architecture、tools / resources / prompts、roots / sampling / elicitation、capability negotiation、authorization を、 protocol と process semantics の境界として整理するページ。

向いている読者:

MCP を process theory とどう接続するか見たい
protocol と governance の境界を理解したい

どれを先に読むべきか

まず一番ニュートラルに入りたい

Related Concepts から読むのがよい。 vendor 固有語彙より前に、一般語彙との差分を見られるからである。

OpenAI / Anthropic から入りたい

それぞれ普段使っている stack に近い方から入ればよい。

OpenAI ユーザー: OpenAI
Claude / Anthropic ユーザー: Anthropic

orchestration / state graph から入りたい

LangGraph が最短である。

control plane / governance / hosted runtime から入りたい

Microsoft が最短である。

protocol / tool exposure から入りたい

MCP が最短である。

どう読むとズレにくいか

mapping ページを読むときは、次の三つの問いを持つとよい。

1. その stack は何を強く持っているか

runtime、tooling、observability、protocol、governance、memory など、どこに強みがあるかを見る。

2. それでも PCE 2.0 が追加で言っていることは何か

特に、

process frame
responsibility bundle
process delta
durable project state
approval separation

のどれが、既存 stack だけでは明示されにくいかを見る。

3. 逆に何を無理に対応づけてはいけないか

似ている語を雑に重ねると、 PCE 2.0 の独自性が消える。「近いが違う」を残すことの方が重要である。

Mappings と他セクションの関係

Guide との関係

もし PCE 2.0 自体の問題設定がまだ弱いなら、 mapping より先に Reading Paths や PCE 2.0 とは何かを見た方がよい。

Spec との関係

mapping は spec を置き換えない。定義が必要なら必ず Spec へ戻るべきである。

Reference との関係

mapping を読んで語が増えたら、

へ戻るとよい。

Cases との関係

mapping で「なるほど」を得たあとに、それが実務でどう現れるかを見るには Cases が効く。

よくある読み方

vendor stack から入る

該当 mapping を読む
強く出てくる canonical term を確認する
その term の spec に戻る
relevant case を読む

skeptical reading

Related Concepts を読む
自分が近い vendor mapping を読む
「似て見えるが違う」箇所だけを拾う
PR Review か Human-AI Handoff を読む

この順だと、PCE 2.0 が単なる rename ではないことを確認しやすい。

暫定的なまとめ

このセクションが言いたいことは、最終的には次の一文に集約できる。

PCE 2.0 の mappings は、既存 stack を PCE 2.0 の語に雑に置換するためのものではない。
既存の runtime・framework・protocol・platform が何を強く持ち、どこで process / responsibility / governance / durability の観点が不足しやすいかを見えるようにして、既知の語彙から PCE 2.0 へ安全に入るための接続面である。