課題と背景
AI コーディングエージェントとのセッションは、終わった瞬間に蒸発する。その日に下した決定、詰まった箇所、解決方法、「次からはこうしよう」という決意まで、すべて。会話ログが残っていても、数万トークンの原文は検索も再利用も難しい。
/agent-memory-log は、この課題を解くスラッシュコマンドだ。セッションが終わるとき（正確にはユーザーが望むとき）に、現在のセッションを構造化された Markdown ノートへ要約し、Obsidian ベースの AgentMemory ボルトに蓄積する。
何を残すのか
原文ログではなく、エピステミックな階層として整理した要約を残す。ノートは固定されたセクション構造を持つ。
- 作業要約 — このセッションで何をしたかを 1〜3 文で
- 変更ファイル — 実際に手を入れたファイルの一覧
- 重要な決定 — なぜその方式を選んだのか
- 詰まった点 / 解決 — デバッグの過程で得られたもの
- 学んだ点 — 次のセッションに引き継ぐ知識
- 今後適用するルール候補 — 習慣へ昇格させるに値するもの
セクションを固定した理由は単純だ。あとで複数のセッションノートを機械的に走査するとき（digest、昇格パイプライン）、どこに何があるかを予測できる必要があるからだ。
設計で気を配ったこと
同日の衝突処理
ノートのパスは 10-sessions/claude/{日付}-claude-{プロジェクト}.md だ。1 日に同じプロジェクトでセッションを複数回保存すると、CLI は既存ファイルに触れずに -2、-3、… の接尾辞で新しいファイルを作る（uniqueFilePath）。以前のセッションを stash/mv/復元する必要はない。
フックではなく手動実行
最初はセッション終了フックで自動保存していたが、今は明示的な要求時のみ実行する。すべてのセッションが記録する価値を持つわけではなく、自動保存はノイズノートを量産し、ボルトの信号対雑音比を下げてしまった。
パイプラインでの位置
このコマンドは［記録 → 知識 → 記事］パイプラインの最初の段階だ。ここで蓄積されたセッションノートと日々の TIL が、次の段階である /til-to-knowledge の入力となり、プロジェクト固有の事情が取り除かれた汎用的な知識ドキュメントへ昇格される。
学んだ点
記録システムの価値は「書くコスト」ではなく「再び読まれる確率」が決める。構造を固定し、衝突を防ぎ、ゴミを作らないこと — この 3 つはいずれも、再び読まれる確率を上げるための仕掛けだ。