作成日: 2026年11月9日

更新日: 2026年11月9日

検索エンジン不要のRAG「DecisionRAG」とは？階層探索の数理と1日13ドル時代の節約術

📂 検証録 #AI開発 #SQLite #Rust #Antigravity #Gemini

論旨

AI に社内資料や大量の記事・コードベースを正確に参照させようとしたとき、「まず全文を細かく刻んでベクトルデータベース（Embedding API）に入れ、類似度検索してから再順位付け（Rerank）する」という従来の RAG（検索拡張生成）の定石に行き詰まりを感じていませんか。一方で、コーディングエージェントに毎回ファイルを丸読みさせれば、Anthropic 公式コスト統計が示す通り開発者 1 人あたり 稼働 1 日平均約 13 米ドル（月額 150〜250 米ドル） ものトークン代や利用枠（クオータ）があっという間に溶けていきます。

そんな中、コーネル大学と ASAPP の研究チームが発表した最新論文 『DecisionRAG（Retriever-Free Retrieval）』（arXiv:2610.35868）が、「そもそも初段のベクトル検索機すら不要であり、人間が図書館の本棚から目次を辿るように 階層構造を 1 パス確率評価でナビゲート させた方が圧倒的に正確で速い」ことを実証しました。結論からお伝えすると、大量の文書をフラットなベクトル空間へ丸投げするのをやめ、「大分類→要約カード→見出し行番号→該当行のみ読込」という階層ナビゲーション構造と、常時読込ルールを最小限に絞る節約設計 を手元の PC 基盤に組むことが、精度向上とトークン激減を両立する最適解です。

合わせて読みたい深まる関連情報

Astro・TS・Rustコード丸読みの罠｜SQLite階層索引で読込98%減の実測録 : DecisionRAGの階層ナビ設計を.astro・.ts・.rs全コードと下書き.mdへ拡張し、3ミリ秒台で読込98%削減を実現した実装録です。
AIトークン年3000万円破産とベクトルDB不要論｜BM25・事前整理で消費91%減 : 有料のクラウド型ベクトルDBを使わず、事前の構造化整理とローカルSQLite検索で読込トークンを最大91%削減した先行論文と実装を解説しています。
GEMINI.md・AGENTS.mdが長いと無視される原因｜24KB壁・2万トークン予算と分割送信廃止術 : ルール定義書が長くなると後半が無視されるエディタ上限を突破し、常時コアのみ注入して残りをローカル検索へ切り出した実測録です。
AIのランダム検索では見抜けない長編ブログの罠｜372記事・297万字を順番通読した実測録 : 断片的なチャンク検索だけでは文脈の前後矛盾を見落とす理由と、章立て階層に沿った監査手順の重要性を検証しています。
AI導入で目視確認が増える原因｜2エージェント隔離検証とPure Rust自動化で暇になる設計 : 定型チェックをローカルのPure Rustゲートへ切り出し、AIの推論トークンと人間の目視負担を同時に減らす分業設計を解説しています。
GEMINI.mdが500KBで勝手に切れる罠｜VS Code差分上限の真因とRust防衛録 : 大規模ルール定義や知識ベースを欠損させずに階層管理・自動同期するローカルRust防衛設計をまとめています。
防災無線6,686台放置と車載「偽基地局」の衝撃｜1時間衛星監査と1ミリ秒遮断 : 外部ベクトルDBに頼らない『DecisionRAG』型の階層法令ナビゲーションを、行政予算の事前審査基盤へ応用する制度設計を論考しています。

対象となる方

従来の RAG（チャンク分割＋ベクトル類似度検索）で 「肝心な前提条件や別章の例外規定を取りこぼす」 と悩んでいるエンジニア・個人開発者の方
Claude Code や Gemini などの AI エージェント運用で、1 日あたりのトークン消費や週間クオータの減りを半分以下に抑える具体策 を知りたい方
数百本の記事や大規模ドキュメントを、追加の API 課金ゼロでミリ秒単位に辿らせるローカル階層索引の作り方 を把握したい方

結論：ベクトルDB丸投げより階層ナビゲーションが速い理由

まずは「従来のベクトル検索型 RAG」「エージェントによる全文 grep 丸読み」「DecisionRAG 型の階層ナビゲーション」の 3 つのアプローチを比較表で整理します。

