企業がAIを活用したシステムを導入・検討する際、「社内の情報をAIにどう探させるか」 は避けて通れないテーマです。
最近AIコーディングツール「Claude Code」の開発者Boris Cherny氏が、従来の主流手法「RAG」をやめて「エージェンティック検索」を採用したと公表し、業界で大きな議論になりました。
AIモデル（ChatGPTやClaude,Geminiなど）は、学習済みの知識しか持っていません。自社の売上データや社内マニュアルの内容は知りません。
そこで必要になるのが、「外部の情報をAIに渡す仕組み」 です。この仕組みの作り方に、大きく2つのアプローチがあります。
RAG（Retrieval Augmented Generation）とは
一言でいうと
「事前にカタログを作っておき、質問が来たら該当ページを引いてAIに渡す」方式です。
仕組み（3ステップ）
① 事前準備：文書をAIが扱える数値データ（ベクトル）に変換し、専用DB（ベクターDB）に格納
② 質問受付：ユーザーの質問も同じ方法でベクトル化
③ 検索＋回答：質問に「意味が近い」文書をDBから取り出し、AIに渡して回答を生成たとえるなら
図書館に蔵書目録（カタログ）を先に作っておく。利用者が質問したら、司書がカタログを引いて関連する本を見つけ、その内容をもとに回答する。
メリット
- 意味で探せる： 「シニア層」と「高齢者」のように、言葉が違っても意味が近ければヒットする
- 大量データ対応： 数万〜数百万件の文書でも高速に検索できる
- トークン節約： 必要な部分だけAIに渡すので、処理コストを抑えられる
デメリット
- 事前構築が必要： カタログ（インデックス）を作る手間がかかる
- 同期の問題： 元データが更新されても、カタログが古いままだと間違った情報を返す
- セキュリティリスク： カタログの保存先が攻撃されると、社内情報が漏洩する可能性がある
- チャンキングの難しさ： 文書をどう分割するかで検索精度が大きく変わる
💡 用語メモ
- ベクトル： テキストを数百個の数値の並びに変換したもの。「意味の座標」のようなイメージ
- ベクターDB： ベクトルを格納・高速検索する専用データベース（Milvus、Pineconeなど）
- トークン： AIが処理するテキストの最小単位。日本語では1文字≒1〜2トークン程度。処理量＝コストに直結
エージェンティック検索とは
一言でいうと
「カタログは作らず、AI自身が検索ツールを使って必要な情報を探し回る」方式。
仕組み
① AIが質問の意図を理解する
② AIが自分でgrep（テキスト検索）やglob（ファイル名検索）などのツールを実行
③ 結果を見て、足りなければ検索条件を変えて再検索
④ 十分な情報が集まったら回答を生成たとえるなら
蔵書目録を作らず、優秀な司書が自分で書棚を歩き回り、本を手に取って中身を確認しながら情報を集める。
メリット
- 事前準備不要： インデックス構築の手間がゼロ
- 常に最新： ファイルが追加・変更されても即座に検索対象になる
- セキュリティがシンプル： コードや文書のコピーを外部に保存しない
- セットアップが簡単： 追加のインフラ（ベクターDB等）が不要
デメリット
- トークン消費が多い： 検索のたびにAIが処理するため、コストがかさむ
- 表記揺れに弱い： 「シニア」と「高齢者」のような意味の一致は見つけにくい
- 大規模データでは非効率： 数万件の文書すべてをAIに探させるのは現実的でない場合がある
- モデル性能に依存： AI自身の能力が低いと、適切な検索ができない
💡 用語メモ
- grep： ファイルの中身からキーワードを検索するツール。Ctrl+Fの高機能版
- glob： ファイル名のパターンで検索するツール（例：「*.pdf」で全PDFを探す）
4. Claude Codeで何が起きたのか
経緯
Claude Codeの開発チームは当初、RAG（Voyage社のembeddingsモデル＋ベクターDB）を採用していました。しかし比較検証の結果、エージェンティック検索に切り替えました。
開発者Boris Cherny氏の発言（要旨）
| 論点 | 発言内容 |
|---|---|
| 性能差 | 「エージェンティック検索が他のすべてを大幅に上回った」 |
| 評価方法 | 「主にvibes（感覚）で判断した。内部ベンチマークもあるが、体感が良かった」 |
| 運用面 | 「インデックスの同期問題やセキュリティリスクがなくなった」 |
| トレードオフ | 「レイテンシとトークンコストと引き換えに、優れた検索とセキュリティを得た」 |
なぜコードベースで成功したのか
プログラミングのコードには以下の特徴があり、エージェンティック検索と相性が良いためです。
- ファイル名・関数名に意味のある命名規則がある（例：
calculateTax） - フォルダ構造が論理的に整理されている
- 特定のキーワードで一致検索すれば目的の情報にたどり着ける
反論：ベクターDB陣営の指摘
Milvus（ベクターDB開発元）は反論記事を公開し、「grep（ファイルの中身からキーワードを検索する）の繰り返しはトークンを浪費しすぎる。RAGなら40%削減できる」と主張しました。
ただし、Claude Codeはローンチから6カ月で年間売上ランレート10億ドルに到達しており、トークンコストよりも精度とUXをユーザーが評価した結果とも読み取れます。
⚠️ MilvusはベクターDBの販売元であり、RAG不要論は自社ビジネスに直接影響するため、利害関係のある立場からの反論です。
コード以外の領域ではどうか ― 小売業務への示唆
Claude Codeの成功事例はコードベース検索に特化した話です。小売の業務では、データの性質が異なるため、そのまま当てはめることはできません。
検索対象による向き・不向き
| データの特徴 | 向いている方式 | 小売での具体例 |
|---|---|---|
| キーワードが明確 | エージェンティック検索 | 商品コード検索、特定店舗名の抽出 |
| 意味・文脈の理解が必要 | RAG | 「顧客体験改善の事例」「シニア向け売場の工夫」 |
| 表記揺れが多い | RAG | 「高齢者」「シニア」「シルバー」の横断検索 |
| 構造化されたデータ | SQL・キーワード検索 | POS分析、棚割データ、商品マスタ |
| 複数形式が混在 | ハイブリッド | 議事録＋売上データ＋顧客アンケートの横断分析 |
実務での使い分けガイド
エージェンティック検索が有効な場面
- 対象データが少量（数十〜数百ファイル程度）
- ファイルの構造・命名が整理されている
- 固有名詞や型番など、一致検索で見つかるものを探す
- セットアップのスピードが最優先
RAGが有効な場面
- 大量の非構造化データ（調査レポート、議事録、顧客の声）
- 「意味が近い」情報を横断的に探したい
- 表記揺れが多い日本語テキスト
- 安定したコスト管理が求められる
ハイブリッド（併用）が現実的な場面
- 上記の両方が混在する業務環境（実務ではこのケースが最も多い）
設計判断として学べること
「定番＝最適解」とは限らない
RAGはAI活用の「正解」のように語られてきました。しかしClaude Codeチームは実験の結果、よりシンプルな方法を選びました。重要なのは「定番を疑い、自分のユースケースで検証する」 という姿勢です。
シンプルさの価値
インデックス構築、同期管理、セキュリティ対策……RAGにはそれぞれ運用コストがかかります。「複雑なシステムより、シンプルで精度が高い方が勝つ」というのがClaude Codeの教訓です。
モデル進化による前提の変化
エージェンティック検索が機能するのは、AIモデル自身が十分に賢くなったからです。今後モデルの性能がさらに向上すれば、事前のインデックス構築なしでも高精度な検索が可能になる領域は広がるかもしれません。
実践への第一歩
自社でAI活用を検討する際、いきなりRAGの構築に着手するのではなく、まず以下を確認する価値があります。
- 対象データはどの程度の量か
- キーワード検索で目的の情報にたどり着けるか
- 「意味の近さ」で探す必要がどの程度あるか
この3点で、どのアプローチが適切かの見当がつきます。
用語集
| 用語 | 説明 |
|---|---|
| RAG | Retrieval Augmented Generation。事前に作った索引から関連情報を取り出してAIに渡す仕組み |
| エージェンティック検索 | AIモデル自身が検索ツールを使い、自律的に情報を探すアプローチ |
| ベクトル（embedding） | テキストを数値の並びに変換したもの。意味が近い文書は数値も近くなる |
| ベクターDB | ベクトルデータを格納し、類似検索を高速に行う専用データベース |
| トークン | AIが処理するテキストの最小単位。処理量＝利用コストに直結 |
| grep | ファイル内のテキストをキーワードで検索するツール |
| glob | ファイル名をパターンで検索するツール |
| インデックス | 検索を高速化するために事前に構築する索引データ |
| チャンキング | 長い文書を検索しやすいサイズに分割する処理 |
出典
- Anthropic “Anthropic acquires Bun as Claude Code reaches $1B milestone” 2025年12月（一次）
- Boris Cherny氏 X投稿（2026年1月）およびインタビュー発言（OfficeChai 2025年5月に記録、二次）
- Milvus Blog “Why I’m Against Claude Code’s Grep-Only Retrieval” 2025年8月（利害関係者による反論）
- Alberto Roura “Vector RAG? Agentic Search? Why Not Both?”（個人ブログ・二次）
