Generative AI Leader 試験対策 — Section 3 深掘り
GEN AI MODEL IMPROVEMENT TECHNIQUES

モデル出力を
劇的に改善する技術

試験配点 ~20% の Section 3 を完全制覇。 ファウンデーションモデルの限界を把握し、プロンプトエンジニアリング・グラウンディング・RAG の3大技術を実例付きで深掘り解説。

~20%
Section 3: Techniques to Improve Gen AI Model Output3つのサブセクション構成 • 試験全体の核心技術領域
3.1 基盤モデルの限界と克服戦略
3.2 プロンプトエンジニアリング技術
3.3 グラウンディング・RAG 技術
3.1

ファウンデーションモデルの限界と克服戦略

基盤モデルが抱える根本的な課題を特定し、Google Cloud 推奨の対処法と継続的モニタリングを理解する

試験頻出
⚠️ なぜ基盤モデルには「限界」があるのか？

LLM（大規模言語モデル）はトレーニングデータのパターンを学習して出力を生成する。このアーキテクチャ上の特性から、生まれつき持つ構造的な弱点が存在する。 試験では「どの限界に対して、どの対処法が最適か」の組み合わせが問われる。

🌀
ハルシネーション（幻覚）
事実と異なる内容を、あたかも確実であるかのように自信を持って生成する現象。「でたらめを堂々と話す」問題。
▸ Google Cloud 推奨の対処法
グラウンディング（Grounding）・RAG（検索拡張生成）・Human-in-the-Loop（HITL）で事実確認を実施
📅
知識カットオフ（Knowledge Cutoff）
トレーニングデータの締め切り日以降の出来事を知らない。「昨日何があったか」を答えられない。
▸ Google Cloud 推奨の対処法
Grounding with Google Search でリアルタイム検索を注入・RAG でリアルタイムデータを補完
⚖️
バイアス・公平性（Bias / Fairness）
トレーニングデータに内在するバイアスがモデルの出力に反映される。人種・性別・文化的偏りが結果に出る。
▸ Google Cloud 推奨の対処法
多様なトレーニングデータの使用・RLHF（人間フィードバックによる強化学習）・定期的な公平性評価
📊
データ依存性（Data Dependency）
学習データの質・量・多様性がモデルの品質を直接決定する。「ゴミを入れればゴミが出る（GIGO）」原則。
▸ Google Cloud 推奨の対処法
高品質なデータガバナンス・Vertex AI Feature Store でデータ一貫性を担保・データ品質監査
🎯
エッジケースへの脆弱性
学習データに存在しない稀なパターンや特殊な状況に対して、予期しない動作や誤った出力を生成する。
▸ Google Cloud 推奨の対処法
ファインチューニング（業界固有データでの追加学習）・プロンプトエンジニアリングで対応範囲を定義
📏
コンテキストウィンドウの制限
一度に処理できるテキスト量（トークン数）に上限がある。長大な文書は一度に処理できない。
▸ Google Cloud 推奨の対処法
RAG でチャンク分割・Gemini 1.5 Pro の 100万トークン対応モデルへの移行・サマリーチェーン技法
🛠️ Google Cloud 推奨の改善戦略マップ

以下の5つのアプローチは目的に応じて単独または組み合わせて使用する。コスト・速度・精度のトレードオフを理解して最適な戦略を選ぶことが試験のポイント。

✏️
プロンプトエンジニアリング
コスト低 / 速度 ◎ / 即時効果
  • 追加学習不要でモデルの動作を制御
  • Few-shot / Chain-of-Thought 等の技法を活用
  • ゼロコストで始められる最初のステップ
  • 効果は中程度（モデル重みは変えない）
最初に試すべき手法
🔗
グラウンディング・RAG
コスト中 / 速度 ○ / リアルタイム性高
  • 外部知識ベースにLLMを紐づける
  • ハルシネーション・知識カットオフを解決
  • 最新情報を常に反映できる
  • Vertex AI Search / RAG API / Google Search
