Claude CodeにObsidianを読ませる方法｜AI社員の台帳【2026年10月】

Claude CodeにObsidianを読ませるには、vaultのパスと読み方をCLAUDE.mdに書けば足ります。Obsidianのノートはローカルに置かれたMarkdownファイルなので、2026年10月時点でも専用のプラグインやMCPは必須ではありません。あとはタスク票の項目と、ターン終了時のフックを決めれば、AI社員と人が同じ台帳を見て仕事を回せます。

当社（株式会社Uravation）では、Claude CodeとCodexで動くAI社員と人が、同じObsidianのvaultを見て仕事をしています。2026年10月3日時点で、vaultのMarkdownノートは6,346本。そのうちAI社員のタスク票が3,081件あり、いちばん古い票は2026年6月9日のものです。

2026年7月2日には、LinearとNotionのタスクDBを廃止して、タスク管理をObsidianに一本化しました。Google Tasksは通知だけに使い、作業の状態は持たせていません。MacBook、Mac Studio、VMのどこで起動したClaude CodeとCodexも、いまは同じ台帳を見ています。

なぜ台帳が要るのか。Claude Codeはセッションごとに新しいコンテキストで始まり、auto memoryもそのマシンの中にしか保存されません（Claude Code公式ドキュメント）。AI社員が複数のマシンで動き出すと、「誰が・何を・どこまでやったか」が会話の中に閉じてしまう。正直、運用でいちばん困るのはここなんです。

この記事では、手順を6つに分け、当社の運用の項目名と実数をそのまま出します。当社のCLIを除き、コマンドと設定キーは2026年10月3日に公式ドキュメントで確認したものだけです。

Claude CodeにObsidianを読ませると何が変わるか

Obsidianを「AI社員と人の共通台帳」に選ぶ理由は3つです。どれも公式の仕組みの範囲で説明できます。

ローカルのMarkdownなので、AIがそのまま読める

Obsidianは、ノートをMarkdown形式のプレーンテキストファイルとしてvault（ローカルのフォルダ）に保存し、外部での変更も自動で読み込み直します（Obsidian公式ヘルプ「How Obsidian stores data」）。Claude Codeがファイルを書き換えると、人が開いている画面にもその変更が出る。AIは「ファイル」として、人は「ノート」として同じものを見ているわけです。

同期の方法を選べるので、複数のマシンに同じvaultを置ける

公式ヘルプでは、Obsidian Sync（公式の同期サービス）のほか、iCloud、OneDrive、Syncthing、Gitなどの同期方法が紹介されています（Sync your notes across devices）。ただし、同じvaultを複数の同期サービスで同時に同期すると衝突や破損のおそれがある、とも注意しています。同期方法は1つに決めてください。

Claude Code側は公式の仕組みだけで足りる

Claude Codeには、毎セッションの開始時に読む指示ファイル（CLAUDE.md）と、決まったタイミングでコマンドを動かすフックが最初からあり、vaultの読み書きは通常のファイル操作です。情報を持ち越す場所は3つあり、役割が違います。

台帳は、CLAUDE.mdとauto memoryでは持てない「マシンをまたいだ状態」を受け持ちます。

手順1〜2：vaultの置き場を決め、CLAUDE.mdにパスと読み方を書く

手順1：vaultの置き場とフォルダ構成を決める

vaultは、AI社員が動くすべてのマシンで同じパスに置くのが基本です。パスがマシンごとに違うと、CLAUDE.mdに書いたパスがどこかで外れます。公式ヘルプの注意点も2つ押さえておきます。

• vaultの中に別のvaultを作らない（内部リンクが正しく更新されないことがある）
• Gitで管理するなら、画面配置を記録する.obsidian/workspace.jsonと.obsidian/workspaces.jsonを.gitignoreに入れることを検討する

参考までに、当社のvaultのトップ階層は次の7つです。

作業票（agent-tasks）、判断の根拠になる恒久ノート、一覧（90_Index）を分けておくと、AIに「まず一覧だけ読んで、必要な票だけ開く」と指示しやすくなります。

手順2：CLAUDE.mdにパスと読み方を書く

