Skip to content

Glossary

このページは PCE 2.0 の用語の早引きです。
各用語の正規定義はリンク先のページにあります。ここでは短い説明と、よく混同される近接概念だけをまとめます。
定義の衝突が起きた場合は、各リンク先のページを優先します。

前稿で提示した Process-Context Engine の初期形です。
Potential Context Pool(候補コンテキスト全体)、Active Context(その時点で実際に使う文脈)、Context Delta(文脈差分)、Engine(それらを回す機構)を中心に、「プロセスがコンテキストを生み、コンテキストが次のプロセスを駆動する」という循環を示しました。
See: PCE 1.0 から 2.0 へ

AI 時代の開発を、単なる prompt 設計や context 最適化ではなく、責任の遷移を伴う process architecture として捉える枠組みです。
context は主語ではなく、process と responsibility から compile される局所視界として扱われます。
See: PCE 2.0 とは何か

ある frame の中で、transition、visibility、capability、evaluation、promotion、recovery のいずれかに意味的な影響を与えうる存在です。
人間に限らず、AI agent(実行主体)、tool(道具)、document(拘束条件を持つ文書)、policy(規則)、registry(参照台帳)、runtime(実行環境)も actor になりえます。
See: Actor

実際に work を進めたり transition を起こしたりする actor です。
たとえば human reviewer、coding agent、tool runner、checkpoint manager など、実作業を前に進める actor です。
See: Actor

自ら作業を進めなくても、解釈、受入条件、scope、authority、policy を拘束する actor です。
approved spec、policy、registry、accepted rubric(採用済み評価基準)などが典型です。
See: Actor, Governance Surface

PCE 2.0 における process は、単なる step の列ではありません。
責任、権限、局所コンテキスト、gate、delta、recovery を含む遷移の体系です。
See: Process-first, Transitions

PCE 2.0 における仕事単位の基本構造です。
goal、success criteria、actors、responsibility allocation(責任配分)、capabilities、constraints、approval points、eval contract(評価契約)、memory write policy(記憶書き込み方針)、recovery strategy を持つ、統治可能な実行単位です。
See: Process Frame

ある actor が、ある frame のある局面で引き受けている責務・権限・能力境界・帰責条件の束です。
role や permission 単体ではなく、goal_ownership(目標保持責任)、execution(実行責任)、approval_authority(承認権限)、evaluation_authority(評価権限)、memory_write_authority(記憶書き込み権限)、incident_ownership(異常時引受責任)などを局所的にまとめて持ちます。
See: Responsibility Bundle

ある frame が何を達成すべきか、どこまでが scope か、何をもって完了とみなすかを定義・維持・再解釈・受理する責任です。
execution や approval と同一ではなく、goal の同一性と completion acceptance(完了として受け入れる条件)を保持します。
See: Goal Ownership, Responsibility-first

与えられた goal slice と制約のもとで、実際に work を進め、evidence を生成し、delta を出し、必要なら stop・handoff・checkpoint を行う責任です。
goal ownership や approval と同一ではなく、bounded action(制約付き行為)と continuity preservation(継続性の維持)の責任を持ちます。
See: Execution, Process Delta, Handoff

特定の subject を次の legal transition へ進めてよいかを、正当な authority に基づいて承認・reject・差し戻し・例外処理する責任です。
evaluation や execution と同一ではなく、gate を解く verdict semantics(判定の意味)と追跡可能な authority 行使を含みます。
See: Approval, Approval Points, Eval Contract

特定の subject が結果として十分か、過程として妥当か、根拠として十分かを、criteria と evidence に基づいて判定し、判定結果を生成する責任です。
approval と同一ではなく、outcome / process distinction(結果と過程の区別)、insufficient evidence(根拠不足)、re-evaluation trigger(再評価のきっかけ)を扱います。
See: Evaluation, Eval Contract, Outcome vs Process

memory candidate や process delta 由来の知識項目を、適切な durable collection に canonical / provisional の区別つきで書き込み、更新、置換、保留、退役させる責任です。
evaluation や approval と同一ではなく、durable form の構成、provenance(由来の追跡可能性)、重複排除、supersession(後続項目による置き換え関係)を扱います。
See: Memory Writing, Durable Project State, Memory Promotion Rules

