AIに「前に決めたこと」を任せる。Claude CodeとObsidianの記憶設計

記録を増やすほど、迷うことも増える

AIに過去のことを覚えてほしいと思うと、つい情報をたくさん渡したくなります。メモを集め、会話を保存し、資料をつなぐ。それで検索できる範囲は広がりますが、現在の決定まで明確になるとは限りません。

先ほどの例で、「初心者向け」は以前の方針、「実務者向け」はまだ採用していない案、「経営者向け」は一度だけの特集企画だったとしたら。日付の新しい文章を見つけても、それを次回に適用してよいかは別の問題です。

ここで整えたいのは、「何を覚えさせるか」に加えて、「何を判断の根拠として読ませるか」です。仕事に使うAIの記憶は、量を増やす前に参照先を設計する。この順番を提案したいと思います。

そのための小さな構成が、「正本1か所＋地図1枚」です。採用中の方針を確認する場所を決め、そこへ辿り着くための短い索引を置く。Claude CodeとObsidianの組み合わせは、この構成を試す選択肢になります。

つなぐ土台は、もうファイルの中にある

Obsidianのノートは、ローカルのフォルダに保存されるMarkdownファイルです。「保管庫（vault）」という名前ですが、特別な形式の箱ではありません。別のエディタで編集した変更もObsidianに反映されます。

一方、ローカルで使うClaude Codeには、作業フォルダ内のファイルを読む機能があります。対象の保管庫にアクセスできる環境を用意すれば、専用プラグインを追加しなくてもノートの参照を始められます。

最初の依頼は短くて構いません。「このノートを読み、要点と参照したファイル名を答えて。ファイルは変更しない」。自分が内容を知っているノートで、きちんと読めるかを確かめます。

外部のツールやデータをAIにつなぐMCPという仕組みもあります。ただ、Markdownを読むための必須条件ではありません。まず直接参照で試し、足りない操作が見えてから接続を増やす。そのほうが、自分に必要な構成を見極めやすくなります。

正本を決める。すべてを引っ越さなくていい

記事づくりなら、「記事方針.md」を採用中の方針の置き場所にします。対象読者は誰か。いつから適用するか。例外はどう扱うか。会議で交わした意見のすべてではなく、現在の判断を確認できる内容を残します。

会議メモや以前の企画書は、そのまま残して構いません。後から経緯を知りたいときには必要です。ただし、古い案と現在の決定が同じ立場で並ばないように、採用状況と正本への参照先を示します。

「正本1か所」は、全情報をObsidianへ移すという意味ではありません。顧客情報はCRM、チームの規程は社内文書、自分の記事方針はObsidian。情報の種類ごとに正式な参照先が決まっていればよく、すでに管理できている場所を壊してまで集約する必要はありません。

また、Claude Codeの自動メモリは、正式な方針とは分けて考えます。自動メモリにはClaudeが学んだ傾向などが記録され、人が書くCLAUDE.mdには継続的な指示を置けます。いずれも作業を助ける文脈であり、業務上の決定を承認する仕組みではありません。

AIが「記事は短いほうが好まれる」と覚えていても、今回の企画が長編インタビューなら企画の要件を確認する。AIが書いたか、人が書いたかだけでなく、何が確定していて、どこまで適用できる情報かを分けることが大切です。

地図は、全部を載せないから役に立つ

正本が決まったら、入口となるノートを一枚つくります。役割は、何を知りたいときにどこを開くかを案内すること。記事づくり用なら、たとえば次のような内容です。

記事の対象読者・編集基準 → policies/記事方針.md 今回の企画の目的と例外 → projects/今回の企画.md 過去の判断に至った経緯 → decisions/ 検討中のアイデア → inbox/（確定した方針とは区別する）

ここに全ノートを並べたり、方針の本文をコピーしたりする必要はありません。地図にも同じ情報を書くと、正本を直すたびに二つの場所を更新することになります。よく使う正本と、そこから先を探す入口に絞ります。

CLAUDE.mdには、その地図をどう使うかを書きます。「方針に関する依頼では入口から該当する正本を確認する」「回答に参照したファイル名を添える」「食い違いがあれば確認する」。知識を詰め込むより、確かめられる指示を短く置く考え方です。

CLAUDE.mdの読み込みは配置によって異なるため、実際にこの入口が参照されるかも試します。公式ドキュメントも指示を短く保つことを勧めています。読むノートを二枚まで、と固定する必要はありません。方針と例外が別なら、その両方を読んでもらいます。

すると、AIへの依頼も変えられます。「記事方針と今回の企画を確認して、構成案を出して。対象読者が食い違うなら、先に教えて」。欲しいのは、もっともらしい構成案だけではありません。「通常は実務者向けだが、今回は経営者向けとある。例外として進めてよいか」と、判断すべき点が見える回答です。

「正しく答えたか」に加えて、「直せるか」を見る

この構成でも、AIは読み落とすことがあります。正本そのものが古い場合もあります。それでも参照先が分かれば、どこから食い違ったかを辿れます。

古い方針が残っていたなら正本を直す。違う記録を読んでいたなら地図を見直す。例外を見落としていたなら、依頼や指示を調整する。プロンプトを何度も書き直すだけでなく、原因に応じて手を入れる場所を選べます。

維持するために、最初から大がかりな自動化は要りません。方針を変えたら適用日と理由を残し、地図の参照先も確かめる。ファイルの更新日時だけでは、誤字を直したのか、方針が変わったのかまでは分からないからです。ノートが増えて負担になったら、リンク切れなど機械的に確かめられる部分から自動化を考えます。

今日試すなら、毎週の記事企画など、繰り返す仕事を一つ選んでください。その仕事の正本と入口を用意し、答えを知っている質問を三つ投げます。

1. 通常の対象読者は誰か。 2. 今回だけの例外はあるか。 3. まだ決まっていないことは何か。

答えだけでなく、参照した記録が正しいか、不明なことを不明と言えたかまで見ます。うまくいけば、次の仕事へ広げれば十分です。

「前に決めたこと」を毎回説明し直さず、必要なときに根拠へ戻れる。間違いがあれば、戻って直せる。そんな状態を一つの仕事でつくることから、第二の脳は日々の仕事に近づいていきます。

技術的な参照資料

• How Obsidian stores data — Obsidian
• How Claude remembers your project — Anthropic
• Configure permissions — Anthropic
• Connect Claude Code to tools via MCP — Anthropic

機能の説明は公式資料、正本と地図の構成はそれを踏まえた運用提案です。利用環境やバージョンによって挙動は異なります。