Actor-local Compiled Context

定義

Actor-local Compiled Context

Actor-local Compiled Context とは、ある actor が、ある process frame のある時点において、
自らに割り当てられた responsibility bundle を遂行するために compile される局所視界 である。

それは単なる関連情報の寄せ集めではなく、
goal slice、relevant state、evidence、Capability Scope、constraints、expected output、stop conditions、handoff / escalation contract を、
当該 actor にとって操作可能な形へ編集・圧縮・整形・制限したものである。

より短く言えば、Actor-local Compiled Context とは
「この actor は、この局面で、何を知り、何をしてよく、何をしてはならず、何を返し、どこで止まるべきか」
を局所的に表現した実行用 view である。

PCE 2.0 において context は主語ではありません。
主語は Process Frame と Responsibility Bundle です。
Actor-local Compiled Context は、それらから導出される従属物です。

この意味で Actor-local Compiled Context は、
Process-first と Responsibility-first を ontology として具体化した概念です。

なぜ「Actor-local」なのか

PCE 1.0 の Active Context は有効な発想でしたが、PCE 2.0 では単数形の active context では足りません。
なぜなら、同じ process の中でも actor ごとに必要な view が違うからです。

たとえば、同じ frame の内部でも次は一致しません。

coding agent が実装に必要とする情報
reviewer が承認のために必要とする情報
evaluator が検証のために必要とする情報
memory writer が昇格判断のために必要とする情報
runtime が再開のために必要とする情報

これらを一つの共通 context へ押し込むと、次の問題が起きます。

1. 過剰な可視性

ある actor に不要な情報まで見せてしまいます。
これはノイズを増やすだけでなく、governance 上も弱い設計です。

2. 過剰な行為可能性

「見えること」と「行えること」が混ざり、
不要な capability や implicit authority が付与されやすくなります。

3. 局面ごとの差が消える

同じ actor でも、実行中と承認待ちと失敗後の再計画では必要な view が違います。
単一の context はその時間差を潰してしまいます。

だから PCE 2.0 では、context は単一の active な塊ではなく、
actor ごと・時点ごとに compile される局所視界 として扱われます。

なぜ「Compiled」なのか

PCE 2.0 で context を compiled と呼ぶのは、context が raw な情報プールではないからです。
それは、元の状態から 選択・整形・圧縮・制限・注釈付け された結果です。

compile は少なくとも次の操作を含みます。

1. Select

Context Selection によって必要な情報だけを選ぶ。
すべてを渡すのではなく、その actor の責任に必要なものだけを残します。

2. Scope

何を見せ、何を見せないかを決める。
visibility と capability は bundle に従って制限されます。

3. Transform

元の artifacts や logs を、その actor が扱いやすい形に変換する。
たとえば要約、diff 化、表形式化、参照リンク化などです。

4. Compress

長すぎる履歴や周辺情報を、責任遂行に必要な密度へ圧縮する。
PCE 2.0 における context は、長さではなく operability が重要です。

5. Redact

見せるべきでない情報、不要な情報、スコープ外の情報を伏せる。
これは安全性のためだけでなく、責任境界を守るためでもあります。

6. Annotate

何を返すべきか、どこで止まるべきか、何を評価すべきかを明示する。
compiled context は情報だけではなく、行為条件も含みます。

7. Package

その actor に合った表現形式に整える。
LLM なら tokenized prompt、human reviewer なら diff view + checklist、tool なら structured input、runtime なら checkpoint package になるかもしれません。

したがって compiled context は、
情報の切り出し ではなく、責任遂行のための局所 view の生成 です。

なぜ「Context」なのか

ここでいう context は、単なる background knowledge ではありません。
PCE 2.0 における context は、もっと強い意味を持ちます。

それは少なくとも次を含みます。

何が今重要か
何が既知で何が未解決か
何をしてよいか
何をしてはいけないか
何を返すべきか
どこで止まるべきか
誰に handoff すべきか

つまり Actor-local Compiled Context は、
単なる情報文脈ではなく、行為可能な責任文脈 です。

この点で、PCE 2.0 の context は単なる prompt より広く、
単なる memory より局所的です。

Actor-local Compiled Context は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておきます。

1. 単なる prompt ではない

LLM actor に対しては prompt として具体化されることがあります。
しかし、human actor には review 画面、tool actor には structured invocation、runtime actor には state package として現れることがあります。

したがって Actor-local Compiled Context は、prompt の上位概念です。

2. 単なる会話履歴ではない

