Context Budget

定義

Context Budget

Context Budget とは、ある actor が、ある process frame のある局面において、
自らの responsibility bundle を 安全かつ十分に遂行するために active に保持できる context の上限と下限 を定める予算である。

それは単なる token limit ではなく、
size ceiling、salience capacity、required evidence floor、visibility / capability limits、freshness bounds、continuity burden、latency constraints を含む。

より短く言えば、Context Budget とは
「この actor は、この局面で、何を最低限見ていなければならず、どこまでを active に持てて、それを超えたらどう分解・圧縮・延期・引き上げるべきか」を定める予算
である。

PCE 2.0 において context は、単に「たくさん入るほどよいもの」ではない。
Actor-local Compiled Context は、必要十分で、かつ governance に適合した局所視界でなければならない。
Context Budget は、その「必要十分」を process 上で定義する概念である。

この意味で Context Budget は、
Actor-local Compiled Context を operational に設計するための中核概念である。

なぜ Context Budget が必要なのか

PCE 2.0 が Context Budget を独立に扱うのは、
大きな context window や豊富な retrieval があっても、それだけで process が良くなるわけではないからである。

少なくとも、次の問題がある。

1. context は大きければよいわけではない

過剰な context は、

relevance の低い情報を混ぜる
stale な前提を残す
current responsibility に不要な情報を見せる
required evidence と optional noise を同列に並べる
actor に不適切な authority 感覚を与える

といった問題を起こしやすい。

2. 逆に小さすぎても process を壊す

必要な情報を削りすぎると、

scope を忘れる
stop condition を落とす
required evidence が足りなくなる
pending gate を見失う
stale approval や stale eval を current と誤認する

といった under-budget failure が起きる。

3. actor ごとに必要な context の性質が違う

同じ frame でも、

coding agent
reviewer
evaluator
memory writer
incident owner

では必要な局所視界が違う。
したがって budget は actor-relative でなければならない。

4. modality ごとに予算の意味が違う

LLM actor には token budget がある。
human reviewer には attention budget がある。
tool actor には parameter / payload budget がある。
runtime には checkpoint / restore budget がある。

PCE 2.0 は、これらを単に同じ「長さ」の問題として扱わない。

5. budget overrun は process design のシグナルである

必要な minimum context が ceiling に収まらないとき、
それは単なる「要約不足」ではなく、

frame が大きすぎる
branch を切るべき
child frame に分けるべき
review を段階化すべき
escalation / reframe が必要

という設計上のシグナルである。

だから Context Budget は、
モデルの制限に受け身で合わせるための概念 ではなく、
process を bounded に保つための設計概念 として必要なのである。

Context Budget は何ではないか

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

1. 単なる model context window ではない

モデルに入る最大 token 数は hard ceiling の一部にはなりうる。
しかし Context Budget は、それだけではない。

何が最低限必要か
何を active にしてよいか
何を by-reference に回すか
何をそもそも見せてはいけないか

まで含む。

2. 単なるコスト上限ではない

安くしたいから短くする、という cost budget は一要素にすぎない。
Context Budget の中心は 安全かつ十分な active context である。

3. 単なる retrieval policy ではない

何を取ってくるかは Context Selection の問題である。
Context Budget は、その selection が どこまで active に入ってよいか を定める。

4. 単なる compaction policy ではない

圧縮は Compaction の操作である。
Context Budget は、圧縮してもよい範囲と、圧縮してはならない floor を定める。

5. 単なる permission policy ではない

visibility / capability の制約は budget に含まれるが、
Context Budget 全体は governance policy そのものではない。
それは policy を active context の境界として具体化したものである。

6. 単なる memory size ではない

Durable Project State がどれだけ大きいかと、
今この actor がどこまで active に持てるかは別問題である。

7. 単なる summary 長さではない

短い summary が良い context とは限らない。
必要な evidence floor を落とした summary は、budget 内でも unsafe である。

Context Budget の中心構造

PCE 2.0 では、Context Budget を少なくとも三層で捉えると扱いやすい。

1. Safety Floor

これを欠くと、その actor は今の責任を legal / adequate に遂行できない という最低限の active context である。

典型的には次を含む。

goal slice
in-scope / out-of-scope
allowed / prohibited actions
stop conditions
pending gates relevant to that actor
required evidence for current act
current expected output / return contract

2. Working Band

floor を満たしたうえで、
実務上あると精度・効率・説明可能性が上がる active context である。

典型的には次を含む。

