MCP との対応関係

このページの目的は、PCE 2.0 を MCP の既存語彙へ無理に還元することではない。むしろ、MCP が何を標準化し、何を intentionally application / host 側に委ねており、PCE 2.0 がどこを引き受け、どこで独自の区別を持ち込むのかを明確にすることにある。

先に要点

MCP は、PCE 2.0 から見ると agent runtime そのものではなく、まず第一に context / capability exchange protocol である。
MCP の主語は host-client-server と protocol primitives であり、PCE 2.0 の主語は process frame と responsibility bundle である。
MCP は tools / resources / prompts / sampling / roots / elicitation / authorization / transport を標準化する。しかし、PCE 2.0 が重視する次は MCP の外側にある。
- goal ownership
- approval topology
- memory writing
- canonical / provisional distinction
- incident ownership
- corrupt success
したがって MCP は PCE 2.0 の競合ではなく、むしろ capability substrate bounded context substrate security / transport substrate として非常に相性がよい。
より短く言えば、 MCP は「どうつなぐか」を与え、PCE 2.0 は「つながれた能力をどういう process と responsibility のもとで使うか」を与える。

俯瞰表

MCP の概念	主に標準化するもの	PCE 2.0 での位置	PCE 2.0 が追加するもの
Host	orchestration container, connection governance, consent handling	outer runtime / outer governance shell	process frame / responsibility topology / current truth distinction
Client	host 内の connector, per-server session, capability negotiation	capability adapter / protocol edge actor	actor-local context semantics, responsibility bundle
Server	specialized context/capability provider	specialized actor / capability surface / resource surface	goal ownership, approval, memory writing, incident handling
Tools	model-invokable executable capability	execution substrate / capability scope material	approval / gate / rollback / durable-write discipline
Resources	context-bearing data exposure	selected inputs / by-reference reserve / evidence source	current truth vs candidate vs stale distinction
Prompts	user-invoked prompt templates	compiled-context seed / operational playbook seed	project-scoped operational memory governance
Roots	filesystem boundary declaration	capability boundary / scope boundary	frame-local bounded autonomy / retained authority
Sampling	nested model invocation via client	delegated reasoning / bounded child execution substrate	child-frame semantics / approval / recovery / auditability
Elicitation	structured user information request	clarification / missing-evidence / human-oversight path	process-local escalation / goal / approval / incident coupling
Capability negotiation	feature declaration at session start	protocol-level capability surface	process-level capability scope and retained / delegated semantics
Lifecycle (MCP connection)	initialization / operation / shutdown	connection lifecycle substrate	process lifecycle, gate lifecycle, delta lifecycle
Authorization	transport-level authz/authn	security / identity substrate	approval, memory write, incident, close authority
Tasks (experimental)	long-running protocol utility primitive	future continuity / workflow substrate	process-frame / recovery / ownership semantics

1. MCP は何を標準化しているのか

PCE 2.0 から見たとき、MCP の中心は次の三つにある。

1. Context exchange

resources や prompts によって、LLM application が外部から context を受け取る方式を標準化する。

2. Capability exposure

tools や sampling によって、LLM application が外部 capability を discover / invoke する方式を標準化する。

3. Security-boundary-preserving connectivity

host-client-server architecture、roots、authorization、capability negotiation によって、つながっていても boundary を保つ方式を標準化する。

このため MCP は、PCE 2.0 で言えばまず次として読むのが自然である。

context input substrate
capability substrate
transport / auth substrate

重要なのは、MCP 自体は 何を current project truth とみなすか 誰が goal を持つか どの success を採用してよいか までは定義しないという点である。

2. Host / Client / Server は PCE 2.0 でどう読めるか

MCP の host / client / server は、PCE 2.0 ではそのまま actor kind に 1:1 対応するわけではない。しかしかなりきれいに読み替えられる。

Host

MCP host は、connection permissions、lifecycle、authorization decisions、context aggregation を担う外側の container である。 PCE 2.0 では、これは最も近いところで次として読める。

outer runtime shell
outer governance shell
actor-local context compile の environment
approval / consent integration point

ただし host は、PCE 2.0 の Process Frame そのものではない。一つの host の中で複数 frame が走ることもあるし、一つの frame が複数 MCP server を跨ぐこともある。

Client

