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

会員登録/ログイン

正解

A. システムメッセージに、キー名とデータ型を明記した出力例を 1 件示し、それ以外の文章は返さないよう指示する

正解。システムメッセージはモデルの振る舞い全体を規定する場所で、出力形式の制約を書くのに最も適しています。
キー名とデータ型を明記した出力例を 1 件示す（one-shot）ことで期待する形が具体的に伝わり、「それ以外の文章は返さない」という指示が挨拶や補足説明の混入を抑えます。
プロンプトだけでは 100% の保証にはなりませんが、有効な対策であり、構造化出力と併用するのが定石です。

B. 応答をいったんそのまま保存し、解析に失敗したレコードだけを担当者が画面から手入力で補う運用にする

解析に失敗したレコードを人が手入力で補うのは、失敗が起きた後の後始末であって、応答をスキーマどおりに受け取るための対策ではありません。
バッチの件数が増えるほど人手のコストが比例して増え、登録の遅延も残ります。
設問が求めているのは「安定して受け取るための対応」なので、要件そのものに答えていません。

正解

C. 呼び出し時に応答形式の指定（構造化出力）を有効にし、定義したスキーマに適合する応答だけを返させる

正解。構造化出力（Structured outputs）は、推論 API 呼び出しで指定した JSON スキーマ定義にモデルの応答を厳密に従わせる機能です。Chat Completions では response_format、Responses API では text.format でスキーマを定義します。
有効な JSON であることしか保証しなかった旧来の JSON モードとは対照的に、キー名・型・必須項目まで固定できるため、賃料・間取り・最寄り駅・徒歩分数を確実に取り出せます。
構造化データの抽出はまさに公式が推奨するユースケースで、本問の課題に直接効きます。

D. frequency_penalty を最大値に設定し、同じキー名が何度も出力されないようにする

frequency_penalty は同じトークンが繰り返し出現することを抑制するサンプリングパラメーターで、出力の構造を制御する機能ではありません。
最大値にすると、JSON で必然的に繰り返される記号やキー名まで出にくくなり、むしろスキーマから外れた応答を招きます。
temperature や penalty 系は表現の多様性を調整するもので、形式の保証には使えません。

E. 取り出す項目が増えるたびにモデルをファインチューニングし直し、プロンプトは短いまま運用する

ファインチューニングは出力の傾向を寄せる手段にはなりますが、取り出す項目が増えるたびに再学習するのはコストと時間が見合わず、仕様変更への追随も遅れます。
構造化出力ならスキーマ定義を書き換えるだけで項目追加に対応できます。
また「プロンプトは短いまま」とあるとおり形式の指示自体を与えないため、そもそも安定化の根拠が弱い選択肢です。

正解への思考ルート

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

要件	判断ポイント
応答に前置きの挨拶や補足説明が混ざる	出力形式の制約はシステムメッセージに書く。出力例とともに「それ以外は返さない」と明示する →選択肢（A）が正解
後続の解析処理が定義済みスキーマを前提にしている	構造化出力で JSON スキーマを指定すれば、キー名・型・必須項目に適合した応答だけが返る →選択肢（C）が正解
対応はモデル呼び出し側で完結させたい	frequency_penalty はトークンの繰り返しを抑えるパラメーターで、出力の構造には効かない →選択肢（D）を消す
取り出す項目は今後増える可能性がある（バッチ運用）	再学習は変更追随が遅くコスト高。手入力での補完は失敗後の後始末で形式の保証にならない →選択肢（B・E）を消す

ひっかけポイント

• temperature や penalty 系のパラメーターは「表現の揺れ」の調整であって出力の構造は保証しない。temperature を 0 にしても前置きの挨拶は消えない
• 旧来の JSON モード（有効な JSON であることのみ保証）と構造化出力（指定スキーマへ厳密準拠）を混同しない。公式も両者を明確に区別している
• 「解析に失敗したものだけ人が直す」は現場的で正しそうに見えるが、設問は「スキーマどおりに安定して受け取る対応」を聞いている。運用回避策は答えにならない
• 構造化出力にはスキーマ側の制約（全フィールドを required にする・additionalProperties を false にする・入れ子は 5 レベルまで等）があり、書き方を誤ると利用できない

出題バリエーション

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

問題文がこう変わったら	正解はこう変わる
「有効な JSON でありさえすればよい（キー構成は問わない）」	旧来の JSON モードでも要件を満たせる。厳密なスキーマ準拠が要るときだけ構造化出力。
「モデル自身に社内 API を呼ばせて物件情報を登録させたい」	関数呼び出し（strict オプションを有効化）が正解軸に。引数のスキーマを構造化出力で固定する。
「応答の口調や役割を固定したい」	システムメッセージによるプロンプトエンジニアリングだけで足りる。
「業界特有の言い回しを大量の例で覚えさせ、精度自体を上げたい」	ファインチューニングが選択肢に入る（形式の保証ではなく精度向上の手段）。
「社内データベースの最新情報を根拠に回答させたい」	RAG（検索拡張生成）が正解軸に。出力形式ではなく参照データの問題になる。

関連サービスの解説

Microsoft Foundry

リファレンス

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

知識項目	公式ドキュメント
構造化出力（JSON スキーマへの厳密準拠・JSON モードとの違い）	Microsoft Foundry モデルで Azure OpenAI で構造化出力を使用する方法