読了時間 : 14 minutes

あなたは完璧なエージェントガバナンスを構築するために何週間も費やしました。Eager/Lazy、セッション終了手順、ローテーションバックアップ。システムは稼働しています。ある日、エージェントが遅くなりました。応答が薄まっています。測定したところ:自動的にロードされた1414行。そして最悪なのは、原因がコードでもバックログでもセッションアーカイブでもないことです。原因は、あなたの方法をドキュメントするファイルです。

チック

[]

シーン: セッション051、何かがおかしい

2026年4月30日、16時00分。私は現在セッション中`magic-stick`, 私のLinuxライブISOのビルドプロジェクト。Opencodeエージェントは、いつものように私のEagerファイルを自動的にロードしました —AGENT.adoc, PROMPT_REPRISE.adoc, .agents/INDEX.adoc. すべてが正常です。

ただし、返答が弱い。エージェントは推論に2秒余計に時間がかかる。彼は、3つ前のメッセージで目の前にあった詳細を忘れてしまう。これはクラッシュでもエラーでもなく、ゆっくりと劣化していくようなもので、すぐに気づくようなことではない。

以前、セッション048で同じ経験をしました。そのとき、ガバナンスファイルの合計が5200行あることを発見しました。そこで、10セッションのスライドウィンドウを持つHot/Warm/Coldメカニズム、同じコールドウェーブ、2つのトリガーを持つセンサーを概念化しました。問題は理論的には解決しました。

しかし、私たちはセッション051にいます。バックアップのローテーションは正常に実行されました — EAGERファイルは2087行から500行に減りました。しかし、コンテキストはまだ重いです。何かが私にはつかめない。

端末を開いて、入力します :

wc -l AGENT.adoc AGENT_MODUS_OPERANDI.adoc PROMPT_REPRISE.adoc \
  .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \
  .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
  287 AGENT.adoc
  627 AGENT_MODUS_OPERANDI.adoc
   51 PROMPT_REPRISE.adoc
  218 .agents/INDEX.adoc
   18 .agents/SESSIONS_HISTORY.adoc
  213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
 1414 total

1414行。バックアップローテーションが INDEX, SESSIONS_HISTORY, COMPLETED_TASKS をうまくトリムしました — これらはきれいです。しかし、部屋に象がいることに気づいていませんでした:627 行1つのファイルに。AGENT_MODUS_OPERANDI.adoc。

このファイルは、セッション1でEager/Lazy戦略を文書化するために私が書いたものです。これはこの方法のマニュアルです。そして、それだけでEAGERコンテキストの44%になりました。

@startuml
skinparam backgroundColor #FEFEFE

title コンテキスト EAGER — 1414 行
rectangle "AGENT_MODUS_OPERANDI
**627 行 (44%)**" as MOD #FFCDD2
rectangle "AGENT.adoc
287 行 (20%)" as AG #BBDEFB
rectangle "INDEX.adoc
218行 (15%)" as IDX #C8E6C9
rectangle "COMPLETED_TASKS
213 行 (15%)" as ARC #FFF9C4
rectangle "PROMPT_REPRISE
51 行 (4%)" as PRO #E1BEE7
rectangle "SESSIONS_HISTORY\n18行(1%)" as HIS #FFE0B2

note bottom of MOD
  Le fichier qui documente
  la méthode est devenu
  le plus gros poste de dépense
end note

@enduml

皮肉は完全だ。コンテキストを*節約*するために設計されたファイルが、コンテキストの主要な*消費者*になった。まるであなたの車の取扱説明書がエンジンよりも重いかのように。

監査:627行を詳細に調べる

私はセクションごとに監査を行うことに決めました。削除するためではなく、*理解*するためです。EAGERにふさわしいものと、知識の損失なく他所で生きていけるものを見極めるためです。

ここに正確な構造があります:`AGENT_MODUS_OPERANDI.adoc`そしてそこで見つけるもの :

