25分の音声が106秒で返ってきて「成功」でした──gemini-3.5-transcribe を自分の素材で測る
公称値と実運用の差は、自分の音声で測らないと出てきません
25分の音声が、106秒で返ってきました
2026年8月31日、Google の新しい音声認識モデル gemini-3.5-transcribe を、自分の手元にある音声で回しました。
25分ぶんの音声を投げて、返ってきたのは最初の106秒ぶんだけでした。所要11.2秒。
エラーではありません。HTTP は 200。レスポンスの status は completed。「成功」です。
一度削除して投げ直しました。9.7秒で、同じ結果が返ってきました。再現します。
私はここで手が止まりました。このまま議事録の生成に流していたら、23分ぶんが消えたことに誰も気づかないからです。
公称の単語誤り率（WER）は、非ストリーミングで 2.6%、ストリーミングで 4.0%。Google が 公式ブログ（2026年8月26日公開）で出している数字です。精度の話だけを見れば、乗り換えない理由がないように見えます。
でも、実務で効いてきたのは精度ではありませんでした。エラーにならずに黙って落ちることのほうでした。
YouTube は入口として本当に有用です。ただ、落ち方までは出てきません
新しいモデルが出ると、YouTube に解説動画がすぐ上がります。何ができるようになったのかを短時間で掴めるので、私も見ます。
ただ、機能一覧にも WER 2.6% にも、書かれていないことがあります。
- 25分が106秒しか返ってこないのに、エラーにならない
- カスタム語彙が、話者分離ともタイムスタンプとも併用できない。これは機能一覧を眺めていても分かりません。エラーメッセージを踏んで初めて出てきます
どちらも、触ったところにしか出てきません。そして触らずに導入すると、気づかないまま記録が欠けます。
公称値と実運用は別物で、その差は自分で測らないと出てきません。 そして測り方には型があります。この記事で書きたいのはその型のほうです。
AIを入れること自体が目的になってしまう話は、「AIを使える社員」と「AIを使う会社」は別であるにも書きました。
日本語の会議 約2時間×2本で、2つのモデルを並べた
比較したのは次の2つです。
gemini-3.5-transcribe（2026年8月に出た音声認識の専用モデル）gemini-2.5-pro（それまで私が議事録の文字起こしに使っていたモデル）
素材は、日本語のビジネス会議の録音、約2時間 × 2本です。同じ会議を2台のICレコーダーで別々に録ったものを使いました。
目的は「発言者と時刻つきの逐語起こしを作る実務用途で、乗り換えるべきかを判断する」ことでした。
モデルの基本情報（2026年8月31日時点）
| 項目 | 値 |
|---|---|
| モデルID | gemini-3.5-transcribe（ファイル・同期）／ gemini-3.5-transcribe-live（ストリーミング） |
| バージョン | 3.5-transcribe-08-2026 |
| 入力トークン上限 | 98,304（live は 131,072） |
| 公称の精度 | WER 非ストリーミング 2.6%／ストリーミング 4.0% |
| 公称の売り | 85以上の言語の自動判定／話者分離／単語レベルのタイムスタンプ／カスタム語彙（最大1,000語）／smart 整形 |
| 音声の長さ制限 | 1リクエストあたり1時間。話者分離か単語タイムスタンプを有効にすると30分 |
| 価格 | 音声入力 $2.00 / 100万トークン、テキスト出力 $12.00 / 100万トークン（合わせて 1分あたり約 $0.005） |
WER は Google 公式ブログ、長さ制限と機能は モデルのドキュメント、価格は 料金ページ（ページ更新日 2026年8月28日）から取りました。いずれも2026年8月31日に確認しています。
WER 2.6% は Artificial Analysis の測定値として示された数字です。同じブログには FLEURS ベンチマークでの値も併記されていて、非ストリーミング 5.04%、ストリーミング 5.50%。
同じモデルでも、測る対象を変えれば数字は倍近く動きます。 ここが今回の話の出発点です。
「成功」を疑うための10工程
手順そのものより、なぜその検査が要るのかを書きます。
| # | やったこと | なぜ |
|---|---|---|
| 1 | モデルが実在するか、正確なIDを API のモデル一覧で確認した | 自分の記憶で答えない。学習データは過去のスナップショットで、新しいモデルの情報は入っていない |
| 2 | 音声の実長を ffprobe で実測した | API やアプリが返す長さを信用しない。ここがずれると以降の検査が全部ずれる |
| 3 | silencedetect で無音区間を調べた | 長い無音は、AIが「それらしい会話」を作り出す温床になる。先に無音の分布を知っておく |
| 4 | 音声を一定の長さに分割して処理した | 長い音声を一括で投げると、後半で品質が落ちる。長さの制限にも引っかかる |
| 5 | 区間の終端まで、タイムスタンプがどこまで到達したかを検査した | 今回の肝。「成功」で返ってきても中身が途中で終わっていることがある。到達率を見ないと気づけない |
| 6 | 同じ会議を2台で録っていたので、2本を別々に文字起こしして突き合わせた | 1本だけだと「間違っているかどうか」を判定する基準が存在しない。独立した2つ目があって、初めて答え合わせができる |
| 7 | 区間ごとに「相手側の録音に対応する発言が何%見つかるか」を計算した | 同じ会議なら対応が見つかるはず。見つからない区間は、AIが作り出した内容。実際にこれで架空の会話を生成していた区間を1つ検出して破棄した |
| 8 | 判断が割れた箇所は、その部分だけ音声を切り出して、先入観を与えずに独立判定させた | 通しの処理の結果を根拠に判断すると、最初の間違いを引きずる。争点は音声に戻って確かめる |
| 9 | 固有名詞と数値を機械的に突き合わせた（出現回数まで） | 目で読んで「合っていそう」では検証にならない。数えると、片方にしか無い語がはっきり出る |
| 10 | 結果を数字で残した（到達率、文字数比、一致率、費用） | 「なんとなく良かった／悪かった」では、次にモデルが出たときの判断に使えない |
この10工程のうち、5・6・7 の3つだけは飛ばせません。
5. 到達率の検査 ──「成功」は「全部返ってきた」の意味ではない
文字起こしの API は、どこまで処理したかを教えてくれるとは限りません。
generateContent を使っていたときは、finishReason と出力の長さを見れば打ち切りを検出できました。ところが今回のエンドポイントのレスポンスには、finishReason に相当するフィールドがありません。
だから、こちらで測るしかありません。
「音声の実長に対して、最後のタイムスタンプが何%の位置まで来ているか」
25分の音声に対して最後のタイムスタンプが106秒なら、到達率は7%です。これが今回、HTTP 200 で「成功」として返ってきました。
私が使っている基準はこうです。
- 到達率が85%未満なら採り直す
- 2回失敗したら、そのチャンクは別のモデルに回す
この1行の検査を入れるかどうかで、23分ぶんの会話が記録に残るか消えるかが決まります。
6. 独立した2つ目の音源 ── 基準が無いと「間違い」は判定できない
今回いちばん効いたのは、同じ会議が2台のレコーダーで録れていたことでした。
文字起こしを1本しか持っていないと、そこに何が書かれていても、それが正しいかどうかを判定する基準が存在しません。読んで違和感があっても、「そう言っていたのかもしれない」で終わってしまいます。
2本あると変わります。同じ時刻の発言が、片方にあって片方に無いなら、どちらかが間違っています。
重要な会議なら、録音機を2台置く。それだけで、後から答え合わせができます。機材代より、こちらのほうがずっと効きます。
7. 対応率の計算 ── AIが作り出した区間を機械で見つける
6を一歩進めると、機械で検出できるようになります。
区間ごとに、**「相手側の録音に対応する発言が何%見つかるか」**を計算します。同じ会議を録っているのですから、対応が見つかるのが当たり前です。
対応が見つからない区間は、AIが作り出した内容です。
今回、実際にこれで架空の会話を生成していた区間を1つ検出して破棄しました。目で読んでいるだけでは、そこはむしろ自然な会話に見えます。数字にして初めて浮かび上がりました。
AIが「それらしいもの」を作ってしまう挙動については、経費整理をAIに任せたら、購入履歴と証憑を作り始めたにも書きました。作り出しは、もっともらしいほど見つけにくいという性質があります。だから目視ではなく、数字で殴るしかありません。
呼び出し方が変わっています（APIを叩く方向け）
エンドポイントが generateContent ではありません
gemini-3.5-transcribe の呼び出し先は v1beta/interactions です。既存の Gemini 用スクリプトは、そのままでは動きません。
レスポンスの構造
steps[0].content[0].{ text, annotations[] }
annotations[i] = {
start_index, end_index, // 本文テキスト内の位置
text, // その単語
start_offset, end_offset, // 音声内の時刻
speaker, // "spk_0" などの記号
type: "word_info"
}
start_index はバイトオフセットです
start_index / end_index は UTF-8 のバイトオフセットであって、文字数ではありません。日本語は1文字が3バイトになることが多いので、文字数だと思って切ると全部ずれます。
対処は簡単で、annotation.text をそのまま使うのが安全です。位置を計算し直す必要がありません。
日本語を通した瞬間に出力がぐしゃぐしゃになって、そこで初めて分かりました。
ドキュメントどおりに書くと、通りません
機能一覧には、話者分離も、単語レベルのタイムスタンプも、カスタム語彙（最大1,000語）も並んでいます。並んでいるので、全部使う前提で設計しました。
通りませんでした。実際に返ってきたエラーが次の4つです。
| 組み合わせ | 結果 |
|---|---|
mode.type を省略 | エラー（type は必須） |
| カスタム語彙 ＋ 単語タイムスタンプ | エラー（併用不可） |
| カスタム語彙 ＋ 話者分離 | エラー（併用不可） |
smart モード ＋ 話者分離／タイムスタンプ | エラー（ドキュメントに記載あり） |
| 話者分離 or 単語タイムスタンプ を有効化 | 音声が1時間 → 30分に制限される |
返ってきたメッセージです。
The 'type' parameter is required at
'generation_config.transcription_config.mode'.
custom_vocabulary is incompatible with timestamps.
custom_vocabulary is incompatible with diarization.
smart と話者分離・タイムスタンプが併用できないことは、音声文字起こしのドキュメントにはっきり書かれています。
問題は残りの2つです。同じドキュメントのサンプルコードには、custom_vocabulary と diarization_mode: "speaker" と timestamp_granularities: ["word"] が同時に載っています。載っているとおりに書くと、API に弾かれます。
私だけの環境の問題かとも思いましたが、Google の開発者フォーラムにも同じ内容の報告が上がっていました。
固有名詞を寄せるか、話者と時刻を取るか
「固有名詞をカスタム語彙で寄せること」と「話者と時刻を取ること」は、どちらか一方しか選べません。
議事録では、誰がいつ何を言ったかが要ります。
つまり、このモデルの最大の売りであるカスタム語彙が、議事録の用途では使えません。固有名詞に強くしたいときほど、話者と時刻を諦めることになります。
結局、動いた構成はこれでした。
{ language_codes: ["ja-JP"],
mode: { type: "verbatim",
diarization_mode: "speaker",
timestamp_granularities: ["word"] } }
カスタム語彙は入っていません。
実測の結果 ── 同じ会議なのに、一方は57%
分量とカバレッジ
同じ音声に対する本文の文字数です。単語ごとのタイムスタンプを使って、5分刻みで集計しました。
| gemini-2.5-pro | gemini-3.5-transcribe | 比 | 実質欠落した5分枠 | |
|---|---|---|---|---|
| 録音1 | 43,280字 | 38,531字 | 89% | 1個 |
| 録音2 | 43,787字 | 24,863字 | 57% | 6個 |
2.5-pro のほうは、2本ともほぼ同じ文字数になりました。同じ会議を2台で録っているのですから、これが期待される姿です。
3.5-transcribe は、**同じ会議なのに一方が57%**でした。
区間の到達率
25分ずつのチャンクに分けて投げたときの、区間終端までの到達率です。
| チャンク | 到達率 |
|---|---|
| 1本目 c1〜c5 | 100% / 86% / 83% / 60% / 73% |
| 2本目 c1〜c5 | 100% / 7% / 計測不能 / 64% / 67% |
冒頭に書いた106秒は、2本目の c2 です。
最初のチャンクはどちらも100%です。 ここが厄介なところで、試しに1回投げて確認するという進め方だと、この問題は出てきません。5回投げて、初めて出てきます。
固有名詞の再現（41語で比較）
固有名詞と専門用語41語について、それぞれのモデルが全編で何回書けたかを数えました。
| 件数 | |
|---|---|
| gemini-2.5-pro のほうが多く拾った | 25語 |
| gemini-3.5-transcribe のほうが多く拾った | 3語 |
| 同数 | 13語 |
3.5-transcribe が全編で0回だった語には、こういうものがありました。
- 製品名（アルファベット表記の固有名詞） … 2.5-pro は録音1で12回、録音2で11回書いています。3.5-transcribe は0回
- 上場企業の英字ブランド名 … カタカナに音写されて、ブランドの表記としては残りませんでした
- 専門用語・会計用語・法律用語 … 複数が0回
一方で、金額そのものは概ね拾えていました。億や万の単位の数値は、両方のモデルでほぼ一致しました。
つまり、落ちるのは数字ではなく、固有名詞と専門語です。
そして、製品名を全編で一度も書けないモデルで、社内の記録は作れません。この一点で、乗り換えの判断は決まりました。
話者分離 ── 4名の会議が、1名に見える
正解が4名と確定している3分間で試しました。
| 検出した話者数 | |
|---|---|
| 正解 | 4名 |
| 3.5-transcribe（録音1） | 1名 |
| 3.5-transcribe（録音2） | 3名 |
| 同じ音声の3分クリップを単独で処理 | 2名（しかも区切りが文の途中） |
区間によって1〜3名に割れ、4名には届きませんでした。ドキュメント上も「3名以上の話者への割り当ては実験的」とされているので、挙動としては説明のつく範囲です。
ただし、2名の対話が続く区間ではきれいに交互になります。「何人が話しているかの下限」を知る材料としては使えます。
そして、実務でいちばん効いた制約はこちらです。
話者分離は氏名を返しません。 返ってくるのは spk_0 spk_1 といった記号です。誰が誰かは結局こちらで当てる必要があります。
ということは、参加者の名簿を渡して LLM に推測させる方式に対して、優位がありません。話者分離を有効にすると音声の長さ制限が半分（30分）になることまで考えると、むしろ不利です。
逐語の精度 ──「後退」が「倒産」になる
正解が確定している3分間で12項目を照合したところ、一致したのは2〜3項目でした（構成による）。残りは、意味が変わる誤りです。
| 種類 | 起きたこと |
|---|---|
| 単語の置換で意味が反転 | 「後退してしまう」が「倒産してしまう」になった |
| 期限のコミットが変わる | 「9月いっぱい」が「9月末まで」「最大限」になった |
| 業務語が別語になる | 「人材が必要」が「賃金が必要」に／「カットした分」が「半端した分」に |
| 副詞が別語になる | 「もうバッサリいきます」が「もう朝行きません」に |
いちばん結果が悪かったのは smart モードです。フィラーを除いて読みやすく整えてくれるのですが、その整形の副作用で、原発言から離れます。読みやすい文章にはなるけれど、記録としては使えません。
「後退」が「倒産」になる誤りは、1文字の違いではなく結論の違いです。この文字起こしをそのまま要約に流したら、要約は正反対のことを言います。
費用と速度
ここは 3.5-transcribe が明確に良いところです。
| gemini-2.5-pro | gemini-3.5-transcribe | |
|---|---|---|
| 分割 | 5分30秒 × 22区間 × 2本 ＝ 44回 ＋ 採り直し | 25分 × 5チャンク × 2本 ＝ 10回 ＋ 再試行1回 |
| API 所要（2本合計） | 約914秒 | 613秒 |
| 実測費用 | 本検証では計測せず | 355,572 audio tokens ＝ 約 $0.71（約4時間ぶん） |
| 公称単価 | — | 約 $0.005/分（$2.00 / 100万 audio input tokens） |
約4時間の音声で $0.71。日本円で100円ちょっとです。速度も1.5倍ほど速い。
ただ、公称単価から見積もると4時間で $1.20 になるはずでした。実際に請求されたトークン数から出すと $0.71。およそ6割です。価格まで、公称と実測はずれます。
失敗の仕方が違うので、検査の仕方も変えます
10工程を通して分かったのは、精度の優劣より、落ち方の性質が違うということでした。
- 一方のモデルは、架空の会話を作り出すことがある（そのかわり固有名詞には強い）
- もう一方のモデルは、作り出しはしないが、黙って大量に取りこぼす
この2つは、同じ検査では見つかりません。
| 失敗の型 | 見つけ方 |
|---|---|
| 作り出す（無い会話が書かれる） | 独立した2つ目の音源との対応率を区間ごとに計算する。対応が見つからない区間を疑う |
| 黙って取りこぼす（あるはずの会話が消える） | 音声の実長に対する到達率を検査する。85%未満なら採り直す |
作り出しは「書かれているものが正しいか」の問題です。取りこぼしは「書かれていないものがあるか」の問題です。前者は読めば疑えますが、後者は読んでも絶対に気づけません。無いものは見えないからです。
だから到達率だけは、目視では代われません。機械で測るしかありません。
それでも、私はこのモデルを捨てません
先ほどの41語の比較で、3.5-transcribe のほうが多く拾った語が3つありました。そのうちのひとつは、2.5-pro が別の企業名に誤変換していた社名です。3.5-transcribe は全編で正しく聞き取っていました。
これは大きいことです。2.5-pro の出力だけを見ていたら、間違った社名がそのまま記録に残っていました。
今の私の結論はこうです。
主に使うモデルにはしない。突き合わせて誤りを洗う「第3の耳」として使う。
安くて速いことが、ここで効いてきます。約4時間で $0.71 なら、答え合わせのためだけに1回まるごと回しても、費用は無視できます。速度も1.5倍なので、待ち時間もそれほど増えません。
主モデルの出力と3.5-transcribe の出力を並べて、食い違った箇所だけを音声に戻して確かめる。これが今の運用です。
「どちらが優れているか」を決めて片方を捨てるのではなく、落ち方の違う道具を2本持って、互いの穴を埋める。今のところ、これがいちばん確実です。
新しいモデルが出たときに、私が確認する4項目
文字起こしのモデルを乗り換えるかどうか判断するとき、私はこの4つを自分の素材で測ります。
- 到達率 — 音声の実長に対して、最後のタイムスタンプが何%の位置まで来ているか。必ず複数回投げる。1回目だけ100%で返ってくることがある
- 固有名詞の再現 — 自社の製品名・取引先名・専門用語を20〜40語選んで、出現回数まで数える。「拾えているか」ではなく「何回拾えたか」
- 話者分離の実力 — 参加人数が確定している数分間で試す。氏名を返すかどうかも確認する。記号しか返さないなら、名簿を渡して推測させる方式と比べる意味がある
- 併用制約 — 使いたい機能を全部同時に有効にして、1回投げてみる。機能一覧に並んでいても、同時に使えるとは限らない
どれも、モデルの紹介記事には書かれていません。
そして、この4項目はモデルが変わっても使い回せます。1回作れば、次からは同じスクリプトを流すだけです。今回の検証も、前に作った検査を持ってきて回しただけでした。
システムの発注で私が経験した失敗も、構造は同じでした。外部の開発会社に約3,000万円を投じて、要件定義3ヶ月、開発6ヶ月。出来上がったものは現場で使えず、最終的にExcelに戻りました。あのときも、仕様書の上では全部そろっていたのです。動かして初めて、抜けているものが見えました。
仕様書と動くもの。公称スペックと自分の素材。この2つの距離は、測らないと縮みません。
この結論が当てはまらない場合
この結論は、私の素材での結論です。
- 素材は日本語のビジネス会議の録音2本です。英語や、単一話者の講演や、短い音声メモでは、結論が変わる可能性が十分にあります
- 用途は発言者と時刻つきの逐語起こしです。要約だけが欲しい、検索できればいい、といった用途なら評価は変わります
- 実測日は2026年8月31日です。モデルは更新されます。今日の挙動が来月も同じとは限りません
- 到達率の問題が、モデル側の仕様なのか、私の投げ方の問題なのかは切り分けきれていません。ただ、削除して投げ直しても同じ結果が返ってきたことは事実として書いておきます
だからこそ、この記事の数字をそのまま信じて乗り換えを決めないでください。
おわりに——「成功」と返ってきたものを、どこで疑うか
HTTP 200、status: completed。それが「全部処理できました」という意味だとは限らない、ということです。
もし今、AIで会議の記録を作る仕組みを動かしているなら、ひとつだけ確かめてください。
「音声の長さと、出てきた文字起こしの最後の時刻を、突き合わせている箇所はありますか」
無ければ、今日から入れてください。数行で書けます。
そして、もしその仕組みが半年前から動いているなら、過去の記録も一度まとめて測ってみてください。エラーが出ていないだけで、消えている会話があります。
無いものは、探さないと見つかりません。
この記事のポイント
- 公称 WER 2.6% の新しい音声認識モデルでも、自分の素材で測ると判断は変わります。 同じ会議の録音2本で、一方は元モデル比89%の文字数、もう一方は**57%**しか返りませんでした
- いちばんの落とし穴は精度ではなく「無言の取りこぼし」です。 25分の音声が106秒で返ってきて、HTTP 200・
status: completed。このエンドポイントにはfinishReasonに相当するフィールドが無いので、音声の実長に対する到達率を自分で検査するしかありません（85%未満なら採り直す、2回失敗したら別モデルへ） - 最大の売りであるカスタム語彙が、話者分離ともタイムスタンプとも併用できません。 公式ドキュメントのサンプルには3つが同時に載っていますが、API に弾かれます。議事録の用途では、固有名詞への強さを諦めることになります
- 失敗の仕方が違うモデルは、検査の仕方も変えます。 作り出しは「独立した2つ目の音源との対応率」、取りこぼしは「到達率」。前者は読めば疑えますが、後者は読んでも気づけません
- ただし捨てるモデルではありません。 約4時間で $0.71、速度も1.5倍。主に使うのではなく「第3の耳」として突き合わせに回すのが、今のところの正解です
伊藤翔太 株式会社IIWAYO.TECH 代表取締役 / 株式会社リサスティー 代表取締役