Grok Voice Think Fast 2.0レビュー:速くて鋭いが、上限付き

実際に検証したこと、できなかったこと

ここでの前提を正直に伝えておきたい。音声モデルについて「テストした」という言葉はかなり緩く使われがちだからだ。

実際に取り組んだのは、xAIの音声対音声ドキュメントを最初から最後まで読み込んだこと、公開された制限が書かれたモデルカード、そして料金ページのレートカードだ。

それに加えて、ローンチ記事と、27の他モデルと比較した独立系のArtificial Analysisのベンチマーク結果も読んだ。さらに、実際に構築している人たちが何を言っているかも確認した。

言えないこと:私はこのモデルで実際の電話回線上で1,000件の本番通話を回したわけではない。xAIの外でそれをやった者は、Starlinkを除いて誰もいない。だからこの記事で負荷時の挙動について何か述べる場合、それは実体験ではなく公開された制限からの推測であり、その都度どちらなのかを明記する。

私はeeselでAIエージェントを構築する仕事をしており、その多くはモデルと実際の顧客との会話の間に入る部分だ。それがここでの視点になる。問うべきは「デモで印象的か」ではない。「火曜の午後、40人が同時に電話をかけてきたときに何が壊れるか」だ。

スコアカード

詳細に入る前に、まず評価の全体像を一箇所にまとめておく。

結論: モデル自体は強く推薦できるが、プラットフォームについては「まず自分の通話量を確認せよ」となる。この2つは別物であり、レビューはしばしば前者しか評価しない。

優れている点

際立っていたのは4つ。そのうちxAIがローンチ時に前面に押し出した数字は1つだけだった。まとめて見ると、これは特定の性格を持つモデルだと分かる。最も賢いモデルではないが、電話回線で十分な速さで応答しながら鋭さを保つモデルだ。

割り込みがもはや弱点ではなくなった

1.0からの最大の変化はFull Duplex Benchだ。これは実際の会話の面倒な部分、つまり割り込み、発話の重なり、相槌、話している途中で考えを変えるといった要素にモデルがどう対応するかを測定する。1.0は77.8%だったが、2.0は**95.1%**を記録している。

これは、人が我慢して使う音声エージェントと、機械だと忘れてしまうほど自然な音声エージェントを分ける数値だ。通話録音を聞いたことがある人なら、この典型的な失敗パターンを知っているだろう。発信者が言い直そうとしているのに、ボットが話し続けてしまい、発信者は声を大きくして繰り返すか、人間につないでほしいと頼む羽目になる。これは顧客が諦めてしまうチャットボットの問題の一覧でも上位に位置しており、まともに設計された導入事例における引き継ぎのパターンの多くは、まさにその瞬間を捉えるために存在している。

公平を期して言えば、これはGrokがOpenAIに負けている唯一の項目だ。GPT-Realtime-2.1 Highは95.7%を記録している。0.6ポイントの差は発信者が知覚できるようなものではないが、ローンチ時の表がそれを自ら公表することはない。

エージェント型スコアこそが本当の目玉

τ-voiceは、モデルが単に良い音声を出すだけでなく、音声上で実際にタスクを完了できるかどうかを測る。注文を調べる、ポリシーを確認する、そのうえで関数を呼び出して正しい答えを返す、という流れだ。Grok Voice Think Fast 2.0はここで**56.5%**を記録しており、Artificial Analysisの表全体で最も高い数値になっている。

本物のエージェントを構築する人にとっては、これは総合インデックスよりも重要な意味を持つ。ツールを確実に使いこなせない音声エージェントは、非常に高価なFAQ読み上げ機に過ぎないからだ。これはテキストの世界でAIエージェントとAIチャットボットを分けるのと同じ違いであり、実用的なAIエージェントの事例が常に記事を読み上げるだけでなく実システムに触れているものである理由も同じだ。

