LLMセッションのドリフトを防ぐ7ファイルガバナンスレイヤー

r/LocalLLaMAの開発者が、ClaudeのようなLLMコーディングアシスタントがセッション間でアーキテクチャ上の決定を黙って元に戻すのを防ぐ解決策を共有しました。LLMセッションを会話として扱う代わりに、プロトコルを必要とするステートレスなプロセスとして扱うようになりました。

核心の問題

すべてのLLMセッションはゼロの記憶から始まります。あなたが再説明し、LLMが再解釈し、自信を持ってずれていきます。開発者は次のように述べています：「プロジェクトの深部、おそらく3ファイル目か4ファイル目、あるいは最後の部分に到達するまで、気づかないでしょう。」

7ファイルのガバナンスレイヤー

解決策はより良いプロンプトではなく、どのモデルでも読み取って即座に動作できるガバナンスレイヤーです。このシステムは7つのファイルを使用し、それぞれが特定の懸念事項を重複なく担当します：

• active_context.md - セッションコントローラー、現在のスコープを定義
• contracts.md - 行動の法則、データスキーマ、列挙値、必要な動作
• agent_core.md - 実行規律、操作方法、検証方法、報告方法
• agent_project.md - プロジェクトの意図、このシステムが存在する理由、期待される成果
• decisions.md - ADRログ、自明でない選択とその採用理由
• build_plan.md - モジュールのロードマップ、実装順序と成果物
• state.md - ライブジャーナル、完了事項、変更事項、残り事項

主要な設計上の決定

開発者は2つの重要な分離を説明しました：

contracts.mdとagent_core.mdの分離：「行動上の矛盾が生じたとき、モデルはどのレイヤーに従うべきか知る方法がありませんでした。これはスキーマのルールなのか、実行上の好みなのか？これらが分離されていると、階層は明確で、契約が常に優先されます。」

decisions.mdを含めること：「私はほとんどそれをスキップしそうになりました（『覚えているから』）。3週間後、特定のモジュールでなぜSQLiteではなくPostgresを選んだのか再構築できませんでした。ADRログが存在するのは、まさに『覚えている』がプロトコルではないからです。」

運用ループ

すべてのセッションは例外なくこの順序に従います：

1. active_context.mdを読む → 現在のスコープを抽出
2. contracts.mdに対して再接地 → 行動ルールを固定
3. agent_core.md + agent_project.mdから運用制約を確認
4. decisions.mdをチェック → 受け入れられた選択を逆転させない
5. active_context.mdが承認し、build_plan.mdに従うもののみを実行
6. テストで検証 — 証拠なしに完了を宣言しない
7. state.mdを事実の結果で更新
8. 新しい非自明な決定がなされた場合、decisions.mdに記録

ワークフローへの影響

active_context.mdのスコープロックは特に価値があることが証明されました：「これ以前は、バグを修正するためにセッションを開始し、『それがそこにあったから』という理由で無関係なモジュールをリファクタリングして終わることがありました。生産的に感じました.........そしてそれはそうでした。」