00:00:00Claude Codeとメモリの問題を解決しましょう。AIシステムに信頼性と正確性を持って
00:00:06過去の会話や膨大なドキュメントに関する質問に答えさせることは、私たちが長年
00:00:13解決しようとしてきた課題です。典型的な解決策はRAG（検索拡張生成）でしたが、
00:00:20この動画のタイトルは「Claude CodeとRAGの7つのレベル」ですが、その本質は
00:00:26Claude Code、そしてAIシステム全般におけるメモリの問題を解体することにあります。
00:00:33さらに重要なのは、AIとメモリの戦いにおいて、あなたが今どの段階にいて、
00:00:37次のレベルへ進むために何をすべきかを示すロードマップを提示することです。
00:00:43Claude CodeとRAGの7つのレベルを辿る中で、多くのトピックに触れますが、
00:00:48GraphRAGのような複雑なものから始めるわけではありません。まずは基本から始めます。
00:00:53それはClaude Codeに標準搭載されている基本的なメモリシステムです。悲しいことに、
00:00:59ほとんどの人がそこで立ち止まってしまっています。自動メモリや
00:01:04CLAUDE.mdから、Obsidianのような外部ツールへと進み、最終的には
00:01:10真のRAGシステムという「大物」に到達します。そのレベルでは、RAGとは何か、
00:01:16どう機能するのか、素朴なRAG、GraphRAG、エージェント型RAGなどの違い、
00:01:21リランカーなどについても話します。各レベルにおいて、同じ形式で解説していきます。
00:01:25そのレベルで期待できること、マスターすべきスキル、回避すべき罠、
00:01:29そして次のレベルへ進むために必要なことです。この動画では、
00:01:34特定のシステムを構築するための非常に詳細な技術解説は行いません。
00:01:40なぜなら、GraphRAGやLightRAG、あるいはさらに高度なトピックや
00:01:45様々な埋め込みシステムについては、すでに多くの動画を公開しているからです。
00:01:50ゼロから構築する方法を解説した動画がありますので、
00:01:55該当するセクションでそれらの動画をリンクします。これは、
00:02:00動画が5時間にも及ばないようにするためです。それでも各レベルにおいて、
00:02:04そのシステムが何をもたらし、いつ使うべきかについては解説します。
00:02:09レベル1を始める前に、今日のスポンサー、つまり私から一言。先月、
00:02:15「Claude Codeマスタークラス」をリリースしました。非技術職の方でも、
00:02:21AI開発者へと成長できる最短ルートです。このクラスが少し違うのは、
00:02:25Claude Codeを学ぶために多くのユースケースに焦点を当てている点です。例えば、
00:02:31プロダクションレベルのRAG。この動画で紹介するRAGシステムを現実のシナリオで構築し、
00:02:37チームメンバーとして活用したり、クライアントに提供したりする方法に焦点を当てています。
00:02:42興味があれば、Chase AI Plus内のリンクからアクセスしてください。お待ちしています。
00:02:47ではレベル1、「自動メモリ（Auto Memory）」から始めましょう。
00:02:51これはClaude Codeが過去の会話を記憶するために自動的に使用する、
00:02:58いわば「記憶装置」のような仕組みです。もしあなたがこれまで、
00:03:02過去の文脈やコードベースの状況をClaude Codeに覚えさせる設定を
00:03:09意図的にしたことがなければ、今のあなたはここにいます。
00:03:13自動メモリとはその名の通り、Claude Codeの使用時に自動的に有効になるシステムで、
00:03:18Claude Codeが自らMarkdownファイルを作成し、
00:03:26そのプロジェクトにおけるユーザーの重要な情報をリスト化する機能です。
00:03:32これは会話から得られた独自の直感に基づいています。作成されたメモリファイルは、
00:03:37「.claude」フォルダ内の「projects」フォルダにある「memory」という
00:03:42フォルダの中に、いくつかのMarkdownファイルとして確認できます。
00:03:47ここには4つあります。これらはClaude Codeによる「付箋」のようなもので、
00:03:51「YouTubeプロジェクトの目標について言及があった」とメモされています。
00:03:59メモリフォルダ内には「memory.md」があり、そこには
00:04:04私のスキルに関するメモや、他のメモリファイルへのインデックスが含まれています。
00:04:09YouTubeの成長、収益、リファレンスなどの項目があり、その中身も記載されています。
00:04:13もし私がClaude Codeとの会話でYouTubeの目標について触れれば、
00:04:19これを参照して「Chaseは2026年末までに登録者数X人を目指している」と思い出すのです。
00:04:23面白い機能ですが、正直あまり役に立ちません。
00:04:30ChatGPTが過去の会話からランダムな情報を持ち出して、
00:04:35無理やり話にねじ込んでくるような感覚に近いものです。
00:04:40「覚えているのは分かったけれど、今はどうでもいいし、少し不気味だ」と感じるでしょう。
00:04:44残念ながら、多くの人がこの段階でメモリの探求を止めてしまいます。これは、
00:04:49チャットボットとの付き合いにおける一種の「トラウマ」が原因かもしれません。
00:04:54本来、チャットボットは会話をまたいで記憶を保持することができないため、
00:05:00チャットウィンドウを閉じたり、ターミナルセッションを終了したりすることに、
00:05:06私たちは恐怖を感じます。「会話が忘れられてしまう！」と。
00:05:10これは切実な問題です。記憶できないチャットウィンドウに対する
00:05:17皆さんの回答は何でしょうか？ それは「会話を永遠に続けること」です。
00:05:22終了して全てを忘れられるのが怖いからです。この恐怖はChatGPTや、
00:05:26Claudeのウェブアプリから始まりました。昔のClaudeはさらに深刻でした。
00:05:31100万トークンのコンテキストウィンドウが登場する前、Claudeと
00:05:3530分話すと「また4時間後に」と言われていた時代を覚えているでしょう。
00:05:39問題は、人々がその強迫観念をターミナルにまで持ち込んでしまったことです。
00:05:45100万トークンが使えるようになったことで、人々は履歴をクリアせず、
00:05:50Claude Codeと延々と話し続けます。記憶を失わせたくないからです。
00:05:55しかし、メモリの問題を恐れて同じセッションで話し続けると、
00:06:00時間の経過とともに効率が大幅に低下します。これが「コンテキスト腐敗」の基本概念です。
00:06:05コンテキスト腐敗（Context Rot）とは、同じチャットセッションを使い続け、
00:06:10コンテキストウィンドウを埋めるほど、AIの精度が悪化する現象です。
00:06:16ここに例があります。Claude Codeの100万トークンのうち、25万トークン、
00:06:23つまり4分の1を埋めた時点での精度は92%ですが、
00:06:30最後の方には78%まで落ちます。使えば使うほど悪くなる、これがメモリの主要な課題です。
00:06:36100万トークンの窓があっても、会話を忘れられたくないために、
00:06:42ウィンドウを閉じずに詰め込み続けます。すると2つのことが起こります。1つは、
00:06:47先ほど見たように有効性が下がること。もう1つは、
00:06:51使用量が膨大になることです。コンテキストが80万の時と8万の時では、
00:06:59消費されるトークン量は桁違いです。これが唯一の問題ではありませんが、
00:07:08今、多くの人が「Claude Codeが弱体化した」「使用量が勝手に増える」と不満を言っています。
00:07:12理由はいくつかありますが、その一つは間違いなく、100万トークンが導入されて以来、
00:07:18人々がコンテキストウィンドウの管理方法を知らず、
00:07:24会話のクリアやリセットを積極的に行っていないことにあります。
00:07:29少し話が逸れましたが、
00:07:34RAGとClaude Codeにおけるメモリの議論で重要なのは、
00:07:39常にコンテキスト腐敗を念頭に置く必要があるということです。
00:07:44多くの文脈を読み込ませてClaude Codeに答えさせたいという欲求と、
00:07:50文脈が大きくなりすぎて精度が下がるのを避けたいという葛藤に対処しなければなりません。
00:07:55メモリの話をする際、これは常に意識すべきポイントです。
00:08:02レベル1に戻りましょう。レベル1で人々は何をしているのか？
00:08:06答えは「実質的に何もしていない」です。何もしないため、
00:08:10肥大化したコンテキストウィンドウに記憶を頼っています。もしあなたが
00:08:15CLAUDE.mdファイルを編集したことがなく、Claude Codeが過去に何をし、
00:08:23将来何をすべきかを把握するためのアーティファクトも作成したことがなければ、ここにいます。
00:08:27このレベルでマスターすべきことは、自動メモリだけでは不十分であり、
00:08:31メモリ管理において能動的な役割を果たす必要があると理解することです。
00:08:35このレベルの罠は、能動的にならないことでコントロールを失うことです。
00:08:40Claude Codeが回答の際に何を考慮するかを、私たちが制御する必要があります。
00:08:44レベル1を脱してレベル2へ進むには、メモリを「明示的」にする必要があります。
00:08:50能動的な役割を担うために、どのファイルを理解し、
00:08:57編集すべきかを知る必要があるのです。
00:09:01レベル2はある特定のファイル、つまり「CLAUDE.md」が中心となります。
00:09:06このファイルの存在を知ると、まるで救世主のように感じます。ついに、
00:09:12Claude Codeに従わせたいルールや規約を書き込める場所が見つかったからです。
00:09:16覚えておいてほしいことを書き込めば、常にそれを守ってくれます。最初は大きな進歩に感じます。
00:09:20これはパーソナルアシスタント・プロジェクト用の標準的なCLAUDE.mdのテンプレートです。
00:09:29Claude CodeはCLAUDE.mdを自動生成しますが、
00:09:33「/init」コマンドなどを使って、これを自由に編集・更新することができます。
00:09:38そのプロジェクトにおけるClaude Codeへの「至高の指示書」と言えるでしょう。
00:09:43Claude Codeはタスクを実行する前に、必ずこのファイルを確認します。
00:09:50ですので、特定のことを記憶させたいなら、ここに書き込みます。
00:09:54論理的には、RAGよりも小規模なものと言えます。膨大なドキュメントを
00:10:00入れるわけではありませんが、常に覚えておいてほしいことや、
00:10:05従うべき規約を記述します。例えば「私について」のセクションや、
00:10:09ファイルシステムの構造、コマンドに対する動作の定義などです。
00:10:14ほぼ全てのプロンプトで参照されるため、Claude Codeはこれに従うのが得意です。
00:10:18記憶させたい情報を置く場所として最適に見えますが、注意が必要です。
00:10:22やりすぎてしまう可能性があるからです。たとえば、
00:10:28「agents.md」を評価した研究（CLAUDE.mdと同等のものと考えてください）によれば、
00:10:33こうしたファイルが大規模言語モデル全体の有効性を
00:10:40低下させる可能性があることが分かりました。なぜでしょうか？
00:10:45「全てのプロンプトに挿入される」という最大の長所が、短所にもなり得るからです。
00:10:51私たちは本当に正しい文脈を注入しているでしょうか？ ノイズを排除し、
00:10:57適切なシグナルを与えているでしょうか？ それとも、ただ良さそうなものを詰め込んでいるだけでしょうか？
00:11:02プロジェクト内のほぼ全てのプロンプトに関連しないのであれば、
00:11:08それをCLAUDE.mdに入れるべきでしょうか？ 私はそうは思いません。
00:11:15CLAUDE.mdの構造について世間で言われていることとは逆かもしれませんが、
00:11:20研究や実体験に基づけば、「Less is More（少ないほど良い）」です。
00:11:26コンテキスト汚染や腐敗は実在します。CLAUDE.mdの内容が、
00:11:32ほぼ全てのプロンプトにそぐわないのであれば、入れるべきではありません。
00:11:37しかし多くの人がその罠にハマり、肥大化したルールブックを作ってしまいます。
00:11:42私たちがマスターすべきスキルは、高いシグナルを持つプロジェクトコンテキストの作成です。
00:11:48中身が論理的であることを確認し、コンテキスト腐敗への意識を持つことです。
00:11:53レベル2は、メモリ管理に能動的に関わっている実感を与えてくれます。
00:11:57しかし、それだけでは十分ではないことに気づくでしょう。
00:12:02レベル3へ進む際に私たちが考えるべきなのは、
00:12:08静的なルールブックではなく、進化し続ける仕組みです。
00:12:14CLAUDE.mdに全てを頼るのではなく、CLAUDE.mdを
00:12:18他のファイルへと誘導する「インデックスファイル」として使うのはどうでしょうか。
00:12:24CLAUDE.mdをインデックスとして使い、他を指し示すとはどういうことか。
00:12:30それは、たった一つのMarkdownファイルで全てのメモリ問題を解決しようとするのではなく、
00:12:37コードベース内に特定のタスクに応じた複数のファイルを置くアーキテクチャのことです。
00:12:41良い例がオーケストレーションツールの「GSD (Get Shit Done)」です。
00:12:47これは「何を作り、何が要件で、これまでに何をしたか」を一ファイルにまとめません。
00:12:53代わりに複数のファイルを作成します。左側に見えるように、
00:12:56「project.md」「requirements.md」「roadmap.md」「state.md」などがあります。
00:13:02要件（Requirements）があれば、Claude Codeは何を作るべきかを常に記憶できます。
00:13:08ロードマップ（Roadmap）は、現在だけでなく、過去と未来に何を作るのかを分解します。
00:13:12プロジェクト（Project）は、高レベルの概要や「北極星」となる目標の文脈を与えます。
00:13:16このようにメモリや文脈、規約を分散させることで、
00:13:22コンテキスト腐敗や、先ほどの研究で指摘された問題に対抗できます。
00:13:29全てのファイルを常にプロンプトに注入するのは逆効果であり、
00:13:34精度の向上には繋がりません。
00:13:39情報をチャンク化し、Claude Codeに明確な道筋を示すことで、
00:13:44「情報がどこにあるか知りたい。まずCLAUDE.mdを見よう」
00:13:49「CLAUDE.mdに5つの選択肢がある。よし、あのファイルを探しに行こう」という流れが生まれます。
00:13:54それはあなたにとって何を意味するでしょうか？ レベル4で話すようなシステムが必要ですか？
00:13:58真のRAGシステムにおけるチャンク化やベクトル類似性検索を
00:14:04簡易的に再構築したものと言えます。もちろん、このレベルは小規模です。
00:14:10数個のMarkdownファイルを扱っているだけで、
00:14:14何千ものドキュメントを処理できるシステムではありません。しかし、
00:14:20あなたにとってそれは何を意味するでしょうか？ レベル4から7で話すような、
00:14:26膨大な書類を扱えるシステムが本当に必要でしょうか？ 答えは「NO」かもしれません。
00:14:32RAGの旅で重要なのは、自分の現在地を知るだけでなく、どこまで行く必要があるかを知ることです。
00:14:36常にレベル7でエージェント型RAGを構築する必要があるでしょうか？
00:14:41やり方を知っておくのは良いですが、それが必要ない時を見極めるのも同じくらい大切です。
00:14:46多くの人にとって、ここで紹介したようなシステムで十分な場合もあります。
00:14:52「できること」と「すべきこと」の区別が重要なのです。
00:14:58レベル3でステート（状態）ファイルを扱っている場合、どうすればそこにいると分かりますか？
00:15:00それは、まだClaude Codeのエコシステム内に留まっており、
00:15:04外部ツールを統合していない段階です。独自の簡易的な
00:15:09メモリ・チャンク化システムとして、複数のMarkdownファイルを作成している状態です。
00:15:14しかし、ここでも重要なスキルをマスターしています。ドキュメントを構造化し、
00:15:18セッションごとに状態を更新する仕組みを構築することです。
00:15:23情報の鮮度を保つことは、本格的なRAGでも共通の課題です。
00:15:28また、この段階ではGSDのようなオーケストレーション層を
00:15:33活用し始めているかもしれません。これらは自動でマルチMarkdown構成を作ってくれます。
00:15:40ただし、罠もあります。ここで作成したものは、そのプロジェクト専用になりがちです。
00:15:46Markdownファイルを別のプロジェクトへ移行するのは少し面倒です。そこで、
00:15:51レベル4では「Obsidian」を導入します。これは現在、非常に注目されているツールです。
00:15:56アンドレイ・カルパシーのような人物が、Obsidianを基盤とした
00:16:00LLMナレッジベースについて語っており、
00:16:06その動画は2000万回近く再生されています。私たちはその仕組みを注視すべきです。
00:16:11私はすでに、カルパシー氏のLLMナレッジベースに関する詳細な解説動画を出しています。
00:16:18構築方法を知りたい方は、上にリンクを貼っておくのでチェックしてください。
00:16:22そして皆さんに伝えたいのは、このレベル4のObsidianこそが、
00:16:27ほとんどの人が目指すべき到達点だということです。
00:16:32なぜなら、多くのユースケースにおいてこれで十分だからです。レベル5、6、7で話す
00:16:37真のRAG構造は、正直、大半の人にはオーバースペックです。
00:16:43RAGについて語るのは楽しいですが、現実的にはやりすぎなことが多いのです。
00:16:50Obsidianは「8割の解決策」と言われますが、個人開発者にとっては99%の解決策になり得ます。
00:16:56無料ですし、オーバーヘッドもほとんどなく、十分に役割を果たしてくれます。
00:17:02「役割を果たす」とは、Claude Codeを多くの異なるドキュメントや
00:17:07Markdownファイルに接続し、正確でタイムリーな情報を引き出し、
00:17:13人間がその内容を把握できる状態にすることです。ファイルをクリックすれば、
00:17:19中身や関連ドキュメントが一目で分かります。
00:17:24リンクを辿れば次々と情報にアクセスできます。
00:17:30人間にとって、この「見通しの良さ」は非常に重要です。
00:17:36Obsidianによるドキュメントの把握のしやすさは、
00:17:42高度なRAGシステムから得られる洞察よりも勝っている場合があると私は考えます。
00:17:47何千ものドキュメントが GraphRAG システムに組み込まれている様子は
00:17:52視覚的には非常に素晴らしく、圧倒されるかもしれません。しかし、中身を本当に把握していますか？
00:17:58実際には提示された回答やリンクを信頼しているだけで、埋め込みの中身を詳しく調べるのは難しいものです。
00:18:03だからこそ Obsidian と Claude Code に注目すべきです。RAG への移行を検討する際、
00:18:08私はクライアントを含め全員に、まずは Obsidian から始めて、どこまでスケールできるか試すよう勧めています。
00:18:13そして最終的に限界に達したなら、より堅牢な RAG システムへいつでも移行できます。
00:18:20シンプルな方法で済むなら、それでいいではありませんか？ 無料ですし、コストもかかりません。
00:18:26一方、RAG システムの構築は内容によっては非常に困難な場合もあります。
00:18:31常にシンプルなものから始めてください。より複雑なものへの移行は、決して難しくありません。
00:18:35では、レベル4で具体的に何を話しているかというと、
00:18:40レベル3で構築し始めた構造、つまりインデックスファイルが
00:18:45複数のマークダウンファイルを指し示す構造をスケールアップさせ、
00:18:50Obsidian という外部ツールを導入して、人間が接続性を視覚化しやすくすることです。
00:18:56このバージョンの理想形は、Andre Karpathy が提示した
00:19:00Obsidian 上に構築され Claude Code で動く LLM ナレッジベースの構造です。
00:19:05具体的にはこのような構造になります。Obsidian をダウンロードしたら（これも無料です）
00:19:11特定のファイルを「Vault（保管庫）」として設定します。Vault を一種の RAG システム、
00:19:16疑似的な RAG システムと考えてください。そして Vault の内部を
00:19:23ファイルで構造化していきます。まず Vault という最上位のフォルダがあり、
00:19:30その中に複数のサブフォルダを作成します。Andre Karpathy の例では3つのフォルダについて話していますが、
00:19:36実際にはテーマに合っていればどんなフォルダでも構いません。
00:19:411つのフォルダには「生データ」を入れます。これは取り込んだ後、
00:19:47後で Claude Code が参照できるように構造化したいすべての情報です。
00:19:52例えば、Claude Code に50社の競合分析をさせ、各社50サイトずつ情報を集めたとします。
00:19:58これは膨大な情報量になります。約2500もの項目が「raw（生）」フォルダに
00:20:03放り込まれることになります。ここがデータのステージングエリアです。
00:20:08次に「wiki」フォルダがあります。ここには構造化されたデータが入ります。
00:20:14Claude Code に生データを処理させ、wiki フォルダ内に
00:20:20Wikipedia のような記事として構造化させます。各記事には専用のフォルダが割り当てられます。
00:20:28これにより、例えば「AI エージェント」に関する情報を Claude Code に尋ねたとき、
00:20:33「AI エージェントについて教えて」と言えば、RAG システムをクエリするのと同じように、
00:20:38Claude Code は Vault にアクセスし、そこから wiki フォルダへ向かいます。
00:20:45wiki にはマスターインデックスのマークダウンファイルがあります。
00:20:50以前話した「claud.md」で行っていたことと同じテーマが、各レベルで引き継がれているのが分かりますね。
00:20:56マスターインデックスを確認することで、Obsidian RAG システム内に何が存在するかを把握します。
00:21:00「AI エージェントがあるな」と判断し、さらにその下層にある
00:21:08個別の記事に関するインデックスファイルも確認します。
00:21:14つまり、Claude Code が情報を探す際に参照すべき明確な階層構造があるということです。
00:21:21Vault、wiki、インデックス、記事といった具合です。情報の探し方や
00:21:31wiki への変換方法が明確なため、RAG を使わなくても
00:21:37適切に運用すれば、何百、何千ものドキュメントを扱うシステムを構築できます。
00:21:44Vault とインデックスを確認し、どこに何があるか明確に区分されていれば、
00:21:50Claude Code にとって、探し場所を特定するのはそれほど難しくありません。
00:21:54そのため、数千のドキュメントがあっても RAG なしの構造で運用できるのです。これは以前は困難でした。
00:21:58なぜなら、多くの人は何の構造も持たず、膨大なドキュメントを1つのフォルダに放り込んでいたからです。
00:22:02それは工場の床に1000万個のファイルをぶちまけているようなものです。
00:22:08それでは Claude Code も見つけられません。必要なのは「書類棚」です。
00:22:13Claude Code は実はかなり賢く、その設計が機能しているのをここで確認できます。
00:22:17今見ているのは Obsidian Vault 内にある claud.md ファイルです。何と書いてあるでしょうか？
00:22:24Vault の構造や wiki システム、サブフォルダ全体の構成、
00:22:30そして基本的な操作方法が説明されています。ここでも claud.md を規約ファイルとして使っています。
00:22:36左側には wiki フォルダがあり、その中のマスターインデックスには内容がリストアップされています。
00:22:43この例では「Claude Managed Agents」という記事が1つだけあります。
00:22:49そのフォルダ内にも wiki フォルダがあり、実際の記事にたどり着くまで詳細に分類されています。
00:22:55踏むべきステップが非常に明確です。ですから「マネージドエージェントについて話して」と言えば、
00:23:01wiki があるので、内蔵の grep ツールを使って非常に簡単に検索できます。
00:23:06実際のマークダウンファイルにリンクし、その内容を詳しく説明してくれます。
00:23:12レベル4での真の課題は「スケール」の問題です。このシステムが
00:23:16機能し続けられるドキュメントの数はどれくらいでしょうか？
00:23:22Andre Karpathy のシステムが崩壊し始める地点はあるのでしょうか？
00:23:26インデックスを辿る明確なパスがあるとはいえ、それが
00:23:312000、2500、3000ドキュメントとなっても維持できるのか。明確な答えはまだ分かりません。
00:23:37ドキュメントの内容も千差万別ですし、限界というのは
00:23:43単に Claude Code が誤回答を出すとか、ファイルが多すぎるといった単純な話ではありません。
00:23:47ファイルが増えたことでトークン費用がどれくらいかかっているか、
00:23:52そして処理速度はどうかも重要です。RAG は特定の状況で、圧倒的に速く安くなる可能性があるからです。
00:23:59ここに見えるのは、巨大な棒グラフで示された「テキストベースの LLM」と
00:24:06「テキストベースの RAG」の比較です。正解を得るまでにかかったトークン量と、
00:24:11それにかかった時間を比較しています。何が見て取れるでしょうか？
00:24:18テキスト RAG とテキスト LLM の間には劇的な差があります。約1200倍の差です。
00:24:25これらの研究では、RAG の方が1200倍安く、1200倍速いとされています。
00:24:33ただし、これは2025年のデータであり、Claude Code で行われたものではありません。
00:24:37モデルは当時から大きく進化しています。しかし、それでも 1200倍の差があったのです。
00:24:48ですから「Obsidian にすべきか RAG にすべきか」を判断する際、
00:24:54単に正解が出るかどうかだけを考えればいいわけではありません。
00:24:59Obsidian で正解が得られたとしても、RAG ならば1000倍安く、
00:25:04かつ速く済むというシナリオもあり得るのです。Obsidian や
00:25:10マークダウンによる構築で十分なラインと、RAG が必要なラインの境界は非常に曖昧です。
00:25:15明確な正解はありません。自分で両方を試して実験してみるしかありません。
00:25:182025年のデータは古く、現在のモデルでは
00:25:25RAG と LLM の差は1200倍ほどではないでしょうが、その差はどれくらい縮まったのでしょうか？
00:25:3210倍ではなく 1200倍という差はあまりに巨大です。知っておくべきことは多くありますが、
00:25:39あらかじめ答えを知ることは不可能です。どんな動画を見ても、
00:25:45誰もその明確な線引きを教えてはくれません。Claude Code に処理させる
00:25:49ドキュメントの数を増やしながら、自分に最適な方法を実験して見極める必要があります。
00:25:54それを踏まえて、レベル5に進みましょう。ここではついに
00:25:59本格的な RAG システムについて、そして埋め込みや
00:26:04ベクトルデータベース、データがナレッジベースの一部となるまでの流れといった基礎を解説します。
00:26:10まずは「Naive RAG（素朴な RAG）」から始めましょう。最も基本的な形式ですが、
00:26:16あらゆる高度な手法の土台となります。RAG システムは3つの部分に分かれていると考えてください。
00:26:21左側に「埋め込み（Embedding）」ステージがあり、次に
00:26:27「ベクトルデータベース」、そして LLM による実際の「検索・抽出（Retrieval）」です。
00:26:331、2、3のステップです。このモデルを説明するために、
00:26:40ナレッジベースの一部となるドキュメントが辿る旅を見ていきましょう。
00:26:45大規模な RAG システムでは数千のドキュメント、それぞれが数千ページということもありますが、
00:26:50この例では1ページのドキュメントで説明します。
00:26:56このドキュメントをデータベースに追加する場合、そのまま取り込まれるわけではありません。
00:27:03まずドキュメントを「チャンク」と呼ばれる小さな断片に分割します。
00:27:08この1ページが、例えば3つのチャンクになります。これらが「埋め込みモデル」に送られ、
00:27:15モデルは各チャンクをベクトルデータベース内の「ベクトル」に変換します。
00:27:21ベクトルデータベースは、標準的なデータベースのバリエーションです。
00:27:27標準的なデータベースといえば、Excel のような行と列で構成されるものを想像しますよね。
00:27:32しかし、ベクトルデータベースは2次元ではなく、実際には
00:27:37数百、数千もの次元を持っています。ただ、今日は分かりやすくするために、
00:27:43図のような3次元グラフを思い浮かべてください。ベクトルはその中の「点」であり、
00:27:50各点は一連の数値で表されます。例えば「バナナ」という項目が
00:27:570.52、5.12、9.31 という数値で表され、それがさらに何百個も続くと考えてください。
00:28:06各ベクトルがこの巨大な多次元グラフのどこに配置されるかは、その「意味（セマンティック）」によります。
00:28:13その言葉が実際に何を意味しているかです。例えばこちら側が「フルーツ」セクションで、
00:28:19バナナ、リンゴ、梨が集まっています。あちら側には船やボートが集まっています。
00:28:24では、先ほどのドキュメントが第二次世界大戦の戦艦に関するものだとしましょう。
00:28:31各チャンクは数値の列に変換され、このグラフ内の「点」として表現されます。
00:28:37どこに配置されるでしょうか？ おそらく、このあたりの領域になるはずです。
00:28:421、2、3番目のチャンクが配置されました。これがドキュメントが格納される仕組みです。分割され、
00:28:49埋め込みモデルを通って、ベクトルデータベースに挿入されます。これをすべてのドキュメントで繰り返し、
00:28:54数千回繰り返した後に出来上がるのが、私たちの「ナレッジグラフ」、
00:28:58つまりナレッジベースとなるベクトルデータベースです。
00:29:04そしてステップ3、検索（Retrieval）の部分です。
00:29:09あなたはここにどう関わるのでしょうか？ あなたを別の色、ピンクで描いてみましょう。
00:29:16これがあなたです。あなたは通常通り、Claude Code に話しかけ、
00:29:23第二次大戦の戦艦について質問します。標準的な非 RAG 環境では何が起きるでしょうか？
00:29:29LLM（例えば Opus 4.6）は自身の「学習データ」を確認し、
00:29:34その学習データに基づいて戦艦に関する回答を生成します。
00:29:39しかし、RAG システムではさらに踏み込んだことを行います。適切なベクトルを抽出し、
00:29:44それらのベクトルを使って、生成する回答を「補強（Augment）」するのです。
00:29:51これが「検索拡張生成（Retrieval Augmented Generation）」、RAG の力です。
00:29:56LLM が自身の学習データに含まれていない情報を取り込み、回答を補強することを可能にします。
00:30:02この例では戦艦の話ですが（LLM も既に知っているでしょうが）、これを
00:30:06ウェブで公開されていない企業の機密データに置き換えて、大規模に運用することを考えてみてください。
00:30:15それが RAG の売りです。今回の例で、RAG 設定の Claude Code に
00:30:21戦艦について質問したとします。するとシステムはまず、
00:30:25私たちの「質問」を、先ほどのベクトルと同じような数値の列に変換します。
00:30:32そして、質問の数値とデータベース内のベクトルの数値を照らし合わせ、
00:30:39質問のベクトルに最も近いものがどれかを探します。「意味的にどれくらい似ているか」を確認するのです。
00:30:46そして、上位いくつかのベクトル（5個、10個、あるいは20個など）を抽出します。
00:30:51抽出されたベクトルとその情報を LLM に送ります。これで LLM は、
00:30:56自身の学習データに加えて、抽出された10個分の情報を持つことになります。
00:31:02これが「検索（Retrieval）」の工程です。その追加情報を使って回答を補強・生成します。
00:31:09これが RAG、特に Naive RAG の仕組みです。ただ、この方式はいくつかの理由で効率的ではありません。
00:31:13この非常に基本的な構造は、初期の段階で壁にぶつかります。例えば、
00:31:19ドキュメントをどう分割（チャンク化）するか。ランダムか、単なるトークン数か、
00:31:25重複部分は持たせるのか。ドキュメント自体の構成が分割に適していない場合もあります。
00:31:31もし「チャンク3」が「チャンク1」の内容を参照していたらどうなるでしょう？
00:31:36検索時に適切なチャンクだけが抽出され、文脈に必要なもう一方のチャンクが漏れてしまったら、
00:31:42その内容は意味をなさなくなります。質問に答えるために
00:31:47ドキュメント全体が必要なケースは非常に多いのです。断片的な回答を繋ぎ合わせるという発想は、
00:31:53実務ではうまくいかないことが多いのですが、RAG は長い間この方式で運用されてきました。
00:31:59他にも問題があります。例えば、異なるベクトル間の「関係性」について質問したい場合です。
00:32:05現在の仕組みでは、各ベクトルは独立した「サイロ」として抽出されます。
00:32:10「ボート」と「バナナ」がどう関係しているか知りたいとしても（奇妙な例ですが）、
00:32:17標準的なベクトルデータベースの Naive RAG アプローチでは、情報を繋ぎ合わせるのが困難です。
00:32:22結局のところ、元のドキュメントが RAG に適した構造で書かれているかどうかに大きく左右されます。
00:32:31長年、これらの問題を軽減する方法が考案されてきました。例えば「リランカー」は、
00:32:36抽出された全ベクトルを LLM で再評価し、関連性の高い順に並べ替えるシステムです。
00:32:41しかし概して、この Naive RAG は時代遅れになりつつあります。それでも、
00:32:46この基礎を理解しておくことは、より堅牢な RAG 手法を採用する際の判断材料として不可欠です。
00:32:51チャンク化や埋め込みの仕組みを理解していなければ、
00:32:56ドキュメントをどう構造化すべきか判断できません。
00:33:03「GraphRAG」や、テキストだけでなく動画も取り込める Google の新しい埋め込みシステムなどを語る際、
00:33:07この土台がないと、ある「罠」に気づくことができません。
00:33:13その罠とは、単に「質の低い検索エンジン」を作ってしまっただけ、という状態です。
00:33:17断片を拾い集めるだけで、それらの関係性を理解できない Naive RAG システムは、
00:33:22過剰に複雑化した「Ctrl + F（検索機能）」と何が違うのでしょうか？ 答えは、
00:33:27大差ありません。世の中にはまだ、このような単純で古い RAG 構造が溢れています。
00:33:31「Pinecone や Supabase を使った RAG システムです」と言いつつ、
00:33:36GraphRAG や高度なリランカーについて言及がないものは、精度が非常に低いでしょう。
00:33:42正解率が25%程度ということもあり、勘で答えるのと大差ないレベルかもしれません。
00:33:48それを知らないと、使い物にならない RAG システムを掴まされたり、混乱させられたりします。
00:33:54レベル5の目的は、Naive RAG を実装することではなく、その仕組みを理解することです。
00:33:58それにより、より洗練されたものを実装する際に、何が起きているか把握できるようになります。
00:34:03「RAG が必要だ」と言う人の多くは、この5分間の説明内容すら理解していません。
00:34:07本当に必要でしょうか？ システムに対してどのような質問を投げているか自問してください。
00:34:12単に巨大なルールブックの中から特定の項目を引き出したいだけなら、
00:34:18Obsidian や Naive RAG で十分かもしれません。しかし、項目間の関係性や、
00:34:23直接の言及がない別々のドキュメント同士の相互作用を知る必要があるなら、
00:34:28さらに、それらのドキュメントが数千もあるためにコンテキストに直接入れられないなら、
00:34:34それこそが RAG、しかも基本以上の洗練された RAG が必要な場面です。
00:34:38そこで「GraphRAG」の出番となります。レベル6では GraphRAG について話します。
00:34:43私の意見では、RAG を活用するならこれが最低限必要なインフラのレベルです。
00:34:48ここでは完全オープンの「LightRAG」というツールを使います。構築方法のリンクも載せておきますが、
00:34:54GraphRAG のコンセプトは明快です。それは「すべてが繋がっている」という考え方です。
00:34:59独立したベクトルの集まりではなく、互いに関連し合ったデータの集合体なのです。
00:35:02ドキュメントをクリックすれば、その説明、名前、タイプ、ファイル、チャンク、
00:35:09そして何より「他のデータとの関係性」が表示されます。この関係性に基づいたアプローチが、
00:35:13より効果的な結果をもたらします。これは LightRAG の GitHub にあるチャートです。
00:35:19半年から8ヶ月ほど前のデータですが、LightRAG は知る限り最も軽量な GraphRAG システムです。
00:35:23Microsoft のその名もズバリ「GraphRAG」のような非常に重厚なバージョンもあります。
00:35:29Naive RAG と LightRAG を比較すると、あらゆる指標で
00:35:34100% 以上の精度向上（31.6% 対 68.4%、24% 対 76% など）が見られます。
00:35:39LightRAG 自称のデータなので、多少割り引いて見る必要はありますが、
00:35:44圧倒的な差であることは確かです。この知識グラフのシステムを見ると、
00:35:50見た目が似ているので Obsidian を連想するかもしれません。しかし、
00:35:55Obsidian で見ているものは、GraphRAG システムの内部で起きていることよりも遥かに初歩的です。
00:36:00Obsidian の繋がりはすべて手動、あるいは多少なりとも恣意的なものです。
00:36:05私たちが関連ドキュメントを設定したり、Claude Code がドキュメント生成時に
00:36:10ブラケット（[[ ]]）を追加したりしたことで繋がっているに過ぎません。
00:36:15理屈の上では、実際には無関係なドキュメント同士を繋ぐこともできてしまいます。
00:36:23Claude Code は賢いのでそんなことはしませんが、GraphRAG の自動的な関係性抽出とは
00:36:30根本的に性質が異なるのです。
00:36:35Obsidianで起きていることは、LightRAGや他のGraphRAGシステムで起きていることよりも、はるかに初歩的なのです。
00:36:4324対75など、枚挙にいとまがありません。LightRAGによれば、
00:36:49GraphRAG本家をも凌駕すると言いますが、自社データなので割り引いて考えるべきでしょう。
00:36:54このナレッジグラフ・システムを見ると、すぐにObsidianを思い浮かべるかもしれません。
00:36:58見た目は似ていますが、ObsidianのグラフはLightRAGなどの
00:37:04GraphRAGシステムが行っていることに比べれば、はるかに原始的です。
00:37:10なぜなら、ここに見える一連の接続はすべて手動で、やや恣意的なものだからです。
00:37:16関連文書を設定したり、Claude Codeが文書生成時に設定したりしたから繋がっているだけです。
00:37:22例えば、ブラケットをいくつか追加するだけで、その文書が接続されます。
00:37:27理論上は、実際には全く関係のないランダムな文書同士を繋げることも可能です。
00:37:30Claude Codeは賢いのでそんなことはしませんが、LightRAGで起きていることとは大違いです。
00:37:35LightRAGでは実際のエンベディング・システムを通し、内容を精査して、
00:37:41関係性やエンティティを定義しています。Obsidianよりもはるかに多くの処理が
00:37:46内部で行われています。では、その違いが実際に低レベルな処理において
00:37:52驚異的なパフォーマンスの差を生むのでしょうか？ 巨大なスケールなら、そうかもしれません。
00:38:02結局、そのあたりはグレーゾーンであり、規模や対象によって異なります。
00:38:07あなた自身の経験以外に答えはありませんが、この2つは別物だと理解してください。
00:38:13全く異なるシステムです。一方は非常に洗練されており、もう一方は原始的です。
00:38:20それを踏まえて、レベル6のGraphRAGをまとめましょう。
00:38:26Obsidianのようなものでは不十分で、単純なRAG（Naive RAG）も
00:38:31機能しないと判断した時に、このレベルに到達します。エンティティや関係性を抽出し、
00:38:36ベクトルとグラフのハイブリッド・クエリ・システムを最大限に活用する必要がある場合です。
00:38:43しかし、レベル6のLightRAGでさえ、重大な落とし穴や障害があります。
00:38:48これはテキスト限定の話です。スキャンされたPDFや動画、画像があったらどうしますか？
00:38:55すべてのドキュメントがGoogleドキュメントのようなテキスト形式とは限りません。
00:39:01そこで「マルチモーダル検索」が重要になります。さらに、
00:39:06これらのシステムにエージェント的な性質、つまりAIの力によるブーストを加えたらどうでしょう。
00:39:11マルチモーダルな話になれば、ようやく現代のRAGの最前線へと
00:39:17足を踏み入れることができます。2026年4月現在の最先端、それがレベル7です。
00:39:24レベル7の「エージェント型RAG」で重視すべき大きなポイントは、
00:39:31マルチモーダルな情報の取り込み（インジェスチョン）です。これについては動画も作りましたが、
00:39:36「RAG Anything」などを使えば、画像や非テキストドキュメント（スキャンされたPDFなど）を
00:39:44先ほどのLightRAGのようなナレッジグラフ構造に取り込むことができます。また、
00:39:493月にリリースされた「Gemini Embedding 2」では、動画そのものを
00:39:56ベクトルデータベースに埋め込むことが可能です。正直、この分野はそこに向かっています。
00:40:01テキスト文書だけでは不十分です。インターネット上、特にYouTubeのような場所には
00:40:06どれほどの知識が動画として埋もれているでしょうか。単なる文字起こしだけでは足りません。
00:40:10文字起こしには限界があります。このマルチモーダルの問題は切実であり、
00:40:16これらはわずか数週間前に登場したばかりの技術です。そしてレベル7では、
00:40:20RAGシステムに出入りするデータのアーキテクチャやパイプラインにも注意を払う必要があります。
00:40:25単にデータを入れればいいというわけではありません。「これらの接続はどう作られたのか？」
00:40:30チーム開発においてデータはどう管理されるのか？ データの出力はどうなるのか？
00:40:35特定のドキュメントの情報が変わったら？ 誰かが編集したら、
00:40:40どう更新されるのか？ 重複を追加した場合は？ 本番環境レベルの運用では、
00:40:46これらすべての問いに答えなければなりません。
00:40:50このn8nのようなエージェント型RAGシステムを見ると、
00:40:54アウトライン化されたインフラの大部分が、データの取り込みと同期に
00:41:01費やされていることがわかります。純粋なRAGの部分はごく一部です。
00:41:06データをクレンジングし、「今取り込んだのはバージョン1を更新したバージョン2だ」と
00:41:11判断して古いデータを整理できるシステムが必要だからです。
00:41:17例えば、ドキュメントを直接システムに入れるのではなく、
00:41:21一度Googleドライブに置き、そこからGraphRAGにインジェストしてログを残す、といったパイプラインです。
00:41:27実運用において、こうした仕組みがRAGシステムの成否を分けることになります。
00:41:31また、エージェント型RAGについて言えば――少し画像がぼやけていますが――
00:41:37AIエージェントがプログラム全体を動かしていると想像してください。チーム用のチャットボットを
00:41:42作ったとして、常にこのデータベースにアクセスする必要があるでしょうか？ おそらく、答えはNOです。
00:41:49チームやビジネスの現場では、こうしたデータベースにあるテキスト情報のほかに、
00:41:54SQLでクエリを投げたい標準的なPostgreSQLデータベースなどの
00:41:58別のデータセットも持っているはずです。
00:42:03したがって、エージェント型RAGシステムには、それらすべてを統合する能力、
00:42:08つまり「GraphRAGデータベースを使うべきか、それともPostgreSQLでSQLを叩くべきか」を
00:42:15賢く判断する能力が求められます。これは非常に複雑になり得ます。
00:42:20すべてはユースケース次第です。だからこそ、動画ですべての例外ケースを
00:42:23網羅するのは難しいのです。レベル7で重要なのは、聞いたこともないような
00:42:30「スーパーRAGシステム」が存在することではなく、
00:42:34データのインジェスチョンや最新状態の維持といった、細部に宿る悪魔に対処することです。
00:42:39また、アクセスのしやすさも重要です。デモなら簡単です。LightRAGの画面に行って、
00:42:46検索メニューから質問すればいいだけですから。しかし、チームで運用し、
00:42:50全員が異なる角度からアクセスする場合は話が別です。おそらく、
00:42:55全員にLightRAGのWebアプリへの直接アップロード権限を与えたくはないでしょう。
00:43:01とはいえ、マルチモーダルな洗練されたRAGシステムを構築しようとしている
00:43:07個人開発者には、「RAG Anything + LightRAG」の組み合わせをお勧めします。
00:43:14これについての動画も以前出しました。お勧めする理由はいくつかあります。
00:43:19まず、オープンソースで軽量であること。多額の費用や時間をかけずに、
00:43:26自分のユースケースに合うかどうかを検証できるからです。
00:43:31私たちが避けたいのは、出口のないシステムに囚われ、そこに辿り着くために
00:43:37大金を使い果たしてしまうことです。私がObsidianを愛し、LightRAGや
00:43:42RAG Anythingを勧めるのはそのためです。試してみて、もし合わなくても
00:43:45失うのは数時間程度です。決して、MicrosoftのGraphRAGのように
00:43:50安くない費用を払い続けるわけではありません。
00:43:56レベル7が必要になる基準は、画像、表、動画などをインデックス化する必要があり、
00:44:02どの経路で回答を得るかをエージェントが自律的に判断するシステムを統合する時です。
00:44:06レベル7ではこれらすべてを統合しているはずです。恒久的な情報はClaudeのmdファイルに、
00:44:12コードベースには検索しやすいMarkdownファイルを、
00:44:16さらにObsidianのボルト（保管庫）も活用しているかもしれません。
00:44:20加えて、一部の文書はGraphRAGデータベースに格納されているでしょう。
00:44:25そして、入り口となるAIシステムが「この質問なら、このルートでいこう」と判断する。
00:44:33それが、私が提案する成熟したメモリアーキテクチャです。では、ここでの罠は何でしょうか？
00:44:40正直なところ、必要もないのに無理にこのレベルの高度さを自分に強いることです。
00:44:47実際のところ、ほとんどの人はObsidianで十分です。
00:44:52GraphRAGも、RAG全般も、本来は必要ないかもしれません。
00:44:57レベル7が必要だと確信が持てない、あるいはObsidianをまだ試していないなら、ここにいる必要はありません。
00:45:01時間の無駄になる可能性が高いからです。この動画の目的は、
00:45:07RAG、メモリ、そしてClaude Codeにおける様々なレベル、課題、緊張関係、
00:45:12トレードオフを明らかにし、あなたがどこに位置すべきかを示すことでした。
00:45:18一番大切なのは、とにかく実験してみることです。始める前に答えを知る必要はありません。
00:45:24試してみてください。できれば低いレベルから順に試すのがいいでしょう。
00:45:28Claudeのシステム内のMarkdownファイルだけで事足りるなら、それで最高です。
00:45:34次にObsidian、それで不十分ならLightRAG、といった具合です。それでは今日はこの辺で。
00:45:39RAGの本番運用、例えばチームへの導入やクライアントへの提供方法について
00:45:43詳しく知りたい方は、Chase AI Plusの中にそのためのモジュールがありますので、
00:45:47ぜひチェックしてみてください。それでは、感想をお聞かせください。
00:45:52長くなりましたが、またお会いしましょう。