IBMはHugging Face上で、Granite Speechファミリーの新モデルとして「granite-speech-5.0-470m-turboctc」と「granite-speech-5.0-470m-turboctc-nc」を公開した。いずれも英語音声認識に特化した470Mパラメータ規模のコンパクトなモデルで、同社は高い認識精度と非常に高い処理速度の両立を前面に出している。原文によれば、NVIDIA H200 GPU上のバッチ推論では12,600 RTFx超を記録し、これは1秒間に3.5時間以上の音声を書き起こせる計算になる。



ここでいうRTFxは、リアルタイムに対して何倍の速度で音声を処理できるかを示す指標だ。たとえば1時間の録音を1分で処理できれば60 RTFxとなる。12,600 RTFx超という表現は、単に「速い」という印象論ではなく、大量の会議録、コールセンター音声、メディア素材などをまとめて処理する用途で、処理待ち時間を大きく短縮し得ることを意味する。

ただし、この性能はNVIDIA H200という高性能GPUを使ったバッチ推論での結果であり、すべての環境で同じ速度が出るわけではない。企業で導入を考える場合は、手元のGPU、CPU、バッチサイズ、音声の長さ、前処理や後処理を含めた全体パイプラインで実測する必要がある。それでも、音声認識モデルの評価軸が精度だけでなく、処理速度、モデルサイズ、導入形態へ広がっていることを示す発表として注目できる。

今回公開された2モデルは、名前はよく似ているが、企業利用の観点では違いを慎重に見る必要がある。granite-speech-5.0-470m-turboctcはApache 2.0ライセンスで提供される。一方、granite-speech-5.0-470m-turboctc-ncは追加データで学習されているが、ライセンスはCC-BY-NC-SA-4.0で、非商用利用を前提とする。研究や評価では後者も有用だが、商用サービスや社内業務システムへの組み込みでは、ライセンス条件の確認が欠かせない。



原文では、非商用モデルのほうが多くのテストセットでわずかに高い精度を示したとされている。OpenASR Leaderboardの公開英語短文テストセットにおける非公式結果では、非商用モデルが集計WER 4.85%、Apache 2.0モデルが5.00%だった。WERはWord Error Rate、つまり単語誤り率を指し、低いほど認識結果が正確であることを意味する。差は大きくはないが、追加データの効果が一定程度見える結果だといえる。

企業にとって重要なのは、最高精度のモデルを選ぶことだけではない。法務上使えるライセンスか、モデルの入手経路が安定しているか、再学習や派生利用にどのような制約があるか、顧客データを扱うシステムに組み込んでよいかといった点が実務上の判断材料になる。今回の2モデルは、評価用には非商用モデル、実装候補にはApache 2.0モデルというように、目的に応じた使い分けがしやすい構成になっている。

IBMは、OpenASR Leaderboardで使われる英語短文の公開テストセットに対する非公式結果を示している。原文によれば、推論はHugging Face Jobsを使い、スコアリングはOpenASR Leaderboardのツールで行われたため、WERとRTFxの値は公式結果と一致する見込みだという。公開テストセットに限定した値である点には注意が必要だが、比較可能な手順で速度と精度を並べて見せている点は、導入検討者にとって参考になる。



この発表で特に目を引くのは、モデルサイズとスループットの組み合わせだ。470Mパラメータという規模は、現在の巨大な生成AIモデルと比べれば小さいが、音声認識タスクにおいては十分に実用的な精度を狙えるサイズである。原文では、両モデルが高い精度を示しつつ、12,600 RTFxを超える集計スループットを達成したと説明されている。大量処理を前提とする業務では、数%の精度差だけでなく、処理コストや待ち時間の差が事業上の価値に直結する。

また、遠距離音声認識を扱うFFASR Leaderboardでも良好な結果が示されている。2026年8月25日時点の公式結果として、Apache 2.0モデルは精度で9位、非商用モデルは5位に入り、さらに両モデルは最速の2モデルでもあったと原文は述べている。遠距離音声は、会議室、講義、現場作業、店舗など、マイクと話者の距離が一定しない環境に近い。日本企業が社内会議や現場音声の自動記録を検討する際にも、この観点は重要になる。

