Googleが2026年5月、Gemini APIの「File Search」機能をマルチモーダル対応に拡張した。PDFや画像、図面、スクリーンショットをそのままアップロードするだけで、画像内の視覚情報を含めて検索・回答生成ができる。これまでRAG構築で最も泥臭かった「画像のテキスト化」工程が、API側に吸収された格好だ。
何が起きたか
GoogleはGemini API File Searchのマルチモーダル拡張を発表した。File SearchはGemini APIに統合されたマネージドRAG機能で、ファイルをアップロードするとチャンク分割・埋め込み生成・ベクトル検索までを自動で処理してくれる仕組み。今回のアップデートで、PDF内の図表、スキャン画像、PNG/JPEGといった画像ファイルそのものをインデックスし、ユーザーのテキストクエリに対して画像内の視覚的内容を含めて検索できるようになった。
従来のRAGパイプラインでは、PDFから図表を抽出し、OCRをかけ、画像キャプションモデルで説明文を生成し、それをテキストとともにベクトル化する、という複数段の前処理が必要だった。今回の変更で、これらがfiles.uploadとfileSearchStoresへの登録だけで完結する。
なぜこのニュースが重要か
RAGの実装現場で最も時間を食うのは、LLMの選定でもベクトルDBのチューニングでもなく、「ドキュメントの前処理」である。製造業の図面、建設業の施工要領書、医療の検査画像レポート、保険業界の事故写真付き調査書――これらは画像が情報の主役で、テキストは補助でしかない。OCRをかけても表組みは崩れ、図面の寸法線や凡例は意味を失う。
ここに対して、Gemini 2.5系のネイティブマルチモーダル能力をそのまま検索層に持ち込んだのが今回の意味だ。画像を画像のままベクトル化し、画像のままretrievalの対象にする。AWSのKnowledge Bases for Bedrockや、AzureのAI Searchも画像対応を進めているが、「アップロードして即クエリ」のシンプルさではGeminiが一歩抜けた印象がある。
エンジニア視点・実装への示唆
実装フローはきわめて簡素だ。Python SDKでの典型的なコードは以下のような形になる。
from google import genai
client = genai.Client()
store = client.file_search_stores.create(
config={"display_name": "drawings-2026"}
)
client.file_search_stores.upload_to_file_search_store(
file_search_store_name=store.name,
file="./blueprint_A3.pdf",
)
response = client.models.generate_content(
model="gemini-2.5-pro",
contents="3階の配管経路で、止水弁の位置はどこか",
config={
"tools": [{
"file_search": {
"file_search_store_names": [store.name]
}
}]
},
)
注目すべき技術的ポイントは3つある。
1. チャンク戦略がブラックボックス化される
LangChainやLlamaIndexでRAGを組んだ経験があるエンジニアなら、chunk_sizeとchunk_overlapの沼を知っているはずだ。File Searchはこれを内部で吸収する。これは「制御を失う」というデメリットでもあるが、PoC段階では速度が勝つ。一方で、リーガル文書のように章節構造を厳密に保ちたいケースでは依然として自前実装が有利だろう。
2. 引用（citation）がレスポンスに含まれる
レスポンスにはgrounding_metadataとして、どのファイルのどの部分が根拠になったかが返る。社内検索botでは「ハルシネーション対策として根拠表示が必須」というのが定石になっており、これがマネージドで提供されるのは大きい。
3. ストレージは無料、エンベディングは有料 Googleの料金体系では、ストアへの保存自体は無料、初回のインデックス生成（embedding）にトークン課金、クエリ時のretrievalは無料、というモデルとされる。100万ページ規模のドキュメント資産を一度に流し込むと初期コストが跳ねるため、対象データの優先順位付けはやはり必要だ。
実務的な注意点として、画像のretrievalは「視覚的類似」ではなく「テキストクエリ→画像内容」の検索である。つまり「この写真と似た部品の図面を探す」という画像→画像の用途には、別途CLIP系の埋め込みを併用する設計が現実的になる。
経営者・技術リーダーが次に取るべき動き
最初に手を付けるべきは、自社の「画像で眠っている情報資産」の棚卸しだ。図面、契約書のスキャンPDF、ホワイトボード写真、過去のプレゼン資料、議事録のスクリーンショット――これらはこれまで「検索不能な暗黙知」として放置されてきた領域である。
次に、PoCのスコープを「2週間・1部門・1ユースケース」に絞ること。RAGプロジェクトが失敗する最大の理由は「全社ナレッジ検索」のような巨大スコープで始めることだ。例えば「保守部の図面検索だけ」「営業部の提案書検索だけ」と切れば、ベンダーに数百万円払う案件が、シニアエンジニア2人で完結する規模になる。
ただし、機密性の高い図面や顧客情報を扱う場合、データレジデンシーとVertex AI側のCustomer-Managed Encryption Keys (CMEK)対応の確認は必須だ。Gemini API（AI Studio経由）とVertex AI経由ではデータ取り扱いポリシーが異なるため、エンタープライズ用途では後者を選ぶのが定石となる。
RAG構築の参入障壁は、また一段下がった。差別化は「どのAPIを使うか」ではなく「どのデータを、どの粒度で、誰のために検索可能にするか」というドメイン理解側に完全に移った。技術が安くなった分、ビジネス設計の重みが増している。
動画でも詳しく
動画は記事冒頭の埋め込みからフル尺で視聴できます。