recent deltas
supporting references
bounded unresolved issues
local history relevant to current phase
comparative alternatives
adjacent decisions

3. Overflow / Reference Band

active には載せないが、
必要時に retrieve / open / expand できる by-reference context である。

典型的には次を含む。

full specs
large logs
full traces
old discussions
related but low-salience documents
large codebase regions

この三層構造があることで、PCE 2.0 は
「全部入れる / 全部削る」
ではなく、

active に必要なもの
active であるとよいもの
ref で十分なもの

を分けて扱える。

Safety Floor と Hard Ceiling

Context Budget を process 設計に使ううえで、最も重要なのは
Safety Floor と Hard Ceiling の区別である。

Safety Floor

その actor が current responsibility を遂行するための最小十分条件。

Hard Ceiling

その actor / modality / phase において、
それ以上 active に持つと quality、latency、governance、attention の面で破綻しやすい上限。

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

safe_to_compile(actor, frame, t) iff
  safety_floor(actor, frame, t) <= hard_ceiling(actor, frame, t)

ここで極めて重要なのは、
floor が ceiling を超えるなら、要約で押し込むのではなく process を変えるべき
だという点である。

たとえば、

child frame に切る
branch を切る
review を段階化する
checkpoint して later pass に回す
authority を分ける
escalation する

などである。

PCE 2.0 において budget overflow は、
単なる compression problem ではなく framing problem になりうる。

Budget の主要軸

Context Budget は一つの数値ではなく、複数軸で考えるべきである。
PCE 2.0 では、少なくとも次の軸を区別するとよい。

1. Size Budget

どれだけの volume を active に持てるか。

例:

max tokens
max fields
max diff chunks
max files
max checklist items

最も分かりやすい budget だが、これだけでは足りない。

2. Salience Budget

同時に何個の論点・分岐・未解決事項を active に扱えるか。

例:

max active unresolved issues
max competing alternatives
max active branches under comparison

これは LLM だけでなく human reviewer にとっても重要である。

3. Evidence Budget

判定や行為に必要な evidence をどこまで active に含めるべきか。

例:

required test report refs
required rationale refs
required rollback note
required provenance refs

重要なのは、evidence budget は optional ではなく floor を持つことだ。

4. Authority / Visibility Budget

その actor に何を見せてよいか、何を active tool surface に出してよいか。

例:

visible collections
hidden collections
allowed tools
allowed action schemas

これは governance surface と強く結びつく。

5. Freshness Budget

どこまで古い state を current active context として使ってよいか。

例:

max state age
invalidated by approval change
invalidated by reframe
invalidated by governance drift

この軸が弱いと stale context execution が増える。

6. Continuity Budget

handoff / recovery / prior history をどこまで active に持つか。

例:

prior handoff depth
number of prior deltas in active view
recovery summary depth
branch comparison depth

長時間 process では特に重要である。

7. Latency Budget

compile / retrieve / rehydrate にどれだけ時間を使えるか。

例:

max retrieval rounds
max compile latency
max review package expansion steps

これは performance だけでなく、UX と process flow にも影響する。

予算超過と予算不足

Context Budget を考えるとき、失敗は over-budget と under-budget の両方から来る。

Over-budget failure

必要以上に多くの context を active に持ちすぎた状態。

典型症状:

irrelevant detail で注意が散る
stale state が紛れ込む
wrong branch comparison が起こる
review が鈍る
local actor が本来見えないものまで見てしまう
compile / render / think time が増える

Under-budget failure

必要な floor を満たさない状態。

典型症状:

scope を忘れる
required evidence なしに pass 扱いする
pending gate を見失う
rollback path を見ない
local output が handoff に耐えない
memory candidate の provenance が抜ける

重要なのは、PCE 2.0 において
under-budget は often governance failure でもある
という点である。
必要な evidence や stop condition を落とした context は、単に短いだけではない。
それは unsafe である。

Context Budget は actor-relative, phase-relative, risk-relative である

同じ frame でも budget は一つではない。

Actor-relative

coding agent と reviewer と memory writer では floor が違う。

Phase-relative

spec analysis、implementation、review、promotion、incident handling では必要な active context が違う。

Risk-relative

low-risk local edit と high-risk release-critical change では、
required evidence floor が違う。

Modality-relative

LLM prompt、human review UI、tool payload、runtime recovery package では budget の形が違う。

したがって budget は、常に

context_budget(actor, frame, phase, risk, modality, t)

のように理解した方がよい。

Context Budget は何から導出されるか