ハルシネーション対策の王道
🎓
ファインチューニング
コスト高 / 速度 △ / 高精度
  • 業界・ドメイン固有データで追加学習
  • モデルの重みを更新し専門性を付与
  • 高品質データが必要（通常 100〜数千件）
  • SFT / RLHF / PEFT（LoRA/QLoRA）等の手法
専門ドメインへの特化
👤
HITL（Human-in-the-Loop）
コスト可変 / 品質保証 ◎
  • AIの判断に人間のレビューを挟む
  • 高リスク判断（医療・法律）で必須
  • ミス検知・フィードバックデータ収集
  • 継続的なモデル改善サイクルの基盤
高リスク業務では必須
📐
継続的評価・モニタリング
コスト低〜中 / 品質維持
  • Vertex AI Evaluation Service で自動評価
  • ドリフト検知・KPI 継続計測
  • 自動モデルアップグレード適用
  • Vertex AI Feature Store で特徴量管理
本番維持に不可欠
⚠️ 試験頻出：戦略の選択基準
  • まずプロンプトエンジニアリングから試し、それで不十分なら RAG / ファインチューニングへ進む
  • 最新情報が必要な場合は RAG / グラウンディングを選ぶ（ファインチューニングでは解決不可）
  • 業界固有の言葉遣い・形式が必要な場合はファインチューニングが適切
  • 医療・法律・金融などの高リスク判断では HITL を必ず組み込む
📡 継続的モニタリングとモデル管理（試験頻出）

Gen AI モデルは一度デプロイして終わりではない。データドリフト・パフォーマンス低下・セキュリティ脆弱性に継続的に対応する必要がある。

🔄 自動モデルアップグレード
Vertex AI の管理モデルはGoogleが定期的にセキュリティパッチ・バージョン更新を自動適用。手動対応の工数を削減し、常に最新の安全なモデルを利用できる。
📊 KPI継続追跡
精度（Accuracy）・F1スコア・BLEU/ROUGE・ユーザー満足度などの指標を継続的に計測。Cloud Monitoring と統合してアラートを自動発火。
🌊 ドリフト監視
入力データの統計的分布が学習時と乖離（ドリフト）していないか監視。コンセプトドリフトを早期検知して再学習トリガーを設定。
🗄️ Vertex AI Feature Store
特徴量（Feature）を一元管理し、学習時と推論時で同じ特徴量変換を使用することを保証。トレーニング・サービングスキューの防止に不可欠。
📦 バージョン管理
Vertex AI Model Registry でモデルのバージョン・メタデータを管理。ロールバック可能な状態を維持し、A/Bテストによる段階的デプロイを実現。
🔒 セキュリティパッチ
プロンプトインジェクション攻撃・データポイズニングなどの脅威に対するパッチを定期適用。Vertex AI の管理モデルは Google が自動更新。
✅ 継続的モニタリングのベストプラクティス
  • 本番デプロイ前にVertex AI Evaluation Serviceでベースラインスコアを記録し、定期比較する
  • Vertex AI Feature Store でオンライン/オフライン特徴量を一元管理してスキューを防止する
  • シャドーモード（Shadow Mode）で新モデルを旧モデルと並行実行し、安全にA/Bテストを実施する
  • ドリフト検知アラートは Cloud Monitoring で設定し、閾値を超えたら自動でエンジニアに通知する
📎 参照リソース
https://cloud.google.com/vertex-ai/docs/model-monitoring/overviewhttps://cloud.google.com/vertex-ai/docs/featurestore/overview
3.2

プロンプトエンジニアリング技術

LLM との効果的なコミュニケーション技法を体系的に理解する。Zero-shot から ReAct まで全手法を実例付きで解説

最重要
🎯 プロンプトエンジニアリングとは？

プロンプトエンジニアリングとは、LLM（大規模言語モデル）から望ましい出力を引き出すための入力文（プロンプト）を設計・最適化する技術。 モデルの重みを変えずに動作を制御できる最もコスト効率の高い改善手法。試験では各技法の名称・定義・適切なユースケースの識別が問われる。

