Go+Gemini File Searchで構築する低コストRAG基盤：ベクトルDB不要の設計と実装パターン

はじめに：RAG基盤における「管理対象」の再定義

RAG（Retrieval-Augmented Generation）基盤の構築において、開発チームが抱え続けてきた課題の一つとして、ベクトルデータベースの運用負荷が挙げられる。インデックスの初期構築、ドキュメント更新時の再同期、シャーディングやレプリケーションの監視、Embeddingモデルのバージョンアップに伴う全量再インデックス化——これらはすべて「検索精度を担保するためのコスト」として、アプリケーションロジックと無関係に発生し続ける。

マネージドサービス（Pinecone、Weaviate、Qdrant Cloudなど）を選べば運用負荷は軽減されるが、それでも月々の固定費が発生し、利用量が変動するPoC〜初期段階ではコスト効率が悪くなる可能性がある。さらに、Embeddingモデルを差し替えた場合、全ドキュメントの再埋め込みが必要になるという点も考慮する必要がある。

Gemini File Searchの登場は、この管理対象の定義を変える可能性を秘めている。インデックスの作成と検索処理がGoogle側でホストされるため、クライアントが管理すべきものは「ストアID」と「APIキー」に集約される傾向にある。インフラの死活監視、容量の横方向スケーリング、Embeddingモデルの差し替え——これらがすべて運用対象から消えるわけではないが、従来のベクトルDBと比較すると管理項目は減少する。残るのは、ドキュメントをストアに投入する前処理と、検索結果を回答に組み立てるプロンプト設計だけである。

本記事では、Go言語を実装基盤として、この「管理対象の最小化」を具体的なコードとパラメータ設定に落とし込む。コスト構造の読み方、APIキーの安全な扱い方、前処理とインデックス化の最適化、実運用で遭遇する落とし穴までを、設計判断の根拠とともに示す。対象読者は、インフラコスト削減と開発効率化を両立させたい技術責任者およびシニアエンジニアである。

Gemini File Searchのアーキテクチャとコスト特性

Gemini File Searchは、Google Cloudプロジェクトに紐づくストア（Store）を介して動作する。ストア作成時に特定のプロジェクトが指定され、この紐付けは変更不可である。つまり、異なるプロジェクトのAPIキーではそのストアにアクセスできない（DEVの解説記事）。この制約は一見不便に見えるが、認可境界が構造的に1対1で固定されるため、誤って他環境のデータにアクセスするリスクを低減できる。本番と開発を分離したい場合は、それぞれ別のプロジェクトとストアを用意すればよい。

コスト構造は、従来のRAG基盤と比較すると大きく異なる可能性がある。File Searchでは、ストレージ容量とクエリ時の埋め込み計算は無料であり、コストが発生するのはインデックス化時の埋め込み処理のみであるという情報がある（DEVの解説記事）。ドキュメントを一度インデックス化すれば、その後の検索回数がどれだけ増えても追加コストはかからない。これは、クエリごとに課金されるマネージドベクトルDBと根本的に異なる点である。

無料ティアではストア容量が1GBに制限されるが、5.3MBのコーパスであれば余裕で収まる（DEVの解説記事）。中小企業の手順書や技術文書、スタートアップのナレッジベースであれば、この容量で十分カバーできるケースが多い。1GBを超える大規模コーパスを扱う場合は有料ティアへの移行を検討する必要があるが、その場合でもインデックス化時のみ課金されるという構造は変わらない可能性がある。

項目	従来のRAG基盤（ベクトルDB使用）	Gemini File Search
インデックスのホスト	自前構築またはマネージドDB	Googleがホスト
検索時のコスト	クエリごとに課金（マネージド）	無料
固定費	DBインスタンスの月次料金	なし（無料ティア）
容量上限	インスタンス依存（拡張可能）	無料ティア1GB
クライアントの管理対象	DB接続、同期ジョブ、監視、モデル差し替え	ストアID＋APIキー

このコスト構造が意味するのは、初期投資と固定費の削減である。PoC段階で「まず検索が効くか」を検証したい場合、ベクトルDBのプロビジョニングやEmbeddingパイプラインの構築を省略できる可能性がある。本番移行時も、インデックス化コストのみを予算に計上すればよく、検索トラフィックの増減に合わせたインフラ設計が不要になる。

