PageIndexとは？ベクトル不要の推論型RAGの仕組みと使い方【v0.2.19対応】

PageIndexは、PDFなどの長い文書を目次のような階層ツリーに変換し、LLMがそのツリーを推論でたどって答えの載っているページを探すRAG（検索拡張生成）エンジンです。埋め込みベクトルもベクトルデータベースもチャンク分割も使わないため、「Vectorless RAG（ベクトルレスRAG）」と呼ばれます。英国のVectify AI Limitedが開発し、GitHubのリポジトリ（VectifyAI/PageIndex）はMITライセンスで公開されています。2026年9月28日時点でスターは約3万5,800件です。

2026年8月のSDK更新で、pip install pageindex で索引作成・保存と検索処理を自分の環境で実行する「ローカルモード」が入りました。ただし、外部LLMのAPIを指定した場合、要約や質問応答に使う文書の内容はそのプロバイダへ送信されます。この記事では、最新安定版0.2.19（2026年9月21日公開）のソースと実行結果をもとに、仕組み・導入手順・クラウド版の料金・日本語PDFでの挙動を整理します。

まとめ：PageIndexの要点

• 2段階で検索する：文書ごとにツリー索引（JSON）を作り、質問時にLLMがツリーをたどって該当ノードのページ本文だけを読む。類似度ではなく推論で関連性を判断する。
• ツリー作成自体はLLMを使わない：v0.2.19の既定であるFlash方式はレイアウトとPDFのしおりから構造を抽出する。LLMはノード要約とツリーの調整にだけ使い、無効化もできる。
• 導入は pip install -U pageindex：Python 3.10以上が必要。3.9以前では旧版0.2.8（クラウド専用）が入り、READMEのコードが動かない。
• ローカルは無料・テキストPDFのみ：スキャンPDFのOCR、ブロック単位の引用、MCPサーバーはクラウド版の機能。クラウドは索引作成1ページ0.01ドルの従量課金。
• 向くのは長い専門文書1本への精密な質問：金融・法務・規制・技術マニュアル。短文を大量に横断する検索や、応答の速さが最優先の用途ではベクトル検索が合う。

PageIndexの仕組み：ツリー索引とLLMによる探索

一般的なRAGは、文書を数百トークンのチャンクに刻んで埋め込みベクトルにし、質問と「意味が近い」チャンクを上位k件取り出します。PageIndexの公式READMEはこれを「similarity ≠ relevance（類似は関連と同じではない）」と批判し、人間の専門家が報告書の目次から該当章を開くように、構造をたどって読む方式を採っています。処理は索引（Index）と検索（Retrieve）の2段階です。

索引：ページ範囲を持つ目次ツリーのJSON

索引は文書1本につき1つのJSONで、各ノードが章・節のタイトルと、その節が載っている開始ページ・終了ページを持ちます。次は同梱サンプル（米連邦準備制度の年次報告書・50ページ）からLLMなしで生成した実際の出力の一部です。

{
  "title": "2 Monetary Policy and Economic Developments",
  "node_id": "0003",
  "start_index": 9,
  "end_index": 20,
  "nodes": [
    {
      "title": "March 2024 Summary",
      "node_id": "0004",
      "start_index": 9,
      "end_index": 14,
      "nodes": [
        { "title": "Monetary Policy", "node_id": "0006", "start_index": 12, "end_index": 13 }
      ]
    }
  ]
}

ページ番号は1始まりで、子ノードは nodes 配列に再帰的に入ります。要約を有効にすると各ノードに summary が加わります。Markdownを入力した場合はページの代わりに行番号（line_num）が入り、#〜###### の見出しがそのまま階層になります。

この例では「Monetary Policy」という同名のノードが、2024年3月版と2023年6月版の下に1つずつあります。タイトルだけではLLMが区別しにくく、要約（summary）を付ける意味はここにあります。

検索：4つのツールでツリーをたどるエージェント

SDKの chat() は、LLMに次の4つのツールを渡して探索させるエージェントとして動きます（pageindex.agent_tools.tool_names() で確認）。

• browse_documents：登録済みの文書を一覧する
• get_document：文書のメタ情報を取る
• get_document_structure：ツリー（目次）を読む
• get_page_content：選んだノードのページ本文を読む

LLMは目次を読んで候補の節を選び、そのページを読み、足りなければ別の節へ移ります。回答にはページ番号の引用が付くため、どこを根拠にしたかを後から確認できます。公式ドキュメントのチュートリアルには、ツリー全体と質問をLLMに渡して thinking（推論）と node_list（該当ノードID）をJSONで返させる最小構成も載っており、公式のダッシュボードとRetrieval APIは、このLLM探索に価値関数ベースのモンテカルロ木探索（MCTS）を組み合わせていると説明されています。

