Gemini 3.5 Transcribeとは？85言語対応・話者分離・料金と使い方を徹底解説【2026年8月最新】

Gemini 3.5 Transcribeは、Googleが2026年8月26日（現地時間）に公開プレビューで提供を開始した、音声をテキストに変換することに特化したGeminiモデルです。 単に聞こえた音を文字にするのではなく、「えーと」「あのー」といったフィラーの除去、言い直しの整理、日付や箇条書きの整形まで含めて、そのまま使える文章として出力する点が従来型の音声認識との最大の違いです。

この記事では、Gemini 3.5 Transcribeの機能、精度、料金（実務ベースの月額試算つき）、使い方、そして導入前に必ず知っておくべき機能の組み合わせ制限までを、公式ドキュメント・Google公式ブログ・DeepMindモデルカードを突き合わせて整理します。

想定読者は次のとおりです。

• 議事録・字幕・コールセンターの文字起こしを自動化したいと考えている企業の担当者
• Whisper系やGoogle Cloud Speech-to-Text（Chirp 3）からの乗り換えを検討している開発者
• APIは書かないが「自分のスマホやPCで使えるのか」を知りたい一般ユーザー

なお本モデルは2026年8月時点で公開プレビュー段階です。料金・上限・機能は今後変更される可能性があるため、本番導入前には必ず公式ドキュメントで最新値を確認してください。

出典: Google 公式ブログ

Gemini 3.5 Transcribeとは何か

出典: Google DeepMind 公式サイト

Gemini 3.5 Transcribeは、Gemini APIおよびGoogle AI Studioで提供される音声認識（Speech-to-Text）専用モデルです。Googleは公式ブログで「これまでで最も精密な音声テキスト変換モデル（most precise speech-to-text model yet）」と表現しています。

DeepMindが公開しているモデルカードによれば、アーキテクチャはGemini 3 Proをベースとした専用オーディオモデルで、リアルタイム音声翻訳のGemini 3.5 Live Translateと同じ「Gemini 3.5 Audio」ファミリーに属します。

基本スペック

モデルは2種類ある

用途によって使うモデルIDが分かれます。ここを取り違えると必要な機能が使えないため、最初に確認しておくべきポイントです。

録音済みファイルを扱うならgemini-3.5-transcribe、マイク入力をその場で文字にするならgemini-3.5-transcribe-live、という切り分けになります。

従来の音声認識モデルと何が違うのか

違いは「聞こえたままを返すか、そのまま使える文章を返すか」にあります。

従来型の音声認識（Google CloudのChirp 3やWhisper系を含む）は、発話をできる限り忠実に文字化することを目的としています。そのため出力には「えーと」「あのー」といったフィラー、言い直し、句読点の乱れがそのまま残り、実務で使うには人手または別のLLMによる後処理が必要でした。

Gemini 3.5 Transcribeは、この整形処理をモデル自身が1回の推論で行うように設計されています。Googleが公式ブログで挙げている改善点は次の3つです。

• フィラーの除去: "um" "ah"（日本語の「えーと」「あのー」に相当）を落とす
• 言い直しの解決: 「明日、いや明後日の14時に」→「明後日の14時に」のように、話者が自己訂正した内容を反映する
• 自動整形: 箇条書き・日付・数値表記などを読める形に整える

加えて、DeepMindのページでは電話番号・郵便番号・注文IDといった英数字列の認識精度が強調されています。コールセンターや受注業務のように「数字を1桁間違えたら業務が破綻する」領域では、この差は無視できません。

Chirp 3（Google Cloud Speech-to-Text）との関係

よくある誤解ですが、Gemini 3.5 TranscribeはChirp 3の後継として発表されたわけではありません。Googleは「Chirp 3を置き換える」とは明言していません。

つまり、両者は別プラットフォームで併存している状態です。すでにGoogle Cloud上でChirp 3を運用している場合、乗り換えはSDK・課金・IAM設計の変更を伴います。「同じGoogleだからすぐ差し替えられる」とは考えない方が安全です。

Gemini 3.5 Transcribeでできること

出典: Google Gemini 公式サイト

公式ドキュメントに記載されている機能サポート状況は次のとおりです。ライブ版では使えない機能があるため、モデル選定の前に確認が必要です。

スマートモードと逐語モード

