GoogleのGemini API File Search、マルチモーダルRAGへ拡張――「探せる社内知」の単位がテキストから画像へ広がる

Googleは2026年5月5日、Gemini APIのFile Searchを拡張し、画像とテキストを同じFile Searchストア内で扱えるようにした。今回の主な更新は、マルチモーダル対応、カスタムメタデータによる絞り込み、ページ単位の引用の3点である。これにより、RAG、つまり検索拡張生成の対象が「文書の段落」だけでなく、図表、商品写真、スクリーンショット、科学画像、設計図のような視覚情報へ広がった。(blog.google)

File Searchはもともと、2025年11月にGemini APIへ導入されたフルマネージドのRAG機能だった。開発者が自前でファイル保存、チャンク分割、エンベディング生成、ベクトル検索、検索結果のプロンプト注入を組み合わせる代わりに、Gemini API内で一連のパイプラインを扱えるようにするものだ。初期リリース時点でも、PDF、DOCX、TXT、JSON、コードファイルなどを対象に、回答に引用を付けて検証しやすくする設計が強調されていた。(blog.google)

今回の変化の中核にあるのが、Gemini Embedding 2だ。Googleは2026年3月にこのモデルをPublic Previewとして発表し、テキスト、画像、動画、音声、ドキュメントを単一の埋め込み空間へ写像できる、Gemini API初のネイティブなマルチモーダル埋め込みモデルと説明している。さらにGoogle Developers Blogは、2026年4月末時点でGemini Embedding 2がGAになり、100以上の言語をサポートし、1回の呼び出しで最大8,192テキストトークン、6画像、120秒の動画、180秒の音声、6ページのPDFを扱えると説明している。(blog.google)

ただし、ここは切り分けて理解する必要がある。Gemini Embedding 2自体は動画・音声も含む広いマルチモーダル入力を扱えるが、Gemini APIのFile Searchドキュメントでは、現時点でFile Searchにおける音声形式と動画形式はサポートされていないと明記されている。File Searchのマルチモーダル対応は、まずテキストと画像を同じ検索ストアで扱う方向に実装されたと見るのが正確だ。画像についてはPNGとJPEGが対象で、解像度は4K×4Kピクセル以下という要件が示されている。(ai.google.dev)

技術的に重要なのは、画像をいったんキャプション化してからテキスト検索にかけるのではなく、画像をネイティブに埋め込み、テキストと同じ意味空間で検索できる点だ。従来のマルチモーダルRAGでは、OCR、画像説明生成、別々のベクトルDB、モダリティごとの検索結果統合といった前処理が必要になりがちだった。File Searchでmodels/gemini-embedding-2を指定してストアを作成すれば、同じアップロードAPIで画像を投入できるため、開発者は検索基盤の接着よりも、アプリケーションの体験設計に集中しやすくなる。(ai.google.dev)

2つ目の更新であるカスタムメタデータは、実運用ではかなり大きい。File SearchではファイルにKey-Value形式のメタデータを付与でき、たとえばauthorやyearのような属性を保存できる。クエリ時にはmetadata_filterを指定し、特定の著者、部署、製品カテゴリ、公開ステータスなどに検索範囲を絞れる。Googleの発表では、department: Legalやstatus: Finalのようなラベルを付けることで、無関係な文書のノイズを減らし、RAGの速度と精度を高められると説明されている。(ai.google.dev)

3つ目のページ単位の引用は、RAGの「答えを信じられるか」という問題に関わる。File Searchでは、回答に使われた文書部分をgrounding_metadataから確認できる。PDFのようにページを持つ文書では、retrieved_context.page_numberを通じて該当ページ番号を取得できる。また、生成時に画像チャンクが参照された場合はmedia_idが返り、モデルが参照した画像チャンクをダウンロードできる。これは、法務、医療、研究、金融、技術文書レビューのように、回答の根拠を人間が確認する必要がある用途で特に意味を持つ。(ai.google.dev)

背景として、RAGはもともと2020年の「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で広く知られるようになった考え方で、生成モデルの内部知識だけに頼らず、外部の非パラメトリックな知識ソースを検索して回答に使う。企業システムではこの外部知識が、社内規程、契約書、設計書、チケット履歴、商品カタログ、研究データなどになる。(arxiv.org)

今回の拡張は、RAGの対象が「読める情報」から「見える情報」へ広がる流れの一部でもある。たとえばAWSも2026年1月、Amazon Bedrock Knowledge Basesでマルチモーダル検索の一般提供を発表し、テキスト、画像、音声、動画をフルマネージドなRAGワークフローで検索・取得できると説明している。OpenAIのRetrieval APIも、ベクトルストア、属性フィルタ、ランキング調整、対応ファイル形式を整備しており、主要AIプラットフォームはRAGを単なるサンプル実装から、管理された検索・検証レイヤーへ押し上げている。(aws.amazon.com)

一方で、File Searchの拡張は万能化を意味しない。ドキュメント上の制限として、1ドキュメントあたりの最大ファイルサイズは100MBで、プロジェクト全体のFile Searchストア容量は利用階層ごとに上限がある。また、最適な取得レイテンシのため、各File Searchストアは20GB未満に抑えることが推奨されている。料金面では、ストレージとクエリ時のエンベディング生成は無料だが、インデックス作成時のエンベディング料金と、取得された文書トークンの通常のコンテキスト料金は発生する。(ai.google.dev)

今後の焦点は、単に「画像も検索できる」ことではなく、検索結果をどの粒度でユーザーに返し、どのように検証可能にするかに移るだろう。図表を含むPDF、製品画像と仕様書が混在するカタログ、研究画像と実験ノート、UIスクリーンショットとバグ報告のようなデータでは、テキストと画像を別々に扱うほど文脈が失われる。Gemini API File Searchの今回の更新は、その分断を少し狭めるものだ。

結論として、この発表は派手な生成モデルの性能競争というより、AIアプリケーションの土台である「検索できる記憶」の拡張である。RAGの品質は、モデルの賢さだけでなく、正しい情報を、正しい範囲から、検証可能な形で取り出せるかに大きく左右される。File Searchが画像、メタデータ、ページ引用を同じ設計の中に取り込んだことは、Gemini APIを使う開発者にとって、より現実の業務データに近いRAGを作るための実用的な一歩と言える。