Deep Dive: Gemini API & Model Garden
§1 のローコード AI 領域を、公式 Vertex AI / Generative AI ドキュメントの文面に沿って深掘りします。 Context Caching・Function Calling・Model Garden 安全性・Gemini ファインチューニング の本番運用観点に焦点。
🌟 Gemini モデルファミリー(2026 年時点)
| モデル | 主用途 | 状態 | Caching | ファインチューニング |
|---|---|---|---|---|
| Gemini 3.1 Pro | 最高精度の推論・コード | preview | ○ | — |
| Gemini 3.1 Flash-Lite | 最小コスト・最速 | preview | ○ | — |
| Gemini 3 Flash | 標準的高速モデル | preview | ○ | — |
| Gemini 2.5 Pro | 本番品質の汎用 | GA | ○ | SFT + checkpoints + continuous |
| Gemini 2.5 Flash | 低レイテンシ・低コスト | GA | ○ | SFT + preference + checkpoints + continuous |
| Gemini 2.5 Flash-Lite | 最小コスト本番 | GA | ○ | 全部対応 |
| Gemini 2.0 Flash with Live API | 音声/動画ストリーミング | preview | ○(75% 割引) | — |
| Imagen / Veo / Lyria | 画像 / 動画 / 音楽生成 | 各別 | — | — |
⚡ Context Caching の核心
プロンプトの冒頭に繰り返し現れる長文(システム指示・大量ドキュメント・PDF 等)の処理を 1/10 程度のコスト で済ませる仕組み。Implicit と Explicit の 2 種類 が並行して動きます。
🔄 Implicit Caching(自動)
仕組み
「全 Google Cloud project にデフォルトで有効」。Vertex が 自動でプロンプト prefix を検出してキャッシュ。プログラム側の対応不要。
料金
cache hit 部分は 90% 割引(Gemini 2.5+)。storage 課金なし。Explicit に対する大きな優位点。
効くプロンプトの形
「large and common contents を prompt の冒頭に」「類似 prefix のリクエストを短時間で送る」と Vertex のヒット率が上がる、と公式が明記。
レスポンスの確認方法
レスポンスメタデータの cachedContentTokenCount でヒット数を確認可能。これが 0 なら効いていない。
🎯 Explicit Caching(手動)
「キャッシュをいつ作るか・いつ消すか・TTL をどうするか」を 明示的にアプリ側で制御。Implicit と違って storage 課金が発生。
必須の閾値
| 項目 | Gemini 2.x | Gemini 3.x |
|---|---|---|
| 最小トークン数 | 2,048 | 4,096 |
| cache hit 割引 | 75% | 90% |
| 最小 TTL | 1 分 | |
| 最大 TTL | 無制限(デフォルト 60 分、API で延長可能) | |
| キャッシュ可能な blob/text 最大 | 10 MB | |
使うべきユースケース(公式記載)
- extensive system instructions を持つ Chatbot
- 長尺動画ファイルの繰り返し解析
- 大量ドキュメントセットへの再帰的クエリ
- コードリポジトリの繰り返しバグ修正・解析
# 疑似コード - Explicit cache 作成
cache = client.caches.create(
model="gemini-2.5-pro",
config={
"contents": [{"role": "user", "parts": [{"text": "長文の社内マニュアル..."}]}],
"system_instruction": {"parts": [{"text": "あなたは X 社の AI アシスタント"}]},
"ttl": "3600s", # 1 時間
}
)
# 利用
response = client.models.generate_content(
model="gemini-2.5-pro",
contents=[{"role": "user", "parts": [{"text": "Q: 有給休暇の取り方は?"}]}],
config={"cached_content": cache.name}
)
# 期限延長
client.caches.update(cache.name, ttl="86400s") # 24 時間
⚠️ Cache の落とし穴
- Cloud Storage オブジェクトの変更で silent invalidation:「don't make changes to objects until the cached contents are expired or deleted」。元 GCS の置き換えで cache が無効化されるが、エラーは出ない
- Implicit と Explicit の混在:Explicit cache 利用時にも background で implicit caching が走る。完全に防げない
- VPC SC の境界に GCS バケットも入れる:「include your bucket in your service perimeter as well」。cache 本体だけ境界に入れても、ソース GCS が外なら漏れる
- Optimized Online Serving (Feature Store) と混同しないこと:Context Caching と Feature Store の Online Store は別物
cache 完全 OFF の方法
「To prevent cache data retention, disable implicit caching and avoid creating explicit caches」と公式が明記。データガバナンス上 cache が NG なケースでは両方無効化が必要。
🔧 Function Calling の核心
LLM に「外部関数 / API を呼ぶ JSON 出力」を生成させる仕組み。LLM 単体ではできない リアルタイムデータ取得・実行系操作 を実現します。
Function 宣言の形(OpenAPI 3.0.3 schema)
{
"name": "get_current_weather",
"description": "Get the current weather in a given location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "The city name, e.g., San Francisco, CA"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"]
}
},
"required": ["location"]
}
}
- 1 リクエストあたり 最大 512 FunctionDeclarations
- 「temperature=0」を「maximum determinism in function calling」のため推奨
- 関数名・パラメータ名・description の clarity が選択精度を決定的に左右
🚦 並列・合成 Function Calling
Parallel function calling
「Get weather in Boston and San Francisco?」のような問いに対して、モデルは 1 ターンで複数の functionCall parts を返します。アプリ側は全ての関数を実行し、結果を 1 つの user message に複数の functionResponse objects として束ねて返す 必要があります。
Compositional (multi-step) function calling
モデルは「別関数の出力が必要」と判断したら次の関数を呼びます。会話履歴に全ターンを保持して投げ直す のが正しい実装。
🎨 マルチモーダル & Thinking モード(Gemini 3 Pro+)
Multimodal Function Responses
Gemini 3 Pro 以降は functionResponse に 画像 (PNG/JPEG/WebP)・PDF・テキスト を含められる。後続ターンで {"$ref": "displayName"} 形式で参照可能。「OCR → グラフ画像 → 説明」のような複合ワークフローが 1 セッションで完結。
Streaming Function Call Arguments
Gemini 3 Pro 以降は streamFunctionCallArguments=true で 引数を生成中にストリーミング。長い引数(複雑な JSON)でユーザー体感レイテンシを大幅削減。
Thinking モード対応
thinking models 使用時は thought_signature オブジェクトを必ず捕捉し、次ターンに response 全体(all parts)を返す。これを欠くと推論コンテキストが切れ、精度が落ちる。
Tool Config (forced calling)
ToolConfig.functionCallingConfig で mode を制御。ANY(必ず関数呼ぶ)・AUTO(モデル判断)・NONE(禁止)。本番では context によって ANY と AUTO を使い分け。
🌳 Model Garden 深掘り
3 つのカテゴリ
| カテゴリ | 例 | 特徴 |
|---|---|---|
| Foundation | Gemini / Imagen / Veo / Lyria / Claude / Llama | 事前学習済み、tuning または直接使用可 |
| Fine-tunable | Gemma / Llama / OSS 各種 | カスタムノートブック・パイプラインで FT 可 |
| Task-specific solutions | 事前構築済みソリューション | カスタム不要、データ準備すれば使える |
提供元の分類
Google 製
Gemini / Imagen / Veo / Lyria(音楽生成)
Partner
Anthropic Claude(Opus / Sonnet / Haiku)/ Mistral / Meta Llama
OSS
HuggingFace Hub / DeepSeek / Qwen ほか
🚀 MaaS vs Self-deployed
| Models as a Service (MaaS) | Self-deployed | |
|---|---|---|
| インフラ管理 | 不要(Google が運用) | 必要 |
| 課金単位 | トークン課金(PayGo / Provisioned Throughput) | compute hour(Endpoint と同じ) |
| 料金階層 | Standard / Priority / Flex の 3 tier | マシン種別による |
| カスタマイズ | 限定的 | フル(vLLM / Hex-LLM カスタムコンテナ) |
| 典型対象 | Gemini, Claude, Llama 等 | HuggingFace Hub の任意モデル |
OSS Self-deploy の流れ
- Model Garden で対象モデルを検索
- 1-click deploy(推奨コンテナで Endpoint 作成)または カスタムコンテナ(vLLM / Hex-LLM ベース)
- Endpoint がデプロイされ、通常の Inference API で呼べる
- SFT 用のチュートリアル notebook は GitHub に多数
🛡 Model Garden のセキュリティ(公式記載)
- Google 製コンテナ:「thorough testing and benchmarking」+「active vulnerability scanning」
- Featured Partner モデル:「model checkpoint scans to ensure authenticity」
- HuggingFace モデル:HF 側で malware・pickle ファイル・Keras Lambda layers・secrets をスキャン、不安全と判定されたものは Model Garden での deploy がブロックされる
組織レベルでのアクセス制御
「organization, folder, or project level」で organization policies を設定し、vetted(審査済み)モデルのみ許可、それ以外を全部 deny が可能。規制業界では必須の機能。
🔧 Gemini ファインチューニングの 4 手法
| 手法 | 説明 | 使い所 |
|---|---|---|
| Supervised Fine-tuning (SFT) | ラベル付きデータでパラメータを学習 | 分類・感情分析・エンティティ抽出・ドメイン特化クエリ生成 |
| Preference Tuning | 主観的 user preference を学習(Flash / Flash-Lite のみ) | 「特定の labels では定義しづらいニュアンス」 |
| Tuning Checkpoints | 中間チェックポイント保存・比較 | 「最適な epoch を再訓練なしで選択」 |
| Continuous Tuning | 既存チューン済モデルに追加 epoch / データ | 反復改善・段階的データ追加 |
📊 モデル別サポート状況
| モデル | SFT | Preference | Checkpoints | Continuous |
|---|---|---|---|---|
| Gemini 2.5 Pro | ✅ | — | ✅ | ✅ |
| Gemini 2.5 Flash | ✅ | ✅ | ✅ | ✅ |
| Gemini 2.5 Flash-Lite | ✅ | ✅ | ✅ | ✅ |
| Code models | SFT のみ | — | — | — |
📁 訓練データと PEFT
データ準備の原則(公式)
- 「High-quality, well-labeled data is crucial for good performance and better than quantity」— 量より質
- 「data should reflect the prompt distribution, format and context the model will encounter in production」— 本番分布の再現が最優先
- 「evaluate where the model makes mistakes before adding more data」— 闇雲なデータ追加禁止、誤答分析が先
- 最低 100 例 程度から開始可能(小規模実験的)
PEFT (Adapter Tuning) のメカニズム
- 「more resource efficient and cost effective compared to full fine-tuning」
- 「significantly lower computational resources」
- 「faster adaptation with smaller datasets」
- 「flexibility for multi-task learning」
JSONL の典型形(SFT)
{"contents": [
{"role": "user", "parts": [{"text": "支店コード ABC123 の今月の売上は?"}]},
{"role": "model", "parts": [{"text": "支店 ABC123 (東京西支店) の今月の売上は 1,234 万円です。"}]}
]}
{"contents": [
{"role": "user", "parts": [{"text": "クラスタ X の状態を教えて"}]},
{"role": "model", "parts": [{"text": "クラスタ X は HEALTHY、稼働率 87%、ノード 32/32 active です。"}]}
]}
...
🎯 プロンプト vs ファインチューニング vs RAG の判断軸
公式が示す段階的アプローチ:「We recommend starting with prompting to find the optimal prompt. Then, move on to fine-tuning (if required) to further boost performances or fix recurrent errors.」
FT が必要なシグナル
- プロンプト + few-shot で 頭打ち
- 出力形式(JSON スキーマ・特定の文体)を厳密に守らせたい
- ドメイン特化用語 の頻出
- 推論コスト削減(小モデル + FT で中モデル並み精度)
- プロンプトが長すぎる → FT で 「shorter prompts」によるレイテンシ・コスト削減(公式記載)
FT を選ばないシグナル
- 「知識」を最新化したい → RAG
- ラベル付きデータが < 100 例 → プロンプト改善が先
- クイック PoC → プロンプトのみ
⚠️ リスクと注意点
- Implicit cache hit が確認できない:
cachedContentTokenCount= 0 ならプロンプト構造を見直し(共通 prefix を冒頭へ) - GCS 元データの変更で cache silent invalidation:cache が消えるまで元 GCS は触らない
- VPC SC 境界に GCS を入れ忘れる:cache 本体だけ境界内でもソースが外なら漏洩
- Function 数 512 超:上限超過でリクエストが reject される
- Parallel function call で 1 つしか返さない:1 user message に全 functionResponse をまとめる必要
- Thinking モードで thought_signature を捨てる:次ターンに all parts を返さないと推論が切れる
- OSS モデルの remote code execution リスク:suspicious フラグは無視せず必ずレビュー
- Code モデルに preference tuning:SFT 限定。preference は使えない
- FT データの本番分布不一致:訓練データが本番プロンプト形式と乖離すると効果なし
- 「データ量で勝負」:公式は quality > quantity を明言。誤答分析が先