出力の性質を決める2つのモードがあります。デフォルトは逐語（verbatim）モードである点に注意してください。「フィラーが消えない」という声の多くは、スマートモードを明示的に指定していないことが原因です。

話者分離（誰が話したかの切り分け）

ファイル処理側では、発言を話者A・B・Cのように切り分ける話者分離が使えます。ただしこれは声紋で個人を特定する機能ではありません。「この声は田中さん」と判定するのではなく、「別の人が話し始めた」ことを検出して番号を振る処理です。話者名の紐付けは、利用側で議事録の出席者リストと突き合わせる必要があります。

対応可能な話者数については、Google公式ブログ・DeepMindページとGemini APIドキュメントで記載が割れています。共通しているのは「3人以上は実験的な扱い」という点であるため、実務では3話者程度までを前提に設計するのが安全です。

カスタム語彙（speech biasing）

社名・製品名・専門用語・独自スペルを最大1,000語まで登録し、認識を寄せることができます。ただし公式ドキュメントは「約100語程度が最良」と明記しており、上限まで詰め込むと精度が落ちる可能性があります。

このモデルの知識カットオフは2025年1月です。2025年以降に登場した製品名・サービス名・人名は誤変換されやすいと想定されるため、カスタム語彙で補うのが現実的な運用になります。

85言語以上の自動検出と日本語対応

言語は自動検出されますが、BCP-47コード（ja-JP、es-ESなど）で明示指定することもできます。日本語・中国語（簡体/繁体）・韓国語・アラビア語・ヒンディー語などを含み、会話中に言語が切り替わるコードスイッチングにも対応しています。日英が混ざる社内会議では実用的な機能です。

なお、日本語単体のWER（単語誤り率）の公式値は公表されていません。日本語での精度を判断したい場合は、自社の実音声で必ず試験してから採用を決めてください。

対応音声フォーマット

WAV / MP3 / AIFF / AAC / OGG / FLAC / MPEG / M4A / L16 / Opus / ALAW / MULAW / WebM

Web会議ツールの録音（M4A、WebM）や電話系のコーデック（ALAW、MULAW）がそのまま通るため、変換工程を挟まずに投入できるケースが多いはずです。

精度はどれくらいか：2つのWER値を正しく読む

Googleが公表している精度の数値は出所によって異なります。前提条件の違う2系統の値が流通しているため、両方を並べて整理します。

数値が2系統ある理由は、測定に使ったデータセットと対象ロケールが違うためです。公式ブログの2.6%／4.0%は平均WER、DeepMind側の5.04%／5.50%はFLEURSベンチマークの上位ロケールを対象とした値として提示されています。

実務上の読み方としては、次のように捉えるのが妥当です。

• 条件のよい音声（クリアな録音、主要言語）ならWER 3%前後が期待値
• 一般的なベンチマーク条件では5%前後
• 会議室の反響、複数人の同時発話、電話回線の帯域制限がある音声ではさらに悪化する前提で設計する

WERは録音品質・話速・専門用語の頻度で大きく変わります。「2.6%だから修正不要」と考えるのは危険で、自社の実音声での試験は必須です。

なお、一部の日本語記事は「第三者機関の計測」としてこれらの数値を紹介していますが、当編集部で確認した限り一次情報はGoogle公式ブログとDeepMindページであり、独立した第三者計測は確認できませんでした。

導入前に必ず確認すべき制約

Gemini 3.5 Transcribeを「使えるかどうか」を実質的に決めるのは、精度よりも制約の組み合わせです。

1. 音声長の上限は3種類ある

話者分離を使った瞬間に上限が30分に半減する点は要注意です。60分の会議を話者付きで文字起こしするなら、音声を30分以下に分割して2回投げる設計が必要になります。分割位置が発言の途中にかかると話者番号の連続性が失われるため、無音区間で切る前処理を用意しておくとトラブルが減ります。

ライブ版の10分制限も同様で、長時間の通話や配信ではセッションの張り直し処理を実装側で持つ必要があります。

2. スマートモードと話者分離・タイムスタンプは併用できない

これが議事録用途における最大の落とし穴です。公式ドキュメントによれば、スマートモードはdiarization_mode（話者分離）およびtimestamp_granularities（タイムスタンプ）と併用できません。

つまり、以下のような出力は1回のリクエストでは得られません。

