文字起こしの整形はもう不要か｜消えた工程と残る工程

「録音は取れているのに、文字起こしを開くと結局そのままでは使えない」——打ち合わせのあと、この徒労を味わったことのある方は多いはずです。

結論から言うと、2026年8月26日に発表されたGoogleの「Gemini 3.5 Transcribe」によって、音声を「読める文章」にする工程は認識モデルの側へ取り込まれました。ただし「使える成果物」に整える工程は消えていません。この2つを混ぜて考えているかぎり、何が楽になったのかを見誤ります。

株式会社Fyveは、打ち合わせやセミナーの録画をローカル環境で文字起こしする運用を日常業務として回しています。本記事では、その実運用を土台に「どの工程が消えて、どの工程が残るのか」を切り分けます。

結論：消えたのは「読める化」、残るのは「使える化」

文字起こしの作業は、ひとかたまりに見えて実際には3つの段に分かれています。今回動いたのは、そのうち真ん中の1段だけです。

多くの人が「文字起こしが面倒だ」と言うとき、その面倒さの正体は段1ではなく段1.5と段2の合計でした。段1はとっくに自動化されていて、そこは誰も苦労していなかったからです。

今回はそのうち段1.5が消えました。残った段2をどう設計するかが、そのまま成果物の質の差になります。

何が発表されたのか（2026年8月26日・公式発表の範囲）

まず事実を確定させておきます。Googleは2026年8月26日、音声認識モデル「Gemini 3.5 Transcribe」を公開しました。公式ブログで明示されている内容は次のとおりです。

数字の読み方に注意したい3点

この手のニュースは、数字がひとり歩きしやすいところが厄介です。公式発表を読むかぎり、次の3点は押さえておく必要があります。

ひとつめ。WERの4.0%・2.6%は平均値です。同じ発表内で参照されているFLEURSベンチマークでの数値は逐次5.50%・一括5.04%と、平均値より高く出ています。どの音声でも4.0%になるという意味ではありません。

ふたつめ。日本語単体の精度は公表されていません。85言語以上を自動判別するという記述はありますが、言語ごとの内訳は出ていません。日本語の打ち合わせで使えるかどうかは、自社の音声で測る以外にありません。

みっつめ。「70%」は作業時間の話ではありません。最終的な文字起こしが確定するまでの時間が前世代モデル比で改善したという速度の指標であって、あなたの議事録づくりが70%短くなるという意味ではありません。ここを取り違えると、導入後に「思ったほど楽になっていない」という感想になります。

日本語で今日触れられる範囲は、まだ限定的

提供形態も正確に見ておきます。2026年8月時点で公開されているのはパブリックプレビューで、触れる場所は次のとおりです。

• Gemini API（Google AI Studio 経由）および Google Antigravity
• Gemini Enterprise Agent Platform
• macOS版 Gemini アプリ（英語）
• Android の Rambler（一部の国・言語）
• Chrome への搭載は「近日」

つまり、日本語の打ち合わせを今日から丸ごと置き換えられる状態ではありません。日本語で試すなら、現時点では AI Studio から自社の音声を投げてみるのが実質的な入口になります。なお価格については、公式発表に記載がありません（2026年8月27日時点）。

これまでの文字起こしは「2段構え」だった

私の運用を具体例として出します。ここが本記事の視点の土台です。

私は打ち合わせやセミナーの録画を、クラウドに上げずに手元のMacで文字起こししています。エンジンは whisper.cpp で、M系MacのMetalによる高速化を効かせています。処理時間の実測はおおよそ次のとおりです。

音声はいったん ffmpeg で16kHzのモノラルに変換してから渡します。副産物として字幕形式（srt）のファイルも出るので、あとから「あの発言どこだったか」を時刻で頭出しできます。

ここまでが段1です。速いですし、コストもかかりません。問題はこの先でした。

出てきたテキストは、そのままでは読めない

whisper系のモデルが吐き出す素の文字起こしは、こういう状態です。句読点が薄く、言い直しがそのまま残り、「えーと」が全部入っていて、段落の区切りがありません。1時間の打ち合わせだと、改行のない文字の壁が出てきます。

だから私は、この素のテキストをAIに渡して「読める文章」に直してから、ようやく中身の話に入っていました。これが段1.5です。ひと手間ではありますが、毎回必ず発生する固定費でした。

