Obsidian

Obsidianの創業者が、自社の有料サービスである Obsidian Sync を 使わずに Vault を同期・バックアップする方法を公式ドキュメントとして明文化したことが話題になっている。 何が起きているのか Obsidian は「あなたのノートは永遠にあなたのもの」を掲げるローカルファースト型のナレッジ管理ツールだ。ノートはプレーンテキスト（Markdown）でローカルに保存され、クラウドへの依存を強制しない設計になっている。 そのObsidianの創業者が、有料の Obsidian Sync（$4〜/月・年払い、または $5/月・月払い）を契約しなくても Vault を複数デバイス間で同期できる方法を、公式ドキュメント上で余すところなく公開した。 公式が案内している無料同期の選択肢 公式ヘルプ（Sync your notes across devices）によると、以下の方法が紹介されている。 1. iCloud（Apple デバイス間） Mac・iPhone・iPad を使うユーザーにとって最もシンプルな選択肢。iCloud Drive の中に Vault フォルダを配置するだけで、Apple デバイス間でシームレスに同期される。 ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault 設定コストがほぼゼロで、iOS アプリとの相性も良い。 2. Google Drive / Dropbox / OneDrive クラウドストレージのフォルダ配下に Vault を置くだけで同期が成立する。Windows や Android ユーザーにも対応できる汎用的な方法だ。 Google Drive のデスクトップアプリで同期するフォルダを指定 Vault を ~/Google Drive/MyVault などのパスに配置 モバイルでは公式の Obsidian アプリ + ファイルマネージャアプリで Vault フォルダを指定 3. Git（バージョン履歴も残したい人向け） obsidian-git プラグインを使えば、Vault の変更を GitHub などに自動プッシュできる。 1 2 3 4 # プラグイン設定後、Vault ルートで初期化 git init git remote add origin https://github.com/yourname/my-vault.git git push -u origin main プラグイン設定で自動コミット・プッシュ間隔を指定できるため、バージョン履歴まで残せる点が他の方法と異なる。 ...

概要 本ガイドは、個人 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 と説明文しか見えないため、サマリの「中身の濃さ」が大きく落ちます。これが本記事の核心です。 ...

海外で話題になっているある個人トレーダーの話が、X（旧Twitter）で拡散されている。彼はObsidianとN8Nを組み合わせて「自動トレーディングAI」を構築し、6ヶ月で$180,000（約2,700万円）を稼ぎ出したという。月のAPIコストはたった$120。クラウドサーバーも、アナリストチームも、Bloombergターミナルも不要だ。 元ネタのツイートは@browomoによるもので、4,500以上のいいね、90万回以上の閲覧数を記録している。 システムの全体像 このシステムの核心は、Obsidianのローカルvaultをナレッジの「中枢」として、N8Nの6本のワークフローパイプラインが情報を自動収集・分析・配信する構造にある。構成要素は次の通りだ。 ハードウェア: 自宅のMac Mini（ローカルでvaultを保管・パイプラインを常時稼働） モバイル: iPhoneでvaultにアクセス・アイデアをキャプチャ コスト: Readwise・Whisper API・N8Nホスティングのサブスクリプションで月約$120 伝統的なクオンツファンドが同等のインサイトフローのために8人のチームを雇っている一方、このシステムはその機能を個人レベルで再現している。 VAULT.md に書かれた「AIアナリストへの指示」 システムの起点となるのは、Obsidian vaultのルートに置かれた VAULT.md ファイルだ。ここにAIアナリストへの役割定義と行動指針が記されている： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 you are the AI analyst of a solo trader. you read his vault every morning at 6:00, find connections between fresh and old notes, and deliver 3 trading ideas he can verify in the hour before the market opens. pipelines: // Reader (pulls every article and highlight from Readwise, Twitter bookmarks, and Kindle into /notes) // Listener (transcribes podcasts through Airr and voice notes through Whisper, puts them in /notes) // Catcher (accepts any message from the Telegram bot and writes it to /inbox with a timestamp) // Connector (every night reads across the entire vault and updates the connection graph between 4,000 notes) // Briefer (at 6:00 AM writes a brief: 3 trading ideas for today plus the emerging thesis of the week, puts it in /inbox) // Mobile (lives in the iPhone, answers any question about the vault by voice, and confirms alerts while the owner is on the go). you wake the owner with a push notification only when a fresh note contradicts his active thesis or when 1 of the 3 morning ideas has a confidence score above 90%. この指示が秀逸なのは、AIに「何を自律的にやるか」と「いつ人間を介入させるか」の境界を明確に定義している点だ。 ...