【田中】明後日の14時に、以下3点を確認します。（00:12:33）

「誰が話したか」「いつ話したか」を取ると整形が効かず、整形を取ると話者とタイムスタンプが落ちる、という排他関係になっています。

回避策：2パス実行

実務では、同じ音声に対して2回リクエストを投げる運用が現実的です。

2回目の出力を議事録本文、1回目の出力を発言者・時刻の索引として保持し、必要に応じて突き合わせます。コストは単純に2倍になりますが、実効レートが1時間あたり約$0.30であることを考えれば、1時間の会議で$0.60（100円未満）です。人手で話者を振り直す工数と比べれば十分に許容範囲でしょう。

3. タイムスタンプを有効にすると精度が下がる

公式ドキュメントには、単語レベルのタイムスタンプを有効にすると文字起こし精度が低下すると明記されています。字幕制作のようにタイムコードが必須の用途以外では、安易にオンにしない方が結果は良くなります。

4. 非対応の機能

大量の音声を夜間にまとめて安く処理するBatch APIが使えない点は、月数百時間規模の処理を想定している場合にコスト計算へ影響します。

5. ハルシネーションと遅延

DeepMindのモデルカードでは、音声に存在しない語を生成するハルシネーション、および時折発生する遅延・タイムアウトが既知の制約として挙げられています。無音区間の長い音声や、極端に音量の小さい発話で起きやすい傾向があります。医療・法務・金融など誤記の影響が大きい領域では、人によるレビュー工程を必ず残してください。

6. Function callingの扱いは記載が割れている

Google公式ブログは「複雑なタスクを他のGeminiモデルへ委譲できる（function calling）」と説明していますが、Gemini APIのモデルドキュメントの機能表では function calling は非対応と記載されています。現時点では断定できないため、この機能を前提にした設計は避け、必要ならGemini 3.7 Flashなどの汎用モデルに後段処理を任せる構成にしておくのが無難です。

7. 話者数の記載も割れている

いずれにせよ「3人以上は実験的」という表現は共通しているため、4人以上の会議で話者分離の精度を当てにする設計は避けるべきです。役員会議や10人規模の定例では、話者分離ではなく発言者を手動で補記する運用の方が確実です。

用途別「使える機能の組み合わせ」早見表

制約を踏まえ、代表的な用途で実際に何が使えるのかを整理しました。導入検討時はこの表で自社の用途が成立するかを先に判断してください。

△＝別リクエストなら可能（同時には不可）

最も相性が良いのは音声入力用途です。話者が1人で、タイムスタンプも不要なため、スマートモードの整形能力をそのまま享受できます。逆に最も設計が面倒なのは議事録用途で、ここで2パス実行の必要性を見落とすと「思っていた出力が出ない」という結論になりがちです。

料金：実務ベースの月額試算つき

Gemini APIの公式価格表（2026年8月時点）に基づく料金は次のとおりです。トークン課金であり、分単位の定額ではありません。

出典: Google AI for Developers 公式サイト

実効レートは、Googleが示す試算前提（音声＝25トークン/秒、テキスト出力＝175トークン/分）に基づく目安です。話速が速い言語、出力量が多い音声ではこれより高くなります。

実務での月額イメージ

日本企業で発生しやすい利用量に当てはめた概算です（1ドル＝150円換算、参考値）。

多くの企業にとって、文字起こしのAPI費用そのものはほぼ誤差の範囲であることが分かります。月8時間の会議なら2パス実行しても1,000円未満です。導入判断のボトルネックは費用ではなく、機能の組み合わせ制限への適合と、録音・保管まわりの運用設計になります。

一方、SaaS型の文字起こしツール（ユーザー課金・月額数千円/人）と比べると、社内に開発リソースがある企業ほどAPI直利用のコストメリットが大きい構図です。逆に開発リソースがない場合は、既製の議事録SaaSの方が総コストは低くなります。

無料枠について

Gemini APIには無料ティアが存在しますが、transcribe系モデルの具体的なレート制限値は公式のレートリミット表で確認できませんでした。利用可能な回数・同時セッション数はGoogle AI Studioのダッシュボードで確認してください。

