◈ API / SDK/2026-03-27上級

Gemini File Search API — RAGなしで自社データに基づくAI応答を構築する

ベクトル DB や RAG パイプラインを組まずに自社ドキュメントへのグラウンディングを実現する Gemini File Search API の解説です。アーキテクチャの仕組み、Python と Node.js の本番実装、コスト最適化、社内ナレッジベースへの応用まで扱います。

gemini¹¹⁵file-search-apigrounding⁸ rag²¹ enterprise³ document-ai² api¹²

✦ プレミアム記事

取り組みの背景 — File Search API が変えるドキュメント活用の常識

2026年3月、GoogleはGemini APIに File Search API をパブリックプレビューとして公開しました。これは、開発者が自社のドキュメントやデータをGeminiモデルに直接グラウンディングソースとして提供し、そのデータに基づいた正確な応答を生成できる画期的な機能です。

従来、自社データに基づくAI応答を構築するには、ベクトルデータベースの構築、エンベディングパイプラインの整備、チャンク分割戦略の最適化など、いわゆるRAG（Retrieval-Augmented Generation）パイプラインの設計・運用が必要でした。File Search APIはこの複雑さを大幅に削減し、ファイルをアップロードするだけでGeminiがドキュメントの内容を理解し、質問に正確に回答できるようにします。

この記事の対象読者は以下のような方です。

RAGパイプラインの構築・運用コストに悩んでいるエンジニア
社内ドキュメント検索やカスタマーサポートAIを構築したい開発者
Gemini APIを本番環境で活用しているチーム

File Search API のアーキテクチャと仕組み

従来のRAGとFile Search APIの根本的な違い

従来のRAGアプローチでは、開発者が以下のパイプラインを自前で構築する必要がありました。

ドキュメントのチャンク分割
エンベディングモデルによるベクトル化
ベクトルDBへの格納（Pinecone、ChromaDB、pgvector等）
クエリ時のセマンティック検索
検索結果をプロンプトに注入
LLMによる応答生成

File Search APIはこの1〜5のプロセスをGoogle側がフルマネージドで処理します。開発者はファイルをアップロードし、質問するだけです。

# 従来のRAGパイプライン（簡略版）
# チャンク分割 → エンベディング → ベクトルDB → 検索 → プロンプト注入
# ↑ これらすべてを自前で構築・運用する必要があった
 
# File Search API のアプローチ
# ファイルアップロード → 質問 → 回答（Googleが内部で最適な検索を実行）

内部処理フロー

File Search APIの内部では、以下の処理が自動的に行われています。

ドキュメント解析: アップロードされたファイル（PDF、テキスト、HTML等）を解析し、構造を理解
インテリジェントチャンキング: ドキュメントの論理構造に基づいた最適なチャンク分割
マルチモーダルインデキシング: テキストだけでなく、図表やレイアウト情報も含めたインデックス構築
セマンティック検索: クエリに対して最も関連性の高いチャンクを高精度で検索
コンテキスト注入: 検索結果をモデルのコンテキストに自動的に注入

この仕組みにより、開発者はインフラ構築に時間を費やすことなく、ビジネスロジックの実装に集中できます。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦File Search APIの仕組みとRAGとの違いを体系的に理解できる

✦Python/Node.jsの本番実装コードで即座にプロジェクトに導入できる

✦コスト最適化・セキュリティ・スケーリングの実践的なノウハウを習得できる

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

Python での本番実装

環境セットアップ

まず、Google AI Python SDKの最新バージョンをインストールします。

# pip install google-genai>=1.5.0
 
import os
from google import genai
from google.genai import types
 
# クライアント初期化
client = genai.Client(api_key=os.environ["YOUR_GEMINI_API_KEY"])

ファイルアップロードとコーパス作成

File Search APIでは、まず**コーパス（Corpus）**を作成し、そこにファイルを追加します。コーパスは検索対象となるドキュメントの論理的なグループです。

# コーパスの作成
corpus = client.corpora.create(
    display_name="社内技術ドキュメント",
    description="プロダクトの技術仕様書・API仕様・運用マニュアル"
)
print(f"コーパスID: {corpus.name}")
# 出力例: corpora/my-corpus-abc123
 
