音声認識（ASR: Automatic Speech Recognition、話し言葉をテキストに変換する技術）を使った文字起こし機能を、会議録や問い合わせ履歴の自動化に組み込もうとしているSREやインフラ担当者に向けた内容です。OpenAI Whisperをはじめとする音声認識モデルは、デモでは驚くほど流暢な出力を返します。しかし本番環境でそのまま採用すると、可用性設計の観点で見落としがちな落とし穴があります。この記事では、その落とし穴の構造と、SLO（Service Level Objective: サービスが満たすべき品質の目標値）として文字起こし精度をどう扱うかを整理します。
何が起きるか
文字起こしパイプラインを本番投入したあとに起きる典型的な事象は、「出力が流暢だから正しく見える」という状態です。
文法的に破綻していない文章は、読み手に「正確だ」という錯覚を与えます。
たとえば「プロジェクトの締切は金曜日です」という出力が、実際の音声では「木曜日」だった場合でも、文章としては何の違和感もありません。
この種の誤りは、支払い指示の金額、医薬品名、口座番号、否定表現（「対応しない」を「対応する」と誤変換するなど）で起きると、業務影響が一気に大きくなります。
影響範囲はテキストの誤りだけに留まりません。
文字起こし結果を下流のワークフロー（チケット自動起票、要約生成、検索インデックス投入など）に接続している場合、誤った claim（主張・事実の単位）がそのまま伝播します。
誤りの発生箇所が音声・モデル・後処理のどこにあるか分からなくなり、障害発生時の原因切り分けに時間がかかる、という二次被害につながります。
なぜ起きるか
原因は大きく3段階に分解できます。
第一に、精度評価の単位が間違っています。
多くのチームはWER（Word Error Rate: 単語誤り率。正解テキストと比較して何語間違えたかを示す指標）だけを品質指標にしますが、WERはビジネス上の深刻度を表しません。
句読点の誤りが20箇所あるケースより、金額の桁が1箇所ズレるケースの方が、実害は大きくなります。
第二に、音声・テキスト・話者情報・不確実性スコア・人間による修正履歴がバラバラに保存されています。
これらが1つのトレース（処理の一連の記録）として紐づいていないと、誤りが見つかっても「どの音声のどの区間が原因か」を追跡できません。
第三に、ローカル実行かAPI利用かという選択を、「プライバシー対コスト」のような曖昧なスローガンで決めてしまっていることです。
管理が甘いローカル端末は、ガバナンスの効いたクラウドAPIより危険な場合があります。
逆に、法的根拠や承認済みの処理体制がない状態でクラウドAPIに機密音声を送るのも適切ではありません。
正しい判断は、実際のデータフロー図と脅威モデルから導く必要があります。
自分のプロジェクトが該当するか確認する
以下の項目を順に確認してください。該当する項目が多いほど、リスクは高くなります。
- 文字起こし結果の精度をWERだけで評価し、エラーの種類（語彙・固有表現・数値・否定・話者・境界・言語）を分類していない
- 音声ファイル・テキスト・話者ラベル・修正履歴が別々のストレージやテーブルに保存され、共通のトレースIDで結合できない
- 下流システム（チケット起票、要約、検索）への接続点に、誤り率の閾値によるゲート（通過条件）がない
- 利用しているモデルのバージョンがピン留め（固定）されておらず、APIプロバイダー側のモデル更新で出力が変わっても検知できない
- 音声データの保持期間・削除証跡（削除の記録）を自分たちで把握していない
実際に確認する手段としては、まずパイプラインの設定ファイルやIaC（Infrastructure as Code: インフラをコードで管理する手法。Terraform、Pulumiなど）のコードでモデルバージョンの指定箇所を探します。
# Terraformでモデルバージョンがハードコードされているか確認する例
grep -r "whisper" ./infra --include="*.tf" -A 2
# APIクライアントのモデル指定箇所を確認する例
grep -rn "model.*=" ./src | grep -i whisperバージョンがlatestや未指定のままになっていると、プロバイダー側のモデル更新がそのまま本番出力に影響します。
リグレッション（既存機能の劣化）を検知する仕組みがないまま運用していないか、ここで確認しておきます。
対策の手順
文字起こしを本番にデプロイする前に、受け入れパイプライン（acceptance pipeline: 出力が品質基準を満たすか機械的に検査する仕組み）を用意します。
1. リスク分類を先に決める
精度の閾値を決める前に、誤りの種類を分類します。
- 語彙誤り（単語の置換・欠落・挿入）
- 固有表現誤り（人名・組織名・製品名・専門用語）
- 数値誤り（金額・日付・時刻・割合・識別子）
- 極性誤り（否定や条件が意味を反転させる）
- 話者誤り（発言の帰属間違い）
- 境界誤り（無関係な発言が結合される）
この分類ごとに許容可能な誤り率、つまりSLOを別々に設定します。
すべてを一律のWERで扱うと、数値誤りのような重大な誤りが他の軽微な誤りに埋もれてしまいます。
2. 代表的な音声でスキーマテストを組む
重なった発話、雑音、方言、専門用語、コードスイッチング（言語の混在）を含むサンプル音声セットを用意し、CIパイプラインに組み込みます。
APIの出力に話者分離（diarization）やタイムスタンプが含まれる場合は、そのスキーマが期待通りか検査します。
3. トレースを1本に統合する
音声・文字起こし結果・話者構造・不確実性スコア・人間の修正・下流アクションを、共通のトレースIDで紐づけます。
オブザーバビリティ（可観測性）基盤に、音声処理パイプライン専用のトレースとメトリクスを流し込み、誤り率の推移をダッシュボードで監視できるようにします。
4. ロールアウト前にロードテストとコストガードレールを設定する
API利用の場合はレート制限とリトライ挙動を確認し、ローカル実行の場合はキューイングとキャパシティプランニングを行います。
コスト急増を防ぐため、1日あたりの処理時間や呼び出し回数に上限（ガードレール）を設定します。
5. 削除証跡とリテンションマップを文書化する
音声データとテキストの保持期間、削除の実行タイミング、アクセス権限を一覧化します。
APIプロバイダーのデータ処理条件（retention behavior）を確認し、自社ポリシーと矛盾がないかを照合します。
まとめ
音声認識の出力は、文法的に自然だからといって正確とは限りません。
WERという単一指標ではなく、語彙・固有表現・数値・極性・話者・境界といった誤りの種類ごとにSLOを設け、受け入れパイプラインを通過したものだけを下流に流す仕組みが欠かせません。
まず着手すべきは、現状の設定ファイルでモデルバージョンがピン留めされているかの確認と、音声・テキスト・修正履歴が1つのトレースに紐づいているかの棚卸しです。
ここから着手すれば、文字起こしパイプラインの可用性設計を段階的に固めていけます。