Claude Code + LightRAG = 最強の組み合わせ(UNSTOPPABLE)

CChase AI
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00RAGの終焉は、かなり誇張されています。
00:00:03ええ、Opus 4.6のような大規模言語モデルが
00:00:05最近、長いコンテキストの処理能力を
00:00:09大幅に向上させたのは知っています。しかし、
00:00:12もうRAGは不要だと思っているなら、
00:00:14プロンプトだけでは解決できない壁にぶつかるでしょう。
00:00:16そこで今日は、RAGが必要な場面と、
00:00:192026年に実際に機能するRAGについて説明します。
00:00:22この1年で状況は劇的に変化しましたからね。
00:00:25さらに、Claude CodeをRAGシステムに
00:00:28接続する方法を紹介し、
00:00:30皆さんが持ち帰れるスキルを伝授します。
00:00:32今日の目標は、これを作ることです。
00:00:35LightRAGをベースに構築したGraph RAGシステムで、
00:00:38Claude Codeと一緒に利用できます。
00:00:40そして何より、膨大なドキュメント群に対して
00:00:43AIを使用する必要がある時に、
00:00:45このシステムが力を発揮します。
00:00:49デモでお見せするような5つや10つの文書ではなく、
00:00:51500、あるいは1,000もの文書を
00:00:52扱う場合の話です。
00:00:55なぜなら、Claude Codeや他のLLMが持つ
00:00:57コンテキストウィンドウだけに頼るのは不十分だからです。
00:00:59規模が巨大になると、
00:01:01大企業だけでなく中小企業でも、
00:01:03このようなRAGシステムを持つ方が、
00:01:05標準的なエージェントによる検索よりも
00:01:06安価で高速になります。
00:01:10ですから、このようなRAGシステムを
00:01:12構築するスキルを身につけることは非常に重要ですが、
00:01:13幸いなことに、実はとてもシンプルです。
00:01:14先ほど触れた通り、
00:01:16今回はLightRAGを使用します。
00:01:18これは私が大好きなオープンソースのリポジトリです。
00:01:19しばらく前から存在しており、
00:01:21何度もアップデートが重ねられてきました。
00:01:25Microsoftのような、より洗練された
00:01:26Graph RAGシステムとも競合できる性能を、
00:01:28わずか数分の一のコストで実現しています。
00:01:30そのため、Graph RAGのコンセプトを
00:01:32初めて試すには最適な場所です。
00:01:35しかし、LightRAGを最大限に活用するには、
00:01:37まずRAGが根本的にどう機能するかを知る必要があります。
00:01:40RAGを取り巻く環境は変わりましたから。
00:01:432024年末から2025年初頭にかけて行われていたのは、
00:01:46「Naive RAG(素朴なRAG)」と呼ばれる最も基本的なものです。
00:01:48n8nの自動化などで「PineconeやSupabaseに行こう」
00:01:51といった手法を覚えていますか?
00:01:54あれがNaive RAGです。
00:01:56それはもう通用しません。
00:01:58それでは不十分なのです。
00:02:00より洗練されたバージョンのRAGを使う必要がありますが、
00:02:02まずは基礎を理解しておきましょう。
00:02:03LightRAGの設定に入る前に、
00:02:06RAGとは何か、どう機能するのかを簡単におさらいします。
00:02:08RAG、つまり検索拡張生成(Retrieval Augmented Generation)。
00:02:12その仕組みは、まず何らかのドキュメントを
00:02:14用意するところから始まります。
00:02:18本格的なRAGシステムでは、
00:02:20これが何千枚にもなります。
00:02:22システムに取り込みたいこのドキュメントを、
00:02:25ベクトルデータベースに入れます。
00:02:27しかし、ドキュメントをそのまま
00:02:29データベースに放り込むわけではありません。
00:02:31Googleドライブのような仕組みとは違うのです。
00:02:34ドキュメントは埋め込み(embedding)モデルを通り、
00:02:38ベクトルに変換されます。
00:02:40さらに言うと、ドキュメントは
00:02:41一つの巨大な塊として扱われるのではなく、
00:02:44「チャンク(断片)」に分割されます。
00:02:46例えばこの1ページのドキュメントが、
00:02:47チャンク1、チャンク2、チャンク3へと分割されるイメージです。
00:02:50それぞれのチャンクがベクトルになります。
00:02:51ベクトルとは、グラフ上の点、
00:02:54つまりベクトルデータベース内の特定の位置のことです。
00:02:59埋め込みモデルがこの分割(チャンキング)を担います。
00:03:03ドキュメントの内容を理解し、
00:03:05それをグラフ上の点に変換する役割です。
00:03:06こうしてドキュメントはチャンク化され、
00:03:09埋め込みモデルを経て、
00:03:11グラフ上のベクトルとなります。
00:03:13ここでは3次元のグラフとして説明していますが、
00:03:16実際には何千もの次元を持っています。
00:03:18今はとりあえず3次元だと考えてください。
00:03:20さて、このドキュメントが「軍艦」についてのものだとしましょう。
00:03:24各ベクトルは軍艦に関する
00:03:27チャンクに変換されました。
00:03:30それはどこに配置されるでしょうか?
00:03:33当然、ボートや船のベクトルの近くに配置され、
00:03:36独立したベクトルになります。
00:03:39ベクトルとは、要するに
00:03:40その内容を表す一連の数値のことです。
00:03:41こちらのバナナの例を見てください。
00:03:43バナナは 0.52, 5.12, 9.31... といった具合に、
00:03:45数千個の数字で表現されます。
00:03:46私たちの船のベクトルも、1, 2, 3... と
00:03:50数字がずっと続いていきます。
00:03:53簡単ですね。
00:03:57バナナやリンゴの隣には配置されませんが、
00:04:00これが「ドキュメントの埋め込み」と
00:04:05「チャンキング」のプロセスです。
00:04:07では、あなたがここにいるとします。
00:04:08あなたは楽しそうなユーザーで、
00:04:10LLMに軍艦について質問をしました。
00:04:14RAGシステムのシナリオでは、
00:04:15その「質問」もベクトルに変換されます。
00:04:18LLMが質問内容を確認し、
00:04:20このデータベース内の何らかのベクトルに対応する
00:04:21一連の数値を割り当てます。
00:04:24そして、質問のベクトルと
00:04:27グラフ上の他のベクトルを比較します。
00:04:30「コサイン類似度」というものを見ていますが、
00:04:34要するにこう言っているのです。
00:04:35「質問はこの内容だ。この数値を割り当てよう。
00:04:38これに最も近いベクトルはどれかな?」
00:04:41「この数値に最も近いのはどれだ?」
00:04:43それは軍艦に関するベクトルであり、
00:04:45おそらくボートや船に関するものでしょう。
00:04:49そこでシステムは、それら全てのベクトルを
00:04:51付随する情報と共に取り出し(リトリーブ)、
00:04:53生成される回答をその情報で補強(オーグメント)します。
00:04:55これが「検索拡張生成(RAG)」です。
00:04:56つまり、LLMが自身の
00:04:58学習データだけに頼るのではなく、
00:05:00ベクトルデータベースの中から関連するベクトルを掴み取り、
00:05:02それを持って帰ってきて、軍艦に関する回答を出すのです。
00:05:04これがRAGの仕組みです。
00:05:08文書の取り込み、チャンクのベクトル化。
00:05:10ベクトルを質問と比較し、
00:05:13最も近いものを取ってくる。はい、RAGの完成です。
00:05:16これがNaive RAGですが、
00:05:17実際のところ、これだけではあまり上手くいきません。
00:05:19そこで、非常に賢い人々が
00:05:22より優れた方法を考案しました。
00:05:24それが「ハイブリッド検索」「Graph RAG」「エージェントRAG」です。
00:05:27今日、私たちが焦点を当てるのはGraph RAGです。
00:05:29Graph RAGも同じプロセスを通ります。
00:05:32ドキュメントを用意し、
00:05:35それをチャンクに分割します。
00:05:39それらをフラットなベクトルデータベースに入れますが、
00:05:40もう一つ別の工程が加わります。
00:05:44「ナレッジグラフ」を作成するのです。
00:05:46この複雑なグラフを構築します。
00:05:49これら全てのベクトルと線、
00:05:53一体これらは何を意味しているのでしょうか?
00:05:55この小さな丸いベクトルたちは、
00:05:57「エンティティ(実体)」として知られています。
00:05:58そして、2つのエンティティを結ぶ線は
00:05:59「エッジ」または「リレーションシップ(関係性)」です。
00:06:03ドキュメントの例に戻ると、
00:06:05これがAnthropic社とClaude Codeについての文書だとします。
00:06:07抽出されたチャンク全体にこう書かれていたとしましょう。
00:06:08「AnthropicがClaude Codeを作成した」
00:06:09システムはこれを読み取り、
00:06:11エンティティと関係性に分解します。
00:06:122つのエンティティは何でしょうか?
00:06:14エンティティは「Anthropic」と
00:06:17「Claude Code」になります。
00:06:21そして関係性は「AnthropicがClaude Codeを作成した」です。
00:06:23ここにAnthropicがあり、
00:06:25こちらにClaude Codeがあります。
00:06:28これがエンティティ、これがエンティティ、
00:06:31そして両者には関係性があります。
00:06:35可視化されたグラフ上では単なる線ですが、
00:06:36内部のコード上では、
00:06:382つのエンティティ間のその線には
00:06:39関係性を説明するテキストが
00:06:41大量に紐付いています。
00:06:44Graph RAGシステムでは、
00:06:48追加する全てのドキュメントに対してこれを行います。
00:06:51これが1,000個のドキュメントで行われるのを想像してください。
00:06:54これは10個のドキュメントによる
00:06:58関係性とエンティティの図です。
00:06:59ベクトルデータベースに孤立している
00:07:03ランダムなベクトルの集まりよりも、
00:07:05いかに洗練されているか想像がつくでしょう。
00:07:08LightRAGのようなシステムを使うと、
00:07:10ナレッジグラフの構築と、
00:07:11標準的なベクトルデータベースの両方が得られます。
00:07:13これら2つを並行して実行するのです。
00:07:16そのため、あなたがLLMに対して
00:07:19何らかの質問を投げかけると、
00:07:21最も近い特定のベクトルを
00:07:24引き出すだけでなく、
00:07:26グラフ上のエンティティも参照します。
00:07:28例えば、Anthropicについて尋ねたとします。
00:07:30するとシステムは関係性(エッジ)を辿り、
00:07:33関連すると判断した全てを見つけ出します。
00:07:35これがユーザーであるあなたにとって
00:07:38何を意味するかというと、
00:07:40単にドキュメント内を「Control + F」で
00:07:43検索するようなレベルではなく、
00:07:45より深い質問ができるようになるということです。
00:07:47異なるドキュメント、理論、アイデアが
00:07:49互いにどう関連しているかを問うことができます。
00:07:54それらの関係性がマップ化されているからです。
00:07:56これが核心です。
00:07:59バラバラの情報を繋ぎ合わせること。
00:08:03それこそがGraph RAGの力なのです。
00:08:06それでは、実際に構築してみましょう。
00:08:08これにより、ユーザーである皆さんは GraphRAG システムを使って
00:08:11単にドキュメントについてだけでなく、より深い質問ができるようになります。
00:08:13実質的にあらゆる目的において
00:08:15「Ctrl+F」で検索するだけのようなものではありません。
00:08:17異なるドキュメント、異なる理論、
00:08:19そして異なるアイデアがどのようにお互いに関連しているかを尋ねることができます。
00:08:21なぜなら、それらの関係性がマッピングされているからです。そうでしょう?
00:08:24これこそが肝心な点です。
00:08:25バラバラな情報を取り込み、それらをつなぎ合わせること。
00:08:30それが GraphRAG の力です。
00:08:32それが LightRAG の力なのです。
00:08:33そして、今日はそれを学んでいきます。
00:08:35LightRAG のインストールと使用は、
00:08:37驚くほど簡単です。
00:08:40最も簡単な方法をお見せしましょう。
00:08:42Claude Code を使います。
00:08:44LightRAG の URL を渡し、
00:08:48「これをセットアップして」と言うだけです。
00:08:50そうすれば、基本的にはすべて自動で行われます。
00:08:52そのシナリオでは、いくつか必要なものがあります。
00:08:55RAG の仕組みの解説で見たように、
00:08:58埋め込み(Embedding)モデルが必要です。
00:08:59そのためには API が必要になります。
00:09:02OpenAI を使うことをお勧めします。
00:09:04彼らは非常に効果的な埋め込みモデルを持っています。
00:09:07ですので、OpenAI のキーが必要になります。
00:09:09LightRAG では、
00:09:11すべてを完全にローカル環境で完結させることも可能です。
00:09:14つまり、Ollama 経由でローカルモデルを使い、
00:09:17埋め込みによる解析や、
00:09:20質疑応答のすべてを行うこともできます。
00:09:21完全にローカルにするという選択肢もあることを理解しておいてください。
00:09:24今回は「半分ずつ」の方法で行います。
00:09:25OpenAI の埋め込みモデルと、
00:09:28実際に処理を行うモデルの両方をセットアップします。
00:09:31それから Docker も必要です。
00:09:34Docker を使ったことがなくても、
00:09:35セットアップはとても簡単です。
00:09:36Docker Desktop が必要なので、
00:09:39ダウンロードしてインストールし、起動しておいてください。
00:09:41LightRAG を実行する際に、
00:09:42コンテナが必要になるからです。
00:09:45では、これから行うことは、
00:09:46Claude Code を開いて、
00:09:47「LightRAG のリポジトリをクローンして、
00:09:50OpenAI 用に構成された .env ファイルを書き、
00:09:53GPT-4o mini と text-embedding-3-large を使い、
00:09:56デフォルトのローカルストレージをすべて使用して、
00:09:58Docker Compose で起動して」と伝えます。
00:10:00そして LightRAG へのリンクを渡します。
00:10:02そうすれば、すべて代わりに行ってくれます。
00:10:06このプロンプトは、無料の School コミュニティ内に置いておきます。
00:10:10リンクは概要欄にあります。
00:10:12また、そこには
00:10:13後ほど詳しく説明しますが、
00:10:15Claude Code からコントロールしやすくするための
00:10:17Claude Code と LightRAG 関連のスキルも置いてあります。
00:10:19ですので、そちらも確認してみてください。
00:10:22さて、お決まりの流れですが、
00:10:22私の運営する School について話させてください。
00:10:24Claude Code マスタークラスの宣伝です。
00:10:25これは初心者から AI 開発者になるための最短ルートです。
00:10:28特に技術的なバックグラウンドがない方には最適で、
00:10:31リンクは固定コメントにあります。
00:10:33私は文字通り毎週更新しており、
00:10:35ここ 2 週間だけでも、
00:10:36すでに約 1 時間半分の
00:10:38追加コンテンツを加えました。
00:10:39ですので、本気で Claude Code や
00:10:40AI 全般をマスターしたい方は、ぜひチェックしてください。
00:10:42繰り返しになりますが、始めたばかりでこれらが難しく感じる方は、
00:10:44無料の School を覗いてみてください。
00:10:46初心者向けの
00:10:47素晴らしいリソースがたくさんあります。
00:10:49実行する前に、
00:10:50Docker Desktop が起動していることと、
00:10:51OpenAI のキーが準備できていることを確認してください。
00:10:53あとは Claude Code に任せましょう。
00:10:55Claude Code がインストールを終え、
00:10:56.env ファイルに OpenAI キーを追加すると、
00:10:58このような画面が表示されるはずです。
00:11:01まず Docker Desktop 上で、
00:11:02LightRAG という名前のコンテナが稼働しているのが見えます。
00:11:04そして Claude Code は、
00:11:07ローカルホスト(通常は 9621 ポート)へのリンクを
00:11:11教えてくれるはずです。
00:11:13そこへ行くと、このようなページが表示されます。
00:11:15これが LightRAG のウェブ UI です。
00:11:18ここでドキュメントのアップロードや、
00:11:21ナレッジグラフの確認、情報の検索ができます。
00:11:24また、さまざまな
00:11:25API エンドポイントを確認することもでき、
00:11:28これは後で役に立ちます。
00:11:30ここに表示されているのは、
00:11:31この動画のためにアップロードしたドキュメントです。
00:11:33ドキュメントのアップロードは非常に簡単です。
00:11:35右側の「Upload」と書かれた場所に来て、
00:11:36ファイルをドロップするだけです。
00:11:39ただし、入力できるドキュメントの種類には制限があります。
00:11:42基本的にはテキストドキュメントや
00:11:43PDF など、
00:11:46テキスト形式のものに限られます。
00:11:49これを回避する方法もあります。
00:11:51画像や図、表などの
00:11:56データについても同様です。
00:11:57少し範囲外の話になるので、
00:11:59動画の最後の方で説明しますが、
00:12:00やり方は学んでいきます。
00:12:02任意のドキュメントをここにドロップすれば、
00:12:04アップロード中の
00:12:07ステータスを確認できます。
00:12:08処理中にナレッジグラフを構築するため、
00:12:10少し時間がかかります。
00:12:12しばらくお待ちください。
00:12:14もしナレッジグラフのページで
00:12:16「ロードできませんでした」といった表示が出た場合は、
00:12:18左上のこのボタンを押して
00:12:19リセットしてください。
00:12:21「Retrieval(検索)」タブでは、
00:12:23ナレッジグラフについて LLM に
00:12:25質問を投げることができます。
00:12:27この場合、埋め込みと同じキーを使っていれば、
00:12:30LLM は OpenAI のものになります。
00:12:31右側にはいくつかのパラメータがあります。
00:12:33正直なところ、最初から変更する必要があるものは多くありません。
00:12:36すぐに Claude Code でのやり方をお見せします。
00:12:39例えば、AI と RAG に関するドキュメントをたくさん入れていたので、
00:12:42「2026 年における RAG 運用の
00:12:44コストの全体像はどうなっていますか?」と聞きました。
00:12:47すると、かなり高度な回答が返ってきました。
00:12:48さらに、何に基づいて回答したかという
00:12:50参照(リファレンス)もすべて表示されます。
00:12:53「4, 3, 2」のように番号が振られていますが、
00:12:56ページの下部を見ると、
00:12:57取得したドキュメントのリファレンスが
00:13:00実際に表示されています。
00:13:01当然ながら、ナレッジグラフ内では、
00:13:03エンティティと関係性が説明されています。
00:13:05例えば OpenAI というエンティティをクリックすると、
00:13:07そのプロパティを確認できます。
00:13:09LightRAG の埋め込みプロセスは、単に関係性やエンティティを
00:13:12抽出するだけではありません。
00:13:14実際にはさらに深く踏み込み、
00:13:17「このエンティティのタイプは何ですか?
00:13:19組織ですか、それとも個人ですか?」といったことまで判別します。
00:13:20また、抽出元の特定のファイルや、
00:13:22チャンク ID も保持しています。
00:13:25そして、右下の方では
00:13:27実際の関係性を見ることができます。
00:13:29(画面を少し動かします)
00:13:31この右下の部分ですが、
00:13:32グラフ上で視覚的に判別しにくい場合は、
00:13:33(情報が密集しがちなので)
00:13:35ここをクリックすれば、
00:13:36関係性のリストに飛ぶこともできます。
00:13:40さて、このサーバー API こそが、
00:13:41これを Claude Code に接続するために使うものです。
00:13:43この UI も素晴らしいのですが、
00:13:46正直なところ、
00:13:48ナレッジグラフに質問したいときに、毎回わざわざ
00:13:50「Retrieval」タブを開いて座っているつもりはありません。
00:13:51それはあまりにも面倒です。
00:13:53代わりに、これらの API を活用します。
00:13:56これらの各 API には、
00:13:57説明があり、パラメータなども確認できます。
00:14:00これらすべてを「スキル」に変換できるのです。
00:14:03今からそれを行い、皆さんにお見せします。
00:14:05そうすれば、Claude Code で LightRAG を使いたいときに、
00:14:08Claude Code 上で「LightRAG クエリスキルを使って、
00:14:11~について質問して」と言うだけで済みます。
00:14:15これはウェブ UI の「Retrieval」タブで
00:14:17質問するのと全く同じことです。
00:14:19さらに良いことに、Claude Code はその回答を受け取り、
00:14:22要約してくれます。
00:14:23LightRAG の生の回答は、
00:14:26かなり詳細になりがちだからです。
00:14:28もし生の回答だけが欲しい場合は、
00:14:30そのように設定することも可能です。
00:14:32要するに、ウェブ UI はありますが、
00:14:34使いたくなければ、
00:14:36一度も触る必要はないということです。
00:14:37私たちの Claude Code エコシステムに
00:14:40取り込むのは非常に簡単です。
00:14:41最もよく使う 4 つの大きなスキルは、
00:14:42Query(クエリ)、Upload(アップロード)、Explore(探索)、Status(ステータス)です。
00:14:44これら 4 つも無料の School に置いておきます。
00:14:46主に何をするかというと、
00:14:48新しいドキュメントを追加し、
00:14:51それについて質問することになるでしょう。
00:14:55また、「何を入れたっけ?」と
00:14:56確認したくなることもあるはずです。
00:14:58ドキュメントが大量になると、
00:15:01同じものを何度も繰り返し入れるのは
00:15:02避けたいですからね。
00:15:04Claude Code 上で先ほどと同じ質問をすると、
00:15:05LightRAG クエリスキルが呼び出され、
00:15:07リクエストが LightRAG へ送られます。
00:15:08これは自分の PC 上の
00:15:12Docker コンテナ内で動作しており、
00:15:14回答をこちらへ返してくれます。
00:15:18それは私たちのコンピュータ上でホストされ
00:15:21そのDockerコンテナ内で動作しており
00:15:22レスポンスを返してくれます
00:15:24さて、このセミローカルなシステムに限定されるわけではありません
00:15:28もしLightRAGで
00:15:30非常に大規模なスケーリングを行う場合は
00:15:33標準的なPostgresサーバーでホストすることも可能です
00:15:36Neonのようなサービスを使うなど、多くの選択肢があります
00:15:38つまり、あらゆる状況に対応できるのです
00:15:40完全にローカルにすることも、必要に応じて
00:15:43すべてをクラウドに移行することもできます
00:15:44LightRAGは非常にカスタマイズ性が高いのです
00:15:46そして、こちらがCloudCodeが返してきたレスポンスです
00:15:48これは、LightRAGが提供した生のレスポンスを
00:15:52要約したもので、ソースも引用しています
00:15:55生のレスポンスも取得できるので
00:15:57それも要求しておきました
00:15:58CloudCodeには単に
00:16:00JSON形式で返ってくるだけだからです
00:16:02仕組みはそれだけです
00:16:04繰り返しになりますが、必要であれば参照も含まれています
00:16:07ご覧の通り、LightRAGのインストールは非常に簡単で
00:16:10CloudCodeのワークフローへの統合も非常にシンプルです
00:16:14そこで問題になるのは、「チェイス、理屈は分かった。
00:16:18大量のドキュメントがあるなら、これを使うべきなんだろう。
00:16:20では、その境界線はどこにあるのか?」ということです
00:16:22いつLightRAGを導入し始めるべきでしょうか?
00:16:23これには明確な数字はありませんが
00:16:26グレーゾーンとしては、だいたい
00:16:28500ページから2000ページくらいの
00:16:33ドキュメント量だと思います
00:16:36単に「ドキュメント」と言いたくないのは
00:16:37そのサイズが分からないからですが
00:16:39テキストで500枚から2000枚程度ですね
00:16:422000ページになると
00:16:44100万トークンほどになり始めます
00:16:47それ以上であれば、間違いなく
00:16:50LightRAGの統合を検討する価値があります
00:16:52なぜなら、RAGの仕組み上
00:16:54CloudCodeの標準的なgrep機能だけに頼るよりも
00:16:57安価で高速になるからです
00:17:00CloudCodeがファイルを検索する手法である
00:17:03Agented grepは、それ自体すでに素晴らしいものです
00:17:04CloudCodeがそれを採用したのには理由があります
00:17:07しかし、それは2000ページや
00:17:124000、5000ページもの資料がある想定ではありませんでした
00:17:14限界があるのです
00:17:16幸いなことに、その決断を
00:17:19今すぐ確定させる必要はありません。先ほど見たように
00:17:22実装は非常に簡単ですから
00:17:24まずは試してみてください
00:17:26もし大量のドキュメントがあって
00:17:28「今の時点でRAGを使うべきかな?」と思ったら
00:17:30とりあえずやってみることです
00:17:32時間はかかりません
00:17:34一番大変なのはエンベディングのプロセスです
00:17:36確かに少し時間はかかりますが、支障が出るほどではありません
00:17:40コストも、特にLightRAGなら法外ではありません
00:17:43Microsoft GraphRAGのような
00:17:45他のGraphRAGシステムと比較すれば
00:17:48コストはごくわずかです
00:17:49そして非常に膨大なドキュメント量の場合
00:17:52RAGを使うコストと、grepのような手法を使うコストを比べると
00:17:561000倍も安くなることがあります
00:17:58昨年の夏に行われた
00:18:04ある調査によると、そのような状況では
00:18:07RAGを使う方が1250倍安かったそうです
00:18:08ここでTextual RAGと
00:18:10Textual LLM、そして実際の応答時間の比較が見られます
00:18:14正直に申し上げますと、これは昨年の7月のデータです
00:18:19モデルは進化しています
00:18:20RAGと標準的なテキスト処理を比較したときに
00:18:23今でもこれほど劇的な差があるかは疑問です
00:18:26当時はGemini 2.0もありませんでしたし
00:18:28Harnessについても話していませんでした
00:18:29多くの状況が変わっていますが
00:18:31その1250倍という差を埋めるほどでしょうか?
00:18:36そうかもしれませんし、違うかもしれません
00:18:39私はそうは思いません
00:18:40いずれにせよ、試してみてください
00:18:42失うものはほとんどありません
00:18:44LightRAGに関してもう一つ、ドキュメントのアップロードについて
00:18:46先ほど少し触れましたが
00:18:48表やグラフのような
00:18:49テキスト以外のものが含まれている場合は
00:18:53どうすればいいでしょうか?
00:18:54LightRAGでそれらを扱えるでしょうか?
00:18:57正確にはNOですが、解決策はあります
00:18:59その答えは「RAG Anything」です
00:19:02LightRAGと同じ開発者によるものです
00:19:04これは実質的にマルチモーダル対応で
00:19:07LightRAGの上にそのまま
00:19:09プラグインのように追加できます
00:19:10がっかりさせて申し訳ないのですが
00:19:13それは今日の動画の
00:19:15範囲外となります
00:19:17ですが、明日の動画では
00:19:18何をすると思いますか?
00:19:19明日はRAG Anythingを取り上げ
00:19:22LightRAGで構築したものに
00:19:25どう統合するかを解説します
00:19:27素晴らしいコンビネーションになるでしょう
00:19:28もし興味があれば
00:19:31高評価とチャンネル登録をお願いします
00:19:32明日詳しく説明しますので
00:19:34というわけで
00:19:35今回はこのあたりで締めたいと思います
00:19:39楽しんでいただけたなら幸いです
00:19:41この新しいカメラ設定での初動画でしたが
00:19:43ライティングが、自分でも分かりますが
00:19:46思うような仕上がりではありませんでした
00:19:48その点はお詫びいたします
00:19:49まだ調整中ですが
00:19:50とにかく動いてよかったですし
00:19:52途中でカメラがオーバーヒートしなくて助かりました
00:19:55スキルの詳細は無料のスクールにあります
00:19:58RAG、特にLightRAGは非常に興味深いものです
00:20:01本当に素晴らしいプロダクトで
00:20:02私もかなり長く愛用しています
00:20:03100%、ぜひチェックしてみてください
00:20:06ご覧いただいた通り
00:20:07CloudCodeへの統合も簡単です
00:20:08スキルやプロンプトが必要な方は
00:20:12無料のスクールを確認してください
00:20:14正直なところ
00:20:15CloudCodeをLightRAGに向けるだけで
00:20:16勝手にセットアップしてくれます
00:20:19それでは
00:20:20マスタークラスに興味がある方は
00:20:21Chase AI Plusもチェックしてください
00:20:24では、またお会いしましょう

