MCPパーソナル知識管理: The Protocol Won.

Anthropicの オープンスタンダード（AIツール統合向け）であるModel Context Protocol（MCP）は、2026年3月までに月間ダウンロード数9,700万回に達し、2024年11月のローンチ時に記録した10万回から970倍の増加を記録しました。MCPによる個人知識管理（PKM）は、代表的なユースケースとなっています。Obsidianのボルト（vault）、Notionのデータベース、Readwiseのハイライトを、独自のプラグインや個別の統合なしに、AIエージェントが直接横断できるようになりました。その売り文句は、あなたの「第二の脳」がついに独自の脳を持った、ということです。

プロトコルの部分は機能しました。しかし、組み立ての部分でほとんどのユーザーが壁にぶつかります。

MCPはAIエージェントが外部データに接続する方法を標準化しました。しかし、その接続の設定がどれほど簡単になるかまでは標準化しませんでした。 Obsidianだけでも64以上のコミュニティ製MCPサーバー実装があり、それぞれ異なるプラグイン、設定ファイル、そして継続的なメンテナンスを必要とします。Notionの公式MCPサーバーはすっきりと動作しますが、Notionが2025年5月に完全なAIアクセスを月額20ドル/ユーザーのBusinessティアに移行した後は、デフォルトの回避策となりました。Readwiseは、よくメンテナンスされたサーバーを提供していますが、そのスコープは読書のハイライトのみに限定されており、一般的なナレッジワーカーのスタックにある他のすべてのソースからは切り離されています。

受動的なPKMストレージから能動的なAIコラボレーションへの移行は現実のものであり、加速しています。その移行を体験できるかどうかは、それを可能にするスタックを自ら構築する意思があるかどうかにかかっています。

何が起きたのか —— MCPがプロトコルからPKMインフラへと進化

Anthropicは2024年11月25日、PythonおよびTypeScriptのSDK、Google Drive、Slack、GitHub、Git、Postgres向けの構築済みサーバー実装、およびClaude Desktopとの統合を備えたオープンスタンダードとしてMCPをローンチしました。その設計は、コードエディタと言語アナライザの通信を可能にする標準規格であるLanguage Server Protocolからメッセージパッシングアーキテクチャを借用したものでした。これにより、開発者にとってすぐに理解しやすいものとなり、大半のプロトコルローンチが達成するレベルを遥かに超えて初期の採用が加速しました。

成長のタイムラインは圧縮されました。最初の1ヶ月でダウンロード数は約10万回に達しました。2025年4月にOpenAIが公式にMCPを採用し、ChatGPTデスクトップアプリに統合すると、月間ダウンロード数は数週間以内に2,200万回を超えました。Google DeepMindも同月にサポートを表明しました。Microsoftは2025年7月にMCPをCopilot Studioに統合しました。2025年12月までに、AnthropicはMCPをAgentic AI Foundation（Anthropic、Block、OpenAIが共同設立し、Google、Microsoft、AWSが追加の支援者として名を連ねるLinux Foundation傘下の管理基金）に寄贈しました。この寄贈により、Anthropicが標準を支配しているという懸念が払拭され、MCPは競争上の優位性（モート）ではなく、業界共有のインフラとして定着しました。

2026年3月までに、MCP SDKの成長により、プロトコルは月間9,700万回のダウンロードと10,000を超えるアクティブなパブリックサーバーを抱えるまでに至りました。 PKMエコシステムは最も活発なセグメントの一つでした。Obsidianは64以上のコミュニティMCPサーバー実装を蓄積し、Notionは開発者プラットフォームを通じて、LLMでの使用向けに設計されたトークン効率の良いMarkdownレスポンスを返す公式サーバーをリリースしました。Readwiseは独自の公式サーバーを立ち上げ、維持しています。2024年末時点では開発者向けの統合プロトコルであったものが、AIアシスタントを個人知識ツールに接続するためのデフォルトの仕組みとなりました。

ナレッジワーカーにとって、これは具体的な能力のシフトを意味していました。ObsidianのボルトへのMCPアクセス権を持つAIエージェントは、バックリンクをたどり、ノートの内容をセマンティックに検索し、数年前に書かれた資料を浮き彫りにすることができます。追加のMCPサーバー設定を行えば、同じエージェントが1つのプロンプトでReadwiseのハイライトを相互参照し、Notionのプロジェクトデータベースにクエリを実行できます。MCPが登場する前は、1つのツールのAIに限定された独自のプラグインが必要でした。MCPがあれば、設定こそ必要ですが、理論的には接続されたすべてのツールを一度に横断できます。

なぜ重要なのか —— PKMの検索（リトリーバル）問題がついに解決へ