チャット履歴をそのまま渡すだけでは compile されていません。
履歴は素材の一つであって、そのまま context とは限りません。

3. 単なる検索結果ではない

関連文書を検索しただけでは、まだ compiled ではありません。
その actor の責任にとってどう意味づけるかが必要です。

4. 単なる app-local state ではない

アプリケーション内部の state は素材の一つですが、
そのすべてが actor に見えるとは限りません。
compiled context は、state を actor 用に局所化した view です。

5. durable state そのものではない

Durable Project State は canonical な永続層です。
Actor-local Compiled Context は、その一部を局所化して一時的に可視化した working view です。

6. bundle そのものではない

Responsibility Bundle は責任状態です。
Actor-local Compiled Context は、その bundle を遂行するために必要な局所視界です。
責任と視界は同じではありませんが、強く対応します。

何から compile されるのか

Actor-local Compiled Context は、少なくとも次の4要素から compile されます。

1. Process Frame

frame は、goal、scope、constraints、approval points、eval contract、memory policy などを与えます。

2. Responsibility Bundle

bundle は、その actor が今何を担っているか、何をできるか、どこで止まるべきかを与えます。

3. Durable Project State

永続層は、canonical artifacts、decision memory、evaluation history、operational memory などを与えます。

4. Runtime State

現在の進行状況、未解決事項、直近の results、pending approval、checkpoint 情報などを与えます。

概念的には、次のように書けます。

actor_local_compiled_context(actor, process_frame, t) =
  compile(
    process_frame,
    responsibility_bundle(actor, process_frame, t),
    durable_project_state,
    runtime_state(t)
  )

この式で重要なのは、context が元からあるのではなく、毎回 compile される ことです。

Actor-local Compiled Context の構造

PCE 2.0 における Actor-local Compiled Context は、少なくとも次の層を持ちます。

1. Goal Layer

この actor が今向き合うべき goal の局所断面です。
process 全体の goal ではなく、その actor に必要な goal slice を含みます。

2. State Layer

その actor が知るべき現在状態です。
relevant facts、artifacts、decision rationale、unresolved issues、recent deltas などが入ります。

3. Capability Layer

何を使ってよいか、何が禁止されているかを示します。
allowed tools、data visibility、write scope、network scope などが入ります。

4. Constraint Layer

品質要求、ポリシー、期限、予算、禁止事項など、行為を縛る条件が入ります。

5. Output Layer

その actor が返すべき成果物や期待出力形式を示します。
summary、diff、decision proposal、approval verdict などが入りえます。

6. Control Layer

stop conditions、handoff target、escalation path、approval dependency などを含みます。
ここがあることで context は単なる情報ではなく、局所的な process interface になります。

情報だけでなく、義務も含む

Actor-local Compiled Context は「何が見えるか」だけを定義するものではありません。
それは同時に、「何が期待されているか」も定義します。

たとえば compiled context は、次を含みえます。

必須の evidence
required checks
expected output schema
must-escalate conditions
do-not-cross boundaries
handoff format

この点が重要です。
PCE 2.0 における context は passive な knowledge bag ではなく、
責任に紐づいた局所的な action contract です。

同じ frame から複数の local context が生まれる

ある一つの Process Frame から、複数の Actor-local Compiled Context が同時に生まれます。
これは PCE 2.0 の基本的な前提です。

例

同じ feature delivery frame でも、

analyst agent には、仕様・既存実装・論点だけをまとめた read-only context
coding agent には、変更対象・禁止領域・必要テストを含む implementation context
reviewer には、diff・リスク・rollback 可否・論拠を含む review context
evaluator には、eval contract・test targets・evidence criteria を含む evaluation context
memory writer には、昇格候補と provenance を含む promotion context

がそれぞれ compile されます。

このように、local context の多重性は例外ではなく通常形です。

modality は actor ごとに違う

Actor-local Compiled Context は、同じ ontology でも actor に応じて表現形式が変わります。
これを modality と呼んでよいでしょう。

LLM actor の場合

system / developer / user instructions
relevant excerpts
tool schema visibility
expected output format

Human actor の場合

diff view
review checklist
risk summary
unresolved issues list

Tool actor の場合

typed input
allowed parameter scope
execution policy
expected return schema

Runtime actor の場合

checkpoint package
pending approvals
state snapshot
recovery metadata

したがって Actor-local Compiled Context は、
同一内容の別表現 ではありません。
同一 frame から導出される、actor 適合的な異なる局所 view です。

