コンテキストエージェントの監査 : 自分のガバナンスが問題になるとき — そして何も失わずにそれを修正する方法
公開日: 27 April 2026
あなたは完璧なエージェントガバナンスを構築するために何週間も費やしました。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 |
問題解決、基本原則、ダッシュボード対マニュアルの類似 |
バックティックコードスパン ( |
P2 — ファイル構造 |
97 |
階層構造, ロードポリシー, 何をいつロードするか |
— |
P3 — 絶対的なルール |
34 |
Git は禁止、破壊的なコマンドは禁止、機密情報は禁止 |
|
P4 — セッションライフサイクル |
133 |
テンプレート オープニング, 作業ルール, セッション終了の6ステップ, チェックリスト |
|
P5―メトリクスとしきい値 |
49 |
理想的なセッション(15-30分、1-3ファイル)、警告サイン |
(空白) |
P6 — セッションの種類 |
72 |
�検出表, 提案フォーマット, 例外 |
— |
P7 — 継続的な改善 |
39 |
追跡指標, 週次レビュー |
— |
P8 — 起動チェックリスト |
13 |
Bootstrap 新しいプロジェクト |
(Empty) |
P9 — 参考文献 |
30 |
参照ファイル, 外部リソース |
|
付録 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`, これが与えられます :
-
�抽出する新しいファイルの161行のユニークな知識 (P1 + P2)
LAZY_EAGER_ESSENTIALS.adoc— 約50行に圧縮され、厳密にEAGER -
名前を変更
AGENT_MODUS_OPERANDI.adocen.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc— 元のファイルは627行で、*intact*の状態でコールドストレージに保存されています -
決して充電するな百科事典ファイルは自動的に — それは人間のため、将来の蒸留のため、そして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/)はタイムスタンプ付きスナップショットである — 過去の状態のバックアップコピー
百科事典、これは別のものだ。これはテーマ別の知識の集まりであり、主題ごとに構成され、包括的だが非線形である。百科事典は最初から最後まで読むものではない。そこに飛び込んで特定の質問に答える。
これはまさにこのファイルの契約です:
ファイル |
役割 |
アクセス |
粒度 |
|
過去のデータ(月ごとに完了したタスク) |
LAZY, 構造化された |
年代順の |
|
冷たいスナップショット(10セッションの波) |
COLD, 完全コピー |
時系列の |
|
包括的なテーマ別の知識(方法論、パターン) |
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ステップ手順は次の通りです:
-
�測る : `wc -l`すべてのEAGERファイルに対して。合計は1000行以下であるべきです。
-
最大のものを特定する: 合計の20%以上を占めるファイルが疑わしいファイル第1位です。
-
セクションごとに監査: 各セクションについて、自分に問いかける 「この情報は他のところにすでにありますか? エージェントは他のファイルで既にこれを読みましたか? これは過去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つも失っていません。
全部ここにある。ただ、もっときれいに片付けられている。
リンク
-
記事 0108 — アイガー/レイジー戦略 :AsciiDocを使ってAIエージェントを管理する
-
条項 0110 — ホット/ウォーム/コールド メカニズム :スライディングウィンドウと寒波
-
私のサイト:https://cheroliv.com
-
プロジェクト`magic-stick`: https://github.com/cheroliv/magic-stick
知識は消える必要はない。必要でないときはロードしないだけだ。
関連記事
31 May 2026
14 May 2026