MCP client は host の内部で server との 1:1 session を持つ connector である。 PCE 2.0 では、これは次として読むのが自然である。

capability adapter
protocol edge
bounded connector actor

client は often process の主役ではない。しかし、次を current process に持ち込む重要な edge である。

何が reachable か
どの capability が negotiated されたか
どの roots / sampling / elicitation / notifications が有効か

Server

MCP server は、focused capability を持つ specialized provider である。 PCE 2.0 では、これは次に近い。

specialized actor
capability surface
resource surface
prompt surface

ただし決定的に重要なのは、MCP architecture 自身が server は whole conversation を読むべきではなく、focused capability を isolate して持つべき という設計原理を持っていることである。これは PCE 2.0 の Actor-local Compiled Context と Capability Scope に非常に近い発想である。

3. Tools は何に対応するか

MCP の tools は、model が discover / invoke できる executable capability である。 PCE 2.0 では、これは最も近いところで次に関係する。

どこが近いか

MCP tools は PCE 2.0 で言えば、execution substrate あるいは action surface に近い。

tool があることで actor は action を起こせる。しかし、それだけで次は決まらない。

その action を今やるべきか
それが in-scope か
それが approval を要するか
rollback path が必要か
canonical durable write として許されるか

PCE 2.0 が追加するもの

PCE 2.0 は、tool invocation をさらに次で bounded にする。

どの actor がその tool を使えるか
どの resource scope に対してか
どの effect class まで許すか
その invocation のあとに何を emit / record すべきか
どの violation で stop / escalate / rollback するか

つまり MCP tools は、PCE 2.0 では 何ができるか を与えるが、 いつ・どこまで・誰が・どの責任で使ってよいか は別途定義される。

4. Resources は何に対応するか

MCP の resources は、files、schemas、app-specific information など、language model に context を与える data surface である。 PCE 2.0 では、これは主に次へ対応する。

どこが近いか

resources は、PCE 2.0 における source pool の一部として非常に自然である。

specs
schemas
docs
issue data
logs
codebase artifacts

などを MCP resources として expose し、そこから actor-local compiled context を作ることは、かなり正攻法に見える。

どこが違うか

ただし PCE 2.0 は、resource をそのまま current truth と同一視しない。 resource はあくまで次である。

candidate context
evidence source
by-reference reserve
external source of truth for some bounded domain

PCE 2.0 が問うのは、そこからさらに次である。

何を active に選ぶか
何を omitted / by-reference にするか
何が stale か
何が required evidence floor か

つまり resources は PCE 2.0 では context-bearing substrate に近い。

5. Prompts は何に対応するか

MCP の prompts は、user-controlled に発火される prompt templates であり、structured instructions / messages を server から client に expose する仕組みである。

PCE 2.0 では、これは最も近いところで次に対応する。

compiled-context seed
reusable interaction template
operational playbook seed

どこが近いか

PCE 2.0 の Operational Memory や reusable review template、analysis template を MCP prompt として expose することはかなり自然である。

どこが違うか

ただし PCE 2.0 は prompt をそのまま理論の主語に置かない。 Prompt はあくまで次である。

local view の seed
reusable instruction artifact
interaction contract の一部

であって、次そのものではない。

goal ownership
approval authority
memory writing authority
process lifecycle

つまり MCP prompts は、PCE 2.0 では reusable local interaction surface として読むのが自然である。

6. Roots は何に対応するか

MCP の roots は、filesystem boundary を host / client 側から server に伝える仕組みである。 PCE 2.0 では、これは非常にきれいに次へ対応する。

Capability Scope
scope constraints
bounded autonomy

どこが近いか

roots は「何を見てよいか」だけではなく、server がどの directory / files に対して operate するのかの boundary を与える。これは PCE 2.0 でいう次とかなり近い。

resource scope
operation scope
bounded child autonomy

PCE 2.0 が追加するもの

PCE 2.0 は roots のような boundary を filesystem だけでなく、さらに次まで拡張する。

approval scope
memory collection scope
branch-local capability
recovery-local scope
canonical / provisional write scope

つまり roots は、PCE 2.0 では capability-boundary design の局所実装例 に近い。

7. Sampling は何に対応するか