# ファイルのアップロード
# 対応形式: PDF, TXT, HTML, Markdown, CSV, JSON
uploaded_file = client.files.upload(
    path="./docs/api-specification-v3.pdf",
    config=types.UploadFileConfig(
        display_name="API仕様書 v3"
    )
)
print(f"ファイルID: {uploaded_file.name}")
 
# コーパスにファイルを追加
document = client.corpora.documents.create(
    parent=corpus.name,
    document=types.Document(
        display_name="API仕様書 v3",
        parts=[types.Part(file_data=types.FileData(
            file_uri=uploaded_file.uri
        ))]
    )
)

グラウンディング付きクエリの実行

コーパスにファイルを追加したら、groundingパラメータを使って質問を投げます。

# File Search によるグラウンディング付き応答
response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents="API v3で追加された認証方式の変更点を教えてください",
    config=types.GenerateContentConfig(
        tools=[types.Tool(
            retrieval=types.Retrieval(
                source=types.GroundingSource(
                    corpus=types.CorpusSource(
                        corpus=corpus.name
                    )
                )
            )
        )],
        temperature=0.2,  # グラウンディング時は低めの温度を推奨
    )
)
 
print(response.text)
 
# グラウンディングメタデータの確認
if response.candidates[0].grounding_metadata:
    metadata = response.candidates[0].grounding_metadata
    for chunk in metadata.grounding_chunks:
        print(f"参照元: {chunk.retrieved_context.title}")
        print(f"関連度: {chunk.retrieved_context.relevance_score}")

バッチファイル処理の実装

複数のドキュメントを効率的にコーパスに追加するバッチ処理の実装例です。

import asyncio
from pathlib import Path
from typing import List
 
async def batch_upload_documents(
    client: genai.Client,
    corpus_name: str,
    file_paths: List[str],
    max_concurrent: int = 5
) -> dict:
    """
    複数ファイルを並行アップロードする
    
    Args:
        client: Gemini APIクライアント
        corpus_name: コーパスのリソース名
        file_paths: アップロードするファイルパスのリスト
        max_concurrent: 最大同時アップロード数
    
    Returns:
        {"success": [...], "failed": [...]}
    """
    semaphore = asyncio.Semaphore(max_concurrent)
    results = {"success": [], "failed": []}
    
    async def upload_single(path: str):
        async with semaphore:
            try:
                file_name = Path(path).stem
                uploaded = client.files.upload(
                    path=path,
                    config=types.UploadFileConfig(
                        display_name=file_name
                    )
                )
                client.corpora.documents.create(
                    parent=corpus_name,
                    document=types.Document(
                        display_name=file_name,
                        parts=[types.Part(file_data=types.FileData(
                            file_uri=uploaded.uri
                        ))]
                    )
                )
                results["success"].append(path)
                print(f"✅ {file_name}")
            except Exception as e:
                results["failed"].append({"path": path, "error": str(e)})
                print(f"❌ {path}: {e}")
    
    tasks = [upload_single(p) for p in file_paths]
    await asyncio.gather(*tasks)
    return results
 
# 使用例
# docs = list(Path("./company-docs").glob("**/*.pdf"))
# results = asyncio.run(batch_upload_documents(client, corpus.name, docs))
# print(f"成功: {len(results['success'])}, 失敗: {len(results['failed'])}")

Node.js / TypeScript での実装

サーバーサイドJavaScriptでの実装パターンも見ていきましょう。

import { GoogleGenAI } from "@google/genai";
 
const ai = new GoogleGenAI({ apiKey: process.env.YOUR_GEMINI_API_KEY });
 
// コーパス作成
async function createSearchableCorpus(
  displayName: string,
  files: { path: string; name: string }[]
) {
  // コーパスの作成
  const corpus = await ai.corpora.create({
    displayName,
    description: `File search corpus: ${displayName}`,
  });
 
  // ファイルの並行アップロード
  const uploadPromises = files.map(async (file) => {
    const uploaded = await ai.files.upload({
      path: file.path,
      config: { displayName: file.name },
    });
 
    await ai.corpora.documents.create({
      parent: corpus.name,
      document: {
        displayName: file.name,
        parts: [{ fileData: { fileUri: uploaded.uri } }],
      },
    });
 
    return { name: file.name, status: "success" };
  });
 
  const results = await Promise.allSettled(uploadPromises);
  return { corpus, results };
}
 
