Compaction

定義

Compaction

Compaction とは、ある source context、trace、delta set、phase history、または handoff / recovery material を、
ある actor、purpose、phase、modality に対して、
安全 floor を保ったまま、active に保持する量と複雑さを縮約し、継続可能な局所視界へ再構成する操作 である。

それは単なる要約や削除ではなく、
required core preservation、relevance reduction、by-reference externalization、governance-preserving omission、evidence trace retention、freshness declaration、expansion path provision を含む。

より短く言えば、Compaction とは
「この actor がいま必要なものを落とさずに、不要な冗長性だけを減らし、active context を bounded に作り直すこと」
である。

PCE 2.0 において context は、ただ長く持つものではない。
Actor-local Compiled Context は、
その actor が今の責任を legal かつ adequate に遂行できる範囲で bounded であるべきである。
Compaction は、その boundedness を operational に実現するための中心操作である。

なぜ Compaction が必要なのか

PCE 2.0 が compaction を独立に扱うのは、
長い process では context が自然に膨張し、膨張した context がそのままでは process quality を損なうからである。

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

1. 冗長な active context は判断を鈍らせる

irrelevant detail が混ざる
stale state が見え続ける
required evidence と optional notes が同列になる
branch / issue / candidate が多すぎて salience が落ちる
reviewer や evaluator が本来見るべき core を見失う

2. 何でも削ると governance failure になる

一方で、雑に短くすると

pending approval が消える
required eval result が見えなくなる
rollback note が落ちる
scope 制約が消える
allowed / prohibited action の境界が曖昧になる
provenance が失われる

つまり compaction は「短くすること」ではなく、
何を絶対に落としてはならないかを守りながら縮約すること である。

3. actor ごとに適切な active context は違う

同じ source からでも、

coding agent
reviewer
evaluator
memory writer
incident owner
checkpoint manager

で必要な local view は違う。
Compaction は actor-relative でなければならない。

4. long-running process では phase ごとに context を畳まないと continuity が壊れる

analysis の全履歴を implementation に丸ごと持ち込み、
implementation の全 trace を review に丸ごと渡し、
review の全議論を memory writing に丸ごと渡すと、
それぞれの actor の local budget をすぐに超える。

Compaction は、phase 間 continuity を壊さずに 履歴を局所 view へ畳み直す ために必要である。

5. overflow は process design の信号でもある

必要 floor を落とさずにコンパクトにできないなら、
それは単なる summary 技術の問題ではなく、

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

という設計問題である。
Compaction は、その overflow を見える形にする。

Compaction は何ではないか

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

1. 単なる要約ではない

要約は compaction の一技法ではある。
しかし compaction は、

pending gates を保持し
required evidence refs を残し
authority / scope を落とさず
omitted parts の再展開手段を持つ

必要がある。
単に短い summary を作るだけでは compaction にならないことが多い。

2. 単なる token compression ではない

LLM の token limit は hard ceiling の一部だが、
PCE 2.0 の compaction は token 数だけを最適化するものではない。

3. 単なる retrieval policy ではない

何を取ってくるかは Context Selection の問題である。
Compaction は、選ばれた source を active view としてどう畳むかを扱う。

4. 単なる compaction = deletion ではない

省略したからといって消えたわけではない。
by-reference で残し、必要時に再展開できることが多い。

5. 単なる memory promotion ではない

compacted artifact は often useful だが、そのまま durable memory になるわけではない。
Compaction と Memory Promotion は別である。

6. 単なる checkpoint ではない

checkpoint は continuity を保存する transition / object である。
compaction は、その checkpoint や resumable summary を作る中で使われる操作であることが多い。

7. 単なる “見せる情報を減らすこと” ではない

compaction の本質は reduction ではなく
safe boundedness である。
必要 floor を壊さない reduction だけが compaction である。

Compaction が扱う source

PCE 2.0 では、compaction の source は一つではない。
少なくとも次のような source が対象になりうる。

1. Raw interaction history

chat transcript
reasoning trace
review discussion
implementation notes

2. Delta history

emitted deltas
accepted / rejected deltas
branch return deltas
pending promotion candidates

3. Evidence bundles

test reports
rationale notes
rollback notes
source refs
evaluation outputs

4. Phase history

analysis phase outputs
implementation phase outputs
review phase outputs
incident handling history

5. Continuity packages

handoff package
recovery package
join package
approval submission package

6. Branch comparison materials

alternative design branches
sibling child returns
conflict summaries
integration notes

このとき source が何かによって、compaction の目的と制約も変わる。