正直に言うべき注意点として、同じベンチマークでQwen Audio 3.0 Realtime Plusは54.6%を記録している。つまりGrokのリードは1.9ポイントであり、その打ち出し方が示唆するほどの大差ではない。OpenAIの最高値である45.7%との差はより大きく、そこから「10ポイント差」という宣伝文句が生まれているが、Qwenはすぐそこにいる。

速さと賢さの組み合わせ

最初の音声が出るまでの時間は0.70秒で、1.0の1.25秒から短縮された。Deepslate Opalは0.44秒でより速く、あるGemini Flashのバリアントも0.63秒であるため、Grokは3番目に位置する。しかし総合インデックスでGrokを上回るQwenは、最初の音声まで4.02秒かかる。電話回線上では、発信者が「もしもし?」と言いたくなるほど長い沈黙だ。

そのトレードオフこそが実質的な製品価値だ。Hacker Newsのある投稿者が、ローンチ記事よりも的確にこう表現していた。

"Grok voice is the best voice AI voice assistant and it's not even close.

The speed + intelligence tradeoff is just right. While GPT voice is smug and unhumanlike despite trying hard to be human."

simianwords, Hacker News

xAIによれば、推論トークンは前モデルのP50の0.4倍の速さで動作しているという。つまり、考える量を減らすことで速くなったのではなく、賢くなりながら速くなったということだ。

文字起こしは過小評価されている部分

ローンチ記事の中に埋もれているのが、文字起こしの精度が1.0の1.4倍であり、Deepgram Nova 3やElevenLabs Scribe v2と比べても24言語で1.5倍から2.0倍優れているという数値だ。ノイズの多い音声や電話回線の音声では、その差はおよそ10倍にもなると主張されている。

電話回線の音声は文字起こしが最も破綻しやすい領域であり、まさにサポート回線が一日中扱っている種類の音声だ。これをElevenLabsや専業の音声認識ベンダーと比較して評価しているなら、その「ノイズの多い音声」の数値には会話ベンチマーク以上の重みを持たせるべきだ。この軸は、ほぼ惰性の理由でOpenAIの文字起こしエンドポイントがデフォルトの選択肢になり続けている領域でもある。

現在はボイスラインナップが26種類あり、2026年7月に21種類が追加された。そのどれもクローンした音声IDに置き換えることができる。自社ブランドらしい声をチャネル横断で保とうと苦労した経験があるなら、出力が音声になったからといってブランドボイスの問題が消えるわけではないと分かるはずだ。

ベンチマークの表が誇張している点

ローンチ時のフレーミングが教えてくれない3つのこと。

82.9%は2位である。Qwen Audio 3.0 Realtime Plusは84.1%だ。Grokはこれと十分競り合っており、速度では大きく上回っているが、「最先端」という言葉はマーケティングコピーの中でかなり働いている。最近のQwenのモデルファミリーやAlibabaの価格設定を見ていれば、彼らが猛烈な勢いで出荷し続けているのが分かるはずだ。

**xAIの2つのτ-voiceの数値を単純比較してはいけない。**7月1日のVoice Agent Builderの記事は、Think Fast 1.0が独自のτ-voice測定で67.3%だったと報告している。一方Artificial Analysisは同じモデルを52.1%と評価している。ハーネスもスケールも異なる。この2つの数値を積み重ねて「これだけ進化した」というグラフを作るのは、実質何も比較していないに等しい。同じ注意はVoice Agent Builderの料金にある数値にも当てはまり、そちらはまだ旧料金を引用したままだ。

**Starlinkの数値は1.0のものだ。**広く引用されている20%の販売転換率と70%の自律解決率は、+1 888 GO STARLINKの回線で28個のツールを組み込んだ状態でのThink Fast 1.0の実績だ。2.0については、xAIは同じ回線でのA/Bテストで転換率とコンテインメント率に「有意な増加」があったとしか述べておらず、具体的な数値は公表していない。しかもこれは同じ資本関係内でのファーストパーティ導入であり、代表例というよりベストケースと見るべきだ。

構築してみて:優れているのはAPIの部分

