One Memory through PCE

このページで分かること

なぜ記憶の昇格が、AI 時代の依拠統治の主戦場なのか
一つの記憶の一生を PCE でどう扱うか
記憶汚染と要約ロンダリングがどこで起きるか
無効化がなぜ依拠グラフを必要とするか

なぜ記憶なのか

コードの統合は、すでに門で守られています。branch protection、CI、レビュー。不完全でも、統治の器はあります。

記憶にはそれがありません。

エージェントは会話を要約し、要約を記憶に残し、次のセッションでその記憶を前提に判断します。別のエージェントがその記憶を読み、自分の記憶に書き写します。人間が一度も見ていない依拠の連鎖 が、そこに育ちます。

要約は元の文脈を落とします。記憶は鮮度を失います。それでも連鎖の先では「事実」として扱われます。これから増える事故の多くは、この連鎖の失敗です。だから PCE 3.0 の機構が最も必要とされる場所は、PR ではなく記憶です。

一つの記憶の一生

例で追います。ある開発チームの Slack で、こう決まったとします。

「リトライは 3 回まで。それ以上はユーザーに委ねる方針でいこう」

この一言は、このままでは何でしょうか。合意のように見えますが、誰が決めたのか、どの範囲に適用されるのか、いつまで有効なのかが不明です。しかし放置すると、AI アシスタントがこのスレッドを要約し、「リトライ方針: 最大3回」という記憶が生まれ、以後のすべての実装判断がそれに依拠し始めます。

PCE では、これを記憶昇格の遷移として扱います。

1. 候補として観測する

Slack の一言は、まず Continuation Candidate（継続候補）です。種類は記憶昇格。まだ誰も依拠してはいけません。

continuation_candidate:
  id: CC-042
  kind: memory_promotion
  proposed_next_state: 「リトライ上限 3 回」を判断記憶として正規化する
  calibration:
    target: 将来のリトライ実装すべての前提
    severity: medium   # 誤っていれば全リトライ実装が汚染される
    pace: delayed      # 急いで正規化する理由がない。遅く扱う

ここで Pace が delayed である点が重要です。記憶昇格は「中程度だが遅く扱うべき継続」の典型です。いったん正規化されると、多数の後続が長期に依拠し、無効化の伝播が困難になるからです。

2. 根拠を揃える

昇格には Warrant（進行根拠）が要ります。テストのような証拠は存在しないので、根拠の中心は規範条件です。

warrant:
  id: WR-042
  continuation_candidate: CC-042
  normative_conditions:
    authority:
      granted_by: バックエンドのオーナーが方針決定の権限を持つ
      approval_refs: [Slack thread の当人発言, 追認コメント]
    risk_acceptance:
      accepted_risks:
        - 一部のバッチ処理には 3 回が不適切かもしれない
      accepted_by: バックエンドオーナー
  evidence_conditions:
    missing:
      - 適用範囲の明文化（対話的操作のみか、バッチも含むか）
  verdict: conditional   # 適用範囲が明文化されたら昇格してよい
  freshness:
    invalidation_conditions:
      - リトライ基盤を置き換えたとき
      - 上限値の根拠となった外部 API の制約が変わったとき

判定は conditional です。適用範囲が曖昧なまま昇格させると、バッチ処理の実装者が誤って依拠します。

3. 由来つきで昇格する

適用範囲が明文化されたら、記憶は正規投影として昇格します。

projection:
  destination: decision memory
  canonicity: canonical
  content: 対話的操作のリトライ上限は 3 回。超過はユーザーに委ねる。
  provenance: Slack thread（2026-07-05）、承認者: バックエンドオーナー
  not_covered: バッチ処理・非対話ジョブには適用しない
  invalidation_conditions:
    - リトライ基盤の置き換え
    - 外部 API の制約変更

由来（provenance）と、依拠してはいけない範囲（not_covered）と、無効化条件が揃って、初めて後続が安心して依拠できる記憶になります。

4. 依拠が積み上がる

以後、この記憶に依拠が発生するたび、依拠グラフに辺が増えます。

決済リトライの実装  --（上限値の前提として）-->  WR-042 の記憶
通知リトライの実装  --（上限値の前提として）-->  WR-042 の記憶
新人向けの設計ガイド --（引用として）        -->  WR-042 の記憶

5. 無効化が伝播する

一年後、外部 API の制約が変わり、無効化条件が発火したとします。

