図表や画像を含む資料の検索は、設計が3通りある：「文字に直す」「画像のまま埋め込む」「ページ画像で探す」。ColPaliの論文と各社の公式文書で、選択肢と制限を確かめる

この記事は、実際に使って確かめた記録ではありません。この記事は、公式の文書と論文のページを読んでまとめたものです。数字と仕様は2026年10月22日に確認しました。変わることがあります。

先に結論

• 図や表が答えの鍵になる資料では、文字だけを取り出して検索すると、図表の情報が落ちます。ColPaliの論文は、ページの文字を取り出す処理は手間がかかり壊れやすく、見た目の手がかり（図、配置、表、書体）をうまく扱えない、と書いています。
• 対策は3通りあり、それぞれ得るものと払うものが違います。文字に直す方式は安く、既存の仕組みを使えますが、図の中身はキャプション（説明文）の質に頼ります。画像を直接扱う方式は、図表を落としにくい一方、保存量と計算、制限が増えます。
• どれを選ぶかは、資料の性質（図表の比重）と、規模（何ページか）と、使う道具の制限で決まります。最後は、自分の資料で「探せたか」を測るしかありません。

前提：何が難しいのか

ふつうのRAG（検索拡張生成）は、資料を文章の塊（チャンク）に切り、各塊を埋め込み（意味の近さを測れる数字の列）に直して保存し、質問に近い塊を探して、AIに渡します。文章だけの資料なら、これで足ります。

図表入りの資料では、2つの場面で情報が落ちます。

1. 探す段階： グラフや図の中身が、文字として取り出せていないと、質問に近い塊として見つかりません。
2. 答える段階： 見つかった塊が文字だけだと、AIは図そのものを見られません。

そこで設計を考えるときは、「探す側」と「答える側」を別々に考えます。

3通りの設計

(1)〜(3)の分類は、僕らの整理です。論文や公式文書が、この3つに分けて書いているわけではありません。

(1) 文字に直す

ColPaliの論文によると、従来の流れは、文書の構造の解析（レイアウト）、文字の読み取り（OCR）、図の説明文づくり（キャプション）を重ねて、文章の検索にかけます。論文には、この流れの1ページあたりの処理時間が合計7.22秒と書かれています（内訳は、レイアウト0.81秒、OCR 2.67秒、キャプション3.71秒、ページの符号化0.03秒）。

見方を変えると、文字に直すのは「前処理が重い」方式です。ただし、Googleの埋め込みモデルのページは、Gemini Developer APIではPDFのOCRが常にオンだと書いており、道具の側が文字の取り出しを内包する場合もあります。

(2) 画像やページを、そのまま埋め込む

Googleの埋め込みのページによると、gemini-embedding-2は、Gemini APIで最初のマルチモーダル（文字・画像・動画・音声・PDF）の埋め込みモデルで、入力は文字、画像、動画、音声、PDFで、出力は共通の空間の数字の列です。PDFは1回に1ファイルで最大6ページ、品質のためには1ページずつが勧められ、1ページあたり258の画像トークンに、取り出した文字のトークンが加わる、とあります。画像は1回に最大6枚（PNGかJPEG）です。

注意点が3つあります。入力は全体で8,192トークンまでで、超えた分は黙って切り捨てられます。1つのリクエストに複数の部品を入れると、1つにまとめた数字の列になります。別々のContentオブジェクトにすると、別々の数字の列になる、と書かれています。そして、旧モデル（gemini-embedding-001、文字のみ）とは数字の空間に互換がなく、切り替えるときは、すべて作り直しです。

Google Cloudのマルチモーダル埋め込みのページも読もうとしましたが、本文を取得できず、ここでは扱いません。

(3) ページ画像から、多数の数字の列を作る（ColPali型）

ColPaliの論文のページによると、ColPaliは、ページ画像から、高品質な「多ベクトル」（1ページを複数の数字の列で表す）の埋め込みを作る、画像も読めるAIです。質問側の数字の列と、遅延相互作用（レイトインタラクション）という突き合わせ方で、ページを探します。論文は、現代の文書検索の流れを大きく上回りながら、より単純で、速い、と書いています。モデルとデータは公開されています。

論文の数字（読んだのは公式のPDFの要約です）は次のとおりです。

• 評価：ViDoRe（Visual Document Retrieval Benchmark）の平均nDCG@5で、ColPaliは81.3。文字の取り出し（OCR）にBGE-M3を組み合わせた方式は66.1、キャプションにBGE-M3は67.0。
• 処理時間：1ページの索引づくりが、従来の流れの7.22秒に対し、ColPaliは0.39秒。
• 保存量：DocVQAのテスト用の埋め込みサイズの比較で、ColPali（float16）が257.5 KB（論文は1ページあたりと記載）、BGE-M3が8.60 KB。

保存量は、表の数字の比で約30倍です（257.5÷8.60、僕らの計算）。BGE-M3側が同じ1ページ単位かは、読んだ範囲では明記を確認できていません。論文は、圧縮の工夫（トークンのプーリング）も報告しています。係数3で、数字の列の数を66.7%減らしても、元の性能の97.8%が保たれた、とあります。

見立てです。数万ページを超える資料では、この保存量と、専用の索引の仕組みが、設計の中心の悩みになると思います。論文の評価は、書籍の数百ページの規模ではなく、文書が500〜1,600件ほどのタスクが中心です。

答える側：見つけたページを、どう渡すか