Key Takeaway

100万トークンを超える膨大な文書群を扱う際は、Claude Codeの標準検索に頼るのではなく、LightRAGで構築したナレッジグラフをAPI経由で統合することで、コストを最大1000倍以上抑えつつ情報の相関関係に基づいた深い洞察を得られる。

Highlights

LightRAGは、Microsoft GraphRAGの数分の一のコストで同等のナレッジグラフ構築能力を提供し、情報の関係性を可視化する。

テキストベースで500ページから2000ページ(約100万トークン)を超える大規模な文書群を扱う場合、標準的な検索よりもRAGの導入が適している。

2024年までの「Naive RAG(素朴なRAG)」は精度不足であり、2026年現在はエンティティとエッジを定義するGraph RAGが主流となっている。

特定の調査データによれば、膨大なドキュメント処理においてRAGを利用する手法は、標準的なLLM処理(grep等)に比べて最大1250倍安価になる可能性がある。

Claude CodeとLightRAGをAPI経由で接続し、専用の「スキル」として組み込むことで、ターミナルから直接ナレッジグラフへのクエリや文書アップロードが完結する。

Timeline

2026年におけるRAGの必要性と進化

  • LLMのコンテキストウィンドウが拡大しても、数千規模の文書を扱うにはプロンプトだけでは不十分である。
  • 単純なベクトル検索のみを行う「Naive RAG」は、現代の複雑な情報処理要求には対応できない。
  • 大規模な組織だけでなく中小企業にとっても、独自のRAGシステムを持つことが速度とコストの両面で有利に働く。