また、Gemini APIの無料ティアは一般に入力データがモデル改善に利用される規約です。会議音声・顧客対応の録音・医療や金融の機微情報を無料枠で処理するのは避け、有料ティアまたはGemini Enterprise Agent Platform側の規約を必ず確認してから運用に乗せてください。

なお、法人向けのGemini Enterprise Agent Platformにおける個別課金レートは公式ページから数値を確認できませんでした。法人利用は営業窓口での見積もり確認が必要です。Gemini Enterprise Agent Platformの全体像も合わせて確認しておくと判断しやすくなります。

Gemini 3.5 Transcribeの使い方

出典: Google AI Studio 公式サイト

手順1：Google AI Studioでノーコードに試す

APIキーの発行前に感触を掴みたい場合は、Google AI Studioでモデルを選択し、音声ファイルをアップロードするだけで出力を確認できます。日本語の会議音声を1本投げてみるのが、精度判断としては最も早い方法です。

手順2：APIで文字起こしする（Python最小構成）

公式ドキュメントに掲載されている最小コードは次のとおりです。Files APIで音声をアップロードし、Interactions APIに渡します。

from google import genai

client = genai.Client()

audio_file = client.files.upload(file="path/to/sample.mp3")

interaction = client.interactions.create(
    model="gemini-3.5-transcribe",
    input=[{
        "type": "audio",
        "uri": audio_file.uri,
        "mime_type": audio_file.mime_type
    }]
)

print(interaction.output_text)

手順3：オプションを追加する

カスタム語彙（社名・専門用語を登録）

generation_config = {
    "transcription_config": {
        "custom_vocabulary": ["Gemini", "Kubernetes", "BigQuery"]
    }
}

話者分離

"mode": {"type": "verbatim", "diarization_mode": "speaker"}

単語レベルのタイムスタンプ

"mode": {"type": "verbatim", "timestamp_granularities": ["word"]}

いずれもスマートモードとは併用できないため、整形済み本文が必要なら別途スマートモードで再実行します。

手順4：リアルタイム処理はLive APIを使う

ストリーミング用途では、モデルIDをgemini-3.5-transcribe-liveにしてLive API（WebSocket）へ接続します。1セッション10分の制限があるため、長時間の通話ではセッションを継ぎ足す処理と、継ぎ目でのテキスト結合処理を実装側で用意してください。JavaScript・RESTの実装例も公式ドキュメントに掲載されています。

APIを書かない人はどこで使えるのか

Gemini 3.5 Transcribeは、開発者向けAPIだけでなくすでにGoogleの一般向け製品にも組み込まれています。コードを書かずに体験したい場合は次の経路があります。

Gboardの「Rambler」は、思いつくままに話した内容をそのまま整った文章にするモードで、Gemini 3.5 Transcribeの整形能力を最も分かりやすく体験できる機能です。Pixel 11シリーズで先行搭載されており、他機種への展開時期は現時点で未公表です。Android全体でのAI機能の広がりはGemini Intelligence for Androidの解説でも整理しています。

macOSでの利用感についてはGemini for Mac（Option+Space）の解説、ブラウザ側の統合についてはGemini in Chromeの解説を参照すると全体像が掴めます。

他の音声認識AI・関連モデルとの違い

出典: Google Cloud 公式サイト

主要なSpeech-to-Text APIとの比較

2026年時点で選択肢になる主なAPIを、料金と機能で並べます。

注意点として、各社が公表するWER（単語誤り率）は測定データセットも対象言語も異なるため、横並びの比較はできません。 「A社4%、B社8%だからA社が2倍正確」という読み方は誤りです。候補を2〜3社に絞ったうえで、自社の実音声で同一条件のテストを行うことが唯一の正しい選定方法です。

選び分けの目安は次のとおりです。

• 出力をそのまま人が読む用途（議事録、記事下書き、口述筆記）→ 整形が効くGemini 3.5 Transcribe
• 音声エージェントの応答速度が最優先→ Deepgram、またはGPT-Liveのような全二重対話モデル
• 既にOpenAIでワークフローを組んでいる→ GPT-Realtime-2を含むOpenAI系で統一した方が実装コストは低い
• 文字起こし後の感情・トピック分析まで一気通貫で欲しい→ AssemblyAI
• 音声合成側もまとめたい→ ElevenLabs系

Gemini 3.5 Live Translateとの違い

同じGemini 3.5 Audioファミリーですが、目的が異なります。

