Claude Code の自動メモリと Obsidian：検証できる文脈の保存方法

個人の仕事上の好みなら、Claude Code の auto memory から始めると便利です。チームで議論し、別のツールにも移す決定事項には、責任者と出典を記した独立した Markdown メモが向いています。Obsidian はその保存場所のエディターとして使えます。ただし、インストールするだけでメモがエージェントにつながるわけではありません。

すべての情報に一つの方法を選ぶ必要はありません。記録の正しさに誰が責任を持つかで文脈を分けます。例えば「短い回答が好み」は個人メモリに、「チームがレポートを新しいサービスに移行している」は決定へのリンクを付けた共有メモに置けます。現在のコードから確認できるパスやコマンドは、リポジトリで確認すると、余分な事実の複製を保守せずに済みます。

何が保存されるのか

Claude Code のドキュメントでは、auto memory はプロジェクトのローカル Markdown ファイルとして説明されています。/memory から開き、編集や削除ができます。同じ Git リポジトリの worktrees はメモリを共有しますが、マシン間で自動転送はされません。/context で読み込まれた memory files を確認できます。メモがディスクにあるだけでは、その内容が現在の会話に入った証明にはなりません。

Obsidian の vaultは、メモと設定を保存するフォルダーです。通常の Markdown ファイルはアプリの外でも利用できます。エージェントに使わせるには、読むファイルを別途指定し、アクセスを許可します。この方法に Obsidian プラグインや MCP サーバーは必要ありません。

確認事項	Auto memory	独立した Markdown vault
誰が記録を提案するか	作業中の Claude。人が確認する	メモの作者、または明示的に依頼されたエージェント
疑わしい事実を誰が直すか	プロジェクトのユーザー	決定事項の担当者
同僚に変更をどう見せるか	選んだ記録を明示的に渡す	ファイルや合意した Git diff を渡す
別のマシンへどう移すか	移行を別途手配する	フォルダーへのアクセスや同期を手配する
古い情報をどこで探すか	保存されたメモ	出典と次の見直し日

右の列は提案する運用です。Obsidian でフォルダーを開いても、Git、担当者、見直し期限は自動で設定されません。

メモリを検証するためのモデル接続を準備する

Claude Code で API を使って両方を試すなら、BetterToken の Anthropic-compatible 接続を利用できます。まず BetterToken の Claude Code ガイドに従い、自分の API Key と、/v1 を付けない Base URL https://bettertoken.ai を設定します。クライアントを再起動し、短いメッセージへの応答を確認してください。ここで確認するのはモデルへの接続です。その後の手順でメモの利用を検証します。

比較ではモデルと課題をそろえます。最初に記録を読ませ、次に変更し、新しい会話で同じ質問を繰り返します。接続の変更を実験の追加変数にしないためです。BetterToken は API 呼び出しを提供し、auto memory と vault は引き続きツール側で管理されます。エージェントが読んだ部分はモデルへのリクエストに入る可能性があるため、機密情報のない学習用メモを使い、API Key は vault に保存しないでください。

BetterToken で Claude Code を設定し、一つのメモを検証するところから、次の例へ進みます。

一つの事実に一つの主な保存先を決める

機密情報のないメモ一件から始めます。例ではチームがエクスポート形式を検討しています。値と名前は架空です。decisions/report-export.md を保存します。

# Report export decision

Status: proposed
Owner: reporting-team
Verified: 2026-09-08
Review-by: 2026-09-22
Source: team decision record to be attached

The proposed export format is CSV.
This is not an approved production requirement.
Before implementation, ask the owner for the approved decision.

これで、提案と必須要件を区別できます。実際のプロジェクトでは、タスク、議事録、決定文書など、アクセスできる出典を示します。確認されていない間は、エージェントもその不確実性を維持すべきです。

新しい会話で具体的に依頼します。

Read decisions/report-export.md.
What export format is proposed, and is it approved for production?
Cite the file and identify the missing evidence.
Do not change code or infer approval from the proposal.

期待する答えは「CSV が提案されているが、production approval はなく、決定の出典が必要」です。これは検証基準であり、モデルが正答する保証ではありません。「CSV を実装すべき」と答えた場合は、読んだファイルと引用先を確認します。重複メモ、古い会話、ステータスの誤解が原因かもしれません。

更新と削除を検証する

学習用メモの形式を JSONL に変更し、ステータスは proposed のままにします。新しい会話で同じ質問をします。エージェントは JSONL と従来の制限を答えるべきです。CSV が返る場合は、矛盾するルールを追加せず、古い値の出典を探してください。

次に通常のファイルマネージャーで学習用メモを削除し、さらに新しい会話で、承認済みの形式決定がどこにあるかを尋ねます。他の出典がなければ、情報不足を伝える回答が有用です。古い値が返るなら、別の複製や出典が残っています。/memory、プロジェクトファイル、指示を確認するきっかけになります。

メモを削除しても、Git history、バックアップ、同期デバイス、開いている会話から自動で消えるわけではありません。このテストは新しい会話の動作を調べるもので、データの完全消去ではありません。API keys、パスワード、個人情報を練習に含めないでください。

誤りの影響に合わせて運用を選ぶ

一人で作業し、メモリの中心が好みであれば、auto memory を使い続け、プロジェクトの大きな変更後に記録を確認します。事実がチームの行動を左右する場合は、主な版を管理された文書に移します。auto memory には決定を複製せず、最新の出典を探す場所を残せます。

必要なら /memory で auto memory を無効にできます。公式の autoMemoryEnabled パラメーターがこの機能を制御します。無効化は、既存ファイルや読み込み済み文脈の確認を代替しません。

チームの vault では、重要な記録に担当者と見直しの契機を決めます。API の変更、プロジェクト中止、移行完了などです。日付は忘れられたメモの発見に役立ちますが、自動の有効期限は生みません。Git を使うなら commit 前に対象ファイルを確認し、個人設定や添付ファイルを含むフォルダー全体を追加しないでください。

一つの決定について、新しい会話で三つを尋ねるところから始めます。何が分かっているか、何が変わったか、何が確認できなくなったか。答えが最新のファイルを引用し、不確実な状態を維持できれば、その保存方法は目的を果たしています。できなければ出典と読む順序を先に直してください。エディターを替えるだけでは矛盾は解消しません。