個人知識管理ツールは、常にインプットのために構築されてきたものであり、検索（リトリーバル）のために作られたわけではありませんでした。 典型的なPKMワークフロー（収集、整理、検索）は、最初の2つのフェーズでは機能しますが、3つ目のフェーズで破綻します。ほとんどのナレッジワーカーは、自分が何について書いたかを大まかに説明することはできますが、必要な瞬間にそれを確実に取り出すことはできません。ハイライトは読まれないまま蓄積されます。ノートは誰かが何かに結びつける前に古びてしまいます。「第二の脳」という比喩は問題を過小評価しています。本物の第二の脳は、オンデマンドではなく、プロアクティブに情報を検索（リトリーバル）するものです。

MCPの貢献は、理論的には大規模な検索（リトリーバル）を解決することです。AIエージェントがナレッジベース全体（ボルト、ハイライト、参照、ブックマーク）への読み取りレベルのアクセス権を持つと、過去の思考は、検索することを覚えているかどうかわからない受動的なアーカイブではなく、クエリ可能なコンテキストになります。プロポーザルを作成しているナレッジワーカーは、MCPに接続されたエージェントに、2年分のノートから関連するすべての情報を引き出し、関連する読書のハイライトと相互参照させ、重複する議論を浮き彫りにするよう依頼できます。MCPがなければ、その統合には何時間もかかります。動作するマルチサーバー設定があれば、それは1つのプロンプトで完了します。

この変化は単なる効率の向上ではなく、質的なものです。PKMにおける支配的な検索モードは、常にキーワード検索でした。フレーズを思い出し、それを検索し、過去の自分が同じ言葉を使っていることを願うのです。MCPは、正確な用語を覚えているかどうかに依存しない、セマンティックでツール横断的な統合を可能にします。そのObsidian MCP integrationのコミュニティは、これを「能動的な想起（キーワードや階層を思い出すこと）から、必要なものを求めることへの移行」と表現しています。

この違いが重要なのは、単一ツールのAIではこれを再現できないからです。Notion AIはNotionしか見えません。Obsidian Copilotはボルトしか見えません。Readwise ReaderのAIは読書のハイライトしか見えません。それらはお互いを見ることはできません。MCPに接続されたエージェントは、それらすべてを同時に見ることができます。これこそが、個々のツールの機能セットだけでなく、特に個人知識管理においてこのプロトコルが重要である理由です。

ナレッジマネジメントソフトウェア市場が2026年の264億ドルから2034年までに742.2億ドルへと成長すると予測されていることは、組織が検索（リトリーバル）インフラをコア投資として扱い始めていることを反映しています。MCPが可能にするシフト（静的なアーカイブからAIが横断可能なナレッジグラフへの移行）こそが、これらの数字の主な原動力であり、新しいユーザーが追加のメモアプリを採用することではありません。

本当の問題 —— 組み立てが必要であること

ほとんどのMCP個人知識管理（PKM）に関する報道が見落としている本質はこれだ。セットアップを実際に機能させるには、大半のナレッジワーカーが途中で挫折してしまうような、継続的な技術的努力が必要になるということだ。

Obsidianのケースが最も具体的だ。64以上のコミュニティ製MCPサーバー実装が存在する。この数字はエコシステムが健全であるように聞こえるが、実際には断片化として機能している。ほとんどのサーバーは、ボルト（保管庫）の内容の読み取り、ノートの書き込み、セマンティック検索など、同様のことを行う。しかし、認証方法、機能のカバー範囲、ドキュメントの品質、メンテナンス状況が異なる。1つを選択するには、GitHubのイシュートラッカーを読み、コミット日を確認し、現在のObsidianのバージョンやMCPクライアントと互換性のあるものを見つけるために、多くの場合複数のオプションを試す必要がある。

選択が完了すると、基本的なObsidianのMCPセットアップには4つの明確なステップが必要になる：Obsidian内にLocal REST APIプラグインをインストールし、ポート番号を設定してAPIキーを生成し、AIクライアントにMCPサーバーを選択してインストールし、正しい資格情報で正しいアドレスを指すようにJSON設定ファイルを記述または編集する。各ステップには失敗するパターンがある。多くの初心者はこれに午後を丸々費やしても完了できない。

セットアップガイドで言及はされていても、ほとんど強調されないセキュリティの側面もある。2025年に公開されたMCPサーバーのセキュリティに関する研究によると、MCP経由でAIエージェントを接続すると、デフォルトでボルト全体への無制限の読み取り、書き込み、削除アクセス権が与えられる。プロンプトの誤解やモデルのハルシネーションによって、ノートが永久に削除される可能性がある。セキュリティ研究者は、プロンプトインジェクションの脆弱性やデータ漏洩のリスクを、MCPエコシステム全体のシステム的な問題として報告している。研究からの実用的なアドバイスは、エージェントを接続する前に完全なバックアップを取ることだ。ほとんどのステップバイステップのセットアップガイドは、導入部分でこのことに触れていない。