ドキュメントが弱点になると思っていたが、実際は逆だった。設計という観点で言えば、これは私が読んだ中で最も考え抜かれたリアルタイム音声APIだ。

wss://api.x.ai/v1/realtimeでOpenAI Realtimeとワイヤー互換になっているため、既存アプリがあるならベースURLとキーを差し替えるだけで移行できる。OpenAIのSDKをそのまま使い、https://api.x.ai/v1を指すように変更するだけでも構わない。4つの点は引き継がれない。conversation.item.done、rate_limits.updated、そしてほとんどのoutput_audio_buffer.*イベントは発行されず、...input_audio_transcription.deltaは.updatedという名前に変わり累積型になる。差分を追加していく実装のままだと、文字起こし表示が静かに壊れてしまう。

xAI独自の拡張機能こそが興味深い部分で、電話エージェントを出荷して痛い目に遭った人が書いたような設計になっている。

• force_message はモデルを一切介さずに、あらかじめ決められた文言をTTSで話す。interruptible: falseを設定すると、話し終わるまで発信者側の音声は無視される。これはシステムプロンプトがうまく機能することを祈るのではなく、コンプライアンス上の開示義務をきちんと解決する仕組みだ。
• replace はTTSに渡す前に適用される発音マップで、音声は「Acme Mobull」と読み上げつつ、トランスクリプトは「Acme Mobile」のままにできる。マッチングは大文字小文字を区別せず、単語境界を尊重し、最長一致が優先される。
• resumption はconversation_idごとにターンをキャッシュし、再接続時に再生する。デフォルトでは無効で、双方が opt-in する必要があり、履歴は30分間操作がないと失効する。
• keyterms は最大100個、各50文字までのドメイン固有語に文字起こしのバイアスをかけられ、セッション中でも更新できる。SKUやプラン名だらけのサポート回線にとって、これは使い物になる文字起こしと使い物にならない文字起こしの差になる。
• idle_timeout_ms は応答のたびに再セットされるため、エージェントは黙り込んだ発信者に対して座って待つのではなく、何度でも再度話しかけに行ける。

reasoning.effortパラメーターが取れる値は"high"(デフォルト)と"none"の2つだけだ。中間設定がないのは実際のギャップだ。以前のGrok音声リリースについて、Hacker Newsでまさにこの点を指摘していた人がいた。

"Grok voice model is also a thinking model. I agree that it's far better than the other voice models

Just give me a option to have a slower response but better model…"

artdigital, Hacker News

ドキュメントが正しく押さえていて、たいていのベンダーなら本番運用で初めて気づかせるような点がもう一つある。ツール呼び出しの後、response.createを送る前に音声再生が終わるのを待つようにと明示的に書かれている。サーバーは関数呼び出しのイベントより先に、すべての音声デルタを配信するからだ。これを怠ると音声が重なってしまう。ドキュメントはその間、考え中であることを示すインジケーターを表示することまで提案している。これは苦労して得た知見が、きちんと文書化されている例だ。

移行ガイド自体のアドバイスは、システムプロンプトを長くではなく短くするというものであり、これはモデルがどのようにチューニングされたかを物語っている。

実際に導入を止める3つの制限

もし私が評価する立場なら、まず読むのはこのセクションだ。

**チームあたり同時10セッション。**これはモデルカードに記載された公開デフォルトで、申請すれば引き上げ可能とされている。同時10通話というのは、小規模なサポートチームの月曜の朝に過ぎない。上記のベンチマークはすべて、11件目の通話がつながらなければ意味を持たない。そして「申請すれば引き上げ可能」というのは設定項目ではなく営業交渉だ。AIコールセンターエージェントのサイズを検討する人は、これを脚注ではなく最初の質問として扱うべきだ。

比較として、ヘルプデスクの上に構築されたパッケージ型の音声製品は、そもそもセッション上限を公開していないことが多い。同時接続数はベンダー側の問題であり、利用者側の問題ではないからだ。Zendeskの音声AIエージェント、Freshcallerのセットアップ、Salesforceの音声エージェントがいずれもそうだ。柔軟性と引き換えに、キャパシティ計画を他社に任せる形になる。

