AWS認定AIプラクティショナー(AIF-C01)のドメイン3「基盤モデルの応用」(配点28%=最大)で必ず問われるのがプロンプトエンジニアリングです。モデルを再学習せずに、指示の書き方だけで出力の質を上げる技術。この記事では試験頻出のZero-shot/Few-shot/Chain-of-Thoughtの違いと、AWSが推奨するベストプラクティスを整理します。
プロンプトの基本構成要素
AWS(Amazon Bedrock)は、良いプロンプトの構成要素を次のように整理しています。これらを意識して書くだけで、出力は大きく安定します。
- 指示(Instruction):モデルに「何をしてほしいか」を明確に伝える本体
- コンテキスト(Context):判断材料となる追加情報・前提・キーワード
- 例(デモンストレーション):望む入出力のお手本(後述のFew-shot)
- 入力テキスト:実際に処理させたい対象のデータ
- ネガティブプロンプト:「〜は含めない」など、避けてほしい内容の指定(特に画像生成で活躍)
あわせて、temperatureなどの推論パラメータ(→ FMアプリ設計)も出力の性質に影響します。
代表的な3つの技法:Zero-shot / Few-shot / Chain-of-Thought

① Zero-shot(ゼロショット)
例を与えず、指示だけで答えさせる方法です。「次の文を要約して:…」のように、モデルの事前学習の知識だけに頼ります。簡単なタスクや一般的な質問に向きます。
② Few-shot(少数ショット)/One-shot(単一ショット)
望む入力→出力のお手本を数個プロンプト内に示してから、本番を解かせる方法です。例が1個ならOne-shot(単一ショット)、複数ならFew-shot。これはインコンテキスト学習とも呼ばれ、モデルは再学習なしで「例から形式や傾向を掴んで」答えます。分類・抽出・特定フォーマットの出力で効果大。例はタスクに似たものを3〜5個選ぶのがコツです。
③ Chain-of-Thought(思考の連鎖/CoT)
「順を追って考えて(Think step-by-step)」と促し、答えだけでなく推論の途中過程を出させる方法です。計算・論理・多段の問題で正答率が上がりやすいのが特徴。Few-shotと組み合わせ、お手本にも考える過程を書いておくとさらに効きます。
- Zero-shot=例なし/Few-shot=例あり(=インコンテキスト学習)/One-shot=例1個
- Chain-of-Thought=「順を追って考えて」で推論過程を出させ、複雑問題に強い
- 構成要素=指示・コンテキスト・例・入力・ネガティブプロンプト
- プロンプトエンジニアリングはモデルを変えない(再学習しない)
AWS推奨のベストプラクティス
- 具体的・簡潔に:曖昧さを避け、必要な条件を明示する
- 指示は最後に置く+区切り文字(改行など)で入力と指示を分ける
- 出力形式を指定:「箇条書きで」「JSONで」「100字以内で」など出力インジケータを添える
- お手本(Few-shot)を必要に応じて与える
- 「わからなければ”不明”と答えて」と逃げ道を用意し、ハルシネーションを抑える
- 反復して改善:実験しながらプロンプトを磨く(テスト用データで検証)
なお、悪意ある入力でプロンプトを乗っ取るプロンプトインジェクションなどの攻撃と対策は、別記事 プロンプト攻撃とガードレール で扱います。
確認クイズ
Q1. プロンプト内に『入力→出力』の例を3つ示してから本番を解かせる手法は?
Q2. 複数ステップの計算問題で正答率を上げたい。最も効果的なプロンプト技法は?
Q3. プロンプトエンジニアリングの説明として正しいものは?
よくある質問(FAQ)
Q. Few-shotとファインチューニングはどう違う?
A. Few-shotはプロンプト内の例で誘導するだけで、モデルは変わりません(インコンテキスト学習)。ファインチューニングはモデル自体を追加学習して振る舞いを変えます(→ ファインチューニング解説)。まず手軽なFew-shotで試すのが定石です。
Q. Chain-of-Thoughtは必ず使うべき?
A. いいえ。単純なタスクでは冗長になり、出力も長くなります。計算・論理・複数ステップが必要な問題で効果的です。タスクの難しさで使い分けましょう。
Q. ネガティブプロンプトとは?
A. 「これは含めないで」と避けてほしい要素を指定する書き方です。特に画像生成モデルで「低品質・文字なし」などを除外する用途でよく使われます。
まとめ
- Zero-shot=例なし、Few-shot=例あり(インコンテキスト学習)、One-shot=例1個
- Chain-of-Thought=推論過程を出させ、複雑問題に強い
- 具体的・簡潔に、出力形式を指定、逃げ道を用意――が品質向上の鉄則
※本記事はAWS公式試験ガイド(AIF-C01)およびAmazon Bedrockプロンプトエンジニアリングガイドラインに基づき、エンジニアKが作成しています。



コメント