第3章では、フロントマターやタグを使って、メモに後から探すための取っ手を付ける方法を見てきました。
けれども、取っ手を付けたファイルが、100枚、1000枚、2000枚と増えていったとき。
その中から、必要な1枚をどうやって見つければよいのでしょうか。
今度は、取っ手や本文の中身を手がかりにして、ほしい内容を探す仕組みが必要になってきます。
この章では、そのための方法として、全文検索を扱います。
4-1 LLMに渡す前に、まず検索で絞る
竹コースの考え方は、突き詰めれば一つです。
読む前に、まず絞る。
人間がObsidianで何かを探すときのことを思い出してください。
2000枚のファイルを上から順に開いていく人は、まずいません。
検索機能で候補を数枚まで絞り込んで、それから中身を確かめるはずです。
LLMに資料を渡すときも、これと同じ考え方が使えます。
保管庫全体をいきなりLLMに読ませるのは、現実的ではありません。
LLMが一度の会話で読める量には、上限があります。
この、LLMが読み込んで覚えていられる範囲のことを、コンテキストと呼びます。
コンテキストには限りがあるうえ、たくさん詰め込むほど、返事の質や応答速度、場合によっては利用料金にも響いてきます。
仮に保管庫全部を詰め込めたとしても、その大半は今の相談には関係のないファイルです。
関係のない2000枚で、LLMの手荷物をいっぱいにする必要はありません。
だから、先に検索でふるいにかけます。
まず、話題に関係しそうな言葉で保管庫を検索する。
出てきた候補の一覧を眺めて、関係しそうなファイルにあたりを付ける。
そのうえで、必要なファイルだけを自分で読むなり、LLMに渡すなりする。
これが、竹コースの基本の流れです。
実は、検索結果の一覧をそのままLLMに渡すだけでも、かなり楽になります。
たとえば、検索で出てきたファイル名と、該当箇所の前後の文章を貼り付けて、「この候補の中から、今の相談に関係しそうなものを教えてください」と頼めます。
LLMが「これが関係ありそうです」と答えてくれたら、そのファイルだけを開いて渡せばよいのです。
探すのは検索。
選ぶのはLLMと自分。
読ませるのは選んだ分だけ。
この分担ができるようになると、保管庫が大きくても、LLMとのやり取りは軽いままで済みます。
では、その「検索」の部分では、何を探しているのでしょうか。
次の節では、全文検索とは何かを見ていきます。
4-2 全文検索とは何か
前の節で、読む前にまず絞る、という竹コースの基本を見ました。
では、その絞り込みは、誰がやるのでしょうか。
人間が読めば、手間がかかります。
LLMに読ませれば、それだけでコンテキストを消費します。
第3章の最後で触れた、梅コースの限界です。
竹コースでは、ここを「読まない機械」に任せます。
全文検索の仕組みは、実はとても単純です。
入れた言葉と一致する箇所を、保管庫の中のテキストから探してくる。
中身を理解しているわけではありません。
基本的には、それだけです。
けれども、読んでいないからこそ、速いのです。
2000枚あっても一瞬で答えが返ってきますし、LLMのコンテキストも消費しません。
ここで大事なのは、「テキストで書かれているものなら、まとめて探せる」ということです。
本文はもちろん、フロントマターも、テキストである以上、検索の対象になります。
第3章で付けた summary や topics は、そのまま「引っかかる場所」として働き続けます。
そのうえで、取っ手に入れそこねた、本文の中の言葉まで拾えます。
第1章の「宣伝 苦手」のようなメモも、本文に書いてありさえすれば、全文検索なら見つけられるのです。
では、この全文検索を使うには、特別な道具が必要なのでしょうか。
実は、Obsidianの標準検索が、すでに全文検索です。
検索窓に言葉を入れれば、保管庫の中のファイルを横断して探してくれます。
だから、竹コースの入口に、新しい道具は要りません。
探すときに、目で辿るのではなく、検索窓に言葉を入れる。
その習慣ができれば、もう竹コースは始まっています。
ただし、一つだけ覚えておいてほしいことがあります。
全文検索が探しているのは、あくまで「入れた言葉と一致する箇所」です。
意味が近くても、言葉が違えば、拾えません。
読まないから速い。
読まないから、意味は分からない。
この裏表は、あとでもう一度出てきます。
頭の隅に置いたまま、先に進みましょう。
4-3 人間は何を覚えているのか
前の節で、全文検索は「入れた言葉と一致する箇所」を探す仕組みだと説明しました。
では、その「入れる言葉」は、どこから持ってくればよいのでしょうか。
ここで、第1章の困りごとを思い出してください。
LLMが書いたメモは、あなた自身の語彙だけで書かれているとは限りません。
そして未来のあなたは、書かれたときとは違う語彙で探しに来ます。
つまり、探したい文章そのものは、たいてい覚えていないのです。
けれども、何も覚えていないわけではありません。
たとえば、筆者が「あのイヤーピースのメモ、どこだっけ」となったとき。
本文にどう書いたかは、まったく思い出せません。
それでも、これくらいは覚えています。
- だいたいの時期。たしか7月の上旬だった
- 話題。イヤーピースの話。メモには「イヤピ」と略して書いたかもしれない
- 置いた棚。日記のフォルダに入れた気がする
文章は忘れても、時期は覚えている。
正確な言葉は怪しくても、話題は覚えている。
中身はぼんやりしていても、どの棚に置いたかは、なんとなく覚えている。
人間の記憶は、こういう断片の寄せ集めです。
そして、竹コースで大事なのは、ここからです。
覚えている断片を、検索条件へ変換する。
これが、この章の基本の考え方です。
「7月上旬」は、日付の条件になります。
「イヤピかイヤーピース」は、表記揺れを含めた言葉の条件になります。
「日記のフォルダ」は、検索範囲の条件になります。
一つひとつの断片は、頼りないものです。
「7月上旬」だけでは、その期間のメモが全部出てきてしまいます。
「イヤピ」だけでは、別の月のイヤホン話まで引っかかるかもしれません。
けれども、条件は重ねられます。
7月上旬の、イヤピかイヤーピースの話で、日記フォルダにあるもの。
ここまで絞れば、候補はかなり減っているはずです。
あとは、残った候補を開いて確かめるだけです。
完全な言葉を思い出す必要はありません。
断片を条件に変えて、重ねて、絞る。
それができるなら、うろ覚えは、検索の敵ではなく材料になります。
では、その条件は、具体的にどう書けばよいのでしょうか。
実は、ここで第3章の取っ手が効いてきます。
次の節で、付けた取っ手を検索側から掴みに行きましょう。
4-4 3章で付けた取っ手を、検索側から掴む
前の節で、三つの断片が手元に残りました。
7月上旬。イヤピかイヤーピース。日記の棚。
これを、Obsidianの検索窓の言葉に変換していきましょう。
まずは、一番思い出しやすい「話題」からです。
検索窓に イヤーピース と入れれば、本文にその言葉があるファイルが出てきます。
けれども、メモには「イヤピ」と略して書いたかもしれないのでした。
こういうときは、ORで繋ぎます。
イヤピ OR イヤーピース
これで、どちらかの表記を含むファイルが全部出てきます。
ちなみにORは大文字です。小文字のorだと、ただの検索語として扱われます。
次に、「棚」の条件です。
フォルダで絞るには、path: という演算子を使います。
path:日記 (イヤピ OR イヤーピース)
これで、パスに「日記」を含むファイルのうち、イヤピかイヤーピースの話をしているものだけに絞れました。
さて、残るは「7月上旬」です。
ここで正直に書いておくと、Obsidianの標準検索には、「この日からこの日まで」と期間を指定する演算子がありません。
じゃあ、時期の記憶は使えないのか。
実は、使えます。ファイル名に日付が入っていれば。
筆者の日記は、2026-07-05.md のように、ファイル名が日付そのものです。
ファイル名は file: という演算子で検索できます。
file:2026-07-0 (イヤピ OR イヤーピース)
2026-07-0 に一致するのは、2026-07-01から2026-07-09までです。
10日も含めて「7月上旬」にするなら、file:2026-07-10もORで足します。
path:日記 (file:2026-07-0 OR file:2026-07-10) (イヤピ OR イヤーピース)
これで、前の節に残っていた三つの断片が、一つの検索式になりました。
ファイル名に日付を入れるのは、よくある命名の習慣です。
けれどもこうして見ると、あれは単なる几帳面さではありません。
未来の自分が「時期」で絞れるようにする、立派な検索用の取っ手です。
そして、取っ手といえば。
第3章で付けたフロントマターも、専用の演算子で直接掴めます。
タグは tag: で探せます。
tag:#LLMまとめ
これは、本文のどこかに「LLMまとめ」と書いてあるファイルではなく、タグとしてLLMまとめが付いたファイルだけを返します。
分類として付けたタグを、分類として引ける。
ここが、本文中の文字列をそのまま探す場合との違いです。
topics のようなプロパティは、角括弧で探せます。
[topics:SpinFit]
これで、topicsにSpinFitを入れたファイルが出てきます。
本文に一度もSpinFitと書いていなくても、取っ手にさえ入っていれば、掴めるわけです。
3章で「後から探さなさそうな話題名は直しましょう」と書いたのは、このためでした。
あのとき整えた取っ手が、ここで検索の持ち手になります。
最後に、探し方の流れを一つだけ。
条件は、最初から全部盛りにしなくて構いません。
まず イヤピ OR イヤーピース だけで検索してみる。
候補が多すぎたら、path:日記 を足す。
まだ多ければ、ファイル名の日付条件を足す。
緩く探して、多ければ絞る。
覚えている断片の数だけ、絞る手段があるのですから。
……と、ここまで読んで、こう思いませんでしたか。
便利そうだけど、この検索式を毎回書くのは、めんどくさくないか。
めんどくさいです。
次の節では、そのめんどくささの話をします。
4-5 検索クエリもLLMに作らせる
前の節の終わりに置いた、めんどくささの正体を分解してみましょう。
演算子の書式を覚えるのが、めんどくさい。
表記揺れを思いつく限り列挙して、ORで繋ぐのが、めんどくさい。
日付やフォルダの条件を、毎回組み立てるのが、めんどくさい。
先に言っておくと、これはあなたの努力が足りないのではありません。
全文検索を使いこなそうとすれば、誰の前にも現れる、ごく普通の摩擦です。
そして、ここで思い出してほしいのです。
断片を検索条件へ変換する。それが竹コースの基本思想でした。
この「変換」、実はLLMの得意分野です。
だったら、変換もLLMにやってもらいましょう。
人間がやることは、覚えている断片を、そのまま自然言語で伝えるだけです。
2026年7月上旬に、イヤーピースの話を日記に書いた気がします。
略して「イヤピ」と書いたかもしれません。
日記は「日記」フォルダにあり、
ファイル名は「2026-07-05.md」のような日付形式です。
Obsidianの標準検索で使える検索式にしてください。
表記揺れはORで拾ってください。
LLMは、こういう式を返してきます。
path:日記 (file:2026-07-0 OR file:2026-07-10) (イヤピ OR イヤーピース)
前の節で、私たちが手で組み立てた式と同じものです。
書式を覚えるのも、ORを組むのも、全部向こうがやってくれました。
しかも、LLMに任せると、人間より気が利くことがあります。
たとえば、「表記揺れがありそうなら、ORで入れておいて」と一言添えれば、自分では思いつかなかった言い換えまで拾ってくれるかもしれません。
「候補が多すぎたら、次にどう絞ればいいかも教えて」と頼めば、絞り込みの二手目まで提案してくれます。
覚えている断片を話すのは、人間。
それを検索式に変換するのは、LLM。
検索窓に貼って、結果を確かめるのは、また人間。
この分担ができると、竹コースの景色が変わります。
検索の操作は、まだ人間がやっています。
けれども、検索の戦略は、もうLLMと一緒に立てているのです。
ただし、注意点が二つあります。
一つ。検索の演算子は、道具ごとに違います。
Obsidianの path: や file: は、Obsidianの書き方です。
別のツールには、別の書式があります。
だから、LLMに頼むときは、どの道具で検索するのかを伝えてください。
心配なら、その道具のヘルプページの検索の項を渡してしまうのが確実です。
二つ。出てきた式は、動くとは限りません。
LLMは、それらしい演算子を、それらしく書いてくることがあります。
存在しない演算子が混ざっていても、見た目は堂々としたものです。
だから、生成された式は、一度検索窓に入れて、動くかを確かめてください。
下書きはLLM、確認は人間。
第3章で、フロントマターを人間が直したのと、同じ理屈です。
さて、これで検索式のめんどくささは、だいぶ軽くなりました。
けれども、そもそもの話をしてもいいでしょうか。
毎回、全文検索から始める必要は、あるのでしょうか。
実は、もっと安く探せる場面が、結構あるのです。
4-6 いきなり全文検索せず、安い手掛かりから探す
前の節の終わりに、少し不穏なことを言いました。
毎回、全文検索から始める必要は、あるのでしょうか。
もちろん、全文検索は頼れるふるいです。
けれども、探す手段には、実はコストの差があります。
ここで比べるのは、探すその場で人間が払う手間です。
仕組みを事前に作り、維持する手間については、あとで別に考えます。
一番安いのは、ファイル名を見ることです。
ファイル名は、メモを作れば必ず付きます。
日付や話題が分かる名前にしてあれば、それだけで検索の手掛かりになります。
たとえば、例の「イヤピのメモ」。
日記フォルダを開いて、7月上旬のファイル名を眺める。
筆者の日記はファイル名が日付ですから、候補は最初から10枚しかありません。
検索式を書くまでもなく、開いて確かめられる枚数です。
次に安いのは、分類や索引を見ることです。
タグを付けてあるなら、タグの一覧から辿れます。
LLMまとめ のタグを開けば、会話まとめだけが並びます。
さらに、索引を自分で育てている人もいます。
話題ごとに、関連するメモへのリンクを一枚に集めたノート。
Obsidian界隈では、MOCと呼ばれたりします。Map of Content、内容の地図です。
イヤホン関連のメモへのリンクを集めた一枚があれば、イヤピの話は、まずそこから辿れます。
本の巻頭にある目次を、自分の保管庫に作るようなものです。
そして一番高いのが、全文検索です。
高いといっても、機械は一瞬で答えます。
高くつくのは、人間の側です。
検索語を考え、表記揺れを拾い、条件を組み、出てきた候補を選り分ける。
前の節でLLMに任せた、あの手間のことです。
だから、探す順番は、こうなります。
ファイル名で分かるなら、ファイル名で。
索引があるなら、索引から。
それでも見つからないときに、全文検索。
安い手掛かりから順に使って、外れたら次へ進む。
最初から一番強い道具を持ち出さなくてもよいのです。
ただし、正直に書いておきます。
分類や索引は、探すときには安く使えます。
けれども、その安さは、先に誰かが準備してくれた結果です。
タグを使うには、メモへタグを付けておく必要があります。
タグ付けくらいであれば、第3章で述べた通り、LLMに頼むのもよいでしょう。
一方で、MOCを使うには、リンクを集めたノートを作り、メモが増えれば育て直す必要があります。
こうして手作りしたMOCは強力です。
強力ですが、作るのも維持するのも、めんどくさい。
だからこの本は、索引を全員に勧めはしません。
よく探す話題が決まってきたら、その話題の分だけ作ればよい、くらいの距離感です。
さて、この「安い順に探す」という考え方。
実は、人間だけのものではありません。
LLMに保管庫を探させるときにも、まったく同じ順番が効きます。
むしろ、機械にこそ効くと言ってもいいくらいです。
次の節では、コーディングエージェントに保管庫を探させる話をします。
4-7 コーディングエージェントに直接探させる
ここまでの竹コースは、検索式を作るところまではLLMに任せても、検索の操作そのものは人間がやってきました。
今一度、この本の出発点を思い出してください。
探した資料は、最終的にLLMに渡したいのでした。
だったら、その「探す」ところごと、LLMにやってもらえないのでしょうか。
実は、やってもらえます。
Claude CodeやCodexのような、手元のPCで動くコーディングエージェントは、ファイルを検索する道具を最初から持っています。
保管庫のフォルダで作業させれば、「まず検索して、当たりのついたファイルだけ読んでください」と頼めます。
いきなり全部読ませない。
まず検索で絞って、必要な分だけ読む。
4-1で見た竹コースの流れを、探すところごと、エージェントに任せられるわけです。
ただし、筆者の実感を正直に書いておきます。
エージェントに検索を丸投げすると、割と外れます。
なぜ外れるのか。
それを知るには、エージェントの持ち物を覗いてみるのが早道です。
実装や名前は製品ごとに違いますが、この種のエージェントがよく使う検索手段は、大きく二つに分けられます。
一つは、ファイル名やパスのパターンから候補を探す方法。globと呼ばれます。
もう一つは、ファイルの中身から文字列の一致を探す方法。grepと呼ばれます。
名前は厳ついですが、正体はもう知っているはずです。
globは、ファイル名やパスから探すこと。
grepは、ファイルの本文を、文字列の一致で探すこと。
役割としては、ここまで見てきた全文検索に近いものです。
つまりエージェントは、前の節で見た「安い手掛かり」の一番安いものと、一番高いものを、最初から持っているのです。
機械にとって高くつくのは、検索にかかる数秒よりも、そのあと大量の候補を読み、コンテキストを使うことです。
globで外れれば、grepに進む。
そのgrepの検索語は、エージェントが自分で選びます。
ここに、外れの正体があります。
エージェントの選ぶ言葉は、あなたのメモの語彙と、微妙にずれることがあります。
そして全文検索は、単語一致のふるいです。
ずれた言葉には、ずれた結果を正直に返します。
さらにもう一つ。
少なくとも、筆者が使ってきたエージェントを放っておくと、手順の真ん中が抜けがちです。
ファイル名で探す。だめなら全文検索。
前の節の三段構えでいえば、二段目の「索引を見る」が、すっぽり空いているのです。
だったら、埋めましょう。
筆者の友人は、エージェントにこう指示しています。
まず、globでファイル名から探す。
見つからなければ、タグごとの関連メモをまとめたMOCを読む。
それでも見つからないときだけ、grepする。
人間の探し方と、同じ形になったのが分かるでしょうか。
安い手掛かりから順に、外れたら次へ。
4-6の考え方は、そのまま機械の操縦法になるのです。
MOCを読ませる利点は、もう一つあります。
索引には、そのメモを表す言葉が、人間が整えた語彙で並んでいます。
エージェントが自前で検索語を発明する前に、保管庫の語彙に触れさせられるわけです。
なお、エージェントからObsidianの標準検索を呼び出せる、Obsidian CLIのような道具もあります。
この章で見た演算子ごと、エージェントに使わせる道です。
Obsidian CLIの利用条件やコマンドは、Obsidianのバージョンによって変わる可能性があります。
気になった方は、公式ヘルプを確認してください。
ただし、Obsidian CLIを使わせたいなら、どの道具から使うかを明示しておくのが確実です。
何も指定しないと、何でもglobとgrepで解決しようとするエージェントもいます。
その癖は、筆者と友人の間では、すでに共通の笑い話になっています。
LLMの癖は、直すものではなく、操るもの。
道具の使う順番を指示するだけで、エージェントの検索は見違えます。
筆者の運用では、基本的に丸投げにはしていません。
企画の中核になるファイルは、名前を手動で指定する。
周辺の資料集めを、検索に任せる。
芯は人間が渡す。
裾野は検索に任せる。
第3章でフロントマターを人間が直したのと、同じ理屈です。
こうして、手元のエージェントは、保管庫を探せるようになりました。
けれども、使っている道具は、まだエージェントの手持ちの品です。
もっと本格的に、検索そのものを機械に仕込みたくなったら、どうすればよいのでしょうか。
4-8 検索を機械の道具にする
その答えの一つが、検索専用のエンジンです。
Meilisearchのような全文検索エンジンは、PCやサーバーで動く、検索の専門家です。
あらかじめ保管庫の中身から索引を作っておき、問い合わせが来たら、索引を引いて一瞬で答えを返します。
この、あらかじめ作っておく索引のことを、インデックスと呼びます。
本の巻末の索引と同じ考え方です。
どの言葉がどのページにあるかを先にまとめてあるから、毎回全ページをめくらずに済むのです。
ただし、索引は育てる必要もあります。
4-6で「あとで別に考える」とした維持の手間が、ここにも顔を出すわけです。
この話は、第6章で改めて触れます。
ここでもう一つ、白状しておきます。
筆者は、Meilisearchを人力検索に使う方法を知りません。
実際にはそういう使い方もできるらしいのですが、詳細は調べてもいません。
それでよいのです。
検索エンジンは、Obsidianの検索窓のように、人間が眺めるための画面を中心にした道具ではありません。
代わりに、プログラムからの問い合わせを受け付ける窓口を持っています。
ですのでこの本では、人間の道具ではなく、機械に持たせる道具として紹介します。
少なくとも筆者の用途では、人間が見るだけなら、Obsidianの検索窓で足ります。
検索エンジンが欲しくなるのは、機械側にも竹コースを本気でやらせたくなったときです。
なお、どのエンジンを選び、どう組み立てるかという構築の手順は、この本では扱いません。
そこはコーディングエージェントと相談しながら進められる領域ですし、大事なのは「検索を機械の道具にする」という考え方の方だからです。
ところで、手元のエージェントはこれで保管庫を引けるようになりました。
では、スマホでチャットしているときのLLMは、どうでしょうか。
チャット画面の向こうにいるLLMからは、手元のPCの中の窓口には届きません。
ここを繋ぐ話は、第6章で扱います。
その前に、竹コースの限界を確かめておきましょう。
4-9 竹コースの限界
全文検索は、ここまで見てきた通り、頼れるふるいです。
取っ手も本文もまとめて探せて、速く、コンテキストも消費しません。
検索式はLLMに作らせられますし、機械に持たせれば、読ませる前の絞り込みまで任せられます。
ただし、もちろん限界もあります。
4-2の終わりに置いた言葉を、ここで回収しましょう。
読まないから速い。
読まないから、意味は分からない。
全文検索が探しているのは、あくまで「入れた言葉と一致する箇所」でした。
だから、意味がどれだけ近くても、言葉が違うものは拾えません。
この章では、その弱点に、ずいぶん手を打ってきました。
「イヤピ」と「イヤーピース」の揺れは、ORで繋いで拾いました。
思いつかない言い換えは、LLMに広げてもらいました。
けれども、よく見てください。
ORで拾えるのは、誰かが思いついた揺れだけです。
LLMに広げてもらっても、網の正体は、言葉の列挙です。
「宣伝が苦手」と書いたメモを、後から「告知がつらい」と探す日が来る。
そんな言い換えまで、あらかじめ全部列挙しておくことは、誰にもできません。
summary や topics の取っ手も、この語彙ずれをある程度は吸収してくれます。
けれども、取っ手に入れた言葉と、未来の自分が検索窓に入れる言葉がずれてしまえば、やはり一致はしません。
4-7で見た、エージェントの検索が割と外れる話も、根っこは同じです。
エージェントの選ぶ言葉と、メモに書かれた言葉がずれれば、単語一致のふるいは、ずれた結果を正直に返します。
つまり、竹コースの限界とは、単語一致という性格そのものです。
4-3で、うろ覚えは検索の材料になる、と書きました。
時期や棚のように、条件に変換できる断片があるうろ覚えなら、竹はよく効きます。
けれども、覚えているのが「あんな感じの話」だけだったら。
条件に変換できる断片が、一つも残っていなかったら。
うろ覚えでも、言い換えでも、話題さえ近ければ拾ってほしい。
そう思うようになったら、次の段階です。
言葉の一致ではなく、意味の近さで探す仕組み。
それが、松コースのベクトル検索です。