Compaction の目的は一つではない

同じ source でも、目的が違えば compacted result は違う。
PCE 2.0 では compaction は常に purpose-bound である。

1. Execution Continuation Compaction

active executor が次の局所 work を進めるための compaction。

重視するもの:

goal slice
target files / current work state
stop conditions
expected output

2. Review / Approval Compaction

reviewer や approver が judgment するための compaction。

重視するもの:

diff / subject
required evidence
pending gates
rollback feasibility
scope note

3. Evaluation Compaction

evaluator が contract を適用するための compaction。

重視するもの:

subject
required evidence
applicable criteria
missing evidence
blocking / advisory context

4. Handoff Compaction

次の actor が continuity を受け取るための compaction。

重視するもの:

transferred responsibility
retained responsibility
unresolved issues
expected next action
return contract

5. Recovery Compaction

later resume のための resumable summary / recovery material compaction。

重視するもの:

current lifecycle
pending gates
delta refs
stale context markers
legal next transitions

6. Join Compaction

複数 branch / child return を統合判断するための compaction。

重視するもの:

branch comparison core
required returns
unresolved conflicts
integration criteria

7. Promotion Preparation Compaction

memory writer や promotion evaluator のための compaction。

重視するもの:

candidate
provenance
target collection semantics
duplication context
evidence adequacy

つまり compaction は、一つの「正しい summary」を作る操作ではなく、
目的別に複数の bounded view を作る操作 である。

Compaction の中心操作

PCE 2.0 では compaction は少なくとも次の操作を含む。

1. Preserve Core

安全 floor に属するものを残す。

例:

goal slice
scope constraints
pending gates
required evidence refs
stop conditions
expected output contract

2. Remove Redundant Surface

重複した履歴、同じ意味の反復、低 salience の detail を active から落とす。

3. Externalize by Reference

必要だが常時 active に置く必要のないものを ref 化する。

例:

full diff
full trace
complete spec
old conversation
full branch logs

4. Normalize Structure

source の形式を、target actor に適した形へ整える。

例:

conversation → issue list
review comments → grouped findings
raw log → failure note
branch outputs → comparison table

5. Collapse History into State

過去の連続的なやりとりを、現在意味のある state として畳み直す。

例:

long discussion → approved interpretation
repeated requests → current unresolved issue
several gate interactions → pending approval state

6. Declare Omission

何を active から外したかを示す。
Compaction は silent omission であってはならない。

7. Attach Expansion Paths

必要なら、何をどう再展開すればよいかを残す。

8. Attach Freshness / Invalidation

この compacted artifact がいつ stale になるか、何が変わったら再 compaction が必要かを示す。

Compaction の妥当性条件

PCE 2.0 では、compaction は次の条件を満たしてはじめて有効とみなせる。

valid_compaction(source, compacted, target_actor, purpose) iff
  safety_floor_preserved(compacted, target_actor, purpose)
  and gate_continuity_preserved(compacted)
  and required_evidence_resolvable(compacted)
  and authority_boundaries_preserved(compacted)
  and omissions_declared(compacted)
  and freshness_declared(compacted)
  and fits_context_budget(compacted, target_actor, purpose)

ここで重要なのは、
compaction が単に「短くなったか」ではなく
継続可能で、governable で、再展開可能か
で判定される点である。

Safety Floor を保つ

Context Budget で述べたように、
compaction で最も重要なのは safety floor を保つことである。

典型的な floor

current goal slice
applicable scope
current stop conditions
pending approval / eval relevant to target
required evidence refs
expected output
required action constraints

落としてはならないものの例

reviewer から rollback note を落とす
memory writer から provenance を落とす
evaluator から required evidence refs を落とす
incident owner から blast radius note を落とす
recovery summary から pending gate を落とす

floor を守れないとき

もし floor を守ると ceiling を超えるなら、
compaction は破綻している。
その場合は、

child frame へ切る
branch を切る
staged review にする
checkpoint して later pass に回す
escalation / reframe する

べきである。
PCE 2.0 では、unsafe compaction より process redesign を優先する。

One source, many compactions

一つの source から、複数の正当な compacted view が生まれうる。
これは PCE 2.0 にとって重要である。

例

同じ implementation phase の source からでも、

coding agent 向け continuation context
reviewer 向け review package
memory writer 向け candidate bundle
recovery 用 resumable summary

は違う。

つまり compaction は、source を一つの正解 summary に変えるのではない。
source を target-relative bounded views に変えるのである。

