スライドウィンドウと寒波 : エージェントコンテキストが爆発し、損失なくアーカイブしなければならないとき

wc -l .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \
  .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

title コンテキストエージェントの成長 — セッション 1 から 48
rectangle "セッション 1-10" as S10 #E8F5E9
rectangle "セッション 11-20" as S20 #C8E6C9
rectangle "セッション 21-30" as S30 #A5D6A7
rectangle "セッション 31-40" as S40 #81C784
rectangle "セッション 41-48" as S48 #66BB6A

note right of S10
  INDEX : ~50 lignes
  SESSIONS : ~10 lignes
  ARCHIVE : ~100 lignes
  **Total : ~300 lignes**
end note

note right of S20
  INDEX : ~100 lignes
  SESSIONS : ~20 lignes
  ARCHIVE : ~400 lignes
  **Total : ~800 lignes**
end note

note right of S30
  INDEX : ~160 lignes
  SESSIONS : ~30 lignes
  ARCHIVE : ~900 lignes
  **Total : ~1800 lignes**
end note

note right of S40
  INDEX : ~220 lignes
  SESSIONS : ~45 lignes
  ARCHIVE : ~1400 lignes
  **Total : ~3200 lignes**
end note

note right of S48
  INDEX : **260 lignes**
  SESSIONS : **55 lignes**
  ARCHIVE : **1756 lignes**
  **Total : 5200 lignes** ⚠️
end note