// グラウンディング付きクエリ
async function queryWithFileSearch(
  corpusName: string,
  question: string
) {
  const response = await ai.models.generateContent({
    model: "gemini-2.5-pro",
    contents: question,
    config: {
      tools: [{
        retrieval: {
          source: {
            corpus: { corpus: corpusName }
          }
        }
      }],
      temperature: 0.2,
    },
  });
 
  return {
    answer: response.text,
    sources: response.candidates?.[0]?.groundingMetadata
      ?.groundingChunks?.map((chunk) => ({
        title: chunk.retrievedContext?.title,
        score: chunk.retrievedContext?.relevanceScore,
      })),
  };
}

本番環境でのコスト最適化戦略

File Search APIを本番運用する際、コストを最適化するための重要な戦略を解説します。

コーパスの設計原則

コーパスは目的別に分割することで、検索精度とコストの両方を最適化できます。

# ❌ 悪い例: すべてのドキュメントを1つのコーパスに入れる
# → 検索範囲が広すぎて精度が下がり、トークン消費も増加
 
# ✅ 良い例: 目的別にコーパスを分離
corpora = {
    "technical": client.corpora.create(
        display_name="技術仕様書",
        description="API仕様・設計書・アーキテクチャドキュメント"
    ),
    "support": client.corpora.create(
        display_name="カスタマーサポート",
        description="FAQ・トラブルシューティング・利用ガイド"
    ),
    "legal": client.corpora.create(
        display_name="法務ドキュメント",
        description="利用規約・プライバシーポリシー・契約書テンプレート"
    ),
}
 
# クエリの種類に応じて適切なコーパスを選択
def route_query(question: str) -> str:
    """質問の内容からルーティング先のコーパスを決定"""
    routing_response = client.models.generate_content(
        model="gemini-2.5-flash",  # ルーティングは軽量モデルで
        contents=f"""以下の質問を分類してください。
        カテゴリ: technical, support, legal
        質問: {question}
        カテゴリ名のみ回答:""",
        config=types.GenerateContentConfig(temperature=0.0)
    )
    return routing_response.text.strip()

コンテキストキャッシュとの併用

頻繁にアクセスされるコーパスは、コンテキストキャッシュと組み合わせることでコストをさらに削減できます。

# 高頻度アクセスのコーパスにはキャッシュを活用
cached_content = client.caches.create(
    model="gemini-2.5-pro",
    config=types.CreateCachedContentConfig(
        display_name="技術仕様書キャッシュ",
        contents=[
            types.Content(
                role="user",
                parts=[types.Part(text="以下の技術仕様書を参照してください。")]
            )
        ],
        tools=[types.Tool(
            retrieval=types.Retrieval(
                source=types.GroundingSource(
                    corpus=types.CorpusSource(
                        corpus=corpora["technical"].name
                    )
                )
            )
        )],
        ttl="3600s",  # 1時間キャッシュ
    )
)
 
# キャッシュを使った低コストクエリ
response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents="認証トークンの有効期限はどこで設定しますか？",
    config=types.GenerateContentConfig(
        cached_content=cached_content.name
    )
)

コスト比較: RAG vs File Search API

項目	従来のRAG	File Search API
インフラ構築	ベクトルDB + エンベディングパイプライン（月額$50〜500+）	不要（API料金のみ）
エンベディング処理	自前で実行（トークン課金）	Google側で自動処理
運用保守	インデックス更新・監視が必要	ファイル追加/削除のみ
検索精度チューニング	チャンクサイズ・検索パラメータの調整が必要	自動最適化
初期開発工数	2〜4週間	1〜3日

セキュリティとアクセス制御

本番環境でFile Search APIを使用する際のセキュリティ設計を扱います。

APIキーとサービスアカウントの管理

# 本番環境ではサービスアカウントを使用
# 環境変数にAPIキーを設定（コードに直接書かない）
import os
 
api_key = os.environ.get("YOUR_GEMINI_API_KEY")
if not api_key:
    raise ValueError("GEMINI_API_KEY environment variable is not set")
 
client = genai.Client(api_key=api_key)
 
# Vertex AI 経由の場合はサービスアカウント認証
# from google.auth import default
# credentials, project = default()
# client = genai.Client(
#     vertexai=True,
#     project=project,
#     location="us-central1",
#     credentials=credentials
# )

コーパスレベルのアクセス制御

コーパスごとにアクセス権限を設定し、機密性の高いドキュメントを適切に保護します。

