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

会員登録/ログイン

A. Azure Speech で通話音声を文字起こしし、その結果を Azure Language の要約機能へ渡す

Azure Speech の音声テキスト変換で文字起こしし、Azure Language の要約機能へ渡す構成は、話した内容を要約するだけなら定番の組み合わせです。
しかし文字起こしで残るのは発話された単語だけで、声の大きさや調子、言葉に詰まった間といった話し方の様子はテキストに残りません。要約機能は受け取ったテキストしか見ないため、「声を荒らげた場面」を反映できません。さらに文字起こし→要約の 2 段構成で、ステップ最少の要件でも正解（B）に劣ります。

なお、Azure Language の要約機能は 2029 年 3 月 31 日に廃止予定です。

C. Azure Speech で文字起こしした結果に Azure Language のセンチメント分析をかけ、否定的な発言に印を付けてから要約機能へ渡す

センチメント分析（感情分析）は、テキストの言葉づかいから肯定・否定・中立を判定する機能です。否定的な発言に印を付けることはできても、判定の材料は文字起こし後のテキストだけなので、声を荒らげたかどうか・言葉に詰まったかどうかは入力に残っていません（丁寧な言葉のまま語気を強めた場面は拾えず、穏やかな口調の否定文は拾ってしまう）。
文字起こし→感情分析→要約の 3 段構成で、ステップ数も選択肢の中で最多です。

なお、Azure Language の感情分析と要約機能は 2029 年 3 月 31 日に廃止予定です。

D. テキスト入力専用の言語モデルを Microsoft Foundry からデプロイし、録音ファイルをそのまま添付して要約させる

録音をそのまま渡す 1 段構成という点は正解（B）と同じに見えますが、テキスト入力専用のモデルは音声を入力として扱えません。モデルが受け付ける入力の種類（モダリティ）はモデルごとに決まっており、モデル カタログで確認します。
音声を処理できないので要約そのものが成立せず、話し方の様子を反映する以前の問題です。「Foundry にデプロイした生成モデルなら何でも音声を読める」わけではありません。

E. Azure Speech で文字起こししたテキストを、Microsoft Foundry にデプロイしたマルチモーダル モデルへ渡して要約させる

モデルはマルチモーダルでも、渡しているのは文字起こし後のテキストです。声の調子や言葉に詰まった間は文字起こしの時点で落ちているため、モデルがどれほど高性能でも、入力に無い情報は要約に反映できません。
文字起こし→要約の 2 段構成でもあり、ステップ最少の要件でも正解（B）に劣ります。決め手はモデルの種類ではなく、何を入力として渡すかです。