PKM

概要 本ガイドは、個人 Obsidian Vault を Claude Code に統合し、AI Agent が個人ナレッジを 読み取り・書き戻し の両方向で活用する循環構造を実装する手順をまとめる。シリーズ 5 記事の実装ステップを 5 段階のロードマップに整理した、再現用ピラー（土台）ガイド。 5 段階ロードマップ ステップ 1: Vault の機密性に対応した接続方式を選ぶ 方式 接続スコープ 特徴 A. グローバル MCP -s user 全プロジェクト共通。個人プロジェクト中心の人向け B. プロジェクト local MCP -s local（デフォルト） .claude/settings.local.json に gitignored で書く。機密プロジェクトに向く C. symlink .claude/knowledge/ Vault サブセットを安定パスで取り込む。CLAUDE.md からの参照を一貫させる 推奨: 方式 B + C のハイブリッド。symlink で安定パスを提供し、検索・走査は MCP を使う。 1 2 3 4 5 6 mkdir -p <proj>/.claude/knowledge ln -s ~/Documents/ObsidianVault/topics/nextjs <proj>/.claude/knowledge/nextjs echo ".claude/knowledge/" >> .gitignore claude mcp add -s local vault-readonly -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault ステップ 2: CLAUDE.md と Skills を階層別に配置 ~/.claude/CLAUDE.md: 全プロジェクト共通の Vault 参照ルール <proj>/CLAUDE.md: プロジェクト固有の参照ポイント（「個人 Vault がない人でも壊れない逃げ道」を明示する） ~/.claude/skills/: Vault 横断スキル（vault-search, vault-daily-log, summary-back-to-vault） <proj>/.claude/skills/: プロジェクト固有のワークフロー（decision-log など） ステップ 3: 書き戻し（writeback）の安全設計 書き込み用 MCP を読み取り用と分離し、inbox/ にしか書けない よう物理隔離する。 ...

Obsidian Vault を Claude Code に繋ぐ実践編 では、読み取り側（Vault → プロジェクト）の設定パターンを整理しました。本記事はその続編で、書き戻し（writeback）側（プロジェクト → Vault）の設計を扱います。 ここを設計しないと、Vault は「過去の自分が書いたノート集」のまま古びていきます。プロジェクトで詰まったこと・学んだこと・設計判断の根拠が Vault に還流して初めて、AI Agent が「3 ヶ月前のあの話、応用できないか？」を提案できるようになります。 書き戻し設計で外せない3つの原則 具体的なパターンに入る前に、絶対に外せないルールを確認します。 AI に Vault の正本（topics/ や projects/ の本文）を直接書かせない Obsidian の [[リンク]] 構造とノート間の整合は、人間が編集してきた歴史の積み重ねです。AI に直接書かせると、リンク切れ・重複ノート・タグ揺れが一気に発生します。 inbox/ を必ず噛ませる AI は ~/Documents/ObsidianVault/inbox/ にしか書かない。inbox/ は「下書き置き場」と割り切り、人間が後で内容を吟味して Vault 本体に統合します。 書き戻す対象は「リポジトリに収まらない知見」だけ コードや設計書はリポジトリの docs/ に書きます。Vault に書くのは、プロジェクトを跨いで再利用される可能性のあるメタ知識 だけです。 つまり「AI が inbox/ に下書きを溜める → 人間が週次レビューで Vault 本体に統合する」という二段階フローを基本形にします。AI は下書き工場、人間は編集長、という分業です。 permissions と MCP の分離設計 書き戻しを安全に行う最大のコツは、読み取り用 MCP と書き込み用 MCP を別サーバとして分離する ことです。前作で触れた permissions 設計 を一段深めます。 1 2 3 4 5 6 7 # 読み取り専用ルート: Vault 全体を grep / Read できるが書き込みは禁止したい claude mcp add -s local vault-readonly -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault # 書き込み用: inbox/ 限定で AI が書ける claude mcp add -s local vault-inbox -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault/inbox これに加えて、<proj>/.claude/settings.json 側で symlink 越しの書き込みを禁止しておきます（前作で作った <proj>/.claude/knowledge/ — Vault のサブセットを symlink した読み取り専用ディレクトリ — を経由する書き込みを塞ぐ目的）。 ...

