そのAI、ルートを grep で掘り返してない？ ── MOC という知識地図で導く

Posted at 2026-07-07

はじめに：AI の探索を、もう少し美しく、静かに整える

LLM（大規模言語モデル）と Obsidian のようなローカルナレッジベース（Vault）を組み合わせ、AI アシスタントや自律型エージェントと一緒に自分の知識を育てていくスタイルが広がっています。

では、育てたその知識を実際に探索させる段になると、何を使っているでしょうか。オープンソースの拡張機能や自作スクリプトを介して、RAG（Retrieval-Augmented Generation）システムや AI コーディングツール（Claude Code、Gemini CLI 等）に情報を探させる ── そうした場面で、私たちは 「全文検索（grep）」 を多用していませんか？

「〇〇に関する記述を探して」と指示された AI は、ディレクトリ内のファイルを片っ端から検索し、キーワードが一致したファイルを大量に読み込みます。しかし、この「力任せの探索」は、便利である一方で、時に私たちのコンテキストを騒がしく、かつ不確実にしてしまう 4 つの課題を孕んでいます。

推論コスト（APIトークン）の膨張：無関係なファイルまでコンテキストに流し込むため、コンテキスト消費が指数関数的に増大する。
表記揺れによる見落とし：シノニム（類義語）や、数理的な抽象概念の表現揺れを拾えず、すぐ隣にあるはずの思考に気づけない。
探索の再現性の揺らぎ：同じ質問をしても、その時々のキーワードの引っかかり方で LLM が参照するコンテキストが変わり、出力の品質が安定しない。
構造的理解の不在：AI が「どの情報がどの概念の配下にあるか」という知識の階層を理解せず、点在する点（単語）の接続だけで回答を捏造（ハルシネーション）しやすくなる。

本稿では、この「 grep 主体の無秩序な探索」から一歩退いて、Obsidian における MOC（Map of Contents / 知識の地図） を AI の探索起点に据える、少し静かで効率的なナレッジ探索のあり方を提案してみたいと思います。

目指すところはシンプルです。必要な時に、必要な情報だけを、取り出す。 それだけです。

MOC を「AIの探索ルータ」として使う

Obsidian には、人間が知的整理を行うための慣習として MOC（Map of Contents） があります。ここでの提案はシンプルです。

「AIに検索させる」のではなく、「人間がすでに作った知識地図を、AIに辿らせる」

イメージとしては、こういう経路になります（以降、Vaultルートの MOC は Top_MOC.md、各ドメインの MOC は ドメイン名/MOC.md（例：AI/MOC.md）という命名で統一して表記します）。

Question
  ↓
Top MOC
  ↓
Domain MOC
  ↓
（必要なら Sub MOC）
  ↓
Concept Note
  ↓
必要なら grep（最終手段）

実際のフォルダ階層に落とすとこうなります。

Vault/
├─ Top_MOC.md (Vaultのルート地図)
├─ AI/ (AIエージェント研究)
│  ├─ MOC.md
│  ├─ Concept_記憶代謝.md
│  ├─ Concept_SCC.md
│  └─ Experiment_N30統計実験.md
├─ Writing/ (技術執筆・編集)
│  └─ MOC.md
└─ Security/ (セキュリティ・監査)
   └─ MOC.md

実際に AI/MOC.md の中身を覗くと、こういう見た目になります。

# 🤖 AIエージェント研究 MOC

このドメインでは、ローカルLLMやマルチエージェントシステムにおける
「記憶」と「同一性」を扱う。

## 概念ノート
- [[Concept_記憶代謝]] — 長期対話における記憶の圧縮・忘却メカニズム
- [[Concept_SCC]] — Self-Consistency Check、自己同一性の検証プロセス

## 実験ログ
- [[Experiment_N30統計実験]] — 忘却機構のN=30検証。p<0.0001で有意差を確認

## 関連ドメイン
- [[MOC_AI×Philosophy]] — 「記憶と自己」を哲学的に接続する交差ノート

見出しと箇条書き、そしてWikiLinksだけで構成された、ただのMarkdownファイルです。特別なプラグインも構文も要りません。AI は、キーワード一致で Vault 全体を掻き回すのではなく、まず Top_MOC.md を読み、次に指示に関連するドメインの MOC.md へとリンクを辿り、目的の Concept Note（さらには Raw Note）へとピンポイントにアクセスします。

具体例：実際の指示ではこう動く

たとえば、こんな指示を出したとします（あくまで一例です）。

「AIの実験ログについて続きをやりたい。準備して」