ツール間の統合（クロスツール・シンセシス）の問題は、設定のオーバーヘッドを倍増させる。3つのPKMツールを使うということは、3つの別々のMCPサーバーのセットアップ、3つの別々の認証フロー、そして3つの別々の障害点が存在することを意味する。すべての接続が機能しているとき、エージェントは3つすべてを認識するが、ユーザーはそれぞれを個別に設定し、デバッグしなければならない。各ツールのセットアップ負荷は決して小さくなく、それらが組み合わさった負荷は非常に大きいため、このプロセスを開始したほとんどのナレッジワーカーは、複数のツールで完了させることはない。

現在のMCP個人知識管理のセットアップからは、モバイルワークフローが完全に排除されている。ほとんどのPKM MCPサーバーは、ホストとなるデスクトップアプリケーションが起動している必要がある。ObsidianのMCPサーバーは、デスクトップ上でObsidianが開いている必要がある。主にモバイルで情報を記録するナレッジワーカー（外出先でのワークフローが主流のプロフェッショナルの大半）には、利用可能なMCPブリッジがない。プロトコルの2026年のロードマップでは、ストリーミング可能なHTTPトランスポートが優先事項として挙げられており、これによりリモートホスト型サーバーが可能になり、このギャップが解消される予定だが、それは将来の修正案である。

パターンは一貫している：MCPはPKMツールに統合のためのインターフェースを提供したが、ユーザーに統合された体験を提供したわけではない。この2つの間にあるギャップこそが、摩擦の大部分が存在する場所だ。現在、個人知識管理（PKM）ツールを評価しているナレッジワーカーにとって、有益な問いは、そのツールにMCPサーバーがあるかどうかではない。ほぼすべての主要なツールがすでに持っているか、今後持つようになるからだ。重要なのは、AIが触れる前の体験がどのようなものであるか、そしてMCPが約束するツール間統合とユーザーとの間に、どのような設定作業が立ちはだかっているかである。

主要なPKMツールの対応状況

MCPに対するPKMエコシステムの反応は、ツールの基盤となるアーキテクチャと価格戦略を反映して、3つの明確な姿勢に分かれている。

Obsidianは、プラグイン優先というアイデンティティに違わず、2025年に商用ライセンスを廃止してコアアプリケーションをすべてのユーザーに無料化し、MCPサーバーの開発を完全にコミュニティに委ねた。その結果、動きは早いがばらつきのあるエコシステムが生まれた。優れたコミュニティサーバーは、ウィキリンクのグラフ探索、Dataviewクエリ、セマンティック検索をサポートしているが、一方で、数ヶ月前のイシュートラッカーが放置されたままのメンテナンスされていないフォークもある。Obsidianの暗黙の立場は「ここにMarkdownファイルシステムがあります。その上にAIスタックを構築してください」というものだ。詳細で相互に接続されたボルトを何年もかけて構築してきたパワーユーザーにとって、これはこれまでの投資を維持し、MCPで拡張することになる。しかし、すぐに使えるAI体験を期待する初心者にとって、セットアップの負担は大きく、どのサーバーが適切かも明確ではない。

Notionは、開発者プラットフォームを通じて公式のMCPサーバーをリリースした。これはドキュメントが充実しており、LLMでの使用向けに生のJSONではなくMarkdownを返し、生のAPIアクセスよりもトークン消費が少ない。しかし、Notionは2025年5月に月額8〜10ドルのスタンドアロンのAIアドオンを廃止した。現在、完全なNotion AIを利用するには、ユーザーあたり月額20ドルのBusinessプランが必要になる。NotionのネイティブAIに料金を支払う代わりに、MCP経由でClaudeや他のAIアシスタントを接続する個人ユーザーのワークフローが確認されており、これはNotion自身の開発者ドキュメントでも可能とされている。

Readwiseは、今回の比較の中で最も洗練されたPKM MCP実装を提供している。ハイライトやReaderドキュメントを段階的にインデックス化し、コンテンツが追加されると自動的に同期し、カスタム設定なしで主要なMCPクライアントと動作する公式サーバーだ。制限はそのスコープ（範囲）にある。Readwiseがキャプチャするのは、読書のハイライトや保存された記事であり、自分が書いたノートや出席した会議、コンピューター上のローカルファイルではない。MCPに接続されたエージェントは、「このトピックについて2年間で何をハイライトしたか？」に正確に答えることができる。しかし、その回答をナレッジスタック内の他のものと結びつけることはできない。

3つすべてに欠けているもの：自動キャプチャ。この比較における各ツールは、ナレッジベースを構築するためにユーザーの意図的なアクションを必要とする。MCPは、ユーザーが入力したものの最上部にAI検索レイヤーを追加するが、ボルトが3ヶ月間放置されていれば、エージェントは3ヶ月前のナレッジグラフを探索することになる。MCPを有効にした検索の品質は、上流での手動キャプチャの一貫性によって制限される。

