AI 文字起こしの料金は据え置き：Grok Voice Transcribe 2.0移行ガイド

実際に変わったこと

xAIは2026年9月18日、Grok Voice Transcribe 2.0をリリースしました。録音済みまたはリアルタイムの音声を、別のプロダクトやワークフローで使えるテキストへ変換する現行の音声認識モデルとして、Grok Voice Transcribe 1.0を置き換えます。

動作モードは2つで、違いは明快です。バッチは、録音後のファイルまたは音声URLをRESTエンドポイントへ送ります。ストリーミングは、話している最中の音声をWebSocket経由で送信します。そのため、字幕やエージェントの応答、リアルタイム支援は通話終了を待たずに反応できます。

リリースページによると、既存のインテグレーションはコードを変更しなくても2.0モデルへ移行できます。一見すると手間のない変更ですが、運用担当者が注意すべき点もまさにそこです。リクエストでモデルを指定しなければ、出力がいつ変わるかはプロバイダー側に委ねられます。

料金表に変更はありません。バッチは音声1時間あたり$0.10、ストリーミングは音声1時間あたり$0.20のままです。話者ごとに発言を分ける話者ダイアライゼーションに加え、単語単位のタイムスタンプと重要語句のバイアス調整も、この料金に含まれます。

AI 文字起こしAPIの料金は据え置きでも、運用コストは変わり得る

API単体の計算はシンプルです。

ストリーミングはバッチの2倍の料金です。音声1,000時間では、差額は$100になります。ライブ字幕、リアルタイムの通話支援、次の発話を判断する音声エージェントのように、録音完了を待つとプロダクトとして成立しない場面なら、この追加費用には意味があります。

すでにストレージにある音声をストリーミングしても、それだけで文字起こしの有用性が高まるわけではありません。メディアアーカイブ、ポッドキャストの未処理分、録音済みインタビュー、夜間の通話レビュー処理は、通常はバッチを使い、低い料金を維持するのが妥当です。

API料金は予算の一部にすぎません。運用で役立つ計算式は次のとおりです。

文字起こしの総コスト = 音声API費用 + 人による修正コスト + 後工程のやり直しコスト

最初の項目は料金表から確定できます。2つ目は、レビュー時間と担当者の諸経費込み時間単価で決まります。3つ目は、単語、話者ラベル、タイムスタンプ、数値の表記が変わり、字幕ファイル、品質スコア、CRMメモ、検索インデックス、自動処理などに影響したときに発生します。

これが今回のリリースが事業にもたらす意味です。音声処理の支出がまったく変わらなくても、実用に耐える文字起こしを作る総コストは上下する可能性があります。代表的な音声で検証するまでは、修正時間の短縮はあくまで可能性であり、予算に織り込める削減額ではありません。

誰が使えるのか、利用者ごとに何が変わるのか

録音済み通話を扱うカスタマーサポート運用責任者

サポートチームは、録音済み通話を音声1時間あたり$0.10のバッチで処理し、話者ダイアライゼーションを有効にしたうえで、製品名を重要語句として渡せます。APIの直接費用は予測しやすいままです。移行判断の焦点は、名前、アカウント情報、話者の割り当てをレビュー担当者が修正する時間が、2.0で減るか増えるかにあります。

見るべき成果は、抽象的な精度スコアではありません。後工程のミスを増やさず、修正待ちのキューを短くできるかどうかです。本番のモデル固定先を変える前に、両方を測定してください。

リアルタイム音声エージェントを運用するプロダクトチーム

音声エージェントでは、通話終了まで待っていてはプロダクトとして機能しません。文字起こしがリアルタイムの制御ループを構成するため、音声1時間あたり$0.20のストリーミングには高い料金を払う価値があります。両モデルが間、数値、割り込み、重要語句をどう処理するか比較し、その文字起こしから実行されたアクションまで確認する必要があります。

人が読んで自然になった文字起こしでも、1つの数値表記が検索結果を変えたり、1か所の発話境界によってエージェントが早すぎる応答を返したりすれば、ワークフローは壊れます。受け入れテストではテキストだけでなく、後工程のアクションも対象にしてください。

字幕を納品するメディア運用責任者

インタビューや顧客向け動画を処理する制作会社は、バッチを使い、比較対象にタイムスタンプ出力も含め、両モデルを明示的に固定した状態で同じ難しい名前や発話の重なりを検証すべきです。成果はベンダーの総合ベンチマークではなく、修正時間と字幕納品物の品質で測ります。

