Zettelkastenを使ってナレッジグラフを増やしていくと、不思議なことに気づきます。知識が増えるのは嬉しい。グラフビューを眺めると、概念同士のつながりが可視化されて、「ああ、ここがつながってたのか」という発見もあります。
だけど、です。
この蓄積した知識を、いちいちAIに説明するのが面倒くさくなってきました。「このzettelに書いてあるんだけど」「あの概念とこの概念、関連性あるよね」と毎回コピー&ペーストするのは、どう考えても効率が悪い。第二の脳を外部化したのに、AIがそれを読めないなんて、なんのための外部化だったのか。
そんなわけで、Obsidian上のナレッジグラフをMCPサーバとして公開して、Claude Codeから直接読み取れるようにしました。脳をAIに接続する時代です。サイボーグ化待ったなし。
今日のエントリは、このあたりのナレッジから作成しています。

- 問題の所在:AIは僕の脳を読めない
- Obsidian MCPサーバという選択肢
- BRATとかいう便利な奴
- aaronsb/obsidian-mcp-pluginの設定
- .mcp.json設定という試練
- 実際に使ってみた感想
- まとめ
問題の所在:AIは僕の脳を読めない
以前、GitHub CopilotのカスタムエージェントでZettelkastenを効率化する話を書きました。
これは確かに便利でした。記事や議事録を投げると、原子的なzettelの候補を出してくれます。定額制だから使用量を気にしなくていいのも良かったです。気兼ねなく使えるって、精神衛生上とても大事です。
ところが、です。
既存のzettelを参照してほしいとき、どうするか。コピー&ペーストです。毎回です。「あのzettelに書いてあったはず」と思っても、AIはzettelの存在を知りません。ナレッジグラフのつながりも理解してくれません。
いや、おかしくないですか。僕の第二の脳として機能しているはずのObsidianを、AIが読めないって。これじゃあ、僕がAIと第二の脳の間で情報を往復させる「人力バス」じゃないですか。デジタル時代に何やってるんだ。
Obsidian MCPサーバという選択肢
調べてみると、ObsidianをMCPサーバとして公開する方法がいくつかあることがわかりました。 大きく分けると3つのパターンがあります。
1. Obsidian内部プラグイン型
Obsidian内部で動作するプラグインとして実装されたMCPサーバです。代表的なのが aaronsb/obsidian-mcp-plugin です。
Obsidianの内部APIを直接使えるので、リンク構造やタグ、プラグインの機能をフルに活用できます。グラフトラバーサル機能もあって、AIが自分でナレッジグラフをたどっていけます。まるで探偵です。名探偵AI。
2. 外部MCPサーバ型
Obsidianとは独立して動作する外部プロセスとしてMCPサーバを立てる方式です。cyanheads/obsidian-mcp-server や MarkusPfundstein/mcp-obsidian などがあります。
外部サーバなので、Obsidianが起動していなくても動作します。複数のクライアントから接続できるのもメリット。ただし、これらのサーバは記事のCRUD(作成・読み取り・更新・削除)に特化しているように見えます。僕が欲しいのは、ナレッジグラフを走査して組み合わせながらナレッジを構築してくれる機能なので、ちょっと方向性が違うかなと。
3. 汎用ファイルシステム型
Obsidianに特化せず、Markdownファイルをripgrepなどで検索する汎用的なアプローチです。kp-ripgrep-mcp などがあります。
導入が軽量で、高速な全文検索ができます。ripgrepは速いですからね。ただし、Obsidianのリンク構造やタグを深く理解するのは苦手です。ただのテキストファイルとして扱われるので、グラフ構造は見えません。
選んだのは内部プラグイン型
僕が選んだのは、Obsidian内部プラグイン型のaaronsb/obsidian-mcp-pluginです。
なぜか。ナレッジグラフのリンク構造を読み取って、AIが自分でグラフをたどっていけるようにしたかったからです。「このzettelから参照されているzettelは?」「このタグが付いているzettelの一覧は?」こういった操作を、AIが自律的に実行できるのが理想です。
aaronsb/obsidian-mcp-pluginは、まさにそれができます。グラフをたどる。知的探索。かっこいいじゃないですか。ripgrepでガサ入れするより、よっぽどスマートです。
BRATとかいう便利な奴
さて、aaronsb/obsidian-mcp-pluginをインストールしようとして、気づきました。これ、公式プラグインリストに載ってないんですね。ベータ版です。
普通のプラグインなら、Obsidianの設定画面で検索してポチッとインストールできます。だけど、ベータ版だとそうはいきません。手動でGitHubからダウンロードして、.obsidian/pluginsフォルダにコピーして、設定ファイルを書いて...面倒くさい。更新のたびにこれを繰り返すのは、僕の性格的に無理です。絶対忘れます。
そこで登場するのがBRATです。
BRATは「Beta Reviewer's Auto-update Tool」の略で、ベータ版プラグインをGitHubから直接インストールして、自動更新までしてくれるPluginです。ベータ版を試すためのツールですが、BRAT自体は公式プラグインとして配布されています。メタですね。
BRATのインストール
まず、BRAT自体をインストールします。これは公式なので簡単です。
- Obsidianの設定を開く
- 左メニューから「Community plugins」を選択
- 「Browse」ボタンをクリック
- 検索欄に「BRAT」または「Obsidian42 - BRAT」と入力
- 表示されたプラグインを「Install」してから「Enable」