Context Budget は単独では決まらない。
少なくとも次から導出される。

1. Process Frame

goal
scope
constraints
stop conditions
approval points
recovery strategy

2. Responsibility Bundle

execution なのか
approval なのか
evaluation なのか
memory writing なのか
incident ownership なのか

によって floor が変わる。

3. Governance Surface

visible / hidden collections
allowed tools
gate-relevant evidence
promotion restrictions

が budget の外周を作る。

4. Eval Contract

required evidence と required criteria が budget floor を押し上げる。

5. Memory Promotion Rules

memory candidate を扱うときは、provenance / scope / decontextualization の floor が増える。

6. Runtime State

pending approval、pending evaluation、recovery 中、branch conflict 中などで、必要な context は変わる。

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

context_budget(actor, frame, t) =
  derive(
    process_frame,
    responsibility_bundle(actor, frame, t),
    governance_surface(frame, t),
    applicable_eval_contracts,
    applicable_memory_promotion_rules,
    runtime_state(t),
    actor_modality(actor)
  )

Floor は削ってはいけない

PCE 2.0 では、Context Budget の最も重要な原理の一つは次である。

No compilation below the safety floor.

つまり、

必要な evidence
必要な stop condition
required pending gate
required scope note
required authority boundary

を落として budget に収めてはならない。

もし floor を落とさないと ceiling に収まらないなら、
やるべきことは more aggressive summarization ではなく、むしろ次のどれかである。

child frame に切る
branch を切る
phase を split する
handoff を挟む
checkpoint して later review に回す
escalation する
actor を変える
governance / authority path を変える

これが PCE 2.0 における context-first ではなく process-first な budget の扱いである。

Overflow Policy

Context Budget には、予算超過時の処理方針が必要である。
PCE 2.0 では、少なくとも次の順で考えるとよい。

1. Drop optional, keep required

まず working band の optional 情報を ref 化・後退させる。
floor は落とさない。

2. Compact low-salience state

低 salience の history や related notes を compaction する。
ただし required evidence を圧縮しすぎてはならない。

3. Move by-reference

full documents, long logs, large traces を active から外し、必要時に open する。

4. Split the work

それでも収まらないなら、context を無理に詰めるのではなく、

child frame
branch
staged review
separate evaluation pass

などに分解する。

5. Escalate or reframe

minimum safe budget がそもそも actor / phase に対して過大なら、
frame 自体が悪い可能性がある。
その場合は reframe や escalation が必要である。

この順番が重要である。
PCE 2.0 では overflow のたびに「もっと上手に圧縮する」だけでは不十分である。

Context Budget と Actor-local Compiled Context の関係

Actor-local Compiled Context は、
Context Budget に従って compile される。

関係

budget が compile の envelope を与える
compile はその envelope の中で selection / transformation / compaction を行う

つまり、

budget = どこまで入れてよいか
compile = 何をどう入れるか

である。

同じ durable state からでも、

reviewer の budget
coding agent の budget
memory writer の budget
incident owner の budget

は違うので、compiled context も違う。

Context Budget と Governance Surface の関係

Context Budget は、単なる usability の問題ではなく governance の問題でもある。

例

visible collections が budget の一部である
allowed tools が context surface の一部である
required pending gate を落とすことは governance failure になりうる
prohibited action を見えなくするのではなく、禁止事項として明示する必要があることもある

したがって budget は
何を入れるか だけでなく
何を入れてはいけないか
も定める。

この意味で Context Budget は、Governance Surface の actor-local projection の一部である。

Context Budget と Eval Contract の関係

Eval Contract は、budget floor を強く左右する。

例

artifact review の context budget では、少なくとも次が floor になるかもしれない。

code diff
approved spec summary
required test report
rollback note
policy violation check result

もしこれが ceiling に収まらないなら、
「全部を短くしよう」ではなく、

review を分割する
phase を分ける
child review frame に切る

などを考えるべきである。

このため Context Budget は、
eval contract の operational counterpart とも言える。

Context Budget と Memory Promotion の関係

memory writing や memory evaluation では、budget の nature が変わる。

典型的に floor に入るもの

candidate itself
provenance refs
source delta ref
scope note
target collection semantics
required eval result
duplication context

ここで budget を削りすぎると、
memory candidate は useful-looking でも provenance-poor になり、
promotion-corrupt success が起きやすくなる。

つまり memory promotion は、
artifact generation よりも often 高い evidence floor を要求する。

Context Budget と Handoff の関係

良い handoff は、次の actor が自分の budget の中で work を始められるようにする。
bad handoff は、target に