Go言語での実装設計：APIキー管理とセキュリティ

Gemini APIの認証において、最も重要な実装上の判断はAPIキーの渡し方である。キーはURLのクエリ文字列として付与するのではなく、HTTPヘッダーのx-goog-api-keyに設定すべきである（DEVの解説記事）。

URLパラメータとして渡した場合、キーが以下のような場所に残るリスクがある。Webサーバーのアクセスログ、リバースプロキシやCDNのキャッシュ、ブラウザの履歴（フロントエンドから直接叩く場合）、そしてデバッグ時に出力されるリクエストURL。一度ログに残ると、キーのローテーションが不可欠になるが、ローテーション自体が運用コストである。

Go言語では、標準ライブラリのnet/httpパッケージを用いてリクエストを構築し、ヘッダーにキーを設定する。以下に最小の実装パターンを示す。

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "os"
    "time"
)

func newGeminiClient() *http.Client {
    return &http.Client{
        Timeout: 30 * time.Second,
    }
}

func uploadFile(ctx context.Context, client *http.Client, filePath string) (string, error) {
    apiKey := os.Getenv("GEMINI_API_KEY")
    if apiKey == "" {
        return "", fmt.Errorf("GEMINI_API_KEY が設定されていません")
    }

    req, err := http.NewRequestWithContext(ctx, "POST",
        "https://generativelanguage.googleapis.com/v1beta/files",
        nil, // バイナリボディは実際のファイル読み込みで設定
    )
    if err != nil {
        return "", err
    }

    // キーはヘッダーに設定する（URLに含めない）
    req.Header.Set("x-goog-api-key", apiKey)
    req.Header.Set("Content-Type", "application/octet-stream")

    resp, err := client.Do(req)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()

    // レスポンスからファイルIDを抽出する（JSONパースは省略）
    body, _ := io.ReadAll(resp.Body)
    return string(body), nil // 実際にはJSONデコードしてfile.nameを取得
}



このコード例は最小構成であり、エラーハンドリングやJSONデコードは省略している。実際の実装では、encoding/jsonを用いてレスポンスのファイルIDを正しく抽出し、リトライロジック（指数バックオフ）を追加すべきである。

ストアIDの管理については、ストア作成時にGoogle Cloud ConsoleまたはAPI経由でプロジェクトと紐付けたStore IDを取得し、環境変数（例: GEMINI_STORE_ID）として管理する。APIキーと同様に、コードにハードコードせず、デプロイ時に注入する方式が望ましい。

sequenceDiagram
    participant G as Goクライアント
    participant API as Gemini API
    G->>API: ファイルアップロード（x-goog-api-keyヘッダー）
    API-->>G: ファイルIDを返却
    G->>API: ストアへのファイル登録（ストアID＋ファイルID）
    API-->>G: インデックス化完了
    G->>API: 検索クエリ送信（ストアID＋プロンプト）
    API-->>G: 参照情報を含む回答


このシーケンスが示すように、File Searchを活用したRAGは「アップロード→登録→検索」の3ステップで完結する。ベクトルDBであれば、Embeddingの計算、チャンキング、インデックスへの書き込み、メタデータの管理をクライアント側で行う必要があるが、File Searchではこれらがすべてストア内部で処理される。Goクライアントが担うのは、ファイルの読み込みとAPI呼び出しのオーケストレーションのみである。
ドキュメント前処理：PDFからMarkdownへの変換戦略

RAGの検索精度は、インデックス化されるテキストの品質に直結する。PDFはレイアウト情報（見出しの階層、段落の区切り、表の構造）がバイナリ形式に埋め込まれており、単純なテキスト抽出ではこれらの構造が平坦化されてしまう。LLMが文脈を理解するためには、見出しが「#」「##」として明示され、段落間の空白が保持されたMarkdown形式が望ましい。