Obsidian Vault 書き戻しの自動化 では、3 方式（Claude Code hooks / Git クライアントフック / GitHub Actions）の使い分けをまとめました。そこで「GitHub Actions は会話文脈が失われる・Vault に書けない」と書きましたが、これは cloud-hosted runner を前提にした話です。self-hosted runner（GitHub の job を手元のマシンで実行する仕組み）に切り替えると、その制約が一気に外れます。 本記事では、自宅 Mac を self-hosted runner にして、PR マージのイベント駆動で claude -p を ローカル文脈（Vault・Skills・CLAUDE.md・MCP サーバ）の中で動かし、Vault に直接書き戻す構成を解説します。ここでの「ローカル文脈」は 対話履歴ではなく、ファイルシステムに永続化された個人資産のセット を指す点に注意してください。シリーズ 5 部作の最終ピースです（思想編 → 読み取り側 → 書き戻し設計 → フック自動化 → self-hosted runner）。 なぜ self-hosted runner が正解になるか cloud-hosted Actions の最大の弱点は次の 3 点でした。 Vault が手元のファイルシステムにあるので、cloud runner からは見えない ローカルの MCP サーバ（vault-readonly / vault-inbox）に接続できない ローカルの Skills や CLAUDE.md が読めず、/summary-back-to-vault を呼べない self-hosted runner は「ジョブは GitHub のイベント駆動で立ち上がるが、実体は手元のマシンが処理する」というハイブリッドです。3 つの弱点がすべて解消します。 ...

開発者にとって、GitHubは事実上の「最強のナレッジベース」になりつつあります。Issue・PR・Wiki・Markdown ドキュメント — 仕事に必要な情報のほとんどがリポジトリの中で完結しており、コードの近くにドキュメントを置く「Docs as Code」のスタイルは、エンジニアリングとして極めて洗練されています。 それでも 2026 年に入ってから、「AI Agent + Obsidian」の組み合わせが開発者コミュニティでホットになり続けています。GitHub で完結しているなら無理に Obsidian を入れる必要はないはずなのに、なぜこれほど話題になるのか。本記事ではその違いを、特に AI Agent に渡せる「文脈の質」 という観点から整理します。 結論を先に書くと、すべてが構造化された「プロジェクト」単位で完結していて、現状の運用にストレスがないのであれば、無理に Obsidian を導入する必要はありません。ただし、「プロジェクトを跨いだ伏線回収」を AI にやらせたい瞬間が来ると、思想の違いが効いてきます。 GitHub方式とObsidian方式の決定的な違い 最大の違いは、情報の「繋がり方」の思想です。 比較軸 GitHub方式（プロジェクト管理型） Obsidian方式（ネットワーク型） 情報の構造 ディレクトリ構造（階層型・縦割り） グラフ構造（網の目型・横断的） 主な単位 リポジトリ / Issue / PR / Wiki ノート（アイディア、ファクト、ログなど） AIとの相性 コンテキストがプロジェクト内に閉じる プロジェクト間を跨いだ「点と点の結合」が得意 向いている情報 目的・ゴール・成果物が明確なもの 抽象的なアイディア、長期的な知見、個人の備忘録 検索の単位 リポジトリ単位の全文検索 Vault 全体のリンク・タグ・全文検索 GitHub は「プロジェクトという箱」に閉じることで一貫性と版管理を担保します。Obsidian は「ノート」というアトミックな単位を Vault 全体にフラットに置き、[[リンク]] で網の目を作ることで横断性を担保します。どちらが優れているという話ではなく、扱う情報の性質によって適切な箱が違うだけです。 「プロジェクトの壁」を越える横断性 GitHub はリポジトリごとに境界線がはっきり分かれています。これは「コードと文脈をセットで版管理する」目的にはとても合っていますが、知識の再利用にはコストがかかります。 GitHub の場合: プロジェクト A で得た「Next.js の認証に関する知見」は、リポジトリ A の docs/ か Wiki か Issue 内コメントに残ります。プロジェクト B を始めたときにそれを再利用するには、「どこに書いたか」を思い出して検索しに行く必要があります。複数リポジトリを横串で検索したい場合は gh search code などに頼ることになります。 Obsidian の場合: 「Next.js の認証」という独立したノートを作っておき、プロジェクト A からも B からもリンクを貼ります。情報がプロジェクトに属するのではなく、知見そのものが独立して進化していく点が決定的に違います。 つまり、GitHub は「プロジェクトに紐づく情報」を蓄積するのに最適で、Obsidian は「プロジェクトから独立した知見」を蓄積するのに最適だ、と整理できます。 ...

