Obsidian + ClaudeCodeで、やり取りを「記憶」として残す仕組みを作った
Obsidian + ClaudeCodeシリーズの続き。
これまで、Claudianプラグインを入れ、
obsidian-skillsを配置し、
Obsidianの中でClaudeCodeと対話できる環境を整えた。
毎日使っているうちに、次に欲しくなったものがある。
セッションをまたいで「記憶」を残す仕組み。
ClaudeCodeを日常的に使っていると、ある問題が。
セッションが終わると、そこまでのやり取りで得た知見が、次のセッションに引き継がれにくいこと。
「このツールはこう使うとうまくいく」
「この手順だとエラーになる」
セッション中に発見したことを、次のセッションでもそのまま活かしたい。
とはいえ、残す手段はちゃんと用意されてはいる。
ClaudeCodeには、自分で書くCLAUDE.mdと、Claude側が自分で書き貯めていく自動メモリという2つの仕組みがあって、どちらも毎セッションの開始時に読み込まれる。
CLAUDE.mdにプロジェクトの規約を書き、自動メモリに任せておけば、ある程度は勝手に記憶が積み上がっていく。
ただ、残せばいいというものでもない。
CLAUDE.mdも自動メモリもコンテキストとして毎回読み込まれるってことは、その分、毎回トークンを消費するってこと。
公式ドキュメントにも「CLAUDE.mdは1ファイル200行以下を目標に。大きくなるほど従う精度も下がる」と。
つまり、残しすぎると逆にClaudeが鈍くなる。
さらに、CLAUDE.mdに書くのは「確定したルール」で、自動メモリはClaudeが自動で拾う「学習」。
その中間にある、「今日のセッションで自分が気づいたこと」「試してダメだった具体的な手順」のような、自分の言葉で整理したい流動的な知見を置く場所が、どちらにもない。
書けなくはないが、書き続けるとすぐ肥大化する。
この「確定でもなく、自動でもない部分」をどう扱うか？
答えは、意外なところから見つかった。
Anthropic社員がやっていた「Task Diary」
きっかけは、Zennで見つけた記事。
Anthropic社員がClaudeCodeをどう使っているかを、公式情報からまとめたもので、8つのテクニックが紹介されていた。
その中のひとつが「Task Diary」。
やり方はシンプルで、タスクが完了するたびにClaudeCodeに「日記エントリ」を書いてもらう、というもの。
何を試みたか？
何がうまくいったか？
何が失敗したか？
その理由は何か？
これをセッションごとに記録していく。
蓄積された日記をあとから分析し、共通パターンが見つかればCLAUDE.mdに昇華させる。
記事ではこれを「複利的エンジニアリング」と呼んでいた。
使えば使うほど、環境が賢くなっていく構造。
読んだ瞬間、「これ、今日作ろう」と。
読んだその日にコマンド化した
ClaudeCodeには「カスタムスラッシュコマンド」という仕組みがある。
`.claude/commands/` にMarkdownファイルを置くだけで、`/コマンド名` で呼び出せるようになる。
中身は自然言語で書いた手順書のようなもので、ClaudeCodeはそれに従って動いてくれる。
「Task Diary」コマンドは、こんな構成
セッション終了時に `/task-diary` と打つと、Claudeがその日の会話を振り返って、4つの観点で学びを抽出する。
うまくいったこと ── 有効だった手法やアプローチ
うまくいかなかったこと ── 失敗や障壁、回避策が必要だったもの
発見 ── 新しくわかった仕様や制限
次回への申し送り ── 中断したタスクや今後試したいこと
抽出した学びは、Obsidian内の専用ノートに日付つきで追記される。
CLAUDE.mdのような「確定ルール」ではなく、「今日わかったこと」の生ログが時系列で積み上がっていく形。
記事を読んでから、コマンドの作成と最初の記録まで、サクッと同じセッション内で完了。
実際に運用してみて
初回の記録がこの仕組みを作った日のもの。
内容はこんな感じだった。
うまくいったこと：記事の知見からTask Diaryを即実装できた
うまくいかなかったこと：Google Keep MCPのマスタートークン取得で詰まった
発見：Claude CodeのRemote Controlは現時点でmacOSのみ
次回への申し送り：markitdown MCPの設定修正がユーザー側の手動作業として残っている
読み返すと、その日に何をやっていたかが一目で。
この日は設定的なことばかりやってたってのもよく分かる。
特に価値を感じるのは「うまくいかなかったこと」と「発見」の欄。
成功した手順はなんとなく覚えていても、「これは試したけどダメだった」という情報は忘れやすい。
次のセッションで同じことを試して同じエラーにぶつかる、という無駄がほぼ無くなった。
「読む → 即作成」が出来た理由
振り返ると、記事を読んでからコマンド化までが速かった理由が2つ。
ひとつは、ClaudeCode自体が「コマンドを作る」ハードルを圧倒的に下げていること。
プログラムを書く必要はない。
Markdownで手順を書いてフォルダに置いてと頼むだけ。
自然言語で「こういう観点で振り返って、こういう形式で書いて」と指示すれば、それがそのままコマンドになる。
もうひとつは、「記録先がすでにあった」こと。
Obsidianで日常的にメモを取っているから、新しい記録先ノートを1つ追加するだけで済んだ。
既存の運用フローの中にTask Diaryがすっと収まった。
ツールの導入で一番コストが高いのは、「習慣を変える」部分だと思う。
今回は習慣を変える必要がなかった。
セッション終了時にコマンドをひとつ打つだけ。
たったそれだけで知見が蓄積されていく。
知見はいつCLAUDE.mdに昇華するか
Task Diaryのコマンドには、こんな一文を入れてある。
学びが5件以上蓄積されたら、共通パターンをCLAUDE.mdに反映することを提案する
まだこの閾値に達してはいないが、すでにパターンは見え始めている。
たとえば「Vault外のコマンドパスはサンドボックスにブロックされる」という発見が複数回記録されている。
これは個別のセッションの学びではなく、環境の制約として確定している知識というか、そう設定して、なるべくobsidian内だけで操作するということを心がけているため。
CLAUDE.mdに書くべき情報である。
こんな感じで、Task Diaryは「流動的な学び」と「確定したルール」の間にあるバッファとして機能している。
毎セッション雑に記録して、パターンが見えてきたら昇華って流れ。
外山滋比古 著『思考の整理学』内に出て来る、「メタ・ノート」に似た構造かも知れない。
まとめ
Anthropic社員の実践から学んだTask Diaryを、読んだその日にClaudeCodeのカスタムコマンドとして実装。
やったことは3つだけ
コマンド定義のMarkdownファイルを作成（4つの観点で学びを抽出する手順書）
記録先のObsidianノートを作成（時系列で追記していくだけのシンプルな構造）
セッション終了時に `/task-diary` と打つ習慣をつける
もちろん、実際に自分でファイルやフォルダを作成したのでは無く、全てObsidian内のClaudianからClaudeCodeに作ってって頼んだだけ。
もし、作ってみたい場合は、このページのURLをコピペして、「Task Diaryってコマンド作って」とClaudeCodeに頼めばやてくれるはず。
技術的にはごく簡単なことだが、効果は想像以上に大きい。
「前にこれ試してダメだったんだよな」という記憶が、ちゃんと文字で残っている安心感。
AIツールの活用術は、読んで「なるほど」で終わりがち。
しかし、ClaudeCodeのカスタムコマンドは「なるほど」から「動くもの」までの距離がとても短い。
「〇〇ってコマンドが作りたい」と頼むだけ。
気になったテクニックがあったら、その日のうちにコマンドにしてしまう。
合わなければ消せばいい。
この「軽さ」が、ObsidianとClaude Codeの組み合わせの一番の強み、なのかも知れない。
