Gemini API File Searchが画像RAG対応、実装要点を整理

Google が 2026年5月5日、Gemini API の File Search をマルチモーダル対応へ広げた。今回の主な更新は、画像を含む File Search、カスタムメタデータによる絞り込み、PDF などのページ単位引用だ。検索意図で言えば、「Gemini API File Search で画像RAGはできるのか」「ページ引用はどう使うのか」「既存のRAG基盤を置き換えるべきか」に答えるニュースになる。

これは派手な新モデル発表ではない。ただ、日本の開発チームや事業会社にとってはかなり実務寄りだ。理由は、RAG の失敗がモデルの賢さだけでなく、どの資料を見つけ、どの範囲に絞り、どの根拠をユーザーへ返せるかで決まるからだ。

以前このサイトでは、Gemini Embedding 2 の一般提供とマルチモーダルRAGの実装要点を取り上げた。今回の File Search 更新は、その埋め込みモデルを、開発者がすぐ使いやすい検索ツール側へ落とし込む動きとして読める。さらに Gemini Enterprise Agent Platform のような企業向けエージェント基盤や、Workspace Intelligence の管理者制御 と合わせると、Google が「モデル」ではなく「文脈を扱う基盤」を押さえに来ている流れが見える。

事実: File Searchに3つの更新が入った

Google の公式発表で確認できる事実は大きく3つある。

1つ目は、File Search が画像とテキストを同じ検索対象として扱えるようになったことだ。File Search のドキュメントでは、テキスト埋め込みには gemini-embedding-001、画像とマルチモーダル埋め込みには gemini-embedding-2 を使えると説明されている。マルチモーダル File Search では、FileSearchStore 作成時に models/gemini-embedding-2 を指定し、PNG や JPEG の画像をアップロードして検索対象にできる。

2つ目は、カスタムメタデータフィルタだ。公式ブログでは、たとえば department: Legal や status: Final のようなラベルを unstructured data に付け、問い合わせ時に検索範囲を絞れると説明している。実務ではここがかなり重要で、単に「似ている資料を探す」だけなら検索ノイズが増えやすい。部門、版、顧客、公開範囲、文書状態で絞れると、RAG の答えが現場の文脈に合いやすくなる。

3つ目は、引用情報の強化だ。File Search は応答に grounding metadata を返し、PDF のようにページを持つ資料では、該当情報がどのページにあるかを page_number として扱える。画像チャンクを参照した場合は media_id も返せる。つまり、ユーザーに「どの資料のどの部分を根拠にしたのか」を示しやすくなる。

ただし、ここで事実と期待を分ける必要がある。ページ引用は検証を助けるが、監査を自動で完了させる魔法ではない。引用が正しいか、権限上その資料を見せてよいか、最終判断に使ってよいかは、アプリ側の設計と運用で決める必要がある。

分析: RAGの競争軸が「作る」から「運用する」へ移っている

今回の更新で重要なのは、Google が File Search を単なるサンプル用ツールではなく、RAG の運用部品に近づけている点だ。

初期のRAGは、PDFを分割し、ベクトルDBへ入れ、質問時に上位チャンクを取ってモデルへ渡す構成が中心だった。これでもデモは作れる。しかし本番ではすぐ壁に当たる。画像や図表が弱い。PDF のどのページか分からない。古い版と最新の版が混ざる。法務資料と営業資料が同じ検索空間に入り、回答がぶれる。ユーザーは「それはどこに書いてあるのか」と聞く。

File Search の今回の更新は、この壁に直接向いている。画像を検索できることは、製品写真、UIスクリーンショット、設計図、店舗棚割り、検査画像のようなデータを扱うチームに効く。メタデータフィルタは、検索範囲の誤爆を減らす。ページ引用と media_id は、ユーザーが根拠へ戻る導線を作る。

ここは Gemini のファイル直接生成 ともつながる。生成AIが文書を作るだけなら、最後は人間が整えるだけで済む。しかし、社内資料を検索し、根拠を示し、そこから報告書や提案書へ落とすなら、検索基盤の品質がそのまま生成物の品質になる。Google は Gemini API と Gemini アプリ、Workspace、Cloud のあいだで、この「探して、根拠を示し、作る」流れを少しずつ詰めている。

日本の開発チームが使いやすい領域

日本で相性が良いのは、テキストだけのFAQより、画像やPDFが混ざる業務だと思う。

たとえば製造業では、検査記録、製品画像、作業手順書、過去不具合報告が別々に残りがちだ。File Search が画像と文書を同じ検索対象にできるなら、「この見た目に近い不具合と関連する手順書を出す」といった問い合わせに近づける。もちろん最終判断は人間が行うべきだが、探す時間は短くできる。

