Claude Code知識管理はObsidianが最適？Markdown運用を選んだ理由
Claude Codeを使い込むほど重要になるのが「知識管理」です。セッションが終わるたびにコンテキストが消え、毎回ゼロから説明し直す——この問題を解決するために、最近注目されているのがObsidianとの連携です。
Karpathy氏やJerry Liu氏（LlamaIndex創業者）が提唱する「AIの出力をObsidianに蓄積して第二の脳を作る」手法は、X上でも大きな反響を呼んでいます。私もこの手法を検討しましたが、最終的にプロジェクト内Markdown管理を選びました。
この記事では、ObsidianアプローチとMarkdown管理の両方を比較し、実務での判断基準を解説します。
なぜAIの知識管理が重要なのか
Claude Codeのアウトプット品質は、与えるコンテキストの質に直結します。同じプロンプトでも、過去の実績データや業務ルールを持たせた状態と、何も持たせない状態では結果が全く違います。
私の実感では、知識管理を整備する前と後で決定的な変化がありました。
- 整備前：セッション間でコンテキストがほぼ引き継がれず、毎回同じ説明を繰り返していた
- 整備後：プロジェクトを開いた瞬間から、事業の方針・実績・執筆ルールを理解した状態で作業が始まる
この「コンテキストの持続性」をどう実現するかが、Obsidian派とMarkdown派の分かれ道です。
Obsidianアプローチの特徴
Karpathy氏やJerry Liu氏が提唱するのは、AIの出力（MarkdownやHTML）をObsidianのVaultに保存し、ナレッジグラフとして可視化する手法です。
- 双方向リンク：ノート同士を[[リンク]]で繋ぎ、知識の関連性を構造化できる
- グラフビュー：蓄積した知識を視覚的に俯瞰できる
- プラグインエコシステム：AI連携プラグインでClaude Codeとの橋渡しが可能
- ローカルファースト：データがローカルに保存されるためセキュリティ面で安心
特にJerry Liu氏のアプローチは、AIのセッション出力をファイルとして保存→Obsidianでナレッジベース化するもので、AI活用の知見を体系的に蓄積できる点が魅力的です。
プロジェクト内Markdown管理の特徴
私が選んだのは、プロジェクトのGitリポジトリ内にdata/フォルダを設け、Markdownファイルで知見を蓄積する方法です。
- Git管理：変更履歴が自動的に残る。いつ何が追加・変更されたかが追跡可能
- Claude Codeが直接読み書き：外部ツールを介さず、Claude Code自身がファイルを読み書きできる
- Skills・ルールファイルとの一体運用：CLAUDE.md→rules/→data/→skills/が同じリポジトリ内で完結する
- 複数端末での同期：GitHubプライベートリポジトリ経由で、自宅Mac・外出先ノートPC・オフィスPCすべてで同じ知識にアクセスできる
私の場合、以下のような構造で運用しています。
- 実績・経験データベース：案件実績・エピソード・「この人しか書けない」要素
- AIツール知見データベース：ツール使用体験・比較知見・活用哲学
- learnings/（月単位）：日々の一時的な知見蓄積→月末に正式DBへ昇格
- rules/：記事執筆・コーディング・ビジネスコンテキストのルール
私がObsidianを選ばなかった3つの理由
Obsidianアプローチを検討した上で、最終的にMarkdown管理を選びました。その理由は3つあります。
1. 外部ツールのフォーマットに縛られる
過去にNotionやObsidianとの連携を試しました。しかし、各ツール固有のフォーマットに合わせる必要があり、コンテキスト保持の形式を自由に決められないという壁に直面しました。
Claude Codeが最もスムーズに扱えるのは、プロジェクト内のプレーンなMarkdownファイルです。余計な変換レイヤーがない分、読み書きの精度が上がります。
2. CLAUDE.mdの肥大化リスクを回避できる
CLAUDE.mdへの記載量が一定以上になると、コンテキスト量の増加により逆に作業精度が下がるという報告があります。
プロジェクト内Markdown管理では、CLAUDE.mdは「目次」として最小限に保ち、詳細はdata/やrules/に分散させます。Claude Codeは必要な時だけ該当ファイルを読みに行くため、常に全知識をロードする必要がありません。
3. Skillsとの相乗効果
繰り返す業務（SEO記事執筆、レポート生成など）はSkill化しています。Skillファイルがdata/内の知見DBを直接参照する設計にしているため、知識蓄積とタスク実行が同じリポジトリ内で完結します。
Obsidianで知識を管理する場合、Skillファイルからの参照パスが複雑になり、運用コストが上がると判断しました。
運用フロー — learningsから正式DBへの昇格
日々の知見蓄積は以下のフローで回しています。
- 日常：セッション中に得た知見をlearnings/YYYY-MM.mdに蓄積（tech / business / feedback 等で分類）
- 月末棚卸し：重要なものは正式ファイル（実績DB・知見DB・ルールファイル）に昇格、不要なものは削除
実際に昇格させた例として、SEO記事執筆で蓄積したノウハウがlearningsに溜まり、それが記事執筆ルール（article-writing.md）に昇格しました。「全てを保存するのではなく、本当に価値のある知見だけを正式DBに残す」ことが品質維持の鍵です。
このフローは最初から完成形だったわけではありません。セッション間のコンテキスト引き継ぎを見ながら微調整を重ね、現在の形に落ち着きました。
どちらが向いている？判断基準
Obsidianが向いている場合：
- 複数プロジェクト横断で知識を管理したい
- 視覚的に知識の関連性を把握したい（グラフビュー）
- チームで知識を共有する必要がある
プロジェクト内Markdownが向いている場合：
- Claude Codeの精度を最大化したい
- Skillsやルールファイルと一体運用したい
- Git管理の恩恵（履歴追跡・複数端末同期）を受けたい
私の場合、1人で複数プロジェクトを回す経営スタイルのため、プロジェクト単位で完結するMarkdown管理が最も効率的でした。チームで知識を共有する場合は、Obsidianの方が適しているかもしれません。
重要なのは「どのツールを使うか」ではなく「AIに何を覚えさせ、何を忘れさせるか」の設計です。知識管理の本質はツール選択ではなく、情報の取捨選択にあります。
Claude Codeのナレッジ管理の仕組みについて、さらに詳しくは以下の記事で解説しています。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。