0円
追加コスト
（API料金のみ）
即時
効果発揮
（再学習不要）
6+
主要技法数
（試験出題範囲）
中
最大効果
（FT比較）
📚 全プロンプト技法 完全ガイド（Zero-shot → ReAct）
BASIC
Zero-Shot
ゼロショット：例示なしで直接タスクを依頼する

事前の例示（デモンストレーション）を与えずに、タスクの指示文だけでLLMに回答させる。最もシンプルで、明確なタスクに有効。モデルが学習済みの知識だけで対応する。

Prompt: "次の文章を日本語に翻訳してください：The weather is nice today."
Output: "今日は天気がいいですね。"
// 例示なし。モデルの事前知識だけで回答。
適用場面：明確で単純なタスク（翻訳・要約・分類）、モデルが十分に学習済みのドメイン
BASIC
One-Shot
ワンショット：1つの例示を与えてからタスクを実行

1つの入出力ペアを例として示してからタスクを依頼する。出力フォーマットを厳密に指定したい場合に特に有効。モデルがパターンを学習して同形式で応答する。

// 例示（1件）
Input: "東京" → Output: "首都 / 日本 / 1380万人"
// タスク
Input: "大阪" → Output: ???
適用場面：出力形式を統一したい場合、JSON/CSV 等の構造化フォーマットを指定する場合
STANDARD
Few-Shot
フューショット：複数の例示（2〜8件）で精度を向上させる

複数の入出力ペアを例として提供することで、モデルが期待されるパターンをより正確に把握できる。Few-shot は In-Context Learning（文脈内学習）の代表的な技法。

// 例示3件：感情分類タスク
"この商品は最高！" → ポジティブ
"遅延が多くて困った" → ネガティブ
"普通の品質でした" → ニュートラル
// タスク
"梱包が丁寧で感動した" → ???
適用場面：特定のパターン・形式・分類スキームに従わせたい場合。例示が多いほど精度が向上するが、コンテキスト消費も増える
STANDARD
Role Prompting
ロールプロンプティング：AIに特定の役割・ペルソナを与える

モデルに専門家・キャラクター・特定の視点を持つ人物として振る舞うよう指示する。役割を明確に設定することで、その専門分野に特化した質・スタイルの回答を引き出せる。

// システムプロンプト
Role: "あなたは15年以上の経験を持つ上級セキュリティエンジニアです。"
"技術的な正確さを最優先し、平易な言葉で説明してください。"
// ユーザー入力
User: "ゼロトラストアーキテクチャを実装する際の注意点は？"
適用場面：技術文書・法律レビュー・医療相談など、専門性が求められるタスク。Gemini の Gems 機能もこれを体系化したもの
STANDARD
Prompt Chaining
プロンプトチェーニング：複雑なタスクを複数ステップに分解して連鎖させる

1つのプロンプトで解決できない複雑なタスクを、複数の小さなステップに分割して順番に実行する手法。前のステップの出力を次のステップの入力に使用する。

// Step 1: 文章を要約
Prompt 1: "以下の長文を3行で要約してください：{raw_text}"
→ summary_text

// Step 2: 要約から課題を抽出
Prompt 2: "以下の要約から主要な課題を箇条書きで抽出：{summary_text}"
→ issues_list

// Step 3: 解決策を提案
Prompt 3: "以下の課題に対する解決策を提案：{issues_list}"
適用場面：長大な文書処理・多段階のデータ変換・エージェントの思考ステップ実装
ADVANCED
Chain-of-Thought
思考の連鎖（CoT）：ステップバイステップで推論プロセスを可視化させる

「ステップバイステップで考えてください（Let's think step by step）」という指示で、モデルが中間の推論ステップを明示的に記述しながら解答する手法。複雑な論理問題・数学・多段階推論で精度が大幅に向上する。

// Zero-shot CoT の例
Prompt: "太郎は50個のリンゴを持っています。20個を花子に渡し、"
"残りの半分を次郎に渡しました。太郎に残るリンゴは何個？"
"ステップバイステップで考えてください。"