比較軸	従来のベクトル検索 RAG	全文 grep・ファイル丸読み	DecisionRAG 型の階層探索
探索の仕組み	文書を細切れにして埋め込み類似度で上位抽出	思いつく単語で検索しヒットしたファイルを全文読込	階層ツリー（棚→章→節→段落）を上流から順番に絞り込む
文脈の取りこぼし	専門用語や指示語（「同条」「上記」）で検索漏れが多発	網羅性は高いが無関係な記述でコンテキストが溢れる	共有文脈で候補同士を見比べながら辿るため取りこぼし極小
構築・維持コスト	Embedding API 課金と文書更新ごとの再インデックス負荷	事前準備は不要だが毎ターンの API 従量課金が爆発	見出し・要約の木構造だけで動きベクトル DB 保守が不要
応答速度・燃費	検索＋Reranker の多段構成で複雑化しやすい	ファイル数に比例して遅延とキャッシュ破棄が増大	Wikipedia 268 万段落から 0.7〜1.8 秒でピンポイント到達

人間が分厚い技術書や六法全書で調べ物をするときも、いきなりページをバラバラにちぎって似た単語を探すんじゃなくて、まず「目次」を見て「第3章」を開いて「第2節」を読むじゃろ。なんで今まで AI にはそれをさせんかったんかね？

まさにそこがコーネル大学の研究チームが突いた急所なんです！これまで「AI に目次を辿らせると、毎ステップ文章を生成して考えるから遅すぎる」と思われていたのですが、文字を 1 文字も生成せずに「1 回の確率計算」だけで枝を選ばせることで、検索エンジン並みの速さを実現してしまったんですよ。

検索機を捨てた『DecisionRAG』の仕組みと実証数値

原著論文『Retriever-Free Retrieval: Navigating Documents with Decision Models』および技術解説記事をもとに、なぜ「検索機（Retriever）を捨てる」ことでかえって検索精度が跳ね上がったのかを紐解きます。

従来のRAGが抱える「能力の非対称性」という構造欠陥

一般的な 2 段階 RAG パイプラインは、第 1 段階の「軽量な検索機（BM25 や密ベクトル Embedding）」で数百万件から数十件の候補を拾い、第 2 段階の「賢い再順位付けモデル（Reranker）や大規模言語モデル」で最終回答を作ります。

しかし論文が指摘する通り、ここには 「能力の非対称性（Capability Asymmetry）」 という致命的なボトルネックがあります。最終段にどれほど推論力の高い最先端モデルを置いても、入口の単純なベクトル類似度計算が「質問文と単語の表面は似ていないが、論理的に決定的な根拠となる段落」を上位候補から落としてしまえば、後段の賢い AI は二度とその情報を見ることができません。

トークン生成ゼロの1パス評価で268万段落を辿る数理

そこで『DecisionRAG』は、文書集合をあらかじめ階層ツリー（ルート → トピック群 → 文書要約 → 個別パッセージ）として構造化し、3B〜8B クラスの軽量な意思決定モデル（Decision Model）に上から下へと枝を選択させます。

このとき従来のエージェント検索のように「どの章を読むべきか理由を述べて選ばせる（自己回帰トークン生成）」のではなく、同じ階層の候補ノード群 $\{c_1, c_2, \dots, c_m\}$ を 1 つのプロンプト内に並べて同時に入力（共有文脈比較：Shared-Context Comparison）し、たった 1 回の順伝播（Single Forward Pass）が出力する選択ロジットから上位 $k$ 個の枝を即座に確定 します。

S_{\text{next}} = \operatorname{Top-}k_{c_i \in \mathcal{C}(u)} \, P_{\theta}\!\left(c_i \mid q, \mathcal{C}(u)\right)

ここで $q$ は質問文、 $\mathcal{C}(u)$ は現在の階層ノード $u$ の子候補集合です。出力トークンを 1 文字もダラダラ生成しないため計算量が劇的に小さく、論文のベンチマークでは以下の驚くべき実証結果が報告されています。

📊 DecisionRAG（arXiv:2610.35868）が実証した主要ベンチマーク結果

Wikipedia 約 268 万パッセージからの探索速度 : 外部のベクトルインデックスや BM25 検索機を一切使わず、1 クエリあたりわずか 0.7〜1.8 秒 で目的の根拠段落へ到達しています。
単一文書・オープンドメイン QA での大幅な精度逆転 : 強力な密ベクトル検索＋8B Reranker の組み合わせと比較して、オープンドメイン質問応答 Natural Questions で Hit@1 が +17.4 ポイント向上 し、文脈依存の強い対話型検索 MultiDoc2Dial でも R@1 が +13.8 ポイント向上 しました。
候補同士を横並びで見比べる強み : ベクトル検索が各チャンクを「孤立した点」として採点するのに対し、DecisionRAG は同じ階層にある複数の章・節を同一コンテキスト内で相対比較するため、「一見似ているが条件が違う紛らわしい章」を正確にふるい落とせます。

