xAI の音声認識モデル「Grok Voice Transcribe 2.0」は、公式 Speech-to-Text ドキュメントの Supported Languages 表に Japanese | ja として掲載されています（2026年10月5日時点）。Arabic から Vietnamese まで25言語が並ぶ表の中に、日本語も入っています。ただしこの表は「精度が保証された言語の一覧」ではありません。表の直前にある注記は、language パラメータは以下の言語の整形（formatting）を有効にするもので、モデルは language の指定にかかわらずこれらの言語を文字起こしする、設定すると数値・通貨・単位が書き言葉の形に整形される、という趣旨です。載っているのは「表記整形が効く言語」の一覧であって、日本語の WER（単語誤り率）は2026年10月5日時点でも公表されていません。
したがって「日本語に対応していますか」への正確な答えは、対応言語として公式に明記されているが、精度は自分で測るしかないです。料金はバッチで音声1時間あたり0.10ドル。1時間ぶんの会議音声を試しても十数円で、検証のコストは実質ゼロに近い水準です。この記事では、公式に何がどう書かれているのかを整理したうえで、日本語で使えるかを自分で確かめる手順をまとめます。
本記事は2026年9月18日の公開時点で「公式原文に日本語を名指しした記述は1つも無い」と書いていました。2026年10月5日に Speech-to-Text ドキュメント（https://docs.x.ai/developers/model-capabilities/audio/speech-to-text）を取り直したところ、Supported Languages の表に Japanese が掲載されていたため、該当箇所を訂正します。
公式原文に書いてあること・書かれていないこと
一次情報は xAI のニュースページ、デベロッパー向けリリースノート、Speech-to-Text ドキュメントの3つです。これを全文読んだうえで、日本語利用の判断に関わる部分だけを表にしました（2026年10月5日時点）。
項目 | 公式に書かれているか | 内容 |
|---|---|---|
対応言語 | ◯ 明記 | Speech-to-Text ドキュメントの Supported Languages に25言語の表。ニュースページ側は「dozens of languages（数十言語）」とのみ記載 |
日本語という言語名 | ◯ 明記 | 同表に |
その表が意味すること | △ 注意が必要 | 注記は「 |
日本語の WER | × 無い | 公開されているのは短文多言語コマンドの WER が20.6%から6.8%へ改善（1.0比）という多言語まとめの値のみ。言語別の内訳は出ていない |
日本語の整形の実例 | × 無い | 整形の例として載っているのは英語のみ（one hundred dollars → $100 など） |
料金 | ◯ 明記 | バッチ0.10ドル／音声1時間、ストリーミング0.20ドル／音声1時間（1.0と同額。リリースノートにも at the same price と記載） |
精度の全体評価 | ◯ 明記 | 社内評価で1.0の約2倍。Artificial Analysis の公開リーダーボードではストリーミング32モデル中1位 |
誤解のないよう念を押すと、「対応言語表に載っている」は「日本語の精度が保証されている」ではありません。表は整形機能の適用範囲を示すもので、日本語の会議音声でどれだけ正確に書き起こせるかは、公式情報からは分かりません。社内で導入を検討する場では、ここを曖昧にしたまま「公式に日本語対応と書いてある」と進めるのが一番危険です。
日本語かどうかに関わらず確定している仕様
言語の話とは別に、機能面と料金面は明記されています。バッチとストリーミングの両方に対応し、単語単位のタイムスタンプと信頼度スコア、話者分離、最大8チャンネルの独立文字起こしが使えます。1リクエストにつき最大100語のキーターム（固有名詞などの指定）を渡せるほか、数値・日付・通貨・電話番号・メールアドレスの整形出力、フィラー（えー、あのー等）の除去、ターン終了の検出も備えます。話者分離・単語タイムスタンプ・キーワードバイアスはいずれも追加費用なしです。
モデルIDは grok-voice-transcribe-2.0 で、2026年10月5日時点では model を省略したときの既定もこれです。旧モデルの grok-voice-transcribe-1.0 は2026年10月2日に end of life を迎え、1.0 宛のリクエストは同額で 2.0 へ自動ルーティングされます。切り替えの段取りと確認手順はgrok-voice-transcribe-1.0の廃止完了と2.0への自動切替で別途整理しています。採用事例としては、Atlassian の Loom が全動画の文字起こしをこのモデルへ切り替えたことが公表されています。
対応言語表に載っているのは「整形が効く言語」
ここが今回いちばん読み違えやすいところなので、分けて説明します。Supported Languages の表は、language パラメータの説明のためにある表です。
- 文字起こし自体は
languageを指定しなくても行われる。注記に「モデルはlanguageパラメータにかかわらずこれらの言語を文字起こしする」と書かれています。レスポンスのlanguageフィールドは検出された言語を BCP-47 で返す仕様です。 languageを指定すると、数値・通貨・単位が書き言葉の形に整形される。これが Inverse Text Normalization で、format=trueと組み合わせて使います。format=trueをlanguageなしで送ると 400 になります。- だから表に載っている＝整形の対象、であって精度の保証ではない。日本語の金額・単位がどう整形されるかの実例は公式には載っていません（例示は英語のみ）。
実務の読み方としては、日本語の音声を投げれば書き起こされる（表の有無にかかわらず）、そのうえで language=ja と format=true を付けると数値や通貨の表記が整う可能性がある、という二段構えで考えるのが正確です。後者が自社の議事録の体裁に合うかは、実際に付けた場合と付けない場合の両方で出力を比べるしかありません。
日本語で使えるか、自分で確かめる手順
公式に精度の数値が無い以上、自社の音源で測るのが唯一の確実な方法です。3つの手順に分けます。難しい話ではなく、要は「本番に近い音を、短く、1回投げてみる」だけです。
1. 試す音源は「きれいな朗読」を選ばない
検証でよくある失敗が、はっきり読み上げた音声で試して「問題なし」と判断してしまうことです。実際の業務で文字起こしにかけるのは、複数人が被って話し、社名や製品名や業界用語が飛び交う会議の録音です。本番でいちばん困っている音源を、3分から5分だけ切り出して投げるのが最短です。長い音源を丸ごと流すと、どこがどう間違ったのかを追えなくなります。
2. キーターム指定に自社の固有名詞を入れる
日本語の文字起こしで実際に困るのは、文章の意味が崩れることより、社名・人名・製品名が別の漢字に化けることです。ここに効くのが最大100語のキーターム指定です。自社名、主要な取引先名、頻出する製品名、社内の略語を並べて渡したうえで、指定あり・指定なしの両方を同じ音源で試すと、改善幅がそのまま自社での実用度になります。追加費用がかからないので、試さない理由がありません。
3. language=ja と format=true の有無で2回投げる
対応言語表の意味を踏まえると、日本語の検証は2回に分けるのが合理的です。1回目は language を付けずに素の文字起こし、2回目は language=ja と format=true を付けて整形あり。差が出るのは主に金額・日付・数量の表記なので、議事録や通話ログで数字を拾っている業務なら、この差がそのまま手戻りの量に直結します。整形が自社の体裁と合わない場合は、付けないほうが後処理が楽になることもあります。
4. 単語タイムスタンプと信頼度で「どこを間違えたか」を見る
出力を全文読んで良し悪しを感じ取るのは、時間がかかるわりに再現性がありません。単語単位の情報が返るので、怪しい単語だけを抜き出して、その時刻の音声を聞き直すという見方ができます。間違いが固有名詞に集中しているならキータームで対処できますし、会話が重なる区間に集中しているなら録音側（マイクの分離、チャンネル分け）の改善が先だと分かります。最大8チャンネルの独立文字起こしは、後者の対策として使えます。
Mihata では、こうした「どのモデルが自社の音源に合うか」の検証と、その後の業務への組み込みまでを支援しています。どこから測ればよいか分からない段階でのご相談も承っています。
日本語の文字起こしで選択肢を比べるときの軸
日本語の明記という条件では、ほかの選択肢と並んだことになります。たとえば Google の Gemini 3.5 Transcribe は、日本語（ja-JP）を含む85言語以上に対応することが公式ドキュメントに明記されています。詳細はGemini 3.5 Transcribe の日本語文字起こしと料金にまとめています。言語名の掲載で差がつかないなら、見るべきは次の軸です。
判断軸 | 見るところ |
|---|---|
日本語の明記の中身 | 言語名が「精度の保証」として載っているのか、整形や機能の適用範囲として載っているのか |
固有名詞への対処 | カスタム語彙・キーターム指定があるか、何語まで渡せるか、追加費用がかかるか |
1時間あたりの実費 | 分課金か時間課金か。ストリーミングは割高になることが多い |
後工程との接続 | 話者分離やタイムスタンプが要約・議事録の自動生成にそのまま渡せる形か |
モデルの寿命 | 旧版の廃止予告が出ていないか、予告から実行までが何週間だったか。切り替え作業の頻度は運用コストそのもの |
料金の横比較は文字起こしAPIの1時間あたり料金比較で数字を並べています。また、文字起こしはたいてい単体では終わらず、要約や議事録の形に整えるところまでが実務です。そこまでの流れは生成AIで議事録の文字起こしから要約までを自動化する手順で解説しています。
まとめ
Grok Voice Transcribe 2.0 の日本語について、公式情報から言えることは3つです。第一に、Speech-to-Text ドキュメントの対応言語表に Japanese | ja が掲載されていること。第二に、その表は language パラメータで数値・通貨・単位の表記整形が効く言語の一覧であり、精度の保証ではないこと。第三に、日本語の WER は2026年10月5日時点でも公表されていないことです。
そのうえで実務の結論はシンプルで、短い実音源を1本、キーターム指定あり・なし／language=ja あり・なしで投げて、怪しい箇所を聞き直す。これだけで自社にとっての答えが出ます。費用は十数円、作業は1時間かかりません。公表値を待つより早いはずです。
検証の設計や、文字起こしを日々の業務に組み込むところでお困りでしたら、現状をお聞かせいただければ一緒に考えます。
よくある質問
Grok Voice Transcribe 2.0 は日本語に対応していますか?
公式 Speech-to-Text ドキュメントの Supported Languages 表に Japanese（ja）として掲載されています（2026年10月5日時点）。ただしこの表は language パラメータで表記整形が効く言語の一覧であり、精度の保証ではありません。日本語の音声は language を指定しなくても文字起こしされると注記に明記されています。
日本語の精度（WER）は公表されていますか?
2026年10月5日時点でも公表されていません。公開されているのは短文の多言語コマンドで WER が20.6%から6.8%へ改善したという多言語まとめの数値のみで、言語別の内訳は出ていません。日本語の会議音声で同じ結果が出るかは自分の音源で確かめる必要があります。
language=ja を指定すると何が変わりますか?
数値・通貨・単位が書き言葉の形に整形されます（Inverse Text Normalization）。format=true と組み合わせて使い、format=true を language なしで送ると 400 エラーになります。文字起こし自体は language を指定しなくても行われるため、整形が自社の体裁に合うかどうかで付け外しを判断します。
社名や製品名の誤変換を減らす方法はありますか?
1リクエストにつき最大100語のキーターム指定が使えます。自社名・取引先名・製品名・社内略語を渡しておくと、固有名詞の取りこぼしを抑えられます。1語は50文字までで、追加費用はかかりません。
既存の grok-voice-transcribe-1.0 はまだ使えますか?
2026年10月2日に end of life を迎えました。リクエストがエラーになるわけではなく、1.0 宛のリクエストは同額で grok-voice-transcribe-2.0 へ自動ルーティングされます。model を省略したときの既定も 2.0 です。