小売やECでも使い道はある。商品画像、商品説明、販促資料、問い合わせ履歴を組み合わせ、似た見た目の商品や、過去の掲載素材を自然文で探せるようにする。画像のファイル名やタグ付けだけに頼らない検索は、素材量が増えるほど効いてくる。

社内ナレッジ検索では、ページ引用が特に重要だ。稟議、契約、規程、マニュアルをRAGに入れると、ユーザーは回答の正しさだけでなく、根拠ページを確認したくなる。File Search がページ情報を返せるなら、「AIが言った」ではなく「このPDFのこのページにある」という導線を作りやすい。

一方で、最初から全社横断検索を狙うべきではない。日本企業では共有フォルダの権限が長年の運用で複雑になっていることが多い。File Search の技術が便利でも、社内の閲覧権限、文書分類、削除ルール、ログ保管が曖昧なままだと、検索体験よりリスクが先に大きくなる。

実装時に先に決めるべきこと

まず決めるべきは、検索対象の単位だ。File Search store は文書埋め込みを入れるコンテナとして使う。部署別、顧客別、プロダクト別、公開範囲別のどれで store を分けるのかを先に決めないと、あとで権限や削除の設計が苦しくなる。

次に、メタデータの設計だ。department や status のようなラベルは便利だが、最初に増やしすぎると運用されない。日本の現場では、最低限 department、document_type、confidentiality、version_status、effective_date あたりから始めるのが現実的だろう。重要なのは、RAGの精度改善のためだけでなく、あとから「なぜこの資料を検索対象にしたのか」を説明できるようにすることだ。

3つ目は、引用の見せ方だ。ページ引用をユーザーに出す場合、ページ番号だけを出しても不十分なことがある。資料名、版、更新日、アクセス権、抜粋範囲を一緒に出せるUIにしないと、ユーザーは結局PDFを開いて探し直すことになる。逆に、根拠への導線がうまく作れれば、RAG は「便利な要約」から「確認しながら使える業務検索」へ近づく。

4つ目はコストだ。File Search のドキュメントでは、ファイル保存と問い合わせ時の埋め込み生成は無料で、最初にファイルを索引化するときの埋め込み生成と通常のモデル入出力トークンに課金されると説明されている。これは試しやすい一方、初回インデックス時の対象量、更新頻度、再インデックスの設計を雑にするとコスト見積もりがぶれる。特に画像が混ざる場合は、対象ファイルを何でも入れるのではなく、業務価値のある範囲から始めたい。

注意点: 画像対応は万能ではない

今回の更新は大きいが、制約もある。File Search のドキュメントでは、現時点で音声と動画形式はサポートされないと説明されている。また、画像ファイルは PNG/JPEG、解像度は最大 4K x 4K、1リクエスト最大6画像という条件が示されている。

つまり、動画マニュアルや録音をそのまま File Search へ投げる構成ではない。動画は必要なフレームやサムネイルを切り出す、音声は文字起こしを用意する、といった前処理はまだ残る。ここを誤解すると、「マルチモーダル対応」という言葉だけが先に立ち、実装時に期待とずれる。

また、検索対象が画像になるほど、権利や個人情報の確認も必要になる。現場写真、店舗写真、顧客提出資料には、人の顔、住所、契約情報、内部設備が写り込むことがある。日本の企業利用では、技術的に検索できるかより先に、どの画像を索引化してよいかを決めるべきだ。

まとめ

Gemini API File Search のマルチモーダル対応は、RAG を「テキスト文書検索」から「画像やPDFを含む検証可能な業務検索」へ近づける更新だ。

日本の開発者やプロダクトチームにとっての論点は、すぐ既存のRAGを置き換えるかではない。まず、画像が検索品質に効く業務、メタデータで検索範囲を安全に絞れる業務、ページ引用がユーザーの確認行動を短縮する業務を見つけることだ。その上で、小さな store、少ないメタデータ、明確な引用UIから始めるのが堅い。

Google は Gemini Embedding 2、File Search、Gemini Enterprise Agent Platform、Workspace Intelligence を通じて、モデル単体ではなく文脈基盤を積み上げている。今回の発表は、その中でもかなり開発者が直接触れる層の更新だ。RAGを本番運用に近づけたいチームほど、早めに設計パターンを検証する価値がある。

出典

• Gemini API File Search is now multimodal: build efficient, verifiable RAG - Google, 2026-05-05
• File Search - Google AI for Developers
• Release notes - Google AI for Developers
• Gemini Developer API pricing - Google AI for Developers