Azure AI Foundry の「Use pronunciation assessment – Foundry Tools」は、発音学習アプリや教育サービスで、ユーザーの音声に対して発音の正確さ・流暢さ・韻律などを評価するための公式ガイドです。結論から言うと、管理者と開発者が確認すべきポイントは、実装に使う SDK、評価モード、対応言語、リージョン、Content assessment の扱い、関連 SDK の更新期限です。特に、Go SDK では発音評価が利用できないこと、30秒を超える音声ファイルでは連続モードを使うこと、Content assessment は Speech SDK 経由のプレビュー機能としてはすでに廃止されていることを先に確認してください。(Microsoft Learn)
Azure AI Foundry の新機能・変更点：「Use pronunciation assessment – Foundry Tools」で確認すべきポイント
Azure AI Foundry の文脈で扱われる「Use pronunciation assessment – Foundry Tools」は、Azure Speech in Foundry Tools の発音評価機能を Speech SDK から利用するための実装ガイドです。発音評価は、通常の Speech to Text とは異なる専用の音声テキスト変換モデルを使い、話者の発音に対して Accuracy、Fluency などのフィードバックを返します。(Microsoft Learn)
この更新ポイントを読むときは、「新しい画面が増えたか」よりも、次の4点を確認するほうが実務では重要です。
| 確認項目 | 見るべき理由 | 実務上の判断 |
|---|---|---|
| SDK 対応状況 | 利用できない言語 SDK がある | Go SDK 前提の構成は見直す |
| 評価モード | 短い発話と長い音声で処理方法が変わる | 30秒超の音声は連続モードを検討する |
| 言語・リージョン | 対応ロケールやデータ所在に影響する | 学習対象言語と Azure リージョンを先に決める |
| Content assessment | 旧実装のままだと機能差分が出る | 必要に応じて Azure OpenAI / Foundry Models に寄せる |
そもそも pronunciation assessment で何ができるのか
Pronunciation assessment は、語学学習者の音声を評価し、発音の品質をスコアとして返す機能です。代表的なスコアには、発音の正確さを示す AccuracyScore、話し方の滑らかさを見る FluencyScore、参照テキストに対してどれだけ発話できたかを見る CompletenessScore、イントネーションやリズムなどを見る ProsodyScore があります。総合評価として PronScore も返されます。(Microsoft Learn)
評価方式は、大きく分けて「scripted assessment」と「unscripted assessment」です。
| 評価方式 | 内容 | 向いている用途 |
|---|---|---|
| scripted assessment | 事前に用意した文章を読ませて、参照テキストと比較する | 音読練習、学校教材、発音テスト |
| unscripted assessment | 参照テキストを用意せず、自由発話を評価する | スピーキング練習、面接練習、会話型学習 |
| gaming assessment | 早口言葉などを使って発音をゲーム的に評価する | 子ども向け教材、継続利用を狙う学習アプリ |
Microsoft Foundry portal では、Reading、Speaking、Gaming の3シナリオが用意されており、コードを書かずに発音評価を試せます。アプリに組み込む場合は Speech SDK を使います。(Microsoft Learn)
影響範囲：誰が確認すべきか
今回の「Use pronunciation assessment – Foundry Tools」は、単なる開発者向けサンプルではありません。教育サービス、社内研修、発音練習アプリ、グローバル人材育成ツールを運用している組織では、開発・運用・管理の各担当者に影響します。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| アプリ開発者 | SDK と評価モードの選択に影響 | 使用言語、音声時間、JSON 取得方法 |
| Azure 管理者 | リージョン、キー、課金管理に影響 | Speech リソースのリージョンとキー管理 |
| 教育サービス担当者 | スコアの見せ方に影響 | 総合点だけでなく、単語・音素単位のフィードバックを出すか |
| セキュリティ担当者 | 音声データの取り扱いに影響 | リージョン外処理の有無、保存ポリシー |
| 既存システム運用者 | 旧 Content assessment 実装に影響 | SDK バージョンと代替構成 |
特に管理者は、アプリケーションの SpeechConfig に指定するリージョンと Azure Speech リソースのリージョンが一致しているかを確認してください。Azure Speech のキーはリージョンに紐づいており、異なるリージョンのキーを使うと認証エラーになります。また、Azure Speech はデータを Speech リソースのリージョン外で保存・処理しないと説明されています。(Microsoft Learn)
更新ポイント：実装方式は「ポータルで試す」か「SDKで組み込む」かを分ける
最初に決めるべきことは、Microsoft Foundry portal で評価を試すだけなのか、本番アプリに組み込むのかです。
ポータルは、PoC や教育担当者による評価確認に向いています。Reading タブでは参照テキストを読ませる評価、Speaking タブではトピックに対する自由発話評価、Gaming タブでは早口言葉のような練習ができます。録音だけでなく、録音済み音声のアップロードにも対応しています。(Microsoft Learn)
一方、ユーザー向けアプリに組み込む場合は Speech SDK を使います。ここで注意したいのが、Go SDK では pronunciation assessment が利用できない点です。Go でバックエンドを組んでいる場合でも、発音評価部分だけは C#、Java、Python、JavaScript など別の対応 SDK を使う構成を検討する必要があります。(Microsoft Learn)
| 利用シーン | 推奨される進め方 |
|---|---|
| 機能を試したい | Microsoft Foundry portal で Reading / Speaking を試す |
| Web アプリに組み込みたい | JavaScript SDK またはバックエンド側 SDK を検討 |
| 学校・塾向け教材に組み込みたい | scripted assessment を中心に設計 |
| 会話練習アプリに組み込みたい | unscripted assessment と内容評価の扱いを確認 |
| Go ベースの構成で使いたい | 発音評価部分だけ別言語 SDK に切り出す |
30秒を超える音声では continuous mode を使う
実装でつまずきやすいのが、音声の長さです。公式ガイドでは、Speech SDK 経由のストリーミングモードは中断のない評価に対応し、録音を止めない限り評価プロセスは終了しないと説明されています。一方で、音声ファイルが30秒を超える場合は continuous mode を使う必要があります。(Microsoft Learn)
ここで重要なのは、continuous mode では EnableMiscue がサポートされない点です。Omission や Insertion のようなタグが必要な場合は、認識結果と参照テキストをアプリ側で比較する必要があります。(Microsoft Learn)
| 音声の条件 | 推奨モード | 注意点 |
|---|---|---|
| 短い単語・短文 | 単発認識または通常の評価 | 音読練習に向く |
| 30秒以下の発話 | 通常の評価で始めやすい | UX 次第でストリーミングも検討 |
| 30秒超の録音ファイル | continuous mode | EnableMiscue 非対応 |
| 長文音読・スピーチ練習 | streaming / continuous を検討 | 途中経過と最終スコアの違いに注意 |
教育アプリでは、長文音読を1回で評価させたくなります。しかし、長すぎる音声ではユーザーのミス箇所を理解しにくくなります。実務では、1段落ごとに評価する、または長文は continuous mode で処理しつつ、結果画面では文単位・単語単位に分解して表示する設計が現実的です。
設定変更で確認すべきパラメーター
Speech SDK で pronunciation assessment を使う場合、PronunciationAssessmentConfig の設計が結果の品質と使いやすさを左右します。特に ReferenceText、GradingSystem、Granularity、EnableMiscue、EnableProsodyAssessment は必ず確認してください。(GitHub)
| パラメーター | 役割 | 判断基準 |
|---|---|---|
ReferenceText | 評価対象の参照テキスト | 音読評価なら設定、自由発話なら空にする |
GradingSystem | 採点方式 | 管理画面で扱いやすいのは HundredMark |
Granularity | 評価粒度 | 発音矯正なら Phoneme、簡易評価なら Word や FullText |
EnableMiscue | 脱落・挿入などの検出 | 音読課題では有効化を検討 |
EnableProsodyAssessment | 抑揚・リズム・話速などの評価 | en-US 前提の機能として扱う |
ScenarioId | カスタム採点システム用 GUID | 標準採点で足りない場合のみ検討 |
初心者向けの実装では、まず ReferenceText を設定した scripted assessment から始めるのがおすすめです。自由発話の評価は便利ですが、認識テキストの品質やトピックとの整合性も絡むため、最初から本番採点に使うと、ユーザーに「なぜこの点数なのか」を説明しにくくなります。
ProsodyScore は便利だが、en-US 前提で設計する
EnableProsodyAssessment を有効にすると、ストレス、イントネーション、話速、リズムなどを評価する ProsodyScore を取得できます。ただし、公式ドキュメントでは prosody assessment は en-US ロケールのみで利用可能とされています。また、この機能を試すには Speech SDK 1.35.0 以降が必要です。(Microsoft Learn)
この制約は、日本語圏のサービス設計では重要です。たとえば、日本人ユーザー向けの英語発音学習アプリで en-US を対象にするなら ProsodyScore は活用しやすい一方、日本語 ja-JP の発音評価に同じフィードバックを期待すると設計ミスになります。
対応言語とロケール：日本語 ja-JP も確認対象
pronunciation assessment は複数ロケールに対応しており、公式の言語サポート表では 33 のサポートロケールが示されています。日本語 ja-JP も一覧に含まれています。対象言語が英語以外の場合は、まずサポートロケール表で対象言語を確認し、SpeechRecognizer に正しいロケールを指定してください。(Microsoft Learn)
ロケール選定で失敗しやすいのは、英語やスペイン語のように複数地域のロケールがある言語です。たとえば英語なら en-US、en-GB、en-AU などで評価傾向が変わる可能性があります。スペイン語でも es-ES と es-MX では学習対象が異なります。公式ドキュメントでも、複数ロケールがある言語ではロケールを試してシナリオに合うものを選ぶ考え方が示されています。(Microsoft Learn)
スコアは単純平均ではない：結果画面では内訳を出す
PronScore は、Accuracy、Prosody、Fluency、Completeness などを重み付けして計算されます。公式ドキュメントでは、reading scenario と speaking scenario で異なる計算式が示されており、利用可能なスコアのうち低いスコアに重みを置く考え方になっています。(Microsoft Learn)
つまり、総合点だけを表示すると、ユーザーは何を直せばよいのか分かりません。学習アプリでは、次のように表示するのが実用的です。
| 表示項目 | ユーザーに伝わること |
|---|---|
| PronScore | 全体の発音品質 |
| AccuracyScore | 音素や単語の発音が合っているか |
| FluencyScore | 不自然な間や詰まりがないか |
| CompletenessScore | 読むべき単語を読み飛ばしていないか |
| ProsodyScore | 抑揚・リズム・話速が自然か |
| ErrorType | どの単語でミスが起きたか |
特に子ども向けや初心者向けの教材では、点数だけでなく「次に練習する単語」「聞き直す箇所」「もう一度読む文」を提示すると、機能の価値が伝わりやすくなります。
Content assessment の扱い：旧実装は見直しが必要
注意すべき変更点が Content assessment です。Speech SDK 経由の Content assessment プレビューは 2025年7月に廃止されており、公式ドキュメントでは、語彙・文法・トピック関連性などの内容評価が必要な場合は Azure OpenAI models を使う代替方法が案内されています。(Microsoft Learn)
また、Use pronunciation assessment のドキュメントでも、Speech SDK 1.46.0 以降では Content assessment preview が retired であり、代替として Microsoft Foundry Models の Azure OpenAI を使う説明になっています。(Microsoft Learn)
実務では、次のように分けると安全です。
| 評価したい内容 | 推奨構成 |
|---|---|
| 発音の正確さ | pronunciation assessment |
| 音読の脱落・挿入 | scripted assessment + miscue |
| 抑揚やリズム | en-US の prosody assessment |
| 語彙・文法・トピック適合 | Azure OpenAI / Foundry Models 側で評価 |
| 高精度な文字起こし前提の自由発話評価 | 先に Azure STT で参照テキストを作り、scripted assessment を検討 |
自由発話の評価では、音声認識結果そのものの精度がスコアに影響します。公式ドキュメントでも、unscripted assessment で高精度な認識テキストに基づく評価が必要な場合は、先に Azure STT で参照テキストを取得し、その後 scripted assessment を実行する方法が推奨されています。(Microsoft Learn)
価格と課金：Prosody は追加料金の可能性を確認する
pronunciation assessment の基本利用料は、Standard または commitment tier の Speech to Text と同じ扱いとされています。Speech to Text の commitment tier を購入している場合、pronunciation assessment の利用分はコミットメントの消費にカウントされます。(Microsoft Learn)
ただし、Microsoft Foundry portal の発音評価ツールの説明では、ProsodyScore などベースラインの Speech to Text 価格に含まれない追加スコアがあり、追加料金の対象になると説明されています。Accuracy、Fluency、Completeness、Miscue はベースラインに含まれ、Prosody は含まれない整理です。(Microsoft Learn)
管理者は、本番導入前に次の観点で見積もりを作るべきです。
| 見積もり項目 | 確認内容 |
|---|---|
| 月間評価回数 | 1ユーザーあたり何回録音するか |
| 平均音声時間 | 1回あたり何秒・何分か |
| Prosody 利用有無 | en-US で使うか、追加料金を許容するか |
| 保存方針 | 音声・JSON 結果を保存するか |
| 再評価の有無 | 同じ音声を複数回評価する設計になっていないか |
移行期限：発音評価そのものより関連 SDK と旧機能を確認する
2026年7月時点で確認すべき移行・期限関連のポイントは、pronunciation assessment 本体の廃止ではなく、周辺機能と SDK 更新です。
| 項目 | 状態・期限 | 対応 |
|---|---|---|
| Content assessment preview via Speech SDK | 2025年7月に廃止済み | Azure OpenAI / Foundry Models で代替 |
| Speech SDK の CRL 対応 | Linux / Android で CRL チェック有効の場合、1.48.2 以降へ更新が必要 | 対象アプリの SDK バージョンを確認 |
| Go SDK | pronunciation assessment 非対応 | 別 SDK で実装 |
| Speech to Text REST API v3.0 / v3.1 | 2026年3月31日に retired | 関連する文字起こし処理が残っていないか確認 |
Speech SDK 1.48.2 以降には Linux と Android の CRL partitioning に関する重要修正が含まれており、CRL チェックを有効にしている場合は 2026年7月1日より前の更新が求められていました。すでに期限を過ぎているため、該当するモバイルアプリや Linux サービスが残っていないかを棚卸ししてください。(Microsoft Learn)
管理者が確認すべきチェックリスト
本番導入前に、管理者は次の順番で確認すると抜け漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 対象シナリオ | 音読評価か、自由発話評価か、ゲーム型練習か |
| 対象ロケール | en-US、ja-JP など学習対象言語を明確にする |
| SDK | Go SDK を前提にしていないか |
| 音声時間 | 30秒超のファイルを扱うか |
| 評価粒度 | FullText、Word、Phoneme のどこまで必要か |
| Prosody | en-US で使うか、追加料金を許容するか |
| Content assessment | 旧 Speech SDK 実装が残っていないか |
| リージョン | Speech リソース、キー、アプリ設定が一致しているか |
| データ管理 | 音声ファイルと評価 JSON の保存期間を決めているか |
| 人手確認 | 試験や人事評価など高リスク用途で人間の確認を入れているか |
失敗しやすいポイント
pronunciation assessment は便利ですが、採点結果をそのまま「絶対評価」として扱うとトラブルになりやすい機能です。Microsoft の Responsible AI 関連ドキュメントでも、発音評価の品質は音声入力の品質、マイクとの距離、背景ノイズ、複数話者の有無などに影響されると説明されています。単一話者の音声を、できるだけ静かな環境で、16kHz 以上の入力品質で収録することが推奨されています。(Microsoft Learn)
特に避けたいのは、次のような設計です。
| NG 設計 | 問題 | 改善策 |
|---|---|---|
| 総合点だけを表示する | 何を直せばよいか分からない | 単語・音素・エラー種別を出す |
| すべての言語で Prosody を期待する | en-US 前提の制約に引っかかる | 言語ごとに表示項目を切り替える |
| 長文を一括採点する | ユーザーが復習しにくい | 段落・文単位に分ける |
| 試験結果を AI の点数だけで決める | 音質や環境の影響を受ける | 人間のレビューを組み合わせる |
| 旧 Content assessment を使い続ける | SDK 更新で期待通り動かない可能性 | Azure OpenAI 側へ移行する |
導入時のおすすめ手順
pronunciation assessment を安全に導入するなら、最初から大規模展開せず、次の順序で進めるのが現実的です。
| 手順 | やること |
|---|---|
| 1 | Microsoft Foundry portal で Reading / Speaking を試す |
| 2 | 対象言語とロケールを決める |
| 3 | 10〜30秒程度の短い音声で scripted assessment を実装する |
| 4 | JSON 結果を保存し、Accuracy / Fluency / ErrorType の見え方を確認する |
| 5 | 必要に応じて Phoneme 粒度や Prosody を追加する |
| 6 | 長文や録音ファイルが必要なら continuous mode を検証する |
| 7 | 本番前に課金、リージョン、データ保存、SDK バージョンを確認する |
最初の PoC では、自由発話よりも参照テキストありの音読評価から始めるのがおすすめです。入力と期待結果が明確なため、開発者・教育担当者・管理者の間で「このスコアをどう解釈するか」をすり合わせやすくなります。
まとめ：次に確認すべきこと
Azure AI Foundry の「Use pronunciation assessment – Foundry Tools」で最初に確認すべきことは、機能名そのものではなく、どの評価方式を、どの SDK で、どのロケールとリージョンで使うかです。
短い音読評価なら Speech SDK の scripted assessment から始め、長い音声は continuous mode を検討します。Go SDK は非対応のため、採用技術に含まれている場合は早めに設計を見直してください。Content assessment を Speech SDK で使っていた環境では、Azure OpenAI / Foundry Models への移行が必要です。最後に、ProsodyScore や Content score は便利ですが、対応ロケールや料金、説明責任まで含めて設計することが、グローバル向けの安定運用につながります。
コメント