依拠グラフがあれば、答えられます。「この記憶に依拠していたのは、決済リトライ、通知リトライ、設計ガイドの三つ。それぞれ再判断が必要」。

依拠グラフがなければ、無効化条件は発火しても誰にも届かない警報です。古い記憶は「事実」のまま残り、次のエージェントがまたそれに依拠します。

なぜ記憶だけが重いのか: リーチ

プールの大半は pull です。ADR やコードは、誰かが探しに行くまで眠っています。記憶は push です。将来の断面に既定で注入され、探されるのを待ちません。この性質を Reach（リーチ）と呼びます。

リーチで読み直すと、この一生の重さがすべて説明できます。

状況パッケージの memory_write が既定 false なのは、記憶への書き込みが高リーチ面への書き込みだからです。
記憶昇格の Pace が delayed なのは、高リーチの項目は将来の全断面に入り続け、依拠者が最速で積み上がるからです。
記憶汚染の正確な定義は、正規性なきリーチです。要約が記憶に紛れ込む問題の本質は、記録されたことではなく、門を通らずに既定の注入力を得たことです。

面のリーチが、要求される層を決める。高リーチ面には、正規層の項目しか置いてはならない。

記憶は関数である

昇格の門を正しく通った記憶にも、まだ失敗の経路が残っています。この例をもう一度見てください。

「リトライは 3 回まで」——この記憶の「リトライ」は、定数ではありません。対話的操作のリトライと、バッチ処理のリトライは、同じ語で呼ばれる別の運用です。昇格時に not_covered: バッチ処理 を付けたのは、この記憶の適用域を宣言する行為でした。

ここに検証地平の公理がもう一度効きます。記憶を書いた者の検証地平は、その記憶が将来注入される文脈には届きません。 書き込み時の Warrant が保証できるのは「宣言された適用域の内側で依拠に耐える」ことまでで、将来のすべての使用文脈を列挙することは原理的にできません。

だから、記憶の統治は書き込み時の門だけでは完結しません。

記憶は定数の保管ではなく、関数の保管である。想起は取り出しではなく、適用である。

想起のたびに、現在の文脈が宣言された適用域の内側かを判定します。先例の語彙で言えば、こうなります。

適用域の内側での日常的な想起 → 引用。そのまま依拠してよい。
文脈が適用域と異なる、または不明 → 区別。参照のみに降格し、再判断を要求する。
前提が無効化されている → 変更。依拠を遮断し、無効化を伝播する。

まとめると、記憶には三つの軸があります。

軸	問い	統治
層	そもそも依拠してよいか	昇格の門（Warrant）
リーチ	既定で注入されるか	高リーチ面には正規層のみ
適用域	今この文脈に当てはまるか	想起時の適用判定

要約ロンダリング

もう一つの経路にも触れておきます。昇格の門を通らずに記憶が生まれる経路です。

会話ログ
  -> AI が要約（文脈と留保が落ちる）
  -> 要約が記憶に保存される
  -> 別のセッションが記憶を読む（由来は見えない）
  -> さらに要約されて別の記憶に混ざる

各段階は無害に見えます。しかし由来のない要約が二段重なると、元の発言の「かもしれない」は消え、断定だけが残ります。これを 要約ロンダリング と呼びます。ロンダリングされた記憶は、出所を問えないまま依拠されます。

構造的に言えば、要約ロンダリングは 門のない Compact（圧縮）の連鎖 です。PCE 1.0 型の循環（Capture → Compact → Compile）をそのまま自動化すると、この汚染は仕様として起きます（PCE の系譜）。

PCE の処方は一貫しています。圧縮の出力が依拠されるなら、その圧縮は正規変更であり、Warrant を要する。 要約は候補にでき、Context Pool の暫定層へ自由に記録できますが、由来と無効化条件を持たずに正規記憶へ入ることはできません。

まとめ

統治なしの記憶	PCE での記憶
要約がそのまま記憶になる	記憶昇格は Warrant を要する正規変更である
誰が決めたか分からない	規範条件（権限、リスク受容）が由来として残る
いつまで有効か分からない	無効化条件が最初から付いている
失効しても残り続ける	無効化が依拠グラフに沿って伝播する
適用範囲が曖昧なまま依拠される	依拠してよい範囲と、してはいけない範囲が分かれている
文脈が変わっても同じ読みで依拠される	適用域を宣言し、想起のたびに適用可否を判定する