ここまで、LLMに書かせたメモは、後から探すときに自分の言葉とずれることがある、という話をしてきました。
では、いきなり大掛かりな検索の仕組みを作らなければならないのでしょうか。
もちろん、そんなことはありません。
まずできる一番手軽な工夫は、メモそのものに「後から探すための取っ手」を付けておくことです。
この章では、そのための方法として、マークダウンファイル、フロントマター、そしてタグを扱います。
3-1 マークダウンファイル、そしてObsidian保管庫
マークダウンファイルとは、ざっくり言えば、少しだけ書き方のルールがあるテキストファイルです。
普通の文章としてそのまま読めますが、見出しや箇条書き、リンク、強調などを、記号を使って表現できます。
例えば、行の頭に # を付けると見出しになります。
# 大きな見出し
## 小さな見出し
行の頭に - を付けると、箇条書きになります。
- ひとつめ
- ふたつめ
- みっつめ
こうした書き方を使うことで、ただの文章ファイルでありながら、人間にも読みやすく、アプリやツールでも構造を読み取りやすい形にできます。
Obsidianは、このマークダウンファイルを扱うメモアプリです。
Obsidian上ではきれいに表示されますが、実体は基本的に .md という拡張子のテキストファイルです。
Obsidian専用の閉じた形式ではなく、テキストエディタでも開けます。
ここが、今回の話ではかなり重要です。
マークダウンファイルは、特殊なデータベースの中に閉じ込められたメモではありません。
ファイルとしてフォルダの中に並んでいて、本文がそのまま文字として読めます。
そのため、検索もしやすく、LLMにも渡しやすいのです。
Obsidianで開くために作成したフォルダ一式を、この本ではObsidian保管庫、略して保管庫と呼びます。
保管庫の中には、マークダウンファイルのほかに、画像やPDFなどを一緒に置くこともできます。
とは言うものの、この本で主に扱うのは、本文をテキストとして読めるマークダウンファイルです。
人間が読める。
検索ツールも読める。
LLMにも読ませやすい。
この三つが揃っているからこそ、Obsidian保管庫は、後から検索性を育てていく素材として扱いやすいのです。
3-2 フロントマターとは何か
では、このマークダウンファイルに「後から探すための取っ手」を付けるには、どうすればよいのでしょうか。
そのために使える場所の一つが、フロントマターです。
フロントマターとは、マークダウンファイルの本文の前に置くメタ情報のことです。
タイトル、作成日や更新日、タグ、要約、後から探すための話題名など、独自に設定したものを含め、様々な情報を書けます。
つまり、マークダウンファイルの本文とは別に、検索用の情報を置くことができます。
さらにありがたいことに、Obsidianでは、表示設定や検索機能を使うことで、フロントマターを普段は目立たせずに扱ったり、フロントマター内の情報を検索したりできます。
日頃は本文だけを読みつつ、必要に応じてフロントマターを検索できるということです。
ここに、筆者が実際に使っているフロントマターの一例を挙げます。
2026-07-05-05-01（右耳さんは通さない）.mdという、ChatGPTとの会話をChatGPT自身にまとめてもらったファイルの冒頭部分です。
---
tags:
- LLMまとめ
- LLM補助
created: 2026-07-05
modified: 2026-07-05
writer_type: LLM
writer_name: ChatGPT
writer_role: チャッピー
writer_role_id: chatgpt
writer_interface: ChatGPT
source_type: conversation_summary
summary: "イヤーピース沼の話から、わーさん（筆者）の耳型・カスタムイヤモニ・SpinFit SSとSednaEarfit MAX SSの装着比較を通じて、右耳を基準にした小耳向けフィッティング方針が見えてきた。"
topics:
- イヤーピース沼
- SpinFit
- SednaEarfit MAX
- SednaEarfit MAX SS
- KZ Sonata
- Prophonics 2max
- センサフォニックス
- カスタムイヤモニ
- 耳型
- 小耳
- SSイヤーピース
- フィッティング
---ファイルの本文を読まなくても、writer_nameを見れば書き手がChatGPTだと分かり、summaryで何の話か掴め、topicsには具体的なグッズ名が並んでいます。
タイトルが「右耳さんは通さない」と比喩的でも、フロントマターを見れば中身の雰囲気が分かりますね。
ただし、どの情報を入れるか、どう名付けるかは、保管庫の使い方によってかなり変わります。
先ほどの例でも、 tags と作成日、更新日以外はほぼ筆者の独自項目です。
ここからは筆者の例をもとに解説しますが、あくまで一例として読んでください。
3-3 summary：タイトルの自由度を守る補助情報
まず見ていきたいのが、summary です。
summary は、そのファイルに何が書かれているのかを、一文で説明するための項目です。
日本語で言えば、要約です。
ただし、ここでいう要約は、本文の余韻や面白さをきれいにまとめるためのものではありません。
後から探すときに、「このファイルには何が書いてあるのか」を素早く判断するための補助情報です。
「いろいろ話した。」「楽しかった。」は summary としては働きません。
未来の自分への判断材料が何も残らないからです。
ファイルのタイトルは、ある程度自由に付けたいものです。
たとえば、先ほどの例に出した 2026-07-05-05-01（右耳さんは通さない）.md というタイトルは、筆者にとっては見れば思い出せる名前です。
けれども、これだけを見て「イヤーピースのフィッティングの話だ」と分かる人は、あまり多くないでしょう。
そこで、summary にこう書いておきます。
summary: "イヤーピース沼の話から、わーさん（筆者）の耳型・カスタムイヤモニ・SpinFit SSとSednaEarfit MAX SSの装着比較を通じて、右耳を基準にした小耳向けフィッティング方針が見えてきた。"これなら、タイトルが少し比喩的でも、本文を読む前にだいたいの中身が分かります。
つまり、summary はタイトルの自由度を守るための補助情報です。
タイトルを読み物らしく、あるいはその場の自分には分かる名前にしても、summary があれば検索用の説明を別に残しておけます。
筆者の運用では、summary は1文、80〜120字程度を目安にしています。
短すぎると探すときの判断材料にならず、長すぎると一覧で流し読みするときに目が滑るからです。
3-4 topics：後から探すための話題名
次に見ていきたいのが、topics です。
topics は、後から探すための話題名を並べておく項目です。
筆者の運用では、分類タグというより、「本文に出てきた具体的な話題の一覧」として使っています。
ここは、tags と少し役割が違います。
tags は、そのファイルが何の分類に属するか、どの用途で使うかを示すラベルです。
一方で、topics は、そのファイルの中に何の話が出てきたかを、検索しやすい形で並べるものです。
たとえば、先ほどの例では、tags には LLMまとめ や LLM補助 が入っていました。
これは、ファイル全体の分類を示す情報です。
分類することについては、次の節でも解説します。
一方、topics には次のような言葉が並んでいました。
topics:
- イヤーピース沼
- SpinFit
- SednaEarfit MAX
- SednaEarfit MAX SS
- KZ Sonata
- Prophonics 2max
- センサフォニックス
- カスタムイヤモニ
- 耳型
- 小耳
- SSイヤーピース
- フィッティングこちらは、本文に登場した具体的な話題名です。
後から「SpinFitの話、どこでしたっけ」「小耳向けのイヤーピースの話を探したい」と思ったとき、こうした単語が topics に入っていると、検索の手がかりになります。
つまり、topics は未来の自分やLLMのために置いておく、検索用の付箋です。
このとき大事なのは、抽象的すぎる言葉だけで埋めないことです。
たとえば、AI、LLM、雑談、作業 のような広すぎる言葉だけでは、後から探すときの手がかりとして弱くなります。
代わりに、固有名詞、企画名、ツール名、作品名、人名、具体的なテーマを優先します。
そのファイルを探す未来の自分が、検索窓に入れそうな言葉を並べておくイメージです。
本文に出てきた言葉。
未来の自分が探しそうな言葉。
LLMに拾ってほしい固有名詞。
topics には、このあたりを入れておくと、かなり探しやすくなります。
3-5 カテゴリ、タグ、トピックスを分けて考える
ここで一度、カテゴリ、タグ、トピックスの違いを整理しておきます。
どれも「後から探しやすくするための情報」ではあります。
ただし、役割は少しずつ違います。
筆者は、ざっくり次のように分けています。
- カテゴリ：そのファイルをどこに置くか
- タグ：そのファイルが何に使われるか、どんな状態か
- トピックス：そのファイルの中に何の話が出てきたか
まず、カテゴリは置き場所です。
Obsidian保管庫のフォルダ分けに該当します。
たとえば、筆者の保管庫には LLM会話サマリー、LLM wiki、雑録、創作 などのフォルダがあります。
これは、「このファイルは保管庫のどの棚に置くか」という考え方です。
次に、タグは分類や用途のラベルです。
たとえば、先ほどの例では、次のようなタグを付けていました。
tags:
- LLMまとめ
- LLM補助これは、そのファイルが「LLMとの会話をまとめたもの」であり、「作成過程にLLMの補助が入ったもの」だと示しています。
タグは、本文に何が出てきたかを全部並べる場所というより、ファイル全体の性質や使い道を示す場所です。
公開用か、下書きか、会話まとめか、資料メモか。
そういった大きめの分類に向いています。
一方、トピックスは中身の話題名です。
SpinFit、KZ Sonata、カスタムイヤモニ、小耳 のように、そのファイルの本文に登場した具体的な言葉を並べます。
タグが「このファイルは何者か」を示すものだとすれば、トピックスは「このファイルの中に何がいるか」を示すものです。
この二つを混ぜてしまうと、後から少し探しにくくなります。
たとえば、tags に SpinFit や KZ Sonata まで全部入れていくと、タグ一覧がどんどん膨れ上がります。
その結果、本来見たいはずの LLMまとめ や 下書き、公開候補 のような分類タグが埋もれてしまいます。
逆に、topics に LLMまとめ や 資料 のような広い言葉ばかり入れても、検索用の手がかりとしては弱くなります。
なので、筆者の運用では、次のように考えています。
- カテゴリ：どの棚に置くか
- タグ：どういう種類・用途のファイルか
- トピックス：本文に出てきた具体的な話題は何か
もちろん、これは絶対のルールではありません。
小さな保管庫なら、タグだけで十分かもしれません。
逆に、大きな保管庫では、カテゴリ、タグ、トピックスを分けておいた方が、後から検索するときに楽になります。
大事なのは、どの項目に何を書くかを、自分の中である程度決めておくことです。
分類したいのか。
状態を示したいのか。
本文中の話題を拾いたいのか。
この役割分担が決まっていると、LLMにメモをまとめてもらうときにも指示しやすくなります。
3-6 LLMにフロントマターを付けてもらう
ここまで、summary、topics、tags の役割を見てきました。
では、これらを毎回自分で書かなければならないのでしょうか。
もちろん、自分で書いても構いません。
けれども、LLMとの会話をまとめたメモなら、最初からLLMにフロントマター付きでまとめてもらうのが楽です。
たとえば、会話の最後に次のように頼みます。
細かい形式は自分の運用に合わせて変えて構いません。
この会話を、以下のフロントマター付きMarkdownとしてまとめてください。
- summary は1文、80〜120字程度
- topics は本文に出てきた具体的な話題名を5〜15個
- tags は分類や用途を示すもの
- created / modified も入れる
こうしておけば、LLMが本文をまとめるときに、検索用の取っ手も一緒に付けてくれます。
既存のファイルに後からフロントマターを付けたい場合も、数が少なければLLMに一つずつ頼めます。
ファイル数が多い場合は、コーディングエージェントにまとめて整備してもらう手もあります。
ただし、LLMが付けた summary や topics が、いつも自分の感覚にぴったり合うとは限りません。
その場合は、人間が直しましょう。
検索するのは未来の自分です。
そのため、気に食わない要約や、後から探さなさそうな話題名が入っていたら、遠慮なく直せば良いのです。
フロントマターは、LLMに任せきりにするものではありません。
未来の自分が探しやすくなるように、LLMに下書きしてもらい、必要に応じて整えるものです。
3-7 梅コースの限界
ここまで見てきたように、フロントマターとタグを整えるだけでも、LLMメモはかなり探しやすくなります。
特に、メモの数が数十から数百くらいであれば、この梅コースだけでも十分役に立つはずです。
ただし、もちろん限界もあります。
まず、フロントマターに書いていない言葉は、フロントマター検索では拾えません。
本文の中には出てくるけれど、summary や topics に入っていない言葉は、見落とされる可能性があります。
また、ファイル数が増えてくると、たとえフロントマターが整っていても、候補を人間が眺めるだけで大変になってきます。
さらに、LLMに探してもらう場合にも問題があります。
大量のファイルやフロントマターをまとめて読ませようとすると、それだけでコンテキストを消費してしまいます。
つまり、梅コースは「メモに検索用の取っ手を付ける」方法としてはかなり有効です。
けれども、保管庫全体が大きくなってくると、その取っ手をどう探すか、という問題が出てきます。
そこで次の段階では、本文全体を検索のふるいにかける方法を考えます。
それが、竹コースの全文検索です。