MCP の sampling は、server が client 経由で LLM generation を request する仕組みであり、nested / agentic behavior を可能にする。しかも sampling request には human-in-the-loop を推奨し、client が model access・selection・permissions を retain する。

PCE 2.0 では、これは主に次へ対応する。

bounded delegated reasoning
child-like local execution
adjunct analysis / evaluation path
human oversight gate

どこが近いか

sampling は PCE 2.0 でいうと、

child frame を full に切るほどではないが
local bounded reasoning を別 actor / server に委ねる

ような場面に近い。

たとえば server が次を client LLM に依頼するのは、PCE 2.0 では bounded delegated execution or evaluation と読める。

classification
option comparison
local summarization
tool-enabled nested deliberation

どこが違うか

ただし sampling 自体は、まだ process unit ではない。 PCE 2.0 ではさらに、次を問う。

その sampling がどの goal slice のためか
その結果が delta になるのか
それを later eval / approval / promotion に使ってよいか
stale になったときどう invalidate するか

つまり MCP sampling は、PCE 2.0 では nested reasoning substrate であって、process semantics そのものではない。

8. Elicitation は何に対応するか

MCP の elicitation は、server が user から必要な情報を structured に集める仕組みであり、current spec では form mode と URL mode を持つ。特に URL mode は、auth flow、payment、sensitive info など、MCP client を通すべきでない out-of-band interaction を安全に扱うための仕組みとして入っている。

PCE 2.0 では、これは主に次へ対応する。

missing-evidence path
clarification path
human-oversight trigger
escalation-lite
out-of-band secure completion path

どこが近いか

PCE 2.0 では、local actor が必要情報を持たず current path を続けられないとき、次が起きる。

clarification
missing evidence request
human oversight
escalation

elicitation は、そのうちの user-supplied missing information にかなり近い。

URL mode が示唆すること

URL elicitation が current spec で重要なのは、MCP 自身が「sensitive flow は protocol 内の普通の context exchange に混ぜるべきではない」という設計を explicit にしている点である。

PCE 2.0 から見ると、これは非常に重要な signal であり、次の設計と親和的である。

capability scope
governance surface
human oversight
auditability

つまり elicitation は、PCE 2.0 では 必要情報の human / out-of-band acquisition を bounded に扱う仕組み と読める。

9. Capability negotiation と MCP lifecycle は何に対応するか

MCP には、connection-level の lifecycle と capability negotiation がある。

initialization
operation
shutdown

そして initialization 時に、client / server が support する capabilities を明示的に宣言する。

PCE 2.0 から見た対応

これは最も近いところで、次に対応する。

outer runtime lifecycle
protocol-level capability envelope
transport-level admissibility

どこが近いか

MCP の capability negotiation は、PCE 2.0 の Capability Scope に似て見える。ただし厳密には違う。

MCP capability negotiation → protocol feature support の宣言
PCE 2.0 capability scope → current frame / actor / phase で何が allowed か

前者は connection substrate、後者は process-local governance である。

MCP lifecycle と PCE lifecycle の違い

MCP lifecycle は connection の initialization / operation / shutdown である。 PCE 2.0 の Lifecycle は次のような process state である。

active
pending approval
blocked
suspended
recovering
completed
abandoned
superseded

つまり MCP lifecycle は connection lifecycle、 PCE lifecycle は process lifecycle であり、同名でも扱うレイヤが違う。

10. Authorization は何に対応するか

MCP authorization は、HTTP-based transport のための transport-level authorization flow であり、current spec では OAuth 2.1 系の resource server / discovery / metadata を使う。 STDIO transport ではこのフローを使わず、environment など別経路を想定する。

PCE 2.0 では、これは主に次へ対応する。

outer identity / auth substrate
capability surface precondition
human oversight and approval integration point

どこが近いか

authorization は、PCE 2.0 の process が使う capability の前提条件になりうる。たとえば MCP server に対する access token が取れなければ、その resource や tool は scope 外になる。

どこが違うか

PCE 2.0 は、authorization を approval と混同しない。これが重要である。

MCP authorization → transport-level access authorization
PCE approval → process-local ratification
PCE memory writing authority → durable-state mutation authority
PCE incident ownership → abnormal-flow acceptance authority

つまり OAuth token があるからといって、次とはならない。

merge してよい
canonical memory を書いてよい
rollback を命じてよい
frame を close してよい

