PMLE 学習ハブ
🎯 公式ドキュメント準拠 / 深掘り

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本番品質の汎用GASFT + checkpoints + continuous
Gemini 2.5 Flash低レイテンシ・低コストGASFT + preference + checkpoints + continuous
Gemini 2.5 Flash-Lite最小コスト本番GA全部対応
Gemini 2.0 Flash with Live API音声/動画ストリーミングpreview○(75% 割引)
Imagen / Veo / Lyria画像 / 動画 / 音楽生成各別
割引率の世代差 Context Caching の cache hit 割引は Gemini 2.5+ で 90%、2.0 系は 75%。同じプロンプト設計でも世代によってコストが大きく違います。

⚡ 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.xGemini 3.x
最小トークン数2,0484,096
cache hit 割引75%90%
最小 TTL1 分
最大 TTL無制限(デフォルト 60 分、API で延長可能)
キャッシュ可能な blob/text 最大10 MB

使うべきユースケース(公式記載)

# 疑似コード - 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 の落とし穴

公式が警告する 4 つの罠
  1. Cloud Storage オブジェクトの変更で silent invalidation:「don't make changes to objects until the cached contents are expired or deleted」。元 GCS の置き換えで cache が無効化されるが、エラーは出ない
  2. Implicit と Explicit の混在:Explicit cache 利用時にも background で implicit caching が走る。完全に防げない
  3. VPC SC の境界に GCS バケットも入れる:「include your bucket in your service perimeter as well」。cache 本体だけ境界に入れても、ソース GCS が外なら漏れる
  4. 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

[User: "Boston の天気から最適なレストランを薦めて"] ↓ [Model: functionCall(get_weather, location="Boston")] ↓ (App 実行) [App: functionResponse(temp=5°C, raining)] ↓ [Model: functionCall(search_restaurants, indoor=true, city="Boston")] ↓ (App 実行) [App: functionResponse([list of restaurants])] ↓ [Model: 自然言語応答]

モデルは「別関数の出力が必要」と判断したら次の関数を呼びます。会話履歴に全ターンを保持して投げ直す のが正しい実装。

🎨 マルチモーダル & 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.functionCallingConfigmode を制御。ANY(必ず関数呼ぶ)・AUTO(モデル判断)・NONE(禁止)。本番では context によって ANY と AUTO を使い分け。

本番でよく忘れること 関数名・引数の validation。公式は「consider adding validations for function names and arguments」と推奨。モデルが存在しない関数や不正な値を出力するケースがあるため、実行前のホワイトリスト検証を必ず実装。

🌳 Model Garden 深掘り

3 つのカテゴリ

カテゴリ特徴
FoundationGemini / Imagen / Veo / Lyria / Claude / Llama事前学習済み、tuning または直接使用可
Fine-tunableGemma / 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 の流れ

  1. Model Garden で対象モデルを検索
  2. 1-click deploy(推奨コンテナで Endpoint 作成)または カスタムコンテナ(vLLM / Hex-LLM ベース)
  3. Endpoint がデプロイされ、通常の Inference API で呼べる
  4. SFT 用のチュートリアル notebook は GitHub に多数

🛡 Model Garden のセキュリティ(公式記載)

Google 側のスキャン体制
  • 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 がブロックされる
公式の重要警告 「suspicious or those that have the ability to potentially execute remote code」とフラグされたモデルは deploy 可能だが警告表示される。「We recommend you perform a thorough review of any suspicious model before deploying」。OSS モデルの自動信頼は禁物

組織レベルでのアクセス制御

「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 / データ反復改善・段階的データ追加

📊 モデル別サポート状況

モデルSFTPreferenceCheckpointsContinuous
Gemini 2.5 Pro
Gemini 2.5 Flash
Gemini 2.5 Flash-Lite
Code modelsSFT のみ

📁 訓練データと PEFT

データ準備の原則(公式)

  1. High-quality, well-labeled data is crucial for good performance and better than quantity」— 量より質
  2. data should reflect the prompt distribution, format and context the model will encounter in production」— 本番分布の再現が最優先
  3. evaluate where the model makes mistakes before adding more data」— 闇雲なデータ追加禁止、誤答分析が先
  4. 最低 100 例 程度から開始可能(小規模実験的)

PEFT (Adapter Tuning) のメカニズム

Vertex AI の Gemini チューニング = PEFT 公式は「parameter-efficient tuning, also called adapter tuning, which updates a relatively small subset of the model's parameters」と明記。Full fine-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.

[STEP 1] プロンプトエンジニアリング + few-shot ↓ 精度が出ない? [STEP 2] RAG(知識を外部から注入) ↓ 知識ではなくスキル不足? [STEP 3] Supervised Fine-tuning(100+ 例) ↓ 主観的好みを学ばせたい? [STEP 4] Preference Tuning(Flash/Flash-Lite のみ)

FT が必要なシグナル

FT を選ばないシグナル

⚠️ リスクと注意点

本番でよく踏むリスク 10 選
  1. Implicit cache hit が確認できないcachedContentTokenCount = 0 ならプロンプト構造を見直し(共通 prefix を冒頭へ)
  2. GCS 元データの変更で cache silent invalidation:cache が消えるまで元 GCS は触らない
  3. VPC SC 境界に GCS を入れ忘れる:cache 本体だけ境界内でもソースが外なら漏洩
  4. Function 数 512 超:上限超過でリクエストが reject される
  5. Parallel function call で 1 つしか返さない:1 user message に全 functionResponse をまとめる必要
  6. Thinking モードで thought_signature を捨てる:次ターンに all parts を返さないと推論が切れる
  7. OSS モデルの remote code execution リスク:suspicious フラグは無視せず必ずレビュー
  8. Code モデルに preference tuning:SFT 限定。preference は使えない
  9. FT データの本番分布不一致:訓練データが本番プロンプト形式と乖離すると効果なし
  10. 「データ量で勝負」:公式は quality > quantity を明言。誤答分析が先

📚 参考リンク(一次情報)