**us-east-1のみ。**リージョンは1つだけで、EUの選択肢はない。データ所在地に関する要件があるなら、他の評価をする前にこの点だけで結論が出てしまう。

優先枠もバッチ割引もない。2倍速の優先枠はChat CompletionsとResponsesのみが対象で、20%のバッチ割引はテキストモデル限定だ。音声には高速レーンもボリューム割引も用意されておらず、見ている料金がどのスケールでもそのまま適用される料金になる。最大セッション時間も120分あり、サポート用途には十分だが、常時監視するような回線にはやや窮屈だ。

さらに小さな注意点が2つ。エージェントが検索を行う場合、ストレージ料金は別建てで、コレクションは1GiB/日あたり0.10ドル、ファイルは0.025ドル、ダウンロードは1GiBあたり0.20ドルかかる。また、Responsesリクエストが生成前にブロックされるたびに利用ガイドライン違反手数料0.05ドルが発生する。

2.0を採用すべきか、1.0に固定すべきか

8月5日のエイリアス切り替えにより、何もしないこと自体が一つの選択になる。自分に当てはまる行を選んでほしい。

実際に構築している人たちの声

xAIへの反応が集まる自然な場所はXだが、現状では深く読み込むのが難しいため、有用なシグナルはHacker Newsにある。2つのスレッドが大半を占めている。

Think Fast 2.0のスレッドで最も支持を集めたコメントは、実質的にローンチがあまり注目されていないことへの不満だ。

"Don't know why this post isn't more popular, this is a SOTA voice model, beating dedicated labs like ElevenLabs"

haaz, Hacker News

これは性能についてはフェアな見方であり、価格についても今や収束したことに触れておく価値がある。有料のElevenLabsのAgentsプランはどれも、含まれる1分あたりの単価がほぼ正確に0.08ドルになり、これはGrokの新料金と1セント単位で一致する。8月5日までは、Grokはこれを37.5%下回っていた。

数か月前の、より慎重な見方も今なお通用する。

"Grok voice is surprisingly good, actually. It's still a dumber model than the thinking modes of frontier models, but it's less dumb than the voice modes of other providers."

modeless, Hacker News

私の見立てもだいたいそこに落ち着く。音声モデルは常に、10秒間考える余裕を持つテキストモデルとの妥協の産物であり、Grokは他社より上手にその妥協点を見つけている。消費者向けのレビューを読んでも、慎重さこそ足りないが同じ結論に行き着くのが分かるはずだ。

これらのスレッドで繰り返し出てくる不満は音声モードでのツール利用についてであり、これは両方向に効いてくる話なので整理しておく価値がある。

"What I'm missing from this announcement is the capability to use connectors and tools. I don't really get it - NONE of the frontier assistants can use tools / connectors while in voice mode"

artdigital, Hacker News

これは消費者向けの音声アシスタントについての話であり、API側ではGrokに当てはまらない。セッションはfunction、file_search、web_search、x_search、そしてリモートのmcpツールに対応しており、サーバー側で実行されるツールは代わりに処理してくれる。サーバーツールは呼び出しごとに課金され、webおよびX検索は1,000回あたり5ドル、コレクションは1,000回あたり2.50ドル、添付ファイル検索は1,000回あたり10ドルだ。このコメントが指摘しているギャップは消費者向けGrokアプリでは現実だが、実際に構築対象となるものには当てはまらない。これはChatGPTの音声機能の展開全体を貫く同じ構図であり、APIはしばらく前からアプリの一歩先を行っている。

誰が導入すべきで、誰が待つべきか

導入すべき人: 話すだけでなく実際に「行動する」電話や音声エージェントを構築している場合。τ-voiceのスコア、ツール対応、force_messageやkeytermsといった拡張機能、そしてフラットな分単位課金を足し合わせると、現時点で出荷されている中で最も開発者フレンドリーな音声スタックになる。OpenAIのリアルタイム音声からの移行はほぼ無料に近い。