Granite Speech 5.0の新モデルは、過去のGranite Speechモデルとは構成が異なる。従来モデルは音響エンコーダ、プロジェクタ、Granite LM、LoRAアダプタを組み合わせていたが、今回のモデルはエンコーダ専用モデルとして設計されている。原文では、この設計により、強い文字起こし性能、小さなメモリフットプリント、470Mパラメータという規模、そして従来のGranite Speechモデルより20倍超のスループットを実現したと説明している。



一方で、エンコーダ専用にしたことには明確なトレードオフがある。言語モデルを組み合わせた従来型モデルが備えていた音声翻訳やキーワードバイアシングといった能力の一部は、今回のモデルでは手放している。キーワードバイアシングとは、特定の固有名詞や専門用語を認識しやすくする調整のことで、医療、法律、金融、製造業のように専門用語が多い領域では重要になる場合がある。

つまり、Granite Speech 5.0 TurboCTCは「何でもできる音声AI」ではなく、英語音声を高速にテキスト化する用途に焦点を絞ったモデルと捉えるのが自然だ。会議録の一次文字起こし、通話ログの検索用テキスト化、動画アーカイブの字幕生成前処理など、後段に要約や検索、分類の処理を置くワークフローでは、この割り切りがむしろ強みになる。特にエッジデバイス向けの音声テキスト化に適していると原文が述べている点は、クラウド集中型ではないAI活用を考える企業にとって示唆がある。

モデル内部について、原文はGranite Speech 5.0が従来のGranite Speechで使われてきたエンコーダと多くを共有していると説明している。具体的には、16層のConformerブロックで構成され、8番目のブロック出力にセルフコンディショニングを使い、標準的なドット積アテンションで生じる系列長に対する二乗スケーリングを避けるためにチャンク単位のアテンションを採用し、学習ではCTC損失を最適化している。



Conformerは、音声認識で広く使われるニューラルネットワーク構成の一つで、Transformer系の注意機構と畳み込み処理を組み合わせることで、長い文脈と局所的な音響パターンの両方を扱いやすくする。CTCはConnectionist Temporal Classificationの略で、音声フレームと文字列の厳密な位置合わせがなくても学習できる手法だ。日本の読者向けに言い換えると、音声のどの瞬間がどの文字に対応するかを人手で細かく指定しなくても、発話全体と書き起こし文から学習しやすい仕組みである。

新モデルの特徴は、従来よりも低いトークンレートで動く点にある。過去のエンコーダは毎秒50文字を生成していたが、Granite Speech 5.0では毎秒12.5トークンに抑えられている。非商用モデルはSentencePiece、Apache 2.0モデルはBPEによるトークン化を使い、いずれも音声トランスクリプトでトークナイザーを学習している。処理する系列が短くなれば、推論時の計算負荷を下げやすい。精度を保ちながらどこまで系列を圧縮できるかが、高速化の鍵になっている。

音声認識では、入力音声をそのままモデルに渡すのではなく、一般に特徴量へ変換してから処理する。原文では、log Mel spectrogramのフロントエンドが毎秒100フレームを生成し、そこから毎秒12.5トークンまで落とすために、2倍のサブサンプリングを3段階使うと説明している。100を2で割り、さらに2で割り、もう一度2で割ると12.5になる。これは単純な数式だが、実装上はモデルの速度とメモリ消費に直結する重要な設計である。



最初の段階では、隣り合うlog Mel特徴ベクトルを単純なreshape操作でまとめる。この方式は過去のGranite Speechモデルのエンコーダでも使われていた。2段階目と3段階目は、16層あるConformerブロックのうち最初の2ブロックに組み込まれ、ストライド付き畳み込みによって時間方向のダウンサンプリングを行う。音声の時間方向の長さを早い段階で短くすることで、後続層の計算を軽くできる。

原文では、時間方向のサブサンプリングを行うConformerブロックと標準的なConformerブロックの違いも説明されている。変更点は主に2つあり、畳み込みブロックがstride=2の時間畳み込みを行うこと、そして畳み込みブロックの残差側も隣り合う2位置の平均を取って時間方向にサブサンプリングすることだ。標準ConformerブロックはPhil Wang氏のlucidrains実装に従いつつ、チャンク単位のアテンションとPyTorchのscaled_dot_product_attention()を利用している。こうした地味な設計の積み重ねが、実務で効く高速化につながっている。