Andrej Karpathy が2026年4月に公開した GitHub gist「LLM Wiki」が、公開から48時間以内に5000スターを超えた。コード一行も含まない、純粋にアイデアだけを記述したドキュメントがここまで反響を呼んだ理由はシンプルだ。「RAGの次」を具体的かつ実践的に示していたからである。 RAGとの決定的な違い 多くの人がLLMとドキュメントを組み合わせるとき、最初に試みるのが RAG（Retrieval-Augmented Generation） だ。ChatGPTのファイルアップロード、NotebookLM、LangChainで構築するベクトルDB検索 — これらはすべて「質問が来たときにドキュメントから関連部分を取ってきて回答する」という設計思想に基づいている。 この方式には根本的な問題がある。知識が蓄積されない。5つのドキュメントを横断する微妙な問いに対しても、LLMは毎回ゼロから関連箇所を探し出し、推論し直す。「矛盾」も「文脈」も「先週気づいた発見」も、次の質問では消えてしまう。 LLM Wiki が提案するのは根本的に異なるアプローチだ。 LLM が incrementally に永続的な wiki を構築・維持する。新しいソースを追加するたびに、LLM はそれを読み込んで既存 wiki に統合し、エンティティページを更新し、矛盾を記録し、進化する合成の全体を強化する。知識は毎回再導出されるのではなく、一度コンパイルされてから最新に保たれる。 この「コンパイルされた知識ベース」こそが LLM Wiki の本質である。 3層アーキテクチャ LLM Wiki は3つの層で構成される。 1. Raw Sources（生ソース） 記事、論文、画像、データファイルなど自分がキュレートしたソースドキュメントの置き場。不変（immutable） — LLMはここから読むだけで決して書き換えない。これが「真実の源泉」となる。 2. The Wiki（wiki本体） LLM が生成・維持するマークダウンファイルの集合。概要、エンティティページ、概念ページ、比較、合成。この層は LLM が完全に所有 する。あなたは読む側で、LLM が書く側だ。 3. The Schema（スキーマ） CLAUDE.md（Claude Code用）や AGENTS.md（Codex用）など、LLMに wiki の構造・規約・ワークフローを伝えるドキュメント。これが LLM を「汎用チャットボット」から「規律あるwikiメンテナ」に変える鍵だ。このファイルはあなたと LLM が協力しながら進化させていく。 3つの操作 Ingest（取り込み） 新しいソースを生コレクションに追加して、LLMに処理を依頼する。LLMはソースを読み込み、重要な情報を抽出し、wikiに統合する。一つのソースが10〜15のwikiページを更新することもある。一度に大量のソースをバッチ処理することも可能だが、Karpathy 自身は「一つずつ取り込み、要約を確認しながら進める」スタイルを好むと述べている。 Query（クエリ） wikiに対して質問する。LLMは関連ページを検索・読み込み、引用付きで回答を合成する。回答の形式は問いによって変わる — マークダウンページ、比較表、Marpスライド、matplotlibグラフなど。 重要な洞察: 良い回答はwikiに新しいページとして追記できる。「あの比較をお願いした結果」「見つけた新しい接続」— これらをチャット履歴に埋もれさせるのではなく、wikiに蓄積させることで探求が複利的に積み重なる。 ...