セクション

行

内容

既に…​に存在しています。

P1 — 概要

64

問題解決、基本原則、ダッシュボード対マニュアルの類似

バックティックコードスパン (…​) をすべてそのまま保持してください — バックティックの内容、間隔、位置を決して変更しないでください。 このテキストはより大きな文の一部である可能性があります — より多くのコンテキストを要求せずにフラグメントを翻訳してください。 翻訳されたテキストのみを出力してください — 説明も commentary も導入も代替案もオプションもありません。

P2 — ファイル構造

97

階層構造, ロードポリシー, 何をいつロードするか

—

P3 — 絶対的なルール

34

Git は禁止、破壊的なコマンドは禁止、機密情報は禁止

AGENT.adoc+INDEX.adoc

P4 — セッションライフサイクル

133

テンプレート オープニング, 作業ルール, セッション終了の6ステップ, チェックリスト

AGENT.adoc§セッション終了 +INDEX.adoc

P5―メトリクスとしきい値

49

理想的なセッション(15-30分、1-3ファイル)、警告サイン

(空白)

P6 — セッションの種類

72

�検出表, 提案フォーマット, 例外

—

P7 — 継続的な改善

39

追跡指標, 週次レビュー

—

P8 — 起動チェックリスト

13

Bootstrap 新しいプロジェクト

(Empty)

P9 — 参考文献

30

参照ファイル, 外部リソース

AGENT.adoc(ファイル EAGER/LAZY)

付録 A+B

42

用語集, バージョン履歴

—

判決は覆らない:

  • 完全な重複(167 行) : P3, P4, P9 — すべて既に含まれている`AGENT.adoc` ou INDEX.adoc, しばしば逐語的に

  • 実践では一度も相談されなかった(215 行) : P5, P6, P7, P8, 付録 — どのセッションでも一度も使われたことがないメタガバナンス

  • 唯一の知識(161 行) : P1 と P2 — LAZY/EAGER の語彙、類推、ロードポリシー

627行で,382 は騒音です. そしてこれらの382行は、各セッションの開始時に 読み込まれ、エージェントによって消費され、私が「こんにちは」と言う前に彼の注意を薄めます。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title AGENT_MODUS_OPERANDI.adoc の監査 — 627 行
left to right direction

rectangle "�🟡 **重複**
167 行 (27%)" as DUP #FFF9C4 {
  card "P3 — 絶対的な規則
(34行)" as D1
  card "P4 — ライフサイクル
(133 行)" as D2
  card "P9 — 参考文献
(30 行)" as D3
}

rectangle "🔴 **未参照**
215 行 (34%)" as JAM #FFCDD2 {
  card "P5 — メトリクス
(49行)" as J1
  card "P6 — 検出\n(72 行)" as J2
  card "P7 — �善
(39 行)" as J3
  card "P8 — Bootstrap
(13 行)" as J4
  card "付録 — 用語集
(42 行)" as J5
}

rectangle "🟢 **独自の知識**
161 行 (26%)" as UNI #C8E6C9 {
  card "P1 — 概要
(64 行)" as U1
  card "P2 — ファイル構造
(97 行)" as U2
}

note bottom of UNI
  C'est ÇA qu'il faut garder en EAGER.
  Le reste → cold storage.
end note

@enduml

この図がすべての鍵です。重複(黄色)は純粋なノイズです — エージェントはそれらを2回読み、異なる2つのファイルで読み取ります。未参照(赤色)は死んだドキュメントです — 慎重に書かれているが、決して使われません。緑だけが、エージェントが他では見つけることができない知識を含んでいます。

エンジニアリングを失う恐れ

この段階で、私は目の前に証拠がある:減らさなければならない。AGENT_MODUS_OPERANDI.adoc. しかし、私は躊躇しています。

