Writeback

概要 本ガイドは、個人 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 つの弱点がすべて解消します。 ...

概要 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 に切り替えるのが正解。 ...

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