OpenAI との対応関係

このページの目的は、PCE 2.0 を OpenAI の既存用語へ無理に還元することではない。

むしろ、OpenAI の current stack がそれぞれ何を強く説明し、PCE 2.0 がどこを引き受け、どこで独自の区別を持ち込むのかを明確にすることにある。

先に要点

OpenAI の current stack を PCE 2.0 から見ると、大まかに次のように整理できる。

Responses API、Conversations、Sessions は、会話状態や run continuity を扱う継続基盤に近い。OpenAI は current docs で Responses API を stateful な中心 API として扱い、Conversations API や previous_response_id による継続、Agents SDK の Sessions による persistent memory / resumable runs を提供している。
Agent Builder と Agents SDK は、handoffs、guardrails、sessions、tracing を含む orchestration 基盤に近い。OpenAI は orchestration を「multiple steps、tool use、handoffs、guardrails、context を扱うもの」と説明し、Agents SDK の core primitives を Agent、Handoff、Guardrail、Session と整理している。
tools、MCP and Connectors、Skills、Shell、tool search、native compaction は、capability と context management の実行基盤に近い。OpenAI は remote MCP / connectors に explicit approval をかけられるようにし、Skills を versioned な reusable bundles として扱い、Responses API には tool search と native compaction を追加している。

PCE 2.0 は、この OpenAI stack を否定しない。むしろかなり親和的である。

ただし、PCE 2.0 の主語は runtime や orchestration primitive ではなく、process と responsibility である。この差が決定的である。

1. OpenAI の current stack をどう読むか

OpenAI の公式導線では、agent 構築は AgentKit という大きな枠で整理され、Agent Builder で workflow を組み、ChatKit で埋め込み、agent evals や trace grading で最適化する、という構成になっている。また、workflow 自体は「agents、tools、control-flow logic の組み合わせ」として説明されている。

PCE 2.0 から見ると、これはかなりよくできた実装レイヤの整理である。ただし PCE 2.0 は、そこで一歩先へ進み、次の問いを explicit にする。

誰が goal を保持しているのか
誰が execution を担い、誰が approval を持ち、誰が memory を書けるのか
何が canonical で、何が provisional なのか
何が process failure で、何が corrupt success なのか
何を durable project state として future process の前提にしてよいのか

つまり OpenAI の stack は、PCE 2.0 から見ると強い runtime / tooling / orchestration substrate であり、PCE 2.0 はその上に乗る process theory である。

2. Responses API / Conversations / Sessions は何に対応するか

OpenAI は Responses API を current state management の中心に置いている。公式 docs では Responses API を stateful な選択肢として推奨し、Conversations API による durable な conversation object や previous_response_id による chaining を提示している。また Agents SDK の Sessions は、過去の conversation items を次 turn に prepend し、新しい入出力を保存し、interrupted RunState から later resume できる persistent memory layer として説明されている。

PCE 2.0 でこれに最も近いのは、まず継続基盤である。ただし、対応は 1:1 ではない。

Responses API / Conversations / Sessions は、PCE 2.0 では runtime continuity に近い
Recovery Point や Checkpoint and Recovery とも強く関係する
しかし、それだけでは Durable Project State そのものではない

この差は重要である。 OpenAI の stateful conversation は「会話や run をまたいで状態を持つ」ための仕組みであり、PCE 2.0 の Durable Project State は「project の current truth を型付きで保持する永続層」である。前者は continuity substrate、後者は project ontology である。

言い換えると、OpenAI の current stack は state continuity を強く扱うが、PCE 2.0 はそこに canonical / provisional distinction と memory mutation semantics を追加する。

3. Agents SDK は何に対応するか

OpenAI Agents SDK は、少数の primitives で orchestration を組むものとして設計されている。公式 docs では core primitives を Agents、Agents as tools / Handoffs、Guardrails とし、主要機能として agent loop、handoffs、guardrails、function tools、MCP server tool calling、sessions、human in the loop、tracing を挙げている。

PCE 2.0 から見た対応は次のようになる。

Agent

OpenAI の Agent は「instructions と tools を持つ LLM」というまとまりであり、実装上とても扱いやすい。しかし PCE 2.0 では、それを一つの塊としては扱わない。少なくとも次へ分解する。

つまり OpenAI Agent は、PCE 2.0 では便利な runtime aggregate に近い。

Handoff