このときAIエージェントは、次のような経路を辿ります。

Top_MOC.md を開き、Vault全体の見出し一覧を確認する
「AI」というキーワードから AI/ ドメインを選ぶ
AI/MOC.md を開き、「実験ログ」セクションから [[Experiment_N30統計実験]] を見つける
Experiment_N30統計実験.md を直接読みに行く

grep主体の探索だと、実際にはこういう結果になります。

$ grep -rl "実験\|AI\|ログ" Vault/
AI/Experiment_N30統計実験.md                 ← 本当に欲しかったファイル
AI/20260702_Ablation_Study_Report.md         ← 別テーマ（SCC/忘却機構）の無関係な研究ログ
01_daily_note/daily/2026-06-12.md            ← 雑談の中で「実験」という単語が出てきただけ
Archive/2025-08-24_Note_Draft.md             ← 数ヶ月前の無関係な草稿
...（この後さらに数十件）

「実験」「AI」「ログ」という単語が同じというだけで、テーマも鮮度もバラバラなファイルが一緒くたに引っかかってきます。AIはこの中から欲しいものを探すために、結局すべて読んで判断するしかありません。

一方MOCルーティングでは、これだけです。

Top_MOC.md → AI/MOC.md → Experiment_N30統計実験.md

3ステップ、1ファイル。ノイズを読む必要も、判断する必要もありません。

ポイントは、GraphRAGのようにグラフを機械が自動生成するのではなく、ユーザーがすでに持っている MOC・リンク・バックリンク構造を、そのまま流用するという点です。

「`ls` や `tree` で十分では？」という疑問に

ここで当然浮かぶ疑問があります。「AIはそもそも ls や find、tree コマンドでフォルダ構造を直接読めるはず。なら、わざわざMOCを書かなくても、フォルダ名を辿らせれば同じことでは？」

結論から言うと、これは誤解です。AIがフォルダ名やディレクトリ構造を取得できないという技術的制約は存在しません。それでもMOCが必要な理由は、フォルダ階層そのものが持つ構造的な限界にあります。

1. フォルダ階層は木構造、MOCはグラフ構造

ファイルは物理的に1つのフォルダにしか置けません。しかし「AI × 哲学」のように複数のドメインにまたがる話は、フォルダ階層だけでは表現できません。フォルダを跨いだ関係性は、フォルダ名からは絶対に浮かび上がってこないのです（この問題への具体的な対処法は、後述の「個人Vaultでの最小実装」で扱う「交差専用MOC」です）。

2. フォルダ名は「分類ラベル」であって「関連性の説明」ではない

Articles/Resonance/ のようなフォルダ名を見ても、AIはその中の各ファイルが互いにどう関連しているか、どれが今重要でどれが古い草稿かまでは分かりません。MOCは「このノートとこのノートは繋がっている」という人間の判断を、プローズとWikiLinksとして明示的に書き記したものです。フォルダ名にはその情報は乗りません。

3. フォルダ一覧は「そこにある」を教えるだけで「見るべきか」は教えない

実際、筆者のVaultでもルート直下に、まだどのMOCにもリンクされていない生煮えのメモ書きが複数存在します。ls でルートを見れば、これらは他の重要ファイルと区別なくただ並んでいます。しかしMOCは意図的にこれらを載せていません。つまりフォルダ・ファイル一覧は「存在」を保証するだけで、「意味的に辿るべきかどうか」は保証しないのです。その選別をやっているのがMOCというわけです。

まとめると、全文検索（grep）とディレクトリ一覧（ls/tree）は同じ「力任せ」の系統に属し、MOCとは別の軸にあります。

比較対象：一般的なAI×Vault活用のアプローチ

この提案が何と比べて何なのかを整理しておきます。現状、AIにVaultを探索させる代表的なアプローチは次の2つです。

Embedding RAG

質問 → Embedding検索 → 類似チャンク → LLM

GraphRAG

質問 → Knowledge Graph → 関連ノード → LLM

いずれも「人間は構造化してくれない」という前提に立っています。実際、主要なObsidian AIプラグイン（Smart Connections：ダウンロード数78万超、Copilot、Local LLM Helper等）は軒並みEmbedding止まりで、MOCもGraphRAGも見ていないのが実態です。

先行事例：実はすでに近い発想がある

MOCをAIのルータにするという発想自体は、全く新しいものではありません。調べてみると、近い問題意識を持つ先行事例がいくつか見つかりました。

