ドキュメントコンテキストレイヤーとは、PDFやWord、PowerPointなどの文書を解析し、その内容をAIエージェントが検索、参照できる状態で管理し、必要に応じて業務処理まで実行できるようにする仕組みを指す。AIエージェントと社内文書の間に入り、文書の「解析」「管理」「業務利用」をつなぐ役割を担う。

　AIエージェントが社内文書をうまく利用できない原因の1つは、ファイル形式そのものにある。

　特にPDFは、文書の意味構造を機械に伝えることよりも、ページを一定の見た目で表示、印刷することを重視した形式だ。文字や図形がページ上の座標として保持されている場合があり、人間の目には表に見える部分も、ファイル内部では「表」として構造化されているとは限らない。

　こうしたPDFの特徴についてリウ氏は、AIエージェントがPDFファイルそのものを受け取っただけでは、その内容を正しく意味付けして理解することは難しいと指摘する。

　複数段組みの文書にも読み取りの課題がある。PDF内部で文字が格納されている順番と、人間がページを読む順番が一致する保証がないためだ。単純に文字だけを抽出すると、異なる段落の文章が混ざったり、読む順序が入れ替わったりする可能性がある。

　WordやPowerPointには、本文だけでなく、フォントや文字サイズ、図形の位置など、表示やレイアウトを再現するための情報が含まれることがある。AIエージェントが文書を理解するには、こうした情報をそのまま渡すのではなく、見出しや段落、表など、意味理解に必要な構造を適切に取り出す必要がある。

　つまり、AIエージェントがSharePointやファイルサーバなどに保存された文書を検索、取得できるようにしただけでは、その中身まで正確に理解できるとは限らない。

AIモデルを替える前に「文書を渡すまで」を確認する

　そこで情シスが確認したいのが、社内文書がAIエージェントに渡るまでの処理の流れだ。

　リウ氏は、AIエージェント向けの文書基盤について、大きく3つの機能を挙げる。PDFやWord、PowerPointを解析する「文書解析」、解析した文書をAIエージェントが検索、参照できる形で保存、管理する「文書管理」、請求書処理など特定業務を繰り返し実行する「文書ワークフロー」だ。

　このうち最初に問題になりやすいのが文書解析だ。PDFなどから文字を抜き出すだけではなく、表やグラフ、見出し、段落などの構造を認識し、AIエージェントが利用できるMarkdownやメタデータなどに変換する必要がある。

　文書解析についてリウ氏は、PDFやPowerPoint、Wordなどを「AIエージェントが扱いやすく、トークン効率の良いコンテキスト」に変換することが重要だと説明する。

　一方、文書を解析する方法は1つではない。例えばPDFから文字や位置情報を取り出すためのソフトウェアを使い、文字の位置などを基に段落や表を推定するという従来型の方法がある。一方、VLM（Vision Language Model）のような画像を理解できるAIモデルを使い、ページ全体を画像として解析する方法もある。

　ただし、VLMを使えば全て解決するわけではない。リウ氏は、VLMだけで文書を解析する方法について、テキスト中心のページで誤った内容を生成する可能性があることや、処理コストが大きくなることなどを課題として挙げる。そのためLlamaIndexでは、従来型のファイル解析と画像認識を組み合わせるアプローチを採っているという。

　情シスがAIエージェントを選定する際も、「どのAIモデルを使っているか」だけでなく、「PDFやMicrosoft Officeのドキュメントをどのような方法で解析し、AIへ渡しているか」を確認する必要がある。

全ての社内文書を最高精度で読む必要はない

　文書解析でもう1つ考える必要があるのが、精度とコストのバランスだ。例えば、契約書や金融関連資料など、数値を1つ読み間違えただけでも業務上の問題につながる文書では、高い解析精度が必要になる。

　この点についてリウ氏は、金融や保険などでは、抽出ミスによる影響が大きいため、処理コストを多くかけてでも極めて高い精度が求められる場合があると強調する。

　一方、社内検索のために膨大な文書をインデックス化するケースでは事情が異なる。例えばSharePoint内で大量の文書が日々更新されている場合、その全ページを高度なVLMで解析すれば、大きな処理コストがかかる。

　リウ氏は、大量の文書をRAGの検索対象として登録する用途では、多少解析精度が落ちても低コストで処理し、必要になったときにAIエージェントが対象文書を詳しく確認する方法も考えられると述べる。

　具体的には、まず高速な解析手段で大量の文書を読み込み、AIエージェントが表やグラフを詳しく確認する必要があると判断した場合だけ、VLMなどを使って再解析する方法だ。

　企業で応用する場合も、全ての文書を同じ方法で処理するのではなく、用途や重要度に応じて解析方法を変える設計が考えられる。

「ベクトル検索につなげれば終わり」でもない

　社内文書を適切に利用できない原因は、文書解析だけとは限らない。解析した文書から必要な情報をどう探すかという検索部分も確認すべき対象になる。初期のRAG（検索拡張生成）では、文書を一定の単位に分割してベクトル化し、質問に意味的に近い文章を取得してLLMに渡す方法が広く使われてきた。

　しかし、AIエージェントの検索方法も変化している。リウ氏は、現在のAIエージェントでは、エージェント自身が適切な検索キーワードや検索語を考え、一度の検索で答えが得られなければ検索を繰り返すことが可能になっていると話す。

　そのため、検索基盤側にも複数の情報取得手段を用意する考え方がある。文書検索に利用できる手法としてリウ氏は、アルゴリズムの「BM25」やLinuxの文字列抽出コマンド「grep」、ベクトル検索、文書そのものの読み込みなどを紹介する。AIエージェントが目的に応じて、こうした手段を使い分ける構成だ。

情シスが確認すべき3つのポイント

　AIエージェントを導入したものの「社内文書から必要な情報を取ってこない」となったとき、より高性能なAIモデルへの変更だけを検討するのは早い。

　まず確認したいのは、PDFやOffice文書がAIの理解できる形に変換されているかだ。

　例えば、PDFの表を読み取った際に列と行の対応が崩れていないか。複数段組みの記事が異なる順番で抽出されていないか。PowerPointの図表やテキストボックス間の関係が失われていないか。実際にAIへ渡されているデータを確認する必要がある。

　次に確認したいのが、文書の用途に応じて解析方法を変えられるかだ。

　社内検索用の大量の文書と、契約書のように一つの読み間違いが問題になる文書とでは、求められる精度が異なる。全てを最高精度で処理するのではなく、必要な文書だけ詳細に解析する方法もある。

　3つ目は、AIエージェントに複数の検索手段を持たせているかだ。

　ベクトル検索だけで目的の情報を取得できない場合でも、キーワード検索や全文検索、元文書の再読み込みを組み合わせれば、必要な情報を取得できる可能性がある。

　AIモデルやAIエージェントの性能が向上しても、企業が持つ文書を適切な形で渡せなければ、その性能を十分に生かすことはできない。

　リウ氏は、AIエージェントが高度になるほど、企業が持つ文書などのコンテキストへ適切にアクセスできることが重要になるとの見方を示す。

　AIエージェント導入後に「社内文書を読めない」という問題が発覚したとき、情シスが見直すべきなのはAIモデルだけではない。文書をどう解析し、どのように検索させ、必要に応じて原文までたどれるようにするか――。AIと社内文書の間にある「文書基盤」が、改善すべきポイントになる。

本稿は、2026年9月23日にAI Engineerが公開したBuilding the Document Context Layer for AI Agents－Jerry Liu, LlamaIndexを基に作成しました。