Claude Desktopは、RAGを使っていない ── 「ファイル検索だけで十分」という新常識

はじめに：RAGは本当に必要なのか？

2023年から2024年にかけて、AI活用の現場では**RAG（Retrieval-Augmented Generation）**が「必須技術」として語られてきました。社内ドキュメントをベクトル化し、類似検索でLLMに渡す──この仕組みは、AI導入の定番パターンとして広く浸透しています。

しかし2025年、AI業界に衝撃が走りました。Anthropic社のClaude Codeの開発責任者であるBoris Cherny氏が、こう明かしたのです。

初期のClaude Codeでは、RAGとローカルベクトルDBを使っていた。しかし、すぐにAgentic Searchのほうが圧倒的に優れていることがわかった。

Claude Desktop（Cowork）も、この思想をそのまま受け継いでいます。ベクトルDB不要、エンベディング不要。使うのは、grep（テキスト検索）とglob（ファイル名検索）という、昔からある「ファイル検索」だけ。それだけで十分だ、というのがAnthropicの結論です。

この記事では、PM・ビジネス層の方に向けて、Claude Desktopがなぜこのアプローチを選んだのか、そしてそれが意味する「RAG不要論」について解説します。

RAGとは何か？（30秒でわかるおさらい）

RAGは、ざっくり言うと「AIが回答する前に、関連する社内資料を自動で探してきて参考にする仕組み」です。技術的には、以下のステップで動いています。

事前準備：社内文書を細かく分割し、AIが理解しやすい数値（ベクトル）に変換して、専用データベースに格納する
検索：ユーザーの質問を同じようにベクトル化し、「意味的に近い」文書を探す
生成：見つかった文書をLLMに渡して、回答を生成させる

一見合理的ですが、導入・運用には多くの課題が伴います。チャンキング（文書の分割方法）の設計、ベクトルDBの構築・管理、検索精度のチューニング、データの鮮度管理──実際にやってみると、想像以上に手間とコストがかかるのが現実です。

Claude Desktopの選択：「AIが自分で探せばいい」

Claude Desktop（Cowork）は、RAGとはまったく異なるアプローチを採用しています。その名もAgentic Search（エージェンティック・サーチ）。

考え方はシンプルです。「AIに検索ツールを渡して、AI自身にファイルを探させればいい」。具体的には、Claude Desktopは以下のような基本ツールだけで情報を探します。

Grep：ファイルの中身をテキスト検索する（ripgrepベース）
Glob：ファイル名のパターンで探す（例：*.pdf、src/**/*.ts）
Read：見つけたファイルを読む

これは、エンジニアがターミナルでコードを探すときの行動そのものです。特別なインフラやデータベースは一切不要。LLMの「コードや文書の構造を理解する力」を活かして、何度も検索を繰り返しながら必要な情報にたどり着きます。

なぜRAGより優れているのか？── 5つの理由

1. インフラが要らない

RAGを導入するには、ベクトルDB、エンベディングモデル、インデックスパイプラインなど、複数のシステムを構築・維持する必要があります。Agentic Searchでは、ファイルシステムとテキスト検索ツールさえあれば動きます。導入のハードルが圧倒的に低いのです。

2. 常に最新データを参照できる

RAGでは、文書が更新されるたびにベクトルインデックスの再構築が必要です。これを怠ると「古い情報を参照して回答する」という深刻な問題が生じます。Agentic Searchは常にファイルの「今の中身」を直接読むので、鮮度の問題が構造的に発生しません。

3. セキュリティとプライバシーの確保

RAGではベクトルインデックスをどこかに保存する必要があり、クラウドに置けば情報漏洩のリスクが生じます。Agentic Searchではデータがマシンの外に出ず、ユーザーのファイルシステム上で直接検索するため、プライバシーが守られます。Boris Cherny氏自身も「データがマシンから出ない」ことを大きなメリットとして挙げています。

4. 検索プロセスが透明

RAGの検索は、ベクトルの類似度計算というブラックボックスです。「なぜこの文書が選ばれたのか」を人間が確認するのは困難です。一方、Agentic Searchでは「どのキーワードで検索し、どのファイルを読んだか」がすべて可視化されます。監査やデバッグが容易で、ビジネスの現場で求められる説明責任を果たしやすい仕組みです。

5. モデルの進化とともに賢くなる

ここが最も重要なポイントかもしれません。Boris Cherny氏はこう述べています。「結局、すべてはモデルだ。モデルが良くなれば、それが他のすべてを包含する」。RAGのパイプラインは、モデルが進化しても基本的に変わりません。しかしAgentic Searchは、LLMの推論能力が上がれば検索戦略も自動的に改善されます。投資が陳腐化しにくい設計です。

公平な視点：Agentic Searchの弱点も知っておく

もちろん、万能ではありません。

トークンコストがRAGより高くなりがちです。RAGは一度の検索で関連文書を取得しますが、Agentic Searchはファイルを何度も検索・読み込むため、API利用料が増える傾向があります。ある試算では、RAGの1クエリあたりのコストが約0.00008ドルに対し、ロングコンテキスト方式は約0.10ドルと、大きな差があります。

また、概念的な検索が苦手です。「認証処理はどこで行われているか？」のような抽象的な質問では、grepのキーワード検索だけでは目的のコードや文書にたどり着きにくいケースがあります。

ただし、これらの弱点はモデルの進化とともに緩和されつつあります。Cognition社の研究では、並列ツール呼び出しを活用することで、Agentic Searchの速度を4倍に改善できることが示されています。

ビジネスへの示唆：AI導入戦略を見直すタイミング

この「RAG不要論」は、AI導入を検討しているPMやビジネスリーダーにとって重要な意味を持ちます。

RAG構築に多額の投資をする前に、まずAgentic Searchで十分かどうかを検証すべきです。Claude Desktopのように、既存のファイルシステムとテキスト検索だけでかなりの業務が回る可能性があります。

特に以下のようなケースでは、RAGは過剰投資になりかねません。

社内ドキュメントの量がそこまで膨大でない場合
対象文書が頻繁に更新される場合
セキュリティ要件が厳しい場合
小さく始めて素早く検証したい場合

一方、数十万件の文書から意味的に関連するものを瞬時に引き出す必要がある場合や、コスト最適化が最優先の大規模運用では、RAGが依然として有効な選択肢です。

おわりに：シンプルさが勝つ時代

Claude Desktopの設計思想は明快です。「複雑なパイプラインを組むより、賢いモデルにシンプルなツールを渡せ」。

2026年現在、LLMの能力は日進月歩で向上しています。検索の精度も、推論の深さも、コンテキストの理解力も。その進化の恩恵を最大限に受けるのは、複雑なインフラに依存するRAGではなく、モデルの力をそのまま活かすAgentic Searchなのかもしれません。

もちろん、「すべてのRAGが不要」と言いたいわけではありません。ただ、Claude Desktopが証明しているのは、「RAGなしでもここまでできる」という事実です。AI導入の第一歩として、まずはシンプルに始めてみる。その価値を、改めて考えてみてはいかがでしょうか。