MCP authorization は、PCE 2.0 では 必要だが不十分な outer security layer である。

11. MCP が意図的に標準化しないもの

PCE 2.0 から MCP を読むうえで重要なのは、MCP がかなり意識的に 標準化しない領域 があることだ。

MCP が主に扱わないもの

global goal ownership
approval topology
frame close semantics
canonical / provisional distinction
durable project state ontology
memory promotion criteria
corrupt-success detection
incident sink and closure
rollback horizon and admissibility
parent-child retained authority semantics
branch join conflict resolution semantics

これは MCP の弱さではなく、設計境界である。 MCP は「何をどうつなぐか」にフォーカスしており、その上で host / application / framework が process semantics を作る。

PCE 2.0 は、まさにその 上位の process semantics を埋める理論だと読める。

12. PCE 2.0 が MCP に追加する区別

PCE 2.0 は、MCP を強い substrate として受け取りつつ、少なくとも次の distinction を追加する。

1. Process Frame

MCP session や tool / resource exchange を、仕事単位としてまとめる構造。 → Process Frame

2. Responsibility Bundle

同じ MCP-connected actor でも、誰が goal / execution / approval / evaluation / memory / incident を持つのかを分ける。 → Responsibility Bundle

3. Actor-local Compiled Context

MCP resources / prompts / tool outputs / prior state から、actor-relative な local view を compile する。 → Actor-local Compiled Context

4. Durable Project State

MCP session continuity と project current truth を分ける。 → Durable Project State

5. Process Delta

MCP-connected execution / evaluation / review / recovery の結果を、current truth ではなく typed change candidate として扱う。 → Process Delta

6. Approval / Memory Writing / Incident Ownership

tool access, resource access, protocol auth とは別に、process-local な adoption / mutation / abnormal-flow authority を定義する。 → Approval, Memory Writing, Incident Ownership

7. Corrupt Success

見かけ上うまく動いたが、そのまま current truth や durable memory にしてはいけない状態を explicit に扱う。 → Corrupt Success

つまり PCE 2.0 は、MCP の上に process / responsibility / durability / adoption discipline を重ねる。

13. 実務上の最短な読み替え

MCP を PCE 2.0 の中で実装的に読むなら、まずは次の読み替えで十分である。

host → outer runtime / outer governance shell
client → protocol adapter / capability edge
server → specialized capability actor or surface
resources → context source pool
prompts → reusable local interaction template
tools → executable capability surface
roots → bounded filesystem scope
sampling → nested delegated reasoning / bounded sub-execution
elicitation → human / user supplied missing evidence path
capability negotiation → transport-level capability envelope
authorization → outer auth substrate
lifecycle → connection lifecycle, not process lifecycle

この読み替えのうえで、PCE 2.0 は MCP を次のように使う。

MCP resources を actor-local compiled context の source にする
MCP tools を capability scope の material にする
roots を bounded autonomy の filesystem boundary に使う
sampling を child-like delegated reasoning に使う
elicitation を human oversight / clarification path に使う
protocol auth を process-local approval と混同しない
MCP session continuity を durable project truth と混同しない

Representative Sources

このページの比較は、主に次の公式資料群を参照軸としている。

Specification

Base protocol

Server features

Client features

Learn docs

暫定的なまとめ

MCP は、AI application と外部 context / capabilities をつなぐための protocol として非常に強い。それは、次をうまく標準化している。

context をどう expose するか
tools をどう invoke するか
boundaries をどう communicate するか
nested model use をどう扱うか
transport と auth をどうするか

しかし MCP 自体は、development をどう定義するかまでは決めない。そこに PCE 2.0 が入る。

より短く言えば、次の関係である。

MCP は connectivity, capability, and context exchange を与える
PCE 2.0 は process, responsibility, and durable truth discipline を与える

この二つは競合しない。むしろ MCP の上で PCE 2.0 を使うと、次の形で、MCP を単なる protocol ではなく、AI 時代の開発 process を支える substrate として読めるようになる。

server isolation は actor-local context になる
roots は capability scope になる
sampling は bounded delegated execution になる
elicitation は human oversight path になる
resources / prompts / tools は process-local compiled context の素材になる
authorization は approval ではなく outer auth substrate として位置づく