// モデルの出力例
Step 1: 50 - 20 = 30個（花子に渡した後）
Step 2: 30 ÷ 2 = 15個（次郎に渡した後）
Answer: 15個
適用場面：数学・論理推論・多段階の意思決定・コードのデバッグ。「なぜその答えか」の説明可能性も向上する
EXPERT
ReAct
ReAct（Reasoning + Acting）：推論と行動を交互に繰り返すエージェント手法

Reason（推論）→ Act（ツール使用などの行動）→ Observe（結果観察）のサイクルを繰り返す。外部ツール（検索・計算・API等）を呼び出しながら問題を段階的に解決する、エージェント設計の核心技法。

Task: "2024年の日本のGDPはアメリカのGDPの何倍か？"

Thought 1: GDPデータを調べる必要がある
Action 1: search("2024年 日本 GDP")
Obs 1: 日本GDP = 約4.2兆ドル

Thought 2: アメリカのGDPも調べる
Action 2: search("2024年 アメリカ GDP")
Obs 2: 米国GDP = 約27兆ドル

Thought 3: 計算する
Action 3: calculate(4.2 / 27)
Answer: 約0.155倍（約15.6%）
適用場面：外部ツール・API・データベースと連携するAIエージェント。Vertex AI Agent Builder の内部ロジックとしても活用
✅ プロンプト設計の黄金律
  • 明確さ優先：「何を」「どのような形式で」「何文字程度で」生成するかを具体的に記述する
  • コンテキストを提供：背景情報・制約条件・対象読者を明示することで出力品質が向上する
  • ネガティブ指示：「〜してはいけない」という制約も書くと不適切な出力を防げる
  • 出力フォーマット指定：「JSON形式で」「箇条書きで3点」などフォーマットを明示する
  • 反復改善：プロンプトはイテレーション（試行錯誤）で最適化する。一発完成を期待しない
技法難易度主なユースケースコスト（トークン）
Zero-shot★☆☆翻訳・要約・分類（明確なタスク）最小
One-shot★☆☆フォーマット指定・構造化出力小
Few-shot★★☆パターン学習・カスタム分類中
Role Prompting★★☆専門家視点・特定スタイルの文章生成中
Prompt Chaining★★☆多段階処理・ワークフロー自動化中〜大
Chain-of-Thought★★★数学・論理推論・説明可能性向上大
ReAct★★★AIエージェント・外部ツール連携最大
📎 参照リソース
https://cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/introduction-prompt-designChain-of-Thought Prompting 原論文 (Wei et al., 2022): https://arxiv.org/pdf/2201.11903.pdfReAct 原論文 (Yao et al., 2022): https://arxiv.org/pdf/2210.03629.pdfGoogle Cloud CoT & ReAct サンプルノートブック: https://github.com/GoogleCloudPlatform/generative-ai/
3.3

グラウンディング技術と RAG

LLM の回答を事実に基づかせる「グラウンディング」の概念・3種類のデータソース・Google Cloud の RAG オファリング・サンプリングパラメータを完全理解する

最重要
🌍 グラウンディング（Grounding）の本質

グラウンディングとは、LLM の生成する回答を、信頼できる外部データソースに「紐づける（錨をおろす）」技術。 モデルが「記憶から作り話をする」のではなく「参照した文書から回答する」ようにすることで、ハルシネーションを根本的に削減する。

❌ グラウンディングなし（危険）
  • モデルの学習済みパラメータのみから生成
  • ハルシネーションが頻繁に発生
  • 知識カットオフ以降の情報を参照不可
  • 企業固有の情報を回答できない
  • 出典・根拠の引用が不可能
✅ グラウンディングあり（推奨）
  • 外部データソースを参照してから生成
  • ハルシネーションを大幅に低減
  • 最新情報・リアルタイムデータを反映
  • 企業固有の社内文書を参照可能
  • 引用元（ソース）を明示して信頼性向上
📂 グラウンディングの3種類のデータソース（試験頻出）

試験では「どのデータソースで、どのグラウンディング手法を使うか」の組み合わせが問われる。

🏢 ファーストパーティデータ（自社データ）
企業が保有する独自の内部データ。社内文書・製品マニュアル・業務ナレッジベース・CRM データ等。

特徴：機密性が高い。外部に出さずにGCP内で処理する必要がある。