frame 全体の goal ではなく、ある actor や child frame が局所的に引き受ける goal の断面です。
handoff や actor-local context では、通常この goal slice(目標の局所切り出し)が渡されます。
See: Actor-local Compiled Context, Handoff

ある retained responsibility のうち、人間や他の authority-bearing actor に最終的に残すべき正当化・受容・例外判断・終端判断の核です。
責務全体や前処理 labor 全体ではなく、reframe、trade-off legitimacy、exception approval、residual risk acceptance、canonical write ratification、closure などの bounded decision surface を指します。
See: Responsibility-first, Human Oversight

本来は retained authority だけが残るはずの human-held responsibility が、raw evidence 読解、候補整理、重複排除、鮮度判定、ログ再構成などの前処理労働まで抱え込んだ状態です。
PCE 2.0 では anti-pattern として扱います。
See: Human Oversight, Responsibility-first

失敗、逸脱、policy violation、重大な曖昧性などが起きたときに、最終的に引き受ける責任です。
execution を担っている actor と incident owner は一致しないことがあります。
See: Incident Ownership, Responsibility Bundle, 対称的アクター性、非対称的責任

同じ process に関わる actor 間で、goal ownership、execution、approval、evaluation、memory writing、incident ownership などが均等ではなく、明示的・境界付き・追跡可能に配分されている構造です。
不透明な格差ではなく、governed process(統治可能なプロセス)を成立させるための責任配置の性質として扱います。
See: Asymmetry, 対称的アクター性、非対称的責任, Responsibility Bundle

ある actor が、その局面の responsibility bundle を遂行するために compile される局所視界です。
単なる prompt や検索結果ではなく、goal slice、relevant state、allowed actions、constraints、expected output、stop conditions を含む実務上のインターフェースです。
より正確には、ALCC 自体が topology なのではなく、その compile を topology 上の局所閉包 / 境界切断 / package として自然に定義できる、と理解するのが近いです。
本文では actor-local context と略記することがあります。
See: Actor-local Compiled Context, Topology, Context Selection, Context Budget

ある actor が、ある frame のある局面で安全かつ十分に持てるアクティブコンテキストの上限と下限を定める予算です。
単なる token 上限ではなく、safety floor(最低限落としてはいけない情報)、hard ceiling(超えてはいけない上限)、required evidence(必要な根拠)、visibility / capability limits、freshness bounds(鮮度条件)を含む制約付きコンテキスト配分として扱います。
See: Context Budget, Context Selection, Actor-local Compiled Context, Governance Surface

ある actor が、ある process frame のある局面で、何をアクティブコンテキストに含め、何を参照渡しに回し、何を除外し、何を保留 / 未解決のまま保持するかを決める選択操作です。
単なる retrieval や ranking ではなく、purpose binding(目的への結びつけ)、安全下限の維持、governance-aware inclusion / exclusion(統治条件を踏まえた採否)、鮮度によるふるい分け、反証根拠の保持を含む governed selection として扱います。
See: Context Selection, Context Budget, Compaction

source context や trace を、target actor / phase / purpose に対して safety floor を落とさずに縮約し、不要な冗長性を減らし、必要なものを参照渡し化して制約付きの local view に再構成する操作です。
単なる要約ではなく、governance-preserving omission(統治条件を壊さない省略)、根拠 trace の保持、鮮度宣言、再展開経路の提供を含む context transformation として扱います。
See: Compaction, Context Selection, Context Budget, Actor-local Compiled Context

raw な情報プールをそのまま見せるのではなく、選択・整形・圧縮・制限・注釈付けを経て、ある actor 用の局所 view にすることです。
PCE 2.0 では context は discover されるものではなく、compile されるものとして扱います。
See: Actor-local Compiled Context, Context Selection, Compaction

project を session や actor をまたいで継続させるための永続層です。
canonical artifacts、decision memory、failure memory、operational memory、evaluation memory、governance records、recovery points を型付きで保持します。
本文では durable state と略記することがあります。
See: Durable Project State

後続 process が前提として依拠してよい とみなされた状態や item を指します。
canonical(正規採用済み状態)への昇格には、通常 eval と required authority が必要です。
See: Durable Project State, No merge without eval

