AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. 抽出したいフィールドの正解例を大量に用意し、その出力形式に沿うようモデルをファインチューニングする

ファインチューニングは出力の傾向を寄せる手法であり、毎回スキーマに厳密一致することを保証しません。学習データを大量に用意する初期コストと、CMMS のスキーマが変わるたびに再学習が必要になる保守コストも重くのしかかります。
構造化出力の指定だけで満たせる要件に対してモデルのカスタマイズを持ち出すのは、典型的な過剰対応です。

B. 必要なフィールドごとに個別にモデルを呼び出し、返ってきた断片を後段のアプリケーションコードで1件のレコードに組み立てる

フィールドごとにモデルを呼び分ければ 1 回あたりの出力は単純になりますが、各呼び出しの出力形式が保証されない点は変わりません。
加えて呼び出し回数が項目数だけ増えるためコストとレイテンシーが悪化し、同じ文字起こしを何度も読ませることでフィールド間の整合（同一設備・同一事象であること）も崩れやすくなります。組み立てロジックというアプリ側の保守対象も増えるだけです。

正解

C. JSON Schema を定義し、モデルの出力がそのスキーマ（型・必須項目）に準拠するよう制約付きで生成させる

JSON Schema を定義し、モデルの出力がそのスキーマに準拠するよう制約付きで生成させる方式です。Amazon Bedrock の構造化出力では Converse API の outputConfig.textFormat に type=json_schema とスキーマを渡すことで、スキーマは文法にコンパイルされ、応答がスキーマ（型・必須項目）に準拠することが保証されます。
サポート外のスキーマ機能は呼び出し時に 400 エラーとして即座に弾かれるため、「登録直前になってバリデーションで落ちる」事態を上流で防げます。
下流の CMMS が解析可能な JSON を確実に受け取れる、要件に直結した唯一の正解です。

D. Amazon Comprehend のカスタムエンティティ認識を使い、モデルが返した自由記述の回答文からフィールド値を後処理で抽出する

Amazon Comprehend のカスタムエンティティ認識は、テキストから固有表現を抽出する別の ML モデルであり、学習データ用意・カスタムモデルの学習とエンドポイント運用という負荷が加わります。
しかも抽出結果が CMMS のスキーマ（型・必須項目）を満たす保証はなく、自由記述の応答を後から解析するという壊れやすい設計のままです。優先度のような文脈依存の判定にも向きません。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
CMMS は列の型と必須項目が厳格に定義されたスキーマを持つ	型・必須項目まで含めて機械的に強制できるのは JSON Schema による制約付き生成 →選択肢（C）が正解
応答が毎回スキーマに一致することを「保証」したい	傾向を寄せるだけの手法（学習・プロンプト）は保証にならない →選択肢（A）を消す
バリデーションで弾かれると点検記録自体が失われる	失敗を後段で検知するのではなく、生成の時点で形式違反を起こさせない設計にする →選択肢（D）を消す
音声メモの文字起こしから 4 項目をまとめて抽出する	1 回の呼び出しで 1 レコード分を構造化して返させるのが素直。項目ごとの分割呼び出しはコストとレイテンシーが増えるだけ →選択肢（B）を消す

ひっかけポイント

• 「大量の正解例でファインチューニング」は精度が上がりそうに見えるが、形式の保証にはならず、スキーマ変更のたびに再学習が必要になる。構造化出力で済む要件に持ち出さない
• 選択肢 B の分割呼び出しは「単純な出力なら失敗しにくい」という直感に訴えるが、形式保証が無いという本質は変わらず、呼び出し回数とレイテンシー・コストだけが増える
• 選択肢 D は「AWS の ML サービスを使う」ので正しく見えるが、Amazon Comprehend は自由記述からの抽出器であってスキーマ強制の仕組みではない。後処理で拾う設計自体が要件（保証）に反する
• 「プロンプトに JSON の例を書けば十分」という発想も同じ穴。例示は誘導、JSON Schema の指定は強制で、要件が「保証」なら後者しかない

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「抽出した値が原文に実在するかまで検証したい」	形式ではなく事実性の問題。グラウンディング（原文との意味的類似度チェック）や Guardrails の根拠確認が正解軸に。
「モデルに外部システムの API を呼ばせて登録まで行わせたい」	Converse API の ツール利用（tool use）と、strict モードによる入力スキーマ検証が正解軸に。
「文字起こし自体を音声から生成する部分も含めて設計したい」	Amazon Transcribe による文字起こし＋ Amazon Bedrock による構造化抽出のパイプラインが問われる。
「大量の点検記録を夜間にまとめて処理したい」	リアルタイム呼び出しではなくバッチ推論によるコスト最適化が正解軸に。

関連サービスの解説

Amazon Bedrock

リファレンス

この問題を解くために必要な知識を扱う公式ドキュメントです。

知識項目	公式ドキュメント
JSON Schema による構造化出力（Converse API の outputConfig.textFormat）	モデルから検証済みの JSON 結果を取得する - Amazon Bedrock