推奨手法：Vertex AI Search（プリビルト RAG）または RAG API
🌐 サードパーティデータ（外部データ）
業界レポート・ニュースフィード・規制当局の発表・パートナー企業から提供されるデータ。

特徴：ライセンス・著作権に注意が必要。定期更新が必要。

推奨手法：データパイプラインで取り込み後、Vertex AI Search に登録
🌏 World Data（世界の一般知識）
インターネット全体のリアルタイム情報。最新ニュース・Wikipedia・公開 Web サイトなど。

特徴：最も新鮮。情報の信頼性はソースによって異なる。

推奨手法：Grounding with Google Search（リアルタイム Web 検索）
⚠️ 試験頻出：データソースとグラウンディング手法の対応
  • 自社機密データ + セキュリティ重視 → Vertex AI Search（VPC 内処理）または RAG API
  • 最新の世界情報 + 知識カットオフ解消 → Grounding with Google Search
  • 両方が必要な企業アプリ → ハイブリッド（社内 Vertex AI Search + Google Search を組み合わせ）
🔄 RAG（Retrieval-Augmented Generation）仕組みの完全解説

RAG = 検索（Retrieval） + 拡張（Augmented） + 生成（Generation）。外部文書から関連情報を検索し、それをコンテキストに追加してLLMが生成する技術。

1
📥 ドキュメントの取り込み・前処理（Ingestion）

PDF・Word・Webページ・データベースなどの企業内ドキュメントを読み込む。テキストを適切なサイズの断片（チャンク）に分割する。チャンクサイズは大きすぎても小さすぎても精度に影響。

チャンキングドキュメント前処理OCR対応（PDF等）
2
🔢 エンベディング（ベクター化）

各チャンクをエンベディングモデル（text-embedding-004等）で数値ベクターに変換。意味的に近いテキストは近い位置のベクターになる。このベクターをベクターデータベースに格納する。

text-embedding-004意味的検索ベクターDB
3
🔍 クエリ・検索（Retrieval）

ユーザーの質問もエンベディングでベクター化。ベクターデータベースでコサイン類似度・内積などで最も関連するチャンクを上位N件取得（ベクター検索 + BM25の組み合わせもある）。

コサイン類似度Approximate NNリランキング
4
📝 プロンプト拡張・LLM生成（Augmentation + Generation）

検索で取得したチャンクをコンテキストとしてプロンプトに追加し、LLMに渡す。LLMはモデルの知識だけでなく提供されたコンテキストを参照して回答を生成。ソース引用も可能になる。

コンテキスト注入Gemini Proソース引用
📌 RAG とファインチューニングの違い

RAG は「外部から情報を検索して補う」→最新情報対応・データを変えればすぐ反映。 ファインチューニングは「モデル自体を再学習させる」→特定ドメインへの深い適応・推論時コストゼロ。 多くの場合 RAG → FT の順で試すのが Google 推奨のアプローチ。

☁️ Google Cloud の3つの RAG オファリング（試験必須）

Google Cloud は難易度・制御度に応じた3段階の RAG ソリューションを提供。何を優先するかで選択肢が変わることが試験のポイント。

① プリビルト RAG — Vertex AI Search
概要：ドキュメントをアップロードするだけで RAG 搭載の検索・Q&A API が完成。チャンキング・エンベディング・ベクター検索・LLM回答生成をすべて自動化。

特徴：コード最少・最速でPoC可能・エンタープライズ品質

適用場面：社内ナレッジ検索・チャットボット・カスタマーサポートのFAQ回答
② RAG API — Vertex AI RAG Engine
概要：RAG パイプラインの各ステップ（チャンキング戦略・埋め込みモデル選択・リランキングアルゴリズム）をAPIで細かくカスタマイズ。

特徴：高度な制御・複数データソースの動的切り替え可能・専用エンドポイント

適用場面：特定のチャンキング戦略が必要な場合・カスタム再ランキングが必要な場合
③ Grounding with Google Search
概要：Google のリアルタイム Web 検索インデックスを LLM の回答に注入。API 設定1行で有効化でき、常に最新の世界情報を提供。