探したページを、AIに渡す方法は、大きく2つです。文字だけを渡すか、ページの画像も渡すか。後者は、各社の公式のPDF・画像の機能で実現できます。

• Anthropic： PDFでは、各ページが画像に変換され、取り出した文字が添えられて、AIは両方を使います。1リクエストの上限は、32MB、600ページ（コンテキストが100万トークン未満のときは100ページ）です。文字の分は、1ページあたり通常1,500〜3,000トークン、そのほかに、ページ画像のトークンがかかります。
• Google（Gemini）： PDFをネイティブの画像認識で読み、最大50MBまたは1,000ページ。1ページが258トークンです。Gemini 3のモデルでは、PDFに埋め込まれた文字のトークンには課金されない、とあります。
• OpenAI： ファイル検索（file search）は、PDFやpptxなどをベクトルストアに入れて、意味とキーワードで探します。ただし、読んだページには、PDFの中の画像を扱うかどうかが書かれていませんでした。

見立てです。RAGで画像を渡す場合は、探した上位k件のページ分だけ、画像のトークンが増えます。たとえばGeminiなら、5ページで1,290トークン（258×5、僕らの計算）で、画像のトークンとしては少なく見えます。Anthropicは、文字の分と画像の分が両方かかるので、費用の見積もりには、トークン数を数える機能で自分の資料を測ることが、公式に勧められています。

選び方・判断の基準

ここからは僕らの見立てです。公式が勧めている手順ではありません。

• 図表がほとんどない資料（議事録、規程）： (1)で十分だと思います。文字の取り出しが正しいかだけを確認します。
• グラフや図が答えに効く資料（決算資料、論文、設計書）： (2)か(3)を、小さい規模から比べます。ColPaliの論文は、ViDoReの評価で、画像から直接探す方式の平均が高かった、と書いています。
• ページ数が非常に多い資料： (3)は保存量が大きいため、規模に応じた索引の設計が必要です。まずは(1)と(2)で作り、評価で足りない場面だけを(3)で補う、という順序が考えられます。
• すでにあるRAGに足す場合： 全部を作り直す前に、図表を含む質問の失敗例だけを集めて、どこで落ちているか（探す段階か、答える段階か）を切り分けます。探す段階で落ちているなら(2)(3)の出番で、答える段階で落ちているなら、ページ画像をAIに渡す変更で足ります。

よくある失敗・つまずき

• 探す段階と答える段階を、まとめて評価する。 どちらで落ちたかが分かりません。ページ単位で「正しいページが上位に入ったか」を、別に測ります。評価の考え方は、別の記事で扱っています。
• 埋め込みモデルの入力の上限を見落とす。 Googleのモデルは、全体で8,192トークンを超えると、黙って切り捨てられます。長いPDFは、ページごとに分けます。
• 埋め込みモデルを替えて、古い数字の列と混ぜる。 Googleのページが書くとおり、モデル間の空間は互換がなく、作り直しになります。
• 小さな画像や回転した画像を入れる。 Anthropicの文書は、小さい（200ピクセル未満）画像や回転した画像で誤りやすいと書いています。PDFでも、ページの向きを揃えるように勧めています。
• 画像のトークンを数えずに、上位kを増やす。 画像1枚の大きさで、トークン数が数倍になりえます（Anthropicの文書では、高解像度は標準の最大約3倍）。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。内容は公式の文書と論文のページの記載です。
• ColPaliの論文の数字は、論文の著者が作った評価（ViDoRe）での結果です。評価も提案も同じ著者の作なので、別の資料や言語でも同じとは限りません。論文には、訓練データが英語のみであることも、書かれています。
• 論文は、アブストラクトのページと、PDFの要約を読みました。WebFetchは、ページを要約して返す仕組みなので、僕らが言い換えており、取りこぼしがありえます。要約には、論文の記述どうしの小さな食い違い（問い合わせ時間の数字が、ColPaliで約30ミリ秒、全体で22ミリ秒以下、と章で違う）も含まれていました。
• Google Cloud（Vertex側）のマルチモーダル埋め込みのページは、本文が取れませんでした。OpenAIのファイル検索の、PDF内の画像の扱い、ファイルの大きさの上限も、読んだ範囲では確認できていません。「ない」とは断定できません。
• 公式のページの数字（ページ数、サイズ、トークン、次元、モデル名）は変わりえます。使う前に、自分のモデルのページで確認してください。
• 3つの設計の分類と、「選び方」の部分は、僕らの整理と見立てです。
• ハイブリッド検索や、RAGの評価の細かい作り方は、別の記事で扱っているので、ここでは短く触れるだけにしています。

出典

• ColPali: Efficient Document Retrieval with Vision Language Models（arXiv 2407.01449、Faysseら、10月22日確認）
• Embeddings（Gemini API、Google AI for Developers、Google、10月22日確認）
• Document understanding（Gemini API、Google AI for Developers、Google、10月22日確認）
• PDF support（Claude Platform Docs、Anthropic、10月22日確認）
• Vision（Claude Platform Docs、Anthropic、10月22日確認）
• File search（OpenAI API、OpenAI、10月22日確認）
• Retrieval（OpenAI API、OpenAI、10月22日確認）

更新履歴

• 2026年10月25日 書き方を直しました。

  • 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した

• 2026年10月22日 公式の資料を読み直して、次の点を直しました。

  • 前：複数の部品を別々に数字の列にしたい場合の扱いは確認できていない → いま：別々のContentオブジェクトにすると、別々の数字の列になると書かれている
• 一部の出典は読めなかったため、その部分は前のままです。