durable に保存はされているが、まだ canonical として採用されていない状態や item を指します。
provisional(暫定保持状態)には、checkpoint、pending promotion candidates、working notes などが入りえます。
See: Durable Project State

ある process frame が生成する型付き差分です。
artifact だけでなく、decision、failure、evaluation、governance、operational memory、recovery まで含みます。Process Delta は「作業の返り値として出る差分束」と考えるとよいです。
See: Process Delta

Process Delta の内部にある個々の差分単位です。
kindopscopetarget_zonerequired_evalrequired_authority などを持ちます。
See: Process Delta

ある item や delta が何の型かを示す属性です。
artifact、decision、failure_memory、evaluation、governance、operational_memory、recovery などがあります。
See: Process Delta

その差分が何をしようとしているかを示す属性です。
add、update、supersede、retract、archive、checkpoint などがあります。
See: Process Delta

ある subject や delta item を、merge、promotion、close、resume などの次の遷移へ進めてよいかどうかを指す概念です。
通常は outcome/process evaluation と required authority の両方に依存します。
See: Outcome vs Process, Eval Contract

PCE 2.0 で topology というと、単なる図の形ではなく、
どの actor / frame / branch / gate / recovery path が、どの条件で接続され、どこで切れ、どこが blocked か
を定める接続構造と遷移規則を指します。

文脈に応じて、次のどれを強調しているかが変わります。

  • process topology: parent-child、branch / join、handoff、rollback など continuation の構造
  • responsibility topology: goal / execution / approval / evaluation / incident ownership の配分構造
  • approval / evaluation / escalation topology: gate と authority-routing の構造

これらは別概念ですが、互いに独立ではありません。
たとえば branch-and-join の process topology が変われば、
join owner が見るべき approval / evaluation path や local context も変わりえます。

Actor-local Compiled Context では、topology 全体をそのまま保持するのではなく、
その topology 上で actor に必要な局所近傍だけを compile した local chart を扱います。
See: Actor-local Compiled Context, Transitions, Branch and Join, Approval, Evaluation

process における意味的な状態変化です。
runtime state、responsibility allocation、context validity、delta lifecycle、durable state などに影響します。
See: Transitions

ある時点の frame において、gate、authority、scope、runtime state を満たした上で、次に取ってよい遷移です。
approval や recovery の後には、legal next transitions が重要になります。
See: Transitions, Lifecycle, Checkpoint and Recovery

ある process frame が時間に沿ってどのような意味的状態を取り、何が pending で、どの next transition が legal かを定める状態モデルです。
単なる進捗ラベルではなく、progression、gate、resolution、recovery readiness を含む状態意味論として扱います。
See: Lifecycle, Transitions, Checkpoint and Recovery

親 frame が global goal や主要 authority を retain したまま、局所 goal slice または adjunct purpose を child frame に切り出し、bounded autonomy のもとで work を進めさせ、その結果を delta・evidence・unresolved issues として回収する階層的 process 構造です。
単なる task breakdown ではなく、retained authority、delegated responsibility、return contract、lifecycle coupling を持つ relation として扱います。
See: Parent-Child Process, Lifecycle, Handoff

親 frame の continuity を複数の bounded child path に分岐し、それぞれの return を join contract に従って再統合・比較・選別・縮約する multi-path process topology です。
単なる parallel execution ではなく、branch set、required branches、join kind、conflict resolution、failure propagation を含む governed reintegration 構造として扱います。
See: Branch and Join, Topology, Actor-local Compiled Context, Parent-Child Process, Lifecycle

現在の actor / bundle / frame の authority や governance の範囲では合法・安全・妥当な continuation を確定できないときに、その subject と decision burden をより適切な authority を持つ actor または frame へ引き上げる transition です。
単なる相談や handoff ではなく、authority overflow、goal ambiguity、policy conflict、join conflict、recovery illegality を governed に処理する authority-routing transition として扱います。
See: Escalation, Lifecycle, Handoff

ある actor または frame から別の actor または frame へ、continuity を継続可能な形で移す遷移です。
単なるメッセージ転送ではなく、goal slice、responsibility transfer、pending gates、delta state、expected next action まで含みます。
See: Handoff