特徴：リアルタイム・最新情報・知識カットオフを完全解消

適用場面：最新ニュース・株価・天気・時事情報が必要なアプリ
比較軸① Vertex AI Search（プリビルト）② RAG API（カスタム）③ Grounding w/ Google Search
実装難易度★☆☆（最簡単）★★☆（中程度）★☆☆（最簡単）
制御度低（自動管理）高（各ステップ制御）低（Google管理）
データソース社内文書・DB任意（カスタム）公開 Web（リアルタイム）
最新情報登録次第（手動更新）データ次第◎（常時最新）
適用場面社内ナレッジ・PoC高精度・専門システム世界の最新情報が必要な場合
✅ RAG オファリング選択のフレームワーク
  • まず試すなら → Vertex AI Search（プリビルト RAG）。最小コード・最速PoC
  • 精度向上が必要なら → RAG API でチャンキング戦略・リランキングをカスタマイズ
  • 最新情報が必須なら → Grounding with Google Search を単体または組み合わせで使用
  • エンタープライズ本番なら → 社内データ（Vertex AI Search）+ 必要に応じて Google Search のハイブリッド構成
📎 参照リソース
https://cloud.google.com/vertex-ai/generative-ai/docs/grounding/overviewhttps://cloud.google.com/vertex-ai/generative-ai/docs/grounding/grounding-with-vertex-ai-searchhttps://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/groundingRAG 原論文 (Lewis et al., 2020): https://arxiv.org/pdf/2005.14165.pdf
🎛️ サンプリングパラメータ — LLM の動作を精密にコントロールする

Gen AI モデルは複数のパラメータで出力の多様性・長さ・安全性を制御できる。試験では各パラメータの機能と推奨設定値が頻繁に問われる。

temperature（温度）
範囲: 0.0 〜 2.0
出力のランダム性・創造性を制御する最重要パラメータ。低いほど決定論的（毎回同じ）、高いほど多様で予測不能な出力になる。
0.0
完全決定論的
0.2
事実QA推奨
0.7
バランス型
1.0+
創作文章推奨
top_p（Nucleus Sampling）
範囲: 0.0 〜 1.0
確率の累積値がP に達するまでの上位トークンからのみサンプリングする。確率が低い「奇妙な単語」を排除し、品質を保ちながら多様性を確保する。
0.1
非常に保守的
0.8
バランス型
0.95
一般推奨値
1.0
全トークン対象
max_output_tokens
モデル仕様で確認が必要（モデル世代ごとに異なる）
生成する最大トークン数を設定。1トークン ≒ 日本語で約1〜2文字、英語で約4文字。短い応答が必要なら小さく設定して API コストを削減できる。実際の上限値は使用するモデル（Gemini 2.5 Pro / Flash 等）の公式仕様で確認すること。
推奨設定：
チャット応答 → 256〜512
要約タスク → 1024〜2048
長文生成 → モデル上限まで
safety_settings
BLOCK_LOW_AND_ABOVE / BLOCK_MEDIUM_AND_ABOVE / BLOCK_ONLY_HIGH / BLOCK_NONE / OFF
有害コンテンツ（ヘイトスピーチ・危険情報・性的内容・暴力）のフィルタリング強度を設定。カテゴリ別に個別設定可能。エンタープライズでは BLOCK_LOW_AND_ABOVE 等の厳しめ閾値を推奨。BLOCK_NONE は許可された場合にのみ利用可能な制限付きフィールドであり、gemini-2.5-flash 以降の新モデルでは OFF がデフォルト。
カテゴリ：
HARM_CATEGORY_HARASSMENT
HARM_CATEGORY_HATE_SPEECH
HARM_CATEGORY_DANGEROUS_CONTENT
HARM_CATEGORY_SEXUALLY_EXPLICIT
token_count（入力トークン）
モデルのコンテキストウィンドウ以内
入力プロンプト（コンテキスト）のトークン数。APIコストは入力+出力トークン数の合計で課金される。長いコンテキストは精度を上げるがコストも上がる。
Gemini のコンテキスト上限：
Gemini 1.5 Flash → 1M トークン
Gemini 1.5 Pro → 1M トークン
Gemini 2.0 Flash → 1M トークン
stop_sequences
任意の文字列リスト
指定した文字列が出力に現れた時点で生成を即座に停止するシーケンス。JSON生成時の「} 」やマークダウン区切りの「---」など、出力の終端を制御するのに使用。
活用例：
stop_sequences: ["```", "END", "\n\n"]
✅ サンプリングパラメータのベストプラクティス
  • 事実確認・QA・要約 → temperature: 0.0〜0.3（低い値で一貫性を確保）
  • マーケティング文章・アイデア生成 → temperature: 0.7〜1.0（高い値で創造性を発揮）
  • コード生成 → temperature: 0.0〜0.2（構文的に正確なコードが必要）
  • エンタープライズ本番環境 → safety_settings を HIGH に設定。コンプライアンス監査ログを記録
  • コスト最適化 → max_output_tokens を必要最小限に設定。不必要な長文生成を防ぐ
