TL;DR

• ZettelkastenをRAGの情報源として使う場合、ノート間のリンクに意味（修飾子）がなければ、AIはグラフを無限に辿ってコンテキストが膨張する 。
• 人間はリンクの意味をノートの文脈から推測できるが、AIにはその判断ができない。これは「人間にとってわかりやすいリンクはAIにとって分からない」という構造的な非対称性である。
• データの意味付けを軽視してきた歴史（セマンティックウェブ、ビッグデータ、企業RAG）は、同じ失敗パターンの繰り返しだと解釈できる。
• 修飾子として supports → / contradicts → / refines → / depends_on → の4種を提案する。
• コンテキストが膨張するとOOMによるクラッシュ（MLX）や推論崩壊（llama.cpp）が起きる。これは設計の問題であり、パラメータ調整で解決できるものではない。
• 実際に計測したところ、修飾子によるトラバーサル制御でトークン使用量を約70%削減（556,006 → 163,782トークン）しながら、回答品質をほぼ維持できることを確認した。
• ただし、リンクの修飾子だけが解決策ではない。どこを意味付けし、どこをしないかという全体設計が必要である。

きっかけ

『ローカルLLMでSpec Driven Developmentは、まだ難しかった』という記事を書きながら、「自分のZettelkastenをRAGの情報源として接続すれば、自分の思考を元にした回答が得られるのではないか」という考えが浮かんだ。

ただし、この設計を考えるにあたって、一つの前提がある。過去にAIにノート操作を任せた結果、Zettelkastenがノイズだらけになるという失敗を経験している（『Zettelkastenで管理する情報は何で、どう管理すべきなのか』、『Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない。』）。その経験から、「AIはZettelkastenを読むことはできるが書いてはいけない」という原則をすでに確立している。今回の設計はその原則の上に成り立っている。

しかし、実際に試そうとした瞬間、問題が見えてきた。Zettelkastenのノートはネットワーク型の構造になっており、ノート間には無数のリンクが張り巡らされている。RAGとして使うということは、AIがそのネットワークを辿ってコンテキストを組み立てることになるが、「どのリンクをどこまで辿るか」という制御をどうするかが難しい。

そこで少し考えてみると、問題の本質は「ノート間のリンクに意味付けがされていない」ことだという考えに至った。

ZettelkastenとRAGの相性問題

そもそもRAGとは何かを整理しておく。RAGは、LLMが一般的な訓練データから回答を生成するのではなく、特定のドキュメント群（情報源）を参照しながら回答する仕組みだ。ハルシネーションの影響範囲を限定し、特定ドメインに閉じた回答を得るための構造設計の方法論として使われる。具体的には、Zettelkastenとの組み合わせで期待できるのは、「自分の思考・知識を格納したナレッジベースを、AIが参照しながら回答できるようになること」だ。

ところが、ZettelkastenをそのままRAGに投げると問題が起きる。Zettelkastenのノートはそれぞれが他のノートへのリンクを持っており、関連するノートをどんどん参照する構造になっている。AIがネットワークを辿り始めると、関連ノートをすべて読み込もうとしてしまい、コンテキストが際限なく膨張する。

これは設計の問題だ。RAGという文脈においては、どのリンクをどこまで辿るかを制御する「トラバーサル制御」がなければ、Zettelkastenは有用な情報源にならない のである。

リンクの「意味」は、人間は理解でき、AIには理解できない

リンクのトラバーサル制御を考えたとき、本質的な問いが生まれる。「このリンクは辿るべきか、辿らなくてよいか」をどう判断するか、だ。

人間はノートを読みながら、リンクの意味を文脈から推測できる。「このリンクは根拠として貼ったもの」「このリンクは反論の候補として貼ったもの」「このリンクは前提知識として必要なもの」といった区別を、リンクを貼った瞬間に理解している。

しかし、AIにはそれが分からない。リンクはただの接続であり、その接続が「支持」なのか「反論」なのか「依存」なのかを、ただのリンクから読み解くことはできないのである。

[人間の場合]
ノートA ──リンク──> ノートB
          ↑
  「これは根拠ノートだ」と文脈から判断できる

[AIの場合]
ノートA ──リンク──> ノートB
          ↑
  意味が分からない。全部辿るしかない。

これは「人間にとってわかりやすいリンクはAIにとって分からない」という構造的な非対称性だ。この非対称性を放置したまま「ZettelkastenをRAGに使う」という設計は、機能しない。本質的には『「顧客はわかっていない」を構造的に再解釈する』で議論した内容と同じである。

データの意味付けを後回しにしてきた歴史

この問題は、実は繰り返されてきた「うまくいかない」パターンと同じ構造を持っている。

(1) セマンティックウェブ

Web 2.0の台頭で、膨大な個人メディアがウェブに溢れたとき、ティム・バーナーズ・リーは、RDFやOWLといったメタデータ技術によって情報に意味を付与する「セマンティックウェブ」を提唱した。機械が情報の意味を解釈し、より賢い検索・統合ができるようにするというビジョンだった。

しかし、広くは普及しなかった。既存の膨大なデータにメタデータを付与するコストが、得られるメリットに見合わなかったからだ。現在はベクトル検索との共存という形で、その理念が部分的に受け継がれている。

(2) ビッグデータ

Hadoopなどのデータ分析基盤が「大量のデータに価値がある」という前提で作られた時代、データの意味付けはないがしろにされた。データが何を意味しているのかが分からない状態で分析を行い、期待通りの洞察は得られなかった。

(3) 企業におけるRAG活用

現在も同じパターンが繰り返されている。企業内に存在するExcelやPowerPointといった非定型データをRAGに登録しても、望む回答精度が得られないという課題がある。原因は単純で、ドキュメント内の要素がどのような文脈でどのような意味を持つのかを、AIが理解できないからだ。意味付けのない情報をいくら積み上げても、AIはそれを有効に活用できない。