このファイルは手書きで書きました。各セクションは実際のセッションで学んだ教訓の結果です。P3の部分はある`rm -rf`偶発的な上で`bakery-plugin`実際のFirebaseトークンを消費させられた。P4部分は、アーカイブし忘れて途中で方向を見失った15回のセッションの結果です。この6ステップの手順は書籍から生まれたものではなく、苦痛から生まれたものだ。

これらのセクションを削除すれば、自分のエンジニアリングの歴史を捨てることになる。これらを生み出した教訓、それらを発見したセッション、二度と繰り返したくないミス。これはテキストではない――結晶化された経験だ。

ここで私が、解決を導く原理を定式化します :

_ 絶対に削除しないで。常に移動させて。知識はプロジェクトから消える必要はない。ただ、必要ないときは自動的に読み込まれないようにすればよい。 _

解決策: split百科事典的

私が提案するモデルはシンプルで、Wikipediaが成長した方法からインスピレーションを得ています : 記事が長くなりすぎたら切るのではなく — 詳細な記事を作成し、主要な記事に要約を残します。

のために`AGENT_MODUS_OPERANDI.adoc`, これが与えられます :

  1. �抽出する新しいファイルの161行のユニークな知識 (P1 + P2)LAZY_EAGER_ESSENTIALS.adoc— 約50行に圧縮され、厳密にEAGER

  2. 名前を変更 AGENT_MODUS_OPERANDI.adoc en .agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc— 元のファイルは627行で、*intact*の状態でコールドストレージに保存されています

  3. 決して充電するな百科事典ファイルは自動的に — それは人間のため、将来の蒸留のため、そして6ヶ月後にもっと良いモデルで呼び出すエージェントのために存在しています。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title 分割百科事典 — AGENT_MODUS_OPERANDI
left to right direction

rectangle "**AGENT_MODUS_OPERANDI.adoc**
627 行
(分割前)" as BEFORE #FFCDD2 {
}

rectangle " " as ARROW1
rectangle " " as ARROW2

rectangle "**LAZY_EAGER_ESSENTIALS.adoc**
**~50 行 — EAGER**" as ESS #C8E6C9 {
  card "P1凝縮
(15行)" as E1
  card "P2凝縮版\n(35 行)" as E2
}

rectangle "**.agents/encyclopedies/**
**LAZY_EAGER_ENCYCLOPEDIE.adoc**
627 行 — COLD" as ENC #BBDEFB {
  card "P1を付録へ
(完全, 無傷)" as C1
}