導入すべき人: 財務部門にとってコストの予測可能性が重要な場合。Artificial Analysisの計測では、Grokの実際のコストは入力音声1時間あたり4.80ドルで、これは定価と完全に一致する。メーターが分単位でフラットだからだ。GPT-Realtime-2は入力の定価が1時間あたり1.15ドルだが、実測では全体で4.14ドルになる。表示価格どおりに請求される音声サービスは珍しく、それがエージェントと人間のコストという問いに正直に答えるのが難しい理由の半分でもある。

導入すべき人: オーケストレーションを自分で構築したい場合。むしろボックスをドラッグして組み立てたいなら、Voiceflowの料金やVoice Agent Builderの代替製品が同じ市場のノーコード側にあたる。

待つべき場合: 同時通話数が10を超え、まだ上限引き上げを書面で確保していないとき。待つべき場合: EUリージョンが必要なとき。待つべき場合: 0.05ドルの料金をあてにしていて、エイリアスが切り替わることに気づいていなかったとき。その場合は今日のうちにgrok-voice-think-fast-1.0に固定し、自分のスケジュールで判断すればよい。

**サポートのソリューションとして買ってはいけない。**これはモデルとAPIであり、ヘルプデスクエージェントではない。チケット履歴もマクロも、エスカレーションのルールも、チームがすでに「AIに触らせない」と決めた質問の存在も知らない。ここまで書いてきたことはすべて音声レイヤーについてであり、その音声レイヤーはサポート自動化を実際に機能させる要素のうちせいぜい20%に過ぎない。残りは地味な部分だ。自社の製品を理解していること、いつ止まるべきかを知っていること、そしてきれいに引き継ぐことだ。

あるDTCサプリメントブランドのCXリーダーは、どんな仕様書よりも的確にこの制約を言い表していた。

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

どんな音声ベンチマークもそれを測ってはくれない。これは方針の問題であり、導入が最初の1か月を生き延びられるかどうかを決めるのはまさにその問いだ。

音声はサポートキューの中で一番うるさい半分だ

電話に発展してしまうチケットの大半は、その1時間前にはテキストで答えられたはずのものだ。初回応答の自動化や、AIが実際に読み込めるナレッジベースチャットボットは、どんな音声モデルよりも多くの通話の芽を摘む。それこそが、音声モデルを探す前に直すべきことだ。

eeselは、すでに運用しているヘルプデスクにそのまま組み込めるAIエージェントで、手書きのシステムプロンプトではなく過去のチケットとヘルプセンターをもとに学習し、実際の顧客が触れる前に、実際のチケット履歴に対して丸ごとシミュレーションできる。この最後の部分は意図的な設計だ。私は自信たっぷりに間違った答えを返すボットを何年も見てきており、すでに解決済みのチケットに対する事前検証こそが、自分のボットが実際に何をするのかを知る唯一の誠実な方法だ。これはまた、あらかじめ決められた分岐が尽きたときに、本物のAIエージェントをルールベースのボットから分ける段階でもある。

これは、xAIのようなドキュメントページを読んで、自分たちがどれだけの部分を保守することになるか理解した多くのチームが最終的にたどり着く、同じビルドか購入かという判断でもある。

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

音声レイヤーにも興味があるなら、Grok Voice Agent Builderや、より広いAI音声企業の分野について読み進めてほしい。その裏側にあるキューをまず片付けたいなら、eeselは無料で試すことができ、ヘルプデスクに接続するのに数分もかからない。GorgiasやZendeskを使っているチームは、たいてい同じ日の午後には実際のチケットに回答させている。

ここから先、行き詰まっている部分に応じて読んでおくとよい3つの記事を挙げておく。

• モデルについてまだ検討中なら:Think Fast 2.0の概要記事がより詳しく仕組みを解説している。
• 料金を計算しているなら:料金の全体解説が4つの利用量で計算をしている。
• 他社と比較しているなら:ElevenLabsの代替製品が同じ料金帯で最も近い比較対象になる。