PDFからMarkdownへの変換ツールとして、MarkItDownやpdftotext（Poppler製）が候補に挙がるが、見出し構造と空白の保持という観点ではpymupdf4llmが優位である可能性がある。MarkItDownはPDFやOffice文書をLLM向けにMarkdown形式に変換するPythonユーティリティとして広く使われているが、複雑なレイアウトの見出し階層を正確に再現しにくいケースがある。pdftotextはテキストの抽出には強力だが、出力がプレーンテキストであり構造化情報を持たない。pymupdf4llmはMuPDFのレンダリングエンジンを活用し、PDFの論理構造をMarkdownの見出し・リスト・コードブロックとして再構築する設計になっている。

Go言語の実装では、pymupdf4llmがPython製であるため、サブプロセスとして呼び出すのが最も実用的なアプローチである。以下は、PDFファイルをMarkdownに変換する最小実装の例である。

package preprocess

import (
	"os/exec"
	"path/filepath"
)

// ConvertPDFToMarkdown は pymupdf4llm をサブプロセスとして呼び出し、
// PDFファイルをMarkdown形式に変換する。
func ConvertPDFToMarkdown(pdfPath, outDir string) (string, error) {
	outPath := filepath.Join(outDir, filepath.Base(pdfPath)+".md")

	cmd := exec.Command("python", "-m", "pymupdf4llm", pdfPath, "-o", outPath)
	cmd.Stderr = os.Stderr // 変換エラーの可視化

	if err := cmd.Run(); err != nil {
		return "", err
	}
	return outPath, nil
}
pre>

この設計の判断基準は、Go製の変換ライブラリ（例えばgo-pdf系）ではMuPDF同等のレンダリング精度が得にくいという制約にある。サブプロセス呼び出しのオーバーヘッドは、ファイル単位で1〜2秒程度であり、インデックス化パイプライン全体のボトルネックにはなりにくい。ただし、Python環境の依存管理（pip install pymupdf4llm）をCI/CDに組み込む必要がある点には注意が必要である。
インデックス化の最適化：チャンキングと差分更新

File Searchのインデックス化では、チャンキングパラメータとして最大トークン数やオーバーラップの設定値はドキュメントにより推奨範囲が異なる場合があります。一般的に、文脈の切れ目を防ぎつつ検索精度を高めるためには、適切なバランス点を見つける必要があります。トークン数が大きすぎるとチャンク内のノイズが増え検索の精度が落ちる可能性があり、小さすぎると文脈が断片化されるおそれがあります。オーバーラップを設定することで、チャンクの境界にまたがる文の意味を両方のチャンクに含め、境界付近の検索漏れを緩和する効果が期待できます。

頻繁に更新されるコーパスに対しては、全ファイルを毎回再インデックス化すると埋め込みコストと時間が無駄になる可能性があります。File Searchではファイルの変更検出にハッシュ値を用いる方式が考えられます。ハッシュはファイルのバイト列に対するダイジェストであり、内容が変更されればハッシュ値も変化します。この性質により、ファイルの内容が同一か否かの判定を比較的効率的に行うことができ、メタデータ管理の複雑さを回避できる場合があります。

package indexer

import (
	"crypto/sha256"
	"encoding/json"
	"io"
	"os"
)

// HashState はファイルパス→SHA256ハッシュの対応を保持する。
type HashState map[string]string

// LoadHashState は前回のインデックス化時のハッシュ状態を読み込む。
func LoadHashState(path string) (HashState, error) {
	data, err := os.ReadFile(path)
	if err != nil {
		return HashState{}, err
	}
	var state HashState
	err = json.Unmarshal(data, &state)
	return state, err
}

// ComputeHash はファイルのSHA256ハッシュを計算する。
func ComputeHash(filePath string) (string, error) {
	f, err := os.Open(filePath)
	if err != nil {
		return "", err
	}
	defer f.Close()

	h := sha256.New()
	if _, err := io.Copy(h, f); err != nil {
		return "", err
	}
	return fmt.Sprintf("%x", h.Sum(nil)), nil
}


差分インデックス化の処理フローは以下のようになります。ファイル群をスキャンし、各ファイルのSHA256ハッシュを計算して前回の状態と比較します。一致したファイルはスキップし、変更があったファイルのみ変換とストアへのアップロードを行います。

