Outlines Index：AI Agent に大量のドキュメントを段階的に開示する手法

3,000 件のドキュメントがあるとします。PDF、Word、Markdown、電子書籍、メモ。必要な時に AI Agent がそれらを見つけて読めるようにしたい。どうすればいいでしょうか？

主流の答えは RAG です：ドキュメントをチャンクに分割し、ベクトル化し、ベクトルデータベースに格納する。ユーザーが質問した時に最も関連性の高いチャンクを検索してプロンプトに詰め込む。このアプローチは過去2年間広く採用されてきましたが、根本的な問題があります——AI が受け取るのは常に事前に切り刻まれた断片であり、ドキュメントそのものではありません。 断片化されたドキュメントチャンクは最終的に AI のコンテキストを汚染し、精度とメンテナンス性の泥沼に陥ります。そのため 2025 年には「RAG は死んだ」という主張が繰り返し見られました。Claude Code などの AI Agent が Grep や Glob のような原始的なツールで検索を行い、目覚ましい成果を上げて以降、RAG はあまり注目されなくなったようです。

しかし検索は基本的な能力です。Skills で使われている段階的開示の考え方を参考に、Outlines Index という全く新しい検索手法を実装しました。

核心のアイデアを一言で：各ドキュメントに構造化された「名刺」を作成し、AI が search → outline → read のパスでドキュメントに段階的にアクセスできるようにする。チャンクに分割した断片を一度に流し込むのではなく。

問題はどこにあるか

AI Agent がユーザーのローカルにある非構造化ドキュメントにアクセスする際、2つの障壁に直面します：

障壁1：パスに意味がない。 コードベースでは src/services/auth.ts というパス自体が認証サービスのコードであることを示しています。しかし 2024年度総括(修正版)(最終版).docx は？パスが伝える情報はほぼゼロです。AI は Claude Code のように glob パターンマッチングでドキュメントを特定できません。
障壁2：フォーマットが読めない。 PDF や DOCX はバイナリ形式で、grep では読めません。プレーンテキストに変換しても、セクション見出しのない 200 ページの PDF はただの巨大なテキストの壁で、AI は手の付けようがありません。

従来の RAG はこの2つの問題を回避します：ドキュメント構造を無視し、すべてを固定サイズのチャンクに切り、ベクトル化後に意味的類似度で検索します。

しかし、これは多くの問題を引き起こします：

コンテキストの喪失：チャンクに切り刻まれると前後の文脈から切り離され、AI はこの文章がどの章から来たのか、前後で何が議論されていたのか分かりません
制御不能：検索されたチャンクが不十分かもしれませんが、AI は「もう少し読む」ことができません
トークンの無駄遣い：10 チャンクで 5,000 以上のトークンを返すが、本当に関連があるのは1つだけかもしれません
品質が不安定：チャンク分割戦略が結果に影響し、重要な段落が2つのチャンクに分割されると、どちらも単独では検索できなくなる可能性があります
意味の喪失：従来の RAG は最終的な並べ替えに Rerank に依存しますが、これはコストの高い方法であり、多くの専門用語は Rerank モデルでは意味を捉えられません

Claude Code からのインスピレーション

転換点は一つの観察から来ました：Claude Code は RAG を使わないのに、コードベース全体を効率的に探索できます。

使うのは3つのツールだけ：Glob（パターンでファイル検索）、Grep（キーワード検索）、Read（ファイル内容を読む）。

そのアプローチは「検索エンジンが断片を返す」のではなく、研究者がファイルキャビネットを閲覧するようなもの——ファイル名をスキャンして候補を見つけ、ファイルを開いて構造をざっと確認し、どの部分が有用か特定してから、精確に読む。この方法には名前があります：段階的開示（Progressive Disclosure）。

段階的開示はインターフェースデザインの原則です：すべての情報を一度に表示するのではなく、ユーザーの現在のニーズに応じて段階的に展開します。AI Agent の文脈では、Agent が自律的に「どれだけ見るか」を決めるということです。

問題は：Glob+Grep はプレーンテキストのコードベースにしか適用できません。ドキュメントには同等の「ディレクトリインデックス」システムが必要です。

