最新のSpeechLLMを用いた音声データからのエンティティ抽出の1年ぶりの検証
AI Shift Tech Blog は、音声エンティティ抽出タスクにおいて過去 1 年間の LLM モデル進化を検証し、Google の最新モデルが曖昧な音声認識における課題を克服した可能性を示唆している。
キーポイント
検証の背景と目的
前回の gpt-4o-audio 検証で失敗していた「曖昧な音声からのエンティティ抽出」が、1 年後の最新モデルで解決されているかを検証する。
比較対象モデルの選定
OpenAI の gpt-4o-audio-preview（安定性確保のため継続使用）、Google Gemini 2.5 Flash Lite、および Gemini 3.0 Pro Preview を比較対象とした。
技術的アプローチと課題
8kHz にダウンサンプリングされた音声データを Base64 エンコードし、CoT（Chain of Thought）を促す詳細なプロンプトを用いて抽出を試みた。
実装の詳細と注意点
OpenAI SDK では chat.completions API を使用し、Google SDK では生成設定を調整して JSON 形式での出力を強制する実装が行われた。
最新モデルの曖昧音声対応と推論能力の進化
gemini-3.0-pro-preview は、従来のモデルが失敗した曖昧な音声でも音素レベルでの類似性を考慮し正解を導き出し、指示への追従性も向上している。
Latency 課題と実用化の展望
高精度な gemini-3.0-pro-preview は推論に 20 秒以上要し実運用には遅すぎるが、思考モードの調整や軽量モデルの登場により改善が見込まれる。
専用認識モデル不要の汎用音声 LLM の可能性
専門用語や一般的なエンティティを扱う際でも、専用の音声認識モデルがなくても最新 SpeechLLM で対応可能となり、システム設計の選択肢が広がった。
影響分析・編集コメントを表示
影響分析
本検証は、実社会での電話自動応答システムなどにおける音声処理の限界を、最新のマルチモーダル LLM がどのように突破しつつあるかを示す重要な指標となる。特に曖昧な音声への対応能力向上は、ユーザー体験の大幅な改善に直結する技術的進歩である。
編集コメント
1 年という短期間で音声認識と理解の精度が劇的に向上したことは驚異的であり、実装におけるモデル選定の重要性を再認識させる記事です。
1年振りに最新のSpeechLLMで音声データからのエンティティ抽出の検証
こんにちは、AIチームの杉山です。 本記事は AI Shift Advent Calendar 2025 15日目の記事です。
昨年のAdvent Calendarでは、OpenAI gpt-4o-audioを用いた音声データからのエンティティ抽出の検証という記事を執筆しました。
当時はまだ gpt-4o-audio-preview という名称でした。
あれから1年。 LLM界隈の進化は凄まじく、GoogleのGeminiやオープンソースモデルなど、画像や音声も入出力できるマルチモーダル対応は当たり前の機能となりました。 そこで今回は、 「1年経った今、同じタスクを最新のAIモデルで実行したら、あの時の課題は解決されているのか？」 を検証してみたいと思います。
前回の検証内容をおさらいします。 電話自動応答における「店舗予約」を想定し、以下の2パターンの音声データから、正しい店舗名（エンティティ）を抽出できるかをテストしました。
明瞭な音声 (clear_toyosu.wav)
曖昧な音声 (ambiguous_toyosu.wav)
それぞれの音声をGoogle音声認識にかけてみると前者は正しく「豊洲です」(confidence=0.97)、後者は「ナースです」(confidence=0.95)と認識されました。前者の場合であれば音声認識をしてNLP的なアプローチでも十分エンティティ抽出することができますが、後者の場合はそうはいかないため音の近さを考慮して抽出してくれることを期待します。 なお、電話自動応答プロダクトでの利用を想定しているため、音声は8kHzにダウンサンプリングしてLLMに入力しています。詳細な課題の説明は昨年の記事をご参照ください。
前回（1年前）の結果は以下の通りでした。
明瞭な音声: 音声入力からヨミを考慮して正しく「豊洲」を選ぶことができた。
曖昧な音声: モデルが回答を拒否、または関係のないエンティティを抽出し失敗。
今回の記事では、この音声データに対し現在利用可能な最新モデルで再検証を行います。
今回は比較対象として、以下の最新モデルを使用します。
OpenAI gpt-4o-audio-preview 昨年検証したgpt-4o-audioの後、gpt-audioというモデルがリリースされたが、音声を入力するとレスポンスは返ってくるものの、gpt-4o-audioのように指示に従って回答する時もあれば「音声を確認し、文字起こしと候補の中から最も近いものを選びますので、少々お待ちください。」のように音声が与えられていないような回答をするときもある。 不安定なのか用途が異なるのかは不明だが、今回は検証対象外として昨年同様gpt-4o-audioを使用。なお1年経った執筆時点でもpreviewは外れていないためモデル指定時は注意が必要。
Google gemini-2.5-flash-lite 音声対話中での利用を想定して選択した、Googleの最新の軽量モデル。
Google gemini-3.0-pro-preview 記事執筆時点での最高レベルのモデル。思考モードをoff(thinking budget=0)にできないため、レスポンスには時間がかかる。
基本的な処理の流れは前回同様です。音声ファイルをBase64エンコードし、プロンプトと共にモデルへ入力します。
現在のOpenAI SDKではResponse APIが最新ですが、現時点では音声入力に対応していないため、引き続きchat.completions APIを使用する必要があります。
import base64
from openai import OpenAI
client = OpenAI(api_key=YOUR_API_KEY)
with open(YOUR_AUDIO_FILE_PATH, "rb") as wav_file:
wav_data = wav_file.read()
encoded_string = base64.b64encode(wav_data).decode('utf-8')
completion = client.chat.completions.create(
model="gpt-4o-audio-preview",
# model="gpt-audio", 指定して動作はするが不安定
modalities=["text"],
# 出力のモーダル。音声も出力したい場合は["text", "audio"]とする。
messages=[
{
"role": "user",
"content": [
{
"type": "text",
"text": YOUR_PROMPT
},
{
"type": "input_audio",
"input_audio": {
# 入力に音声を与える場合はinput_audioとしてbase64エンコードした文字列を指定
"data": encoded_string,
"format": "wav"
}
}
],
},
]
)
print(completion.choices[0].message.content)
import base64
import os
import google.generativeai as genai
from google.generativeai import types
genai.configure(api_key=YOUR_API_KEY)
generation_config = {
"temperature": 0,
"top_p": 0.95,
"top_k": 10,
"response_mime_type": "application/json",
}
model = genai.GenerativeModel(
model_name = "gemini-2.5-flash-lite",
# Gemini-3-Proを使う場合は以下を指定
# model_name = "gemini-3-pro-preview",
generation_config=generation_config,
)
with open(YOUR_FILE_PATH, "rb") as wav_file:
wav_data = wav_file.read()
encoded_string = base64.b64encode(wav_data).decode('utf-8')
response = model.generate_content(
[
YOUR_PROMPT,
{"mime_type": "audio/wav", "data": encoded_string},
]
)
print(response.text)
プロンプトは前回より詳しく、音の近さを考慮したCoTを期待して以下の指示とします。 また、設定を少し難しくするために候補エンティティ集合は数を増やしてプロンプト中の10個としました。
まず、音声の文字起こし結果を出力してください。
次に、入力音声の認識結果から、読み方の近さを考慮して一番尤もらしいものを次の候補から選んでください。
候補:['神田', '杉山', '豊洲', '河野', '八重洲', '渋谷', '青梅', '高津', '銚子', '新宿']
入力音声は「候補＋です」のように発話される可能性があります。
最後に、選んだ理由を出力し、回答は必ず候補の中から選んでカタカナで出力してください。
回答形式は以下のようにしてください。
{
"transcription": "",
"reason": "",
"most_likely_candidate": "",
}
それでは、結果を見ていきましょう。 以降記載した結果は、出力を詳細化したためその見やすさを考慮し、今回は1回実行しただけの再現性が低い結果であることはご了承ください。また、サンプルコードには記載していませんがリクエストを送ってからレスポンスが返ってくるまでの時間を計測し、Latencyとして結果に載せています。
- 明瞭な音声 (clear_toyosu.wav)
まずは、前回も成功していた明瞭な音声です。
gpt-4o-audio-preview
{
"transcription": "豊洲です",
"reason": "認識結果の発音は「とよす」ですので、候補の中で最も近いのは「豊洲」になります。",
"most_likely_candidate": "豊洲"
}
gemini-2.5-flash-lite
{
"transcription": "神田です",
"reason": "音声認識結果は「神田です」と最も近く、発話内容も「候補＋です」の形式に合致しているため。",
"most_likely_candidate": "カンダ"
}
gemini-3.0-pro-preview
{
"transcription": "豊洲です",
"reason": "入力音声の認識結果は「トヨスデス」でした。提供された候補リストの中で、読みが「トヨス」である「豊洲」が音声と完全に一致するため選定しました。",
"most_likely_candidate": "トヨス"
}
gpt-4o-audio-preview, gemini-3.0-pro-previewは正しく豊洲を選択できています(gpt-4o-audio-previewはカタカナで出力、という指示には従っていませんが)。一方でgemini-2.5-flash-liteは誤ってしまいました。普段使っている感覚だと正解できそうに感じましたが、複数回試しても神田や杉山になりがちで、CoTや文字起こしが苦手だったりといったモデルの癖があるのかもしれません。
- 曖昧な音声 (ambiguous_toyosu.wav)
次に、前回の課題だった曖昧な音声です。
gpt-4o-audio-preview
{
"transcription": "たかつです",
"reason": "発音が「たかつです」と聞こえたため、候補の中で最も近い「高津」を選びました。",
"most_likely_candidate": "高津"
}
gemini-2.5-flash-lite
{
"transcription": "神田です",
"reason": "音声認識結果は「神田です」と最も近く、候補の中から読み方が最も尤もらしい「カンダ」と発音されているため。",
"most_likely_candidate": "カンダ"
}
gemini-3.0-pro-preview
{
"transcription": "Does desu",
"reason": "音声認識結果の「Does」は、発音記号で/dʌz/や/doʊz/となり、候補の中で音韻的に最も近いのは「豊洲（トヨス）」です。「Does」の語頭の破裂音/d/は「トヨス」の/t/（有声音と無声音の関係）に近く、語尾の/z/または/s/の響きも共通しています。「八重洲（ヤエス）」は語頭が/y/であり、「Does」の音とは距離があります。",
"most_likely_candidate": "トヨス"
}
昨年同様gpt-4o-audio-previewと、gemini-2.5-flash-liteも正解することはできませんでした。一方で、gemini-3.0-pro-previewはついに正解することができました。reasoningの内容も、4年前のAdvent Calendarに書いた記事(音声認識結果とエンティティ候補との音素列アラインメントによるマッチングの検証)でやりたいと考えていた
モチベーションとしては読みを用いた編集距離やアラインメントよりも、「sh」と「ch」や「hy」と「ky」の類似性を考慮できるのではないかと考えたためです。
のような音的な近さを考慮した(ように見える)エンティティ抽出が行えています。
Latencyに関しては、上2つはどちらも2秒弱でレスポンスが返ってきています。音声対話中にエンティティ抽出だけで2秒弱かかるのは少し遅く感じますが、相槌などで推論時間を稼ぐなどの工夫である程度軽減できそうです。gemini-3.0-pro-previewは20秒以上かかっており、正解はできているもののこのままでは音声対話中に使用するのは厳しそうです。今後思考モードがoffにできるようになったり、gemini 3系の軽量モデルが出た際には都度検証し、プロダクトへの適用可能性を探っていきたいと思います。
今回は、1年前に検証したSpeechLLMによるエンティティ抽出を最新モデルで再評価しました。
この1年でのモデルの進化は、単なる精度の向上だけでなく、指示に対する追従性や曖昧さへの対処という点でも進展が見られました。従来のカスケード型音声対話システムでは音声認識→テキストでの言語理解が一般的でしたが、汎用的な音声認識器では専門用語のような一般的でないエンティティの認識が困難でした。そういったケースに特化した専用の音声認識モデルがなくても、今回のような仕組みで認識できるようになる可能性が見えてきました。 一方で、抽出(リンキング)対象のエンティティ集合が、たとえば取引先会社名や小売店の取り扱い商品名など数千・数万以上になったときにどうすべきかなどといった問題点も残っており、Latencyの課題も含めLLM一つで全てが解決できるものではなく、我々としては引き続き実運用で使える機能の開発に取り組んでいきます。
AI Shiftでは、こうした最新のマルチモーダル技術をいち早くキャッチアップし、電話自動応答をはじめとするプロダクトの体験向上に取り組んでいます。 音声対話の未来を一緒に作りたいエンジニアの方、ぜひお話ししましょう！ 少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか？ （オンライン・19時以降の面談も可能です！）
【面談フォームはこちら】 https://hrmos.co/pages/cyberagent-group/jobs/1826557091831955459
原文を表示
1年振りに最新のSpeechLLMで音声データからのエンティティ抽出の検証
こんにちは、AIチームの杉山です。 本記事は AI Shift Advent Calendar 2025 15日目の記事です。
昨年のAdvent Calendarでは、OpenAI gpt-4o-audioを用いた音声データからのエンティティ抽出の検証という記事を執筆しました。
当時はまだ gpt-4o-audio-preview
あれから1年。 LLM界隈の進化は凄まじく、GoogleのGeminiやオープンソースモデルなど、画像や音声も入出力できるマルチモーダル対応は当たり前の機能となりました。 そこで今回は、 「1年経った今、同じタスクを最新のAIモデルで実行したら、あの時の課題は解決されているのか？」 を検証してみたいと思います。
前回の検証内容をおさらいします。 電話自動応答における「店舗予約」を想定し、以下の2パターンの音声データから、正しい店舗名（エンティティ）を抽出できるかをテストしました。
明瞭な音声 (clear_toyosu.wav
曖昧な音声 (ambiguous_toyosu.wav
それぞれの音声をGoogle音声認識にかけてみると前者は正しく「豊洲です」(confidence=0.97)、後者は「ナースです」(confidence=0.95)と認識されました。前者の場合であれば音声認識をしてNLP的なアプローチでも十分エンティティ抽出することができますが、後者の場合はそうはいかないため音の近さを考慮して抽出してくれることを期待します。 なお、電話自動応答プロダクトでの利用を想定しているため、音声は8kHzにダウンサンプリングしてLLMに入力しています。詳細な課題の説明は昨年の記事をご参照ください。
前回（1年前）の結果は以下の通りでした。
明瞭な音声: 音声入力からヨミを考慮して正しく「豊洲」を選ぶことができた。
曖昧な音声: モデルが回答を拒否、または関係のないエンティティを抽出し失敗。
今回の記事では、この音声データに対し現在利用可能な最新モデルで再検証を行います。
今回は比較対象として、以下の最新モデルを使用します。
OpenAI gpt-4o-audio-preview 昨年検証したgpt-4o-audioの後、gpt-audioというモデルがリリースされたが、音声を入力するとレスポンスは返ってくるものの、gpt-4o-audioのように指示に従って回答する時もあれば「音声を確認し、文字起こしと候補の中から最も近いものを選びますので、少々お待ちください。」のように音声が与えられていないような回答をするときもある。 不安定なのか用途が異なるのかは不明だが、今回は検証対象外として昨年同様gpt-4o-audioを使用。なお1年経った執筆時点でもpreviewは外れていないためモデル指定時は注意が必要。
Google gemini-2.5-flash-lite 音声対話中での利用を想定して選択した、Googleの最新の軽量モデル。
Google gemini-3.0-pro-preview 記事執筆時点での最高レベルのモデル。思考モードをoff(thinking budget=0)にできないため、レスポンスには時間がかかる。
基本的な処理の流れは前回同様です。音声ファイルをBase64エンコードし、プロンプトと共にモデルへ入力します。
現在のOpenAI SDKではResponse APIが最新ですが、現時点では音声入力に対応していないため、引き続きchat.completions APIを使用する必要があります。
import base64 from openai import OpenAI client = OpenAI(api_key=YOUR_API_KEY) with open(YOUR_AUDIO_FILE_PATH, "rb") as wav_file: wav_data = wav_file.read() encoded_string = base64.b64encode(wav_data).decode('utf-8') completion = client.chat.completions.create( model="gpt-4o-audio-preview", # model="gpt-audio", 指定して動作はするが不安定 modalities=["text"], # 出力のモーダル。音声も出力したい場合は["text", "audio"]とする。 messages=[ { "role": "user", "content": [ { "type": "text", "text": YOUR_PROMPT }, { "type": "input_audio", "input_audio": { # 入力に音声を与える場合はinput_audioとしてbase64エンコードした文字列を指定 "data": encoded_string, "format": "wav" } } ] }, ] ) print(completion.choices[0].message.content)
import base64 import os import google.generativeai as genai from google.generativeai import types genai.configure(api_key=YOUR_API_KEY) generation_config = { "temperature": 0, "top_p": 0.95, "top_k": 10, "response_mime_type": "application/json", } model = genai.GenerativeModel( model_name = "gemini-2.5-flash-lite", # Gemini-3-Proを使う場合は以下を指定 # model_name = "gemini-3-pro-preview", generation_config=generation_config, ) with open(YOUR_FILE_PATH, "rb") as wav_file: wav_data = wav_file.read() encoded_string = base64.b64encode(wav_data).decode('utf-8') response = model.generate_content( [ YOUR_PROMPT, {"mime_type": "audio/wav", "data": encoded_string}, ] ) print(response.text)
プロンプトは前回より詳しく、音の近さを考慮したCoTを期待して以下の指示とします。 また、設定を少し難しくするために候補エンティティ集合は数を増やしてプロンプト中の10個としました。
まず、音声の文字起こし結果を出力してください。 次に、入力音声の認識結果から、読み方の近さを考慮して一番尤もらしいものを次の候補から選んでください。 候補:['神田', '杉山', '豊洲', '河野', '八重洲', '渋谷', '青梅', '高津', '銚子', '新宿'] 入力音声は「候補＋です」のように発話される可能性があります。 最後に、選んだ理由を出力し、回答は必ず候補の中から選んでカタカナで出力してください。 回答形式は以下のようにしてください。 { "transcription": "", "reason": "", "most_likely_candidate": "", }
それでは、結果を見ていきましょう。 以降記載した結果は、出力を詳細化したためその見やすさを考慮し、今回は1回実行しただけの再現性が低い結果であることはご了承ください。また、サンプルコードには記載していませんがリクエストを送ってからレスポンスが返ってくるまでの時間を計測し、Latencyとして結果に載せています。
- 明瞭な音声 (clear_toyosu.wav)
まずは、前回も成功していた明瞭な音声です。
gpt-4o-audio-preview
{ "transcription": "豊洲です", "reason": "認識結果の発音は「とよす」ですので、候補の中で最も近いのは「豊洲」になります。", "most_likely_candidate": "豊洲" }
gemini-2.5-flash-lite
{ "transcription": "神田です", "reason": "音声認識結果は「神田です」と最も近く、発話内容も「候補＋です」の形式に合致しているため。", "most_likely_candidate": "カンダ" }
gemini-3.0-pro-preview
{ "transcription": "豊洲です", "reason": "入力音声の認識結果は「トヨスデス」でした。提供された候補リストの中で、読みが「トヨス」である「豊洲」が音声と完全に一致するため選定しました。", "most_likely_candidate": "トヨス" }
gpt-4o-audio-preview, gemini-3.0-pro-previewは正しく豊洲を選択できています(gpt-4o-audio-previewはカタカナで出力、という指示には従っていませんが)。一方でgemini-2.5-flash-liteは誤ってしまいました。普段使っている感覚だと正解できそうに感じましたが、複数回試しても神田や杉山になりがちで、CoTや文字起こしが苦手だったりといったモデルの癖があるのかもしれません。
- 曖昧な音声 (ambiguous_toyosu.wav)
次に、前回の課題だった曖昧な音声です。
gpt-4o-audio-preview
{ "transcription": "たかつです", "reason": "発音が「たかつです」と聞こえたため、候補の中で最も近い「高津」を選びました。", "most_likely_candidate": "高津" }
gemini-2.5-flash-lite
{ "transcription": "神田です", "reason": "音声認識結果は「神田です」と最も近く、候補の中から読み方が最も尤もらしい「カンダ」と発音されているため。", "most_likely_candidate": "カンダ" }
gemini-3.0-pro-preview
{ "transcription": "Does desu", "reason": "音声認識結果の「Does」は、発音記号で/dʌz/や/doʊz/となり、候補の中で音韻的に最も近いのは「豊洲（トヨス）」です。「Does」の語頭の破裂音/d/は「トヨス」の/t/（有声音と無声音の関係）に近く、語尾の/z/または/s/の響きも共通しています。「八重洲（ヤエス）」は語頭が/y/であり、「Does」の音とは距離があります。", "most_likely_candidate": "トヨス" }
昨年同様gpt-4o-audio-previewと、gemini-2.5-flash-liteも正解することはできませんでした。一方で、gemini-3.0-pro-previewはついに正解することができました。reasoningの内容も、4年前のAdvent Calendarに書いた記事(音声認識結果とエンティティ候補との音素列アラインメントによるマッチングの検証)でやりたいと考えていた
モチベーションとしては読みを用いた編集距離やアラインメントよりも、「sh」と「ch」や「hy」と「ky」の類似性を考慮できるのではないかと考えたためです。
のような音的な近さを考慮した(ように見える)エンティティ抽出が行えています。
Latencyに関しては、上2つはどちらも2秒弱でレスポンスが返ってきています。音声対話中にエンティティ抽出だけで2秒弱かかるのは少し遅く感じますが、相槌などで推論時間を稼ぐなどの工夫である程度軽減できそうです。gemini-3.0-pro-previewは20秒以上かかっており、正解はできているもののこのままでは音声対話中に使用するのは厳しそうです。今後思考モードがoffにできるようになったり、gemini 3系の軽量モデルが出た際には都度検証し、プロダクトへの適用可能性を探っていきたいと思います。
今回は、1年前に検証したSpeechLLMによるエンティティ抽出を最新モデルで再評価しました。
この1年でのモデルの進化は、単なる精度の向上だけでなく、指示に対する追従性や曖昧さへの対処という点でも進展が見られました。従来のカスケード型音声対話システムでは音声認識→テキストでの言語理解が一般的でしたが、汎用的な音声認識器では専門用語のような一般的でないエンティティの認識が困難でした。そういったケースに特化した専用の音声認識モデルがなくても、今回のような仕組みで認識できるようになる可能性が見えてきました。 一方で、抽出(リンキング)対象のエンティティ集合が、たとえば取引先会社名や小売店の取り扱い商品名など数千・数万以上になったときにどうすべきかなどといった問題点も残っており、Latencyの課題も含めLLM一つで全てが解決できるものではなく、我々としては引き続き実運用で使える機能の開発に取り組んでいきます。
AI Shiftでは、こうした最新のマルチモーダル技術をいち早くキャッチアップし、電話自動応答をはじめとするプロダクトの体験向上に取り組んでいます。 音声対話の未来を一緒に作りたいエンジニアの方、ぜひお話ししましょう！ 少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか？ （オンライン・19時以降の面談も可能です！）
【面談フォームはこちら】 https://hrmos.co/pages/cyberagent-group/jobs/1826557091831955459
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み