flowchart TD
    A["ファイル群のスキャン"] --> B["SHA256ハッシュ計算"]
    B --> C{"前回ハッシュと一致？"}
    C -->|Yes| D["スキップ"]
    C -->|No| E["Markdown変換"]
    E --> F["ストアへのアップロード"]
    F --> G["ハッシュ状態の保存"]


この設計の注意点として、ファイルが削除された場合の処理があります。ハッシュ状態に存在するがファイルシステム上に存在しないエントリは、ストア側からも削除（または無効化）する必要があります。これを怠ると、古いコンテンツが検索結果に残り続け、ユーザーに誤った情報を提示する原因となる可能性があります。

検索と回答生成：API呼び出しのパターン

File Searchを活用したRAGパイプラインは、実質的にドキュメント追加（インデックス化）と検索クエリの実行という2つの主要な処理で構成されます。従来のRAGでは、Embeddingの計算、ベクトルDBへの書き込み、メタデータフィルタリング、再ランキング、LLMへのプロンプト構築といった多段のパイプラインをクライアント側で実装する必要がありました。File Searchでは、これらの処理の一部がストア内部にカプセル化されており、Goクライアントが担うのはAPI呼び出しのオーケストレーションとなります。

検索クエリの実行時、ユーザーの質問をコンテキストとして含むプロンプトを構築し、File Searchの結果（参照情報）と組み合わせてLLMに渡します。以下は、この処理をGoで実装した最小構成の例です。実際のAPIエンドポイントやレスポンス形式は公式ドキュメントに基づいて実装してください。

package rag

import (
	"context"
	"encoding/json"
	"fmt"
	"io"
	"net/http"
)

// Search は File Search ストアに対して検索クエリを実行し、
// 参照情報を含む回答を返す。
func Search(ctx context.Context, client *http.Client, apiKey, storeID, query string) (string, error) {
	// 実際のAPIエンドポイントは公式ドキュメントで確認してください
	url := fmt.Sprintf(
		"https://generativelanguage.googleapis.com/v1beta/stores/%s:search",
		storeID,
	)
	body := fmt.Sprintf(`{"query": %q}`, query)

	req, err := http.NewRequestWithContext(ctx, http.MethodPost, url, nil)
	if err != nil {
		return "", err
	}
	req.Header.Set("x-goog-api-key", apiKey)
	req.Header.Set("Content-Type", "application/json")

	resp, err := client.Do(req)
	if err != nil {
		return "", err
	}
	defer resp.Body.Close()

	data, err := io.ReadAll(resp.Body)
	if err != nil {
		return "", err
	}

	var result map[string]json.RawMessage
	if err := json.Unmarshal(data, &result); err != nil {
		return "", err
	}

	// 参照情報（citations）を抽出してプロンプトに組み込む
	return string(data), nil
}


この「2つの呼び出し」という単純さは、複雑なパイプライン構築の手間を省く最大のメリットです。ただし、単純さゆえに制御可能なパラメータも限られる場合があります。検索の上位N件数やフィルタ条件を細かく調整したい場合、File SearchのAPIが公開しているパラメータの範囲内に収まる必要があります。この制約は、高度な検索戦略（ハイブリッド検索やメタデータフィルタリング）を必要とするユースケースでは設計上のボトルネックになり得ます。小規模〜中規模なコーパスに対しては、このトレードオフは許容範囲内であることが多いですが、要件が拡大した場合の移行経路（ベクトルDBへの移行）を事前に検討しておくことが望ましいでしょう。
プロンプトガバナンス：AgentLawsの活用

RAGシステムを本番運用に移行すると、プロンプトの管理が品質維持のボトルネックになることがあります。特に「参照情報に基づく回答生成」では、LLMに「引用された文書にない情報は断言しない」といった制約を課す指示文が精度を左右します。この指示文がバージョン管理されていないと、ある日突然回答のトーンが変わったり、ハルシネーション率が上昇したりしても原因を特定できないおそれがあります。

