🔍

OpenAI Responses API File Searchを理解する

に公開
AI
API
OpenAI
RAG
filesearch
tech

はじめに

OpenAI Responses APIは、2025年3月にリリースされた新しいAPIプリミティブで、Chat Completions APIとAssistants APIの長所を組み合わせたものです。この中でも特に注目すべき機能がFile Searchツールで、知識ベースを検索し、取得したコンテンツに基づいて回答を生成できるホスティング型ツールです。

従来、RAGシステムを構築するにはPDFの解析、チャンク化戦略の定義、ストレージプロバイダーへのアップロード、エンベディング生成、ベクトルデータベースへの保存など、複雑な設定が必要でした。File Searchは、これらの複雑な処理を単一のAPIコールで実現します。

Responses API File Searchとは何か

基本概念

File Searchは、Responses APIで使用できるホスティング型ツールで、以前はAssistants APIのベータ版でのみ利用可能でしたが、現在はResponses APIで正式に利用可能になり、メタデータフィルタリングなどの機能が強化されています。

主な機能：

  • PDF、Word文書、プレゼンテーションなど、複数のファイルタイプを横断した検索
  • 自然言語クエリに基づく特定情報の発見
  • 複数文書からの情報抽出・統合
  • ソース文書の特定セクションへの引用提供

アーキテクチャフロー（シーケンス図）

実装例

OpenAI Cookbookに掲載されている例に基づいたコード：

from openai import OpenAI
import os
import time

client = OpenAI(api_key=os.getenv('OPENAI_API_KEY'))

# 1. Vector Storeの作成
def create_vector_store(store_name: str) -> dict:
    try:
        vector_store = client.vector_stores.create(name=store_name)
        details = {
            "id": vector_store.id,
            "name": vector_store.name,
            "created_at": vector_store.created_at,
            "file_count": vector_store.file_counts.completed
        }
        print("Vector store created:", details)
        return details
    except Exception as e:
        print(f"Error creating vector store: {e}")
        return {}

# 2. ファイルのアップロードとVector Storeへの追加
def upload_file_to_vector_store(file_path: str, vector_store_id: str):
    try:
        # ファイルをアップロード
        file_response = client.files.create(
            file=open(file_path, 'rb'),
            purpose="assistants"
        )

        # Vector Storeにファイルを追加
        attach_response = client.vector_stores.files.create(
            vector_store_id=vector_store_id,
            file_id=file_response.id
        )

        return {"status": "success", "file_id": file_response.id}
    except Exception as e:
        print(f"Error uploading file: {str(e)}")
        return {"status": "failed", "error": str(e)}

# 3. File Searchを使用した検索と回答生成
def search_and_respond(query: str, vector_store_id: str):
    response = client.responses.create(
        input=query,
        model="gpt-4o-mini",
        tools=[{
            "type": "file_search",
            "vector_store_ids": [vector_store_id],
            "max_num_results": 5
        }]
    )

    # アノテーション（引用情報）の取得
    if hasattr(response.output[1], 'content') and response.output[1].content:
        annotations = response.output[1].content[0].annotations

        # 使用されたファイルの確認
        retrieved_files = set([result.filename for result in annotations])
        print(f'使用されたファイル: {retrieved_files}')

    # 応答テキストの取得
    return response.output[1].content[0].text

Responses APIとVector Store APIの違い

機能比較表

機能 Vector Store API Responses API File Search
主要な用途 純粋なベクトル検索 統合されたRAGシステム
検索結果 生の検索結果とスコア LLMによる統合された回答
クエリ最適化 手動実装が必要 自動的にクエリを最適化
再ランキング 手動実装が必要 自動的に結果を再ランキング
引用情報 なし annotationsとして自動生成
価格体系 ストレージのみ ストレージ + 実行料金

Vector Store API直接使用の例

# Vector Store APIの直接使用（検索のみ）
search_results = client.vector_stores.search(
    vector_store_id="vs_abc123",
    query="技術実装方法"
)

# 検索結果の処理（手動で行う必要がある）
for result in search_results.data:
    print(f'ファイル: {result.filename}')
    print(f'スコア: {result.score}')
    print(f'内容: {result.content[0].text[:200]}...')

Pre-search・Post-search最適化の詳細

Pre-search処理の自動化

File Searchツールは以下の前処理を自動的に実行します：

  1. クエリ分析: ユーザーの意図と文脈の理解
  2. クエリ拡張: 関連語彙や同義語の追加
  3. クエリ分解: 複合的な質問を複数の検索に分割
  4. 検索戦略選択: ハイブリッド検索（セマンティック + キーワード）の実行

Post-search処理の自動化

