5.1標準
生成モデルに顧客分類をJSONで返させる。
下流の業務システムが誤った型や余計な命令を受け取らないようにする。
実装として適切なものを2つ選べ。
× 不正解
構造化出力はスキーマと値域を検証し、失敗時は再生成・保留・人手確認へ分岐する。下流のSQLやHTMLへ無加工で渡さない。
詳細解説
誤りモデル出力をSQLやHTMLへ直接連結する
インジェクションや表示攻撃につながる。
誤りJSONらしい文字列なら検証せず保存する
型、値、必須項目が保証されない。
正しい検証に失敗した出力を再生成・保留・人手確認へ分岐する
不正な出力をそのまま実行しない。
正しい許可するスキーマ、列挙値、長さ、必須項目を検証する
出力を業務システムが安全に解釈できる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
Task 5.1の出力検証とBedrockの構造化出力を確認する。顧客分類の仮想JSONについて、必須フィールドの欠落・未許可の分類値・長すぎる文字列を検査する場所を整理し、違反時の保留経路を決める。
参考にした公式資料
確認できる内容
JSONの解析、対応するスキーマ制約、アプリ側の長さ・業務条件の検査を区別できる。
理解のポイント
- スキーマ
- 列挙値
- 失敗時分岐
確認時の注意
- 確認環境: 公式資料と仮想例による参照確認。AWS APIの呼出し、業務データの取得、後続処理の実行は不要。
- Bedrockの構造化出力は対応する制約への適合を助けるが、公式資料ではminimum/maximumやminLength/maxLengthは未対応。長さ・数値範囲を全て生成側だけに任せず、アプリ側の要件として検査する。
- 許可された分類値でも、顧客の実際の分類が正しいとは限らない。データ検証は権限確認やSQLのパラメーター化、HTMLの文脈別エンコードも置き換えない。
基礎のおさらい
形式と値の検証
構文を解析できても、必要なフィールドや許可された分類値が正しいとは限らない。下流の契約に沿って確認する。
対応するスキーマ制約
生成APIが対応する制約の範囲を確認する。アプリ側の検証器が扱える全てのJSON Schema機能を、生成APIも扱えるとは限らない。
問題IDAWS-AIF-194
確認環境公式資料と仮想例による参照確認。AWS APIの呼出し、業務データの取得、後続処理の実行は不要。
最終技術確認2026-10-25
誤り・権利侵害を報告