AI英会話のアプリが「今の発話は予約の相談だ」と見分ける層のことを意図認識と呼ぶが、その名前を冠した機能は、音声を扱う部品の側からすでに姿を消している。
消えた日付まではっきりしている。
2025年9月30日である。
Microsoft の移行ガイドは、アプリケーションが Speech を使って意図の判定を行うことはもうできない、と正面から書いている。
おもしろいのは、その名前が付いたアドレスだけが今も生きていることだ。
末尾が intent-recognition の公式ページを開いても、返ってくるのは「Azure Speech とは」という別の概要ページである。
そのページの生テキストを取得して数えたところ、「意図認識」も「IntentRecognizer」も0件だった。
機能の説明が短くなったのではなく、機能を載せていた棚ごと畳まれている。
この記事では、意味をつかむ処理がどこへ引っ越したのかを、AIの部品を売っている会社の開発者向けドキュメント3枚だけを材料に追いかける。
サービスの順位づけはしない。
仕組みの話だけをする。
【結論】AI英会話の意図認識は、聞き取りの部品から切り離されて別の層へ移った
先に答えを置く。
音声を文字にする処理と、その文字から意味を読み取る処理が、別々の製品に分かれた、というのが今回の変更の中身だ。
| 変わった場所 | 公式が書いていること |
|---|---|
| どこで意図を判定するか | Speech では行えない。Azure の言語サービスか Azure OpenAI の側で行う |
| 消えた部品 | IntentRecognizer、パターン照合の意図とエンティティ、それに付随するパラメーター |
| 作り直しの方針 | 2段階（文字起こし→意図分類）か、プロンプト1本で済ませる形のどちらか |
| 影響を受けないもの | 音声テキスト変換・テキスト読み上げ・音声翻訳。話者の分割にも変更なし |
4行目が地味に重要だ。
英語を聞き取って文字に起こす部分は、今回まったく手を付けられていない。
⇒ 止まったのは「耳」ではなく、耳と同じ箱に同居していた「読解」のほうだ。
AI英会話の意図認識①｜廃止で実際に使えなくなった部品
古い作りでは、意図の判定が音声SDKの中に組み込まれていた。
公式の移行ガイドによれば、Speech SDK はかつて IntentRecognizer というオブジェクトの一群を外に出していた。
それらが内部で頼っていたのは2種類の仕組みだ。
ひとつは LUIS（Language Understanding Intelligent Service）というアプリケーション。
もうひとつは、単純なパターン照合の構文である。
廃止によって、この両方が同時に使えなくなった。
⇒ 既存のアプリは、音声SDKの中に書いてあった意図のロジックを取り除いたうえで、外部の判定先へ繋ぎ直すことになる。
公式が示す繋ぎ直しの形は2通りしかない。
文字起こしと意図分類を順に呼ぶ2段階か、プロンプト1本で両方をまとめて済ませる形か、である。
AI英会話の意図認識②｜移行先は要件ごとに4通りに割られている
代替は1つに決め打ちされていない。
移行ガイドは、何が欲しいかによって勧める先を分けている。
| やりたいこと | 勧められている先 | 理由として書かれていること |
|---|---|---|
| ラベルを付けた学習データで、意図とエンティティをきちんと取り出したい | 会話言語理解（CLU） | 複数の意図の分類と抽出のために作られている。版の管理・テスト・分析が揃っている |
| 例をほとんど用意せずに意図を決めたい | Azure OpenAI | 見本を添えたプロンプトで動く。枠組みを変えずに素早く合わせ込める |
| 文字起こしと、要約のような推論をまとめてやりたい | Azure OpenAI と Speech の併用 | 音声を文字にしたうえで、込み入った推論を言語モデルの出力で肉付けする |
| 複数言語の音声入力を、ひとつの意図の枠に揃えたい | 音声テキスト変換と CLU の併用 | 音声側が文字起こしを受け持ち、CLU 側が正規化と分類を受け持つ |
4行とも、音声の部品が単独で完結していないことに注目したい。
どの道を選んでも、必ず2つ以上のサービスをまたぐ構成になる。
⇒ AI英会話の裏側は、1本の管からいくつかの部品を数珠つなぎにする作りへ変わった。
AI英会話の意図認識③｜処理が流れる順番は4段になった
移行ガイドには、推奨される並び方が図解として載っている。
言葉に直すと、次の4段だ。
- ①音声を文字にする＝リアルタイムでも、まとめて処理するバッチでもよい。
- ②文字を判定先へ送る＝方針しだいで CLU か Azure OpenAI のどちらかへ渡す。
- ③返ってきた答えを共通の形に揃える＝意図の名前と、抜き出した項目を持つ JSON にする。
- ④揃えた答えで処理を振り分ける＝予約、ナレッジベース、業務の流れなど、後段のサービスへ回す。
③で共通の形に揃える、という一手が効いている。
公式が例として挙げているのは、意図の名前に BookFlight、抜き出した項目に Destination と Seattle が入った形である。
判定を CLU にやらせても言語モデルにやらせても、後段から見える形は同じになる。
⇒ 判定の中身を差し替えても、アプリの後半を書き直さずに済む設計になっている。
AI英会話の意図認識④｜CLUは読み取るだけで、何も実行しない
移行先の筆頭に挙がる CLU が何者なのかを押さえておきたい。
会話言語理解の概要ページは、これを Azure の言語サービスが用意するカスタム機能のひとつとして紹介している。
中身はクラウド上の API で、自前の自然言語理解モデルを組み上げるための道具だ。
やることは2つに絞られている。
受け取った発話の全体としての意図を当てること、そしてそこから大事な情報を抜き出すことだ。
そして公式は、CLU が入力テキストを理解する知能を提供するだけで、行動は一切起こさないと断っている。
アプリに何かをさせるのは、あくまで呼び出した側の責任になる。
もうひとつ、品質の話も明記されている。
ラベル付けしたデータの質が、モデルの出来を大きく左右する、という一文だ。
⇒ 意図の判定精度は、モデルの銘柄よりも、用意した教師データの質のほうに紐づいている。
AI英会話の意図認識⑤｜組み上げ方は2本あり、手数がまるで違う
CLU には、入り口が2つ用意されている。
軽いほうは、大規模言語モデルを使って一気に展開する道だ。
- 枠組みを決める＝どんな意図を認識させたいかを並べ、その意図が何を指すのかを言葉で説明する。
- デプロイする＝言語モデル寄りの学習設定で展開し、実行用の API から呼べる状態にする。
- 予測させる＝発話から、自前の意図と、あらかじめ用意された項目を取り出す。
3手で終わる。
もう一方、自前の機械学習モデルを鍛える道は7手になる。
- 枠組みを決める → データにラベルを付ける → トレーニングする。
- 評価の内訳を見る → 弱いところを直す → デプロイする → 予測させる。
- 差はラベル付け・訓練・評価・改善の4工程まるごとであり、ここが人手のかかる部分になる。
なお、この CLU 自体にも期限が告知されている。
概要ページの冒頭には、2029年3月31日に Azure の言語サービスから引退する旨と、新規の案件は Microsoft Foundry 側へ寄せるようにという案内が置かれている。
⇒ 意図を扱う層は、ここ数年で2回引っ越しが予告されている計算になる。
AI英会話の意図認識⑥｜CLUと言語モデルは性格が正反対
移行ガイドは、2つの選択肢を5つの観点で並べている。
| 観点 | CLU | Azure OpenAI |
|---|---|---|
| 出力の形の安定 | 高い（意図と項目が定義ずみ） | 柔らかい（プロンプトで決まる） |
| 版の管理 | モデルの版が仕組みとして備わる | プロンプトの版を人が管理する |
| 学習の手間 | ラベル付きのデータセットが要る | プロンプトに例を数個置く |
| 想定外の入力 | ラベル付きデータを足して対処 | 例か手順を書き足して対処 |
| 待ち時間 | 予測用の API を1回呼ぶ | 生成の呼び出しを1回（同程度と書かれている） |
待ち時間の行が「同程度」で並んでいるのは、意外に思えるかもしれない。
どちらを選んでも、往復が1回増えること自体は変わらない、という読み方になる。
そして、二択にしなくてもよいとも書かれている。
確信度が低いときだけ言語モデル側へ回す、という組み合わせ方が、公式のよくある質問で認められている。
堅い判定を CLU に任せ、取りこぼしの受け皿を言語モデルに持たせる形だ。
AI英会話の意図認識が、学習者の画面に出てくるところ
ここまでの話を、使う側から見える現象に並べ替えてみる。
- 何往復かの会話で、足りない情報だけを少しずつ聞き返してくる＝項目を埋めながら進む複数ターンの使い方にあたる。
- 「もう一度」「次へ」と話しかけると画面が動く＝音声テキスト変換と組み合わせた命令と操作の使い方にあたる。
- 質問の種類で答える窓口が変わる＝問い合わせを仕分けて担当へ回す案内役のボットと同じ構図になる。
- 複数の機能が1つのチャットに同居している＝要求ごとに適切なサービスへ回すオーケストレーションの流れが後ろにある。
いずれも、CLU の概要ページが使用シナリオとして挙げている形だ。
一方、Azure Speech の概要ページが語学の用途として並べているのは3つだけである。
発音評価のフィードバック、遠隔の学習での会話のリアルタイム文字起こし、ニューラル音声による教材の読み上げ。
⇒ 語学向けの機能の並びに、意味の読み取りはもう入っていない。
AI英会話のアプリで会話が噛み合っていると感じるとき、その仕事をしているのは音声の部品ではなく、後ろに立っている別のサービスだということになる。
AI英会話の意図認識｜よくある質問
Q. 廃止で、英語の聞き取りの精度まで落ちたのか。 A. 公式は、この変更が音声テキスト変換・テキスト読み上げ・音声翻訳に影響しないと明記している。話者の分割についても変更は無いと書かれている。
Q. 古い仕組みで貯めたデータは捨てるのか。 A. LUIS を使っていた場合は、データを書き出して CLU へ取り込み直し、再度トレーニングする流れになると書かれている。
意図と項目の対応は、多くの場合そのまま移せるとされている。
Q. パターン照合で作っていた分はどうなるのか。 A. パターン照合の意図については、例文への変換を手作業でやる必要が出てくる場合があるとされている。
自動で移せるとは書かれていない。
Q. CLU と言語モデルは、どちらか一方を選ぶしかないのか。 A. 併用できると明記されている。
確信度が低い場面では、要約や受け皿としての分類を言語モデル側に任せる形が挙げられている。
Q. 移行が終わったら何を見張ればよいのか。 A. 公式は最後の手順として、これまで見ていた待ち時間や精度の監視を、CLU の評価ログや言語モデルの結果の追跡へ移すことを挙げている。
まとめ｜AI英会話の意図認識は「聞き取り」の外側へ出た
もう一度、要点だけ並べ直す。
- 音声サービス側の意図認識は2025年9月30日に廃止され、
IntentRecognizerとパターン照合の部品が使えなくなった。 - 置き換えの形は2つ＝文字起こしと意図分類の2段階か、プロンプト1本か。
- 移行先は要件で4通りに割られ、どれを選んでも複数のサービスをまたぐ構成になる。
- CLU は意図を当てて情報を抜くだけで、行動は起こさない。精度はラベル付けの質に左右される。
- その CLU にも2029年3月31日の引退が告知され、新規は Microsoft Foundry 側へ寄せるよう案内されている。
⇒ AI英会話で「意図をくみ取ってくれる」と感じたら、それは音声の部品の仕事ではなく、その後ろに繋いだ別のサービスの仕事だと考えたほうが構造に合っている。
※本記事の一次ソースはすべて2026-09-20に各公式ドキュメントで確認した。
仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
AIの会話を「指示・履歴・確率」の3つに分解した記事です。
言語モデルの中身まで分解した記事
Comments