検索後の処理も自動化されています：

  1. 結果統合: 複数の検索結果をマージ
  2. 関連性スコアリング: ハイブリッド検索によるスコアリング
  3. 重複除去: 類似コンテンツの統合
  4. 引用情報生成: annotationsオブジェクトとして提供

デフォルト設定と技術的詳細

公開されているデフォルト設定

File Searchツールの主要な設定：

  • チャンクサイズ: 約800トークン（推定値）
  • チャンクオーバーラップ: 約400トークン（推定値）
  • エンベディングモデル: text-embedding-3-large（256次元と推定）
  • 最大検索結果数: max_num_resultsパラメータで指定可能（デフォルト5-10）
  • ランカー: ハイブリッド検索（セマンティック + キーワード）

チャンクサイズ設計の理論的根拠

800トークン設定の推定される理由：

  1. 文脈保持: 50%のオーバーラップにより文脈の連続性を確保
  2. 検索精度: 情報の密度と検索精度のバランス
  3. 処理効率: LLMのコンテキストウィンドウでの効率的な処理

理想的なカスタマイズ値（将来的に可能になった場合）：

  • 技術文書: 1200トークン（コードブロックや詳細な説明を含む場合）
  • FAQ文書: 400-600トークン（Q&A単位での検索に最適）
  • 学術論文: 1000-1500トークン（段落単位の論理構造を保持）

現在の制約とブラックボックス化の影響

制御不可能な要素

1. エンベディングモデルの固定

  • 使用モデルが固定されており変更不可
  • ドメイン特化型のカスタムモデル使用不可
  • 日本語などの非英語言語での最適化が限定的

2. 検索アルゴリズムのブラックボックス化

  • ハイブリッド検索の内部実装が非公開
  • BM25とセマンティック検索の重み付けが不明
  • スコアリング基準の詳細が非公開

3. ランキングアルゴリズムの自動選択

  • どのランカーが使用されているか不透明
  • ドメイン特性に応じた調整が不可能
  • A/Bテストによる最適化が困難

ブラックボックス化による実装上の課題

デバッグの困難性：

  • 期待と異なる検索結果の原因特定が困難
  • 内部処理のログが取得できない
  • パフォーマンスボトルネックの特定が不可能

最適化の限界：

  • ドメイン固有の最適化が実施できない
  • 精度向上のための調整ポイントが限定的
  • 内部アルゴリズムの更新により結果が変動する可能性

料金体系と制約

※ 以下の情報は2025年8月時点のものです。最新情報は公式ドキュメントを参照してください。

コスト構造

File Searchの料金体系：

  • ストレージコスト: $0.10/GB/日（最初の1GB無料）
  • 実行コスト: $2.50/1000 file_search実行
  • LLMトークンコスト: 選択したモデルの標準レート（別途）

ファイル制限

サポートされるファイル形式：

  • PDF、Word文書（.docx）
  • プレゼンテーション（.pptx）
  • テキストファイル
  • その他多様な形式

サイズ制限（推定値）：

  • ファイルサイズ: 最大512MB/ファイル
  • ファイル数: 最大10,000ファイル/Vector Store
  • トークン数: ファイルあたりの上限あり（詳細は非公開）

日本語文書での考慮事項

トークン数の違い

日本語は英語と比較して約1.5-2倍のトークンを消費するため：

  • チャンク内の実質的な情報量が減少
  • コスト増加の要因となる
  • 検索精度への影響を考慮する必要がある

文字エンコーディング

  • UTF-8エンコーディングの確認が必須
  • Shift-JISなどのレガシーエンコーディングは事前変換が必要

検索精度の課題

  • 形態素解析の精度による影響
  • 同義語・表記ゆれへの対応が限定的
  • カタカナ/ひらがな/漢字の混在による検索精度の低下

まとめ

OpenAI Responses API File Searchは、RAGシステムの実装を大幅に簡素化する強力なツールです。単一のAPIコールで、ファイルストレージ、エンベディング、検索がすべて統合されています。

主要な利点：

  • 複雑なRAGパイプラインの実装が不要
  • Pre-search・Post-search処理の自動化
  • 検索から回答生成まで統合された体験

注意すべき制約：

  • エンベディングモデルやアルゴリズムのカスタマイズ不可
  • 内部処理のブラックボックス化によるデバッグの困難さ
  • 実行コスト（$2.50/1000回）とストレージコスト（$0.10/GB/日）の両方が発生

適切な要件分析と制約の理解により、File Searchは多くの実用的なRAGシステムで効果的に活用できます。ただし、ブラックボックス化による制約を理解し、それを前提とした設計・運用が重要です。

Discussion