OpenAI の handoffs は、専門領域の違う agent へ task を委ねる機構であり、実装上は tool-like に扱われる。

これは PCE 2.0 の Handoff にかなり近い。ただし PCE 2.0 はさらに、次まで explicit に持ち込む。

transferred / retained responsibility
pending gate continuity
return contract
later recovery semantics

OpenAI handoff は delegation primitive として強く、PCE 2.0 handoff は continuity contract としてより広い。

Sessions

OpenAI の sessions は persistent memory layer として useful だが、PCE 2.0 では主に short-term continuity substrate に相当する。 project-scoped durable truth までを自動的に与えるわけではない。

Tracing

OpenAI tracing は、LLM generations、tool calls、handoffs、guardrails、custom events を記録し、Traces dashboard で debug / monitor できる。

これは PCE 2.0 の Auditability と Process Metrics に非常に近い substrate である。ただし trace は event record であり、PCE 2.0 が求める次までは、trace だけでは足りない。

current truth の理由
invalidation / supersession の意味
canonical / provisional の区別
corrupt success の explanation

PCE 2.0 は trace を意味づける理論を追加する。

4. Agent Builder は何に対応するか

OpenAI の Agent Builder は、multi-step workflow を visual canvas で組み、typed edge で nodes をつなぎ、preview し、publish して versioned object として deploy する仕組みである。workflow は agents、tools、control-flow logic の組み合わせとして説明される。

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

ただし差分も大きい。 OpenAI Agent Builder は workflow composition に強いが、PCE 2.0 はそこに次を追加する。

goal ownership の明示
retained authority と delegated responsibility の明示
incident ownership の存在
memory mutation policy の存在
frame close の意味（completed / abandoned / superseded）
runtime continuity ではなく project continuity をどう残すか

つまり Agent Builder workflow は、PCE 2.0 では process topology の実装形に近いが、PCE 2.0 自体は topology だけでなく、責任の存在論を中心に置く。

5. Guardrails, HITL, MCP は何に対応するか

OpenAI Agents SDK の guardrails は、input guardrails、output guardrails、tool guardrails に分かれ、workflow 上でもどのタイミングで走るかが分かれている。input guardrails は chain の最初の agent に、output guardrails は final output に、tool guardrails は各 custom function-tool invocation に適用される。

また OpenAI の human-in-the-loop は approval-based で、tool call に approval が必要だと run が pause し、interruptions と RunState を通して later resume できる。しかもその approval surface は run-wide で、nested agent.asTool() や handoff 越しでも outer run に現れる。

さらに OpenAI の MCP and Connectors は、model に新しい capability を与える仕組みであり、tool calls は自動許可も developer-controlled な explicit approval もできる。

PCE 2.0 から見ると、これは次のように読める。

guardrails → Governance Surface の一部
approval-based HITL → Approval Points + Human Oversight + Checkpoint and Recovery
MCP / connectors → Capability Scope の substrate

ただし、PCE 2.0 は OpenAI の guardrails / HITL より広く governance を捉える。 OpenAI の docs が特に強いのは次である。

input / output / tool guardrails
approval-based tool execution gating
MCP approval control
prompt-injection / private-data leakage risk

一方 PCE 2.0 は、そこに加えて次まで governance の一部として扱う。

goal reframe
rollback / resume
canonical durable write
incident closure
supersession / invalidation
omission traceability

つまり OpenAI の guardrails / HITL は、PCE 2.0 の governance surface の強い部分集合だと読むのが自然である。

6. Skills / Shell / Compaction は何に対応するか

OpenAI の Skills は versioned bundle of files + SKILL.md manifest であり、local execution と hosted container-based execution の両 form factor を持つ。OpenAI の blog では、Skills は “the how” を encode し、Shell は “the do” を execute し、Compaction は long-running agents を coherent に保つ、と整理されている。さらに Responses API には native compaction、tool search、hosted shell、skills が追加されている。

PCE 2.0 から見ると、これはかなり面白い対応になる。

Skills → Operational Memory の候補、あるいは reusable procedure bundle
Shell → Execution の substrate
compaction / tool search → Context Budget / Context Selection / Compaction の substrate

ただし差分は明確である。 OpenAI Skills は reusable execution bundle として強いが、PCE 2.0 はさらに次を問う。

どの skill が project-scoped durable memory になるのか
canonical か provisional か
どの evaluation を通るのか
誰が write authority を持つのか
いつ stale / superseded とみなすのか

