Gemini モデル選定とマルチモーダル活用 — Flash / Pro / Flash-Lite と画像・動画・音声・PDF 入力

🎯 はじめに：モデル選定はコスト × 品質 × レイテンシの三角形

本記事はシリーズ 「Gemini AI プラットフォーム活用」の第 2 回 です。前回 第 1 回 で課金と APIキーの足場を整えたので、今回は 「実際にどのモデルを呼び出すか」 を決めるための判断材料を整理します。

Gemini ファミリーは 4 段の生成モデル + 2 系統の Embedding モデルがあり、同じ APIキーで全部使い分けできるのが大きな強みです。モデル名を変えるだけで性能・コスト・レイテンシの三角形を調整できます。

📋 利用可能なモデル一覧（2026 年 5 月時点）

テキスト生成モデル

Embedding モデル

💡 1M トークン = 100 万トークン。日本語なら 概ね 70 万文字相当。gemini-2.5-flash で 100 万トークン処理しても入力 $0.15 = 約 22 円。Flash-Lite ならさらに半額。

🧭 用途別モデル選定フロー

実プロジェクトで悩む順序を、Yes/No チャートで整理します。

処理するタスクは「即時応答」が必要？
├─ No（バッチでよい）
│   └─→ 用途を問わず Batch API（Part 3）で 50% オフ
│       ├─ 単純分類・抽出 → gemini-2.5-flash-lite + Batch
│       └─ 複雑推論       → gemini-2.5-flash + Batch
│
└─ Yes（リアルタイム必要）
    └─ 入力サイズと推論難度は？
        ├─ 短い・単純（要約、分類、定型応答）
        │   └─→ gemini-2.5-flash-lite（最安）
        │
        ├─ 中規模・標準的なタスク（チャット、RAG 応答）
        │   └─→ gemini-2.5-flash（主力）
        │
        ├─ 長文・複雑推論（コード生成、長文要約、エージェント）
        │   └─→ gemini-2.5-pro
        │
        └─ 最高品質が必要・思考過程が要る
            └─→ gemini-3-pro-preview（高単価注意）

「迷ったら Flash」が正解

ほとんどのプロダクション用途は gemini-2.5-flash で開始するのが無難です。

• 1M トークンのコンテキスト長
• マルチモーダル対応（画像・動画・音声・PDF）
• 入力 $0.15 / 出力 $0.60（per 1M tokens）
• 高速レスポンス

ここから「もっと安く」なら Flash-Lite、「もっと賢く」なら 2.5 Pro、というチューニングのほうが、最初から Pro で始めて課金事故を起こすより健全です。

🎨 マルチモーダル：同じ APIキーで Vision まで使える

Gemini 2.0 以降の全モデルは マルチモーダル対応で、テキストと同じ APIキー・SDK でそのまま使えます。

画像入力のトークン消費とコスト

画像は トークンに変換されてカウントされます。

💡 1 万枚の商品画像を分類しても、Flash なら約 $2（約 300 円）。これがマルチモーダル × Gemini の破壊的なコスト感です。Batch API を併用すれば半額になります（Part 3）。

画像処理の典型タスク

• 画像キャプション生成 — EC サイトの商品説明自動生成
• 画像分類 — 在庫管理での自動カテゴリ分類
• オブジェクト検出 — レイアウト解析、不適切画像検出
• OCR — 名刺 / 領収書 / 帳票のテキスト抽出
• Visual QA — 画像に対する自然言語での質問応答
• カラー判定 — CTS-EC 共通商品マスタ ではこの用途で使用

動画・音声・PDF の扱い

20MB 以下ならインライン送信、それ以上は File API 経由のアップロードを使います。

< 20MB
├─ インライン（base64 / Pillow Image オブジェクト等）
└─ そのまま contents に渡せる

>= 20MB
├─ client.files.upload() で先にアップロード
├─ サーバー側で「PROCESSING → ACTIVE」を待つ
└─ アップロード後の file_uri を contents に参照させる

具体的なコードは Part 4（Python 実装ガイド）で扱います。

📐 1M トークンコンテキストの使いどころ

gemini-2.5-flash / 2.5-pro は 1M トークンのコンテキスト長を持ち、これは他社の大規模モデルと並ぶ最大級です。日本語で約 70 万文字入る計算で、実用上「ほぼ無制限」と思って設計できます。

1M トークンで現実的にできること

• ✅ 数百ページの PDF を一括読み込み（契約書、技術仕様書、論文）
• ✅ 数時間の動画を一気に要約（議事録、講義動画）
• ✅ 中規模リポジトリ全体をコンテキストに入れた質問応答（数万行のコードベース）
• ✅ 長期会話履歴を全部保持したカスタマーサポート