Gemini 3.5 Transcribe が消したのは、まさにこの固定費です。フィラー除去・自動整形・言い直しの解釈という発表内容は、そのまま段1.5の作業項目と一致します。

整形と構造化は、似ているようで別の作業

ではなぜ、段1.5はモデルに載せられて、段2は載らなかったのでしょうか。ここが本記事でいちばん伝えたい部分です。

整形は「正解が1つに決まる」作業

「明日、いや明後日で」を「明後日で」に直す作業に、判断の余地はほとんどありません。誰がやっても同じ結果になりますし、その文字起こしを何に使うつもりなのかを聞かなくても決められます。

目的を知らなくても正解が決まる作業——これが整形です。だからモデルの中に閉じ込められました。

構造化は「目的が決まらないと決まらない」作業

一方で段2はそうはいきません。同じ音声でも、必要な成果物は目的によって別物になります。

• 打ち合わせなら、決定事項・未解決の持ち帰り・担当と期限のアクション表
• レクチャーなら、要点の整理・新しく学んだこと・実践したいこと
• インタビューなら、Q&Aの対応づけとハイライト

私は目的別のテンプレートを5種類（打ち合わせ／レクチャー／インタビュー／個別セッション／汎用）用意して使い分けています。同じ文字起こしを別の目的のテンプレートに流し直したこともありますが、そのとき起きたことははっきりしていました。転写のテキストは1文字も変わらないのに、出てくる成果物は完全な別物になったのです。

これは、構造化が音声ではなく目的の下流にあることの証拠です。音声の中に「決定事項」というラベルは録音されていません。何を決定事項と呼ぶかを決めているのは、聞いた側の目的です。

だから境目はここに引かれた

整形は音声だけを見れば答えが出るので、音声認識モデルの内側に入りました。構造化は音声の外側にある目的を必要とするので、外側に残りました。この線引きは、次のモデルが出ても動きにくい種類の線です。

工程が1つ消えると、設計のどこが変わるか

ここからは実務の話です。段1.5が消えると、周辺の設計に3つの変化が起きます。

変化①：中間ファイルを抱えておく理由が減る

これまでは「素の転写」と「整えた転写」の2つを持っていました。前者は読めないけれど原本で、後者は読めるけれど加工済み。あとで疑義が出たときに原本を参照するため、両方を残す必要がありました。

段1.5がモデル側に入ると、この2本立てを持つ理由が薄くなります。保管するファイルが減るのは、地味ですが運用としては効きます。

変化②：品質の見張り所が「読みにくさ」から「抜け」へ移る

これは注意点のほうです。整形が上手くなるほど、消えたものが見えなくなります。

読みにくい文字起こしは、目で見て「これは変だ」と気づけます。ところが整った文章から1文が抜け落ちていても、読み手には気づけません。文章として自然に流れてしまうからです。

固有名詞についても同じことが言えます。今回のモデルに語彙登録の機能が用意されているということは、裏を返せば既定のままでは独自の用語は外れうるということです。社名・製品名・人名は、これまでどおり突き合わせる前提で組んだほうが安全です。

つまり、見張るべき対象が「読みにくさ」から「抜けと取り違え」へ移動します。チェックの手間がゼロになったわけではなく、置き場所が変わったと捉えるのが正確です。

変化③：消えた工程の代わりに、事前の準備が増える

ここは見落とされやすいところです。段1.5が消えるかわりに、新しく増える作業があります。語彙登録です。

これまで固有名詞の誤変換は、出てきた文字起こしを見てから直していました。事後の作業です。ところが語彙登録という機能は、渡す前に用語のリストを用意しておくことを求めます。事前の作業です。

つまり正確には「作業が消えた」のではなく、作業が事後から事前へ移ったと言うべきです。そしてこの移動には、はっきりした損得があります。

• 事後の修正は、毎回かかる。10回やれば10回分
• 事前の準備は、一度作れば使い回せる。10回やっても1回分

したがって、文字起こしの回数が少ない人にとっては手間が増えたようにすら見えます。逆に毎週のように回している人ほど、この移動は効きます。自社がどちらなのかで、着手する優先度は変わります。

