Gemini 3.5 Transcribe実測|Antigravityで社名を間違えられた話【2026年8月】
取締役 大竹 享

結論: 2026年8月26日、GoogleがGemini 3.5 Transcribeを公開しました。発表には「Google Antigravityで使える」と書かれています。私は普段そのAntigravityを使っているので、自分の経路で試しました。結果、手元からモデルを名指しで呼ぶことはできず、音声ファイルを投げる経路では別のモデルが、しかも回ごとに違うやり方で処理していました。
この記事の要点:
- 「◯◯で使える」という発表は、「自分の手元からそのモデルを名指しで呼べる」を意味しない。経路によって動くものが違った
- 同じ音源・同じモデル・同じ指示で3回投げたら、3回中2回、自社の社名を間違えられた(2回とも「ドゥスク」)。経路を変えると、化け方まで変わった
- 固有名詞を先に渡した2回は、どちらも正しく出た。ただしそのうち1回は、モデルが勝手にSwiftを書いてAppleの音声認識を呼び、その結果と突き合わせていた
/voiceの音声入力でも3回中1回、社名が「ディスク」になった。しかも私はそれに気づいていなかった- 「使える」と発表されていても、自分の経路で何がどう動くかは別問題。実行のされ方まで回ごとに変わる
- 価格はファイル処理ならOpenAIとほぼ互角。差が出るのはリアルタイム。ただし課金方式の性質が違う
対象読者: AIコーディングCLIを日常的に使っているエンジニア、1on1や週次MTGの議事録をAIで回したい方。
読了後にできること: 新しいモデルのニュースを見たとき、自分の利用経路で本当に動くのかを確かめる手順が持てます。

「Antigravityで使える」と書いてあったので、試した
株式会社デュスク取締役の大竹です。
普段はSES事業の会社で取締役をやりつつ、自分でも手を動かしてAIツールを業務に組み込んでいます。
この公開ブログに私が書いたのは、Gemini 3.7 Flashを自分の実務タスクで測った記事が最初でした。
ベンダーが出したベンチマークの数字ではなく、自分が普段回している作業で測る。今回もやり方は同じです。
文字起こしについては、当ブログにOpenAIの文字起こしAPIを取り上げた記事があります。
そこでは、Whisperの弱点として「固有名詞」が挙げられていました。社名や人名、技術用語が崩れて、それが修正コストになる、と。
その1か月足らずあとに、Googleが話者分離つきで参入してきたわけです。
そして今回、私はAPIキーを取って生で叩くより先に、確かめたいことがありました。
いま自分が使っている経路で、本当に動くのかです。
このブログの制作フローでは、Antigravityを日常的に使っています。だから「Antigravityで使える」と書かれているなら、そこで試すのが自然でした。
何が出たのか — 発表内容の整理
この節に出てくる数値は、すべてGoogleが公表しているものです。
公開日は2026年8月26日、public previewです。
Googleはこのモデルを「これまでで最も精度の高い音声テキスト変換モデル」と説明しています。
モデルは2本立てです。
gemini-3.5-transcribe— 録音済みファイル向け。Interactions API経由gemini-3.5-transcribe-live— ライブ音声向け。Live API経由
提供チャネルはGemini API、Google AI Studio、Gemini Enterprise Agent Platformです。
すでに製品にも入っています。
GboardのRambler(Android)、macOS版Geminiアプリ、Google Antigravityのプロンプト入力のマイク。Chromeへの搭載は近日、とGoogleは説明しています。
機能面では、85以上の言語の自動検出(日本語も対応言語に含まれます)、話者分離、単語単位のタイムスタンプ、カスタム語彙、フィラー除去と自動フォーマット。
ここでAntigravityについての説明が伏線になります。Googleは、プロンプトボックスのマイクについて「画面のコンテキストとチャット履歴を、ユーザーの許可のうえで組み合わせ、ファイル名やエージェントの思考、開いているドキュメントにわたって正確な文字起こしを実現する」という趣旨の説明をしています。
つまり、固有名詞を自動で拾う仕組みがある、と読めます。
【実測】Antigravity経由の経路を、3つに分けて調べた
測った環境
Antigravity CLI(agy)のv1.1.22、macOS。モデルにはGemini 3.7 Flash (High)を指定しました。
検証日は2026年8月30日です。
音源はmacOSのsayコマンドで合成した約12秒の日本語音声です。実際の会議録音ではありません。
読ませた原稿はこれです。
こんにちは。株式会社デュスク取締役の大竹です。今日は音声認識モデルのテストをしています。会議は三十分で、参加者は二名です。
固有名詞のトラップとして自社名「デュスク」と人名「大竹」を仕込みました。数字の扱いを見るために「三十分」「二名」は漢数字にしています。
測り方で一点だけ気をつけました。各回とも、agyの新しいセッションで実行しています。
同じセッションで繰り返すと、前のやりとりから答えを拾えてしまうからです。

