ここまで、LLMメモをあとから探しやすくするための段階として、梅、竹、松の三つを見てきました。
梅コースでは、フロントマターやタグを使って、メモに検索用の取っ手を付けました。
竹コースでは、全文検索を使って、言葉の一致で素早く候補を絞りました。
松コースでは、ベクトル検索を使って、意味や話題の近さでうろ覚えの候補まで拾う方法を見ました。
ここまで扱ってきたのは、どれも保管庫の中を探すための方法です。
けれども、筆者がやりたかったのは、もう一歩先のことでした。
チャット中のLLM自身に、保管庫を探しに行ってもらうことです。
つまり、探す方法そのものをLLMに渡すことと言い換えられます。
この章では、その実例として、筆者の保管庫MCPについて紹介します。
6-1 MCPとは：検索をLLMの道具にする規格
MCPとは、ざっくり言えば、LLMに外部の道具を使わせるための規格です。
本来は検索に限らず様々な道具を使ってもらえますが、この本では検索の話に絞っています。
第4章の終わりに触れた通り、チャット画面の向こうにいるLLMからは、手元のPCの中の検索の窓口には届きません。
チャット画面で話しているだけなら、LLMが見られるのは、基本的にその会話の中で渡された情報です。
だから、保管庫のメモを読んでほしいときは、人間がファイルを探して、内容を貼り付けたり、アップロードしたりする必要があります。
これは、メモが少ないうちはまだ何とかなります。
けれども、保管庫が大きくなってくると、だんだん面倒になります。
そもそも、どのファイルを渡せばよいのか。
そのファイルはどこにあるのか。
今の相談に関係するメモは他にもあるのか。
これを毎回人間が探してからLLMに渡すのは、手間がかかります。
MCPは、この窓口への通路を作るための仕組みだと言えます。
検索そのものを、LLMが使える道具にしてしまいます。
たとえば、LLMが会話の流れを見て、「この話なら、保管庫の中を検索した方がよさそうだ」と判断する。
そして、検索用の道具を呼び出して、関係しそうなファイル候補を探す。
必要なら、見つかったファイルの中身を読み、そのうえで返事をする。
このような流れを可能にするための規格の一つが、MCPです。
MCPを使うと、検索機能やファイル読み取り機能を、LLMから呼び出せる道具として用意できます。
つまり、これまで人間がやっていた、
「保管庫を探す」
「関係しそうなファイルを開く」
「中身をLLMに渡す」
という作業の一部を、LLM自身に任せられるようになります。
もちろん、MCPを使ったからといって、LLMが勝手に何でも分かるようになるわけではありません。
道具として用意されていないものは使えませんし、検索語が悪ければ、うまく見つからないこともあります。
それでも、チャット中に「このあたり、保管庫を探してみて」と頼めるだけで、かなり楽になります。
MCPは、保管庫そのものをLLMの記憶にする仕組みではありません。
むしろ、必要なときに探しに行ける資料庫への通路を作る仕組みです。
筆者の保管庫MCPでは、この通路を使って、クラウドLLMから自分のObsidian保管庫を検索したり、特定のマークダウンファイルを読んだりできるようにしています。
MCPには、手元のPCの中で使うものと、インターネット越しに使えるようにしたリモートMCPがあります。
筆者の保管庫MCPは、後者です。
次の節では、実際に筆者の保管庫MCPで何をしているのかを見ていきます。
6-2 保管庫MCPで何をしているか
筆者の保管庫MCPが検索対象にしているのは、この原稿執筆時点で2000ファイル近く、今も日々成長を続けているObsidian保管庫です。
本人でも、どこに何を書いたか、一瞬考え込んでしまう規模の保管庫です。
そんな筆者の保管庫の中には、第4章でも触れたような特徴的なフォルダがいくつかあります。
- LLM引き継ぎ（LLMと共同で走っている企画のために引き継がれているファイル群）
- LLM会話サマリー（LLMとの会話をまとめたサマリー群）
- LLM wiki（LLMに調べてもらった知識のメモたち）
- 雑録（筆者が自分で調べたり体験したことなどの備忘録）
- 創作（筆者の創作小説など）
LLMと何かを相談するときには、これらの情報があると何かと捗ります。
けれども、さすがに総数およそ2000ものメモ帳の束から、ピンポイントで特定の話題を探すには、工夫が必要です。
そこで、この保管庫MCPでは、以下の2つの操作ができるようにしています。
- 大雑把な単語で、話題に関係しそうなファイルを検索する
- 正確なファイル名を指定して、ファイルの中身を取得する
会話の流れでLLMが検索する場合、筆者がファイルの名前をど忘れしていても、それまでのやり取りで拾えた、いくつかのキーワードがあれば、関連しそうなファイル候補が、該当する単語の周囲の記載と一緒に返ってきます。
見つかった候補は、今度はファイル名を指定して中身まで読ませられます。
つまり、いきなり2000ファイル全部をLLMに読ませるのではなく、まず検索で候補を絞り、必要なものだけを深掘りする仕組みです。
大雑把な単語から話題に近いファイルを探せるところは、これまで説明してきた松コースの実例そのものです。
さらに、名前にMCPと付いている通り、この検索機能はクラウドLLMから呼び出せる道具として接続されています。
リモートMCPとして作り上げたので、対応環境と接続が整っていれば、ある程度端末を問わず使えます。
初めから正確なファイル名を直接指定すれば、外出先からチャットしていても、煩雑なアップロード操作を経ることなく、LLMにそのファイルの中身を読ませられます。
これが、筆者の保管庫MCPでやっていることです。
大量のマークダウンファイルを、単なる保存場所ではなく、LLMと一緒に使える資料庫として扱えるようにしています。
6-3 なぜMCPまで作ったのか
保管庫検索のための仕組みを単に手元で検索するツールにとどめず、リモートのMCPまで実装した背景には、以下のような理由があります。
- ふわっと話題に乗ってほしい
- チャット中に使いたい
- ファイルを毎回アップロードしたり貼ったりしたくない
何かしら特徴的な話題を、セッションを超えても正確に覚えていてほしい。
……というのは、もちろん完全に夢の話です。
けれども、クラウドLLMの多くには、すでにメモリやプロジェクト機能があります。
そこへさらに、こちらから自分の資料庫を参照できる仕組みを用意すれば、もしかしたら、もう少し話の続きを拾いやすくなるかもしれません。
例えばチャットで雑談している間に、話が芋づるのように連なって、思い悩んでいた企画のブレイクスルーにつながりそうなときがあります。
そんなとき、関連する企画メモや過去の会話サマリーを、もう一度アップロードしたり、コピペしたりせずに済むと、とても楽です。
筆者の保管庫は、多端末間で同期する仕組みも利用しています。
だから、ファイル自体はモバイル端末からでも見られます。
しかし、2000近くあるファイルの中から、モバイル端末でLLMに渡したいファイルをピンポイントで特定し、さらに中身をコピペしたりアップロードしたりするのは、工夫をこらしても、それなりに不便です。
人間が頑張って探して、選んで、貼る。
もちろん、それでも使えます。
けれども、会話の流れの中でLLM自身が保管庫を検索し、必要そうなファイルを読みに行けるなら、こちらの手間はかなり減ります。
そして何より、LLMとの会話が「毎回資料を渡し直すもの」から、「必要に応じて自分の資料庫を参照しながら進むもの」に近づきます。
筆者がMCPまで作ったのは、単に検索を強くしたかったからだけではありません。
保管庫を、LLMとの会話の中で自然に使える資料庫にしたかったからです。
結構、贅沢な仕組みだと自負しています。
6-4 実例としてのポイント
ここまで、筆者の保管庫MCPで何をしているのか、なぜMCPまで作ったのかを見てきました。
この実例で大事なのは、まず、検索をLLMに丸投げしないことです。
MCPで保管庫を検索できるようにしたからといって、LLMが毎回、完璧なファイルを探し当ててくれるわけではありません。
検索語がずれれば、検索結果もずれます。
だから、実際に使うときは、「まず検索して、次に必要そうなファイルを読む」という流れを意識します。
いきなり全ファイルを読ませるのではありません。
まず検索で候補を絞る。
その候補を見て、必要なファイルだけを読む。
これは、第4章から繰り返してきた考え方と同じです。
探す。
絞る。
読む。
この順番があるから、保管庫全体を相手にしていても、LLMに渡す情報量をある程度抑えられます。
次に大事なのは、保管庫を更新したら、検索側にも反映することです。
保管庫は、日々変わります。
新しいメモが増え、既存のメモを書き換え、不要になったファイルを消すこともあります。
その変化が検索側に反映されていなければ、MCPで検索しても、今の保管庫とはずれた結果が返ってきます。
だから、検索用の索引を更新する仕組みが必要になります。
筆者の環境では、保管庫の差分を見て、検索側に反映する処理を用意しています。
これは、第5章で触れた「便利な検索を守り育て続ける」話そのものです。
さらに、常時使いたい道具にするなら、起動し続ける環境の世話も必要になります。
通路の先の窓口が閉まっていたら、LLMは何も探せません。
だから窓口を開けておくPCの世話も要ります。
筆者の保管庫MCPは、リモートから使えるようにしているため、手元のPC側で検索用の仕組みが動いている必要があります。
つまり、PCの再起動や、検索用サービスの停止、索引の破損といった問題にも向き合うことになります。
こうしたことが起きても、保管庫本体のマークダウンファイルが無事であれば、検索用の索引は作り直せます。
検索用の仕組みが壊れても、元のメモまで失われるわけではありません。
ただし、作り直せることと、世話が要らないことは別です。
保管庫MCPは便利です。
けれども、便利なぶん、更新、起動、復旧といった運用が付いてきます。
個人的な資料を扱うリモートMCPでは、第三者から勝手に利用されないよう、認証やアクセス制限も必要です。
だから、この仕組みは、やはり最初の一歩ではありません。
メモを少し探しやすくしたいだけなら、フロントマターやタグから始めれば十分です。
Obsidianの検索で困っていないなら、全文検索だけでも十分です。
うろ覚え検索が欲しくなったら、ベクトル検索を考えればよいでしょう。
MCPまで進むのは、さらにその先です。
LLMとの会話の中で、自分の資料庫を自然に使いたい。
毎回ファイルを探して貼る手間を減らしたい。
保管庫が大きくなり、人間だけで探すには少し重くなってきた。
そうなったときに、保管庫MCPのような仕組みが選択肢になります。
大事なのは、保管庫をLLMに丸ごと覚えさせることではありません。
必要なときに探し、必要な分だけ読む流れを作ることです。
その流れを、チャット中のLLMからも使えるようにしたもの。
それが、筆者の保管庫MCPです。
6-5 RAGでサブスク制限に引っかからない？
実際に聞かれた質問ですので、この場をお借りしてお答えします。
まず、RAGとはRetrieval-Augmented Generationの頭文字を取ったもので、日本語だと「検索拡張生成」です。
仕組みは一言で言えば、LLMが答える前に、まず資料を検索して、見つかった内容を読ませてから答えさせるやり方です。
Retrieval（検索して取ってくる）で Augment（補強）した Generation（回答生成）、という意味です。
つまり、この本で学んできたことそのものが、RAGの骨組みのようなものだと思ってください。
保管庫MCPについて、「そんなにLLMに検索させて、サブスクの制限に引っかからないのか」と心配されたのが、この質問の意図になります。
なので、ここで一旦LLM使用量について整理してみます。
LLMの使用量は、多くの場合、第4章でも触れたコンテキスト量や、出力された回答量に左右されます。
回答量もある程度は指定できますが、毎回きれいに制御できるとは限りません。
そこで、今回はコンテキスト側で考えてみます。
人間が手動で必要最低限の資料を探して貼ることには、確かに負けます。
一方で、ごちゃ混ぜの資料を片っ端からすべてLLMに読ませて、必要な情報を探させるよりは、断然お得です。
特に、保管庫が大きければ大きいほど、お得度は上がるとも言えます。
第4章、第5章で述べた仕組みを思い出してください。
全文検索、ベクトル検索ともに、LLMとはまた別の仕組みが使われていました。
全文検索には、そもそもAI不要の仕組みがあります。
ベクトル検索では埋め込みモデルを使用しますが、これも回答文を生成するLLMとは別系統のモデルです。
つまり、探す部分は、回答を生成するLLM本体から切り分けられているのです。
しかも、筆者の保管庫MCPでは、第5章でも書いた通り、ベクトル検索の埋め込みにローカルのモデルを使用しています。
そうやって保管庫の内容を厳選してからLLMに渡すため、少なくとも筆者の使い方では、コンテキストの節約につながっています。
コンテキストの消費は使用量にも関わるため、結果としてサブスクでの制限にも引っかかりにくくなる可能性があります。
ただし、サブスク制限やAPI課金の仕組みはサービスによって違います。
検索を挟めば必ず得になる、とまでは言えません。
などと偉そうに書いていますが、正直、筆者はLLM重課金勢なので、胸を張っての断言ができないんですよね。
少なくとも使用量が極端に膨張したという感覚はありません。