handoff のために source から target へ渡される continuity package です。
goal slice、relevant evidence、pending gates、delta refs、unresolved issues、expected output などを含みます。
See: Handoff

human oversight や retained authority の行使に必要な、bounded な decision package です。
subject、requested decision、allowed options、required evidence、risk delta、counterevidence、rollback path、staleness conditions、write scope、provenance を含み、人間に raw labor を押し付けないための介入用 package として扱います。
See: Human Oversight, Human-AI Handoff

進行・採用・昇格・再開のいずれかを継続するために、明示的な authority による ratification を要求する構造上の地点です。
approvereject そのものではなく、それらが適用される gate 構造です。
See: Approval Points

process を止めたり解放したりする構造的条件です。
approval gate、evaluation gate、promotion gate、policy gate などがあり、governance surface の局所要素として現れます。
See: Approval Points, Governance Surface

ある時点の process continuity を Recovery Point として切り出して保存する transition です。
単なる autosave ではなく、後で安全に再開するための意味的な切断です。
See: Checkpoint and Recovery

Recovery Point を使って runtime continuity を再構成する transition family です。
過去の snapshot を盲目的に戻すのではなく、現在の durable reality と照合しながら再構成します。
See: Checkpoint and Recovery

recover 済み状態から、再び active な legal transition を開始する遷移です。
recover と resume は別であり、recover しただけでは直ちに resume できないことがあります。
See: Checkpoint and Recovery

不適切な進行や不整合を、以前の許容状態へ戻す遷移です。
runtime rollback と durable rollback は区別して考えるべきです。
See: Rollback, Transitions, Checkpoint and Recovery

現在の continuity をそのまま再開するのではなく、goal、scope、bundles、next transitions を再設計することです。
recover の結果として replan に進むこともあります。
See: Transitions, Checkpoint and Recovery

責任・権限・可視性・評価・昇格・監査・回復条件が、実行可能かつ拘束力のある形で process に露出する面です。
visibility surface、capability surface、approval surface、evaluation surface、promotion surface などを含みます。
See: Governance Surface, Capability Scope

誰が何を見てよいかを定める governance surface の一部です。
見えることとできることは別であり、visibility は capability と混同してはなりません。
See: Governance Surface

誰が何をしてよいかを定める governance surface の一部です。
tool allowlist、write scope、network scope、data access scope などを含みます。
See: Governance Surface, Capability Scope

ある actor が、ある frame のある局面で、どの resource に対して、どの種類の action を、どの効果範囲まで、どの条件のもとで実行してよいかを定める境界です。
単なる tool allowlist ではなく、operation scope、resource scope、effect scope、temporal validity、quantitative limits、delegation bounds、preconditions、postconditions を含む bounded action envelope として扱います。
See: Capability Scope, Governance Surface, Responsibility Bundle

誰が何を、どの authority と evidence に基づいて行い、何が current truth として採用され、何が無効化・保留・省略されたかを、後から再構成できる性質です。
単なる log retention ではなく、attribution、authority trace、evidence trace、state mutation trace、omission trace、invalidation / supersession trace、continuity trace を含む governance property として扱います。
See: Auditability, Governance Surface, Durable Project State

人間 actor または human-backed organizational actor が、process の framing、gate、exception、recovery、memory mutation、closure に対して明示的な介入権と停止権を持ち、AI / tool-driven process が governance と accountability を失わないようにする統治構造です。
単なる HITL ではなく、oversight scope、intervention rights、trigger conditions、required evidence package、override / freeze / escalate / resume authority、audit trace を持つ bounded governance pattern として扱います。
See: Human Oversight, Auditability, Capability Scope

人間が review に入っているように見えても、実際には AI 提案の追認しかしておらず、独立した decision quality をほとんど加えていない anti-pattern です。
See: Human Oversight, Approval

承認者は存在するが、bounded subject、required evidence、stale invalidation、rollback path が弱く、approval が単なる待ち行列に崩れている anti-pattern です。
See: Human Oversight, Approval