visibility と capability は分けて扱う

Actor-local Compiled Context は、しばしば visibility と capability を同時に扱います。
しかしこの二つは区別されるべきです。

Visibility

何を見てよいか。
facts、artifacts、logs、decision memory、policy のどこまでが visible か。

Capability

何をしてよいか。
tool use、write operation、approval、evaluation、memory promotion のどこまでが allowed か。
この operational 境界は Capability Scope として扱える。

ある情報が見えるからといって、それを編集できるとは限りません。
ある capability があるからといって、goal ownership や incident ownership があるとも限りません。

Actor-local Compiled Context は、この違いを明示したまま actor に渡されるべきです。

コンテキストは更新・失効・再コンパイルされる

Actor-local Compiled Context は static ではありません。
process が進むと、context は古くなります。

再コンパイルが必要になる典型条件

runtime state が更新された
approval が通過または拒否された
bundle が変更された
scope violation や policy violation が検出された
新しい evidence や failure knowledge が追加された
checkpoint から再開された

このため Actor-local Compiled Context には暗黙の鮮度があります。
それは durable state のような永続物ではなく、
一定の state と responsibility にだけ有効な局所 view です。

by-value と by-reference

compiled context は、必ずしもすべての中身を埋め込む必要はありません。
とくに長時間・大規模な process では、by-value と by-reference を使い分ける必要があります。

by-value

要点、要約、必要な抜粋、直近の delta などを直接埋め込む。

by-reference

大きな artifacts、完全なログ、過去の decisions、詳細な evidence を参照リンクや handle として持つ。

この区別により、Actor-local Compiled Context は
小さく保ちながら、必要な深さへ到達できる ようになります。

PCE 2.0 において重要なのは、情報量の多さではなく、
局所責任に対する十分性です。

最小スキーマ

PCE 2.0 における Actor-local Compiled Context の最小スキーマは、次のように置けます。

actor_local_compiled_context:
  actor:
  frame_id:
  derived_from:
    process_frame:
    responsibility_bundle:
    durable_state_refs:
    runtime_state_ref:
  modality:
  goal_slice:
  relevant_state:
    facts:
    artifacts:
    evidence:
    unresolved_issues:
    recent_deltas:
  capability_scope:
    allowed_tools:
    allowed_actions:
    data_visibility:
    prohibitions:
  constraints:
  expected_output:
  stop_conditions:
  handoff_contract:
    next_target:
    required_format:
  escalation_path:
  provenance:
  freshness:

このスキーマで重要なのは、次の点です。

raw history がそのまま入っていない
responsibility bundle が導出元として明示されている
modality が含まれている
stop / handoff / escalation が context の内部にある

つまり Actor-local Compiled Context は、
単なる knowledge slice ではなく 局所的 process interface です。

小さな例

「checkout にクーポン併用制約を追加する」frame の中で、同じ frame から二つの local context を compile するとします。

coding_agent 用

actor_local_compiled_context:
  actor: coding_agent
  frame_id: feature.checkout.coupon-combination
  modality: llm_prompt
  goal_slice: >
    承認済み仕様に従って、
    coupon combination logic を実装し、
    関連テストを更新する
  relevant_state:
    facts:
      - spec_approved
      - payment_gateway_changes_are_out_of_scope
    artifacts:
      - src/checkout/coupon_validation.ts
      - tests/checkout/coupon_validation.test.ts
    evidence:
      - approved_spec_summary
      - existing_validation_flow_summary
    unresolved_issues:
      - edge_case_for_stackable_discount_threshold
    recent_deltas:
      - analysis_delta_v3
  capability_scope:
    allowed_tools:
      - repository_search
      - code_edit
      - test_runner
    allowed_actions:
      - edit_target_files
      - run_local_tests
    data_visibility:
      - checkout_specs
      - existing_tests
      - adr_history_excerpt
    prohibitions:
      - payment_gateway_edit
      - production_access
  constraints:
    - preserve_backward_compatibility
    - do_not_change_settlement_flow
  expected_output:
    - code_diff
    - updated_tests
    - implementation_note
  stop_conditions:
    - failing_regression_tests
    - scope_violation_detected
    - unresolved_spec_conflict
  handoff_contract:
    next_target: reviewer
    required_format:
      - diff_summary
      - changed_files
      - test_results
  escalation_path: product_owner
  provenance:
    process_frame: feature.checkout.coupon-combination
    bundle: coding_agent_impl_bundle_v2
  freshness:
    valid_until: next_state_change