これでBRATが使えるようになりました。さあ、ベータ版の世界へようこそ。
ベータプラグインの追加
次に、aaronsb/obsidian-mcp-pluginを追加します。
- コマンドパレット(Cmd/Ctrl + P)を開く
- 「BRAT: Add a beta plugin for testing」と入力
- GitHubリポジトリURL入力欄が表示される
aaronsb/obsidian-mcp-pluginを入力- Enterを押す

BRATがGitHubから最新版をダウンロードしてインストールしてくれます。完了したら、Obsidianの設定 → Community pluginsからプラグインを有効化します。
あっという間です。BRATに出会えて本当に良かった。
aaronsb/obsidian-mcp-pluginの設定
プラグインをインストールしたら、MCPサーバとして動作するように設定します。
このプラグインの特徴は以下の通りです。
- HTTPSでMCPサーバを提供できる
- 証明書検証を無効化できる(開発環境で便利)
- APIキーでの認証が可能
- ナレッジグラフのトラバーサル機能
プラグイン設定画面
Obsidianの設定 → Obsidian MCP Pluginを開くと、以下の設定項目があります。まぁだいたいデフォで良さそう。

証明書について
プラグインは自己署名証明書を自動生成して、ファイルシステム上に配置してくれます。親切設計ですね。HTTPS通信で使いたい人は、この証明書を活用できます。
証明書検証を無効化するオプションもあるので、開発環境でさくっと試したいときは無効化しておくのもありです。まあ、お好みで。僕は無効化しました。だってdevcontainerに取り込むのが面倒だもの。
.mcp.json設定という試練
Claude CodeからObsidianのMCPサーバに接続するには、.mcp.jsonファイルを設定します。
僕の設定は以下の通りです。
{ "mcpServers": { "obsidian-vault": { "command": "npx", "args": [ "mcp-remote", "https://host.docker.internal:3443/mcp", "--header", "Authorization: Bearer ${OBSIDIAN_API_KEY}" ] } } }
シンプルに見えますが、ここに至るまでに何度か試行錯誤しました。最初はlocalhostで接続しようとしたんですが、Docker内のClaude Codeからはlocalhostがコンテナ自身を指すんですね。当たり前といえば当たり前ですが、一瞬「あれ?」となりました。
なぜこの設定なのか
いくつかポイントがあります。
mcp-remoteを使う
mcp-remoteは、HTTPSで提供されているMCPサーバに接続するためのツールです。npxで実行することで、インストール不要で使えます。便利な世の中になったものです。
host.docker.internalを使う
僕の環境では、Claude CodeがDocker内で動いています。Docker内からホストマシンのObsidianに接続するには、host.docker.internalというホスト名を使います。Dockerの特殊なホスト名で、コンテナ内から見たホストマシンのIPアドレスに解決されます。
How do I connect from a container to a service on the host?
The host has a changing IP address, or none if you have no network access. It is recommend that you connect to the special DNS name host.docker.internal, which resolves to the internal IP address used by the host.
最初この仕様を知らなくて、「なんでlocalhostでつながらないんだ」と30分くらい悩みました。Dockerのドキュメントを読んで「そういうことか」と。知らないことは調べればいいんです。ただし、調べるまでの時間は取り戻せません。
環境変数でAPIキーを管理
${OBSIDIAN_API_KEY}という記法で、環境変数を参照しています。
僕は.envファイル(direnvで管理)に以下のように書いています。
export OBSIDIAN_API_KEY="ここにAPIキー"
Claude Codeの.mcp.jsonは、command、args、env、url、headersフィールドで環境変数展開をサポートしています。${VAR}という構文で環境変数を参照でき、${VAR:-default}でデフォルト値も指定できます。
実際に使ってみた感想
この仕組みを使い始めて数日。率直な感想は「もう戻れない」です。
Claude Codeで何か調べものをしているとき、「あ、これ前にzettelへ書いたな」と思ったら、そのままClaude Codeに聞けます。AIが勝手にObsidianを検索して、関連するzettelを見つけてきてくれます。
ナレッジグラフのつながりも理解してくれます。「このzettelから参照されているzettelは?」と聞くと、リンクをたどって一覧を出してくれます。グラフ構造を把握しているからこそできる芸当です。まさに「脳をAIに提供している感じ」です。
以前は、「あれ、どのzettelに書いたっけ?」と自分で探していました。Obsidianの検索機能も優秀ですが、それでも手間です。検索Wordを考えて、入力して、結果を眺めて、「これじゃない」と思ってまた検索して。
今は、AIに任せればいい。僕の第二の脳を、AIも自由に参照できます。人力バスから解放されました。情報流通の自動化です。素晴らしい。
第二の脳をさらに拡張できた実感があります。Zettelkastenで蓄積した知識を、AIを介してさらに活用できるようになりました。知識の価値も上がった気がします。溜め込むだけじゃなくて、使えるようになったんです。
まとめ
Zettelkastenで蓄積した知識を、AIが活用できるようになりました。
BRATを使ってaaronsb/obsidian-mcp-pluginをインストールして、ObsidianをMCPサーバとして公開しました。Claude Codeから.mcp.jsonで接続設定を行い、環境変数でAPIキーを安全に管理しています。
これで、Claude CodeがObsidianのナレッジグラフを自由に探索できます。zettel同士のつながりを理解して、関連する情報を引き出してくれます。
第二の脳とAIの融合。これがZettelkastenの新しい使い方かもしれません。脳を外部化して、AIに接続する。サイボーグ化の第一歩です。