概要 Obsidian Vault Writeback Loop は、AI Agent が個人ナレッジ（Obsidian Vault）を 読み取るだけでなく、得た学びをそこに書き戻して自己強化する 循環設計パターン。GitHub リポジトリに閉じた知識管理（プロジェクト型）に対して、Vault を中心に据えたネットワーク型のナレッジ管理を、Claude Code のフック・スキル・MCP・GitHub Actions self-hosted runner を組み合わせて実装する。 4 つの構成レイヤー レイヤー 役割 主な構成要素 読み取り Vault → AI Agent への文脈供給 symlink (.claude/knowledge/) + 読み取り用 MCP (vault-readonly) 書き戻し設計 AI Agent → Vault inbox への安全な投入 書き込み用 MCP (vault-inbox)、inbox-first 原則 書き戻しトリガ いつ書き戻すかの発火制御 Claude Code hooks（PostToolUse / Stop / SessionEnd）、Git post-merge 昇格 inbox → Vault 本体への統合 人間による週次レビュー（4 択フロー: 昇格 / 追記 / 保留 / 破棄） 設計原則 AI に Vault 正本を直接書かせない: リンク構造を壊さないよう、inbox/ にしか書かない 読み取り MCP と書き込み MCP をサーバ単位で分離: @modelcontextprotocol/server-filesystem は引数で渡したディレクトリしか公開しないため、サーバを分けるだけで構造的な物理隔離になる CLAUDE.md には安定パス（.claude/knowledge/）を書く: Vault の生パスをコミットしない 昇格判断は人間に残す: AI に自動昇格させると Vault が壊れる 書き戻し対象はリポジトリに収まらない知見だけ: コードや設計書はリポジトリの docs/ に置く 自動化レイヤーの段階導入 Claude Code PostToolUse フック — gh pr merge 直後に書き戻しを促す Claude Code Stop フック — Daily Note の器を自動作成 Git post-merge フック — GitHub UI マージ派の取りこぼし回収 Self-hosted runner + GitHub Actions — マシン起動中なら必ず走る最後の砦（Vault・Skills・MCP がフル活用可能） cloud-hosted Actions は Vault に書けない・Skills が使えない・会話文脈ゼロという三重苦のため、書き戻し用途では self-hosted runner に切り替えるのが正解。 ...