情報の蓄積に価値があるという幻想と、意味付けのコストを軽視してきた結果が、この繰り返しである と私は考えている。この課題を解決しようとしている企業が多く存在していることからも、今回は同じ繰り返しをしないようにしていると考えられる。

修飾子付きリンクの提案

この構造的な非対称性を解消するために、リンクに「修飾子（意味ラベル）」を付ける設計を考えた。リンクの種類を以下の4つに分類し、リンクを貼る際に明示的に意味付けを行う。

実際の記述例はこうなる。

## 主張

ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクは修飾子付きで設計する必要がある。

- supports → [[人間にとってわかりやすいリンクは、AIにとっては分からない]]
  - context: 人間はリンクの意味を文脈から推測できるが、AIはできない。

- depends_on → [[Zettelkastenのノート間のリンクは修飾子によって意味づけしておくことが重要]]
  - context: 修飾子がなければ、AIはグラフを無限にトラバースしてしまう。

この設計をすることで、RAGのトラバーサル制御が可能になる。たとえば「supportsリンクだけを辿る」「depends_onは1ホップまで」といったルールをクエリ時に適用できるようになる。

なお、contradictsリンクが多いノートは、未解決の領域あるいは思考の臨界点を示していることになる。これはAIへの指示の文脈だけでなく、ノートを管理する人間にとっても有用な情報になる。

トラバーサル制御の効果を計測する

提案している設計の効果を確認するために、実際にトークン使用量を計測した。170ノート・41,370文字・207リンクで構成されたZettelkastenを対象に、「生成AIにおけるRAGの現状と課題」を調査するタスクをClaude Codeに依頼し、修飾子によるトラバーサル制御の有無でどれほど差が出るかを比較した。

制御なしの場合、AIはすべてのリンクを辿るために12のサブエージェントを起動し、55万トークン超を消費した。制御ありの場合は、修飾子をもとに必要なノードに絞り込み、4エージェント・16万トークン強で完了した。

回答品質についても比較した。

制御ありで「ベクトル検索とメタデータの共存」「歴史的失敗の反復リスク」の2項目が未回答となったが、これは修飾子によって選ばれたノード群が中心的な問いに絞り込まれた結果であり、カバレッジの欠落ではなく焦点化の結果と解釈している。

トークン使用量を約70%削減しながら回答品質をほぼ維持できたことは、修飾子によるトラバーサル制御の有効性を裏付けている。また、データを絞ることでAIが中心的な問いにフォーカスするという副作用も確認できた。コンテキストの膨張は「情報量が多ければ回答の質が上がる」という直感に反し、むしろ回答品質を下げる可能性があることを示唆している。

コンテキスト膨張は実害を生む

これは概念的な話ではなく、『ローカルLLMでSpec Driven Developmentは、まだ難しかった』で身をもって経験した実害でもある。コンテキストが膨張すると、推論エンジンはOOM（Out of Memory）に陥る。その挙動はエンジンによって異なる。

• MLX（mlx_lm）: OOMが発生した時点でクラッシュする。これ以降の推論崩壊を防ぐための設計だが、処理が中断される。
• llama.cpp: OOM後も ctx_pos / n_past が進み続け、初期化が保証されていないKV Cacheを参照しながら推論を続けてしまう。結果として推論崩壊が起きる。

どちらが良い悪いではなく、設計思想のトレードオフだ。しかし、いずれにしてもコンテキストを膨張させないことが根本的な解決策であり、修飾子付きリンクによるトラバーサル制御はその手段の一つになる。

課題

修飾子付きリンクは一つの解だが、リンクだけを意味付けすれば十分というわけではない。ノート内のどの部分がAIにとって「文脈」として有効なのか、何をZettelkastenにおけるメタデータに含めるべきか、ノート自体にどのようなメタデータを持たせるかといった設計の問いは、リンクの修飾子を整備した後にも残る。意味付けは「設計行為」であり、どこを意味付けし、どこをしないかという全体像を先に決めなければ、部分最適に終わる という考えである。

また、既存の大量のノートに修飾子を後から付与するコストも現実的な障壁だ。セマンティックウェブが普及しなかった理由の一つが「既存データへのメタデータ付与コスト」だったことを考えると、新規ノートから修飾子を付け始めて様子を見るスモールスタートが現実的だろうと考えている。

まとめ

• ZettelkastenをRAGの情報源として接続するには、ノート間のリンクに意味ラベル（修飾子）が必要である。修飾子がなければ、AIがグラフを無限にトラバースしてコンテキストが膨張する。実際の計測では、トラバーサル制御なしで556,006トークン・12エージェントだったのに対し、制御ありでは163,782トークン・4エージェントに抑制できた（それぞれ約70%・約67%の削減）。
• これはデータの意味付けを軽視してきた歴史（セマンティックウェブ、ビッグデータ、企業RAG）と同じ構造である。情報の蓄積には価値があるが、意味付けなき蓄積は、AIがそれを有効活用できないという点で、「何を蓄積するか」以上に重要な論点になる。
• Zettelkastenのノート間のリンクに意味付けを行うという点においては、supports → / contradicts → / refines → / depends_on → の4種の修飾子を提案する。これによりトラバーサル制御が可能になると考えている。
• コンテキスト膨張はOOMクラッシュや推論崩壊という実害を生む。これはパラメータ調整ではなく、設計で解決すべき問題である。
• リンクの修飾子は解決策の一部であり、全体の意味付け設計と合わせて考える必要がある。
  • リンクの修飾子は、双方向リンクに対しては爆発的にコストが大きくなる。片方向の意味付けで十分かどうかも含めて検討する必要がある。