# 本番環境でのコーパス管理クラス
class SecureCorpusManager:
    def __init__(self, client: genai.Client):
        self.client = client
        self._corpus_registry = {}
    
    def create_corpus(
        self,
        name: str,
        description: str,
        access_level: str = "internal"
    ):
        """アクセスレベル付きコーパス作成"""
        corpus = self.client.corpora.create(
            display_name=f"[{access_level.upper()}] {name}",
            description=description
        )
        self._corpus_registry[name] = {
            "corpus": corpus,
            "access_level": access_level
        }
        return corpus
    
    def query(
        self,
        corpus_name: str,
        question: str,
        user_role: str = "viewer"
    ) -> str:
        """ロールベースのクエリ実行"""
        entry = self._corpus_registry.get(corpus_name)
        if not entry:
            raise ValueError(f"コーパス '{corpus_name}' が見つかりません")
        
        # アクセスレベルチェック
        access = entry["access_level"]
        if access == "confidential" and user_role not in ("admin", "manager"):
            raise PermissionError(
                f"コーパス '{corpus_name}' へのアクセス権がありません"
            )
        
        response = self.client.models.generate_content(
            model="gemini-2.5-pro",
            contents=question,
            config=types.GenerateContentConfig(
                tools=[types.Tool(
                    retrieval=types.Retrieval(
                        source=types.GroundingSource(
                            corpus=types.CorpusSource(
                                corpus=entry["corpus"].name
                            )
                        )
                    )
                )],
                temperature=0.2,
            )
        )
        return response.text

実践ユースケース: 社内ナレッジベースアシスタント

ここまでの知識を統合して、社内ナレッジベースアシスタントの完全な実装例を示します。

import os
import logging
from dataclasses import dataclass
from typing import Optional, List
from google import genai
from google.genai import types
 
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
 
@dataclass
class SearchResult:
    answer: str
    sources: List[dict]
    confidence: float
    corpus_used: str
 
class KnowledgeBaseAssistant:
    """社内ナレッジベースAIアシスタント"""
    
    def __init__(self):
        self.client = genai.Client(
            api_key=os.environ["YOUR_GEMINI_API_KEY"]
        )
        self.corpora = {}
        self.model = "gemini-2.5-pro"
    
    def add_corpus(self, name: str, corpus_id: str):
        """既存コーパスを登録"""
        self.corpora[name] = corpus_id
        logger.info(f"コーパス登録: {name} -> {corpus_id}")
    
    def ask(
        self,
        question: str,
        corpus_name: Optional[str] = None,
        include_sources: bool = True
    ) -> SearchResult:
        """
        質問に回答する
        
        corpus_nameが指定されない場合、自動ルーティングを実行
        """
        # コーパスの自動選択
        if corpus_name is None:
            corpus_name = self._auto_route(question)
        
        corpus_id = self.corpora.get(corpus_name)
        if not corpus_id:
            raise ValueError(f"Unknown corpus: {corpus_name}")
        
        # グラウンディング付きクエリ
        response = self.client.models.generate_content(
            model=self.model,
            contents=question,
            config=types.GenerateContentConfig(
                tools=[types.Tool(
                    retrieval=types.Retrieval(
                        source=types.GroundingSource(
                            corpus=types.CorpusSource(
                                corpus=corpus_id
                            )
                        )
                    )
                )],
                temperature=0.2,
                system_instruction=(
                    "あなたは社内ナレッジベースアシスタントです。"
                    "提供されたドキュメントの情報のみに基づいて回答してください。"
                    "ドキュメントに記載がない場合は、正直にその旨を伝えてください。"
                ),
            )
        )
        
        # ソース情報の抽出
        sources = []
        confidence = 0.0
        grounding = response.candidates[0].grounding_metadata
        if grounding and grounding.grounding_chunks:
            for chunk in grounding.grounding_chunks:
                ctx = chunk.retrieved_context
                sources.append({
                    "title": ctx.title if ctx else "Unknown",
                    "score": ctx.relevance_score if ctx else 0.0,
                })
            confidence = max(s["score"] for s in sources)
        
        return SearchResult(
            answer=response.text,
            sources=sources,
            confidence=confidence,
            corpus_used=corpus_name,
        )
    
    def _auto_route(self, question: str) -> str:
        """質問内容からコーパスを自動選択"""
        corpus_list = ", ".join(self.corpora.keys())
        routing = self.client.models.generate_content(
            model="gemini-2.5-flash",
            contents=(
                f"以下の質問を最適なカテゴリに分類してください。\n"
                f"カテゴリ: {corpus_list}\n"
                f"質問: {question}\n"
                f"カテゴリ名のみ回答:"
            ),
            config=types.GenerateContentConfig(temperature=0.0)
        )
        result = routing.text.strip()
        if result not in self.corpora:
            return list(self.corpora.keys())[0]
        return result
 
