【AI開発】AI に「育つ記憶」を持たせる ― Claude Code × Obsidian × memory で作る個人ナレッジ環境

TL;DR — 個人の知見を Markdown ファイル（Claude Code の memory）に蒸留して貯め、人間は Obsidian で眺め、Claude Code は同じファイルを直接読み書きする。Obsidian は後付けできる「ただのビューア」で MCP も常駐も不要。作業の型は再利用可能な「スキル」に、全プロジェクト共通の好みは常時ロードされる設定ファイルに置く。ひとつの Markdown 知識ベースを、人間と AI が別々の入口から触るのが肝。

はじめに：AI は優秀だが、毎回忘れる

コーディング支援 AI は賢くなったが、根本的な弱点がある——セッションをまたぐと忘れる。前回ハマった落とし穴、プロジェクト固有の判断、「自分はこう進めてほしい」という好み。毎回説明し直すのは消耗する。

一方で「全部メモに残す」と、今度はノイズで埋もれる。会話ログを丸ごと保存しても、次に効く知見は埋もれてしまう。

この記事は、その間を狙った個人ナレッジ環境の作り方の記録だ。中核は Claude Code の個人 memory（.md ファイル群）。そこに Obsidian という閲覧窓と、作業の型を貯めるスキルを組み合わせる。

全体像：ひとつの知識ベースに、2つの入口

memory（.md ファイル群）= 実体・保管庫
├─ Claude Code が触る側 : Read / Write / Edit / Grep でファイルを直接読み書き（MCP不要）
└─ 人間が触る側          : Obsidian でグラフ・バックリンク・全文検索

スキル（~/.claude/skills/）   = AI の「作業の型」（全プロジェクト共通）
グローバル CLAUDE.md          = 全プロジェクト共通の指示・好み（常時ロード）

ポイントは、知識の実体はあくまで Markdown ファイルで、Obsidian も AI もそれを「別の入口から」触っているだけ、という点だ。

なぜ Obsidian は「後付けのレンズ」でいいのか

Obsidian の使い方には2つのモードがある。この環境は A モードを選んだ。

A モードなら Obsidian 連携用の MCP は要らない。Claude Code は素の Read/Write/Edit/Grep で完結し、Obsidian が起動していなくても動く。配線が少ないほど壊れにくく、保守もゼロに近い。

Obsidian は AI のためではなく、人間のための道具だ。AI 目線では直接の恩恵はなく、「人間が知識ベースを健全に保ちやすくなる」という二次効果で間接的に効く。

Vault の作り方：データは動かさず、symlink で集約する

知識ベースの本体は AI の memory フォルダに据え置き、Obsidian は symlink 越しに覗くだけにする。

~/vault/                    ← Obsidian で開く Vault
└── <repo>  →  ~/.claude/projects/<repo>/memory   (symlink)
                  ↑ 本体はここ。データは動かさない

# 1. Obsidian を入れる
brew install --cask obsidian

# 2. Vault を作り、プロジェクトの memory を symlink で集約
mkdir -p ~/vault
ln -sfn ~/.claude/projects/<repo>/memory ~/vault/<プロジェクト名>

# 3. Obsidian で ~/vault を "Open folder as vault" で開く
#    → グラフ・バックリンク・検索が全プロジェクト横断で効く

設計上のこだわり：

• データの本拠地は AI の memory 側に固定する。設定でデータの保存先をリダイレクトはしない（データの住所が設定に結合すると脆くなる）。
• 新しいプロジェクトを足すときは ln -sfn <その memory パス> ~/vault/<名前> を1本足すだけ。
• Obsidian をやめても ~/vault/ を消すだけ。実データは無傷。

知識ベースの運用ルール

memory に何を保存するか

• ⭕ やりとりから蒸留した「将来も効く知見」（設計判断の背景、ハマりどころ、進め方の好み）
• ❌ 会話ログ／コード・git・既存ドキュメントを読めば分かること

「あとで grep して読めること」は保存しない。残すのは蒸留された判断だけ。