CLAUDE.mdの置き場所は、組織（IT部門が管理）・ユーザー（~/.claude/CLAUDE.md）・プロジェクト（./CLAUDE.mdか./.claude/CLAUDE.md）・ローカル（./CLAUDE.local.md）の4つです（How Claude remembers your project）。どのプロジェクトで作業していても同じ台帳を見せたいなら、ユーザー単位の~/.claude/CLAUDE.mdに書きます。当社もグローバルのCLAUDE.mdにタスク台帳と索引ノートのパスを書いていて、これで全セッション・全マシンのAI社員が同じ台帳を見ています。雛形はこんな形です（パスは例です）。

## 社内台帳（Obsidian vault）
- タスク票: `/path/to/company-vault/00_Inbox/agent-tasks/`（1タスク1ファイル）
- 一覧: `/path/to/company-vault/90_Index/Agent Task Board.md`
- 読み方: 作業の前に一覧だけ読み、関係するタスク票だけ開く。vault全体を読み込まない
- 書き方: 状態の変更はCLIで行う。frontmatterを手で書き換えない
- 完了: evidence（URL・ファイル・ログ・実行結果）がない限りdoneにしない
- 書かないもの: 鍵・パスワード・トークンなどの秘密情報、会話ログ

大事なのは、パスをバッククォートで囲むことです。@path/to/fileと書いたファイルは起動時に全部読み込まれ（入れ子は最大4階層）、公式ドキュメントも「取り込んでもコンテキストは減らない」としています。バッククォート内のパスは取り込まれないので、大きくなる台帳はパスだけ教えて必要なときに読ませます。CLAUDE.mdは1ファイル200行未満が推奨です。書き方全体はCLAUDE.mdの書き方｜何を書く・どこに置く・実例にまとめています。

vaultが作業ディレクトリの外にあるときは、読み書きの許可も要ります。起動時の--add-dir <path>、セッション中の/add-dir、settings.jsonのpermissions.additionalDirectoriesの3つが公式の方法です（Configure permissions）。

{
  "permissions": {
    "additionalDirectories": ["/path/to/company-vault/"]
  }
}

読み込まれたかどうかは、セッション内で/contextを実行し、「Memory files」の一覧に自分のCLAUDE.mdが出ているかで確かめられます。

手順3〜4：タスク票のfrontmatterと索引ノートを設計する

手順3：タスク票は1件1ファイルにする

当社のタスク台帳（00_Inbox/agent-tasks/）は、1タスク1Markdownファイルです。1つの大きな表にしないのは、AIが関係する票だけ読めば済み、複数のAI社員が同時に動いても触るファイルが分かれ、Gitの差分や同期の衝突も票1枚の単位に収まるからです。

Obsidianのプロパティは、ファイル先頭のYAML（frontmatter）として保存されます（Obsidian公式ヘルプ「Properties」）。人は画面で項目として編集でき、AIはYAMLとして読める。台帳に向いているのはここです。

frontmatterの8項目と、statusの8つの値

「待ち」をwaiting_user（人）とwaiting_external（社外）に分けているのがポイントです。どちらもAIが自分では進められない状態ですが、催促する相手が違います。分けておけば、人が朝いちばんに見るべき票だけを抜き出せます。書き方の例を1枚出しておきます（中身は説明用です）。

---
status: waiting_user
owner: claude-code
project: website
source: 営業部からの依頼
next: 料金表の改定案AとBのどちらで進めるか決めてもらう
evidence:
related:
  - "[[料金表 改定メモ]]"
note: 改定案は2つともtemplatesの書式で作成済み
---

コツはnextを「人への質問1行」にすることです。票を開いた人が、本文を読まなくても何を決めればいいか分かります。

手順4：索引ノートで一覧を作る

当社では、タスクの一覧を90_Index/Agent Task Board.mdという索引ノートにまとめ、CLAUDE.mdにはタスク台帳と並べてこの索引ノートのパスも書いています（人が日常的に見るのは社内のダッシュボードです）。自社で作るなら「作業の前にまず索引ノートを読む」と一緒に書いておくと、AIがagent-tasksフォルダを片端から開くのを防げます。

これから作るなら、Obsidianのコア機能「Bases」も選択肢です。プロパティを使って表やカンバンのような一覧を作る機能で、データはMarkdownファイルのまま保存されます（Introduction to Bases）。AIはファイルを、人は表を見る、という分担ができます。