経路① モデルとして名指しで呼ぶ — できませんでした
agy modelsが返すモデル一覧に、transcribe系のモデルは1つもありませんでした。
返ってきたのは、Gemini 3.7 / 3.6 / 3.5 Flash(各High・Medium・Low)、Gemini 3.1 Pro、Claude Sonnet 4.6、Claude Opus 4.6、GPT-OSS 120Bです。
つまりgemini-3.5-transcribeを指定して呼ぶことは、このCLIからはできません。
経路② 音声ファイルを添付して投げる — 動きました
agyは音声ファイルの添付に対応しています。変更履歴のv1.1.18に、wav・mp3・m4a・aac・flac・opusを受け付けるようにした旨の記載があります。
実際に.m4aを添付して、文字起こしを頼みました。
ただしここが肝です。これはGemini 3.5 Transcribeではありません。
通常のチャットモデルが音声を受け取って書き起こしています。
試行1 — 語彙ヒントなしで3回投げたら、結果が揺れた
まず「この音声を一字一句そのまま文字起こししてください」とだけ頼みました。同じ音源、同じモデル、同じ指示で3回です。
回 | 社名(正解は「デュスク」) | 「二名」の出方 |
|---|---|---|
1回目 | デュスク(正解) | 2名 |
2回目 | ドゥスク | 2名(ふた名) |
3回目 | ドゥスク | 2名(ふたな) |
3回中2回、自分の会社の名前を間違えられました。
正解した1回目と、間違えた2回目・3回目。入力は完全に同じです。
漢数字の「三十分」は、3回とも「30分」に自動整形されました。原文どおりではありませんが、議事録としてはこちらの方が読みやすいですね。
一方で「二名」の読みが3回とも違うのが、地味に厄介です。
試行2 — 固有名詞を先に渡したら、2回とも正しく出た
次に、頼み方を変えました。
この音声にはデュスク(株式会社デュスク)と大竹(おおたけ)が含まれます。一字一句そのまま文字起こししてください
これを2回。2回とも社名は「デュスク」で正しく出ました。
試行1では3回中2回外していたので、渡す効果はありそうに見えます。
ただし、これで話を終えると事実を取り違えます。