そして気づくのは、これが段2のテンプレート設計とまったく同じ構造だということです。先に型を作っておくことで、毎回の判断を消す。私が目的別テンプレートを5種類持っているのも、語彙リストを先に用意するのも、投資の形としては同じものです。ツールが変わっても、この形の投資だけは手元に残ります。

変わらないこと：出力の型は自分で決める

そして段2は残ります。決定事項をどう定義するか、誰の宿題として書くか、どのフォーマットで残すか。ここはモデルの性能ではなく、自社の仕事の進め方の問題です。

議事録づくりそのものの組み立て方については、別の記事で実践ワークフローを整理しています。

AI業務効率化議事録をAIで自動作成する方法｜録音→資料化の実践ワークフロー

整形されたテキストは、もう「逐語録」ではない

もうひとつ、整形が自動化されたことで生まれる論点があります。整えられた文字起こしは、発言そのままの記録ではなくなるということです。

「明日、いや明後日で」が「明後日で」になるのは、便利であると同時に解釈が入っているということでもあります。フィラーを落とし、言い直しをたたみ、段落を切る。どれも読みやすさのための操作ですが、操作である以上、元の発話と一対一で対応するとは限りません。

普段の打ち合わせなら、これで何の問題もありません。問題になるのは、記録が証拠として使われる場面です。

• 取引先とのトラブルで「言った・言わない」を確認するとき
• 契約条件の詰めで、どちらがどう発言したかが効いてくるとき
• 労務や苦情の対応で、経緯を正確に残す必要があるとき

こうした場面では、整形済みのテキストを議事録に引用として貼るのは避けたほうがよいと考えています。読みやすく整った文章は、それらしく見えるぶん、実際には言っていない形に整っている可能性を隠します。

実務的な対処はそれほど難しくありません。録音の原本を消さないこと、そして時刻で原本に戻れる状態を保つこと。この2つだけです。私が字幕形式のファイルを残しているのは、要約のためというより、この戻り道のためという面が大きい。

整形が自動化されるほど、原本の価値は上がります。工程が消えたときに手放してよいのは中間生成物であって、原本ではありません。

それでも、どこで処理するかは中身で決める

精度と速度の話をしてきましたが、置き場所の判断はそれとは別の軸で決めるべきです。

打ち合わせの録音には、こちらの都合だけでなく相手の事情が入っています。まだ公になっていない計画、社内の人間関係、うまくいっていない案件の話。便利さだけで置き場所を決めると、あとから戻せません。

手元で完結する選択肢が実在することは知っておいて損はありません。私が whisper.cpp をローカルで回しているのは、速いからというより、この理由が大きいです。

ただし「ローカルが正義」という話ではありません。85言語の自動判別や複数話者の割り当てが必要な場面では、クラウド側のモデルのほうが明確に強い。判断軸は次の3つで十分です。

• 誰の声が入っているか（自分だけか、相手がいるか）
• 何が話題として写り込んでいるか（公開できない情報が含まれるか）
• あとで参照し続けるものか、その場限りか

速さで選ばず、中身で決める。この順番だけ守れば、あとはツールの好みの問題です。

業務パターン別・どう組むのが現実的か

ここまでの整理を、実際の使用場面に落とします。どのパターンかで、必要になる機能も置き場所も変わります。

「最大3人」の線は、実務ではけっこう効く

話者を最大3人までタイムスタンプ付きで割り当てる、という仕様は、一見すると十分そうに見えます。ただ実際の打ち合わせは2〜4人であることが多く、この3という数字はちょうど実務の境目に引かれています。自社と先方が2名ずつ出れば、それだけで4人です。

4人以上になる会議では、話者ラベルを前提にした設計にしないほうが安全です。私は代わりに、字幕形式（srt）で出るタイムスタンプを使って、あとから時刻で追える状態にしています。誰が言ったかをモデルに当てさせるのではなく、必要になったときに録音へ戻れる導線を残しておくほうが壊れにくい。

これも先ほどの「見張り所が移る」話と同じ発想です。自動で付いたラベルは、間違っていても自然に見えてしまいます。人数が増えるほど、当てにしない設計に倒したほうが結果的に早く済みます。

今から手をつけるなら、この4ステップ

最後に、実際に手を動かす順番を書いておきます。