GitHubで全部完結する開発者にObsidianは本当に必要か？ では、Obsidian を併用する場合の「思想差」と「AI Agent に渡せる文脈の質」を整理しました。本記事はその実践編です。特定のプロジェクトで Claude Code セッションを行うときに、個人の Obsidian Vault を併用してエージェントに処理させるには、CLAUDE.md / Skills / Settings をどう階層管理すべきか を具体的な設定例で示します。 ポイントは次の3つです。 Claude Code の設定階層（global / project / local）を理解して役割分担する Vault は gitignored 層 で繋ぐ（リポジトリにパスを残さない） CLAUDE.md には安定パスを書く — Vault の生パスを書かない（symlink 経由で参照） Claude Code の3層構造を整理する まず大前提として、Claude Code の設定は 3 層あり、それぞれ用途が違います。 階層 主なファイル Git 管理 使いどころ Global (user) ~/.claude/CLAUDE.md / ~/.claude/skills/ / ~/.claude/settings.json 個人の dotfiles で管理（任意） 全プロジェクト共通の個人スタイル・横断スキル Project <proj>/CLAUDE.md / <proj>/.claude/skills/ / <proj>/.claude/settings.json / <proj>/.mcp.json リポジトリにコミット プロジェクト固有の規約・公開してよい設定 Local <proj>/.claude/settings.local.json .gitignore で除外 Vault パスなど個人秘匿情報を置く claude mcp add の --scope（-s）オプションも、これと同じ 3 値を取ります（local / user / project）。重要なのはデフォルトの挙動です。 ...

Claude Code から個人 Obsidian Vault に「書き戻す」設計 では、書き戻しの設計パターンとして summary-back-to-vault スキル / Daily Note 追記 / ADR 二重書きの 3 つを示しました。本記事はその続編で、書き戻しを自動化する仕組みを扱います。 スキルを作ったとしても、毎回 /summary-back-to-vault と手で打つのは続きません。トリガを自動化しない限り、書き戻しは「気が向いたときだけ」になり、Vault は古びます。本記事では Claude Code のフック・Git のクライアントフック・GitHub Actions の 3 方式を、それぞれが拾えるトリガと文脈の違い に着目して整理します。 自動化候補の俯瞰 書き戻しを発火させる場所は大きく 3 つあります。 方式 トリガ位置 セッション文脈 適性 Claude Code hooks（PostToolUse, Stop, SessionEnd 他） セッション内、ツール呼び出し前後 ✓ 会話履歴・スキル・MCP がすべて生きている AI Agent と最も相性が良い Git クライアントフック（post-merge, pre-push など） クライアント側、git pull / git push 等 ✗ PR の diff だけ Vault が Git リポジトリ化されている人向け GitHub Actions サーバ側、pull_request: closed 等 ✗ PR メタデータのみ マシンを開いていなくても回したい場合 書き戻しに必要な「会話の文脈（なぜそう判断したか／どこで詰まったか）」を保てるのは Claude Code フックだけです。Git フックや Actions は PR の diff と説明文しか見えないため、サマリの「中身の濃さ」が大きく落ちます。これが本記事の核心です。 ...

Andrej Karpathy（元 OpenAI・元 Tesla AI ディレクター）が提唱した「Claude Code での第二の脳の作り方」。 この記事では、Claude Code + Obsidian を組み合わせて知識を蓄積・進化させる「AI 第二の脳」システムの仕組みとセットアップ手順を解説します。 普通の RAG と何が違うのか ChatGPT へのファイルアップロードや NotebookLM のような一般的な RAG は、以下のように動きます。 ファイルを渡す 質問のたびに AI が関連部分を探す 毎回ゼロから答えを生成する 次の質問がきたら、また同じことをゼロから繰り返す 何も積み重ならないのが問題です。 Karpathy が提唱したシステムは根本的に異なり、**AI が「Wiki を育て続ける」**仕組みです。新しい資料を入れるたびに、AI がその内容を読んで既存の知識と統合し、矛盾があれば修正し、関連ページを更新します。知識が一度まとめられると、常に最新状態に保たれます。 システムの全体像 このシステムには 4 つの動く部品があります。 あなたのデータ — 記事・ノート・文字起こし・アイデアなど 整理 — Claude Code が Obsidian に自動で整理 即座の質問 — 育てたデータベースにいつでも質問可能 進化する記憶 — 使えば使うほど賢くなる仕組み 3 つの層構造 層 名称 役割 層 1 生のソース（immutable） 記事・論文・画像・データファイル。AI は読むだけで書き換えない 層 2 Wiki 要約・人物・概念・比較・総合分析ページ。AI が作成・更新し続ける 層 3 スキーマ（CLAUDE.md） Wiki の構造・ルール・ワークフローを AI に教える設定ファイル この 3 層構造により、AI が「汎用チャットボット」ではなく「規律を持った Wiki 管理者」として動きます。 ...

