2026 年、コードエージェントを Obsidian の Vault に接続することは、もはや特殊なアイデアではありません。おそらく、今現在存在する知識管理のセットアップの中で、最も過小評価されているものの一つでしょう。しかし、それを実践しているほとんどすべての人が、最初のステップ「Claude Code にフォルダを指定して、Markdown を読み書きさせる」に留まっています。これでも機能します。しかし、これは始まりに過ぎず、なぜ次のステップである MCP が重要なのかを理解するには、まず現在の仕組みとその限界を理解する必要があります。
MCP なしで既に可能なこと
Claude Code が Vault を直接指定する場合、ファイルシステムにアクセスできる他のエージェントと同じように動作します。フォルダ構造を読み取り、grep や glob を使って関連するコンテンツを探し、指定された規則（YAML フロントマター、ウィキリンク、コンテンツタイプごとのフォルダ階層）に従って Markdown ファイルを書き込んだり編集したりします。プラグインも、データベースも、API も必要ありません。プレーンテキストと、それを判断して読み書きする方法を知っているエージェントだけです。
システムが適切に設計されていれば、その結果は見た目以上に強力です。架空の話ではなく、実際の例として、私が密にフォローしている Vault では、まさにこの方法で、78 の生のソース（論文、記事、ドキュメント）から、180 の相互リンクされた Wiki ページ（そのうち 83 がコンセプトページ、残りはツール、人物、比較、ソースの要約）へと成長しました。そして、それらすべての相互参照は、新しいコンテンツが入るたびにエージェント自身が更新し続けています。誰も手で 1 ページも書くことなく。
直接ファイルアクセスの限界
しかし、このモデルにはパフォーマンス上の制限だけでなく、構造的な限界があります。Claude Code は、あなたの Vault がどのように構成されているかを事前に知っている必要があります。つまり、どのフォルダが不変で、フロントマターの規則は何か、コンセプトはどこにありツールはどこにあるか、といったことです。事実上、新しい Vault ごとに異なる統合が必要となり、その都度システムプロンプトで最初から説明しなければなりません。
さらに、エージェントは Vault に対して「あなたは何ができるのか？」と問いかけることができません。既に存在するものを読み取り、汎用的なファイル操作（読み取り、書き込み、テキスト検索）を実行することしかできません。派生した操作（このノートのバックリンクグラフを表示する、この Dataview クエリを実行する、孤立したページを教えてくれる）をエージェントに公開する方法はなく、エージェント自身が毎回そのロジックをゼロから再構築する必要があり、その過程でコンテキストとエラーマージンを浪費してしまいます。
MCP が解決するもの、深く
MCP（Model Context Protocol）は、まさにこの問題、つまり AI モデルと外部システム間の統合を解決するために、Anthropic が 2024 年 11 月に立ち上げたオープンスタンダードです。MCP 以前は、N 個の AI アシスタントが M 個の異なるツールやデータソースに接続する必要がある場合、N×M のカスタム統合が必要でした。あるアプリケーションが Notion をサポートしたい場合、ゼロから構築し、別のアプリケーションが同じことを望む場合、再びゼロから構築していました。MCP はこれを N+M に変えます。つまり、汎用クライアント（アプリケーションごとに 1 つ）と汎用サーバー（システムごとに 1 つ）が構築され、どのクライアントもカスタム統合なしにどのサーバーとも通信できるようになります。
適切な例えは USB-C です。以前は、周辺機器ごとに独自のコネクタがありましたが、USB-C では、デバイスは Mac に接続されているか PC に接続されているかを気にせず、プロトコルを話すだけで済みます。
アーキテクチャは 3 つの層で構成されています。ホストは、ユーザー向けアプリケーション（Claude Code、Claude Desktop、またはカスタムエージェント）であり、リクエスト内容を解釈し、外部データやツールが必要かどうかを判断します。クライアントはホスト内に存在し、各サーバーとの 1:1 接続を管理し、抽象的なリクエストを具体的な MCP メッセージに変換し、セッションのライフサイクルを管理します。サーバーは、プロトコルを実際のシステム（この場合は Obsidian Vault）に接続し、MCP リクエストをネイティブな操作に変換します。
2 つの特性により、これは単なる表面的な抽象化レイヤー以上のものになります。1 つ目は動的な機能発見です。接続時に、クライアントはサーバーに何ができるかを尋ね、サーバーはリアルタイムで応答します。もし明日サーバーが新しい機能を追加しても、クライアントはそれを使用するために再プログラムする必要はありません。2 つ目は、インテリジェンスとデータの分離です。Obsidian 用の MCP サーバーを構築する人は、どのモデルがそれを使用するかを知る必要がなく、エージェントを構築する人は、モデルを変更するたびに統合を再構築する必要がありません。
MCP サーバーは、3 種類のプリミティブを公開します。リソースは、モデルが読み取ることはできるが変更できないデータです。ノートの内容、検索結果、バックリンクグラフなどです。ツールは、モデルが積極的に呼び出すことができるアクションです。ノートの作成、タグの更新、構造化クエリの実行などです。プロンプトは、再利用可能でパラメータ化可能な指示テンプレートです。例えば、「このソースを要約し、対応する Wiki ページを生成する」を、毎回書き直す必要のある自由テキストではなく、名前付きの操作として提供します。
具体的に Obsidian に適用する
Obsidian 専用に構築された MCP サーバーは、既にそのオープンソースエコシステム内に存在しており、通常は Obsidian 自身のローカル REST API プラグインによってサポートされています。これらは、Vault 内のセマンティック検索、ノートの作成と編集、タグとメタデータの管理、リンクグラフの読み取りなどの操作を公開し、エージェントが事前に正確なフォルダ構造を知っている必要はありません。
実際に何が変わるかは微妙ですが重要です。MCP がない場合、Claude Code はあなたが一つずつ説明したルールで Vault を管理します。MCP がある場合、あなたの Vault は、Claude Code が API やデータベースを操作するのとまったく同じように操作できるツールとなり、その機能を事前に記憶するのではなく、接続時に発見します。そして、同じ接続は Claude Code だけでなく、他の MCP クライアントでも機能します。つまり、同じサーバーが、Obsidian 側のコードを一行も変更することなく、別のアプリケーション内の別のエージェントにデータを提供できるのです。
実践的なフレームワーク：3 つの成熟度レベル
自分のセットアップがどの段階にあるかを把握するために、私が使っているフレームワークを紹介します。
レベル 0：手動でのコンテキストのコピー＆ペースト。すべての会話はゼロから始まり、ユーザーはノートの関連部分をチャットに貼り付けます。特定のタスクには機能しますが、スケールしません。
レベル 1：直接ファイルアクセスを持つエージェント。これは、この記事の 78→180 ページの例を含め、現在のほとんどの Claude Code + Obsidian のセットアップが該当する段階です。エージェントは、指示ファイルで説明された規則に従って、Vault を直接読み書きします。レベル 0 よりもはるかに強力であり、単一のエージェントが管理する単一の Vault であれば、長期間にわたって十分である可能性があります。
レベル 2：MCP 経由で接続されたエージェント。Vault は、動的に発見可能な機能を持つサーバーとして公開され、異なるモデルやアプリケーション間で再利用可能です。これは、複数のエージェント、複数の Vault、またはファイル単位の読み書きを超えた操作を公開する必要が生じた時点で意味を持ちます。
AI 管理型 Vault を活用するために、すぐにレベル 2 にジャンプする必要はありません。レベル 1 だけでも、システムがない状態と比較すれば、すでに大きな飛躍です。しかし、MCP が何を解決するかを理解することは、これがどこに向かっているのかを理解することでもあります。「私の AI は私のノートを読める」から、「私の知識は、あらゆる AI が操作できるシステムである」へ。
あなたのセットアップは今、どのレベルにありますか？コメントで教えてください。もし十分な関心があれば、次の記事では、Obsidian 用の最初の MCP サーバーをセットアップするためのステップバイステップガイドを公開します。
そして、これが役に立ったなら、私をフォローしてください @chesny
これは、システムを読み取るだけでなく操作するエージェントに関するシリーズの最初の記事です。