S10 -[#green]-> S20
S20 -[#green]-> S30
S30 -[#FF9800]-> S40
S40 -[#red]-> S48

@enduml

----
----
.agents/
├── INDEX.adoc                         → Sessions N-9 à N (10 dernières)
├── SESSIONS_HISTORY.adoc              → Sessions N-9 à N
├── SCRIPT_VERIFICATION.adoc           → Dernière vérif (pas d'historique)
├── PROMPT_REPRISE.adoc                → Session N+1 uniquement
├── sessions/                          → Sessions N-1 à N uniquement
└── backup/
    └── Y2026-sessions-001-039/          ← Vague froide, COPIE INTÉGRALE
        ├── INDEX.adoc                  → Sessions 001 à 039 (complet)
        ├── SESSIONS_HISTORY.adoc       → Sessions 001 à 039 (complet)
        ├── COMPLETED_TASKS_ARCHIVE.adoc → Sessions 001 à 039 (complet)
        └── sessions/                   → 001.adoc, 002.adoc...
----

メカニズムの鍵 :**バックアップは中央のインデックスではなく、過去の波の正確なコピーです。**. 10セッションのアクティブなホライゾンを超えると、何も削除せず、何も再インデックスせず、何もマージせず、セッション N-10時点のエージェントファイルのパケットをそのまま取り、それを移動`backup/`。

アクティブなファイルは、切り捨てられます :

* INDEX : 最後の10行のみ (sliding window)
* SESSIONS_HISTORY : 同様
* COMPLETED_TASKS_ARCHIVE : 現在の期間の新しいファイル
* sessions/ : 直近の 2 セッションのみ

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title コンテキスト エージェントのホット / ウォーム / コールド アーキテクチャ
package "HOT (EAGER)
自動的に充電
~300 行" as HOT #FFCDD2 {
  file "INDEX.adoc
(10 セッション)" as IDX_HOT
  file "PROMPT_REPRISE
(セッション N+1)" as PRO_HOT
  file "AGENT.adoc\n(絶対ルール)" as AG_HOT
}

package "WARM (LAZY)
オンデマンドでロード
約500行" as WARM #FFF9C4 {
  file "SESSIONS_HISTORY\n(最近の10件)" as HIS_WARM
  file "SCRIPT_VERIFICATION
(最後)" as VER_WARM
  file "PROCEDURES.adoc
(テンプレート)" as PRO_WARM
  file "*_REFERENCE.adoc
(技術文書)" as REF_WARM
}

package "COLD (backup/)
決して充電されていない
人間のみが読むことができます" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "インデックス (完全)" as IDX_COLD
    file "SESSIONS_HISTORY\n(完了)" as HIS_COLD
    file "完了タスク
(完了)" as ARCH_COLD
    folder "セッション/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???\n(将来)" as FUTURE
}

HOT --> WARM : "エージェントが上がる
必要に応じて"
WARM --> COLD : "決して自動ではない
人間は一人でそこに行く"

note bottom of COLD
  Règle : COPIE INTÉGRALE
  Pas de transformation
  Pas de réindexation
  Read-only après archivage
end note

@enduml
----

即時の利益は巨大です：EAGERコンテキストはから**~5200行から~300行まで**. 17で割る。 歴史的データの一行も失わずに。

== なぜこれは万能ではない

エージェントは、最初のイテレーションで、恐れていた`backup/`ブラックボックスになる — つまり、二度と見返すことのないファイルを捨て込むフォルダーだ。それは正当な恐れだ。だが、それは誤解に基づいている。

雑多な集まりとは、ファイルを投げ込むときのこと**構造もなく、慣習もなく、グループ化の論理もなく**. ここで、バックアップは期間 (Y2026-001-039) によって構造化されており、各バックアップフォルダには**同じ構造**が ファイル`.agents/`アクティブ : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.

これは雑多なものではありません。これは**タイムスタンプ付きスナップショット**. さらに言うと、これは簡略化されたバージョン管理のメカニズムと言えるかもしれません — ただし、ファイルを個別にバージョン管理するのではなく、ある時点Tでのガバナンスの完全なパッケージをバージョン管理するという意味です。

古い情報を見つけたいときは、中央のインデックスは必要ありません。二つの選択肢があります。

1. **grep` ターゲット指定の** : `grep -r "zsh" backup/Y2026-001-039/`— そして、期間中にzshを言及するすべてを見つけることができます。どの角度からでも (INDEX, SESSIONS_HISTORY, セッションアーカイブ)。
2. **手動再統合**バックアップフォルダーを一時的にアクティブコンテキストにコピーし、エージェントにこの特定の期間を分析させるように依頼します。

インデックスは暗黙的である。ファイルの構造そのものに存在し— 各ファイルはそれ自身の視点からすでにインデックスである。

== 棚のメタファー

メカニズムを直感的にするために、私はそれを3つの棚に概念化しました

* **棚 1 (EAGER)**— 作業計画。私が必要としているもの *今*。最近のINDEX、PROMPT_REPRISE、絶対ルール。軽量、即時、重要。
* **棚 2 (LAZY)**— 参照図書館。私が要請時に取りに行けるもの。技術参照、最近の履歴、手順。ボリュームは大きいが、メモリにロードされていない。
* **�洞窟 (backup/)**— コールドアーカイブ。 過去のすべてだが、捨てたくないもの。 エージェントはそこに決して入らない。 人間は、蒸留したいときにそこに降りる。

エージェントは最初に4番目の棚を提案した — 一つ`index-backup.adoc`それは LAZY で、バックアップ全体の目次を含むものになるでしょう。私は断りました。それは、すでに線形成長に苦しんでいるシステムにさらなる冗長性を加えることになります。アーカイブされたファイルの構造はすでにインデックスです。

== 二重トリガーセンサー

概念化は堅固だったが、盲点が残っていた :**正確にいつ回転を開始するべきですか？**最初の記事はそれをオープンな質問として特定していた。二日後、答えは6つのプロジェクトのガバナンスファイルにコード化されていた：2つのトリガーを持つセンサー。

=== 自動トリガー — `N % 10 == 0

最初のトリガーは数学的なものです。セッション番号が10の倍数 — つまりセッション10、20、30、40 — のとき、バックアップのローテーションはセッション終了手順の一部として自動的に実行され、特に手順6の直後に実行されます。

なぜ10なのか？それは相反する二つの力の間の妥協点です。短すぎるウィンドウ（5セッション）は継続に必要な文脈を失い、長すぎるウィンドウ（20セッション）は文脈の肥大化問題を解決しません。1日あたり1～2セッションのペースで10セッションは概ね1週間分の仕事をカバーします。これはエージェントが最近の決定を思い出すには十分ですが、文脈が爆発的に増えるほどではありません。

=== しきい値トリガー — 500行 EAGER

2番目のトリガーは動的です。セッション番号に関わらず、累積されたEAGERファイルが超える場合**500行**, 回転が開始されます。

このしきい値は、セッションが例外的に生産的であるシナリオ — 少ないセッションで多くのコンテンツが書かれる — から保護します。120行の編集コンテンツを生成するセッションは、2行を修正するデバッグセッションよりもCOMPLETED_TASKS_ARCHIVEをはるかに速く肥大化させます。500行のしきい値は、経由で測定されます`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, この非対称性を捉える。

=== マニュアルトリガー — "ローテーションバックアップ

最後に、人間が主導権を握ります。キーワード`rotation backup`, `backup rotation` ou `lance la rotation backup`要求時にプロシージャを起動し、セッションの終了とは独立して行われます。コンテキストが重くなってきたと感じたとき、まだ10の倍数には達していない場合や、新しい作業フェーズを開始する前に現在の作業フェーズをアーカイブしたいときに便利です。

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title バックアップ回転センサー — 三つのトリガー
start

:Procédure de fin de session;
note right: Mots-clés "セッションの終了"\nou "ここでやめよう"

:Étapes 1 à 6\n(archivage standard);
note right
  1. Archive sessions/N.adoc
  2. MAJ PROMPT_REPRISE
  3. MAJ SESSIONS_HISTORY
  4. MAJ INDEX.adoc
  5. MAJ TEST_COVERAGE
  6. MAJ COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :⚙️ Rotation Backup\n(étape 7);
  note right
    1. Créer backup/Y20XX-sessions-X-Y/
    2. Copier intégrale INDEX + HISTORY
       + COMPLETED_TASKS + sessions/
    3. Tronquer actifs à 10 sessions
    4. Ajouter _Localisation active_
  end note
else (non)
  :Pas de rotation;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

この図は、セッション終了手順におけるセンサーの正確な挿入を示しています。ステップ 7 はオプションであり（２つの条件のいずれかが真である場合にのみ実行されます）が、常に *チェック* されます。最終チェックリストには`[✅] 7. Backup roté (si applicable)`。

=== 閉じられたループ

このセンサーは、前の記事で開かれたループを閉じます。Eager/Lazy ガバナンスは、2 つのセッション間のエージェント メモリの問題を解決しました。Hot/Warm/Cold メカニズムは、増大するメモリの問題を解決しました。2 つのトリガーを持つセンサーは、*いつ* の問題を解決します —  — 人間にコンテキスト サイズを監視する精神的負担を強いることなく。

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title エージェントガバナンスの三層
left to right direction

package "�層 1 — メモリ
(条項 0108)" as C1 #E8F5E9 {
  rectangle "EAGER
ダッシュボード
自動ロード" as EAG
  rectangle "**LAZY**\n所有者マニュアル\n必要時にロード" as LAZ
  EAG -[hidden]right-> LAZ
}

package "�層2 — 経年変化
(条項 0110)" as C2 #FFF9C4 {
  rectangle "**HOT**
10件のアクティブなセッション
~300 行" as HOT
  rectangle "**WARM**\n参照\n手順" as WRM
  rectangle "**COLD**
backup/
寒波" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "レイヤー 3 — トリガー
(今日)" as C3 #BBDEFB {
  rectangle "**オート**\nN % 10 == 0" as AUTO
  rectangle "しきい値
> 500行" as SEUIL
  rectangle "**マニュアル**
ローテーション バックアップ" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "メモリは増大する
→ メカニズムが必要
老化の"
C2 --> C3 : "老化
→ トリガーが必要です
これを実行するために"

note bottom of C3
  ✅ Déployé sur 6 projets
  magic-stick · bakery-gradle
  plantuml-gradle · cheroliv.com
  jhipster-gradle-plugins
  quizz-benchmark-gradle
end note

@enduml
----

3つの層は論理的に積み重なります。最初の層はエージェントにメモリを与えます。2番目の層はこのメモリがエージェントを圧迫しないようにします。3番目の層はこのメモリのメンテナンスを自動化し、人間がそれについて考える必要がなくなります。

=== cheroliv.comでの効果的な移行

メカニズムは理論のままでは残らなかった。 Sur`cheroliv.com`,最初のバックアップローテーションは2026年4月29日に実行されました — セッション-6から2までが移行されました`.agents/backup/Y2026-sessions-neg6-a-002/` :

|===
|ファイル |回転前 |回転後 |利益 |`.agents/INDEX.adoc` |リストされている19のセッション |10 セッション (3-12) |-9 件 |`.agents/SESSIONS_HISTORY.adoc` |18セッション |10セッション |-8件 |`COMPLETED_TASKS_ARCHIVE` |161 行 (セッション 1-12) |135 行 (セッション 3-12) |-26 行 |`sessions/` |20個のファイル |10ファイル |-10 ファイル |**バックアップ/** |存在しない |1つの寒波 (10件のアーカイブされたセッション) |+1 冷却パック
|===

行数の増加は控えめでした — プロジェクトは若く、12セッション — しかし重要なのは**メカニズムは整っている**. 次の自動ローテーションは、セッション20でトリガーされます。または、500行のEAGERに到達した場合はそれより早くトリガーされます。

== 人間エージェントのレッスン

このセッション048 から、AI エージェントとの協力について根本的に重要なことを学びました。

エージェントは自然なバイアスを持っている：それを求める**最適化する**, à **簡素化する**, à **�冗長を排除する**. これは、きれいで簡潔な回答を生成するように訓練されたシステムのバイアスです。リッチで多次元的なデータセットに直面したとき、その最初の反応はそれを最もシンプルな形にまで簡素化することです。

人間は、むしろ異なる直感を持っている：彼は構造化された冗長さが何かであると直感している**強み**, 欠点ではない。同じ現実に対する角度の多様性こそが、後に質の高い蒸留を可能にするものだ。

エージェントが間違っているわけではない。彼の `optimum` が私のものではないということだ。エージェントは…のために最適化している**プレゼント**直近の文脈、質問に対する素早い回答。人間はそれに最適化する**未来**— 3か月または3年で見つけ、交差し、蒸留する能力。

____ 私が欲しいのは未加工の素材だ。君の考え、ためらい、私の質問への答え。君のまとめではない。まとめは、私なら君より上手にできる。私が欲しいのは原材料だ。 ____

私がセッションの終わりに彼に言ったこの言葉は、すべてを表している。エージェントは生産のためのツールだ。人間は抽出のためのツールだ。ガバナンスはエージェントが自分一人で全てを理解できるように作られているわけではない — ガバナンスは、人間が後で生産された素材を扱えるように作られている。

同じ冷たい波は、この哲学の建築的な翻訳である：何も捨てず、何も結合せず、何も再インデックスしない。パケットをそのまま移動させる。蒸留は後に、手作業で、人間によって行われる。

== 前の記事の論理的な続き

もしあなたが読んだらlink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Eager/Lazy 戦略に関する記事], あなたは自然な進行を認識するでしょう:

1. **第108条**— Eager/Lazyガバナンス： *comment*エージェントコンテキストを2段階の可用性で構造化する方法
2. **この記事 0110**— バックアップメカニズム : *comment* このコンテキストを失うことなく古くする、それが大きすぎるようになるとき

最初の記事は次の質問に答えていた：「エージェントはセッション間で何も覚えていない。どうすれば記憶を与えることができるか？」

これは最初の質問から必然的に派生する質問に答えるものです：「メモリは各セッションごとに肥大化します。エージェントを削除せずに窒息させないようにするにはどうすればよいでしょうか？」

答えは1つのパターンに収まる：**ホット/ワーム/コールド**, ガバナンスファイルに適用された。そして一つの原則 :**決して何も失わない、常にすべてを再配置する**。

== リンク

* 前の記事 :link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[AsciiDocを使ったAIエージェントの管理]
* 私のサイト : https://cheroliv.com
* プロジェクト`magic-stick`: https://github.com/cheroliv/magic-stick

---

*良いガバナンスシステムはデータを決して削除せず、整理する。*
----