この点で compaction は、
Actor-local Compiled Context の生成過程そのものと深く結びつく。

Compaction と Governance Surface の関係

Compaction は単なる usability の操作ではない。
Governance Surface を壊さないことが必要である。

保持すべきもの

visible / hidden boundary
allowed / prohibited actions
pending approval / eval / promotion gate
escalation path
scope restrictions

危険な compaction

prohibited tool constraint を省略する
pending approval を summary から落とす
“review passed” っぽく圧縮して実際は pending である
parent-retained authority を child summary から落とす

こうした compaction は、
governance-corrupt compaction であり、
Corrupt Success を生みやすい。

つまり compaction は、
ただ短くするのではなく governance-preserving reduction でなければならない。

Compaction と Eval Contract の関係

Eval Contract は、何が required evidence かを決める。
Compaction は、その evidence を active に残すか、by-reference で保持するかを決める。

重要な原則

required evidence は落としてはならない
active に全文を置かないことは許される
しかし evaluator / approver が必要時にすぐ到達できる ref を残さなければならない

例

review package compaction では、

full CI log は by-reference でよい
しかし CI report ref 自体は floor
rollback note の全文は summary + ref でよい
しかし rollback feasibility の有無は active に必要

つまり compaction は、
eval contract を evidence topology として反映する。

Compaction と Memory Promotion の関係

Memory promotion 前の candidate は、often compaction を必要とする。
だが compaction と promotion は別である。

典型例

raw failure trace → failure lesson candidate
long review discussion → approved summary candidate
repeated review comments → checklist candidate

ここで compaction は、candidate を durable-form に近づける。
しかしそれを canonical memory にしてよい かどうかは、
まだ Memory Promotion Criteria と Memory Promotion Rules が必要である。

重要な点

compacted = durable ではない
compacted = approved でもない
compacted artifact は often provisional である

この区別がないと、
summary を作っただけで canonical truth のように扱う危険がある。

Compaction と Handoff の関係

Handoff は target actor が継続可能になるための continuity transfer である。
この continuity package は、ほぼ必ず何らかの compaction を含む。

良い handoff compaction

goal slice を明確にする
relevant evidence を絞る
pending gates を落とさない
unresolved issues を整理する
expected next action を一意に近づける
target budget に fit する

悪い handoff compaction

source local context をそのまま投げる
raw transcript を長いまま渡す
pending approval を消す
evidence refs を失う
“たぶんこの辺りが重要” で丸める

つまり handoff の品質は、
compaction の品質にかなり依存する。

Compaction と Checkpoint / Recovery の関係

Checkpoint and Recovery において compaction は特に重要である。
長時間 process では、recover 時に raw past を全部 active に戻すことはできないし、すべきでもない。

Recovery Compaction の目的

current lifecycle を短く記述する
pending gates を保持する
emitted deltas を ref で保持する
stale local contexts を明示する
legal next transitions を保持する

注意点

recover 用 compaction は、通常の execution 用 compaction と違う。
ここでは

provenance
gate continuity
freshness
invalidation rules

がより重要になる。

warm vs cold

warm compaction は recent local continuity を多く残す
cold compaction は refs + validated summary を中心にする

つまり compaction は、
recovery semantics の shape をかなり左右する。

Compaction と Branch-and-Join の関係

複数 branch の比較や統合では、compaction は必須になる。
すべての child return を full detail のまま active に持つと、join が破綻しやすい。

Join compaction の目的

required branch returns だけを active にする
branch ごとの key differences を並べる
unresolved conflicts を明示する
integration owner が次を決められるだけの evidence を保つ

危険

alternative branch の差異を潰しすぎる
branch failure note を落とす
join に必要な risk / rollback info を消す
one branch の assumptions を全体の truth に見せる

したがって join compaction は、
比較情報を保ったまま bounded にする必要がある。

Compaction の主な型

PCE 2.0 では、少なくとも次の compaction type を区別できる。

1. Structural Compaction

重複やノイズを減らし、形式を整理する。
意味内容はほぼ変えない。

例:

repeated logs の dedup
grouped comments
sorted issue list

2. Referential Compaction

大きい情報を by-reference に回す。
active には ref と short descriptor だけ残す。

例:

full diff → diff ref
full log → log ref
full document → document ref

3. Semantic Compaction

複数の source を意味的にまとめる。
このとき omissions と provenance が重要である。

例:

discussion → approved summary candidate
trace → failure lesson candidate
repeated comments → checklist candidate

4. Phase Compaction

一つの phase の history を、次 phase 用の bounded view に畳む。

