Gemini 3.5 Transcribeは、Gemini APIで音声ファイルを文字に起こすための専用モデルです。結論から言うと、「音声を渡せば文字が返る」だけの機能ではなく、言語の指定、カスタム語彙、話者分離、単語ごとのタイムスタンプ、Smart transcription（読みやすく整える方式）という設定を目的に合わせて選ぶ機能で、しかも一部の設定は同時に使えません。この記事では、公式ページに書かれている範囲だけを土台に、基本の呼び出し方、設定の選び方、同時に使えない組み合わせ、長さと形式の制限、料金の読み方、ライブ（ストリーミング）版との違いまでを順に整理します。
公式のモデルページ（Gemini 3.5 Transcribe）は、このモデルを「Gemini’s audio understanding capabilities（Geminiの音声理解の能力）」に基づく音声文字起こしモデルと説明しています。リリースノート（Gemini API changelog）では、2026年8月26日の項目に「Gemini 3.5 Transcribe generally available (GA)」と書かれています。この記事の内容は、2026年10月4日に取得した公式ページの記載だけを根拠にしています。
この記事に出てくる録音の内容、固有名詞、設定の組み合わせは、考え方を示すために私たちが作った「仮の例」です。実在の利用者の記録や成果ではありません。仮の例として、社内の打ち合わせを録音した音声ファイルがあり、「誰が何を言ったかを残したい」「議事録に使う固有名詞を正しく拾いたい」「あとで該当箇所へ頭出ししたい」という三つの希望が同時にあるとします。後の章で見るとおり、この三つは設定上ぶつかる部分があり、その調整が使いこなしの中心になります。
なお、この記事はGemini APIという開発者向けの機能を扱います。Geminiアプリの音声入力とは別のものです。Gemini APIの料金全体の読み方は料金体系を横断して整理した記事、音声を作る側の機能はテキストから音声を生成するモデルの解説記事で扱っています。
Gemini 3.5 Transcribeとは何か：音声ファイルを文字にする専用モデル
【完全無料】AI×SNSで成果を出す100大特典を受け取る
AIの使い方を、SNS運用の実務につなげたい方へ。LINEで特典の案内を受け取れます。
Gemini 3.5 Transcribeとは、Gemini APIで音声ファイルの話し言葉をテキストに変換するための音声文字起こしモデルで、モデルコードは gemini-3.5-transcribe です。
公式のモデルページは、このモデルの特徴を「utterance-based language detection（発話ごとの言語検出）」「speaker diarization（話者分離）」「word-level timestamps（単語単位のタイムスタンプ）」「Smart transcription」「custom vocabulary speech biasing（カスタム語彙による認識の誘導）」と並べています（モデルページ）。言い換えると、文字にするだけでなく、誰が話したか、いつ話したか、どの言葉を優先して拾うか、読みやすく整えるかどうかまで、設定で調整できる作りです。
ここで押さえておきたいのは、公式ガイドが文字起こしと「音声理解」を別の用途として分けている点です。ガイドには、音声の内容について推論したり質問に答えたりする用途には Audio understanding を、テキストから音声を作る用途には Text-to-speech を使うように書かれています（Audio transcriptionガイド）。つまりこのモデルの役割は、音声を忠実に、または読みやすく文字にするところまでで、要約や分析は別の工程として組み合わせる前提です。
モデルページの機能一覧では、キャッシュ、コード実行、ファイル検索、関数呼び出し、画像生成、Thinkingは「Not supported」とされ、Batch API、Flex inference、Priority inferenceも「Not supported」とされています（モデルページ）。他のGeminiモデルで使える機能を、そのままこのモデルに持ち込めるとは限らない点に注意が必要です。たとえば、外部の関数を呼び出す仕組みはFunction Callingの入門記事、長い入力を再利用する仕組みはコンテキストキャッシュの解説記事で扱っていますが、これらはgemini-3.5-transcribeの対象外と公式ページに書かれています。たとえば、大量のファイルをまとめて安く処理したいときに頼りたくなるバッチ処理は、このモデルでは対象外と書かれています。バッチ処理の仕組みそのものは非同期でまとめて処理する方式の解説記事にありますが、gemini-3.5-transcribeには使えないと公式ページに明記されているため、長い録音が多い場合は1件ずつ順番に処理する設計を考えることになります。
仮の例として、毎回の定例会議を録音し、翌日までに文字の記録を共有したいとします。この場合、文字起こしの工程と、その結果から議事録の体裁を作る工程を分けて考えます。前半をこのモデルに任せ、後半は別のテキスト処理に任せる、という二段構えです。この分担を最初に決めておくと、「文字起こしの設定で議事録まで作らせよう」として設定が衝突するのを避けられます。
2つのエンドポイント：ファイル向けとライブ向けの違い
2つのエンドポイントとは、録音済みの音声ファイルを処理する gemini-3.5-transcribe と、マイクなどの音声を流しながら文字にする gemini-3.5-transcribe-live のことで、使える機能と上限が異なります。
公式のモデルページは、バージョンとして「gemini-3.5-transcribe（Unary）」と「gemini-3.5-transcribe-live（Live API）」の二つを挙げています（モデルページ）。Unaryは、音声を一度に渡して結果を受け取る呼び出し方です。Liveは、WebSocketsで接続したまま音声を流し続け、途中経過と確定結果を受け取る方式です。どちらも同じ「Gemini 3.5 Transcribe」の名前で呼ばれますが、設定できる項目が違います。
モデルページの機能比較は、次のとおりです。同じ項目でも、ファイル向けとライブ向けで可否と上限が変わります。
| 比較する項目 | ライブ向け（gemini-3.5-transcribe-live） | ファイル向け（gemini-3.5-transcribe） |
|---|---|---|
| 言語の自動検出 | 対応（85以上の言語） | 対応（85以上の言語） |
| 単語単位のタイムスタンプ | 非対応 | 対応 |
| カスタム語彙 | 対応（最大1,000語） | 対応（最大1,000語） |
| 話者分離 | 非対応 | 対応（最大8人） |
| 最大の音声の長さ | 1セッションあたり10分 | 最大1時間 |
出典は公式のモデルページの「Feature support and limitations」の表です（Gemini 3.5 Transcribe）。表の読み方として大切なのは、話者分離と単語タイムスタンプが必要なら、選べるのはファイル向けだけだということです。録音の後処理で字幕や頭出しを作りたい場合はファイル向け、画面にその場で字幕を出したい場合はライブ向け、という分け方が基本になります。
仮の例として、オンライン講座の収録を考えます。収録後に動画へ字幕を付けたいならファイル向けで単語タイムスタンプを使い、収録中に画面へ仮の字幕を出したいならライブ向けを使う、というように、タイミングで選びます。ライブ向けの詳しい動作は後の章で扱い、リアルタイムの会話エージェントとしての使い方はLive APIの対応モデルとセッション制限をまとめた記事に分けてあります。
基本の使い方：音声ファイルをアップロードして文字起こしする
基本の使い方とは、Files APIで音声ファイルをアップロードし、そのファイルを gemini-3.5-transcribe に渡して、返ってきたテキストを受け取る流れのことです。
公式ガイドの最初の例は、Pythonで、ファイルをアップロードしてからモデルに渡す形です（Audio transcriptionガイド（generateContent版））。公式にはInteractions APIを使う同内容のガイド（こちら）もあり、そちらでは呼び出し方とパラメータ名が異なります。この記事のコードと設定名は前者に沿っており、要点を読みやすく短くして示します。
from google import genai
client = genai.Client()
audio_file = client.files.upload(file="path/to/sample.mp3")
response = client.models.generate_content(
model="gemini-3.5-transcribe",
contents=[audio_file],
)
print(response.text)ガイドは、文字起こし全体のテキストは response.text で返ると説明しています。ガイドの例では、音声ファイルだけを渡しており、「こう文字にしてほしい」という指示文は渡していません。また、ガイドのベストプラクティスには、数秒より長い録音はFiles APIでアップロードしてから渡すこと、音声は声がはっきり分かれていて極端に音割れしていないものを用意することが挙げられています（ガイド）。
Files APIでのアップロードの仕組みや保存期間は、ファイルを一時的に預けるFile APIの使い方の記事で詳しく扱っています。録音ファイルを繰り返し使うかどうかで、アップロードの扱い方が変わるため、先に目を通しておくと迷いません。
仮の例として、定例会議の録音をmp3で保存したとします。最初の試行では、設定を何も付けずに上のコードをそのまま実行し、文字の出来栄えを確認します。そのうえで、固有名詞の取りこぼしが多ければカスタム語彙、発言者が混ざって読みにくければ話者分離、というように、困りごとに合わせて設定を一つずつ足していきます。最初から全部の設定を盛り込まないのが、原因を切り分けやすい進め方です。公式ページにはRESTの呼び出し例もあり、curlでFiles APIのURIを渡す形で書かれています（ガイド）。
言語の指定と自動検出：language_codesの使い分け
言語の指定とは、audio_transcription_config の language_codes に BCP-47 形式の言語コードを渡して、音声の言語をモデルに伝える設定のことです。
公式ガイドによると、既定では言語を自動で検出し、話者が途中で言語を切り替える場合も動的に追従します。自動検出を使うには language_codes を省略するか、空のリストを渡します。言語が事前に分かっている場合は、language_codes にコードを指定すると精度が上がる、とガイドは説明しています（Audio transcriptionガイド）。日本語のコードは、対応言語の一覧に ja-JP と書かれています（モデルページの対応言語表）。
config = types.GenerateContentConfig(
audio_transcription_config=types.AudioTranscriptionConfig(
language_codes=["ja-JP"],
)
)使い分けの考え方は単純です。録音がすべて日本語だと分かっているなら ja-JP を指定し、日本語と英語が入り混じる会議や、言語が分からない素材には自動検出を任せます。ガイドは、文内の言語切り替えと文をまたぐ切り替えの両方を、手動設定なしで扱えると書いています（ガイド）。ただし、自動検出で日本語の固有名詞や専門用語がどの程度正しく拾われるかは、公式ページに数値や例がありません。この記事では精度を断定せず、自分の素材で試して確かめる前提にします。
仮の例として、海外拠点とのオンライン会議の録音を考えます。大半は日本語で、ところどころ英語の製品名が混ざります。この場合は、言語コードを固定してしまうより、まず自動検出で試し、混在部分の出来を見たうえで、必要なら語彙の指定を足す、という順序が安全です。逆に、すべて日本語の講演録音で、自動検出が別の言語に引っ張られる様子が見られたなら、ja-JP を指定して比較します。同じ録音を二通りの設定で処理して見比べるのが、いちばん確かな判断材料になります。
カスタム語彙：固有名詞や専門用語を拾いやすくする
カスタム語彙とは、audio_transcription_config の custom_vocabulary に用語のリストを渡し、専門用語、略語、固有名詞を認識しやすくする設定のことです。
公式ガイドは、カスタム語彙に最大1,000語まで渡せるとしたうえで、最良の結果は通常100語程度までで得られると書いています。さらに、日常的な一般語ではなく、特有の専門用語、ブランド名、固有名詞だけを入れるよう勧めています（Audio transcriptionガイド）。ガイドの例では、custom_vocabulary に Gemini、Kubernetes、BigQuery の三つの語を渡しています。
config = types.GenerateContentConfig(
audio_transcription_config=types.AudioTranscriptionConfig(
custom_vocabulary=["Gemini", "Kubernetes", "BigQuery"],
)
)最も大事な制約は、カスタム語彙を話者分離や単語タイムスタンプと一緒に使えないことです。ガイドの注意書きには、これらを同時に指定したリクエストはAPIに拒否されると書かれています（ガイド）。この制約があるため、先ほどの仮の例のように「固有名詞を正しく拾いたい」と「誰の発言か残したい」を同時に満たす設定は、一回の呼び出しでは組めません。
仮の例として、社内の新サービスの呼び名が「アオバ」「ミドリ連携」だとします。これらは一般の辞書に載っていないため、カスタム語彙に入れる候補です。一方で、「会議」「資料」「確認」のような日常語は入れません。語彙を絞る理由は、ガイドが一般語を避けるよう勧めていること、そして多すぎるリストは効果が出にくいと読めることです。リストは、前回の出力で間違えた語を拾い集めて育てていくと、無駄がありません。
話者分離：誰が話したかのラベルを付ける
話者分離とは、録音の中の異なる声を見分け、発言の区間ごとに spk_1 や spk_2 のような話者ラベルを付ける機能で、公式ガイドでは diarization を True にして有効にします。
公式ガイドは、話者分離が最大8人までの話者に対応し、3人以上の話者の割り当ては実験的だと明記しています（Audio transcriptionガイド）。モデルページの比較表にも「Attribution for 3+ speakers is experimental」と同じ趣旨が書かれています（モデルページ）。つまり、二人の対談は安定した使い方として想定されていても、三人以上の会議では、結果をそのまま確定情報にせず、人の目で確認する前提で扱うのが筋です。
config = types.GenerateContentConfig(
audio_transcription_config=types.AudioTranscriptionConfig(
diarization=True,
)
)ラベルは spk_1 のような識別子であり、実名ではありません。ガイドが示す出力例でも、speakerLabel に spk_1 と入る形です。誰が spk_1 なのかは、録音を聞いた人が後から対応づける作業になります。また、話者分離を有効にすると、音声の処理は30分までに制限されます。ガイドの制限事項には、話者分離や単語タイムスタンプを有効にした場合は30分までと書かれています（ガイド）。さらに、話者分離はVERBATIMモード（既定）で使う必要があります。
仮の例として、二人の対談の録音を文字起こしします。話者分離を有効にしたうえで、出力の spk_1 と spk_2 を、録音を聞いて「司会」「ゲスト」と手作業で置き換えます。長い対談で収録が長時間に及ぶ場合は、公式の上限に合わせて録音を区切ってから処理する必要があります。区切る位置を話題の切れ目にしておけば、ラベルの対応づけも区切りごとにやり直しやすくなります。
単語タイムスタンプ：字幕や頭出しに使う
単語タイムスタンプとは、認識した各単語に開始位置と終了位置の時間を付ける機能で、公式ガイドでは word_timestamp を True にして有効にし、字幕や該当箇所への頭出しの材料にできます。
公式ガイドの出力例では、各単語が word、startOffset、endOffset を持ち、たとえば「0.100s」から「0.450s」のように秒で表されています（Audio transcriptionガイド）。話者分離と単語タイムスタンプは同時に指定でき、その場合は話者ラベルと時間の両方が返ります。ガイドには、両方を同時に有効にする設定の例も載っています。
注意点として、ガイドは「Enabling word-level timestamps may degrade overall transcription accuracy」、つまり単語タイムスタンプを有効にすると全体の文字起こしの精度が下がる場合があると注意しています（ガイド）。時間情報が不要な用途では、有効にしない方が文字の質を保てる可能性があります。必要なときだけ付ける、という使い方が公式の注意に沿います。タイムスタンプを付けた場合も処理は30分までに制限され、カスタム語彙とは同時に使えません。
仮の例として、動画の字幕を作る場合を考えます。字幕には時間が必須なので、単語タイムスタンプを有効にします。その代わり、固有名詞の補正にカスタム語彙は使えません。そこで、出力された文字の中の固有名詞の誤りは、後から置換表で直す、という工程を設計します。時間情報を取るか、語彙の補正を取るかは二者択一になるため、どちらを優先するかを先に決めておくと、作業の手戻りが減ります。
Smart transcriptionとVERBATIM：読みやすさか忠実さか、同時に使えない組み合わせ
Smart transcriptionとは、mode に SMART を指定して、言いよどみの除去、言い直しの解決、箇条書きや数字の整形などを自動で行い、読むための文章に整える文字起こしの方式です。
公式ガイドによると、mode には VERBATIM（既定）と SMART の二つがあります。VERBATIMは、話された言葉をそのまま、フィラーや言い直しも含めて忠実に返す方式で、タイムスタンプや話者分離を使うときに必要です。SMARTは、言いよどみやどもり、言い間違いの開始部分を取り除き、言い直しをその場で解決し、段落や番号付きリスト、日付、金額、数字などを整えます（Audio transcriptionガイド）。ガイドの英語の例では、「Let’s meet on Tuesday, actually no, Wednesday at two」が「Let’s meet on Wednesday at 2:00 PM」に変わるとされています。
config = types.GenerateContentConfig(
audio_transcription_config=types.AudioTranscriptionConfig(
mode="SMART",
)
)ここで見落としたくないのは、SMARTは単語タイムスタンプや話者分離と同時に使えないことです。ガイドには、これらが必要ならVERBATIMを使うよう書かれています。また、公式の例はすべて英語で、日本語の音声で同じ整形になるかを示す例はありません。日本語の言い直しや数字の整形がどう扱われるかは、自分の音声で確かめる必要があります。
仮の例として、一人で話す音声メモを文章にしたいとします。話者は一人で、時間情報も不要なので、SMARTが向いています。反対に、複数人の会議を、発言者ごとに正確に残したい場合は、VERBATIMと話者分離の組み合わせになります。読みやすさと忠実さは両立しない場面があり、用途から逆算して選ぶことになります。法務や契約に関わる発言の記録のように、言い直しも含めて残したい場合は、整形を行わないVERBATIMが適しているという考え方もできます。
ここまで見てきた設定は、カスタム語彙、話者分離、単語タイムスタンプ、Smart transcriptionのうち、公式ページがAPIに拒否される、または併用できないと書いている対があります。設定が増えると、どれとどれが同時に使えるのかが分かりにくくなるため、まとめて確認します。
公式ガイドの「Parameter reference」と「Limitations」の記載を、組み合わせごとに整理します。
| 設定の組み合わせ | 公式ガイドの扱い | 代わりの考え方 |
|---|---|---|
| カスタム語彙と話者分離 | 併用不可（APIが拒否） | 語彙の補正は後処理の置換で行う |
| カスタム語彙と単語タイムスタンプ | 併用不可（APIが拒否） | 時間情報を優先するなら語彙指定を外す |
| 話者分離と単語タイムスタンプ | 同時指定が可能 | 両方を一度に取得できる |
| SMARTと話者分離 | 併用不可（VERBATIMを使う） | 整形は後の工程で別に行う |
| SMARTと単語タイムスタンプ | 併用不可（VERBATIMを使う） | 字幕には整形なしの文字を使う |
出典は、公式ガイド（generateContent版）のパラメータ一覧と制限事項、モデルページの機能比較表です（Audio transcriptionガイド、モデルページ）。表の「代わりの考え方」の列は、公式の記載ではなく、この記事の提案です。language_codes と他の設定の併用については、制限事項の一覧に記載が見当たりません。記載がないことを「問題なく併用できる」と読み替えず、実際に試して確認するのが安全です。
仮の例として、仮の設定A「話者分離と単語タイムスタンプ」、設定B「カスタム語彙のみ」、設定C「SMARTのみ」の三通りを考えます。同じ録音に対して、Aは発言者と時間が残る代わりに固有名詞の補正がなく、Bは固有名詞に強い代わりに発言者も時間も残らず、Cは読みやすい代わりに発言者も時間も残りません。三つのどれも、一回の呼び出しで全部を満たすことはできません。必要な情報が複数ある場合は、同じ録音を設定を変えて複数回処理し、結果を組み合わせる運用になります。
長さと音声形式の制限：1時間と30分の線引き
長さの制限とは、1回の呼び出しで処理できる音声の上限のことで、公式ページでは通常は最大1時間、話者分離や単語タイムスタンプを有効にした場合は30分までとされています。
公式のモデルページは、入力として音声を最大1時間、出力としてテキストと単語アノテーションを挙げ、「Unary audio limit」を1リクエストあたり最大1時間、話者分離または単語タイムスタンプを有効にした場合は最大30分としています（モデルページ）。長時間の録音を扱う場合は、機能の組み合わせによって上限が変わる点が重要です。
対応する音声形式は、ガイドのMIMEタイプの一覧に、wav、mp3、aiff、aac、ogg、flac、mpeg、m4a、l16、opus、alaw、mulaw、webmが挙げられています（Audio transcriptionガイド）。一般的なmp3やwav、m4aは含まれています。完全な一覧とパラメータの仕様は、ガイドからInteractions APIのリファレンスに案内されています。録音アプリの保存形式が一覧にあるかどうかを、処理の前に確かめておくと、変換の手間を先に判断できます。
仮の例として、長めの録音を扱う場合を考えます。話者分離を付けるなら、公式の上限の短い方に合わせて録音を話題の切れ目で区切り、区間ごとに処理します。話者ラベルは区間をまたぐと対応が変わる可能性があるため、公式ページに記載はありませんが、区間ごとに対応づけをやり直す前提で設計します。文字だけが目的なら、通常の上限に収まる範囲でまとめて処理できます。上限のどちらを適用するかは、使う設定で決まるため、先に設定を決め、それから録音の区切り方を決めます。
料金の読み方：無料枠と有料枠、分あたりの目安
料金の読み方とは、公式の料金ページにある無料枠（Free Tier）と有料枠（Paid Tier）の表から、音声の入力と文字の出力のそれぞれの単価を確認し、1分あたりの目安に換算して見積もることです。
公式の料金ページ（Gemini Developer API pricing）の「Gemini 3.5 Transcribe」のStandardの表には、2026年10月4日の時点で次の記載があります。Paid Tier（100万トークンあたり、米ドル）の入力は、音声で2.00ドル、または1分あたり0.003ドル、出力は12.00ドル、または1分あたり0.002ドルです。Free Tierは入力も出力も「Free of charge」です。注記には、1秒あたり音声25トークン、1分あたりテキスト175トークンという前提で、実効の合算レートは1分あたり約0.005ドルと書かれています。
| 料金の区分（Standard、米ドル、2026年10月4日取得） | 入力（音声） | 出力（テキスト） | 公式の合算目安 |
|---|---|---|---|
| ファイル向け gemini-3.5-transcribe（Paid Tier） | 100万トークンあたり2.00ドル、または1分あたり0.003ドル | 100万トークンあたり12.00ドル、または1分あたり0.002ドル | 1分あたり約0.005ドル |
| ファイル向け gemini-3.5-transcribe（Free Tier） | Free of charge | Free of charge | 料金は無料（製品改善に使われる行は Yes） |
| ライブ向け gemini-3.5-transcribe-live（Paid Tier） | 100万トークンあたり3.50ドル、または1分あたり0.005ドル | 100万トークンあたり21.00ドル、または1分あたり0.004ドル | 1分あたり約0.009ドル |
仮の例として、音声の長さをかけて見積もる計算を示します。公式の合算目安である1分あたり約0.005ドルを使うと、1時間の録音は60分なので、約0.30ドルという概算になります。数値は一例です。実際の請求は、トークンの消費量、料金ページの改定、適用されるTierによって変わるため、見積もりは目安として扱い、最終的には請求の画面で確認してください。
もう一つ、料金ページの表には「Used to improve our products（製品の改善に使われるか）」の行があり、Free Tierは「Yes」、Paid Tierは「No」と書かれています（料金ページ）。無料枠で社内の会議録音のような機密性のある音声を処理するかどうかは、この行を確認して判断する材料になります。また、料金ページの出力行には「including thinking tokens」と書かれている一方、モデルページではThinkingが「Not supported」とされています。両ページ（料金ページとモデルページ）の記載が揃っていないため、この記事ではThinkingの扱いを断定しません。
ライブ文字起こし：ストリーミングで使う場合の違いと上限
ライブ文字起こしとは、Live APIの gemini-3.5-transcribe-live を使い、WebSocketsで音声を流しながら途中経過と確定結果の文字を受け取る方式で、会話するエージェントではなく文字起こし専用の仕組みです。
公式のライブ文字起こしのガイドは、Live Agent（聞いて考えて声で返す会話アシスタント）とLive Transcription（入ってくる音声を文字にするだけの仕組み）を比較しています。後者の応答形式はテキストのみで、対応する機能として、カスタム語彙、言語検出、手動およびハイブリッドのVAD、Smart transcriptionが挙げられています（Live transcriptionガイド）。入力は生の16ビットPCM音声です。
ライブ版の出力には二種類あります。interim_input_transcription は、話している最中に更新される暫定の文字で、画面の字幕のプレビューに使えます。input_transcription は、話者が間を置いた、またはターンが終わったときに出る確定した文字です（Live transcriptionガイド）。暫定と確定を分けて扱えるため、字幕は暫定を表示し、記録には確定だけを保存する、という設計ができます。
制限として、ガイドはライブのセッションが連続で最大10分であること、話者分離と単語タイムスタンプが使えないこと、SMARTを単語アノテーションと組み合わせられないことを挙げています（Live transcriptionガイド）。話者の区切り方の仕組みとして、ガイドは自動VAD、ハイブリッドVAD、手動VAD（押している間だけ話す方式）の三つを説明しています。
仮の例として、オンラインセミナーの画面に、話している内容の字幕を出したいとします。ライブ版で暫定の文字を表示し、確定した文字だけを後の記録用に保存します。セッションが10分で終わる以上、長いセミナーでは接続を張り直す設計が必要になりますが、張り直したときに文脈や話者の対応がどう引き継がれるかは、公式ページに記載がありません。この点は、実際に動かして確かめる項目として残します。
他の機能との使い分けと、出力を確かめる手順
使い分けとは、文字起こし、ライブ文字起こし、音声理解、音声合成のどれが目的に合うかを選ぶことで、出力を確かめる手順とは、返ってきた文字を元の音声と突き合わせて誤りを見つける作業のことです。
公式ガイドは、文字起こしと音声理解と音声合成を別の用途として案内しています（Audio transcriptionガイド）。音声理解については、公式の音声理解ページ（Audio understanding）が別にあります。目的ごとの選び方を、表に整理します。
| やりたいこと | 向いている機能 | 公式ガイドでの位置づけ |
|---|---|---|
| 録音済みの音声を文字にする | gemini-3.5-transcribe | 音声ファイルの音声認識 |
| 流れてくる音声をその場で字幕にする | gemini-3.5-transcribe-live | WebSocketsによる低遅延の音声認識 |
| 音声の内容について質問する、推論させる | Audio understanding | 音声についての汎用的な推論や質問応答 |
| 文章から音声を作る | Text-to-speech | テキストからの音声合成 |
出力の確かめ方は、機械の出力を一次情報にしない、という姿勢が基本です。公式ページに、文字起こしの誤り率や、固有名詞、数字、日本語での精度を示す数値はありません。そのため、重要な用途では次の観点で人が確認します。固有名詞と数字が元の音声と合っているか、話者ラベルが入れ替わっていないか、言い直しの整形が意味を変えていないか、区切りの位置で文が欠けていないか、です。話者ラベルと整形は、特に誤りが意味を変えやすい部分です。
仮の例として、議事録に使う文字起こしを確認します。まず、決定事項と数字が出てくる箇所だけを、元の音声を聞いて突き合わせます。次に、話者ラベルを実名に置き換え、置き換えた後の文を読んで不自然な箇所がないかを見ます。その後に、議事録の体裁への整形を、別のテキスト処理に任せます。整形の結果を機械で扱いやすい形にする方法は、出力の形をスキーマで指定する構造化出力の記事で扱っています。最終的な公開や共有の前に、人が一度読む工程を残すことが、誤りの流出を防ぐ最後の関門になります。
よくある質問（FAQ）
- Q1. Gemini 3.5 Transcribeは日本語に対応していますか。
- 公式のモデルページの対応言語の表に、日本語が ja-JP のコードで載っています。日本語の認識精度を示す数値は公式ページにないため、自分の音声で確かめてください。出典：Gemini 3.5 Transcribe。
- Q2. 無料で使えますか。
- 公式の料金ページのStandardの表で、Free Tierの入力と出力は「Free of charge」と書かれています。ただし同じ表で、Free Tierは製品の改善に使われる行が「Yes」です。2026年10月4日時点の記載のため、利用前に現在の料金ページを確認してください。出典：料金ページ。
- Q3. 1回に処理できる録音の長さはどれくらいですか。
- 公式のモデルページでは、通常は1リクエストあたり最大1時間、話者分離または単語タイムスタンプを有効にした場合は最大30分とされています。出典：モデルページ。
- Q4. 話者の名前まで自動で特定できますか。
- 公式ガイドでは、話者分離は発言の区間に spk_1 や spk_2 のような識別子を付ける機能と説明されています。実名への対応づけは、録音を聞いた人が行う作業になります。出典：Audio transcriptionガイド。
- Q5. 固有名詞の補正と話者分離を同時に使えますか。
- 使えません。公式ガイドには、カスタム語彙を話者分離や単語タイムスタンプと併用したリクエストはAPIに拒否されると書かれています。語彙の補正は後処理で行うなど、工程を分けて考えます。出典：Audio transcriptionガイド。
- Q6. バッチ処理で大量の録音をまとめて安く処理できますか。
- 公式のモデルページでは、Batch API、Flex inference、Priority inferenceはいずれも「Not supported」とされています。大量処理の設計では、この対象外の扱いを前提にしてください。出典：モデルページ。
- Q7. 文字起こしの結果を要約することもできますか。
- 公式ガイドは、音声の内容についての推論や質問応答にはAudio understandingを使うよう案内しています。文字起こしの結果を別のテキスト処理に渡して要約する、という二段構えも設計できます。出典：Audio transcriptionガイド。
まとめ：目的を先に決め、組み合わせの制約を踏まえて設定を選ぶ
Gemini 3.5 Transcribeは、Gemini APIで音声を文字にする専用モデルで、録音済みのファイル向けとライブ向けの二つのエンドポイントがあります。使いこなしの要点は、設定を足す前に目的を決めることです。発言者を残したいなら話者分離、時間情報が要るなら単語タイムスタンプ、固有名詞を拾いたいならカスタム語彙、読みやすさならSMART、と目的ごとに選び、同時に使えない組み合わせを表で先に確かめます。
長さの上限は、公式のモデルページによると、通常は最大1時間で、話者分離やタイムスタンプを使う場合はこれより短い上限になります。料金は、2026年10月4日時点の公式の料金ページで、Paid Tierのファイル向けが1分あたり約0.005ドルの合算目安と書かれています。Free Tierについては、製品の改善に使われる行も利用前に見ておきましょう。精度を示す数値は公式ページにないため、重要な用途では元の音声との突き合わせを残してください。
次の一歩は、手元の短い録音を一つ選び、設定なしで文字にして、困りごとを一つ見つけることです。その困りごとに合う設定だけを足し、結果を比べます。Google AIの機能を幅広く試したい場合は、Google AIの使い方の全体像をまとめた入門記事から、関心のある機能に進むのも一つの方法です。
あわせて読みたい・姉妹メディア
