LlamaIndex レビュー：RAG とドキュメントエージェントのためのデータ中心フレームワーク
LlamaIndex は、社内文書や業務データを LLM アプリケーションへ接続するオープンソースのフレームワークです。中心にあるのはチャット UI ではなく、データソースを Document、Node、メタデータ、インデックス、Retriever、Query Engine、そしてエージェントの Tool へ変換する流れです。Python と TypeScript、モデルやベクトルストアとの連携、イベント駆動の Workflows、評価・可観測性の統合を提供します。
評価すべき問いは「PDF と 5 行で会話できるか」ではありません。チームが取り込みと検索品質を製品能力として設計し、権限、同期、評価、運用を引き受ける意思があるかです。LlamaIndex は実装を短縮しますが、低品質な文書、誤った ACL、未検証の Retriever を本番品質には変えません。
LlamaIndex OSS は MIT ライセンスのフレームワーク、Workflows は複数ステップやエージェントを組むイベント駆動モデル、LlamaParse/LlamaCloud は解析・抽出・分類・分割・マネージド Index を提供する別の商用サービスです。OSS の利用にクラウド契約は必須ではありません。
2026 年時点の製品境界
| レイヤー | LlamaIndex が提供するもの | 利用側が決めること |
|---|---|---|
| OSS フレームワーク | LlamaIndex OSS（Python / TypeScript） | アプリ、変換、検索、Tool を自社で制御 |
| 保守状況 | llama-index-core v0.14.24、2026-08-19 リリース | 活発だが、連携パッケージは別々の版で動く |
| ライセンス | 主リポジトリは MIT | モデル、DB、Parser、各連携の条件は別途確認 |
| マネージド文書層 | LlamaParse / LlamaCloud ダッシュボード | 任意の有料境界。Enterprise 構成以外では文書が外部事業者へ渡る |
| 料金スナップショット | Free 10K credits、Starter 月額 $50・40K credits | 処理別消費量と料金は変化するため再確認が必要 |
| 最適な仕事 | 社内文書中心の RAG とエージェント | 文書構造と検索品質を第一級の要件にする場合 |
コンポーネント別に見る技術スタック
| レイヤー | LlamaIndex が提供するもの | 利用側が決めること |
|---|---|---|
| Reader / Connector | ファイル、API、DB、SaaS を Document にする | 認可、レート、削除、差分同期 |
| Parsing / Transform | Node 分割、メタデータ付与、変換 | チャンク境界、表・画像、OCR、変換版 |
| Index / Storage | VectorStoreIndex と各種ストア連携 | テナント分離、暗号化、バックアップ、費用 |
| Retriever / Postprocessor | 意味・キーワード・ハイブリッド検索、filter、rerank | Recall、filter 正当性、遅延、fallback |
| Query / Chat Engine | 検索結果と LLM で回答を合成 | 引用、回答拒否、注入対策、モデル費用 |
| Agent / Tool | Query Engine、関数、API、MCP を Tool 化 | 最小権限、副作用承認、timeout、監査 |
| Workflows | Agent・Tool・データをイベント駆動で編成 | 耐久性、冪等性、状態、retry、手動復旧 |
| 評価 / 可観測性 | 忠実性、回答・文脈関連性、検索指標と連携 | 代表データ、release gate、trace 保存、目視確認 |
向いているケース、向いていないケース
企業内検索、サポートアシスタント、技術文書 Q&A、デューデリジェンス、契約書・請求書抽出、Research Copilot、検索と限定的な操作を組み合わせる文書エージェントに向きます。Embedding、Vector DB、Reranker、Parser を交換しながら全体を書き直したくないチームほど恩恵を受けます。
少数の固定ページへの単純な Q&A、主課題が検索ではなく長時間の取引ワークフローであるシステム、運用を持たず完成済み SaaS を求めるチームには過剰な場合があります。小規模ならモデル SDK と DB の直接利用、耐久的な状態機械なら LangGraph 等、SLA 優先ならマネージド検索も比較対象です。
編集上の判断は明確です。検索品質を継続的に設計するなら選ぶ価値があります。VectorStoreIndex を素早く作れるという理由だけでは不十分です。「何を Index したか、何を取得したか、なぜその回答や操作を許したか」を測って初めて抽象化が投資になります。
本番 RAG／エージェントの実装手順
- 許可ソース、必須引用、鮮度、利用者・テナント、拒否すべき質問を回答契約として定義する。
- 最適化前に、典型・長尾・文書矛盾・権限・古い情報・回答不能を含む評価セットを作る。
- 安定した source ID と版で取り込み、各 Node に ACL、canonical URI、更新時刻、parser 版、hash を保存する。
- 単一 embedding・単一 vector store・説明可能な top-k から始め、hit-rate と MRR を測ってから rewrite、hybrid、rerank を追加する。
- 許可された検索証拠だけで生成し、出典と明示的な「回答不能」を返す。証拠が弱いときに補完させない。
- Tool は read-only と副作用ありに分け、引数をサーバーで検証し、送金・送信・削除・機密 export は人が承認する。
- parser、retriever、reranker、model、tool の版を trace し、検索・忠実性・遅延・費用・権限の回帰で全変更を gate する。
デモでは省略される本番ゲート
| リスク | テスト／制御 | 理由 |
|---|---|---|
| 検索漏れ | ラベル付き質問の hit-rate/MRR と false negative 確認 | 取得できない根拠をモデルは引用できない |
| Hallucination | faithfulness、引用 entailment、人手 sampling | LLM judge は証明ではなく signal |
| テナント漏えい | 強制 metadata filter と攻撃的 ID テスト | 生成後の filter では遅い |
| Index の陳腐化 | change feed、照合 job、削除 test、freshness SLO | 初回成功は継続更新を保証しない |
| Prompt injection | 取得文を未信頼データとして Tool policy と分離 | 文書内の命令で Agent が誘導され得る |
| 費用急増 | parse、embedding、rerank、token、retry の予算 | OSS でも運用費はゼロではない |
| 依存 drift | core と integration を pin、canary、release note | モジュールは別々に release される |
| Workflow 障害 | 冪等 key、上限 retry、永続 state、operator resume | Notebook の loop は復旧可能な業務処理ではない |
プライバシー、配置、コスト
OSS のデータ配置は採用部品で決まります。ローカルの Parser、Embedding、Vector DB、LLM を使えば内部に保てますが、外部 API、Hosted DB、Trace exporter を選べば新しい処理者が増えます。フレームワークだけで private になるわけではありません。Reader、model、store、callback ごとの data flow を作成してください。
LlamaParse SaaS は別の判断です。公式料金 FAQ は通信・保存時の暗号化、既定 48 時間 cache、cache 無効化、Enterprise の private VPC、SOC 2 Type II・GDPR・HIPAA を掲げています。ただしこれは事業者の表明です。DPA、region、subprocessor、log、backup、削除を自組織で審査する必要があります。
費用は少なくとも Parsing、Embedding、Vector Search、Reranking、生成／Tool call の 5 系統で発生し、再 Index、評価、Trace 保存も加わります。確認時点の公式換算は 1,000 credits = $1.25 ですが処理別の消費量は異なります。スキャン PDF、表、スライド、通常テキストの実サンプルで見積もるべきです。
代替案：システムの重心で選ぶ
| 選択肢 | 選ぶ条件 | LlamaIndex との違い |
|---|---|---|
| LangChain + LangGraph | 広い Tool 生態系と durable graph orchestration が中心 | 検索も可能だが、LlamaIndex はデータ／Index／文書処理を中心に設計 |
| Haystack | 明示的で serialize 可能な component pipeline を好む | Pipeline の構造が明快。LlamaIndex は context augmentation と query engine の面が広い |
| Microsoft Semantic Kernel | .NET/C#/Java と Microsoft 組織標準が支配的 | 言語・企業統合に合う一方、文書 RAG は追加選択が増える |
| Model + Vector DB の直接 SDK | 小さく安定し、抽象層を最小化したい | 挙動は直接的だが connector、chunk、評価、編成を自作 |
| LlamaParse 単体 | OCR／抽出だけを既存 stack に供給したい | Parser は独立利用可能。ブランドを揃えるためだけに OSS 全体を入れない |
独立評価
強みは、取り込み時のメタデータから検索、合成、文書 Tool までを連続した診断対象にできる点です。「回答が間違った」を Parser、chunk、filter、recall、rerank、generation に分解して試験できます。現在も更新は活発で、必要な integration だけを導入できる構成です。
一方、モジュール性は保守負担でもあります。例は古くなり、パッケージ版はずれ、default は変わり、短いデモの裏で複数の外部サービスが動くことがあります。依存を pin し、部品を少数に絞り、新しい抽象は評価改善が確認できた場合だけ加えるべきです。
結論として、文書中心の RAG やデータに根差す Agent を作り、検索を制御したいエンジニアには有力です。しかし精度保証、Vector DB、認可システム、完成済み chatbot ではありません。厳密な評価があるほど価値が増し、評価がなければ複雑な未検証デモを速く作るだけです。
よくある質問
LlamaIndex は無料の OSS ですか？
主リポジトリは MIT です。Model API、Vector DB、Hosting、LlamaParse/LlamaCloud は別料金になり得ます。各 integration の license も確認してください。
LlamaCloud／LlamaParse は必須ですか？
いいえ。OSS だけでローカルまたは第三者部品を使った取り込み、Index、検索が可能です。Hosted parsing や extraction に価値がある場合のみ選択します。
RAG 専用ですか？
いいえ。Agent、Tool、Workflows、構造化抽出、Multimodal、評価もあります。ただしデータ取り込みと検索を第一級に扱う RAG が最も明確な差別化です。
LangChain とどちらを選びますか？
文書検索・context augmentation が中心なら LlamaIndex、広い Tool 編成や durable graph が中心なら LangChain/LangGraph を検討します。Retriever だけを他 runtime の Tool にする併用も妥当です。
完全オンプレミスで動かせますか？
OSS は自社環境へ置けますが、Model、Embedding、Parser、Storage、Telemetry もローカル選択する必要があります。Hosted LlamaParse は別境界です。
Hallucination を防げますか？
自動では防げません。Source Node と評価 module はありますが、検索評価、引用、abstention、未根拠回答の test はアプリ側の責任です。LLM evaluator も校正と人手確認が必要です。
確認した情報源
- Framework documentation
- LlamaParse platform quickstart
- Evaluation documentation
- Official GitHub repository
- GitHub releases
- LlamaParse pricing and data-handling FAQ
- LangChain product concepts
- Haystack documentation
- Microsoft Semantic Kernel
独立レビュー日：2026 年 8 月 20 日。バージョン、料金、credits、セキュリティ表明は変わり得るため、導入・調達前に一次情報を再確認してください。