英語の会議を「日本語の音声で」聞きたいならLive Translate、「テキストの記録として残したい」ならTranscribe、という切り分けになります。詳細はGemini 3.5 Live Translateの解説記事で整理しています。

文字起こし後の活用まで含めた設計

Gemini 3.5 Transcribeが返すのはあくまでテキストです。要約・アクションアイテム抽出・ナレッジ化まで行うなら、出力をGemini Notebook（旧NotebookLM）のような文書処理ツールに渡すか、汎用モデルで後段処理する構成になります。文字起こしと要約を1つのモデルで完結させようとしない方が、精度もコストも安定します。

セキュリティ・録音同意・データ取り扱いの注意点

音声データは、テキスト以上に慎重な扱いが求められる情報です。技術検証と並行して、次の3点を必ず社内で確認してください。

1. 録音と文字起こしの同意取得

会議・商談・カスタマーサポート通話を録音して文字起こしする場合、参加者への事前告知と同意取得は実務上ほぼ必須です。日本の法令が一律に禁じているわけではありませんが、社外の相手が含まれる商談録音は、告知なしで運用すると信頼関係の毀損や契約上の問題につながります。会議冒頭のアナウンス文と、議事録への録音有無の明記をテンプレート化しておくのが現実的な対処です。

音声データの権利まわりについては、法務省の「声の権利」に関する指針の解説も参考になります。

2. 話者分離は個人データの処理になりうる

話者分離自体は個人特定機能ではありませんが、出力された話者ラベルを出席者名簿と紐付けた時点で、「誰が何を発言したか」という個人に紐づくデータになります。保管期間・アクセス権限・削除フローを社内規程に組み込んでください。個人情報保護法上の取り扱いについては法務部門の確認が必要です。

3. どのティアで処理するか

Gemini APIの無料ティアは、一般にデータがモデル改善に利用される規約です。業務音声は有料ティア、または法人向けプラットフォームで処理するのが原則になります。特に医療・金融・法務の音声は、データ所在地（リージョン）とログ保持ポリシーの確認まで済ませてから本番投入してください。Gemini Enterprise Agent Platform側のデータガバナンス条件は公式ページから確認できなかったため、営業経由での確認が必要です。

なお、Gemini 3.5 TranscribeにはGoogleのAI原則および生成AI禁止使用ポリシーが適用されます。DeepMindのモデルカードによれば、開発中に自動評価・人手レビュー・倫理評価が実施されており、フロンティア安全性の観点では「Gemini 3.1 Pro / 3.7 Flashと比較して新たな危険能力や大幅な性能増はない」と評価されています。

こんな人・企業におすすめ

次の条件に当てはまる場合、Gemini 3.5 Transcribeは有力な選択肢です。

• 社内に開発リソースがあり、既存システムに文字起こしを組み込みたい企業。API直利用のコストメリットが最も大きい層です
• 整形済みのテキストがそのまま欲しい用途。議事録の下書き、インタビュー原稿、音声メモの文書化など、後処理工数を削りたいケース
• 多言語の会議・問い合わせを扱う組織。85言語以上の自動検出とコードスイッチング対応は、言語ごとにモデルを切り替える手間をなくします
• 電話番号・注文ID・郵便番号を正確に取りたい業務。受注センターや予約受付など、英数字列の誤変換が業務事故に直結する領域
• すでにGemini APIを使っている開発チーム。認証・SDK・請求が既存の仕組みに乗ります
• 音声入力・口述筆記を業務に組み込みたい個人・チーム。制約の影響を最も受けにくく、整形の恩恵が最も大きい用途です

おすすめしない人・見送るべきケース

• 開発リソースがなく、明日から議事録を自動化したい組織。APIをそのまま使うのは現実的ではなく、既製の議事録SaaSを選ぶ方が総コストは低くなります
• 1回で「話者名つき・タイムコードつき・整形済み」の議事録が欲しい人。機能の排他関係により、単一リクエストでは実現できません
• 4人以上の会議で話者分離の精度を業務前提にしたい組織。3人以上は実験的扱いであり、精度を保証できません
• 60分を超える音声を分割せずに投げたい場合。特に話者分離を使うなら30分が上限です
• 本番SLAが必要な基幹業務。2026年8月時点で公開プレビュー段階であり、仕様・料金・可用性は変更されうる状態です
• Google Cloud上でChirp 3を安定運用中で、乗り換え工数を割けない組織。プラットフォームが異なるため、移行はSDK・課金・権限設計の変更を伴います
• オンプレミス・完全ローカル処理が必須の組織。クラウドAPIである以上、音声は外部に送信されます。この場合はローカル実行可能なモデルを検討してください