過剰な raw trace
必要な evidence の欠落
goal slice の曖昧さ
pending gate の脱落

をもたらす。

したがって handoff package は、単に情報を詰めるのではなく、
target budget に fit するように package 化されるべき である。

逆に言えば、handoff が target budget に収まらないなら、

staged handoff
child frame 化
separate evidence bundle
later retrieval by-reference

などが必要になる。

Context Budget と Checkpoint / Recovery の関係

recovery 後の context budget は、通常の active phase と同じではないことが多い。

recovery 時の特徴

stale context を再利用してはいけない
gate continuity を再表示しなければならない
rollback anchors や recovery constraints が floor に入ることがある
by-reference で十分だったものを active に戻す必要がある場合がある

したがって warm recovery と cold recovery では、budget が違う。

Warm recovery

recent local context の再利用枠が大きい
latency budget は小さい
freshness check は still required

Cold recovery

refs と summaries の比重が上がる
active context は再構成される
governance / authority / drift check が floor に入る

この意味で Context Budget は、
recovery semantics と強く結びつく。

Context Budget と Branch-and-Join の関係

複数 branch を比較・統合するとき、budget 問題は特に深刻になる。

典型例

option A / B / C を一度に active に持つ
それぞれの evidence と risk note を比較する
unresolved conflict を抱えたまま join する

ここでは salience budget と uncertainty budget が重要である。
同時に active に比較できる branch 数や unresolved conflict 数には ceiling がある。

もし join の safety floor が ceiling を超えるなら、

pairwise join
staged reducer
integration child frame
comparative summary child

などに分解すべきである。

Context Budget の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置ける。

context_budget:
  actor_ref:
  frame_id:
  phase:
  modality:
  risk_tier:
  safety_floor:
    required_goal_slice: true
    required_scope_constraints: true
    required_stop_conditions: true
    required_allowed_actions: true
    required_pending_gates:
    required_evidence_refs:
    required_output_contract: true
  hard_ceiling:
    max_tokens:
    max_items:
    max_active_unresolved_issues:
    max_active_branches:
    max_retrieval_rounds:
    max_compile_latency_ms:
  working_band:
    preferred_recent_deltas:
    preferred_supporting_refs:
    preferred_related_decisions:
  governance_limits:
    visible_collections:
    hidden_collections:
    allowed_tools:
    prohibited_tools:
  freshness_limits:
    max_state_age:
    invalidated_by:
  continuity_limits:
    max_handoff_depth:
    max_recovery_history_depth:
  overflow_policy:
    on_soft_overflow:
      - compact_optional
      - move_to_reference
    on_hard_overflow:
      - split_child_frame
      - branch
      - checkpoint_and_resume
      - escalate
  provenance:

もう少し compile 指向に書くなら、次のようにも置ける。

compiled_context_budget:
  actor_ref:
  frame_ref:
  bundle_ref:
  compile_target:
    # llm_prompt | review_ui | tool_payload | runtime_package
  floor:
  ceiling:
  optional_slots:
  evidence_floor:
  visibility_ceiling:
  freshness_policy:
  unresolved_issue_budget:
  branch_comparison_budget:
  overflow_resolution:
  invalidation_triggers:

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

floor と ceiling を分けている
evidence と governance を budget の中に含めている
unresolved issue や branch comparison も budget に入る
overflow 時の process response を持つ
actor / phase / modality / risk に依存する

小さな例

feature.checkout.coupon-combination frame の reviewer budget は、たとえば次のように書ける。

context_budget:
  actor_ref: reviewer
  frame_id: feature.checkout.coupon-combination
  phase: review
  modality: review_ui
  risk_tier: medium
  safety_floor:
    required_goal_slice: true
    required_scope_constraints: true
    required_stop_conditions: true
    required_allowed_actions: true
    required_pending_gates:
      - code_review_approval
    required_evidence_refs:
      - code_diff
      - ci_report
      - approved_spec_summary
      - rollback_note
    required_output_contract: true
  hard_ceiling:
    max_tokens: null
    max_items: 12
    max_active_unresolved_issues: 2
    max_active_branches: 1
    max_retrieval_rounds: 3
    max_compile_latency_ms: 1500
  working_band:
    preferred_recent_deltas:
      - implementation_note
      - failure_note_if_any
    preferred_supporting_refs:
      - precedence_adr_excerpt
    preferred_related_decisions:
      - no_payment_gateway_change
  governance_limits:
    visible_collections:
      - current_diff
      - relevant_decisions
      - review_checklist
    hidden_collections:
      - unrelated_operational_memory
      - production_credentials
    allowed_tools:
      - diff_view
      - test_report_view
      - review_comment
    prohibited_tools:
      - direct_code_edit
  freshness_limits:
    max_state_age: current_review_cycle_only
    invalidated_by:
      - code_diff_changes
      - approved_spec_changes
  continuity_limits:
    max_handoff_depth: 1
    max_recovery_history_depth: 1
  overflow_policy:
    on_soft_overflow:
      - move_large_logs_to_reference
      - compact_optional_notes
    on_hard_overflow:
      - split_review_into_staged_review
      - escalate_for_scope_reframe
  provenance:
    derived_from:
      - eval.feature.checkout.coupon-combination.artifact.v1
      - reviewer_bundle_v1

