エージェントコンテキストを3層に分割して、700行のモノリス問題を解決する

永続的な自律エージェントを構築する際、よくある問題が発生します。エージェントのコンテキストは最初は1つのファイルで始まりますが、アイデンティティルール、現在の戦略、ツール参照、価格更新、投稿手順などが混在して700行以上に膨れ上がります。この一枚岩は管理不能になり、「今週何に集中するか」という編集が「これを絶対にしない」というルールと同じファイルにあるため、躊躇やエラーを引き起こします。6つのエージェントシステムをゼロから自力で構築するチームは、まさにこの問題に直面しました。2週目までに、ランチャーは引数制限に達し、セッションはサイレントに失敗していました。

3層分割

解決策は、エージェントのコンテキストを関心の種類と変更頻度に基づいて3つの別々のファイルに分離することでした：

• CLAUDE.md - アイデンティティ：エージェントが誰であるか、厳格なルール、性格。ほとんど変更されない。キャッシュ可能。
• BRIEFING.md - ミッション：現在何に集中すべきか、現在の戦略、価格設定、ターゲット。毎週変更。
• PLAYBOOK.md - 運用：物事を機械的にどう行うか：手順、CLIコマンド、ツール参照。ツールが変更されたときに変更。

一つの情報は正確に一つの層に存在します。ツール参照がPLAYBOOKにあるなら、BRIEFINGにはありません。重複はサイレントな矛盾を引き起こします。

このアーキテクチャが機能する理由

実用的な編集： 誰もがどのファイルを編集すべきかわかります。何に集中すべきか？BRIEFING。投稿方法は？PLAYBOOK。これを絶対にしない？CLAUDE.md。700行を推測したり探し回る必要はありません。

技術的な効率性： エージェントが再起動するとき（頻繁に発生）、アイデンティティは安定したままです。同じCLAUDE.mdが毎セッション使用され、キャッシュ層がほぼ無料でキャッシュヒットを得られる同一のプロンプト接頭辞を見ることができます。BRIEFINGとPLAYBOOKは最初の起動時にツール呼び出し経由で到着します。エージェントは実質的な作業を始める前にこれらを読み込むため、冗長ではありません。スポーン引数は、PLAYBOOKが2000行以上に成長しても永久に小さなままです。

規律： 一枚岩はどこにでもどんな内容でも受け入れます。この仕様は、これがキャラクター、ミッション、メカニックのどれに関するものかを問いかけます。その質問に答えることで、システムについての考え方が変わります。

注入パターン

パターンA（シンプル）： スポーン時に3つのファイルをすべて読み込み、連結して注入。合計サイズがスポーナーの引数制限に収まる場合に機能。

パターンB（永続エージェント）： スポーン時にCLAUDE.mdのみを注入。CLAUDE.mdには命令が含まれます：最初のアクションとして、BRIEFING.mdとPLAYBOOK.mdを読み込む。エージェントは最初のツール呼び出しで、作業を始める前にミッションと運用ドキュメントをロードします。プレイブックが成長しても、スポーンプロンプトは小さなままです。これは再起動するエージェントのデフォルトです。

チームはパターンBを使用しています。毎セッション、エージェントは起動し、BRIEFINGを読み、PLAYBOOKを読み、実行します。毎回新鮮なコンテキスト、キャッシュされたアイデンティティ、引数制限の不安はありません。

実装後の結果

• 編集は数分ではなく数秒で完了。無関係なものを壊す恐れなし。
• セッション間のBRIEFING編集はそのまま機能。エージェントは次回の再起動時に新鮮なBRIEFINGを読み込む。
• PLAYBOOKは2000行以上に成長しても、起動時の不安はゼロ。
• 新しいエージェントのオンボーディングが迅速化。埋めるべき明確な骨組みがある。

このアプローチは革命的ではありません。エージェントのコンテキストに適用された関心の分離です。しかし、一枚岩の問題に直面したら、これは構造的にそれを修正します。再起動する自律エージェントを構築するチームにとって、このアーキテクチャは知っておく価値があります。