つまり OpenAI は reusable procedure を提供し、PCE 2.0 はそれを project knowledge として採用してよいかを問う。

同様に、native compaction や tool search は context / runtime の問題をかなり platform 側へ押し下げてくれる。しかし PCE 2.0 の立場では、floor > ceiling になったときに必要なのは compaction の工夫だけではなく、frame を分けることや branch / checkpoint / escalation / reframe である。この点で PCE 2.0 は compaction を技法ではなく process design の signal として読む。

7. Evals と Trace grading は何に対応するか

OpenAI は agent evals と trace grading を agent optimization の中核に置いている。公式 docs では agent evals は workflow-level の quality measurement であり、trace grading は trace に structured score / label を付けて correctness・quality・adherence を測り、orchestration or behavior の改善につなげるものとされている。

これは PCE 2.0 では、かなり直接的に次へ対応する。

特に trace grading は、OpenAI stack の中で最も PCE 2.0 の process evaluation に近い。なぜなら trace grading は output だけでなく trace を見るからである。

ただし、ここでも PCE 2.0 は一歩追加する。 OpenAI の evals / trace grading は主に optimization loop に寄っている。 PCE 2.0 はそれを次へ直接つなぐ。

merge / promotion / close の前提条件
corrupt success の検知
memory mutation discipline
canonical / provisional の分岐

つまり OpenAI evals が「改善のための測定」に強いのに対し、PCE 2.0 evals は「採用してよいかの制度」にまで踏み込む。

8. OpenAI stack が分散して持っているものを、PCE 2.0 は名前づける

OpenAI の official stack は非常に強い。だが、その強さは runtime / tooling / orchestration / evals / safety に分散している。 PCE 2.0 は、その分散している concern を、開発理論として再命名し、束ね直す。

PCE 2.0 が explicit に立てる区別は、たとえば次である。

Goal Ownership
Incident Ownership
Memory Writing
Durable Project State における canonical / provisional distinction
Process Delta と current truth の区別
Recovery Point を provisional durable object として扱うこと
Corrupt Success を独立の評価概念として扱うこと

これらは OpenAI docs に「存在しない」と言いたいのではない。むしろ OpenAI docs では、workflow、guardrails、sessions、tracing、agent evals、skills、MCP approval などの形で分散して現れている。 PCE 2.0 はそれらを、開発を新しく定義するための ontology としてまとめて explicit にする。

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

OpenAI stack の上で PCE 2.0 を使うなら、まずは次の読み替えで十分である。

Responses API / Conversations / Sessions → 継続 substrate。PCE 2.0 では recovery / session continuity の足場
Agents SDK / Agent Builder → orchestration substrate。PCE 2.0 では frame / transition / handoff の実装面
Tools / MCP and Connectors / Shell → capability substrate。PCE 2.0 では capability scope の material
Guardrails / Human-in-the-loop → governance substrate。PCE 2.0 では governance surface / approval points / human oversight
Tracing / Agent evals / Trace grading → observability / evaluation substrate。PCE 2.0 では process evaluation と process metrics の足場
Skills → reusable procedure substrate。PCE 2.0 では operational memory 候補

この読み替えのうえで、PCE 2.0 は OpenAI stack の「使い方」を次の方向へ強くする。

orchestration を responsibility-aware にする
stateful conversation を durable project state と混同しない
trace を current truth の説明可能性へつなぐ
skills を procedural memory として評価・昇格する
guardrails / HITL を process-wide governance に広げる
evals を optimization だけでなく merge / promotion discipline に接続する

暫定的なまとめ

OpenAI の current stack は、agent 構築のための実装基盤としてかなり強い。 Responses API、Conversations、Agents SDK、Agent Builder、guardrails、HITL、MCP、Skills、Shell、tracing、agent evals、trace grading まで揃っており、runtime・tooling・workflow・state・safety・evaluation の主要部品はほぼ出そろっている。

PCE 2.0 は、その部品群の代替ではない。それらを process / responsibility / durable state の観点から束ね直す理論である。

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

OpenAI は build / run / observe / optimize の stack を与える
PCE 2.0 は what development is, under AI conditions の theory を与える

この二つは競合しない。むしろ、OpenAI stack の上で PCE 2.0 を使うと、次のように開発の定義が一段深くなる。

workflow が process になる
session state が continuity semantics になる
traces が auditability になる
skills が operational memory 候補になる
evals が merge / promotion discipline につながる