これが Outlines Index を生み出した理由です。

Outlines Index とは

インデックスされた各ドキュメントに対して、2つの部分からなる構造化情報を生成します：

Metadata（メタデータ）——ドキュメントの「身分証明書」：

タイトル（多段フォールバック：ドキュメントメタデータ → 最初の見出し → ファイル名）
著者、言語、語数
要約（ドキュメント冒頭の約 200 語）
キーワード（自動抽出）
brief フラグ（語数 < 500 の場合 true）

Outline（構造アウトライン）——ドキュメントの「目次」：

セクション見出し、階層関係、各セクションの最初の文の要約、キーワード、行番号範囲。ツリー構造で格納されます。

重要なポイント：Outline は原文を格納せず、ナビゲーション情報のみを格納します。 地図であって、領土そのものではありません。

3層の段階的開示

Outlines Index は Agent Skills にインスピレーションを受けています。Agent Skills は段階的開示技術を採用しており、数十のスキルを読み込んでも効果的にフィルタリングし、コンテキスト爆発を防ぎます。

同様に、Outlines Index に基づいて3つの MCP ツールを構築しました。3つの開示レイヤーに対応します：

Layer 1: search — ドキュメントの発見

> search("context engineering")

Found 5 results:

#1  Effective context engineering for AI agents
    doc_id: 1714 | type: md | words: 3,200 | lines: 139
    has_outline: yes | relevance: 0.92
    snippet: "Context engineering is the art of providing..."

#2  Prompt Design Best Practices
    doc_id: 892 | type: pdf | words: 28,600 | lines: 580
    has_outline: yes | relevance: 0.78
    snippet: "This guide covers effective prompt..."

...

各結果は約 50 トークン。20 件の結果で合計約 1,000 トークン。

このリストを受け取った後、LLM は以下を確認できます：

has_outline: yes → outline ツールでさらに深掘り可能
words: 3200 → 中程度の長さのドキュメント
relevance: 0.92 → 高い関連性

Layer 2: outline — 構造のブラウジング

次に LLM はツール呼び出し能力を活用して、関連性があると判断したドキュメントのアウトラインを一括で確認し、さらに絞り込みます。これは人間が本を閲覧する方法と全く同じです。

> outline(1714)

[1] Effective context engineering for AI agents [L1-139, 139行]
  [1.2] Context engineering vs. prompt engineering [L16-27, 12行]
  [1.3] Why context engineering is important [L28-41, 14行]
  [1.4] The anatomy of effective context [L42-65, 24行]
  [1.5] Context retrieval and agentic search [L66-127, 62行]
    [1.5.1] Context engineering for long-horizon tasks [L86-127, 42行]
  [1.6] Conclusion [L128-135, 8行]

各ドキュメントは約 200〜500 トークン。

各ノードの後の [L42-65, 24行] に注目してください——これは行番号範囲で、read ツールのパラメータに直接対応します。アウトラインを見れば、AI はどこを読むべきか分かります。

Layer 3: read — 精密な読み取り

このツールは Claude の Agent SDK と全く同じ動作をします。

> read(1714, offset=42, limit=24)

42 | ## The anatomy of effective context
43 |
44 | Effective context has several key properties:
45 | it is relevant, complete, concise, and well-structured.
...
65 | The best context feels invisible — the AI simply
   | "knows" what it needs to know.

Showing lines 42-65 of 139.

必要な 24 行のみを読み取りました。

ワークフロー全体で約 800 トークンを消費。同じシナリオで従来の RAG は 10 チャンクを返し、4,000〜6,000 トークンを消費し、AI はドキュメント構造の知識がなく、埋め込みモデルと ReRank モデルの理解力に完全に依存します。

実際の例：検索から精密な読み取りまで

より複雑なケースを見てみましょう。AI に「Docker デプロイのドキュメントを探して」と頼んだとします。

AI の操作プロセス

ステップ1：search

AI が search("Docker デプロイ") を呼び出し、5つのファイルを返します。1つは deployment-guide.pdf——2,400 行、has_outline: yes。もう1つは .env.example——20 行、brief: true。

