{
  "issue": "2026-09-17",
  "generated_at": "2026-09-17T07:00:00+09:00",
  "theme": {
    "title": "コード検索の設計が三方向に割れた — ベクトルDBを捨てる陣営、極める陣営、置き換える陣営",
    "category": "agentic-search",
    "lede": "「RAGはハイブリッド検索+リランカーが正解」という結論は一般的な文書検索では固まりつつあるが、コーディングエージェントの世界では事情が違う。Claude Code はベクトルインデックスを完全に捨てて grep/glob による反復探索に切り替え、Cursor と GitHub Copilot は逆に埋め込みの構築効率を磨き込み、Sourcegraph は検索そのものを静的解析に置き換える道を選んだ。同じ「コードを探す」という課題に、3社が3通りの答えを出している。",
    "tldr": [
      "Claude Code は埋め込みベースのRAGを捨て、grep/globの反復探索に完全移行——再インデックスの陳腐化とコードアップロードのセキュリティリスクを避けるため。",
      "Cursor と GitHub Copilot は埋め込みを維持しつつ、Merkle木による差分再索引や新埋め込みモデルで構築・更新コストを下げる方向に投資している。",
      "Sourcegraph は「答えが一意に決まるクエリ」を静的解析（SCIP）による確定的ルックアップに逃し、曖昧なクエリだけを検索に残す設計で精度を底上げした。"
    ],
    "sections": [
      {
        "heading": "Claude Code はなぜベクトル検索をやめたのか",
        "body_html": "<p>Claude Code の「エージェント検索」は、事前にコードベース全体をベクトル化してインデックスを作る代わりに、<code>grep</code> と <code>glob</code> による反復探索をエージェント自身に実行させる方式だ。クエリのたびにファイルを絞り込み、読み、必要なら検索語を変えて再検索する——人間のエンジニアがコードを探すのと同じ手順をツール呼び出しの連鎖として再現する。</p><p>Anthropicは当初、埋め込みベースのRAGパイプラインをClaude Codeに組み込んでいたが、後にエージェント検索へ完全に置き換えた。理由は精度だけでなく運用コストにある。ベクトルインデックスはコード変更のたびに再構築が必要で、ローカルの未コミット変更とはすぐにズレる。さらに社外のベクトルDBへコードをアップロードすること自体がセキュリティ上のリスクになる。エージェント検索はレイテンシとトークン消費の増加を引き受ける代わりに、この2つの負債を丸ごと回避した。</p>",
        "examples": [
          {
            "product": "Claude Code（Anthropic）",
            "approach": "grep/glob による反復探索でベクトルDBを完全代替",
            "detail": "創業エンジニアのBoris Cherny はLatent Space のインタビューで、社内評価においてエージェント検索が「あらゆる面で圧倒的に(RAGを)上回った」と証言。埋め込みの再インデックス負債とコードアップロードのセキュリティリスクを避けるトレードオフとして、レイテンシとトークン消費の増加を受け入れたと説明している。",
            "source_url": "https://www.latent.space/p/claude-code"
          }
        ],
        "takeaway": "コードベースが頻繁に変わる、または社外へのアップロードを避けたい場合は、精度より鮮度とセキュリティを優先してエージェント検索を検討する価値がある。ただしレイテンシとトークンコストの増加は事前に計測しておくこと。"
      },
      {
        "heading": "埋め込みを手放さない陣営 — Cursor と GitHub Copilot は索引の構築効率に投資する",
        "body_html": "<p>一方でCursorとGitHub Copilotは埋め込みベースの検索を手放していない。むしろ索引の構築・更新コストを下げる方向に工数を投じている。Cursorはファイルツリーをハッシュ差分で管理し、変更があったブランチだけを再索引する。新規メンバーが参加した際は、その人のコードベースと類似度の高い既存インデックスを組織内で探して再利用し、初回検索までの待ち時間を数秒からミリ秒単位に縮めた。GitHub Copilotも新しい埋め込みモデルを投入し、検索精度を約38%引き上げつつインデックスサイズを8分の1に圧縮している。</p><p>この2社が埋め込みを維持する理由は、Claude Codeとは前提が違うからだ。IDEに常駐して多数のユーザーが同じリポジトリに繰り返しアクセスする製品では、索引コストを一度払えば以後のクエリで償却できる。エージェント検索のように毎回ファイルシステムを探索するコストは、多人数・高頻度アクセスの場では割に合わない。</p>",
        "examples": [
          {
            "product": "Cursor",
            "approach": "差分ハッシュによる部分再索引と組織内インデックス再利用でオンボーディングを高速化",
            "detail": "ファイル変更をMerkle木のハッシュ差分で検出し、変更されたブランチだけを再索引する。新規参加者には組織内の類似コードベースの既存indexを再利用し、初回検索までの時間を7.87秒から525ミリ秒に短縮したと公式ブログで報告している。",
            "source_url": "https://cursor.com/blog/secure-codebase-indexing"
          },
          {
            "product": "GitHub Copilot",
            "approach": "新しい埋め込みモデルで検索精度と索引効率を同時に改善",
            "detail": "VS Code向けに投入した新埋め込みモデルで検索品質を37.6%向上、スループットを約2倍、インデックスサイズを8分の1に圧縮したと公式ブログで報告。C#開発者のコード採用率は+110.7%だったという。",
            "source_url": "https://github.blog/news-insights/product-news/copilot-new-embedding-model-vs-code/"
          }
        ],
        "takeaway": "同一リポジトリに多数のユーザーが繰り返しアクセスする製品では、索引コストは償却できる投資になる。索引の鮮度そのものより、索引構築の効率化（差分更新・共有再利用）に工数を割く方が費用対効果が高い。"
      },
      {
        "heading": "中間解 — Sourcegraph は『検索』の一部を確定的なコード解析に置き換える",
        "body_html": "<p>SourcegraphのMCPサーバーは、キーワード検索とベクトル検索に加えて、SCIPという静的解析ベースのコードインデックスを使う13種類のツールをエージェントに公開する。シンボルの定義元や参照元を尋ねるクエリには、テキスト類似度に基づく確率的な検索ではなく、コンパイラ相当の精度を持つ確定的なルックアップで答える。</p><p>この使い分けが効くのは、クエリの種類によって「正解が一意に決まるか」が違うからだ。「この関数はどこで定義されているか」への答えは1つしかなく、検索より静的解析の方が向いている。Sourcegraph自身のベンチマークでは、MCPサーバー経由でのファイル再現率が0.127から0.277まで改善し、grepベースのベースラインではタイムアウトしていたタスクが制限時間内に完了する例もあったという。</p>",
        "examples": [
          {
            "product": "Sourcegraph（Amp / MCP server）",
            "approach": "SCIPベースの確定的コード解析をキーワード/セマンティック検索と併用",
            "detail": "MCPサーバーが13種類のツールを公開し、シンボルの定義・参照解決はSCIPインデックスによる確定的ルックアップで返す。CodeScaleBenchでファイル再現率が0.127から0.277に改善したと公式ブログで報告している。",
            "source_url": "https://sourcegraph.com/blog/context-engineering"
          }
        ],
        "takeaway": "検索精度を上げたいなら、まず『このクエリは一意の正解を持つか』を仕分けるとよい。一意に決まるクエリ（定義・参照・依存関係）は検索ではなく静的解析やAPI呼び出しに載せ替え、曖昧な自然言語クエリだけをキーワード/ベクトル検索に残すと、両方の精度が上がる。"
      }
    ]
  },
  "editorial": "RAGの標準装備として語られてきた「ハイブリッド検索+リランカー」は依然として有効だが、コーディングエージェントの世界ではそれが唯一の正解ではなくなった。Claude Codeはコストとセキュリティを理由に検索そのものを放棄し、CursorとCopilotは索引の償却コストが合う前提で埋め込みを磨き、Sourcegraphは「検索が要らないクエリ」を静的解析に逃がした。問われているのは「RAGを使うか」ではなく、自分のプロダクトがどの前提——鮮度、多人数償却、クエリの一意性——の上に成り立っているかだ。",
  "quick_picks": [
    {
      "title": "Claude Codeチームが語る、ベクトル検索を捨てた本音",
      "summary": "Every.toのインタビューでCat WuとThariqが、埋め込みの再インデックス負債とセキュリティリスクを理由にエージェント検索へ移行した経緯を語る。本文で扱ったClaude Codeの意思決定の一次証言にあたる。",
      "url": "https://every.to/podcast/how-to-use-claude-code-like-the-people-who-built-it"
    },
    {
      "title": "Anthropic公式：『必要になるまで読み込まない』コンテキスト設計",
      "summary": "Anthropicのエンジニアリングブログが提唱するjust-in-time context loadingは、事前に全データを処理せずファイルパスなどの軽量な参照だけを保持し実行時に取得する設計思想。本文のエージェント検索がなぜ有効かを裏付ける原則になっている。",
      "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents"
    },
    {
      "title": "パターンカタログ：ベクトル埋め込みの代わりにエージェント検索を使う",
      "summary": "コミュニティ主導のエージェント設計パターン集が「Agentic Search Over Vector Embeddings」を独立したパターンとして整理している。本文3社の実装がこのパターンのどの変種にあたるかを比較する際の参考になる。",
      "url": "https://www.agentic-patterns.com/patterns/agentic-search-over-vector-embeddings/"
    }
  ]
}
