プロンプト設計・JSONスキーマ・few-shot・バッチ処理
Prompt Engineering & Structured Output は CCAF 5ドメイン中で20% を占めるドメインです。 公式ページに記載された範囲としては、「明示的な基準でのプロンプト設計」「few-shot 技法」 「JSON スキーマによる構造化出力の強制」が中心トピックです。
AI を業務に組み込む際の核心的領域。出力の信頼性を高めるための設計判断が問われます。
曖昧な指示（「保守的に」「自信のある場合のみ」）は精度を上げません。 公式ドキュメントが推奨するのは、具体的な分類基準・閾値・例外条件を明文化するアプローチです。 「重大な問題のみ報告」より「セキュリティ脆弱性・データ破損リスク・性能劣化のいずれかに該当する場合」のように。
曖昧なシナリオでは、2〜4個の具体例を入力に含めることで一貫した出力が得られます。 few-shot 例の役割は次の通り:
JSON Schema を入力スキーマとするツールを定義し、tool_use で呼び出させる手法。 JSON 構文エラーを排除しつつ、スキーマに従った構造化出力を保証できます。
tool_choice の使い分けが重要:
auto — モデルがツール使用を判断（テキスト応答もあり得る）any — 必ず何らかのツールを呼ぶ（テキストにならない）スキーマに「ソースに存在しない可能性のあるフィールド」を nullable で定義することで、 モデルが値を捏造（hallucinate）するのを防げます。 required フィールドを多用すると、モデルが情報不足の場合に偽データを埋める原因になります。
Pydantic 等で構造化検証 → 失敗時は元プロンプト + 元ドキュメント + 検証エラー情報 を含めて 再リクエスト。フォーマット mismatch や構造エラーは retry で復旧可能ですが、 ソース文書に情報がない場合は retry しても解決しない（識別が重要）。
非同期バッチ処理用のAPI。50%のコスト削減・最大24時間の処理ウィンドウ・custom_id で request/response の対応付け。
適切な用途は レイテンシ許容ワークロード:
不適切な用途は ブロッキングワークフロー:
大量ファイルの review で、1パスで全部やると注意散漫（attention dilution）になる現象があります。 ファイル別ローカルレビュー → 別パスでクロスファイル統合、のように分割するアーキテクチャが信頼性を上げます。
「JSON Schema は "optional" を恐れずに使う」。 スキーマ設計時に required を多用しがちですが、ソース文書に確実にあるフィールド以外は nullable / optional にした方が、モデルが捏造するリスクを大幅に下げられます。
「Few-shot は少なくとも2例必要」。 1例だけでは「これと同じ形式で」と解釈され、汎化されません。 対照的な複数例があってこそ判断基準が伝わります。
「Batch API は会計・財務系で大きい」。 月次帳票生成・大量レシート処理など、レイテンシが許容できる業務では、 Batch API のコスト50%削減が効きます。
本ページは Exam Guide PDF の Task Statement、Knowledge of / Skills in リスト、Sample Questions を一切引用していません。