どんな問題があったかというと
AI コーディングエージェントとのセッションは、終わった瞬間に蒸発します。 その日下した判断も、詰まった箇所も、どう突破したかも、「次からはこうしよう」という決意まで全部です。
会話ログが残っていてもあまり役に立ちません。数万トークンの原文は検索もできませんし、読み返されることもないからです。
/agent-memory-log はこの問題を解くスラッシュコマンドです。セッションを構造化された Markdown ノートに要約して、Obsidian ベースの AgentMemory ボルトへ入れてくれます。
何を残すかというと
原文のログをそのまま放り込むことはしません。「どういう種類の知なのか」で分けて整理します。だからノートのセクションが固定されています。
- 作業要約 — このセッションで何をしたか 1〜3 文で
- 変更ファイル — 実際に触ったファイルの一覧
- 重要な判断 — なぜその方式を選んだのか
- 詰まった点 / 解決 — デバッグして得られたもの
- 学んだ点 — 次のセッションへ渡す知識
- 次から適用するルール候補 — 習慣にできそうなもの
セクションを固定した理由は単純です。あとで複数のセッションノートを機械的にさらうとき（要約パイプラインや昇格作業など）、どこに何があるか予測できる必要があるからです。毎回形式が違うと、人も道具も読めません。
設計で気を配ったこと
同じ日に何度も保存したら
ノートのパスは 10-sessions/claude/{日付}-claude-{プロジェクト}.md です。では、同じ日に同じプロジェクトで二度、三度保存したらどうなるでしょう。
CLI が既存のファイルには一切触れずに -2、-3 といった接尾辞を付けて新しいファイルを作ります。以前は既存ノートを一旦どかして戻す方式で処理していたのですが、途中で失敗すると復旧できませんよね。今はそういうことが起きません。
フック自動保存をやめた理由
最初はセッション終了時に自動保存していました。便利そうでしたから。
でも使ってみると、すべてのセッションに記録する価値があるわけではないと分かりました。誤字を一つ直しただけのセッション、ファイルを読んだだけのセッションまで全部ノートになって、ボルトがあっという間にゴミで埋まりました。本当に必要なノートを探すのが逆に難しくなったんです。
なので今はこちらが頼んだときだけ動きます。
パイプラインのどこにいるかというと
このコマンドは [記録 → 知識 → 記事] という流れの最初の段階です。
ここに溜まったセッションノートと日次 TIL が、次の段階である /til-to-knowledge の入力になります。そこでプロジェクト固有の事情を取り除き、どこでも通用する知識へ昇格させるわけです。
学んだ点
記録システムの価値は、「書くコスト」ではなく「もう一度読まれる確率」 が決めます。
構造を固定したのも、衝突を防いだのも、ゴミを作らないと決めたのも、結局は再読の確率を上げるための仕掛けでした。どれだけ熱心に書いても、読み返されないノートは書かなかったのと同じですから。