memory writer が canonical write の ratifier ではなく、全候補の分類・整形・重複排除・鮮度管理を一手に抱え込んでいる anti-pattern です。
See: Human Oversight, Memory Writing

incident owner が containment / closure authority ではなく、生ログの再構成係に沈んでいる anti-pattern です。
See: Human Oversight, Incident Ownership

ある subject に対して ratify できる権限です。
approver identity と approval authority は同じではなく、bundle 上の根拠が必要です。
See: Responsibility Bundle, Approval Points

何を、どの criteria で、どの重みで評価できるかに関わる責任です。
approval authority とは別物です。
See: Responsibility Bundle, Eval Contract

何を durable state に昇格・更新してよいかに関わる権限です。
提案者、evaluator、memory writer は一致しないことがあります。
See: Responsibility Bundle, Memory Promotion Rules

その evaluator の fail が、少なくとも当該 subject の promotion や merge を阻止する evaluator です。
required regression tests や mandatory review などが典型です。
See: Eval Contract, Process Metrics

判断に有用な signal は与えるが、それ単独では promotion や merge を止めない evaluator です。
style suggestion や non-critical maintainability note などが典型です。
See: Eval Contract, Process Metrics

何を、誰が、どの基準で、どの証拠に基づいて評価し、どの verdict で次の遷移へつなぐかを定める評価契約です。
criteria そのものと、評価者や決定規則をまとめて持ちます。
See: Eval Contract

subject が、結果として何を達成したかを問う評価です。
correctness、completeness、requirement fit、performance などを見ます。
See: Outcome vs Process

subject が、どの process、責任構造、統治条件、根拠、継続条件のもとで成立したかを問う評価です。
procedural validity、governance validity、evidence sufficiency、continuity integrity、promotion discipline などを見ます。
See: Outcome vs Process

handoff、gate、approval、recovery、promotion、governance のどこで process が健全で、どこで壊れているかを継続的に観測するための指標群です。
outcome 指標の代用品ではなく、process を見えるものにする観測層です。
See: Process Metrics

承認 1 件あたりに必要な active review cost です。
approval queue の速さではなく、1 subject を ratify するのにどれだけ review labor を要したかを見る governance / approval metric です。
See: Process Metrics, Approval

人間に渡る oversight package や介入件数が、bounded autonomy を壊すほど重くなっていないかを見る oversight-oriented 指標です。
承認量そのものではなく、人間が実際に吸っている attention / review labor の重さを捉える補助 metric として使います。
See: Human Oversight, Human-AI Handoff, Process Metrics

human verdict が AI 推薦や前段の推薦をほぼ追認しており、counterevidence や独立した disagreement capture が乏しい割合です。
burden の低さだけではなく、oversight quality と組で読むべき governance / oversight metric candidate として扱います。
See: Human Oversight, Process Metrics

Human Decision Package が、その human actor の attention / time ceiling を超えていた割合です。
高い場合は manual review の努力不足ではなく、frame 粒度、package 設計、authority split の失敗を疑います。
See: Human Oversight, Context Budget, Process Metrics

outcome は pass しているように見えるが、process が壊れている成功です。
PCE 2.0 では、こうした subject をそのまま canonical 化しません。
See: Corrupt Success, Outcome vs Process, Process Metrics

upstream task 自体は失敗していても、failure lesson、rejection rationale、checklist candidate など durable learning を残しうる失敗です。
artifact outcome と process learning を分けて扱うときに重要な概念です。
See: Outcome vs Process

評価を通過していない差分は durable state に昇格させない、という PCE 2.0 の中核原理です。
merge は保存ではなく、future process の前提を書き換える制度的な昇格として扱われます。
See: No merge without eval

durable memory へ昇格しうる知識候補です。
source delta item そのものの場合もあれば、delta や trace から抽出・再表現された derived candidate の場合もあります。
See: Memory Promotion Rules, Memory Promotion Criteria

ある candidate を durable project state の適切な zone / collection へ昇格させることです。
単なる保存ではなく、future reuse に耐える durable form への選別された再表現です。
See: Memory Promotion Rules

どの candidate を、どの条件で、どの collection へ、どの status で昇格させてよいかを定める規則です。
保存方針ではなく、project memory を汚さないための昇格制度です。
See: Memory Promotion Rules