海外 AI 活用シーンで Obsidian × Claude Code の組み合わせが爆発的な注目を集めている。6本の主要記事だけで合計 1,240万 views、ブックマーク数は 8万件超え。元 OpenAI 創設メンバーの Andrej Karpathy 氏が提唱し、Obsidian CEO の Steph Ango 氏自らが AI 連携スキルを GitHub で公開。ここまで業界の中心人物が動いたツール組み合わせは、近年なかった。 本記事は東大 ClaudeCode 研究所（@ClaudeCode_UT）が公開した解説記事「【決定版】ゼロから始めるClaudeCode × Obsidianの完全解説」をベースに、その要点をまとめる。 そもそも Obsidian とは何か Obsidian は、個人向けのローカル Markdown ノートアプリだ。2020 年公開、個人利用は無料で、Mac / Windows / Linux / iOS / Android に対応している。同じノート系の Notion や Evernote とは設計思想が根本的に異なる。 ノート本体は Markdown ファイル — 各ノートは .md としてディスク上に実ファイルで存在する。独自データベースに閉じ込められない。 Vault は OS のただのフォルダ — ノートを束ねる「Vault」は普通のディレクトリ。Git でも Dropbox でも iCloud でも、好きな仕組みで同期・バックアップできる。 双方向リンク [[ノート名]] — ノート同士をリンクで繋ぎ、知識をグラフ構造として可視化できる。Zettelkasten など既存 PKM 手法の基本機能を標準で備える。 ローカルファースト — 規定ではすべて自分の PC 内に保存。クラウドに置くかどうかは利用者が選ぶ。 豊富なプラグイン — 2,000 以上のコミュニティプラグインで、PDF 注釈・タスク管理・グラフ可視化まで拡張できる。 なぜ「AI × 記憶設計」の目的に最適なのか Obsidian のこれらの特徴は、Claude Code のようなファイルシステムを直接操作する AI エージェントと噛み合う。理由は3点ある。 ...

概要 Obsidian はローカルファイルベースの Markdown エディタであり、個人の知識管理（PKM）に特化したツール。個人利用は完全無料、データはすべて自分のマシン上の .md ファイルとして保存されるため、ベンダーロックインがない。2,700 種以上のコミュニティプラグインが存在する。 設計哲学 「Your thoughts are yours（あなたの思考はあなたのもの）」。ローカルファースト・プレーンテキスト・オフライン動作・ベンダーロックインなしを基本原則とする。 主な機能 バックリンクとグラフビュー: ノート間の双方向リンクと視覚的な知識マップ Dataview プラグイン: Markdown ファイルをデータベースとしてクエリ Templater: 動的テンプレートで繰り返し作業を自動化 Canvas: ホワイトボード的なビジュアル思考ツール AI 連携: Smart Composer / Copilot プラグインで LLM をノート作成に統合 料金 プラン 価格 用途 個人 無料 個人利用 Commercial $50/年 商用利用 Sync $10/月 デバイス間同期 Publish $20/月 Web 公開 AI Agent との統合（Claude Code） Obsidian Vault は単なるノートアプリではなく、AI Agent に「個人ナレッジ層」として常時参照させる Markdown 倉庫 として機能する。Claude Code との統合では次のレイヤーで連携する。 読み取り: .claude/knowledge/ symlink + 読み取り用 MCP (vault-readonly) 書き戻し（writeback）: 書き込み用 MCP (vault-inbox) で ~/Documents/ObsidianVault/inbox/ にのみ書く 自動化: Claude Code hooks（PostToolUse / Stop）と GitHub Actions self-hosted runner を組み合わせ、PR マージや日次のタイミングで書き戻しを発火 Vault が AI Agent 越しに自己強化される循環構造を構築できる（Obsidian Vault Writeback Loop 参照）。 ...