正解にたどり着いた道のりが、回ごとに違った
ここが今回いちばん驚いたところです。
あとからagyの会話ログを掘り返したら、同じ指示なのにモデルのやり方が毎回違っていました。
回 | モデルがやったこと | 社名 |
|---|---|---|
試行1・1回目 | 音声を直接聴いただけ | デュスク |
試行1・2回目 | 音声を直接聴いただけ | ドゥスク |
試行1・3回目 | 音声を聴いたあと、ffmpegとWhisperを探しに行った(見つからず) | ドゥスク |
試行2・1回目 | Swiftのコードを自分で書いて、Appleの音声認識を実行した | デュスク |
試行2・2回目 | 音声を直接聴いただけ | デュスク |
試行2の1回目が、とんでもないことをしていました。
ログを追うと、こういう順番です。
- まず音声を聴く
ffprobeでファイルの情報を確認する- Whisperが入っていないか探す(
whisper、mlx_whisper、Pythonのモジュール) → いずれも無し /tmp/recognize.swiftを書いて、AppleのSpeechフレームワーク(SFSpeechRecognizer)を日本語で呼ぶ → 1本目は応答が返らず、自分で強制終了- pipのパッケージ一覧、
whisper-cli、whisper-cppなども探す → 無し - ffmpegで16kHzのwavに変換。さらに8秒目以降を切り出して、そこだけもう一度聴き直す
- Swiftを書き直して再実行 → 今度は動いた
- もう1本書いて、単語ごとのタイムスタンプまで取る
- 作った一時ファイルを自分で消して片付ける
頼んだのは「音声を文字起こしして」の一言です。
そして、そのAppleの音声認識が返した結果がこれでした。
こんにちは株式会社デスク取締役の大竹です今日は音声認識モデルのテストをしています会議は30分で参加者は2名で
「デスク」。3つ目の化け方です。
単語単位のタイムスタンプでも、2.07秒から2.46秒のところが、はっきり「デスク」と出ています。
それでも最終的な回答は「デュスク」でした。
つまりこの回の正解は、モデル自身が聴いた内容と、Appleの音声認識の結果と、私が渡した固有名詞のヒントを突き合わせて出したものです。
Geminiが単独で正しく書き起こした、という話ではありません。
しかも、突き合わせの材料になったAppleの音声認識は間違えています。
正解にたどり着いた要因が語彙ヒントなのか、外部の音声認識との合議なのか、たまたまなのか。この回に関しては切り分けられません。
経路③ /voiceディクテーション — ここでも揺れました
agyにはv1.1.21で/voiceディクテーションが追加されています。
変更履歴には、発話をそのままプロンプトに書き起こすこと、f5または/voiceで開始・停止すること、mic-serveサブコマンドでSSH越しに手元のマイクを別マシンのCLIへ転送できること、そしてライブのディクテーションは1アカウントにつき同時1本までであることが書かれています。
agy mic-serve --helpも実在し、既定で127.0.0.1:4713をlistenします。
中身をもう少し覗いてみました。
まず、つなぎ方です。
/voiceを起動すると、agyはサーバーとの間に「通話」に近い接続を張ります。
録り終えた音声ファイルを送って結果を待つ、という形ではありません。喋っている端から音声を送り、認識された文字が端から返ってくる。だから画面にリアルタイムで文字が出てくるわけです。
そしてもう一つ、面白い仕組みが入っていました。
その接続には、音声と一緒に「この単語が出てきそうです」という単語のリストを渡せるようになっています。
人間の書記に「今日は『デュスク』と『大竹』が出ますからね」と先に伝えておくのと、発想は同じですね。
ファイル添付の試行2で、私が手で書いたヒント文がありました。あれの自動版に見えます。
実際、送った単語リストの件数をログに出す実装まで用意されています(コードの中ではAsrContextという名前で扱われていました)。
ただし、ここまでで確認できたのは「プログラムファイルの中身を覗いたら、そういう仕組みのコードの痕跡があった」ということだけです。
もう一点、どのモデルが動いているのかは分かりませんでした。プログラムファイルの中にgemini-3.5-transcribeという文字列は1つもありません。
呼んでいるのはVertex AIの音声ストリーミング認識で、どのモデルにルーティングされているかは手元からは分かりません。
それで、実際に喋ってみました。
ファイル添付のときと同じ原稿を、マイクに向かって3回読み上げます。毎回/newで新しいセッションにしました。
回 | プロンプトに入力された社名 | 数字 |
|---|---|---|
1回目 | 株式会社ディスク | 30分 / 2名 |
2回目 | 株式会社デュスク(正解) | 30分 / 2名 |
3回目 | 株式会社デュスク(正解) | 30分 / 2名 |
3回中1回、「ディスク」になりました。
白状すると、私はこの3回を「全部ちゃんと出た」と思っていました。
あとから履歴を見返して、1回目が違うことに気づいたんです。
「デュスク」と「ディスク」。字面が似すぎていて、画面を流し読みしていると気づけません。
これ、議事録に使うことを考えると地味に怖い話です。
間違いに気づけないまま残る、という種類の間違い方だからです。
なお数字の正規化は3回とも効いていました。「三十分」も「二名」も、ちゃんと「30分」「2名」で入っています。
これで、私の手元で観測した社名の化け方は3種類になりました。
- ドゥスク — ファイル添付、モデルが直接聴いた回
- デスク — ファイル添付、Appleの音声認識が返した結果
- ディスク —
/voiceのディクテーション
経路が変われば化け方も変わる。そしてどの経路でも揺れる、というのが正直なところです。
ひとつ、確かめたけれど分からなかったことも書いておきます。
先ほどの「この単語が出てきそうです、と先に渡す仕組み」です。もしあれが効いているなら、正解した2回はその恩恵かもしれません。
そう思って当日のCLIログを全部調べたのですが、その仕組みが実際に動いた形跡は1行も見つかりませんでした。既定のログレベルでは出力されないようです。
ですから言えるのは「そういう仕組みのコードが入っている」までです。実際に動いていたかどうかは確認できていません。
そもそも、この3回はすべて自分の作業フォルダの中で実行しています。ファイル名も会話履歴もたっぷりある状態です。
それでも3回に1回は化けました。
この実測は、あくまで一例です
正直に限界を並べておきます。
- 音源が合成音声です。雑音ゼロ・声の被りゼロ。実際の会議室の録音はもっと厳しいはずです。社名の誤変換も、合成音声側の発音の癖が原因である可能性を排除できていません
- 回数が少なすぎます。語彙ヒントなしで3回、ありで2回。この試行数で「ヒントが効く」と結論づけることはできません
- 試行2の1回目は、外部の音声認識との合議でした。語彙ヒントの寄与だけを取り出せていません
- 短い音声1本のみ。長さの制限も話者分離も試せていません
/voiceも3回だけ。長い発話や専門用語だらけの指示は試していません- ファイル添付と
/voiceは条件が違います。合成音声と生身の声。両者の成績を直接比べることはできません - 作業フォルダの外で
/voiceを試していません。周囲のファイル名や会話履歴が認識に効いているのかどうかは、切り分けられていません - バイナリを調べて言えるのは「その文字列が入っていない」ことだけです。サーバ側でどのモデルが動いているかを否定する証拠ではありません
したがってこの結果は、Googleの発表が間違っているという話ではありません。
価格を、額面ではなく中身で比べる
公表されている単価
Google公式のpricingページの値です。
モデル | 入力(音声) | 出力(テキスト) |
|---|---|---|
| $2.00 / 100万トークン(≒ $0.003/分) | $12.00 / 100万トークン(≒ $0.002/分) |
| $3.50 / 100万トークン(≒ $0.005/分) | $21.00 / 100万トークン(≒ $0.004/分) |
Google自身が「実効の混合レートは1分あたり約$0.005」と注記しています(ファイル版)。ライブ版を同じように計算すると約$0.009/分です。
無料枠もあります。
OpenAIと並べる
OpenAI公式のpricingページの値です(2026年8月29日確認)。
モデル | 単価 |
|---|---|
| $0.0045 / 分 |
| $0.006 / 分 |
| $0.017 / 分 |
Whisper | $0.006 / 分 |
並べると、線がはっきり引けます。
- ファイル文字起こしはほぼ互角。Gemini 約$0.005/分に対してOpenAI $0.0045/分。むしろOpenAIがわずかに安い
- リアルタイムは差が大きい。Gemini 約$0.009/分に対してOpenAI $0.017/分で、おおよそ半額
つまり「Googleが出したから安くなった」は、ライブ用途に限った話です。
「1分いくら」の意味が、両者で違う
ここが本題です。
OpenAIは分単位の固定課金です。1時間の録音なら、喋った量に関係なく額が決まります。
Googleはトークン課金で、pricingページの「1分あたり」は、1秒あたり25音声トークン・1分あたり175テキストトークンという想定を置いた換算値です。
何が起きるか。よく喋る会議は想定より高くなりうるし、沈黙の多い録音は安くなります。
実務的に効いてくるのは、見積もりの立てやすさです。社内稟議に「月いくら」と書く必要があるなら、固定課金の方が話が早い。
実際のブレ幅までは測っていないので、「そういう課金構造になっている」というところまでにしておきます。
円換算の目安
1ドル150円換算で計算すると、こうなります。
- 1時間の録音をファイル版で処理: 実効レート約$0.005/分 × 60分で約$0.30(約45円)
- 1時間のライブ: 同じく約$0.009/分 × 60分で約$0.54(約81円)
精度の数字は、誰が測ったものか
ここは出典を分けて書きます。混ぜると意味が変わってしまうので。
Googleが発表で挙げた数値は、平均の単語誤り率(WER)でストリーミング4.0%、非ストリーミング2.6%。GoogleはこれをArtificial Analysisによる測定として引用しています。
旧モデルとの比較では、Chirp 3比で「最終的な文字起こしが出るまでの時間」が70%改善したとGoogleは公表しています。
FLEURSベンチマーク(上位ロケール)では、ストリーミング5.50%、非ストリーミング5.04%。
日本語のFLEURS WERは5.90%という第三者まとめの数値もありますが、これは私の実測ではなく、第三者記事の表からの引用です。
そのうえで一言添えておきます。
WERはベンチマーク音源での数字であって、雑音の入った会議室や、複数人が被って喋る録音や、専門用語だらけの現場の数字ではありません。
そして今回私が引っかかった「社名」のような固有名詞の誤りは、WERにはほとんど表れません。1単語の誤りですから。
制約から逆算すると、使える会議と使えない会議が分かれる
公式ドキュメントに書かれている制限です。
- ファイル版は1リクエストあたり最大1時間
- 話者分離または単語単位タイムスタンプを有効にすると、最大30分
- ライブ版は1セッション10分
- 話者分離のラベルは最大8人分。ただしGoogleは3人以上への割り当てをexperimental(実験的)と位置づけています
- カスタム語彙は最大1,000語。ただし公式ドキュメントに「実運用では100語程度までが最も結果が良い」という趣旨の注記があります
- 非対応: コンテキストキャッシュ、バッチAPI、コード実行。バッチAPI非対応は、溜めた録音をまとめて一括処理できないという意味を持ちます
これを会議の型に当てはめると、こう分かれます。
会議の型 | 判定 | 理由 |
|---|---|---|
30分の1on1(2人) | 素直に通る | 30分制限に収まり、話者2人ならexperimentalの外側 |
60分の週次MTG(4〜5人) | ひと工夫要る | 話者分離ありだと30分超で分割が必要。3人以上の割り当ては実験的 |
リアルタイム字幕(常時) | 設計が要る | 1セッション10分。張り替えの実装が前提になる |
顧客ヒアリング録音 | 技術以前の話 | 録音の同意・情報の取り扱いを先に整理する |
30分の1on1が、いちばん素直にハマります。
SESで客先常駐だと、エンジニアと上司が物理的に離れていることが多い。そこと相性がいいんですよね。
60分の会議は「30分で切って2回投げる」で回避できますが、分割点をまたぐ話者ラベルの対応づけは自前になります。
何が言えて、何が言えないのか
言えないことを先に置きます。
- 「Antigravityではgemini-3.5-transcribeが動いていない」— 手元からモデルを特定できなかっただけです
- 「Gemini 3.5 Transcribeは固有名詞に弱い」— 今回書き起こしたのはGemini 3.7 Flashであって、transcribeモデルではありません
- 「
/voiceはコンテキスト送信のおかげで社名を正しく出した」— その仕組みが動いた形跡はログに1行もありません。言えるのは「実装がバイナリにある」までです - 「作業フォルダの文脈が効いている」— 切り分け実験をしていません。そもそも文脈たっぷりの場所で3回に1回化けています
- 「試行2ではGeminiが正しく書き起こした」— 1回目は外部の音声認識との突き合わせの結果であって、モデル単独の成果ではありません
- 「語彙ヒントを渡せば直る」— そう見えますが、試行数は3回と2回。断定できる回数ではありません
- 合成音声1本・数回の結果から、一般的な精度を語ること
そのうえで言えることです。
- 「◯◯で使える」という発表は、「自分の手元からそのモデルを名指しで呼べる」を意味しない。経路によって動くものが違いました
- 同じ入力でも結果は揺れます。ファイル添付では3回中2回、
/voiceでも3回中1回、社名が化けました。1回試して動いたから大丈夫、とは言えません - 間違いに気づけない種類の間違いがあります。「デュスク」が「ディスク」になっても、流し読みでは気づけません。私は実際に見落としました
- 最初に間違えられるのは、たいてい自分にとって一番大事な固有名詞です。今回は社名でした
- 固有名詞を先に渡すのは、試す価値があります。タダで、モデルが何であれ害はありません
- エージェント経由だと、実行のされ方まで毎回変わります。同じ指示で、直接聴くだけの回もあれば、外部ツールを探して自分でコードを書く回もありました
- 価格は用途で結論が変わる。ファイルはほぼ互角、リアルタイムはGeminiが約半額
- 実務で効くのは価格より制約。話者分離を使うと30分、ライブは10分
今すぐ確認・検討すべきこと
- 自社・自チームの固有名詞リストを100語くらい作っておく。社名・サービス名・メンバー名・頻出する技術用語。文字起こしでもディクテーションでも使い回せます
- 自分の会議の長さと人数を数える。30分・2人に収まるものから試すのが最短です
- ツールを比較するとき、「1分いくら」の課金方式(固定かトークンか)まで見る
- リアルタイムが本当に要るのかを疑う。要らないならファイル版で足りますし、そこでは価格差はほぼありません
- ニュースで「◯◯で使えるようになりました」を見たら、自分の使っている経路で5分だけ触って確かめる。名指しで呼べるのか、別のものが動くのかで、運用の作り方が変わります
- 顧客との会話を録るなら、同意と情報の取り扱いを先に決める。ツール選定より前の話です
- 会議データを外部ツールに預けるリスクについては、AI議事録ツールtl;dvで18万件の会議データが流出した件も参考になります
まとめ
Googleが2026年8月26日に、Gemini 3.5 Transcribeをpublic previewで公開しました。
発表どおりAntigravityには入っていましたが、手元のCLIからモデルを名指しで呼ぶことはできませんでした。
音声ファイルを投げる経路は動きました。ただし処理したのは通常のチャットモデルです。
そこで最初に間違えられたのが、自分の会社の名前でした。3回投げて、正しく出たのは1回だけです。
固有名詞を先に渡した2回は、どちらも正しく出ました。
ただしそのうち1回は、モデルが勝手にSwiftを書いてAppleの音声認識を呼び、その結果と突き合わせていました。Geminiが単独で当てたわけではありません。
ちなみにそのAppleの音声認識は「デスク」と間違えています。3つ目の化け方でした。
マイクに向かって喋る/voiceでも、3回中1回は「ディスク」になりました。
そしてその1回を、私は見落としていました。あとから履歴を見返すまで、3回とも正しく出たと思い込んでいたんです。
結局どの経路でも揺れます。1回試して動いたから大丈夫、とは言えません。
価格はファイルならほぼ互角、リアルタイムならGeminiが約半額。ただし課金方式の性質が違います。
実務で効くのは制約です。話者分離で30分、ライブで10分。
持ち帰っていただきたいのは「安いらしい」ではなく、自分の経路で触って確かめるという順番の方です。
次は実際の1on1の録音で試してみるつもりです。合成音声では分からないことが、まだ残っているので。
参考・出典
- Gemini 3.5 Transcribe 公式ドキュメント: https://ai.google.dev/gemini-api/docs/models/gemini-3.5-transcribe
- Gemini API 価格: https://ai.google.dev/gemini-api/docs/pricing
- Google公式ブログ(2026年8月26日): https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5-transcribe/
- Google DeepMind - AI transcription: https://deepmind.google/models/gemini-audio/ai-transcription/
- OpenAI API 価格: https://developers.openai.com/api/docs/pricing
- Antigravityへの搭載についての報道(9to5Google, 2026年8月26日): https://9to5google.com/2026/08/26/gemini-3-5-transcribe/
- 日本語のFLEURS WERなど第三者まとめ: https://www.autointerviewai.com/blog/gemini-3-5-transcribe-speech-to-text-review-2026
/voiceと音声添付についての記述はagy changelog(v1.1.21 / v1.1.18)より