例:

analysis history → implementation brief
implementation history → review package

5. Handoff Compaction

target actor が work continuity を受け取れるように package 化する compaction。

6. Recovery Compaction

later resume のために resumable summary を作る compaction。

7. Join Compaction

複数 branch / child return を比較可能・統合可能な形にする compaction。

8. Promotion-prep Compaction

memory candidate を durable-form に近づける compaction。
ただし promotion と同一ではない。

Lossless, Bounded-loss, Forbidden

compaction は loss profile でも分類できる。

1. Lossless Structural Compaction

主に冗長性や形式だけを減らし、意味的内容はほぼ失わない。
安全性が高い。

2. Bounded-loss Semantic Compaction

いくつかの detail を落とすが、

safety floor
evidence trace
gate continuity
authority boundaries
expansion paths

を保つ。
実務で最も一般的である。

3. Forbidden Compaction

floor を壊したり、corrupt success を生みやすい compaction。

例:

required evidence の蒸発
pending approval の削除
speculative note を fact-like に圧縮
policy violation を summary から消す

PCE 2.0 では、compaction の巧拙より先に
compaction の可否 を問う必要がある。

Compaction Failure Modes

compaction は便利だが、壊し方も強い。
PCE 2.0 では、少なくとも次の failure mode を意識するとよい。

1. Gate Evaporation

pending approval / pending eval / pending promotion が summary から消える。

2. Evidence Evaporation

source ref、rollback note、rationale の出所が落ちる。

3. Scope Laundering

out-of-scope 変更や policy conflict が compacted view では見えなくなる。

4. Confidence Inflation

「仮説」「未確認」「候補」が、compaction によって「確定事項」のように見える。

5. Authority Laundering

source actor の local view や local acceptance が、
あたかも global approval のように見えてしまう。

6. Staleness Camouflage

古い summary が current truth のように再利用される。

7. Branch Flattening

alternative branch の差や unresolved conflict が潰れて、
比較不能・責任不明になる。

これらは Corrupt Success の源になるため、
compaction は always reversible / attributable / bounded であるべきだ。

いつ compact すべきで、いつ process を変えるべきか

これは実務上とても重要である。

compact すべき典型条件

floor はすでに分かっている
source は冗長だが、意味の中心は clear
target actor / purpose が明確
by-reference で十分な large payload がある
same frame / same path の continuation として扱える

process を変えるべき典型条件

floor を守ると ceiling に収まらない
unresolved issues が多すぎて salience budget を超える
actor ごとに必要な view が根本的に違う
join conflict が大きすぎる
explanation のために全 trace を active に持たないと判断不能
authority overflow を compaction で隠してしまいそう

この場合は、

child frame 化
branch 化
staged review
checkpoint and later pass
escalation
reframe

の方が正しい。

つまり compaction は、
good process design の代用品ではない。

Compaction の最小スキーマ

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

compaction_spec:
  compaction_id:
  source:
    frame_ref:
    actor_ref:
    bundle_ref:
    source_kind:
    source_refs:
    horizon:
  target:
    actor_ref:
    phase:
    modality:
    purpose:
  budget_ref:
  retained_core:
    goal_slice:
    required_scope_constraints:
    required_pending_gates:
    required_evidence_refs:
    stop_conditions:
    expected_output:
  transformed:
    summaries:
    grouped_items:
    normalized_structures:
  externalized_by_reference:
  omitted:
  unresolved:
  governance_constraints:
    visible_collections:
    allowed_actions:
    prohibited_actions:
  freshness:
    source_epoch:
    invalidated_by:
  expansion_paths:
  resulting_status:
    # transient | provisional | approved_summary_candidate
  provenance:

実行結果の record としては、次のようにも置ける。

compaction_record:
  compaction_ref:
  target_context_ref:
  floor_preserved: true | false
  fits_budget: true | false
  omitted_items:
  by_reference_items:
  unresolved_items:
  invalidation_conditions:
  evidence_refs:
  notes:

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

source と target を明示する
retained core を独立に持つ
omitted と by-reference を区別する
freshness / invalidation を持つ
resulting_status を持つ
provenance を持つ

つまり compaction は、
単なる文字列生成ではなく governed context-transformation artifact として扱われるべきである。

小さな例

feature.checkout.coupon-combination frame の implementation phase から reviewer 用 review package を compact するとする。

