問題設定

このページは、PCE 2.0 が何を解こうとしているのかを明示するための出発点です。
ここで言いたいのは単純です。
いま問題になっているのは、コンテキストだけではない。プロセスそのものが問題になっている。

問題の要約

PCE 2.0 が必要になるのは、AI を使った開発の難しさが、もはや「モデルに何を見せるか」だけでは説明できなくなったからです。

現在の開発では、少なくとも次の問題が同時に発生しています。

仕事が 単発の応答 ではなく 長時間・多段・多主体の実行 になっている
context を大きくしても、それだけでは仕事の継続性は担保されない
人間、AI、tool、document、policy が同じプロセスに参与するようになった
責任、権限、承認、評価、記憶更新の境界が露出し始めた
成果物だけを見ても、プロセスの健全性が判断できなくなった

PCE 2.0 は、この状況を
「責任の遷移を中心に、局所コンテキストを compile し、評価済み差分だけを durable state に還流させる問題」
として捉え直します。

1. 仕事の単位が「応答」から「実行」へ移った

以前の AI 活用では、主な関心は「よい出力を一度で得ること」でした。
しかし現在の主要な実装や公式ドキュメントは、すでにその前提を離れています。

いま中心にあるのは、次のような仕事です。

複数ステップで進む
途中で tool を使う
状態を保持する
承認待ちで止まる
失敗後に再開する
別の agent や人間に handoff する
最後に評価して merge する

つまり、単一の prompt ではなく、ひとつの実行系としての仕事 が対象になっています。

この変化によって、問題の焦点も変わりました。
もはや問うべきなのは「どう prompt を書くか」だけではありません。
問うべきなのは、どう進めるか、どこで止めるか、何を引き継ぐか、誰が確定するか です。

2. context engineering は必要だが、それだけでは足りない

この変化の中で、context engineering はたしかに重要になりました。
実際、現在の公式資料でも、何を現在の推論に入れるか、何を落とすか、どの情報を先に見せるかは核心的な論点になっています。

ただし、ここで一つ重要なことがあります。

context engineering は必要条件であって、十分条件ではありません。

理由ははっきりしています。

長い context window は、長い仕事そのものではない

大きな context window があっても、それだけで長時間の仕事が安定するわけではありません。
履歴が伸びれば、古い情報が混ざり、焦点が散り、何を残し何を要約するかが問題になります。

したがって本当の問題は、単に「多く入れること」ではありません。
むしろ次の設計です。

何を active に保つか
何を compact するか
何を memory に退避するか
何を次の session に引き継ぐか
どの checkpoint から再開できるか

ここで必要なのは、context の設計だけではなく、context の生涯を管理する process です。

3. 「ひとつの Active Context」では足りない

PCE 1.0 では Active Context が中心語でした。
この考えは今でも有効ですが、PCE 2.0 ではそのままでは足りません。

なぜなら、現在の実装では、同じ仕事の中でも「誰が何を見るべきか」が分かれているからです。

たとえば、次の actor は同じ情報を必要としません。

実装を進める AI agent
承認を行う人間
結果を検証する evaluator
途中状態を保存する runtime
監査する governance layer

実際、現在の agent SDK や workflow runtime は、モデルが見る入力と、アプリケーションが保持する local state を分けて扱っています。
また、tool 呼び出しや handoff、approval の際には、それぞれ異なる view が必要になります。

このため、PCE 2.0 では context を単数で考えません。
中心に置くのは、actor ごとに責任に応じて compile される局所視界 です。

これが Actor-local Compiled Context です。

4. AI の導入によって、責任の境界が露出した

AI を使わない開発では、多くの責任が人間側に束ねられていました。
しかし AI を組み込むと、その束が分解されます。

たとえば、次の責任は分けて考えなければなりません。

何を達成するのかを決める責任
実際に手を動かす責任
何をしてよいかを決める権限
結果を承認する権限
成功か失敗かを判定する責任
durable state を更新してよい責任
事故や逸脱を最終的に引き受ける責任

現在の AI runtime は、これを隠していません。
むしろ pause / resume、approval、tool permission、session state、control plane、agent identity といった形で、責任の分解が表面化しています。

ここで本当に重要なのは、プロセスを「作業の順番」としてではなく、責任の配分と遷移の仕組み として見ることです。

PCE 2.0 は、まさにそこを中心に据えます。