DecisionRAGが268万段落から正解へ辿り着く3段階ナビゲーション

Step 1

大分類・章の比較

質問文と大分類リストを同時に入力し、トークン生成ゼロの1回計算で有望な領域だけを残します。

Step 2

文書要約・節の選択

残った枝の要約・見出し群を共有文脈で横並び比較し、前提条件が合致する節へ降りていきます。

Step 3

根拠段落のみ抽出

最終的に選ばれた数段落だけを回答用AIへ渡すため、読込トークンとノイズが極限まで減ります。

全文を細切れベクトルにするのではなく、目次の木構造を1パス確率評価で高速に降りていきます。

平均1日13米ドル時代のAI節約7習慣と階層索引の実装

この「階層を辿らせて必要な箇所だけを読む」という原理は、専用の Decision Model を自前で追加学習しなくても、普段私たちが使っている Claude Code や Antigravity、Cursor などの AI エージェント開発環境にそのまま応用できます。

公式統計が示す1日13米ドルの壁と指示書半減の7習慣

Anthropic 公式のコスト管理ドキュメントによると、Claude Code を利用する開発者の平均コストは 稼働 1 日あたり約 13 米ドル（1 ヶ月あたり約 150〜250 米ドル相当、利用者の 90% は日額 30 米ドル未満） と公表されています。1 日 13 米ドルといえば日本円で毎日約 2,000 円前後であり、何も対策せずに巨大なルールファイルや長大なソースコードを毎ターン丸読みさせていれば、定額プランの 5 時間枠・週間枠も API 残高もあっという間に吹き飛びます。

コミュニティで検証が進んでいるトークン節約の 7 習慣と公式推奨プラクティスを、先ほどの階層ナビゲーションの視点で整理すると、やるべき対策は驚くほど一貫しています。

💡 指示書と読込トークンを半減させる実践7習慣の要点

常時注入ファイル（CLAUDE.md / GEMINI.md）を半分以下にダイエットする : 毎ターン無条件で送信されるルート指示書には「絶対に毎回守る最上位原則」だけを書き、特定の作業でしか使わない詳細仕様は別ファイルやローカル DB の索引へ分離します。
ファイル丸読みの前に「階層目次（アウトライン）」を引かせる : いきなり数千行のファイルを cat や全文 Read させるのではなく、見出し一覧と行番号マップを先に取得させ、該当する数十行だけをピンポイントで読ませます。
曖昧な全文 grep 連打をやめ、要約カード索引を第 1 階層に置く : 各ファイルや記事のタイトル・100 字要約・タグ・関連リンクだけをまとめた軽量インデックスを用意し、DecisionRAG の第 1〜第 2 階層と同じく「どのファイルを開くべきか」を一発で特定させます。
無闇な /clear 連打でプロンプトキャッシュを壊さない : 同じ作業の途中で細かく履歴を消すと、せっかく 90% 割引（または高速再利用）されていたキャッシュが破棄され、再度ファイルを一から読み直す二重課金が発生します。履歴のリセットは明確に別テーマへ移るときだけに限定します。
大量ファイルの横断調査はサブエージェントへ隔離する : 親チャットのコンテキストに 10 個も 20 個も検索結果を積み上げると以降の全ターンが重くなるため、調査専用のサブエージェントに探索させて「結論の要約数行」だけを親へ返させます。
文字数・構文・リンク検査を AI にやらせずローカル CLI へ切り出す : 決定論的に判定できるチェックは Rust やスクリプトの Hook（数ミリ秒）で機械処理し、AI の推論トークンを 1 トークンも使わせないようにします。
曖昧な一言指示を避け、対象スコープと完了条件を最初に渡す : AI が「どこを直せばいいか」を探し回る無駄な探索ターン自体をゼロにします。

当ラボが実践する3段階階層探索と64GB母艦の費用対効果

実際、当ラボでも公開記事が 706記事、単一マスターの設計ルール書（GEMINI.md）が 1,310行（約543KB）まで拡大しましたが、クラウド側のベクトル DB は 1 つも契約していません。

その代わりに、①毎ターン常時注入するコア原則は 4本（2 万トークン予算内）だけに絞り、②記事や公理を探すときはローカル SQLite の要約カード（card）で対象ファイルを特定し、③Pure Rust 製ツールの --outline で見出し・表・コンポーネントの正確な行番号マップを取得してから必要な行範囲だけを読むという「ローカル版・階層ナビゲーション」を徹底しています。これにより、記事数が数百本を超えても AI が読むテキスト量は常に数キロバイトで済み、週間クオータの消費を数パーセント台に抑え込めています。