ステップ2：振り分け判断

.env.example → brief: true、20 行 → outline をスキップ、直接 read、一回で完了
deployment-guide.pdf → 2,400 行 → まず outline

ステップ3：outline

> outline(deployment-guide)

[1] Introduction [L1-50, 50行]
[2] Prerequisites [L51-120, 70行]
[3] Docker Setup [L121-380, 260行]
  [3.1] Dockerfile Configuration [L125-200, 76行]
  [3.2] Docker Compose [L201-310, 110行]
  [3.3] Environment Variables [L311-380, 70行]
[4] Kubernetes Deployment [L381-800, 420行]
  ...
[8] Troubleshooting [L1900-2400, 500行]

AI は「Docker Setup」が第3章にあり、L121 から始まることを確認しました。

ステップ4：精密な read

> read(deployment-guide, offset=121, limit=260)

Docker Setup の章全体を精確に読み取りました。Docker Compose セクションだけが必要な場合は、offset=201, limit=110 にさらに絞り込めます。

合計消費：search 1,000 + outline 400 + read 2,000 ≈ 3,400 トークンで、完全なコンテキストを持つ精確な情報を取得。

RAG のアプローチでは？2,400 行のドキュメントからランダムに切り出された 10 チャンク、5,000 以上のトークン、Docker Compose の設定例がちょうど欠落している可能性があります。

brief フラグ：目次を確認するかどうかを AI に判断させる

小さいけれど重要な設計の詳細：brief ブーリアンフィールド。

ドキュメントの語数が 500 未満の場合、brief は true に設定されます。AI は検索結果で brief: true を見て、このドキュメントは短いので outline をスキップして直接全文を read できると判断します。

ツールレベルで強制ロジックは不要です。LLM は「このファイルは短い、そのまま読もう」と自然に理解します。決定権をハードコードするのではなく、AI に委ねます。

アウトライン生成：フォーマットごとに異なる戦略

ドキュメントフォーマットによってアウトライン抽出方法が異なります：

フォーマット	戦略	アウトライン品質
Markdown	`#` 見出しレベルを解析	高
PDF（ブックマークあり）	PDF ブックマークツリーを抽出	高
DOCX	Heading スタイルを解析	高
HTML	Markdown に変換後に抽出	高
PDF（ブックマークなし）	ヒューリスティックルール認識	中
プレーンテキスト	ALL CAPS / 番号パターン / 下線マーカー	中またはなし

プレーンテキストファイルでは、ヒューリスティックルールで潜在的な見出しを識別します：

=== または --- 下線マーカーのある行
番号パターン：1.、1.2、Chapter N、Section N
全大文字行（ALL CAPS）

ヒューリスティックで信頼性の高いアウトラインが識別できない場合、outline_quality は none とマークされ、outline ツールは「No reliable outline available. Use read to browse this document line by line.」と返します——エラーではなく、優雅なデグラデーションです。

バジェット戦略：ドキュメントの大きさに関係なく、アウトライン出力を制御可能に

2,000 ページの学術論文は、数百のアウトラインノードを持つ可能性があります。すべてをそのまま出力するとトークンを大量に消費します。

多段階のデグラデーション戦略を実装しました：

完全出力——トークン予算内であれば、すべてのノードを返す（要約とキーワード付き）
要約を削除——見出しと行番号のみを保持
深度を下げる——Level 5 から順に削除し、最終的には Level 1 のトップレベル見出しのみを表示
ハードカット——最終フォールバック

これにより、ドキュメントの大きさに関係なく、アウトライン出力が合理的な範囲内に収まることが保証されます。

ドキュメントごとに1つのベクトル：チャンキング不要

従来の RAG はドキュメントをチャンクに分割してからベクトル化する必要があります。100 ページのドキュメントは 200 のベクトルを生成する可能性があります。10,000 ドキュメントで 200 万ベクトル。

Outlines Index は異なるアプローチを取ります：埋め込みの対象は原文ではなく、Outline Index そのものです。