reviewer 用

actor_local_compiled_context:
  actor: reviewer
  frame_id: feature.checkout.coupon-combination
  modality: review_ui
  goal_slice: >
    code change が承認済み仕様と制約に適合しているかを判断し、
    merge readiness を承認または差し戻す
  relevant_state:
    facts:
      - spec_approved
      - code_diff_ready
    artifacts:
      - code_diff
      - test_reports
    evidence:
      - approved_spec_summary
      - decision_rationale
      - rollback_note
    unresolved_issues:
      - none
    recent_deltas:
      - implementation_delta_v1
  capability_scope:
    allowed_tools:
      - diff_view
      - test_report_view
      - review_comment
    allowed_actions:
      - approve
      - request_changes
    data_visibility:
      - code_diff
      - test_results
      - decision_rationale
    prohibitions:
      - direct_code_edit
      - change_scope_expansion
  constraints:
    - review_against_spec_only
    - verify_scope_compliance
  expected_output:
    - approval_decision
    - review_comments_if_any
  stop_conditions:
    - missing_required_checks
    - policy_violation_detected
  handoff_contract:
    next_target: memory_writer
    required_format:
      - approval_status
      - accepted_rationale
      - follow_up_notes
  escalation_path: product_owner
  provenance:
    process_frame: feature.checkout.coupon-combination
    bundle: reviewer_bundle_v1
  freshness:
    valid_until: next_diff_change

この例で分かるのは、同じ frame を見ていても、
局所 goal、visible state、allowed action、expected output が大きく違うということです。

Actor-local Compiled Context の不変条件

PCE 2.0 では、少なくとも次の不変条件を置きます。

1. Every local context must be justified by a frame and a bundle

どの local context にも、対応する process frame と responsibility bundle が必要です。

2. No omniscient default context

「とりあえず全部見せる」は default として許されません。
visibility は bundle に基づいて限定されるべきです。

3. No capability without contextual justification

allowed tool や action は、その actor の責任に結びついていなければなりません。

4. No local context without stop logic

execution、approval、evaluation のいずれかを担う actor の context には、少なくとも停止条件または escalation 条件が必要です。

5. No stale context reuse

重要な state change 後に旧 context をそのまま使い続けてはなりません。
必要なら recompile が必要です。

6. No canonical promotion from raw local context

local context 自体は canonical state ではありません。
そこから生じた Process Delta が eval を通過して初めて durable state に昇格できます。

いつ新しい local context を切るべきか

context を再コンパイルすべき典型条件は次です。

1. Responsibility Bundle が変わったとき

read-only analysis から write-enabled implementation へ移る場合などです。

2. Approval 状態が変わったとき

approved / rejected / pending の違いは局所視界を変えます。

3. Capability Scope が変わったとき

使える tool や write boundary が変わるなら、同じ context は使えません。

4. Eval Contract が変わったとき

何をもって pass とするかが変わるなら、expected output や evidence も変わります。

5. Runtime State が大きく変わったとき

checkpoint からの再開、重大な failure、scope change などです。

短く言えば、
責任、権限、評価、進行状態のいずれかが変わったら、context は再コンパイルされるべき
です。

最低限の自己点検

ある設計が Actor-local Compiled Context を十分に持っているかは、次で点検できます。

その context が、どの frame とどの bundle から導出されたか言えるか
goal slice が process 全体の goal と区別されているか
visible state と allowed action が分けて書けるか
constraints と prohibitions が明示されているか
expected output と handoff format が定義されているか
stop conditions または escalation path があるか
raw history ではなく compile 済みの view になっているか
stale になったとき再コンパイルすべき条件が分かるか
modality が actor に適合しているか
この context を見れば、その actor が今何をすべきか説明できるか

このどれかが欠けるなら、その context はまだ局所責任に対して粗いままです。

暫定的なまとめ

Actor-local Compiled Context が言っていることは、最終的には次の一文に集約できます。

context は、何かが単に関連しているから成立するのではない。
ある actor が、ある frame の、ある局面で、自らの責任を遂行するために必要な view と contract が compile されてはじめて成立する。

PCE 2.0 において context は受動的な背景ではありません。
それは、責任に応じて局所化され、行為可能性と停止条件まで含めて構成される working interface です。

だから Actor-local Compiled Context は、単なる「見せる情報」ではありません。
それは、PCE 2.0 において actor を 操作可能かつ統治可能にする局所的実行面 です。