（なお、本記事公開直後の点検で判明した「毎日いちばん開く管理文書・TODO 進捗表・整合性マップ計約 886KB がベタ 1 行格納のまま残っていた盲点」を SQLite 階層木へ分解し、読込量を最大約 99% 削減した続編の実測データは『CLAUDE.md・GEMINI.md・TODO丸読みの罠｜SQLite階層目次で読込99%減の実測録』で公開しています）。

毎月クラウドのベクトル DB 代や追加の API トークン代で何万円も払い続けるくらいなら、手元の Mac をしっかり整えてローカルで階層インデックスを爆速回転させた方が、よっぽど財布にも優しいわい。

本当にその通りです！ローカル SQLite と Rust バイナリ、RAMDisk キャッシュを余裕で常駐させられる 64GB ユニファイドメモリの母艦があれば、クラウドへの無駄な通信そのものを根元から減らせますからね。

毎日長時間 AI エージェントを回す開発・執筆母艦として、当ラボでも中核に据えているのが 64GB ユニファイドメモリ構成の『Apple Mac mini（Pro チップ搭載モデル）』 です。初期投資として仮に約 30 万円前後かかったとしても、5 年間（1,825 日）毎日使う開発母艦として割れば 1 日あたり約 164 円（推論・試算）です。Claude Code の平均消費額（1 日約 13 米ドル＝約 2,000 円前後）のわずか 12 分の 1 以下の日額コストで、ローカル索引・ビルド・検問ゲートを待ち時間ゼロで並列稼働させ続けられます。

Apple Mac mini（M4 Pro 等 Appleシリコン Pro系チップ・64GBユニファイドメモリ構成）

Amazon 楽天市場 Yahoo!

また、肥大化しやすい会話ログのアーカイブや知識ベース SQLite の定期スナップショット退避先には、Mac 標準の APFS フォーマットと相性が良く最大 1,050MB/s で高速転送できる外付け SSD 『Crucial X9 Pro For Mac』 を組み合わせると盤石です。2TB モデル（実勢約 2.5 万円前後）を 5 年（1,825 日）使えば 1 日あたりわずか約 14 円（推論・試算）で、数年分の全プロジェクト履歴と階層インデックスを安全に手元保管できます。

Crucial X9 Pro For Mac 外付けポータブルSSD (1TB / 2TB / 4TB・USB 3.2 Gen 2 最大1,050MB/s)

Amazon 楽天市場 Yahoo!

まとめ：最上位AIに階層索引を組ませる実践プロンプト

『DecisionRAG』が証明したのは、「AI の検索精度を決めるのは高価な外部ベクトル検索エンジンではなく、文書がどれだけ綺麗に階層化され、上流から無駄なくナビゲートできるかである」というシンプルかつ本質的な事実でした。

手元のプロジェクトにこの「検索機不要・丸読み不要の階層ナビゲーション」を導入する際は、人間が手作業でスクリプトを書く必要はありません。必ず推論力の高い 『Gemini 4 Argon』（または同等以上の最上位フロンティア AI モデル）を選び、以下のプロンプトをコピー＆ペーストしてご自身の環境に合わせた設計案から作らせてみてください。

📋 コピペ用：最上位AI（Gemini 4 Argon等）に階層ナビゲーション基盤を作らせる指示書

以下の記事で解説されている『DecisionRAG』の階層ナビゲーション設計とトークン節約原則を参考に、私の現在のプロジェクト環境に最適な「ファイル丸読み防止・階層インデックス＆アウトライン抽出仕組み」を導入したいです。

参考記事URL：https://lab.chihouzakki.com/blog/review/decisionrag-retriever-free-navigation-claude-13dollar-saving-guide/

【厳守してほしい手順】

いきなりコードを書き換えたりファイルを大量作成したりせず、まず現在のワークスペースのディレクトリ構成、ドキュメント数、既存のルール定義ファイル（GEMINI.md / CLAUDE.md / AGENTS.md 等）のサイズを調査してください。
私の環境に合わせて、①常時読み込むコア原則のスリム化案、②「要約一覧 → ファイル内見出し・行番号マップ → ピンポイント行範囲読込」の3段階ナビゲーションを実現する軽量ローカルスクリプト（またはSQLite索引）の実装計画を作成し、メリット・注意点とともに提示してください。
私が計画内容を確認して合意してから、実際の実装とテストに進んでください。