ステップ1：今の工程を3段に分けて書き出す。自分の作業が段1・段1.5・段2のどこに何分かかっているかを、いちど紙に出します。ここを分けずに「文字起こしが面倒」と括っているうちは、何を改善したのか判定できません。

ステップ2：段1.5に使っている時間を測る。ここが今回のニュースで消える可能性のある部分です。測ってみると、思ったより小さいこともあれば、毎回15分かかっていたと分かることもあります。

ステップ3：自社の実音声で短く試す。ベンチマークの数値ではなく、自分たちの会議室の音、自分たちの専門用語で試します。AI Studio から短い音声を1本投げるところからで十分です。

ステップ4：段2のテンプレートを先に作る。ここが本体です。文字起こしの精度がどれだけ上がっても、出力の型がなければ成果物は出てきません。逆に型さえあれば、段1のエンジンは後から差し替えられます。

Claude Code を使って動画から要約までを一本の流れにする具体的な手順は、こちらで解説しています。

Claude CodeClaude Codeで会議・セミナー動画を文字起こし要約

よくある質問

Q. Gemini 3.5 Transcribe は日本語の精度が上がったのですか

公式発表では85言語以上の自動判別と、平均WER（逐次4.0%・一括2.6%）が示されていますが、日本語単体の数値は公表されていません。日本語での実用性は、自社の音声で確かめる必要があります。

Q. 料金はいくらですか

2026年8月27日時点で、公式発表に価格の記載はありません。パブリックプレビューとして Gemini API（AI Studio 経由）などで提供されています。

Q. 4人以上の会議では話者を区別できますか

公式に明記されているのは、録音済み音声でタイムスタンプ付き最大3人までです。それを超える人数への対応は実験的な扱いとされています。参加者の多い会議では、話者の区別を前提にした設計にしないほうが無難です。

Q. すでに whisper で回しているのですが、乗り換えるべきですか

まず段1.5に何分かけているかを測ってください。そこが小さいなら、乗り換えの効果も小さいはずです。いずれにしても消えるのは段1.5であって、段2のテンプレート設計はそのまま残ります。

Q. ローカルとクラウドで、コストはどう変わりますか

比べる対象を間違えないことが大事です。手元で動かす場合、実行にかかる費用はほぼ電気代だけですが、そのぶんマシンの性能に依存します。クラウドは従量課金になります。

ただし、これまで段1.5（読める化）を別のAIに投げていたなら、そのぶんの費用は消えます。したがって比較すべきは段1の料金単体ではなく、段1と段1.5の合計です。ここを分けずに「APIは高い」と判断すると、実態とずれます。

Q. 整形された文字起こしを、そのまま議事録に引用してよいですか

普段の打ち合わせであれば問題ありません。ただし「言った・言わない」が後で効いてくる可能性のある場では、整形済みテキストは逐語の記録ではない点に注意してください。録音の原本を残し、時刻で戻れるようにしておくのが安全です。

Q. 音声入力ツールそのものを選び直したいのですが

用途が「会議の記録」ではなく「日々の入力」なら、選ぶ軸が変わります。主要ツールの比較はこちらにまとめています。

AI業務効率化音声入力AI比較 Typeless vs Aqua Voice vs Superwhisper｜評判・精度・料金で選ぶ完全ガイド【2026年版】

まとめ

Gemini 3.5 Transcribe の登場で起きたことを、もう一度整理します。

• 消えたのは段1.5＝読める化（句読点・段落・フィラー除去・言い直しの解釈）
• 残るのは段2＝使える化（目的別の型に流し込む作業）
• 両者を分ける基準は「目的を知らなくても正解が決まるか」
• 整形が上手くなるぶん、見張るべき対象は「読みにくさ」から「抜け」へ移る
• 置き場所は速さではなく、録音の中身で決める

ニュースとしては「精度が上がった」という一行で流れていく発表です。ただ実務の側から見ると、動いたのは精度ではなく工程の境目でした。境目が動いたときにやるべきことは、新しいツールを買うことではなく、自分の工程のどこが空いたかを確かめることです。

私たちは、こうした「AIで何が変わって、何が変わらないのか」の切り分けを、中小企業の現場に合わせて一緒に整理する伴走を行っています。自社の業務のどこから手をつけるべきか迷っている場合は、専属AI活用顧問サービスもご覧ください。