事例	内容
Chris Lettieri（Medium）	MOCノートからリンクの木を歩いて、そのMOCに特化したRAG範囲を作るという実践報告
Andrej Karpathy「LLM Wiki」	埋め込み・ベクトルDBなしで、LLMが自己管理インデックスを辿って探索するパターン。約40万語規模で実用に耐えると報告されている
`obsidian-wiki`（Ar9av）	Karpathyパターンを実装したフレームワーク。除去するとグラフが分断される「hub/bridge page」の分析機能も持つ
PageIndex	理論的に最も近い概念。ベクトルなし・LLM推論で文書の木構造（目次）を降りていく検索方式。ただし対象は単一文書
RAPTOR	階層木を作るが、ボトムアップかつアルゴリズムによる自動クラスタリング。人間が意図した概念構造とは限らない
GraphRAG（Microsoft）	Entity抽出 → Leidenコミュニティ検出 → 要約生成 → 検索、という4段階。索引構築コストが高い

つまり、「木構造・インデックスをLLM推論で降りていく」という発想自体には、すでに複数の先行研究・実装があります。この記事の主張は「新しいパラダイムの発明」ではなく、その系譜を ユーザーがすでに持っているMOC資産 の上でどう実践するか、という再解釈・実装ガイドに近い立ち位置です。

三者の立ち位置：Embedding / GraphRAG / MOCルーティング

Embedding RAG・GraphRAG・MOCルーティングの3つを並べて整理すると、それぞれの得意不得意がはっきりします。

	Embedding RAG	GraphRAG	MOCルーティング
構造の出所	構造なし（フラットなベクトル空間）	LLMが自動生成	人間がすでに構築済み
事前処理コスト	低い	高い（抽出→コミュニティ検出→要約）	ほぼゼロ
検索時の動き	クエリ→ベクトル化→類似度計算	クエリ→グラフ走査/コミュニティ検索	クエリ→木を上から降りる推論
得意なクエリ	局所的・具体的一致	コーパス全体のテーマ的質問	ドメインの位置が明確な質問
弱点	ノイズ、概念構造の喪失	コスト、entity解決の曖昧さ、木ではなくグラフの問題	木ではなくグラフの問題、MOCの鮮度依存、孤立ノート

核心の違いはここです。GraphRAGとMOCルーティングはゴール（階層的・意味的探索）は同じですが、構造の入手方法が真逆です。

GraphRAG：「構造がない」前提で、機械が構造を作り直す
MOCルーティング：「構造はもうある」前提で、それをそのまま使う

Embeddingはこの両者とは別軸で、そもそも構造という発想自体を持ちません。

言い換えると、MOCは「人間が最も高い解像度と文脈的なバイアスを持って構築した、コミュニティ要約」に近い性質を持っています。ただし注意が必要なのは、これが保証するのはリンク構造そのものがAIの捏造ではないという点であって、AIがリンク先のノート内容を正しく解釈・要約できることまでは保証しません。関係性の出所が信頼できることと、AIの読解が常に正確であることは別の話です。

もう一つ、地味だが重要な違いがあります。可視性です。GraphRAGのナレッジグラフやEmbeddingのベクトル空間は、人間が直接開いて「これは正しいか」を目で確認できる形をしていません（DB内部の表現や、数値の羅列を見て検証するのは現実的ではない）。一方MOCは、ただのMarkdownファイルとWikiLinksです。最初にそれを書いたのが人間であっても、AIが下書きしたものであっても関係なく、人間がその場で開いて読み、間違っていればその場で直せるという性質は変わりません。重要なのは「誰が最初に書いたか」ではなく、「常に人間が検証・修正できる形になっているか」の方です。

実務上は、この3つを役割分担させるハイブリッドが現実的だと考えています。

MOCルーティング（Coarse） → Embedding（Fine、葉ノード内） → GraphRAG（多段の関係推論が要る時だけ部分利用）

なぜこの発想はまだ広がっていないのか

ここまで読むと「じゃあなぜ誰もやっていないのか」という疑問が浮かぶはずです。正直に書いておきます。

MOCは公式仕様ではなく、ただの慣習です。運用品質がユーザー次第で、汎用プラグインとして作りにくい
多段のLLM推論（MOCを1段ずつ降りる）は、Embeddingの一発ベクトル計算より遅く、コストも高い。しかもこのコストは検索のたびに毎回発生する。GraphRAGのコストが主に事前のインデックス構築時（一度きり）にかかるのとは対照的です
発想自体がまだ新しく（Karpathy Wiki、obsidian-wiki、PageIndexいずれも最近の実装）、製品化する主体がまだ少ない
「ユーザーの構造を信頼する」という設計は、不特定多数に配布する汎用ツールにとってリスクが高い（フォルダ＝概念という前提が崩れているユーザーも多い）