compaction_spec:
  compaction_id: comp.review-package.checkout.coupon-combination.v1
  source:
    frame_ref: feature.checkout.coupon-combination
    actor_ref: coding_agent
    bundle_ref: coding_agent_impl_bundle_v2
    source_kind: implementation_phase_history
    source_refs:
      - implementation_trace
      - delta.feature.checkout.coupon-combination.v3
      - local_test_run_552
      - approved_spec_summary
    horizon: implementation_phase_only
  target:
    actor_ref: reviewer
    phase: review
    modality: review_ui
    purpose: approval_review
  budget_ref: reviewer_review_budget_v1
  retained_core:
    goal_slice: >
      approved spec に対して code change が適合しているか判断し、
      merge readiness を approve / reject / request_changes する
    required_scope_constraints:
      - payment_gateway_changes_are_out_of_scope
    required_pending_gates:
      - code_review_approval
      - required_regression_confirmation
    required_evidence_refs:
      - code_diff_ref
      - ci_report_ref
      - approved_spec_summary_ref
      - rollback_note_ref
    stop_conditions:
      - missing_required_evidence
      - scope_violation_detected
    expected_output:
      - approval_verdict
      - review_comments_if_any
  transformed:
    summaries:
      - implementation_note_summary
      - changed_files_summary
      - unresolved_issue_summary
    grouped_items:
      - changed_files_by_area
      - edge_case_notes_grouped
    normalized_structures:
      - review_checklist_mapping
  externalized_by_reference:
    - full_implementation_trace_ref
    - full_test_logs_ref
    - complete_precedence_adr_ref
  omitted:
    - coding_agent_internal_iteration_notes
  unresolved:
    - edge_case_for_stacked_discount_rounding
  governance_constraints:
    visible_collections:
      - current_diff
      - required_decisions
    allowed_actions:
      - approve
      - reject
      - request_changes
    prohibited_actions:
      - direct_code_edit
  freshness:
    source_epoch: implementation_completed_at_2026_03_09T10_30_00Z
    invalidated_by:
      - code_diff_changes
      - approved_spec_changes
  expansion_paths:
    - open_full_diff
    - open_full_ci_report
  resulting_status: transient
  provenance:
    compiled_from:
      - feature.checkout.coupon-combination

この compaction で重要なのは、

reviewer に必要な floor は残っている
coding agent の internal trace 全部は active にない
しかし full diff と CI report には ref で戻れる
pending approval / pending eval は保持されている
old package が stale になる条件も明示されている

という点である。

Compaction の不変条件

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

1. No compaction below safety floor

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

2. No compaction that hides governance-relevant state

approval pending、policy conflict、authority boundary を消してはならない。

3. No compaction without provenance for condensed claims

要約された claim は source refs に戻れるべきである。

4. No compaction that turns uncertainty into certainty

候補、仮説、pending、insufficient を確定事項のように圧縮してはならない。

5. No compaction without freshness / invalidation semantics

いつ stale になるかを示さない compacted artifact は危険である。

6. Compaction does not imply durable truth

compacted output は often transient または provisional であり、そのまま canonical ではない。

7. If floor exceeds ceiling, change the process

unsafe compaction より process redesign を優先すべきである。

8. Compaction must remain actor- and purpose-specific

一つの compacted view を universal truth として流用してはならない。

9. By-reference must remain resolvable

ref に逃がしたなら、その ref が開けることが必要である。

10. Compaction should reduce noise, not erase accountability

短くなっても、誰が何をしたか、どの gate が残っているかは追えるべきである。

最低限の自己点検

ある compaction が十分かどうかは、次で点検できる。

target actor と purpose が明示されているか
safety floor を列挙できるか
omitted と by-reference を区別しているか
pending gates を落としていないか
required evidence refs が残っているか
uncertainty が certainty に変わっていないか
stale になる条件があるか
budget overflow 時に process redesign を検討しているか
compacted artifact を canonical truth と誤認していないか
same source から別 actor 向けに別 compaction が必要だと理解しているか

このどれかが欠けるなら、その compaction はまだ PCE 2.0 の意味で安全ではない。

暫定的なまとめ

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

context を短くすること自体には価値がない。
価値があるのは、ある actor がいま必要な floor を落とさずに、冗長性だけを減らし、必要なものは ref で辿れ、pending gate と authority boundary を壊さずに、bounded な local view を作ることである。

PCE 2.0 において compaction は、省メモリ技法ではない。
それは、長い process を bounded context の連続へ変換しつつ、governance と evidence を失わないための操作である。

だから Compaction は、単なる要約ではない。
それは、PCE 2.0 において context を安全・十分・再展開可能な形へ縮約する governed reduction operation である。