RAG不要論の実際
――何度も語られる「もうRAGはいらない」は本当か
2026年2月、「RAGはもう要らないのではないか」という議論が再び注目を集めた。発端は、AnthropicのシニアエンジニアでありClaude Codeの開発責任者であるBoris Cherny氏の一言だ。実は、このRAG不要論は今回が初めてではない。本記事ではRAG不要論の歴史を整理し、今あらためてRAGの必要性を問い直す。
01RAG不要論の歴史
「RAGは不要ではないか」という議論は、RAGが登場したときから繰り返されてきた。今回の盛り上がりを正しく評価するためにも、これまでの経緯を整理しておこう。
① 登場時：ファインチューニングでいいのでは？
RAGが登場した当初から、「自社データを追加学習させるファインチューニングで十分ではないか」という声があった。ファインチューニングは推論時に検索処理を挟まないため、回答速度が速い点が魅力だった。
ただし、新しい情報を学習させるたびに膨大な計算リソースと時間が必要になる点、そしてハルシネーション（事実と異なる情報の生成）が起きやすい点がネックとなった。その後、「ファインチューニングはモデルの振る舞いを調整するもの、RAGは最新知識を参照するもの」という役割分担が定着し、この不要論は下火になった。
② コンテキストウィンドウ拡張時：全部入れればいいのでは？
現在の主要なLLMは、100万トークン（文庫本7～10冊分に相当）ものコンテキストウィンドウを持つ。ここで浮上したのが「RAGを構築しなくても、プロンプトにすべてのデータを貼り付ければいいのではないか」という議論だ。
確かに、複雑なシステムを事前に構築しなくても済むというシンプルさは大きな魅力だ。ただし、毎回大量のデータを添付する手間や、処理時間・コストの増大という課題も存在する。
③ Cherny氏の発言：Agentic Searchのほうがいいのでは？
今回の議論の発端となったのが、X（旧Twitter）へのCherny氏の投稿だ。
―Boris Cherny (@bcherny), 2026年2月
Claude Codeの開発責任者という実運用の最前線からの発言だけに、大きな注目を集めた。この発言はコードという頻繁に更新されるデータを扱う文脈でのものだったが、「そもそもRAGは不要では？」という広い議論へと発展した。
Anthropicには「手書きコード禁止」という企業文化がある。人間が知識ベースの設計や探索方針を決めるRAGは、この文化と相性が悪い。さらに開発プロセスの80%以上をAIが担い、秒単位でコードが更新される環境では、RAGの「事前インデックス作成」がボトルネックになりやすいという背景もある。
02そもそもRAGとは何か
RAGが登場した背景
LLMは学習データに基づいて確率的に言葉を生成するシステムだ。そのため、ネット上に公開されていない自社データ（社内ルール、過去の経緯、個別の契約内容など）は推論に使えない。
そこで企業が求めたのが、「自社の非公開データを使って、より正確で自社に適した回答を引き出す仕組み」だった。RAGはその答えとして登場した。
RAGの仕組み
RAGは「Embedding（埋め込み）＋ベクトルDB＋セマンティック検索」という組み合わせで動く。
まず、文書や資料をベクトル（数値の配列）に変換してデータベースに保存する。ユーザーからの質問も同様にベクトル化し、意味的に近い情報をデータベースから検索して、その結果をLLMに渡して回答を生成する流れだ。
RAGの問題点と改良の試み
普及が進むにつれ、2つの大きな課題が明らかになってきた。
| 課題 | 内容 |
|---|---|
| ① 精度が上がらない | 意味が近くても表現が異なれば見つからない。長文をチャンク（塊）に分割する際に文脈が途切れる問題もある。 |
| ② 構築・運用コストが高い | データサイエンティストの専門知識が必要で、ベクトルDBの維持費もかさむ。データ更新のたびに再インデックスが必要。 |
| ③ セキュリティリスク | 社内の機密情報が入ったDBを自動的に参照する構造のため、情報漏洩リスクへの考慮が必要。 |
これらの課題を解決しようと、GraphRAG（Microsoftなどが推進。文書からエンティティと関係性を抽出してグラフ構造で管理）やハイブリッドRAG（ベクトル検索とキーワード検索を組み合わせる）といった改良版も登場している。ただし、いずれも精度向上には貢献する一方で、構築・運用コストはさらに増大する傾向がある。
↑ 目次に戻る03RAG以外の手法
ロングコンテキスト
すべての関連文書をそのままLLMのプロンプトに入力してしまう方法だ。事前のシステム構築が不要で、チャンク分割による文脈の途切れも起きない。
課題は、毎回大量のデータを添付する手間と処理コストの増大である。ただし、コンテキストキャッシング（一度入力したデータを保存して再利用する技術）の発展により、この問題は徐々に緩和されてきている。
Agentic Search
今回の議論の中心となった手法だ。AIが自律的に探索計画を立て、grepやglobなどのツールを使いながら段階的に情報を探索する。
RAGは「事前に作った地図から答えを探す」、Agentic Searchは「AIが自分で地図を描きながら答えを探す」イメージだ。
マルチステップ推論で複雑な質問に強く、自己検証機能により回答精度も高い。一方、探索を繰り返す分だけ処理時間が長くなり、LLMのコストも増加するというデメリットがある。
3つの手法の比較
| 手法 | 向いているケース | 弱点 |
|---|---|---|
| RAG | 大規模な社内知識ベース 更新頻度が低いデータ |
構築コスト・精度の限界 セキュリティ管理 |
| ロングコンテキスト | 参照ファイル数が少ない シンプルな用途 |
毎回の入力コスト 大規模データには不向き |
| Agentic Search | 頻繁に更新されるデータ 複雑な推論が必要な場面 |
処理時間・コスト増大 複雑なシステム設計 セキュリティ管理 |
04NotebookLMという答え
技術的な議論とは別に、現実の普及という観点から見逃せない存在がGoogleのNotebookLMだ。
社内文書やWebの文書をアップロードするだけで、その内容に基づいて回答したり資料を作成したりできるサービスで、回答の根拠となった元資料の該当箇所を逆引きできるソースグラウンディング機能も備えている。
NotebookLMをひと言で言えば：「ノーコードRAG」
ベクトル化などの複雑な作業を製品側が自動処理するため、ユーザーは使いたい文書を指定するだけでよい。従来のRAGが「材料から自分で調理する自炊」だとすれば、NotebookLMは「一流シェフがコース料理を作ってくれるサービス」のようなものだ。
ただし、NotebookLMにも限界はある。1ノートに入力できるファイル数は有料版でも300ファイルまで、ファイルサイズは200MBまで、文字数は1ファイルあたり50万単語まで。大企業のデータをすべて取り込むような用途には対応していない。また、精度が上がらないときに細かい調整ができない（処理がブラックボックスになっている）という制約もある。
↑ 目次に戻るおわりに
RAG不要論が何度も繰り返される背景には、「RAGの構築・運用が面倒だ」という根強い不満がある。一方で、RAGが生き残り続けてきたのは、自社データを推論に活かしたいというビジネスニーズが強く、他の手法も完全ではないからだ。
NotebookLMが爆発的に普及したのは、RAGの面倒な作業を裏側に隠しながら、「自社データに基づく正確な回答」と「ソースグラウンディング」という本質的な価値を提供したからだろう。
現時点での結論は「RAGは不要とは言えない。ユースケースに合わせて適材適所で使い分ける」ということになろう。ただし、Agentic Searchやロングコンテキストの進化は速く、数年後には状況が大きく変わっている可能性もある。引き続き注目しておきたい分野だ。
↑ 目次に戻る