# 使用例
# assistant = KnowledgeBaseAssistant()
# assistant.add_corpus("技術仕様", "corpora/tech-docs-xxx")
# assistant.add_corpus("FAQ", "corpora/faq-xxx")
# result = assistant.ask("APIのレート制限はどうなっていますか？")
# print(f"回答: {result.answer}")
# print(f"信頼度: {result.confidence:.2f}")
# print(f"参照元: {result.sources}")

スケーリングと監視

パフォーマンスモニタリング

本番環境では、レスポンスタイム・検索精度・コストを継続的に監視する点が肝心です。

import time
from functools import wraps
 
def monitor_api_call(func):
    """API呼び出しのパフォーマンスを計測するデコレータ"""
    @wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        try:
            result = func(*args, **kwargs)
            elapsed = time.perf_counter() - start
            logger.info(
                f"API Call: {func.__name__} "
                f"| Time: {elapsed:.3f}s "
                f"| Status: SUCCESS"
            )
            # メトリクスの記録（Prometheus、CloudWatch等に送信）
            # metrics.histogram("gemini_api_latency", elapsed, tags=[func.__name__])
            return result
        except Exception as e:
            elapsed = time.perf_counter() - start
            logger.error(
                f"API Call: {func.__name__} "
                f"| Time: {elapsed:.3f}s "
                f"| Status: ERROR "
                f"| Error: {e}"
            )
            raise
    return wrapper

リトライとフォールバック戦略

import asyncio
from tenacity import retry, stop_after_attempt, wait_exponential
 
@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=2, max=30),
)
def query_with_retry(client, corpus_name, question):
    """リトライ付きクエリ実行"""
    return client.models.generate_content(
        model="gemini-2.5-pro",
        contents=question,
        config=types.GenerateContentConfig(
            tools=[types.Tool(
                retrieval=types.Retrieval(
                    source=types.GroundingSource(
                        corpus=types.CorpusSource(corpus=corpus_name)
                    )
                )
            )],
            temperature=0.2,
        )
    )

個人開発者の視点から（実体験メモ）

取り組みの背景：File Search APIとは何か

Gemini APIに新たに追加された File Search API（ファイル検索API）は、自分のドキュメントやデータを使ったRAG（Retrieval Augmented Generation）を、インフラ構築なしで実現するマネージドサービスです。

従来、自社データをLLMに活用させるには、ベクトルDBのセットアップ、埋め込みモデルの選定、チャンキング処理のチューニングなど、多くの手順が必要でした。File Search APIはこれらをすべて自動化し、ファイルをアップロードするだけで意味検索が可能な知識ベースを構築できます。

ここではFile Search APIの仕組みから実践的な使い方、コスト管理まで、Pythonコード付きで詳しく解説します。

File Search APIとFile APIの違い

まず、既存の File API との違いを整理しておきましょう。

機能	File API	File Search API
目的	ファイルをモデルのコンテキストに渡す	ファイルをインデックス化してRAG検索する
処理	アップロード→直接参照	アップロード→チャンキング→ベクトル化→検索
最適な用途	単一ファイルの分析・要約	大量ドキュメントからの知識抽出
引用	なし	あり（ソース箇所を自動引用）

File Search APIは大量のドキュメントから関連情報を抽出するシナリオに最適です。社内マニュアル、製品仕様書、研究論文のコレクションなど、「知識ベース」が必要な場面で真価を発揮します。

前提条件と環境構築

必要なもの

Python 3.9以上
Gemini APIキー（Google AI Studio で取得）
google-genai パッケージ（バージョン1.0以上）

インストール

pip install --upgrade google-genai

Step 1：File Search Storeの作成

File Search APIを使うには、まずFile Search Store（ファイル検索ストア）を作成します。ストアはドキュメントを格納するコンテナで、複数のファイルをまとめて管理できます。

import os
from google import genai
from google.genai import types
 