ベクトルRAGとPageIndexの違い

既存のベクトルRAGを置き換えるかは、対象文書の構造と許容できる検索時間・費用で判断します。PageIndexもRAGの一種で、置き換わるのは検索（Retrieval）部分だけです。違いは次の表のとおりです。

固定長のチャンク分割をしないので、表の途中で切れる・前後の文脈が失われるといった分断は避けやすくなります。ただし、PDFの解析や節・ページの選択による情報の欠落は残ります。一方で、検索のたびにLLMが目次とページを読むため、ベクトル検索より遅く、LLMの利用料もかかります。公式ドキュメントも、LLMだけの探索は推論に時間がかかること、要約だけでノードを選ぶと原文の細部を見落とし得ることを制約として挙げています。

意味の近さで探す方式そのものの整理はベクトル検索とセマンティック検索の違い、キーワード検索との併用はハイブリッド検索（BM25とベクトル検索の統合）で解説しています。

GraphRAGとの違い

どちらも「構造を使うRAG」ですが、作る構造が違います。GraphRAGは文書群から人物・組織などのエンティティと関係を抜き出してナレッジグラフを作り、コーパス全体をまたぐ問い（「この資料群の主要テーマは何か」）に強い方式です。PageIndexは文書1本の章立てをそのままツリーにし、その文書の中で答えの載っている節を突き止める方式です。Flash方式では、GraphRAGのようにエンティティと関係を抽出するLLM処理は不要です。ただし、索引作成の総時間・費用は文書と設定によって変わります。

PageIndexの使い方：pip installからローカル実行まで

ここからは0.2.19での手順です（公式READMEとソースで確認）。2026年8月より前の解説記事は、リポジトリをcloneして run_pageindex.py を実行する方法か、APIキー必須のクラウドSDKの方法のどちらかで書かれており、現行のローカルモードとは手順が違います。

インストールとPythonのバージョン

python3 --version   # 3.10以上であること
python3 -m pip install "pageindex==0.2.19"
python3 -m pip show pageindex  # Version: 0.2.19 を確認

PyPIの0.2.10以降は Requires-Python >=3.10 です。macOS標準の /usr/bin/python3（3.9）で同じコマンドを実行すると、エラーにならず旧版0.2.8（2026年3月公開）が入ります。0.2.8の PageIndexClient は api_key だけを受け取るクラウド専用の実装で、ローカルモードのコードは引数エラーで止まります。pip show で版を確かめてから進めてください。

ローカルモードによるPDF質問応答

import os
from pageindex import PageIndexClient

os.environ["OPENAI_API_KEY"] = "sk-..."

client = PageIndexClient(
    index="gpt-5.6-luna",   # ツリーの要約・調整に使うモデル
    chat="gpt-5.6-sol",     # ツリーを探索して回答するモデル
)
doc_id = client.submit_document("report.pdf")["doc_id"]
print(client.chat("2023年の営業利益率は？", doc_id=doc_id))

索引は既定でカレントディレクトリの .pageindex に保存され、2回目以降の質問は同じツリーを使い回します。READMEの推奨は、索引側は安いモデルで足り、探索側には使える範囲で最も賢いモデルを当てることです。公式の計測では、索引作成は gpt-5.6-luna で1ページ約0.001ドル、9〜1,098ページの文書で約13秒〜4.5分でした。

モデル名はLiteLLMの表記で、OpenAI以外は anthropic/claude-sonnet-4-6 のように「プロバイダ/モデル」で指定します（config.yaml のコメントより）。環境変数は ANTHROPIC_API_KEY・OPENROUTER_API_KEY、OpenAI互換のローカルLLMなら OPENAI_BASE_URL を使います。

複数の文書を対象にするときは doc_id にリストを渡し、citations=True で引用を構造化して受け取れます。ただし公式チュートリアルは、推論による探索は基本的に文書1本の中で行うものとし、多数の文書から対象を絞る段階はメタデータや説明文での選別と組み合わせる前提で書かれています。

LLMを使わないPDFツリー生成

ツリーの形を先に確かめたいときは、リポジトリ同梱の run_pageindex.py で要約と最適化を切ると、APIキーなしで実行できます。

git clone --branch v0.2.19 --depth 1 https://github.com/VectifyAI/PageIndex.git
cd PageIndex
pip install -r requirements.txt
python3 run_pageindex.py --pdf_path report.pdf --no-summary --optimize off
# => ./results/report_structure.json