これこそが、以下を中心に構築されたツールが自動キャプチャ問題を異なる角度からアプローチします。既存のノートツールにMCPを追加するのではなく、自動キャプチャを基盤として構築します。ブラウジング中にウェブページがインデックスされ、会議がローカルで文字起こしされ、ローカルファイルやメールが継続的に同期されます。ナレッジベースは意図的な操作なしで更新され、AI検索レイヤーは最新のデータに基づいて動作します。MCPは、主要なアクセスレイヤーとしてではなく、外部ツールに接続するための拡張プロトコルとして利用可能です。真のトレードオフ：自動キャプチャは、意図的なメモ作成と比較して、ナレッジベースに入る内容に対する管理（キュレーション）のコントロールが低下することを意味します。そのトレードオフが機能するかどうかは、ワークフローに依存します。

次なる展開 - まだ誰も答えていないアーキテクチャの問い

2026年のMCPロードマップは、PKMのユースケースに直接影響を与える3つの改善点を特定しています。ストリーマブルなHTTPトランスポート - MCPサーバーをローカルホストのプロセスからリモートホストのサービスに移行すること - は、デスクトップアプリケーションを実行することなく、モバイルが除外される問題に対処します。SSO統合された認証フローは、現在のツールごとのAPIキーやJSON設定ファイルに代わるものであり、セットアップを標準的なOAuth接続に近いものに簡素化します。マルチエージェント・オーケストレーション・プリミティブにより、単一のエージェントがすべてのMCP接続を同時に管理する必要がなくなり、特化したエージェントがツール間で連携できるようになります。

これらはアセンブリ問題の改善であり、それに代わるものではありません。ロードマップの3つの項目がすべて実現したとしても、ユーザーは依然としてツールの選択、接続の設定、そしてツール更新に伴う統合スタックの維持を行う必要があります。変わるのは、各ステップの難易度です。現在のパターン - ポート番号、生のAPIキー、手動のJSONファイル - は、OAuthフローや一元管理インターフェースへと移行するでしょう。それは有意義な進歩です。しかし、設定がまったく不要になることとは異なります。

セッションをまたぐ記憶の問題は、ロードマップで正式に対処されていません。Obsidianボルト全体にわたる研究の統合を1時間かけて支援してくれたAIエージェントは、次回接続したときにはそのセッションの記憶を失っています。毎回、ゼロからコンテキストを再構築する必要があります。これにより、「第二の脳」という比喩の正確性が制限されます。すべてのセッションを忘れてしまう第二の脳は、高度な検索インターフェースにすぎず、認知のパートナーではありません。

2つのアーキテクチャ上の賭けが並行してストレステストにかけられています。1つ目は、MCP統合と既存のPKMツールが成熟するにつれて、ネイティブなAIナレッジベースの価値へと収束していくというもの。つまり、プロトコルの改善によって最終的に摩擦が十分に排除され、後付け（レトロフィット）のアプローチがほとんどのユーザーにとって利用可能になるという賭けです。2つ目は、AIファーストの検索向けに設計されたツールは、プロトコルが成熟したとしても、MCPでパッチを当てたレガシーツールを凌駕するというもの。なぜなら、アーキテクチャ上の違いは検索アクセスだけでなく、キャプチャとインデックス作成にあるからです。

すでに明らかなのは、受動的なストレージから能動的なAIコラボレーションへの移行は現実であり、加速しているということです。MCPは、それをプロトコルレベルで技術的に可能にしているメカニズムです。それを体験できるかどうかは、あなたがスタックを構築できる立場にあるか、あるいはすでにスタックが組み込まれたシステムを使用しているかどうかにかかっています。

2026年において、あらゆるPKMのセットアップを評価するための最も有用な枠組みは、MCPサーバーの数ではありません。それ以前の2つの問いです。情報はどのようにナレッジベースに入るのか、そしてそれは実際にどれほど一貫して行われているのか？ AI検索レイヤーは、MCP上に構築されているかツールにネイティブであるかにかかわらず、それが処理する対象（データ）と同等の価値しか持ち得ません。まばらで古いボルトを横断する、完璧に設定されたMCP個人ナレッジ管理セットアップは、まばらで古い回答しか返しません。

ナレッジベースが活発に維持されており、設定作業が苦にならないのであれば、MCPを介してObsidian、Notion、またはReadwiseをAIクライアントに接続することは価値があります。もしキャプチャの一貫性が本当のボトルネックであるなら、検索レイヤーはそれを解決しません。プロトコルのインフラはすでに整っています。適切なエントリーポイントは、あなたが実際にどの問題を解決しようとしているかによって異なります。