# クライアントの初期化
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
 
# File Search Storeを作成
store = client.file_search_stores.create(
    config={
        "display_name": "my-knowledge-base",
        "description": "社内ドキュメントの知識ベース"
    }
)
 
print(f"ストア作成完了: {store.name}")
# 出力例: stores/abc123def456

ストアの name フィールドに一意のIDが割り振られます。このIDを後のファイルアップロードやクエリに使用します。

Step 2：ファイルのアップロードとインデックス化

ストアにファイルをアップロードすると、自動的にチャンキング・埋め込みが行われます。

import time
 
# PDFファイルをアップロードしてインデックス化
with open("company_manual.pdf", "rb") as f:
    file_data = f.read()
 
document = client.file_search_stores.documents.create(
    name=store.name,
    config={
        "display_name": "社内マニュアル2026",
        "metadata": {
            "department": "HR",
            "version": "2.1"
        }
    },
    document_data=file_data,
    mime_type="application/pdf"
)
 
print(f"ドキュメントID: {document.name}")
print(f"ステータス: {document.state}")
 
# インデックス化が完了するまで待機（通常1〜2分）
while document.state == "PROCESSING":
    time.sleep(10)
    document = client.file_search_stores.documents.get(name=document.name)
    print(f"処理中... ステータス: {document.state}")
 
print("✅ インデックス化完了")

対応ファイル形式

PDF、DOCX、TXT、JSON、Markdown、主要なプログラミング言語ファイル（.py、.js、.ts 等）に対応しています。1ファイルの最大サイズは 100MB です。

Step 3：File Searchツールでクエリを実行

インデックス化が完了したら、Geminiモデルに対してFile Searchツールを指定してクエリを送ります。

# File Searchツールを使ってクエリを実行
response = client.models.generate_content(
    model="gemini-3-flash-preview",  # または gemini-2.5-pro
    contents="有給休暇の取得ルールを教えてください",
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[store.name]
                )
            )
        ]
    )
)
 
# 回答テキストを表示
print(response.text)
 
# 引用情報を確認
if response.candidates[0].grounding_metadata:
    for chunk in response.candidates[0].grounding_metadata.grounding_chunks:
        if chunk.retrieved_context:
            print(f"\n📎 ソース: {chunk.retrieved_context.title}")
            print(f"   テキスト: {chunk.retrieved_context.text[:100]}...")

出力例:

有給休暇は入社6ヶ月後から取得可能で、年間10日間付与されます。
取得する場合は、原則として3日前までに上長に申請してください...

📎 ソース: 社内マニュアル2026 (p.15)
   テキスト: 有給休暇の取得については、労働基準法の規定に従い...

引用情報によって、回答の根拠となったドキュメント箇所を特定できます。これによりハルシネーション（誤情報）のリスクを大幅に低減できます。

メタデータフィルタリングで検索精度を向上

複数のドキュメントをストアに格納している場合、メタデータフィルタを使って検索対象を絞り込めます。

# 特定の部署のドキュメントのみ検索
response = client.models.generate_content(
    model="gemini-3-flash-preview",
    contents="2026年の採用計画について教えてください",
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[store.name],
                    # HR部門のドキュメントのみ対象
                    filter='metadata.department = "HR"'
                )
            )
        ]
    )
)
 
print(response.text)

メタデータには任意のキーと値のペアを設定できるため、部門、バージョン、日付、著者など、業務に合わせた分類が可能です。

構造化出力との組み合わせ

File Search APIは Gemini の構造化出力と組み合わせて使用できます。これにより、ドキュメント検索結果をJSON形式で取得できます。

from pydantic import BaseModel
 
class PolicyAnswer(BaseModel):
    answer: str
    confidence: str  # "high" | "medium" | "low"
    source_section: str
 
response = client.models.generate_content(
    model="gemini-3.1-pro-preview",
    contents="リモートワークの規定はありますか？",
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[store.name]
                )
            )
        ],
        response_mime_type="application/json",
        response_schema=PolicyAnswer
    )
)
 
result = PolicyAnswer.model_validate_json(response.text)
print(f"回答: {result.answer}")
print(f"信頼度: {result.confidence}")
print(f"参照セクション: {result.source_section}")

料金とストレージ制限

File Search APIのコスト構造は開発者フレンドリーな設計になっています。