ある memory candidate を durable memory として採用してよいかを判断する評価基準です。
reuse value、bounded scope、provenance、decontextualizability、governance compatibility などを問います。
See: Memory Promotion Criteria

accepted rationale、chosen trade-off、approved interpretation など、将来の process が意思決定の前提として参照すべき memory です。
See: Durable Project State, Memory Promotion Criteria

rejected alternative、failure pattern、do-not-repeat note、anti-pattern など、同じ失敗の再発を防ぐための durable memory です。
See: Durable Project State, Memory Promotion Criteria

checklists、playbooks、workflow patterns、skills など、future process の進め方に効く実務知です。
artifact そのものではなく、どう進めるとうまくいくかを保持します。
See: Durable Project State, Memory Promotion Rules

baselines、thresholds、rubrics、review outcomes など、将来の評価条件や比較軸として再利用される memory です。
See: Durable Project State, Eval Contract

approval rule、scope restriction、escalation rule、audit-relevant annotation など、project の統治条件として durable に残る記録です。
See: Durable Project State, Governance Surface

memory 候補が、元の会話や trace を読まなくても意味が通る durable form になることです。
future process は毎回元の長い履歴に戻れないため、memory promotion で重要な基準になります。
See: Memory Promotion Criteria

新しい durable item が、古い item を置き換える関係です。
置き換えた事実そのものも traceable に残すべきであり、無言の上書きにしてはなりません。
See: Durable Project State, Memory Promotion Rules

中断された process を安全かつ意味的に再開するために保存される再開点です。
runtime snapshot、responsibility snapshot、pending gates、delta state、recompile requirement などを持ちます。
See: Recovery Point

比較的短い中断や同一 actor による再開を前提とした recovery です。
reusable context が多い一方で、stale context をそのまま使いすぎる危険があります。
See: Recovery Point, Checkpoint and Recovery

時間や actor をまたいだ再開を前提とした recovery です。
refs と summaries を重視し、recompile と reconciliation を前提に設計されます。
See: Recovery Point, Checkpoint and Recovery

Actor は process に参与する存在です。
Responsibility Bundle は、その actor がその局面で引き受けている局所責任状態です。
See: Actor, Responsibility Bundle

Process Frame は仕事単位の構造です。
Transition は、その frame の中で何が変化したかを表す動的概念です。
See: Process Frame, Transitions

Actor-local Compiled Context ≠ Durable Project State

Section titled “Actor-local Compiled Context ≠ Durable Project State”

Actor-local Compiled Context は局所的で一時的な working view です。
Durable Project State は project を継続させる永続層です。
See: Actor-local Compiled Context, Durable Project State

Process Delta は state-change candidate です。
Durable State は、評価と authority を通ったあとに実際に project が採用している状態です。
See: Process Delta, Durable Project State

Approval Point は承認が必要な構造上の地点です。
Approve / Reject は、その point を実際に解く transition です。
See: Approval Points, Transitions

Eval は criteria と evidence に基づく適合性判断です。
Approval は authority による ratification です。
See: Eval Contract, Approval Points

Checkpoint ≠ Recovery Point ≠ Recover ≠ Resume

Section titled “Checkpoint ≠ Recovery Point ≠ Recover ≠ Resume”

Checkpoint は保存する transition、Recovery Point は保存結果、Recover は再構成、Resume は再進行です。
この四つを分けることで、継続性は convenience ではなく governed continuation になります。
See: Recovery Point, Checkpoint and Recovery

Delegation は responsibility の再配分です。
Handoff は active work continuity の受け渡しです。
両者はしばしば一緒に起こりますが、同一ではありません。
See: Handoff, Responsibility Bundle

artifact や subject を merge することと、knowledge を durable memory として promotion することは別です。
artifact correctness と memory worthiness は一致しません。
See: No merge without eval, Memory Promotion Rules

Outcome は「何ができたか」を問います。
Process は「それがどのような責任構造・統治条件・根拠のもとで成立したか」を問います。
PCE 2.0 では、どちらか一方だけでは十分な admissibility 判定になりません。
See: Outcome vs Process


この glossary を起点に読むなら、次の導線が自然です。