ここまでのコストだけ見ると、Embeddingの方が合理的に思えるかもしれません。ただし、Embeddingが低コストなのは「概念構造そのものを保持できない」という弱点と引き換えです（前掲の比較表の通り）。Embeddingが捉えられるのは、あくまでテキスト自体の意味的な近さです。「語彙は違うけれど、人間がこの2つは関連していると判断した」という、テキストの外側にある分類の意図までは反映されません。MOCが払っている都度の推論コストは、「人間がすでに検証済みの、捏造のない構造をそのまま使える」という、Embeddingにはない保証への対価だと捉えてください。

つまりこれは技術的な壁ではなく、Vaultをきれいに切っている人がそもそも少数派であり、かつ汎用ツール化するには運用品質への依存が大きすぎる、というのが実態に近いと考えています。逆に言えば、日頃からMOCを丁寧に維持している個人のVaultであれば、今すぐ実践できる話でもあります。

個人Vaultでの最小実装

理論武装は不要で、実装自体は非常にシンプルです。

Vault/
 ├ AI/
 │   ├ MOC.md
 │   └ ...
 ├ Philosophy/
 │   ├ MOC.md
 │   └ ...
 ├ MOC_AI×Philosophy.md   ← ディレクトリ横断の交差専用MOC
 └ Top_MOC.md（Root）

各ディレクトリに MOC.md を置き、Root MOCから辿れるようにする
AGENTS.md（またはCLAUDE.md等）に「MOC→MOC→grep」の順で探索する指示を数行書くだけで動く
ディレクトリを跨ぐ関係（＝木ではなくグラフの問題）は、交差専用のMOCを作り、RootやドメインMOCから相互リンクしておけば解決します
- これは obsidian-wiki が機械的に検出しようとしている「bridge page」を、人間が最初から明示的に用意しておくのと同じ効果を持つ、より確実な方法です

ポイントは、Root MOCが「このクエリは交差MOCを見るべきか」を判断できるよう、Root（またはドメインMOC）に交差MOCへのリンクと簡単な要約を書いておくことです。

AI 共存型 Vault を育てる工夫

すべてのルートを MOC にそっと繋いでおく：孤立したノート（オーファンノート）を減らし、MOCや親概念ノートからのWikiLinksを意識的に貼る。上記の交差専用MOCもこの一環です
全文検索（grep）は「最終手段」と位置づける：AIに対し、「まずMOCを辿って目的の情報が見つからない場合のみ、補助手段としてgrepを使う」という優先順位を意識させる
MOCの段階で概念を緩やかに一般化しておく：マルチエージェントやAIが対外向けのアウトプット（執筆等）を行う場合、MOCの段階で概念が適切に一般化されていれば、AIは余計な文脈翻訳を挟むことなく意図に沿ったドキュメントを育められる
MOC自体の下書きはAIに任せてもいい：ゼロから全部手で書く必要はありません。出力形式まで指定した上で下書きさせ、内容を人間が確認・修正してから確定させれば十分です。MOCが保証しているのは「常に人間が検証・修正できる形になっている」という点であって、「最初の下書きを誰が書いたか」ではありません

「AI/ フォルダの中身をすべて読んで、AI/MOC.md を作って。見出しは ## 概念ノート ## 実験ログ ## 関連ドメイン のように分類し、各項目は [[ノート名]] — 一言で内容の要約 という形式でリストにして。内容が把握しきれないファイルがあれば、無理に分類せずそのまま報告して」

おわりに：人間が意味を紡ぎ、AI がその上を滑る

全文検索（grep）は便利ですが、AIにとっては「ただの砂漠をブルドーザーで掘り返すような作業」です。

人間がVaultという庭園に、MOCという名の小径を敷く。AIはその小径をなぞり、人間が意図した文脈とストーリーに沿って、必要な果実（知識）を的確に摘み取る。

ただし、これは万能の処方箋ではありません。上で見た通り、この方法が機能するのはVaultの構造そのものがすでに信頼できる形で維持されている場合に限られます。MOCが古くなっていたり、孤立ノートだらけだったりすれば、AIは間違った小径を歩かされるだけです。

それでも、日頃からVaultを丁寧に育てている人にとっては、今日から実践できる話です。あなたのVaultも、AIのための知識の地図として、そっと調律してみませんか？

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up