手順5〜6：CLIで状態を変え、Stopフックで取りこぼしを止める

手順5：状態の変更はCLIに寄せる

当社では、タスク票の操作をobs-agent-taskというCLIにまとめています。サブコマンドはadd／list／show／set／done／block／waitingの7つで、運用の決まりは次のとおりです。

• doneはURL・ファイル・ログ・実行結果の証跡つきでだけ付ける
• 同じ名前の未完了タスクがあれば、新しく作らずにそれを使う（意図して分けるときだけ--allow-duplicate）
• 秘密情報（鍵・パスワード）はタスク本文に書かない
• 商談に関わるタスクは--anken 社名を付けて、案件ボードも同じターンで更新する

CLAUDE.mdのルールは「強制される設定ではなくコンテキストとして扱われる」と公式ドキュメントにあります。状態の変更をCLIに寄せておけば、「証跡なしで完了にしない」といったルールを道具の側でも確かめられます。

自社で作るなら、frontmatterを書き換える小さなスクリプトを自作するか、Obsidian公式のCLIを使います。Obsidian CLIは2026年2月27日公開のデスクトップ版1.12で追加され（Obsidian Changelog）、設定の「General」で「Command line interface」を有効にすると使えます。

# agent-tasksフォルダの中を検索する
obsidian search query="waiting_user" path="00_Inbox/agent-tasks"

# タスク票のstatusを読む・書き換える
obsidian property:read name=status path="00_Inbox/agent-tasks/example.md"
obsidian property:set name=status value=done path="00_Inbox/agent-tasks/example.md"

Obsidian CLIはアプリが起動している必要があり、1.12以降のインストーラーが前提です（Obsidian公式ヘルプ「Obsidian CLI」）。画面のないサーバーやVMでAI社員を動かすなら、ファイルを直接書き換えるスクリプトのほうが扱いやすいはずです。

手順6：Stopフックで「やりっぱなし」を止める

台帳を作っても、作業のあとに票を更新しなければ意味がありません。当社では、Claude CodeのStopフック（ターン終了時に動くフック）が、状態の変わったターンで「タスクの登録・更新・完了をしたか」を確かめ、AI社員のやりっぱなしを機械で止めています。公式の仕様は次のとおりです（Hooks reference）。

• メインのエージェントが応答を終えたときに動く（ユーザーが中断したときは動かない）
• "decision": "block"とreasonを返すと、Claudeはreasonを受け取って作業を続ける
• 入力のstop_hook_activeで、すでにStopフックで続行中かが分かる。続行が8回連続すると次のblockは無視される

全プロジェクトに効かせるなら~/.claude/settings.jsonに書きます。

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/check-ledger.sh"
          }
        ]
      }
    ]
  }
}

呼び出すスクリプトは自社の台帳に合わせて書きます。考え方は3段です。

1. 標準入力のJSONを読み、stop_hook_activeがtrueなら何もせず終わる（無限ループを避ける）
2. そのターンでファイルの変更や外部への操作があったかを確かめ、なければ終わる
3. 変更があったのにタスク票が更新されていなければ、decision: "block"と「台帳の更新が残っています」というreasonを返す

判断を伴う確認なら、"type": "prompt"のフックでモデルに判定させる方法も公式に用意されています。フックの基本はClaude Code Hooksガイドでも解説しています。

当社の実数：タスク票3,081件の内訳と読み方

2026年10月3日時点で、当社のタスク台帳にある票をファイルから集計した結果です（いちばん古い票は2026年6月9日）。

割合は総数3,081件に対する値です。8つの内訳を足すと3,080件で、1件はどの値にも数えられていません。担当（owner）は、claude-codeが2,562件、codexが516件、社内のSlackボットが2件でした。

「人の判断待ち」が最多という意味

いちばん多いのはwaiting_userで、総数のほぼ半分です。AI社員が手を止める理由の1位は、技術的な行き詰まりではなく人の判断でした。blocked（止まっている）は13件しかありません。

AI社員を増やすほど、「人が判断する場所」の設計が効いてきます。判断待ちをblockedと分け、nextに人への質問を1行で書いておく。人の判断を見える場所に集めないと、AIの作業が速くなっても仕事全体はそこで止まります。

