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のような「確定ルール」ではなく、「今日わかったこと」の生ログが時系列で積み上がっていく形。

記事を読んでから、コマンドの作成と最初の記録まで、サクッと同じセッション内で完了。

実際に運用してみて

初回の記録がこの仕組みを作った日のもの。

内容はこんな感じだった。

読み返すと、その日に何をやっていたかが一目で。

この日は設定的なことばかりやってたってのもよく分かる。

特に価値を感じるのは「うまくいかなかったこと」と「発見」の欄。

成功した手順はなんとなく覚えていても、「これは試したけどダメだった」という情報は忘れやすい。

次のセッションで同じことを試して同じエラーにぶつかる、という無駄がほぼ無くなった。

「読む → 即作成」が出来た理由

振り返ると、記事を読んでからコマンド化までが速かった理由が2つ。

ひとつは、ClaudeCode自体が「コマンドを作る」ハードルを圧倒的に下げていること。

プログラムを書く必要はない。

Markdownで手順を書いてフォルダに置いてと頼むだけ。

自然言語で「こういう観点で振り返って、こういう形式で書いて」と指示すれば、それがそのままコマンドになる。

もうひとつは、「記録先がすでにあった」こと。

Obsidianで日常的にメモを取っているから、新しい記録先ノートを1つ追加するだけで済んだ。

既存の運用フローの中にTask Diaryがすっと収まった。

ツールの導入で一番コストが高いのは、「習慣を変える」部分だと思う。

今回は習慣を変える必要がなかった。

セッション終了時にコマンドをひとつ打つだけ。

たったそれだけで知見が蓄積されていく。

知見はいつCLAUDE.mdに昇華するか

Task Diaryのコマンドには、こんな一文を入れてある。

まだこの閾値に達してはいないが、すでにパターンは見え始めている。

たとえば「Vault外のコマンドパスはサンドボックスにブロックされる」という発見が複数回記録されている。

これは個別のセッションの学びではなく、環境の制約として確定している知識というか、そう設定して、なるべくobsidian内だけで操作するということを心がけているため。

CLAUDE.mdに書くべき情報である。

こんな感じで、Task Diaryは「流動的な学び」と「確定したルール」の間にあるバッファとして機能している。

毎セッション雑に記録して、パターンが見えてきたら昇華って流れ。

外山滋比古 著『思考の整理学』内に出て来る、「メタ・ノート」に似た構造かも知れない。

まとめ

Anthropic社員の実践から学んだTask Diaryを、読んだその日にClaudeCodeのカスタムコマンドとして実装。

やったことは3つだけ

1. コマンド定義のMarkdownファイルを作成（4つの観点で学びを抽出する手順書）

2. 記録先のObsidianノートを作成（時系列で追記していくだけのシンプルな構造）

3. セッション終了時に `/task-diary` と打つ習慣をつける

もちろん、実際に自分でファイルやフォルダを作成したのでは無く、全てObsidian内のClaudianからClaudeCodeに作ってって頼んだだけ。

技術的にはごく簡単なことだが、効果は想像以上に大きい。

「前にこれ試してダメだったんだよな」という記憶が、ちゃんと文字で残っている安心感。

AIツールの活用術は、読んで「なるほど」で終わりがち。

しかし、ClaudeCodeのカスタムコマンドは「なるほど」から「動くもの」までの距離がとても短い。

「〇〇ってコマンドが作りたい」と頼むだけ。

気になったテクニックがあったら、その日のうちにコマンドにしてしまう。

合わなければ消せばいい。

この「軽さ」が、ObsidianとClaude Codeの組み合わせの一番の強み、なのかも知れない。