ここで有効なのが、AgentLaws というプロンプトガバナンスの考え方です。AgentLawsはプロンプトを法典のように構造化し、バージョン管理と引用追跡を可能にします。具体的には、各プロンプトセグメントに識別子（例: rule:no-hallucination-v2）を付与し、どのルールがどの回答に影響を与えたかを追跡できます。RAGシステムでは、以下の3層を分離して管理するのが実践的です。


システム層: 回答の形式・トーン・制約（「引用元を明示せよ」「不明な場合は『情報なし』と回答せよ」）
コンテキスト層: File Searchから返された参照情報の組み立て方（件数制限、形式）
ユーザークエリ層: 入力された質問の正規化・意図分類


Go実装では、これらを文字列リテラルでハードコードするのではなく、YAMLやJSONファイルから読み込むことで、コード変更なしにプロンプトを修正・ロールバックできるようにします。

package prompt

import (
    "fmt"
    "os"
)

// PromptConfig はプロンプトの各層を保持する
type PromptConfig struct {
    System  string `yaml:"system"`
    Context string `yaml:"context"`
    Version string `yaml:"version"`
}

func Load(path string) (*PromptConfig, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("prompt config not found: %w", err)
    }
    var cfg PromptConfig
    // YAMLデコード処理（gopkg.in/yaml.v3 を想定）
    // ここでは省略
    return &cfg, nil
}

func Build(cfg *PromptConfig, citations, query string) string {
    return fmt.Sprintf("%s\n\n参照情報:\n%s\n\n質問: %s",
        cfg.System, citations, query)
}

この分離により、システム層の指示文を修正した際にコンテキスト層やクエリ層への影響が起きないことが構造的に保証されます。プロンプト変更のレビュー対象も「システム層の差分」に絞れるため、レビューコストも下がる可能性があります。

実装における落とし穴と解決策

前述の設計を前提にしても、実装・運用フェーズで頻出する問題があります。以下に、実務で遭遇しやすい問題と対応策をまとめます。



問題 原因 対策

ストア容量超過エラー 無料ティアの制限に到達 定期バックグラウンドジョブで容量監視し、閾値（例: 80%）でアラート
PDF変換でレイアウト崩壊 表・図・複数カラムのPDF 対象ドキュメントを事前分類し、表中心のPDFは別処理（表抽出API等）へ
APIキーのローカル漏洩 .envファイルのコミット・共有 ローカル開発用と本番で異なるGCPプロジェクト・ストアを分離
インデックス化遅延による stale 検索 差分インデックス化の処理時間 検索レスポンスに「最終更新時刻」を付与し、UI側で注意表示
チャンク境界で文脈断裂 トークン分割で文が途中で切れる オーバーラップを設定しつつ、文単位での分割を前処理側で行う




特に注意すべきは、容量監視とインデックス化遅延です。前者は無料ティアの制限が「静かに」到達するため、エラーが発生した時点で初めて気づくケースが多いです。Go実装では、ストアのメタ情報取得APIを定期実行し、現在の使用量と上限の比率をPrometheus形式でエクスポートするのが実用的です。

後者は、SHA256による差分検出が機能していても、変更ファイルの埋め込み処理自体に時間がかかるため、ユーザーが「先ほど追加したドキュメントが検索されない」と感じる可能性があります。このギャップを埋めるには、インデックス化のキュー状態（処理中・完了・エラー）をクライアントに可視化することが有効です。

PDF変換の品質問題は、MarkItDown 等のツールで変換結果を検査し、見出し構造が崩れているファイルを特定して手動修正フローに回す、という半自動のQAプロセスを設けるのが現実的です。すべてのPDFを機械的に処理しようとすると、精度とコストのバランスが崩れるおそれがあります。
運用と拡張：コードレビューと監視の統合

RAGシステムの本番運用では、コード変更のリスク管理が重要になる。特に、API呼び出し部分やプロンプトテンプレートの修正は、一見すると小さな変更でも検索精度や回答品質に影響を与える可能性がある。ここで有効なのが、LiveReview のようなAIコードレビュアーである。

LiveReviewは、変更の波及範囲（blast radius）に基づいてコードレビューの優先順位をスコアリングする。RAGシステムのGoコードベースでは、以下の変更が特に高いスコアを付けられるべきである。