--mode の既定は flash で、PDFのしおり（埋め込み目次）を信頼できる場合は使い、なければレイアウトから見出しを検出します。前述の50ページのサンプルでは、キーなしで56ノードのツリーが約22秒（Pythonの起動を含む）で出ました。Markdownは --md_path で渡します。

日本語PDFでの挙動：しおりの有無でツリーが変わる

公式のベンチマークは英語文書が中心なので、日本語のPDFで試しました。対象はIPA「情報セキュリティ10大脅威 2025 組織編」の解説書（60ページ・しおり24件）、条件は上と同じLLMなし（--no-summary --optimize off）です。

2026年9月28日のPython 3.14・PageIndex 0.2.19環境での計測では、しおりを使うと「1位 ランサム攻撃による被害」から「10位 不注意による情報漏えい等」までが独立したノードになり、1回の実行時間は12.8秒でした。しおりを切ってレイアウト検出だけにすると、順位の見出しが拾われず、11〜55ページが1つの大きなノードにまとまり、その下に「＜攻撃者＞」「＜脅威と影響＞」といった同じ小見出しのノードが並びました。このツリーでは「3位」に対応する見出しがないため、目次だけで該当箇所を絞るのが難しくなります。ただし、今回の検証では質問応答の成否までは確認していません。

しおりを使った場合にも癖がありました。この解説書はしおり自体が「はじめに」の下に全章をぶら下げる構造になっており、PageIndexのツリーでも「はじめに」が4〜60ページを覆う親ノードになりました。PageIndexはPDF側の目次を忠実に引き継ぎます。

日本語の社内文書で使う前に確かめることは次の3点です。

• 要約なしでツリーを出し、章の見出しが漏れていないかを目で確認する
• WordからPDF化するときは、見出しスタイルからしおり（ブックマーク）を作る設定で書き出す
• しおりの階層がおかしい文書は、Markdownに変換してから --md_path で入れる（変換にはDoclingなどが使える）

クラウド版・API・MCPとOCR

同じ PageIndexClient で、索引の作成と保存だけをPageIndex Cloudに移せます。PAGEINDEX_API_KEY を設定し、index="cloud" を指定するだけです。探索に使うLLMは引き続き自分で選べます。

PageIndex OCRとスキャンPDF

以前は「PageIndex OCR」が独立したモデルとして紹介されていましたが、現在はクラウドの文書処理に組み込まれた機能です。ローカルモードはOCRを実行しません。テキスト層のないスキャンPDFを渡すと、Flashは「no text layer in this PDF (scanned or image-only); run OCR before indexing it.」というメッセージで止まります。スキャン資料が多いならクラウドを使うか、事前にOCRをかけてテキスト層を付けてから索引します。

クラウドの料金（2026年9月時点）

公式の試算では、3,000ページなら索引作成に30ドル（1回）、保持に月2ドルです。月額の最低料金はなく、登録時に10ドル分の無料クレジットが付きます（クレジットカード不要）。これとは別に、エンドユーザー向けのチャット製品PageIndex Chatには、1,000ページ・100メッセージの無料枠を掲げるFreeプランと、月20ドルからのProプランがあります。料金は改定されることがあるので、契約前に公式の料金ページで確認してください。

MCPサーバーの接続

MCPの接続先は、開発者向け（APIキー認証）とPageIndex App利用者向け（OAuth認証）の2系統に分かれています。SDKやAPIで索引した文書をエージェントから検索するなら、開発者向けのエンドポイント https://api.pageindex.ai/mcp にAPIキーを付けて接続します（公式リポジトリの設定例）。

{
  "mcpServers": {
    "pageindex": {
      "type": "http",
      "url": "https://api.pageindex.ai/mcp",
      "headers": {
        "Authorization": "Bearer <APIキー>"
      }
    }
  }
}

開発者向けMCPはAPIと同じキー・文書・プランを共有しますが、PageIndex Chat（App）とはファイルも利用量も共有しません。App利用者向けには、OAuthで接続する https://app.pageindex.ai/mcp、Claude Desktop用の .mcpb パッケージ、ローカルのPDFをアップロードできるnpm版 @pageindex/mcp（npx -y @pageindex/mcp で起動・1.8.2）が用意されています。

FinanceBench 98.7%の読み方

PageIndexが注目された理由は、これを使った金融文書向けモデルMafin 2.5が、金融文書QAのベンチマークFinanceBenchの公開セットで98.7%の正解率を出したことです。公式サイトの開発者向けページは、ベクトルRAGの正解率を全文書で索引1つなら30%、文書ごとに索引を分ければ50%としています。