APIは部品であり、編集ワークスペースではありません。ブラウザ上のエディター、会議ボット、字幕制作ワークフロー、人へのエスカレーション経路が必要なら、用途別の文字起こしツール比較を参照してください。

多言語対応のSaaSサポートチーム

xAIは、自社評価において2.0の精度が1.0の2倍になったと説明しています。また、独自の多言語短文データセットにおける単語誤り率が20.6%から6.8%へ低下したと報告しています。いずれもベンダー自身による比較であり、この記事のために実施したテストではありません。

多言語サポートチームは、自社で実際に扱う言語構成、アクセント、電話回線、名前、コードスイッチングをサンプルに含める必要があります。全体としての改善だけでは、問い合わせ件数の多い言語で精度が上がったか、あるいは人員配置を変えられるほど修正時間が短縮したかは分かりません。

モデルを固定してから出力を検証する

最小限のバッチリクエストは簡潔です。次のcURL例は、2.0モデルを明示したxAIのドキュメントどおりのリクエストです。

curl -X POST https://api.x.ai/v1/stt \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -F model=grok-voice-transcribe-2.0 \
  -F file=@audio.mp3

重要なのはモデルの行です。grok-voice-transcribe-2.0を明示的に固定すれば、選択権を自社側に置けます。一時的な比較基準としては、現在のドキュメントでもgrok-voice-transcribe-1.0を使用できます。xAIは後ろに置いたオプションフィールドが無視される場合があると警告しているため、マルチパートリクエストではファイルフィールドを最後にしてください。

移行検証では、両モデルで同じリクエスト設定を使います。モデル、話者ダイアライゼーション、書式設定、フィラーワード処理、重要語句を一度に変えると、どの変更が出力差を生んだのか説明できなくなります。

正直に言えば

料金は検証済みですが、人件費の削減はまだ確認できていません。

xAIの精度に関する主張は、テストを始める理由としては有用です。しかし、人員計画の根拠にはなりません。音声の構成が異なれば結果も変わり、単語誤り率が下がっても、レビュー時間の短縮や自動化の安全性向上に直結するとは限りません。

移行に関する表現も、発表より速く変化しています。9月18日のページではデフォルト変更を「近日中」としていますが、現在のドキュメントでは、モデルを省略した場合のデフォルトがすでに2.0になっています。この食い違いも、変化するエイリアスに依存せず、本番環境でモデルを明示すべき理由です。

最後に、$0.10と$0.20は音声処理だけの料金です。レビュー待ちのキュー、インテグレーション作業、ストレージ、再試行、後工程で誤ったアクションが起きた場合のコストは含まれません。安価なAPIの陰に高コストなワークフローが隠れないよう、これらは別々に管理してください。

いま取るべき対応

xAIの音声テキスト変換リクエストでモデルを省略している、または本番環境を1.0に固定しているなら、今週中に対応してください。呼び出しを棚卸しし、代表的な音声セットで検証したうえで、本番モデルを明示的に固定します。

ストリーミングを使うのは、発話中に文字起こしが届くことがプロダクトの結果を左右する場合に限ります。待機できる録音にはバッチを使ってください。話者ダイアライゼーション、タイムスタンプ、重要語句のオプションが含まれながら、音声処理の料金は半分で済みます。

xAIを含むプロバイダーを比較しているだけで、文字起こしが稼働中のワークフローへまだ接続されていないなら、いまは待って構いません。2.0を候補には残しつつ、移行前に自社の音声を使って修正コストと後工程のコストを比較してください。

xAIの音声テキスト変換を使っていない、または2.0をすでに固定して出力を検証済みなら、今回の変更による影響はありません。1.0を固定したインテグレーションも現時点では安定していますが、xAIはすでに非推奨化を予告しているため、移行テストを先延ばしにする理由にはなりません。

週明けにやることは簡単です。代表的な音声を用意し、同じ設定で1.0と2.0を実行し、修正時間と後工程の差分を測定してから、基準を満たしたモデルを固定します。料金表が変わらないため、API予算の計算は容易です。文字起こしの検証によって、その周囲のワークフローを守れます。

AIの料金やワークフローが実際に変わったときの実践的な解説を読みたい方は、ニュースレターにご登録ください。