// Vertex AI Python SDK でのサンプリングパラメータ設定例
from vertexai.generative_models import GenerativeModel, GenerationConfig

model = GenerativeModel("gemini-1.5-pro-002")

config = GenerationConfig(
temperature=0.2, # 事実QA向けに低く設定
top_p=0.9, # 上位90%のトークンからサンプリング
max_output_tokens=1024, # 最大1024トークンで応答
stop_sequences=["END"], # "END"が出たら停止
)

response = model.generate_content(
"本日の気温と過去30年の平均気温を比較してください",
generation_config=config,
)
📎 参照リソース
https://cloud.google.com/vertex-ai/generative-ai/docs/learn/modelshttps://cloud.google.com/vertex-ai/docs/generative-ai/model-reference/text#request_bodyhttps://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/configure-safety-attributes
🎯 Section 3 試験攻略 — 最重要ポイント完全まとめ
~20%
試験での配点
3
サブセクション数
7
プロンプト技法数
6
サンプリングパラメータ
3.1 で絶対押さえる3点
① 6つの限界とそれぞれの対処法の組み合わせ ② 5つの改善戦略のトレードオフ ③ Vertex AI Feature Store・ドリフト監視の役割
3.2 で絶対押さえる3点
① 7技法の名称・定義・適用場面（特に CoT と ReAct） ② Zero-shot→ReAct の難易度・コスト順 ③ プロンプト設計の黄金律5箇条
3.3 で絶対押さえる3点
① 3種データソースとグラウンディング手法の対応 ② RAG 3オファリングの使い分け基準 ③ temperature・top-p の意味と推奨設定値
⚠️ Section 3 で特に混同しやすい概念
  • RAG ≠ ファインチューニング：RAG は「検索して補う」、FT は「モデルを再学習させる」。最新情報対応は RAG でしか解決できない
  • Temperature=0 は「完全に同じ出力」ではない：top-p・top-k の影響で完全同一ではないが、極めて高い一貫性になる
  • Prompt Chaining ≠ Chain-of-Thought：Chaining は複数プロンプトをつなぐ「ワークフロー」、CoT は1プロンプト内で推論を「見える化」する技法
  • Grounding ≠ RAG：RAG はグラウンディングの実装方法の一つ。Grounding はより広い概念で、Google Search グラウンディングは RAG の変形
📎 Section 3 全体の参照リソース
試験ページ: https://cloud.google.com/learn/certification/generative-ai-leader試験ガイド PDF: https://services.google.com/fh/files/misc/generative_ai_leader_exam_guide_english.pdfPrompt Design ガイド: https://cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/introduction-prompt-designGrounding 概要: https://cloud.google.com/vertex-ai/generative-ai/docs/grounding/overviewModel Monitoring: https://cloud.google.com/vertex-ai/docs/model-monitoring/overviewChain-of-Thought 論文 (Wei 2022): https://arxiv.org/pdf/2201.11903.pdfReAct 論文 (Yao 2022): https://arxiv.org/pdf/2210.03629.pdfRAG 論文 (Lewis 2020): https://arxiv.org/pdf/2005.14165.pdf