ただし、この数字をそのまま自社文書での精度と読まないでください。評価リポジトリ自身が次の2点を明記しています。

• 曖昧な問題・正解が複数ある問題・無効な問題は、専門家の人手判定で採点している
• FinanceBenchは主に文書1本からの単純な検索を問う課題で、複数文書をまたぐ推論は含まれない

98.7%は、主に単一の金融文書を対象とするFinanceBench公開セットで、開発元が報告した評価値です。PageIndex自身の別のベンチマーク（34本・1,945ページのPDFに対する62問）では、正解率は探索に使うモデルと推論量（reasoning effort）の組み合わせごとに分布し、モデルを1段上げるごとに1問あたりの費用がおよそ1桁増えると報告されています。自社で採用を判断するなら、実際の文書と質問を20〜30問用意し、探索用モデルを変えて正解率と1問あたりの費用を並べるのが確実です。

PageIndexを採用すべきでない場面

PageIndexは、長く構造のある文書1本に対して精密に答える場面で真価を発揮します。次の条件に当てはまるなら、ベクトル検索（または併用）を選ぶべきです。

• 章立てのない短い文書が中心：FAQ、メール、チャットログ、ニュース記事など。目次ツリーを使う利点が小さいため、まずベクトル検索を比較候補にする。公式の開発者向けページも、短いニュースやメールの検索、汎用的な知識QAにはベクトルDBが妥当な選択肢だとしている。
• 応答を1秒以内で返したい：検索のたびにLLMが目次とページを読むため、ベクトル検索と同じ速さにはならない。
• 何千本もの文書を横断して探す：推論による探索は文書1本の中が基本。コーパス全体を扱うFile Systemはクラウド専用の機能で、ローカルでは前段で対象文書を絞る仕組みが別に要る。
• スキャンPDFが中心で社外に出せない：ローカル版にはOCRがないため、社内のOCRでテキスト層を付けてから索引する工程が別に要る。クラウドのOCRを社内で動かすオンプレミス設置は個別契約（要問い合わせ）になる。

既存のベクトルRAGで、決算書・契約書・仕様書のように章立てのある長文だけ回答精度が低いなら、その文書群だけをPageIndexに切り出す構成が現実的です。ベクトルデータベースを廃止する必要はありません。

PageIndexに関するよくある質問

PageIndexは無料で使えますか？

オープンソース版（MITライセンス）とSDKのローカルモードは無料で、PageIndexへの支払いは発生しません。ツリーの要約と探索に使うLLMの利用料だけがかかります。クラウド版は索引作成1ページ0.01ドルの従量課金で、登録時に10ドル分の無料クレジットが付きます。

PageIndexのGitHubリポジトリはどこですか？

github.com/VectifyAI/PageIndex です。PyPIのパッケージ名は pageindex で、2026年9月28日時点の最新安定版は0.2.19です（別に0.3.0系の開発版があります）。MCPサーバーのソースは別リポジトリのVectifyAI/pageindex-mcpにあります。

日本語のPDFでも使えますか？

使えます。IPAの60ページの日本語PDFでは、しおり（埋め込み目次）を使ったツリー作成が12.8秒で終わり、章見出しがノードになりました。ただし、しおりのない日本語PDFでは見出しの検出が漏れることがあったため、要約なしでツリーを出して構造を確認してから使ってください。

OpenAI以外のLLMでも動きますか？

動きます。モデル名をLiteLLMの「プロバイダ/モデル」形式（例：anthropic/claude-sonnet-4-6）で指定し、対応する環境変数にキーを設定します。OpenAI互換APIを持つローカルLLMは OPENAI_BASE_URL で接続します。

PageIndexとLlamaIndexは何が違いますか？

LlamaIndexは、ベクトル索引・キーワード索引など複数の検索方式を組み合わせてRAGアプリを作るためのフレームワークです。PageIndexは、目次ツリーと推論で探すという検索方式そのものを提供するエンジンです。PageIndexの公式MCPクックブックにはLlamaIndexやLangChainから呼び出す例があり、両者は置き換えではなく組み合わせて使えます。

関連記事

• GraphRAGとは？仕組みとベクトルRAGの違い【2026年版】
• BookRAGとは何か？階層構造とナレッジグラフを活用する次世代RAG手法の特徴と概要について徹底解説
• ベクトル検索とセマンティック検索の違い｜包含関係・仕組み・使い分けを実装目線で整理
• Doclingとは？PDFをMarkdown化してRAGに載せる実装手順と採用判断
• LangChainでRAGを構築する手順｜v1.3系のコード例とlangchain-classic移行