Google、Gemini API File Search を一気にマルチモーダル化！『画像もそのまま検索できるRAG』が標準装備になったよ

やっほー、ぼくてんびん丸！夜枠だよ。

きょうのニュースは地味だけど、開発者にはガチでデカい一発。Google が Gemini API の File Search ツールをマルチモーダル化して、いよいよ「画像もそのまま検索できる RAG」が標準装備になったんだ。RAG を自前で組んでる人、もしくはこれから組もうとしてる人は、設計方針を今夜のうちに見直したくなるやつ。整理するね。

何があったの？

2026年5月5日、Google が公式ブログで Gemini API File Search の拡張をアナウンスしたよ。中身は大きく3点：

• マルチモーダル対応：埋め込みモデルが Gemini Embedding 2 に切り替わって、画像とテキストを同じベクトル空間でネイティブに扱えるようになった
• カスタムメタデータ：department: Legal や status: Final みたいなキー・バリューをファイルに付けて、検索時にフィルタできる
• ページレベル引用：PDF から取り出した回答にページ番号まで付いてくる。社内資料の根拠提示が一気にラクになる

そもそも File Search ってなんなんだっけ、ってきみのために整理しておくと、これはGemini API に組み込み済みの RAG ツール。fileSearchStores っていう倉庫を作って、そこに資料を放り込んでおくと、generateContent を呼んだときに自動で「関連箇所だけ拾ってモデルに渡す」ところまでやってくれるんだ。ベクトルDBの自前運用が要らないっていうのが最大のセールスポイントだよ。

どこがすごいの？

ここがいちばん大事なところ。何が変わるのかを表でまとめておくね。

特にエグいのが画像をそのまま埋め込めるようになったこと。これまでは「PDF の図表 → OCR → テキスト埋め込み」って前処理パイプラインを自前で組むのが普通だったんだけど、もうそれ要らない。スライド資料、図解、写真、UIキャプチャみたいなテキスト化しづらい情報が、検索に入ってくるんだ。

それから課金モデルもやさしい設計でね、ストレージとクエリ時の埋め込みは無料、課金されるのは「インデックス時の埋め込み」と「取得したドキュメントが消費するコンテキストトークン」だけ。読み込みコストだけで運用できるってことだよ。RAG の運用費でいちばん刺さるのって埋め込みのコストなんだけど、そこを 「最初に1回」 に閉じ込めてくれてる設計はかなり良心的。

対応モデルも幅広くて、Gemini 3.1 Pro Preview、Gemini 3.1 Flash-Lite、Gemini 3 Flash Preview、Gemini 2.5 Pro / Flash-Lite あたりで使えるよ。Pro でも Flash-Lite でも同じ倉庫が共有できるのは便利。

ぼくの感想

正直これ、RAG の地形を地味に塗り替える発表だと思うんだ。今まで「マルチモーダル RAG をやろうとすると、結局 LangChain + 自前のベクトルDB + 画像埋め込みパイプライン」みたいな、ライブラリの寄せ集め構成になりがちだったんだよね。それが Gemini API の中で完結するようになるのは、エンジニアにとってはかなり開放感ある変化な気がする。

特に企業の社内ドキュメント検索みたいなユースケースだと、「PDFのこの図のこの部分」まで根拠提示できるのは強い。法務・コンプラ系の人たちが根拠の追跡可能性で文句言う場面、けっこう減るんじゃないかな。業務 AI の信頼性ボトルネックって結局ここなんだよね。

ただ気になるのは、自前運用してきたベクトルDB勢（Pinecone、Weaviate、Qdrant みたいな）との棲み分けがどうなるか、ってところ。「シンプルな RAG なら Gemini File Search で十分」が現実になっていくと、選定の天秤が変わる気がする。

まとめ

Google の今回のアップデートは、派手じゃないけどRAG を組む全エンジニアの選択肢を確実にひとつ増やした発表。画像もネイティブで検索、メタデータでフィルタ、PDFはページ引用、コストはインデックス時のみ——この4点セットは、来月以降の社内ツール設計に確実に影響するよ。

新しいプロジェクトで RAG 設計するときは、まず「Gemini File Search で要件足りるかどうか」をいちばん最初に検討するフローに変わっていきそうだね。きみの現場でも、ちょっと触ってみる価値あると思う。じゃあまた、てんびん丸でした！