長大なコンテキストを処理できるOpus 4.6のようなモデルが登場しても、RAGの役割は終わっていない。500から1000もの膨大なドキュメント群を扱う場合、モデルのメモリだけに頼ると処理が低速化し、コストも増大する。そのため、2026年の環境ではより洗練されたGraph RAGへの移行が必須となっている。

ベクトル検索からナレッジグラフへの仕組み

  • ドキュメントは「チャンク」に分割され、埋め込みモデルを通じて高次元のベクトルとしてデータベースに格納される。
  • Graph RAGは、文書から「エンティティ(実体)」と「エッジ(関係性)」を抽出し、情報のつながりをマップ化する。
  • 質問内容をベクトル化してコサイン類似度で比較するだけでなく、関連するエンティティの関係性を辿ることで深い回答を生成する。

従来のRAGは単に関連する断片を拾うだけだったが、LightRAGは「AnthropicがClaude Codeを作成した」といった具体的な関係性を構造化する。これにより、複数の文書にまたがるアイデアや理論がどのようにつながっているかを問うことが可能になる。可視化されたグラフ上の各ノードには、属性情報やチャンクIDなどの詳細なメタデータが紐付いている。

Claude CodeとLightRAGのセットアップ手順

  • Docker DesktopとOpenAIのAPIキーを用意すれば、Claude Codeへの指示だけで環境構築が完了する。
  • 埋め込みモデルにはtext-embedding-3-large、推論にはGPT-4o miniを組み合わせる構成が推奨される。
  • Ollamaを使用することで、すべての処理を外部APIに頼らずローカル環境で完結させる選択肢も存在する。