File Search APIの呼び出しパラメータ変更（チャンキングサイズ、検索件数）
プロンプトテンプレートの文言変更
差分インデックス化のハッシュ計算ロジックの変更
APIキーの取得方法やヘッダー設定の変更


これらの変更は、単一の関数に収まっているように見えても、システム全体の挙動に影響する。LiveReviewのようなツールをCIパイプラインに組み込むことで、PR作成時に自動で「この変更はFile Searchのインデックス化フローに波及する」という警告を発し、レビュアーの注意を引くことができる。

監視面では、以下3つのメトリクスを最低限トレースすることを推奨する。


検索レイテンシ: File Search APIの応答時間（P50/P95）。異常上昇はGoogle側の負荷増大やネットワーク問題を示す。
インデックス化成功率: 差分処理でエラーになったファイルの比率。PDF変換の失敗が原因であることが多い。
回答の引用率: LLMの回答に参照情報が実際に反映された比率（プロンプト層で制御可能）。低下傾向はハルシネーションリスクの上昇を示唆する。


これらのメトリクスは、Goの net/http パッケージ組み込みの promhttp 経由でエクスポートし、Grafana等の可視化ツールに接続する構成が標準的である。アラート閾値は、まず1週間程度の観測期間を設けてベースラインを把握した上で設定するのが安全である。

まとめ：選択と集中によるRAG実装の効率化

Gemini File SearchとGo言語を組み合わせたRAG実装は、ベクトルデータベースの構築・同期・監視という運用負荷を構造的に排除する。コスト面では、ストレージとクエリ時の埋め込みが無料であり、インデックス化時の埋め込み処理のみが課金対象となる。小規模〜中規模なドキュメントコーパスに対しては、初期投資と固定費を大幅に削減できる可能性がある。

一方で、設計上の制約も明確である。無料ティアの1GB容量制限、File Search APIが公開するパラメータ範囲内の検索制御、PDF変換時のレイアウト情報の損失、インデックス化遅延による検索結果の鮮度問題。これらは「ベクトルDBを使うと解決できる」問題というより、「要件が拡大した時点で移行判断が必要になる」問題である。

実装上の要点を整理すると、以下のようになる。


APIキーは x-goog-api-key ヘッダーで渡し、URLパラメータには含めない
チャンキングは最大400トークン・オーバーラップ60を起点に、ドキュメント特性に応じて調整する
差分インデックス化はSHA256ハッシュで未変更ファイルをスキップし、コストを最小化する
プロンプトはシステム層・コンテキスト層・クエリ層に分離し、バージョン管理する
容量監視とインデックス化状態の可視化を、本番運用の前提として実装する


「何を使うか」よりも「何を使わないか」を明確にする設計判断が、このアーキテクチャの本質である。ベクトルDBを排除することで得られる開発速度と運用簡素化は、要件が特定の規模を超えた時点で再検討すればよい。重要なのは、その再検討のトリガー（容量上限到達、検索精度の要求変化、マルチテナント化など）を事前に定義しておくことである。

                関連記事
                
                    Cloudflare Workersで軽量APIを爆速デプロイする
                    RAG（検索拡張生成）の仕組みを徹底解説！LLMの精度を向上させる実装パターン
                    社内ナレッジベース×RAGで独自AIアシスタントを構築入門
                

                参考
                本記事は海外の技術トレンド「Cheap RAG in Go with Gemini File Search: no vector DB, two calls, one hosted store」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。

問題	原因	対策
ストア容量超過エラー	無料ティアの制限に到達	定期バックグラウンドジョブで容量監視し、閾値（例: 80%）でアラート
PDF変換でレイアウト崩壊	表・図・複数カラムのPDF	対象ドキュメントを事前分類し、表中心のPDFは別処理（表抽出API等）へ
APIキーのローカル漏洩	.envファイルのコミット・共有	ローカル開発用と本番で異なるGCPプロジェクト・ストアを分離
インデックス化遅延による stale 検索	差分インデックス化の処理時間	検索レスポンスに「最終更新時刻」を付与し、UI側で注意表示
チャンク境界で文脈断裂	トークン分割で文が途中で切れる	オーバーラップを設定しつつ、文単位での分割を前処理側で行う