この budget の下では、reviewer に full implementation trace 全部を見せる必要はない。
しかし

diff
ci report
approved spec
rollback note

は floor なので落としてはならない。
もし diff が大きすぎて safety floor が ceiling を超えるなら、
レビュー対象を staged review に分けるか child frame 化すべきである。

Context Budget の不変条件

PCE 2.0 では、少なくとも次の不変条件を置ける。

1. No compilation below safety floor

required goal / scope / evidence / gate / stop condition を落として compile してはならない。

2. If floor exceeds ceiling, process must change

要約で押し込むのではなく、split / branch / checkpoint / escalate / reframe が必要である。

3. Budget is actor-specific

同じ frame でも actor ごとに budget は違う。

4. Budget is phase-specific

analysis、execution、review、promotion、incident、recovery で同じ budget を流用してはならない。

5. Governance limits are part of the budget

visibility と capability の境界は budget 外の話ではない。

6. Evidence floor cannot be traded away for compactness

短くするために required evidence を落としてはならない。

7. Freshness violations invalidate budget assumptions

stale context を前提にした budget は無効である。

8. Overflow handling must be explicit

silent omission ではなく、compaction / by-reference / split / escalate のどれかを取るべきである。

9. Optional context should yield before required context

落とす順番が必要である。

10. Budget must remain traceable to frame and bundle

なぜこの budget なのかが process 設計から説明できなければならない。

いつ Context Budget を見直すべきか

次の条件があるなら、budget の再設計が必要である。

1. handoff loss が高いとき

target の floor を満たしていない可能性がある。

2. stale context execution が増えるとき

freshness budget や invalidation policy が弱い可能性がある。

3. evidence insufficiency が多いとき

evidence floor が低すぎるか、handoff package が budget に fit していない可能性がある。

4. review / promotion が重すぎるとき

working band が広すぎるか、floor が wrongly inflated している可能性がある。

5. branch join で詰まりやすいとき

salience budget や active branch comparison budget が超えている可能性がある。

6. frequent reframe / escalation が起きるとき

frame 自体が大きすぎて、minimum safe budget が actor に対して過剰なのかもしれない。

短く言えば、
過剰なノイズ、根拠不足、stale execution、handoff loss、join overload が増えたら budget の再設計が必要
である。

最低限の自己点検

ある process が context-budget-aware かどうかは、次で点検できる。

actor ごとに最低限必要な floor を言えるか
floor と ceiling を分けて考えているか
evidence floor を明示しているか
visibility / capability を budget の一部として扱っているか
unresolved issue や branch comparison の上限を考えているか
overflow 時の対応が silent omission になっていないか
floor が ceiling を超えたとき process を変える設計があるか
phase / recovery / incident で budget を切り替えているか
by-reference に落とせるものと active に残すものを区別できるか
actor-local compiled context がこの budget から正当化できるか

このどれかが欠けるなら、その process はまだ context budget を十分に持っていない。

暫定的なまとめ

Context Budget が言っていることは、最終的には次の一文に集約できる。

context は、入るだけ入れればよいものではない。
ある actor が、ある局面で、安全に判断し、適切に作業し、必要な gate を守り、future process に耐える差分を返すために、最低限必要なものと、それ以上持つと壊れやすくなる上限の両方を設計する必要がある。

PCE 2.0 において context budget は、token 数の節約術ではない。
それは、局所視界を bounded にし、governance と evidence を落とさず、overflow を process change のシグナルとして扱うための設計概念である。

だから Context Budget は、単なる「何文字まで入れるか」ではない。
それは、PCE 2.0 において actor-local context を安全・十分・統治可能な範囲に保つための bounded-context semantics である。