RAG(検索拡張生成)を実装したいとき、ベクトルデータベースを選んで、埋め込みモデルを決めて、チャンク化のロジックを書いて...って、めちゃくちゃ面倒じゃないですか?
2025年11月6日、GoogleがリリースしたGemini File Search APIは、この面倒な作業をすべて丸投げできる革命的なAPIです。ファイルをアップロードするだけで、あとは全部Googleが管理してくれます。
公式ブログ: Introducing the File Search Tool in Gemini API
来春からデータサイエンティストとして働く予定の技術オタク。
『知りたい』気持ちで質問を止められない、好奇心旺盛な学生。
File Search APIって、何がすごいの?ファイルを検索できるだけ?
いや、それがすごいんだ!これは単なるファイル検索じゃなくて、完全に管理されたRAGシステムなんだよ。
RAGって何?聞いたことあるけど、よくわかんない...
RAGはRetrieval Augmented Generation(検索拡張生成)の略で、LLMに外部の知識を与える技術なんだ。例えば、「うちの会社のマニュアル全部読んで質問に答えて」みたいなことをChatGPTにやらせるとき、そのマニュアルをLLMに渡す仕組みがRAGってわけ。
へー!でも、それって普通にファイルをアップロードすれば良いんじゃないの?
実はそう簡単じゃないんだ。LLMには一度に読み込める文字数に限界があるから、100ページのマニュアルを全部渡すことはできない。だから、質問に関係ありそうな部分だけを検索して渡す必要があるんだよ。
あー...確かに。じゃあ、どうやって関係ある部分を探すの?
そこで必要になるのが、ベクトル検索なんだ。文章を数値(ベクトル)に変換して、意味的に似ている文章を高速に探す技術だよ。
うわー、難しそう...自分で実装するのは大変そうだね
そう!従来のRAGを実装するには、こんな作業が必要だったんだ:
- ファイルを適切なサイズに分割(チャンク化)
- 各チャンクをベクトルに変換(埋め込み生成)
- ベクトルデータベースに保存
- ユーザーの質問もベクトル化して検索
- 検索結果をLLMに渡す
でも、File Search APIなら、この全部をGoogleがやってくれるんだよ。
え!?全部やってくれるの!?
File Search APIの仕組み
File Search APIは、セマンティック検索っていう技術を使ってるんだ。これはキーワード検索じゃなくて、意味的な類似性で検索する方法なんだよ。
セマンティック検索...?キーワード検索とどう違うの?
いい質問だね!例えば、「Pythonでファイルを開く方法」って検索したときを考えてみよう。
- キーワード検索: 「Python」「ファイル」「開く」っていう単語が入ってる文章を探す
- セマンティック検索: 「Pythonでファイル操作する」「open関数の使い方」みたいな、意味的に関連する文章も探す
あー!完全一致じゃなくて、意味が似てれば引っかかるんだ!
そうそう、まさにそういうこと。だから、マニュアルに「ファイルを開く」って書いてなくても、「ファイル読み込み」とか「データの取得」みたいな関連情報も見つけてくれるんだ。
ファイルのアップロード方法
File Search APIには、2つのアップロード方法があるんだ。
2つもあるの?どう違うの?
1つ目は直接アップロード。uploadToFileSearchStoreっていうAPIを使って、ファイルを一発でストアに送り込む方法だよ。
なるほど。もう1つは?
2つ目は段階的アップロード。まずFiles APIでファイルをアップロードしておいて、後からimportFileでストアに追加する方法なんだ。
なんで2つも方法があるの?使い分けるの?
段階的アップロードは、同じファイルを複数のストアで使いたいときに便利なんだ。一度アップロードしておけば、別のストアにも追加できるからね。
あ、使い回しができるんだね!
サポートされているファイル形式
どんなファイルがアップロードできるの?PDFとか?
PDFはもちろん、Word、Excel、PowerPoint、JSON、SQL、プログラミング言語のファイルまで、50種類以上のフォーマットに対応してるんだ。
50種類!?めっちゃ多いじゃん!
具体的には、こんな感じだよ:
- ドキュメント: PDF、Word(.docx)、PowerPoint(.pptx)、Excel(.xlsx)
- テキスト: Markdown、HTML、プレーンテキスト
- データ: JSON、CSV、SQL
- プログラミング: Python、JavaScript、Java、C++など
プログラミングのコードも読めるんだ!ドキュメント化されてないコードを質問攻めにできそう!
そうそう、まさにそういう使い方が想定されてるんだ。コードベース全体をアップロードして、「この関数は何してるの?」みたいな質問ができる。
使えるモデル
File Search APIって、どのGeminiモデルで使えるの?
現在はGemini 2.5 ProとGemini 2.5 Flashの2つで使えるんだ。
ProとFlash...どう違うの?
Proは高性能モデルで、複雑な質問や詳細な分析が得意。Flashは高速で安価なモデルで、シンプルな質問に素早く答えるのが得意なんだ。
じゃあ、ちょっとした質問ならFlash、複雑な分析ならProって感じ?
その通り!用途に応じて使い分けるといいよ。
制限事項とコスト
便利そうだけど、制限とかあるの?
もちろんあるよ。主な制限はこんな感じ:
| 項目 | 制限 |
|---|---|
| 1ファイルのサイズ上限 | 100 MB |
| ストレージ容量(無料) | 1 GB |
| プロジェクトあたりのストア数 | 最大10個 |
| 推奨ストアサイズ | 20GB未満 |
100MBって結構大きいね!普通のPDFなら余裕そう
そうだね。ただ、無料枠のストレージは1GBだから、大量のファイルを扱う場合は有料プランが必要になるかも。
お金かかるの?どのくらい?
料金体系はこんな感じだよ:
- ファイルをインデックス化するとき(初回のみ): $0.15 / 100万トークン
- ストレージ: 無料
- 検索時の埋め込み生成: 無料
- 検索結果をLLMに渡すとき: 通常のコンテキストトークンとして課金
えっ、ストレージと検索が無料なの!?めっちゃ良心的じゃん!
そう、初回のインデックス化だけお金がかかって、あとはLLMを使うときの通常料金だけなんだ。かなりコスト効率がいいよね。
100万トークンって、どのくらいの文章量なの?
だいたい日本語で50万文字くらいかな。普通の小説が10万文字くらいだから、小説5冊分って感じ。
それで$0.15!?安すぎない!?
実際の使い方
じゃあ、実際にどうやって使うの?
基本的な流れはこんな感じだよ:
- File Search Storeを作成: データを保存する場所を用意
- ファイルをアップロード: PDFや文書をアップロード
- 検索クエリを投げる: 自然言語で質問する
- 結果を取得: 関連する情報がLLMに渡されて回答が返ってくる
File Search Storeって何?
File Search Storeは、アップロードしたファイルを保存・管理する「箱」みたいなものだよ。プロジェクトごとに最大10個まで作れるんだ。
なるほど。プロジェクトごとに分けられるんだね
そう。例えば、「製品マニュアル用」「社内規定用」「技術ドキュメント用」みたいに分けて管理できるんだ。
チャンク化のカスタマイズ
ちなみに、チャンク化の設定もカスタマイズできるんだよ。
チャンク化って何?
チャンク化は、大きなファイルを小さな「かたまり」に分割する処理のことだよ。LLMには一度に読み込める量に限界があるから、適切なサイズに分けるんだ。
どのくらいのサイズに分けるの?
それが、カスタマイズできるんだ。デフォルトでは自動で良い感じに分けてくれるけど、必要なら「最大トークン数」と「オーバーラップトークン数」を設定できる。
オーバーラップって何?
オーバーラップは、隣り合うチャンクで重複する部分のことだよ。例えば、文章の途中で切れちゃうと意味が分からなくなるから、ちょっと重複させるんだ。
あー!文脈が途切れないようにするんだね!
実際の活用例
File Search API、実際にどんなことに使えるの?
色々な活用例があるけど、代表的なのはこんな感じだよ:
1. サポートボット
カスタマーサポートのチャットボットに使えるんだ。製品マニュアルや FAQをアップロードしておけば、ユーザーの質問に自動で答えてくれる。
マニュアル読まなくても、聞けば答えてくれるってこと!?
そう!しかも、マニュアルの該当ページも引用(citation)として返してくれるから、「詳しくはこちら」みたいな案内もできるんだ。
2. 社内ナレッジアシスタント
社内の規定や議事録、過去のプロジェクト資料を全部アップロードしておけば、「この件のルールってどうなってたっけ?」みたいな質問にすぐ答えられる。
社内Googleみたいな感じ!?
まさに!キーワード検索と違って、セマンティック検索だから、「育休の申請方法」って聞いたら「産休・育児休暇制度について」みたいなドキュメントも引っかかるんだ。
3. コンテンツプラットフォーム
教育プラットフォームや記事サイトにも使えるよ。大量の記事やコースをアップロードしておけば、ユーザーが自然言語で質問できる。
「JavaScriptの配列操作について教えて」って聞いたら、関連する記事を教えてくれるんだね!
そうそう!しかも、複数の記事から情報を統合して、オリジナルの回答を生成してくれるんだ。
メタデータフィルタリング
もう一つ便利な機能として、メタデータフィルタリングがあるんだ。
メタデータって何?
メタデータは、ファイルに関する情報のことだよ。例えば、「作成日」「著者」「部署」「カテゴリ」みたいな属性を付けられるんだ。
それで何ができるの?
検索するときに、「2024年以降の技術記事だけ検索」とか「営業部のドキュメントだけ検索」みたいにフィルタリングできるんだ。
お!古い情報を除外できるんだね!それは便利!
従来のRAG実装との比較
ねえ、従来のRAG実装と比べて、どのくらい楽になるの?
めちゃくちゃ楽になるよ。比較してみようか:
従来のRAG実装
従来のRAG実装では、こんな作業が必要だったんだ:
- ベクトルデータベースの選定: Pinecone、Weaviate、ChromaDBなどから選ぶ
- 埋め込みモデルの選定: OpenAI、Cohere、オープンソースモデルなど
- チャンク化ロジックの実装: ファイルを適切に分割するコードを書く
- パイプラインの構築: データの流れを全部自分で制御
- インフラの管理: データベースのホスティング、スケーリング
- コストの最適化: 各サービスの料金体系を比較して選定
うわー...めっちゃ大変そう...
File Search APIの場合
File Search APIなら、こうなるんだ:
- ファイルをアップロード:
uploadToFileSearchStoreを呼ぶだけ - 検索: Gemini APIを呼ぶときにストアIDを指定するだけ
- 以上!
えっ!?それだけ!?
そう、それだけ。ベクトルデータベースも、埋め込みモデルも、チャンク化も、全部Googleが勝手にやってくれるんだ。
これはすごい!開発時間がめっちゃ短縮されそう!
注意点と制約
便利すぎて怖いんだけど、何か注意点とかある?
いくつかあるよ。まず、カスタマイズ性が低いこと。
どういうこと?
例えば、自前でRAGを組むと、埋め込みモデルを自由に選べたり、チャンク化のロジックを細かく調整できたりする。でもFile Search APIは、Googleが決めた方式に従うしかないんだ。
なるほど。便利さとカスタマイズ性のトレードオフってことか
そう。他にも、Gemini APIでしか使えないっていう制約もある。OpenAIのGPTとかClaudeとは使えないんだ。
あー、Gemini専用なんだ。他のモデルも使いたいときは自前で組むしかないのか
そういうこと。あと、ストレージ容量の制限もあるから、めちゃくちゃ大量のデータを扱いたい場合は、有料プランが必要になるかもね。
まとめ
File Search API、めっちゃ便利そうだね!
そうだね!最後にポイントをまとめておこう:
- 完全管理型RAG: ファイル保存、チャンク化、埋め込み、検索を全自動
- 幅広いフォーマット対応: PDF、Word、コードなど50種類以上
- セマンティック検索: キーワードじゃなく意味で検索
- コスト効率が良い: 初回インデックスのみ課金、ストレージと検索は無料
- 簡単実装: 複雑なパイプラインを自前で組む必要なし
でも、カスタマイズ性は低いし、Gemini専用なんだよね
その通り。だから、使い分けが大事なんだ:
- File Search APIが向いてる: プロトタイプ作成、シンプルな用途、開発速度重視
- 自前RAGが向いてる: 細かいカスタマイズが必要、複数のLLMを使いたい、特殊な要件がある
なるほど!まずはFile Search APIで試してみて、必要になったら自前RAGに移行するのもありだね!
そうそう、それがベストプラクティスだと思うよ。まずは手軽に試してみて、どんなことができるか体験してみるといい。
よし!早速試してみよう!教えてくれてありがとう!
どういたしまして!良いRAGライフを!