BEFORE -[#4CAF50]-> ESS : "クリティカルな知識の抽出"
BEFORE -[#2196F3]-> ENC : "完全な保存
エンジニアリングの"

note bottom of ESS
  Chargé automatiquement
  en début de session
  → L'agent comprend le vocabulaire
end note

note bottom of ENC
  Jamais chargé automatiquement
  Consultable par l'humain
  Matériau brut pour distillation future
end note

@enduml

名前`encyclopedies/`それは軽々しいことではない。百科事典はアーカイブのファイルではなく、整理された知識の集まりで、参照できるが持ち運びはできない。メトロではEncyclopédie Universalisを読まない。これを図書館に置き、具体的な質問があるときにそこに行く。

これはまさにこのフォルダーの役割です:冷たく、構造化され、包括的な参照ライブラリ — エージェントが自動的に触れないもの。

ファイルの内容 ESSENTIALS

これが新しいファイルの具体的な姿です。LAZY_EAGER_ESSENTIALS.adoc, 抽出および圧縮され、P1 と P2 から:

= Stratégie LAZY/EAGER — Principes Essentiels

[abstract]
Ce fichier définit la stratégie de gestion du contexte agent.
Chargé automatiquement (EAGER) en début de session.

== Principes

|===
| EAGER | LAZY
| Tableau de bord | Manuel du propriétaire
| Chargé automatiquement | Chargé sur demande
| <= 100 lignes, <= 10k tokens | Illimité, détaillé
| Règles absolues, mission courante | Archives, historique, références
|===

== Politique de Chargement

|===
| Fichier | Type | Quand charger
| PROMPT_REPRISE.adoc | EAGER | Début session (auto)
| *_ESSENTIALS.adoc | EAGER | Début session si EPIC active
| .agents/INDEX.adoc | EAGER | Début session (auto)
| *_REFERENCE.adoc | LAZY | Sur besoin (détails architecture)
| .agents/sessions/N-*.adoc | LAZY | Sur demande (détails session)
| .agents/encyclopedies/*.adoc | COLD | Jamais auto (humain seulement)
|===

== Comment l'Agent Sait Quoi Charger

Début session → PROMPT_REPRISE + INDEX + ESSENTIALS actifs.
Besoin de détails → charger les *_REFERENCE et sessions/ en LAZY.
Connaissance froide → encyclopedies/, jamais automatique.

50行。これがエージェントがメカニズムを理解するために必要なすべてだ。それ以外―レッスンの履歴、詳細なアナロジー、ステップバイステップの手順、付録―はすべて百科事典にある。

そして最も重要なこと:何も削除されていません. 627行のエンジニアリングラインはまだそこにあります、その中`.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc`. それらはただ本棚に置かれているだけで、作業台の上にあるわけではありません。

結果: -50% の EAGER コンテキスト

分割前:

 287 AGENT.adoc
 627 AGENT_MODUS_OPERANDI.adoc
  51 PROMPT_REPRISE.adoc
 218 .agents/INDEX.adoc
  18 .agents/SESSIONS_HISTORY.adoc
 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
1414 total

分割後:

 287 AGENT.adoc
  50 LAZY_EAGER_ESSENTIALS.adoc       ← remplace 627 lignes
  51 PROMPT_REPRISE.adoc
 218 .agents/INDEX.adoc
  18 .agents/SESSIONS_HISTORY.adoc
 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
 837 total                              ← -41%
@startuml
skinparam backgroundColor #FEFEFE

title エン�ンサイクロペディック分割後の EAGER コンテキスト — 837 行 (-41%)
rectangle "AGENT.adoc
287行(34%)" as AG #BBDEFB
rectangle "INDEX.adoc
218行 (26%)" as IDX #C8E6C9
rectangle "COMPLETED_TASKS
213 行 (25%)" as ARC #FFF9C4
rectangle "PROMPT_REPRISE
51 行 (6%)" as PRO #E1BEE7
rectangle "ESSENTIALS
50 行 (6%)" as ESS #A5D6A7
rectangle "SESSIONS_HISTORY
18 行 (2%)" as HIS #FFE0B2

note bottom of ESS
  De 627 → 50 lignes
  577 lignes d'ingénierie
  préservées en cold storage

  Rien de perdu. Tout de relocalisé.
end note

@enduml

最大の消費者(AGENT_MODUS_OPERANDI, 627行)は50行のファイルに置き換えられました。利益は即座に得られます:577行のコンテキストが解放されました。エージェントは安堵しています。

そして中で`.agents/encyclopedies/`元のファイルは627行で待っています。変更されていません。すべてのセクション — 重複しているものも、まだ使われていないものも含めて — 。なぜなら、いつかより良いモデルまたは人間のデータサイエンティストがこれらの角度、これらの受け入れられた冗長性、これらの学んだ教訓を交差させたくなるからです。そしてその日には、原材料がそこにあるでしょう。

なぜフォルダーは `encyclopedies/`と呼ばれるのですか?

名前の選択は装飾的ではない。それはメカニズムの哲学をエンコードする。

アーカイブ (archives/) 歴史的なデータが年代順に整理されて含まれています — 月次の COMPLETED_TASKS のように。 backup (backup/)はタイムスタンプ付きスナップショットである — 過去の状態のバックアップコピー

百科事典、これは別のものだ。これはテーマ別の知識の集まりであり、主題ごとに構成され、包括的だが非線形である。百科事典は最初から最後まで読むものではない。そこに飛び込んで特定の質問に答える。

これはまさにこのファイルの契約です:

ファイル

役割

アクセス

粒度

archives/

過去のデータ(月ごとに完了したタスク)

LAZY, 構造化された

年代順の

backup/

冷たいスナップショット(10セッションの波)

COLD, 完全コピー

時系列の

encyclopedies/

包括的なテーマ別の知識(方法論、パターン)

COLD、決してオート

テーマ

この区別は雑多になることを防ぎます。各ファイルは、*作成時*ではなく、*その中身*に従って、どこに置くべきかを知っています。

シリーズの論理的な続き

最初の2つの記事を読んだ場合、ここで3つのピースがどのように組み合わされるかを示します:

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220

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

package "�📖 **Article 0108**
戦略 Eager/Lazy" as A1 #E8F5E9 {
  card "エージェントメモリ
セッション間" as M1
  card "EAGER ファイル
(自動的にロードされた)" as M2
  card "ファイル LAZY
(オンデマンド)" as M3
  card "6段階の手順" as M4
}

package "�🧊 **Article 0110**
メカニズム ホット/ウォーム/コールド" as A2 #FFF9C4 {
  card "老化
コンテキストの" as V1
  card "スライドウィンドウ
10セッション" as V2
  card "�寒波
同じ" as V3
  card "二つのトリガーを備えたセンサー" as V4
}

package "�🔍 **Article 0111**\n監査 + 百科事典ソリューション" as A3 #BBDEFB {
  card "ファイルの監査
EAGER" as E1
  card "特定
廃棄物" as E2
  card "Split
ESSENTIALS/百科事典" as E3
  card "保存
エンジニアリングの" as E4
}

A1 --> A2 : "メモリは増大する\n→ 経年劣化のメカニズムが必要"
A2 --> A3 : "経年だけでは不十分です
→ 監査する必要があるもの
EAGERである価値がある"

note bottom of A3
  ✅ Les trois couches sont en place
  sur 6 projets actifs
end note

@enduml
  • 0108回答: «エージェントに二つのセッションの間で記憶を与える方法は?

  • 0110それに答える : « この記憶がエージェントを窒息させないようにどう防ぐか?

  • 0111返答: 「そして問題がアーカイブのサイズではなく、EAGERに設定することを*選んだ*ものである場合は?」

最初の論文は構造を構築した。二番目は老化メカニズムを追加した。三番目は内容を監査し — そして方法論自身が問題になったことを発見した。

私が違うようにやったこと

振り返ってみると、最初の設計ミスに気づく。`AGENT_MODUS_OPERANDI.adoc`これは単一のドキュメントとして作成され、マニフェストとなりました。それは思考を形式化するための正しいアプローチでした。しかし、思考が形式化された後、ドキュメントはすぐに分割されるべきでした:EssentialはEAGER、包括的はcoldとして。

私は文書に誇りを持っていたので、それを行わなかった。627行の純粋なエンジニアリング、手書きで書かれ、各セクションはセッションのレッスンの成果だった。それは私の作品だった。そして、あらゆる作者のように、私はそれを分割するのに苦労した。

レッスン:文書が良いからといって、自動的に読み込まれるべきではない。. コンテンツの品質は、エージェントの直近の文脈への関連性とは関係がない。

今日、ルールは単純です:EAGERコンテキストにおいて100行を超えるドキュメントはすべて疑わしいものです。監査の対象となります。非難ではなく監査です。問題は決して「削除すべきか?」ではなく「各セッションでロードすべきか?」です。

自分のコンテキストを監査するためのガイド

最初の2つの記事に従い、独自のEager/Lazyガバナンスを構築した場合、監査の5ステップ手順は次の通りです:

  1. �測る : `wc -l`すべてのEAGERファイルに対して。合計は1000行以下であるべきです。

  2. 最大のものを特定する: 合計の20%以上を占めるファイルが疑わしいファイル第1位です。

  3. セクションごとに監査: 各セクションについて、自分に問いかける 「この情報は他のところにすでにありますか? エージェントは他のファイルで既にこれを読みましたか? これは過去5セッションで使用されましたか?」

  4. 分類器重複、一度も使用されていない、独自の知識。

  5. 分割または再配置: 何が独自かつ重要であるか → ESSENTIALS コンパクト化。それ以外すべて →encyclopedies/。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title コンテキストエージェントの監査手順 — 5ステップ
start

:1. **Mesurer**\n`wc -l *.adoc .agents/*.adoc`;

if (Total > 1000 lignes ?) then (oui)
  :⚠️ Contexte trop lourd;
else (non)
  :✅ Contexte OK;
  stop
endif

:2. **Identifier le suspect**\nLe fichier > 20% du total;

:3. **Auditer section par section**\nPour chaque section :\n• Déjà ailleurs ? → doublon\n• Jamais servi ? → mort\n• Information unique ? → critique;

:4. **Classifier**\n🟡 Doublons → à retirer de l'EAGER\n🔴 Jamais utilisé → cold storage\n🟢 Connaissance unique → à garder;

:5. **Splitter**\n🟢 → ESSENTIALS (~50 lignes, EAGER)\n🟡🔴 → encyclopedies/ (cold storage);

:✅ Contexte optimisé\nsans perte d'ingénierie;

stop

@enduml

この手順は15分かかります。50セッションのプロジェクトでは、今後の各セッションで数百トークンを節約できます。ROIは即座に現れます。

活きたガバナンス

この3部作の記事シリーズから私が学んだことは、エージェントガバナンスは完成品ではないということです。それは生きている生物. 彼女はプロジェクトとともに成長する。 彼女は成長に伴う病気にかかる。 彼女は定期的なチェックアップが必要だ。

セッション 048 は、アーカイブが膨らんでいることを明らかにしました。セッション 051 は、方法論そのものが膨らんでいることを明らかにしました。セッション 060 はおそらく別の何かを明らかにするでしょう。それは普通です。それは健全です。決して自己反省しないガバナンスは死んだガバナンスです。

三つのメカニズム — Eager/Lazy、Hot/Warm/Cold、百科事典的分割 — が配置され、コンテキストの飽和に対する深層防御システムを形成しています。いずれも単独では十分ではありません。組み合わせると、互いに補完し合います:

  • 熱意がある/怠惰な可用性で情報を構造化する

  • 暑い/温かい/寒い情報を*新鮮さによって*構造化する

  • 百科全書の監査情報を*密度で*構造化する

@startuml
skinparam backgroundColor #FEFEFE
skinparam nodeBackgroundColor #E3F2FD

title コンテキストの飽和に対する深層防御
node "**エージェントコンテキスト**
~800 行
健康" as CTX #C8E6C9

node "レイヤー 1\n**EAGER / LAZY**" as C1 #BBDEFB
node "�層2
**ホット / ウォーム / コールド**" as C2 #BBDEFB
node "層 3
**基本 / 百科事典**" as C3 #BBDEFB

CTX --> C1 : "構造による\n**可用性**"
CTX --> C2 : "構造による\n**新鮮さ**"
CTX --> C3 : "構造による
**密度**"

note bottom of C3
  Les trois couches sont nécessaires.
  Aucune n'est suffisante seule.
end note

@enduml

これらの3つの層で、エージェントのコンテキストについて`magic-stick`2087行(あらゆる最適化を行う前)から約800行に減少 — つまり2.6倍に削減されました。ドキュメントの1行も、セッションのアーカイブも、学んだ教訓も1つも失っていません。

全部ここにある。ただ、もっときれいに片付けられている。

リンク


知識は消える必要はない。必要でないときはロードしないだけだ。

関連記事