インタビューの音声を文字起こしAIへ入れる。数分後、読みやすい文章が返ってくる。作業が速くなったように見えるが、最初に確かめるべきなのは誤字の数だけではない。話し手の「えー」「その」、途中で止めた言葉、言い直し、自己修正が残っているかである。
取材では、フィラーを残す`verbatim`を原本にし、読みやすくする作業は複製した編集コピーで行うのが安全である。 最初から`clean`だけを保存すると、何をAIが整え、何を話し手が実際に言ったのかを後から分けにくい。
この違いが見える新しい例が、Microsoftが2026年9月3日にドキュメントを更新した「MAI-Transcribe-2」だ。文字起こしの出力を`verbatim`と`clean`から選べる。これは単なる文章の好みではなく、取材記録をどこまで保存するかという編集設計の選択である。
MAI-Transcribe-2は、認識と「整え方」を別の設定にした
Microsoft Learnの公式ドキュメントによると、MAI-Transcribe-2は60言語に対応し、日本語も対象に含む。話者を分けるダイアライゼーション、単語単位のタイムスタンプ、言語の自動判定、会話途中で言語が切り替わるコードスイッチング、雑音や重なった発話への対応、固有名詞を認識しやすくするキーワードバイアスを備える。
ただし、現在はパブリックプレビューである。Microsoft自身がサービスレベル合意なしで提供され、本番ワークロードには推奨しないと明記している。機能があることと、重要な取材フローをすぐ全面移行できることは同じではない。まず既存の録音から代表的な数本を選び、日本語、複数話者、雑音、固有名詞ごとに試す段階だ。
注目されやすい平均精度や料金についても、確認の線を引きたい。公開ドキュメントには日本語単体の誤り率や、取材音声に限定したベンチマークは載っていない。本稿では二次情報で流通する単語誤り率や1音声時間あたりの価格を採用しなかった。多言語の平均値が良くても、自社名と話者名を取り違えれば、編集の戻し工数は減らないからである。
戻し工数を決めるのは、固有名詞と話者の境界である
企業取材で頻繁に直すのは、一般語より社名、製品名、人名、業界固有の略語である。MAI-Transcribe-2の`phraseList.phrases`には、こうした語を配列で事前に渡せる。公式説明は、入力した語を必ず出す命令ではなく、認識をそちらへ寄せるヒントだとしている。誤認識をゼロにする仕組みではないが、取材前に用語表をつくる作業が、そのまま文字起こしの品質管理になる。
- 会社と組織：正式社名、部署名、ブランド名、買収前後で変わった名称
- 人：登壇者、取材者、経営者、研究者の氏名と読み方
- 製品と技術：製品名、型番、API名、英字の略語、社内でだけ使う呼称
- 数字の周辺語：年度、プラン名、指標名。数値そのものだけでなく何の数字かを渡す
話者分離も同じくらい重要だ。誰の言葉かがずれると、内容が正しくても引用できない。もっとも、ダイアライゼーションが返すのは話者ラベルであり、人物の身元を保証する機能ではない。冒頭で名乗る箇所や映像、取材メモと照合し、Speaker 1を自動的に特定人物へ置き換えない。単語タイムスタンプは、その確認地点へ音声を戻す索引として使う。
つまり、AIに渡す用語表、話者表、録音ファイルの三つをセットで管理すると、精度を抽象的な点数ではなく、直す箇所まで戻れる運用へ変えられる。AI企業が編集者を必要とする理由も、出力をうまく書き直す能力だけではない。何を根拠として残し、どこで人が確かめるかを決める役割にある。
cleanは完成原稿ではなく、目的の違う出力である
`transcribeStyle`の既定値は`verbatim`である。公式説明では、`verbatim`はフィラー、言いかけ、自己修正を含む発話をそのまま捉える。`clean`はフィラーを取り除き、一般的な話し言葉のパターンを自動で整え、字幕、メモ、公開用文字起こしを読みやすくする設定だ。
ここで注意したいのは、`clean`が何をどう変えるかを公式文書が一語ずつ列挙しているわけではない点である。自己修正を必ず削るとも、意味を必ず保つとも書かれていない。したがって「cleanなら校正済み」と扱うことはできない。自分たちの音声で両方を出し、どの表現が変わるかを先に比較する必要がある。
取材では、言い直し自体が情報になる。日付を言った直後に訂正した、断定しかけて表現を弱めた、主語を会社から個人へ変えた。最終原稿では前半を削るとしても、編集者は変更の跡を見て、確認が必要な発言だと判断できる。クライアント校正で「実際の発言と違う」と指摘されたときも、原本があれば音声へ戻れる。
実務では、録音を一次記録、`verbatim`を検索できる原本、整えた文章を編集コピーとする。編集コピーではフィラーの削除、表記統一、文の接続を行うが、重要な引用には音声の時刻を残す。原本を上書きしなければ、読みやすさと忠実性を二者択一にしなくてよい。
この分業は、AIでライターの仕事がどう変わるかを考えるうえでも重要だ。文字列を得る作業は速くなる。一方、何を残すべき発言とみなし、どの変更を話し手へ確認し、公開文としてどこまで整えるかは、出力速度からは決まらない。
導入時は、モデルが替わる前提で記録を残す
音声認識を業務フローへ固定すると、モデルの更新が次の問題になる。MAI-Transcribe-1は2026年8月20日に非推奨となった。Speech to Text REST APIも、2025-10-15版でリクエスト構造やフレーズリストの扱いが更新されている。新モデルへの移行は例外ではなく、運用の一部として予算と時間を置くべきである。
- 音声を残す：文字起こしだけでなく、権限を管理した元音声を保持する
- 条件を残す：モデル名、API版、`transcribeStyle`、言語、phraseList、話者設定を記録する
- 定点音声を持つ：雑音、複数話者、専門語を含むサンプルで、新旧モデルを同じ条件で比べる
- 差分を人が見る：文字誤り率だけでなく、話者、固有名詞、否定、数字、自己修正の変化を確認する
- 切り戻せるようにする：プレビュー障害や仕様変更時に、別モデルまたは従来工程へ戻せるようにする
制作会社へ文字起こしを発注するときも、「AIを使うか」だけでは違いが見えない。どのモデルか、フィラーを残す設定か、用語表を渡すか、話者をどう確定するか、音声と原本をいつまで保持するかを聞く。回答に工程があれば、原稿の忠実性を偶然ではなく設計していると分かる。
文字起こしAIの価値は、きれいな文章を一度で返すことだけではない。実発言を失わず、編集者が速く探し、必要な箇所へ戻れることにある。取材なら、まず`verbatim`。整えるのは、その後の編集工程で行う。
Sources / 参考資料