Claude CodeとRAGの7つのレベル

하이라이트

• チャットセッションをクリアせずに使い続けると、コンテキストウィンドウの4分の1（25万トークン）を占有した時点でAIの回答精度は92%から78%まで低下する。

• 2025年のデータによれば、テキストベースのRAGは純粋なLLMへの全データ注入と比較して、回答生成のコストを1200倍削減し、処理速度を1200倍向上させる。

• Obsidianを活用した「疑似RAG」構造は、個人開発者のユースケースにおける約99%のメモリ問題を無料で解決する実用的な到達点となる。

• Naive RAG（素朴なRAG）の回答精度は25%程度に留まることがあり、これは実質的に「質の低い検索機能」と大差ない性能である。

• GraphRAG（LightRAG）は、単純なベクトル検索と比較して、エンティティ間の関係性を抽出することで精度を100%以上向上させる。

타임라인

1. 00:00 - 09:00

   コンテキスト腐敗とメモリの限界

   AIが過去の会話を忘れることへの恐怖から、ユーザーはセッションをリセットせずに使い続ける傾向がある。しかし、コンテキストが肥大化するとモデルの有効性は著しく低下し、コストも跳ね上がる。この段階ではユーザーがメモリ管理に対して受動的であり、精度のコントロールを失っている状態にある。

   • 100万トークンのウィンドウを埋めるほどAIの精度が悪化する「コンテキスト腐敗」が発生する。
   • 情報の詰め込みすぎは精度を78%まで下げると同時に、トークン消費量を劇的に増大させる。
   • レベル1の自動メモリ機能は、Claude Codeが独自の判断で作成する断片的な付箋程度の役割しか果たさない。
2. 09:01 - 12:13

   CLAUDE.mdによる明示的な規約管理

   レベル2では、CLAUDE.mdを編集することでプロジェクト固有の規約やスタイルをAIに強制する。研究によれば、こうしたシステム指示ファイルが大きすぎるとノイズとなり、本来のタスク遂行能力を妨げる。そのため、最小限でシグナルの高い情報のみを記述する「Less is More」の原則が推奨される。

   • CLAUDE.mdはClaude Codeがタスク実行前に必ず参照する「至高の指示書」として機能する。
   • このファイルに全てのルールを詰め込みすぎると、逆にLLM全体の有効性を低下させるリスクがある。
   • プロジェクトに関わる全てのプロンプトに関連しない情報は、CLAUDE.mdから除外すべきである。
3. 12:14 - 15:45

   複数Markdownファイルによる分散管理

   レベル3は、コードベース内に「project.md」や「requirements.md」といった複数のメタデータファイルを配置するアーキテクチャである。情報をチャンク化し、AIに明確な探索経路を示すことで、コンテキストウィンドウの汚染を防ぐ。これは、小規模なプロジェクトにおいては最も効率的なメモリ管理手法となる。

   • 要件、ロードマップ、状態などを個別のMarkdownファイルに分散させることで、情報のノイズを減らす。
   • CLAUDE.mdを「インデックスファイル」として使い、必要に応じて他のファイルへAIを誘導する。
   • この構造化により、本格的なRAGを構築せずとも情報の鮮度と精度を維持できる。
4. 15:46 - 25:53

   ObsidianによるLLMナレッジベースの構築

   レベル4では外部ツールのObsidianを導入し、Vault（保管庫）内にインデックス、wiki、生データの階層を作る。Andre Karpathyが提唱したこの手法は、ブラケットリンクによる接続性を活用し、AIがgrep等で情報を特定しやすくする。特定の閾値を超えるまでは、高価なRAGシステムよりもこの構造の方が人間にとっての見通しが良い。

   • Obsidianは、人間による視覚的な確認とAIによる情報検索を両立させる「8割の解決策」である。
   • 生データを処理して構造化された「wiki」フォルダに格納する階層構造が、数千のドキュメント管理を可能にする。
   • RAGへの移行を検討する前に、無料かつ低コストなObsidianでどこまでスケールできるか実験すべきである。
5. 25:54 - 34:37

   RAGの基礎とNaive RAGの限界

   レベル5では、テキストをベクトル（数値の列）に変換し、多次元空間での距離に基づいて情報を抽出する仕組みを解説する。しかし、この基本方式ではチャンク間の相互参照や複雑な関係性のクエリに対応できない。このレベルを理解することは、自作のシステムが単なる「質の低い検索エンジン」になっていないかを判断するために重要である。

   • RAGは埋め込み、ベクトルデータベース、検索・抽出の3段階で構成される。
   • Naive RAGはドキュメントを単純にチャンク分割するため、文脈の断絶や情報の孤立が発生しやすい。
   • 意味的な類似性のみに頼る検索は、単なる「高度なCtrl+F」に留まり、情報の関係性を把握できない。
6. 34:38 - 39:23

   GraphRAGとLightRAGによる関係性抽出

   レベル6は、ベクトル検索とグラフ構造を組み合わせたハイブリッド・クエリ・システムである。これにより、直接的な言及がないドキュメント同士の相互作用をAIが理解できるようになる。大量のドキュメントを扱い、かつ項目間の複雑な関係性を問う必要がある場合には、このレベルのインフラが最低限必要となる。

   • GraphRAGは独立したベクトルの集まりではなく、エンティティ同士が繋がったナレッジグラフを構築する。
   • LightRAGは、Naive RAGと比較して複数の評価指標で100%以上の精度向上を達成している。
   • Obsidianの手動リンクとは異なり、GraphRAGはAIが自動的にデータ間の深い関係性を定義する。
7. 39:24 - 46:00

   エージェント型RAGとマルチモーダル統合

   最終レベルでは、あらゆる形式のデータを統合するマルチモーダルなアーキテクチャを目指す。単なる検索システムではなく、データの鮮度を保つための自動化されたインジェスチョン・パイプライン（n8n等の活用）が含まれる。ただし、この高度なシステムが必要なケースは稀であり、まずは低いレベルから実験し、必要に応じてスケールアップすることが推奨される。

   • レベル7では画像、スキャンされたPDF、動画（Gemini Embedding 2等）をベクトル化して取り込む。
   • エージェントは、GraphRAGやPostgreSQL、Web検索など、どの経路で回答を得るかを自律的に判断する。
   • 本番運用では、データのクレンジング、バージョン管理、同期といったパイプラインの構築が成否を分ける。