Anti-pattern：何でも詰め込まない

ただし「入るから入れる」は危険です。

• 🚫 コスト増 — 1M トークン × Pro = 入力だけで $1.25。RAG で必要部分だけ抽出すれば 1/100 で済む
• 🚫 レイテンシ増 — 入力トークンが多いほど初回応答が遅くなる
• 🚫 精度低下リスク — Lost in the middle（中盤情報の見落とし）が起きる

長コンテキストは「RAG で絞れない・絞ると精度が落ちるケースの最終手段」と捉え、通常は埋め込み検索で必要文書だけ詰める方が安く速く正確です。

🧪 Embedding モデルの選び方（RAG 用途）

埋め込みは RAG 検索の心臓部です。Gemini ファミリーには 3 つあります。

次元削減（Matryoshka）の威力

gemini-embedding-001 は 3072 次元がデフォルトですが、768 / 1536 にダウンサンプリング可能な Matryoshka 表現を持ちます。

💡 RAG の検索精度は 768 次元でも 3072 とほぼ変わらないケースが多く、ストレージ・速度・コストすべてで圧倒的に有利。プロダクション運用では 768 次元から始めて、必要に応じて 1536 / 3072 へ昇格するのがコスパ最適。

⚠ ベクトル DB 側のインデックス制約に注意

次元数の選択は 保存先 DB のインデックス制約にも縛られます。「3072 次元で保存できるか」と「3072 次元にインデックスを張れるか」は別問題で、後者で詰むケースが多いです。

⚠ pgvector を使うなら設計時に必ず確認: gemini-embedding-001 のデフォルト 3072 次元をそのまま vector 型に保存すると、後から HNSW インデックスを張ろうとして「column cannot have more than 2000 dimensions for hnsw index」エラーで詰みます。

pgvector で 3072 次元を扱う 3 つの選択肢

A. 768 / 1536 にダウンサンプリング   ← 推奨（精度ほぼ同等、コスト・速度最適）
   gemini-embedding-001 の output_dimensionality で指定
   → vector(768) または vector(1536) に保存、HNSW OK

B. halfvec(3072) を使う              ← 3072 次元のまま使いたい場合
   pgvector 0.7.0+ で追加された fp16 圧縮型
   → halfvec(3072) に保存、HNSW OK（最大 4000 次元）

C. インデックスを張らず全件スキャン   ← データ件数が小さい場合のみ
   < 数千件なら現実的、それ以上は遅すぎる

💡 「halfvec = 半精度 = 精度が落ちる」ではない: halfvec は fp32 → fp16 へのストレージ圧縮で、数値表現の小数点以下精度は半分になりますが、コサイン類似度や recall@k 等の意味的検索精度は実測で 0.1% 未満の差しか出ません。OpenAI / Anthropic / Pinecone も内部で fp16 / int8 圧縮を標準採用している領域です。

次元数の選び方（実用ガイド）

選定の正攻法: 評価データセットで 768 / 1536 / halfvec(3072) を並列にベンチして recall@k を比較する。768 で要件を満たすなら 768、満たさないなら 1536、それでも不足なら halfvec(3072) という昇順アプローチがコスト最適。最初から 3072 で組むと「過剰精度・過剰コスト・過剰レイテンシ」のリスク。

✅ 第 2 回まとめ

• 主力は gemini-2.5-flash — 1M コンテキスト、マルチモーダル、$0.15 / $0.60 の主力枠
• 安く: gemini-2.5-flash-lite / 賢く: gemini-2.5-pro / 最高品質: gemini-3-pro-preview
• マルチモーダルは モデル名を変えるだけで画像・動画・音声・PDF が使える
• 画像は 1024×1024 で 1,290 トークン ≒ Flash で 1 万枚処理しても約 300 円
• 1M トークンは「最終手段」。通常は RAG で絞ったほうが安く速く正確
• Embedding は gemini-embedding-001 の 768 次元から始めるのがコスパ最適。保存先 DB のインデックス制約（pgvector は 2000 次元上限）を設計時に必ず確認
• 即時応答が要らないタスクは全部 Batch API（次回） で 50% オフ

次回 Batch API で Gemini を 50% 安く使う では、本記事で紹介したモデルをすべて 50% オフで使うためのバッチ処理設計を扱います。

📚 シリーズ記事

🔗 関連リソース

• Gemini API モデル一覧（公式）
• Gemini — 用語集
• CTS-EC 共通商品マスタ — Gemini Vision の実運用例