doneが少ないのは失敗ではない

doneは382件（12.4%）です。少なく見えますが、当社では完了したものを別の場所（作業ログ）に流し、台帳には未完了のものを残す運用にしています。台帳は「いま何が止まっていて、誰の番か」を見る場所として使っているわけです。

複数のAI社員で回すときの役割分担

複数のセッションやエージェントが同時に動くと、同じファイルの取り合いが起きます。当社では役割を4つに分けています。

決まりは、同じファイルを複数のエージェントで同時に編集しないこと。編集はDriverだけで、ScoutとReviewerは読むだけです。台帳の更新役をArchivistとして名前で決めておくと、「誰かが更新するだろう」で抜けるのを防げます。この役割分担も30_Permanent/35_AI/に恒久ノートとして置いています。

もう1つの線引きは、Obsidianを「状態と判断」の置き場にして、会話ログの置き場にしないことです。当社では過去の会話ログの検索に別の索引を使っています。サブエージェントの分け方はClaude Codeサブエージェントの使い方も参考にしてください。

やってはいけない4つのこと

1. 秘密情報を台帳に書く

❌ APIキーやパスワードを、タスク票の本文やnoteに「あとで使うから」と貼る。

⭕ 書くのは環境変数の名前や保管場所だけ。vaultは同期先やGitにそのまま複製されるので、一度書くと消し切れません。

2. AIにvaultを全部読ませる

❌ CLAUDE.mdで@を使ってvaultのノートを取り込む。「vaultを全部読んで状況を把握して」と頼む。

⭕ 一覧を先に読ませ、関係する票だけを開かせる。当社のvaultは6,346本あり、全部を読ませる前提では回りません。

3. 同じファイルを複数のエージェントで同時に編集する

❌ 2つのセッションに同じ索引ノートやタスク票を書き換えさせる。複数の同期サービスで同じvaultを同時に同期する。

⭕ タスク票は1件1ファイル、編集はDriver 1つ。同期方法も1つに決める。

4. 会話ログをvaultに流し込む

❌ セッションの全文をノートとして保存し、台帳と同じ場所に積み上げる。

⭕ 残すのは「状態」「判断」「証跡」だけ。ログが混ざると、AIが読むべき票を探すのに余計なコンテキストを使います。

MCPやObsidianの連携プラグインを使う場合

ここまでは、vaultをファイルとして読み書きする前提です。Obsidianの検索やリンクの機能をAIから使いたいなら、MCP（AIと外部ツールをつなぐ規格）でつなぐ方法もあります。

Claude CodeへのMCPサーバーの登録はclaude mcp addで行い、--scopeでlocal・project・userのどこに保存するかを選びます。接続状態はセッション内の/mcpで確認できます（Connect Claude Code to tools via MCP）。詳しい手順はClaude Code MCP設定｜mcp addとスコープにまとめています。

Obsidian側では、公式のコミュニティプラグイン一覧に掲載されている「Local REST API with MCP」（作者: Adam Coddington）があり、READMEにClaude Codeからつなぐ節があります。導入と設定は作者のREADMEを参照してください。どちらの方法でも、AIにvaultのすべてのノートへの入口を渡すことになります。秘密情報を入れない、必要なファイルだけ読ませる、という前提は変わりません。

そのまま使えるプロンプト5本

Claude Codeに渡すプロンプトの例です。<vault>は自社のvaultのパスに置き換えてください。

1. CLAUDE.mdに台帳の節を足す

~/.claude/CLAUDE.md に「社内台帳（Obsidian vault）」の節を追加してください。
タスク票は `<vault>/00_Inbox/agent-tasks/`、一覧は `<vault>/90_Index/Agent Task Board.md` です。
「作業の前に一覧だけ読み、関係するタスク票を開く。vault全体は読み込まない」と書き、パスは @ を付けずバッククォートで囲んでください。
追加する前に、既存のCLAUDE.mdと矛盾する記述があれば指摘してください。

2. 依頼をタスク票にする

次の依頼を `<vault>/00_Inbox/agent-tasks/` に1タスク1ファイルで登録してください。
依頼: （ここに依頼内容）
frontmatterは status / owner / project / source / next / evidence / related / note の8項目、statusはtodoにします。
同じ題名の未完了タスクがあれば、新しく作らずにそのファイルを更新してください。
不足している情報があれば、最初に質問してから作業を開始してください。

