Databricks Certified Generative AI Engineer Associate 教科書
第1章 生成AIアプリケーション設計(Design Applications, 14%)
🎯 この節の学習目標
プロンプトエンジニアリングとは、モデルの重みを変えずに、入力の書き方だけで出力の品質と形式を制御する技術です。最も基本となる分類が、例示の有無によるゼロショット/フューショットの区別です。
| 技法 | 内容 | 有効な場面 |
|---|---|---|
| ゼロショット(Zero-shot) | 入出力の例を示さず、指示だけでタスクを実行させる | モデルが既に得意な一般的タスク(要約、翻訳、単純な分類)。プロンプトが短く済むためコスト・レイテンシに有利 |
| フューショット(Few-shot) | 少数(数個程度)の入出力例をプロンプト内に提示する | 出力形式を安定させたいとき、ドメイン特有の判断基準やエッジケースの扱いを示したいとき、指示だけでは意図が伝わりにくいとき |
使い分けの基本は「まずゼロショットで試し、品質や形式が安定しなければフューショットに切り替える」です。フューショットの例はトークンを消費するため、例の数は品質が安定する最小限にとどめます。また、例の品質がそのまま出力品質に影響するため、代表的なケースと紛らわしいエッジケースをバランスよく選ぶことが重要です。
💼 例:フューショットで分類の判断基準を教える
問い合わせ分類で「配送中の破損」を「返品」ではなく「故障」に分類したい、という自社ルールがあるとします。ゼロショットではモデルが一般常識で「返品」と判断しがちですが、フューショットで示せば揃えられます。
次の例にならって問い合わせを「返品」「故障」「請求」「その他」に分類してください。
入力:「届いた商品の画面が割れていました」 → 出力:故障
入力:「サイズが合わなかったので返したい」 → 出力:返品
入力:「先月2回引き落とされています」 → 出力:請求
入力:「{問い合わせ本文}」 → 出力:
Chain-of-Thought(CoT)は、最終回答の前に推論の過程を段階的に書かせる技法です。「ステップバイステップで考えてください」といった指示や、推論過程付きのフューショット例を与えることで、計算・論理推論・複数条件の判断など多段の思考が必要なタスクの正答率を高められることが知られています。
プロンプトチェイニング(Prompt Chaining)は、1つの複雑なタスクを複数のプロンプトに分割し、前段の出力を後段の入力として直列につなぐ技法です。1-1の Step 4 で見た「1プロンプトに詰め込むと品質が落ちる」場合の解決策であり、1-5で学ぶマルチステージ・チェーン設計のプロンプト面での基礎になります。
💼 例:会議録からアクションアイテムのメール文を作る
各プロンプトは単一の目的に集中できるため指示が明確になり、中間のJSONを機械的に検証できる点も品質管理上の利点です。
欠点は、LLM呼び出し回数が増えることによるレイテンシとコストの増加、および前段の誤りが後段に伝播することです。分割は「品質・検証性の利益が追加コストを上回るか」で判断します。
メタプロンプト(Meta-prompting)は、プロンプト自体をLLMに生成・改善させる技法です。「このタスクのための効果的なプロンプトを書いてください」「このプロンプトで誤答が出た。原因を分析して改善案を出してください」のように、LLMをプロンプトエンジニアリングの道具として使います。
試験ガイドには「特定の形式の応答を引き出すプロンプトを作成する」が明示的な学習目標として挙げられています。アプリケーションに組み込む場合、出力は後段のプログラムがパースするため、形式の安定が品質そのものです。次の4つの道具を組み合わせます。
| 道具 | 内容 | 記述例 |
|---|---|---|
| 明確・具体的な指示 | やること・やらないことを曖昧さなく書く | 「3文以内で要約する」「推測で補完しない。不明な項目は null とする」 |
| デリミタ(区切り文字) | 指示と入力データを """ や XMLタグなどで明確に区切る | 「以下の <document> タグ内の文書を要約してください」 |
| 出力形式の指定 | 形式・スキーマ・選択肢を明示し、余計な前置きを禁止する | 「次のキーを持つJSONのみで答える:category, amount, due_date。説明文は出力しない」 |
| ロール付与 | 役割を与えてトーン・視点・専門性を方向付ける | 「あなたは経験豊富なカスタマーサポート担当者です」 |
デリミタにはプロンプトインジェクション対策としての側面もあります。入力データを明確に区切ることで、データ内に紛れ込んだ「これまでの指示を無視して…」のような文を「処理対象のデータ」として扱わせやすくなります(完全な防御ではありません。第6章で詳述)。
📝 試験のポイント
「LLMの出力に『はい、喜んでお手伝いします』のような前置きが混ざりJSONパースが失敗する」というシナリオが典型です。正解はプロンプトで「JSONのみを出力し、それ以外のテキストを含めない」と明示する、あるいはフューショット例で形式を示す、という選択肢です。「後段の処理で前置きを毎回手作業で削る」「モデルを大型化する」といった選択肢は誤答の典型です。
✅ この節のまとめ
問1. 商品レビューの感情分類で、ゼロショットプロンプトでは「皮肉を含むレビュー」の分類が安定しない。モデルはそのままで改善したい。最も適切な対応はどれか。
正解:A
エッジケース(皮肉)の扱いを安定させるのはフューショットの典型的な適用場面です。判断が難しい例を提示することで、モデルに判断基準を具体的に示せます。Bは指示がなくなり品質がさらに不安定になります。Cはコストが3倍になるうえ根本解決になりません。Dは翻訳で皮肉のニュアンスが失われる可能性が高く、ステージ追加のコストも増えます。
問2. LLMの応答をアプリケーションでJSONとしてパースしているが、「以下が結果です:」のような前置きが混ざってパースエラーが頻発する。最も適切な改善はどれか。
正解:B
特定形式の応答を引き出すには、出力形式の明示的な指定(「JSONのみ」「説明文は出力しない」)とフューショット例の提示が第一の手段です。Aはコスト増のわりに前置き問題の解決は保証されません。Cはエラーの発生自体を減らしません。Dは出力のばらつきを増やし、形式の安定という目的に逆行します。
問3. 長い技術文書から「用語の抽出」「用語ごとの平易な説明の生成」「用語集ページの整形」を行うアプリを作る。1つのプロンプトでまとめて指示すると品質が不安定になった。最も適切な設計はどれか。
正解:A
性質の異なる複数タスクの品質が1プロンプトで不安定になる場合、プロンプトチェイニングによる分割が定石です。各段が単一目的に集中でき、中間結果の検証も可能になります。Bは指示の競合という根本原因を解決しません。Cはタスク間に依存関係(抽出→説明→整形)があるため順序を崩せません。Dは要件放棄です。
問4. 数値の含まれる複数条件の与件から結論を導くタスクで、LLMが途中の論理を飛ばして誤った結論を出すことが多い。プロンプトの改善として最も適切なのはどれか。
正解:B
多段の推論が必要なタスクにはChain-of-Thoughtが有効です。推論過程を明示的に書かせることで正答率が向上し、誤りの箇所も特定しやすくなります。Aは推論を省略させる方向であり逆効果です。Cは判断材料を失わせます。Dは推論の飛躍という問題と無関係です。