項目	料金
インデックス化（初回）	$0.15 / 100万トークン
ストレージ	無料
クエリ時の埋め込み生成	無料
取得されたトークン	通常のコンテキストトークンとして課金

ストレージ制限:

無料ティア: 1GB
ティア1: 10GB
ティア3: 最大1TB

ドキュメントを更新する際は再インデックス化のコストが発生しますが、変更のないファイルは追加料金なく保持できます。

チャンク分割を自分でチューニングする — 検索精度を左右する設定

File Search API は、アップロードしたファイルを自動でチャンクに分割してインデックス化します。多くの場合はデフォルトのままで十分です。ただ、検索結果がどうも噛み合わない、回答に必要な箇所が拾われない、という場面に出会うことがあります。

私自身、個人開発で社内向けの検索アシスタントを試作していたとき、社内マニュアルを入れて「手順の途中で文脈が切れている」と感じたことがありました。原因はチャンクの境界でした。1つの手順が2つのチャンクに割れてしまい、検索でどちらか片方しか拾われていなかったのです。

このとき効くのが、アップロード時に渡す chunking_config です。

from google import genai
from google.genai import types
 
client = genai.Client()
 
operation = client.file_search_stores.upload_to_file_search_store(
    file="docs/internal_manual.pdf",
    file_search_store_name=store.name,
    config=types.UploadToFileSearchStoreConfig(
        chunking_config=types.ChunkingConfig(
            white_space_config=types.WhiteSpaceConfig(
                max_tokens_per_chunk=400,   # 1チャンクの最大トークン数
                max_overlap_tokens=60,      # 隣接チャンクと重ねるトークン数
            )
        )
    ),
)

設定の勘どころは2つです。

max_tokens_per_chunk はチャンクの粒度を決めます。FAQ や短い回答が中心なら 150〜250 程度に小さくすると、ノイズの少ない断片がヒットしやすくなります。逆に、手順書や仕様書のように前後の文脈が意味を持つドキュメントでは 400〜600 程度に広げたほうが、回答に必要な情報が1チャンクに収まりやすくなります。

max_overlap_tokens は隣接チャンクの重なりです。ゼロにすると境界で文脈が途切れます。先ほどの「手順が割れる」問題は、ここを max_tokens_per_chunk の 1〜2 割程度に設定することで和らぎました。重ねるほど検索の取りこぼしは減りますが、その分ストレージとトークン消費は増えます。やみくもに大きくせず、取りこぼしが起きた箇所を見てから調整するのが現実的です。

チューニングの効果は体感ではなく数字で確かめます。代表的な質問を20〜30問用意し、グラウンディングの relevance_score と、期待する箇所が grounding_chunks に入っているかを記録します。設定を変えるたびにこのセットを回せば、どの値が自分のドキュメントに合うかが見えてきます。一度に複数の値を動かさず、max_tokens_per_chunk を決めてから max_overlap_tokens を詰める、という順番が遠回りに見えて確実でした。

なお、チャンク設定はアップロード時に確定します。既存ファイルの分割をやり直したい場合は、対象ファイルを削除して新しい設定で入れ直す必要があります。本番のストアでまとめて変える前に、小さな検証用ストアで値を決めておくと安全です。

よくあるエラーと対処法

QUOTA_EXCEEDED エラー: ストレージ上限に達した場合に発生します。不要なドキュメントを削除するか、上位ティアにアップグレードしてください。

インデックス化が FAILED になる: ファイルが破損しているか、対応外の形式の場合があります。ファイルを再確認してPDFなら再エクスポート、TXTなど確実に対応している形式に変換してみてください。

検索精度が低い: チャンクサイズのデフォルト設定が合わない場合があります。chunk_config パラメータで max_chunk_size_tokens を調整すると改善することがあります。

まとめ

Gemini File Search APIは、RAGパイプラインの構築・運用にかかる膨大な工数を削減し、自社データに基づくAI応答を驚くほど簡単に実現できるサービスです。本記事で解説した本番実装パターン、コスト最適化戦略、セキュリティ設計を活用すれば、すぐにプロダクション環境への導入を開始できます。

今後のGA（一般提供）リリースでは、ファイルサイズ制限の緩和やリアルタイムインデキシングなどの機能強化が期待されます。File Search APIの進化をGemini APIの公式チェンジログで追いつつ、自社のAI活用をさらに加速させていきましょう。

APIプログラミングの基礎をさらに体系的に