AI エージェントの記憶を git だけに置き環境は捨てる「秘書戦略」
事業の戦略ドキュメントだけを置いたリポジトリを Docker サンドボックス（使い捨ての実行環境）内の Claude Code で開き、そのセッションに調査・Issue 起票・道具のリポジトリへの指揮を任せています。（以下、このセッションを秘書と呼びます）
サンドボックスは作り直すたびに、clone した内容も記憶ファイルも環境変数への追記もすべて消えます。そこで、エージェントの記憶は git だけに置き、サンドボックスとセッションは消える前提で設計しています。自動メモリ（Claude Code が会話から自動で書き溜める記憶）よりも永続性と汎用性において理があると考えているからです。
置き場所を責務で分ける
エージェントの記憶は、1つのファイルにまとめず、責務ごとに分けて置いています。
direction.md なぜ・誰に・何を・何で測るか
channels/*/strategy.md 出口ごとの戦略（同じ型で）
operations.md 自律でやってよいこと・止まる基準・委譲の型
runbook.md 実行環境がなぜ動くか・壊れたら何をするか
decisions/ 採った案・捨てた案・理由（日付ごと）
journal/ 目的・分かったこと・決めたこと・やったこと・持ち越しdirection.md と channels/ は方針だけを持ち、手順やコードは持ちません。手順は道具のリポジトリの責務です。operations.md は自律の範囲と止まる基準という権限の判断だけを持ち、runbook.md は環境がなぜ動くか・壊れたら何をするかという実行手順だけを持つというように、判断と手順も別の文書に分けています。
権限の判断が書かれているのは operations.md だけなので、秘書がどこまで自分で動いてよいかを確かめるときに読む場所は1つに決まります。
runbook.md には、再利用可能な知識はその場でこのファイルかジャーナルに書き、main にコミットするという原則を明文化しています。実行環境の再現手順が会話の中にしか残っていないと、次のセッションからはそれを読む手段がありません。
議事録は書ける、判断は PR を通す
文書の変更は、小さくてもプルリクエストにします。git log の 1行には「何をしたか」しか残りませんが、プルリクエストの本文には理由が残ります。変更の理由を文脈の濃い瞬間に書かせるのと同じ理屈です。
唯一の例外が journal/ です。目的・分かったこと・決めたこと・やったこと・持ち越しの 5節だけを書く議事録で、プルリクエストを通さず main に直接コミットします。判断そのものは journal/ に置かず、決まったことは direction.md や channels/、decisions/ 側に反映します。ジャーナルは、セッションの終わりを待たずに、揮発させたくない結果が出た時点で書きます。セッションが途中で切れても、記録だけは残ります。
まだ決めていないことは、1件1Issue にします。決まったら文書に反映して Issue を閉じます。
decisions/ の引き継ぎ文書は、次のセッションが前の会話を一切知らない前提で、決めた理由、捨てた案、現在地の数字、次にやることをまとめた物です。次のセッションが読むのは、会話のログではなくこの 1本です。
唯一 PR を必須にする一線
operations.md の「必ず止まって仰ぐこと」には、この規約自体の変更と、秘書の権限を広げる変更が含まれます。この2つだけは、例外なくプルリクエストにして人がマージします。
journal/ は main に直接書けます。この 1行が無いと、同じ手で規約や権限の記述を書き換えられてしまいます。判断と議事録を置き場所で分けるだけでは、その分け方自体が書き換えられることまでは防げません。規約の自己書き換えと権限拡大だけは、置き場所の設計とは別に、人の承認を経由させています。記憶を git に置く設計は、この 1行があって初めて、git に書いてあることを信用してよい設計になります。
消えてよい物と消えてはならない物
接続先ごとに、何が消えて何が残るかは違います。
- GitHub: プロキシがホスト登録のトークンを注入する。clone・push・PR・Issue はサンドボックスを作り直しても何も要らない
- X: 読み取りは公式 MCP、投稿は自作 bot の投稿口で、どちらもトークンはホスト側が保持し、サンドボックスから見えるのは道具だけ。作り直した後はホストで読み込みの 1コマンドを打つだけで、再認証は要らない
- AWS CloudWatch: 読み取り専用の IAM プロファイルでホスト側のサーバーが動き、鍵はサンドボックスに入らない
runbook.md には、消えてよい物として、サンドボックス内の自動メモリ、リポジトリの clone、環境変数ファイルへの追記の3つを明記しています。認証情報がサンドボックスに入らないのは、この置き場所設計の副産物です。X のトークンも bot のトークンも AWS の鍵も、いずれもホスト側にあり、サンドボックスの中のエージェントはどれも持ちません。持たない物を最初から作らないからこそ、サンドボックスは気兼ねなく作り直せます。