Title: デプロイガイド
Author: DevOps Team
Language: zh
Keywords: Docker, Kubernetes, CI/CD
Abstract: 本文では本番環境のデプロイ方法を紹介...
---
## Prerequisites
> 本セクションではデプロイ前に必要な環境とツールを紹介...
## Docker Setup
> docker-compose を使用したコンテナ化デプロイ...

Outline はドキュメントのコアとなる意味を自然に凝縮します。1つのドキュメントから1つのベクトルのみ生成。

10,000 ドキュメント = 10,000 ベクトル ≈ 30MB ストレージ。

これは単にスペースの節約だけではありません——単一ベクトル検索は 200 万ベクトルの中を検索するよりはるかに高速です。しかも Outline はドキュメント全体の情報を凝縮しているため、ベクトルの品質はむしろ高くなります。目標を関連チャンクの取得から、まず関連ドキュメントの取得に変えた時、検索プロセス全体がシンプルで汎用的になりました。

デュアルパス検索：正確なマッチング + 意味理解

過去の RAG の実践により、BM25+ベクトルのデュアルパスハイブリッド検索がシンプルで効果的なアプローチであることが証明されています。そのため search ツール内部ではこの戦略を採用し、2つの検索パスを同時に実行します：

BM25 全文検索：正確なキーワードマッチング、技術用語、固有名詞、人名に不可欠
ベクトル意味検索（Outline Index ベクトルに基づく）：クロス言語能力、「deployment」が「部署」にマッチ

両パスの結果を RRF（Reciprocal Rank Fusion）で融合します。

これによりシステムにもう一つの優雅な特性が生まれます：段階的利用可能性。

BM25 インデックスは通常インストール後 1〜3 分で構築完了し（Outline 生成も同時に行われます）、キーワード検索がすぐに利用可能になります。ベクトルインデックスはより長い時間がかかりますが（ドキュメント数による）、完了後に意味検索が自動的にオンラインになります。ユーザーは気づかず、待つ必要もありません。まさにこのアプローチにより、コンシューマー向け製品の体験が確保されます——おそらく市場でインストール後最速で利用可能になるナレッジベースアプリです。

おそらく未来を見据えたアプローチ

RAG の設計前提は：LLM は十分に賢くないので、情報を準備し、切り刻み、並べ替え、プロンプトに詰め込む必要がある、というものです。これは GPT-3.5 時代には合理的でした。

しかし今日の LLM は、複雑な多段階検索タスクを自律的にツールを使って完了できます。Claude、GPT-4、Gemini はすべて強力なツール使用能力を示しています。事前に切り刻まれた断片は不要です——必要なのは手がかりです。ファイルがどこにあるか、構造がどうなっているかを伝えれば、何を読むか、どれだけ読むかは自分で決められます。

Outlines Index のコア理念：AI のために情報を前処理するのではなく、地図を渡して自分で探索させる。

3つのアトミックツール（search、outline、read）が LLM の創発的能力を解放します：

クロスドキュメント比較：複数のドキュメントのアウトラインを同時に確認し、構造と内容を比較
反復検索：結果に満足できなければ、自動的にキーワードを調整して再試行
深い読み込み：ある章が別の概念を参照していることを発見？関連ドキュメントを検索
ドキュメントベースの執筆：複数の参考資料を読んだ後、新しいコンテンツを総合的に生成

これらの能力には Agent オーケストレーションフレームワークは不要です。ますます多くの LLM が、自然にツールを組み合わせて複雑なタスクを完了するようになっています。

試してみてください

Outlines Index は Linkly AI のコア技術です。Linkly AI はローカルファーストのドキュメントインデックスツールで、すべてのデータが 100% ローカルに格納されます。

インストール後にドキュメントディレクトリを選択すれば、バックグラウンドで自動的にインデックスが構築されます。その後、MCP プロトコルまたは CLI を通じて、任意の AI ツール（Claude、Cursor、ChatGPT など）が search → outline → read のワークフローでドキュメントにアクセスできます。

ぜひお試しください。

Linkly AI チーム制作。AI Agent のドキュメントアクセス方法についてご意見があれば、コメント欄でお聞かせください。