Claude CodeにLightRAGのリポジトリURLを渡し、.envファイルの作成やDocker Composeの実行を指示するだけで自動的にサーバーが立ち上がる。このシステムは「半分ローカル、半分クラウド」の構成が可能で、データのプライバシーと処理能力のバランスを柔軟に調整できる。セットアップが完了すると、ポート9621でウェブUIにアクセスできるようになる。

APIを利用したワークフローの自動化とスキルの活用

  • ウェブUIを介さず、Query、Upload、Explore、Statusの4つのAPIエンドポイントをClaude Codeのスキルとして登録する。
  • LightRAGが生成する詳細すぎる生の回答を、Claude Code側で要約してユーザーに提示する。
  • バックエンドとしてNeonのようなPostgresサービスを利用すれば、さらなる大規模スケーリングにも対応できる。

ナレッジグラフへの質問を効率化するため、APIを「カスタムスキル」として統合する。これにより、ターミナル上で「~について質問して」と入力するだけで、Dockerコンテナ内のLightRAGが回答を生成し、Claude Codeがソース引用付きで要約を返す仕組みが整う。UIを一度も触ることなく、シームレスにナレッジベースを管理・利用できるのが最大の利点である。

RAG導入の判断基準と将来の拡張性

  • 文書量が500ページから2000ページを超え始めたタイミングが、RAG導入を検討すべき境界線となる。
  • 「RAG Anything」をプラグインとして追加することで、画像や表などの非テキストデータも扱えるようになる。
  • Microsoft GraphRAGと比較して、LightRAGは構築コストが大幅に抑えられており、試行のハードルが低い。

Claude Code標準のgrep機能は強力だが、数千ページの資料をスキャンするには限界がある。2024年夏の調査では、特定の条件下でRAGの方が1250倍安価であったという結果も出ている。今後はマルチモーダル対応の「RAG Anything」を統合することで、より多様な資料形式をナレッジグラフに組み込むことが可能になる。

Community Posts

View all posts