3. 朝いちばんに人の判断待ちを確認する

`<vault>/00_Inbox/agent-tasks/` のタスク票のfrontmatterだけを読み、statusがwaiting_userのものを古い順に10件まで挙げてください。
各タスクについて、nextから「人に決めてほしいこと」を1行で抜き出してください。
本文は、判断に必要なものだけ開いてください。

4. 完了にする前に証跡を残す

このタスクをdoneにする前に、完了の証跡（URL・ファイルパス・ログ・実行結果のどれか）をevidenceに書いてください。
証跡を示せない場合はdoneにせず、statusをwaiting_userにして、nextに人へ確認したいことを1行で書いてください。
仮定した点は必ず「仮定」と明記してください。

5. 止まっている票を棚卸しする

`<vault>/00_Inbox/agent-tasks/` で、statusがworkingのまま最終更新から7日以上たつ票を挙げ、
「続ける」「人の判断待ちにする」「取り消す」のどれが妥当か理由つきで提案してください。ファイルはまだ書き換えないでください。

よくある質問

Obsidianのプラグインを入れないと、Claude Codeはvaultを読めませんか？

読めます。vaultはMarkdownファイルのフォルダなので、通常のファイルとして読み書きできます。作業ディレクトリの外にある場合は、--add-dirなどで読み書きを許可してください（手順2）。

Codexにも同じObsidianの台帳を読ませられますか？

読ませられます。当社でもClaude CodeとCodexが同じ台帳を見ていて、タスク票3,081件のうち516件はCodexの担当です。Codexは~/.codex/AGENTS.mdとプロジェクトのAGENTS.mdを読むので（Codex公式ドキュメント）、CLAUDE.mdと同じ台帳の節をそちらにも書きます。書き方はAGENTS.mdとは｜対応ツールとClaude Codeが読む条件で解説しています。

CLAUDE.md、auto memory、Obsidianはどう使い分けますか？

ルールはCLAUDE.md、Claudeが覚えた好みや訂正はauto memory、タスクの状態と判断と証跡はObsidianです。auto memoryはマシンの中にしか保存されないので、マシンをまたいで共有したい情報はObsidianに置きます。

vaultをGitで管理するときの注意点は？

画面配置のファイル（.obsidian/workspace.jsonなど）を.gitignoreに入れる、別の同期サービスと同時に同期しない、秘密情報を書かない、の3つです。

「人の判断待ち」の票が溜まったらどうすればいいですか？

まずnextに「人に決めてほしいこと」が1行で書かれているかを確かめます。質問がない票は、人が開いても判断できません。そのうえでプロンプト3のようにwaiting_userだけを抜き出し、毎朝まとめて判断する時間を取るのが現実的です。

まとめ：今日から始める3つのアクション

Claude CodeにObsidianを読ませる仕組みは、CLAUDE.md・タスク票・Stopフックの3つでできています。どれも公式の機能だけで作れます。

1. 今日やること：プロンプト1で~/.claude/CLAUDE.mdに台帳の節を足し、/contextで読み込まれたかを確かめる。
2. 今週中：タスク票の8項目をvaultのtemplatesに置き、Stopフックで「状態の変わったターンに票を更新したか」を確かめる。
3. 今月中：waiting_userの件数を週に1回数え、人の判断がどこで止まっているかを見る。

あわせて読みたい：

• AI社員61体の運用でわかった9つの教訓
• CLAUDE.md ベストプラクティス｜設定の書き方20選

参考・出典

参照日はすべて2026年10月3日です。

• Claude Code公式ドキュメント：How Claude remembers your project／Hooks reference／Configure permissions／Connect Claude Code to tools via MCP
• Obsidian公式ヘルプ：How Obsidian stores data／Properties／Sync your notes across devices／Introduction to Bases／Obsidian CLI
• Obsidian：Changelog（2026年2月27日 1.12 Desktop）
• Codex公式ドキュメント：Custom instructions with AGENTS.md
• Obsidianコミュニティプラグイン：Local REST API with MCP

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計約6万部）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。