よくある質問

Q. Gemini 3.5 Transcribeは無料で使えますか？

Gemini APIには無料ティアがあり、transcribe系モデルも無料枠の対象です。ただし具体的なレート制限値は公式のレートリミット表で確認できず、Google AI Studioのダッシュボードでの確認が必要です。無料ティアはデータがモデル改善に利用される規約が一般的なため、業務音声の処理には使わないでください。

Q. 日本語の精度はどれくらいですか？

日本語単体のWERは公表されていません。公式が示すのは全体平均（2.6%／4.0%）とFLEURS上位ロケールの値（5.04%／5.50%）のみです。日本語は同音異義語が多く、固有名詞・敬語表現の扱いで結果が変わるため、自社の実音声でのテストが不可欠です。

Q. 「えーと」を消すにはどうすればいいですか？

スマートモードを明示的に指定してください。デフォルトは逐語モードで、フィラーを含めてそのまま出力されます。

Q. 話者分離で「田中さん」のように名前を出せますか？

できません。話者分離は「別の人が話し始めた」ことを検出して話者A・B・Cと番号を振る処理であり、声紋による個人特定機能ではありません。名前の紐付けは利用側で行う必要があります。

Q. 話者分離とタイムスタンプと整形を全部同時に使えますか？

1回のリクエストではできません。スマートモード（整形）は話者分離・タイムスタンプと併用できない仕様です。同じ音声に対して設定を変えて2回実行し、結果を突き合わせる運用が現実的です。

Q. 3時間のセミナー録画を一度に処理できますか？

できません。通常リクエストは最大60分、話者分離やタイムスタンプを使う場合は最大30分が上限です。事前に分割してください。無音区間で切ると、分割の継ぎ目での欠落を減らせます。

Q. Chirp 3から乗り換えるべきですか？

用途によります。整形済みテキストが欲しい、最終確定までの時間を短縮したい場合はメリットがあります。ただし提供プラットフォームが別（Gemini API vs Google Cloud Speech-to-Text）であり、SDK・課金・権限設計の変更が必要です。Googleも「Chirp 3を置き換える」とは明言していません。

Q. リアルタイム字幕に使えますか？

gemini-3.5-transcribe-liveで可能です。ただし1セッション10分の制限があり、話者分離と単語タイムスタンプは使えません。長時間の配信ではセッションの継ぎ足し処理が必要です。

Q. Gemini 3.5 Live Translateとの違いは？

Transcribeは「音声→同一言語のテキスト」、Live Translateは「音声→別言語の音声」です。文字起こしと通訳という別の目的のモデルです。

まとめ

Gemini 3.5 Transcribeは、2026年8月26日に公開プレビューで登場した音声認識専用モデルで、フィラー除去・言い直しの解決・自動整形まで含めた「そのまま使えるテキスト」を返す点が従来の音声認識との決定的な違いです。1時間あたり約$0.30という料金は、日本企業の一般的な利用量ではほぼ誤差の範囲に収まります。

導入判断のポイントは3つに集約されます。

1. 機能の排他関係を理解しているか — スマートモードと話者分離・タイムスタンプは同時に使えず、議事録用途では2パス実行が前提になります
2. 音声長の上限に耐える設計になっているか — 通常60分、話者分離時30分、ライブ10分の3つの上限があります
3. 音声データの取り扱い体制が整っているか — 録音同意、保管ポリシー、処理ティアの選定は技術検証と並行して進めるべき項目です

そのうえで、公開プレビュー段階であることを踏まえ、まずはGoogle AI Studioに自社の実音声を1本投げて精度を確かめるところから始めるのが最短ルートです。日本語での精度は公式値が存在しないため、実測以外に判断材料はありません。

Geminiシリーズ全体の位置づけを整理したい場合はGemini 3.5 Proの解説、他社の生成AIとの比較検討にはChatGPTとGeminiの比較記事も参考にしてください。