5. actor は増えたが、責任は対称ではない

PCE 2.0 では、人間だけが actor ではありません。

AI agent
subagent
tool
MCP server
CI
document
policy
registry
identity
approval gate

これらはすべて、プロセスの状態を変えうる存在です。

この点では、人間と AI はかなり同じ分析平面に立っています。
しかし、ここで誤ってはいけない点があります。

actor であること と
責任や権限が同じであること は別です。

現在の実装では、AI は実行や提案を担えても、approval、governance、incident ownership、memory promotion の一部は人間側に留保されやすいです。
つまり、現代の AI 開発で起きているのは「完全な対称化」ではありません。

起きているのは、
対称的な actor 性の拡大と、非対称的な責任配分の明示化
です。

この非対称性を扱えない理論は、現代の実務に追いつけません。

6. memory は「履歴の蓄積」ではなく「昇格の規則」になった

長時間の仕事では、すべてを context に残すことはできません。
だから memory が必要になります。

ただし、ここでも重要なのは、memory を単なる保存場所として見ないことです。

本当に問うべきなのは、次のことです。

何を durable に残すのか
何を session 限りにするのか
何を再利用可能な skill / workflow knowledge として昇格させるのか
誰がその昇格を許可できるのか
どの評価を通ったら project state に入れてよいのか

この意味で、memory は 会話履歴の延長 ではありません。
memory は、次の仕事の初期条件を構成するための制度 です。

PCE 2.0 が Durable Project State を中心語に置くのは、そのためです。

7. 成果物だけではなく、プロセスそのものが評価対象になった

現在の実務では、結果が一見正しく見えても、それだけでは安心できません。

たとえば、次のような問題があります。

禁止された tool を使っていないか
承認を飛ばしていないか
本来保存すべき判断根拠を失っていないか
再開不能な形で状態を壊していないか
同じ失敗を何度も繰り返していないか
実行手順そのものが劣化していないか

このため、評価の対象は output だけでは足りません。
run、trace、handoff、approval、checkpoint、memory promotion まで含めて、process 自体を評価する必要 が出てきます。

PCE 2.0 の原則である No merge without eval は、ここから導かれます。

8. 既存の語彙は重要だが、まだ分断されている

現在の主要な公式語彙には、それぞれ役割があります。

context engineering は、何を入れるかを扱う
workflow / orchestration は、どう流すかを扱う
durable execution は、どう継続するかを扱う
memory / skills は、何を再利用するかを扱う
control plane / governance は、どう監視し統治するかを扱う
agent identity は、誰に何を許すかを扱う

どれも重要です。
ただし問題は、これらがまだ別々に語られやすい ことです。

PCE 2.0 が必要なのは、これらを無視するためではありません。
逆です。
これらを ひとつの process-centered theory として接続するためです。

PCE 2.0 は、現在ばらばらに現れている概念群を、
責任の遷移と局所コンテキストの compile という軸で束ねる
ことを目指します。

9. ここで立てるべき中核的な問い

この問題設定から、PCE 2.0 が立てるべき問いはかなり明確になります。

プロセスに関する問い

仕事をどの単位で process frame に分けるのか
どこで分岐し、どこで合流させるのか
どこで checkpoint を切るのか
どこで再計画し、どこで rollback するのか

責任に関する問い

誰が goal owner なのか
誰が executor なのか
誰が approver なのか
誰が evaluator なのか
誰が memory writer なのか
誰が incident owner なのか

context に関する問い

どの actor にどの局所視界を見せるのか
何を active にし、何を compact し、何を外に退避するのか
visibility と capability をどう scope するのか

memory に関する問い

何を durable state に昇格させるのか
その昇格条件は何か
その根拠と評価履歴をどう残すのか

evaluation に関する問い

何をもって成功とするのか
output と process をどう分けて評価するのか
どの delta を merge してよいのか

この一連の問いに答えるための枠組みが、PCE 2.0 です。

10. このページでの暫定的な結論

このページの結論は、次の一文に要約できます。

AI時代の開発で本当に問題になっているのは、
「どうコンテキストを詰めるか」だけではなく、
「責任をどう分解し、どの actor にどの局所コンテキストを与え、どこで止め、何を評価し、何を durable state に残すか」である。

つまり、問題の中心は context shortage ではありません。
問題の中心は、責任が分解された状況で、プロセスをどう成立させるか です。