1原則＝1住所（重複を作らない）

知見の置き場所を、効く範囲で決める。

• 常に効く振る舞い・好み → グローバル CLAUDE.md（例：「フォーマット等の定型チェックは毎回確認しない」）
• 特定の作業中だけ効く判断 → スキル（例：レビュー姿勢 → レビュースキル）
• プロジェクト固有の事実 → そのプロジェクトの memory

ファイルの約束ごと

• slug = ファイル名の kebab 化（feedback_xxx.md → feedback-xxx）。これで [[wikilink]] の不一致が起きない
• frontmatter は name / description / metadata.type で統一
• MEMORY.md をインデックスにして、各ファイルへ1行リンク（セッション開始時に索引が読まれる）
• 関連ノートは [[slug]] で相互リンク（Obsidian のグラフ・バックリンクに効く）

作業の「型」をスキルにする

~/.claude/skills/ には、自分の仕事の型を貯める。プロジェクト固有の知識は入れない（それは各リポの memory へ）。

調査・レビュー系のスキルは、手順の冒頭で「関連 memory を確認する」よう組み込んである。AI が起動時に索引を受動的に思い出すのに加えて、作業時に能動的に参照する——二段構えにしておくと取りこぼしが減る。

余談：スキルは「育てる」もの

最初は知見保存・振り返り・タスク整理を /note /tune /next と3つに分けていた。だが運用してみると入口が似ていて混ざる。そこで1つの /retro（区切りの振り返り）に統合した。スキルは作って終わりではなく、実戦で重複や摩擦が見えたら畳むのが健全だと感じている。

設計判断 ― なぜそうしたか

• auto-memory はプロジェクト（git リポジトリ）単位でしか読まれない。全プロジェクト共通の auto-memory は存在せず、memory のサブフォルダも自動走査されない。
  → 汎用的な知見を全プロジェクトで効かせたいなら、memory の中で工夫するのではなく、常時ロードされる層（CLAUDE.md / スキル）へ昇格させる。
• Obsidian は後付けできるレンズにすぎない。本当の基盤は「知識ベースの構造＋リンク作法＋書き込みの型」であって、アプリではない。だからアプリを乗り換えても壊れない。
• 検証ファースト。方針を確定する前に一次情報（公式ドキュメント・実データ・git）で裏を取る。これにより「共有フォルダ案は仕組み上効かない」「ファイル名の不統一こそリンク切れの真因」といった事実を着手前に発見でき、手戻りを防げた。

これは何「ではない」か（限界）

過信しないために、カバーしない範囲も明記しておく。

• チーム共有の仕組みではない。 個人 memory は自分のマシンのみ。チームで共有する知識はリポジトリの wiki など別の場所へ。
• 会話ログのアーカイブではない。 残すのは蒸留した知見だけ。生のやりとりは残さない。
• Obsidian は必須ではない。 .md はエディタや grep でも読める。Obsidian はグラフ・バックリンク・検索が欲しい人向けの任意のレンズ。
• memory はプロジェクト単位。 別リポジトリでは別の memory になる。全プロジェクトで効かせたい知見は CLAUDE.md / スキルへ昇格する。
• 同時編集に注意。 Obsidian で開いたまま AI が同じファイルを書き換えると、反映ラグや競合が起きうる（同じファイルを同時に触らない運用で回避）。

まとめ

• 知識の実体は Markdown ファイル1つ。人間（Obsidian）と AI（直接読み書き）が別々の入口から触る。
• Obsidian は MCP も常駐も不要な後付けレンズ。壊れにくさと保守ゼロを優先した。
• memory には蒸留した知見だけ。効く範囲で置き場所を決める（1原則1住所）。
• 作業の型はスキルに育て、振り返り（/retro）で知見・型・タスクを定期的に仕分ける。

アプリや派手な連携が主役ではない。「何を残し、どこに置き、どう書くか」という運用の型こそが資産になる——というのがこの環境を作って得た一番の学びだった。