Granite Speech 5.0の学習には、自然音声データと合成データの両方が使われている。自然音声データとしては、MLS、YODAS、CommonVoice-17、Librispeech、VoxPopuli、AMI、Earnings-22が両モデルで使われ、非商用モデルではさらにGigaSpeechとSPGI Speechが使われている。時間数としては、MLSが44,600時間、YODASが8,900時間、CommonVoice-17が2,500時間、Librispeechが960時間などと原文に記載されている。



ここで重要なのは、非商用モデルが追加データによって精度面でやや有利になる一方、そのライセンスが商用利用に制約を持つことだ。モデル評価ではついスコアだけを見たくなるが、実務導入では「どのデータで学習されたか」と「どのライセンスで使えるか」がセットで問われる。特に音声データは、収集元、話者の同意、用途制限、再配布条件が問題になりやすい領域である。公開モデルを使う場合でも、社内の法務・セキュリティ確認を前提にすべきだ。

合成データについては、3種類が挙げられている。MLS、YODAS、CommonVoice-17、VoxPopuli、AMIの単一話者セグメントを連結して作った2,000時間の複数話者データ、Earnings-22の単一話者セグメントを連結して作った500時間の複数話者データ、そして数字、通貨、ウェブサイト名、電話番号、住所、小数点やドットを含む項目を含む240時間の発話データである。最後のデータはgpt-oss-120bまたはgpt-oss-20bで生成し、StyleTTS2で音声合成されたと説明されている。数字やURL、電話番号は業務音声で誤りが目立ちやすい要素であり、そこを合成データで補う発想は実用的だ。

Granite Speech 5.0 TurboCTCは、Hugging FaceのTransformersでネイティブにサポートされる。原文では、次回のTransformersリリースまではGitHubのソースからインストールする手順が示されている。サンプルコードでは、datasetsとtransformersを使い、AutoProcessorとAutoModelForCTCでモデルを読み込み、LibriSpeechのダミーデータを使って複数音声をまとめて処理し、batch_decodeでテキスト化している。



サンプル中で興味深いのは、processorにdevice=model.deviceを渡し、log-melフロントエンドをモデルのアクセラレータ上で計算している点だ。原文のコメントでは、これによりホストからデバイスへのコピーを節約できると説明されている。高速な音声認識では、モデル本体の推論だけでなく、音声読み込み、リサンプリング、特徴量抽出、GPU転送、バッチ化、後処理まで含めた全体最適化が必要になる。モデルが速くても、周辺処理が詰まればシステム全体の処理能力は伸びない。

本番環境で使う場合は、いくつかの論点がある。まず対象は英語音声認識であり、日本語音声認識モデルではない。日本企業でも、グローバル会議、海外拠点の通話、英語ウェビナー、海外ニュースや決算説明会の分析などでは使い道があるが、日本語の会議録用途には別の評価が必要だ。次に、ストリーミング処理の応答性を確認するためのWebGPUデモが用意されているものの、原文ではChromeまたはEdgeブラウザでのみ動作するとされている。検証時には利用環境の制約も見ておきたい。

今回の発表は、生成AIニュースとしては派手な対話AIや巨大モデルの話題に比べると地味に見えるかもしれない。しかし、B2Bの現場では音声認識の高速化と小型化は実用上の価値が大きい。会議、商談、サポート通話、研修動画、現場報告など、企業内には音声のまま眠っている情報が多い。これを検索可能なテキストへ変換できれば、ナレッジ共有、監査、品質管理、要約、FAQ作成などの後続プロセスにつなげられる。



ただし、導入の成否はモデル単体では決まらない。音声データをどこに保存するか、個人情報や機密情報をどう扱うか、話者分離やノイズ除去をどう組み合わせるか、誤認識を人がどの段階で確認するか、生成AIによる要約や分類に渡す前にどの程度整形するかといった運用設計が必要になる。英語音声認識であっても、グローバル企業では地域ごとのアクセントや業界用語、録音品質のばらつきが結果に影響する。

Granite Speech 5.0 TurboCTCのような小型・高速モデルは、音声を大規模に前処理する基盤部品として捉えると理解しやすい。すべてを一つの巨大なマルチモーダルモデルに任せるのではなく、音声認識、翻訳、要約、検索、分類を役割ごとに分ける構成では、こうした専用モデルがコストと速度の面で効いてくる可能性がある。日本の企業が注目すべきなのは、単に新モデルのスコアではなく、音声データを業務知識へ変えるパイプライン全体の中で、この種のモデルをどこに置くかという設計である。