Speech-to-Text

解決する課題

音声認識モデルを自前で学習・運用する手間なく、音声からテキストを取り出せます。

• 会議・通話・動画などの音声を文字起こしして、検索・分析・字幕生成に使いたい
• コールセンターの通話をリアルタイムに文字化し、要約や感情分析の入力にしたい
• 音声認識モデルの学習・チューニング・GPU 運用といったインフラ負担を避けたい
• 多言語の音声を、言語ごとに別システムを組まずに1 つの APIで扱いたい

主要概念と用語

• 文字起こし（Transcription）: 音声波形をテキストへ変換する処理。本サービスの中心機能
• 同期認識 / 非同期認識（バッチ）: 短い音声をその場で返す同期認識と、長尺音声を時間をかけて処理する非同期認識。長い録音は非同期で扱い、結果を後から取得する
• ストリーミング認識: 音声を送りながら**逐次的に途中結果（interim result）と確定結果（final result）**を受け取る方式。リアルタイム字幕や対話用途に向く
• 認識モデル（Recognition model）: 用途に合わせた音声モデル。電話音声向け、動画向け、汎用の長尺向けなど、入力特性に応じて選ぶと精度が上がる
• 言語コード（Language code）: 認識対象の言語・地域を指定する設定（日本語、英語など）。複数候補を渡して自動判別させることもできる
• 話者分離（ダイアライゼーション, Speaker diarization）: 1 つの音声に複数話者がいるとき、発話を話者ごとに振り分ける機能
• 句読点の自動付与（Automatic punctuation）: 認識結果に句読点を自動で挿入し、読みやすいテキストにする
• 音声適応（Speech adaptation）: 固有名詞や専門用語などの語句のヒントを与え、特定ドメインの認識精度を高める仕組み

仕様・制限・クォータ

• 入力は音声データで、リクエストに直接含める方法と、Cloud Storage 上のファイルを参照する方法がある。長尺の音声は Cloud Storage 経由の非同期認識を使う
• 同期認識には音声の長さ・サイズに上限があり、それを超える録音は非同期認識で処理する。具体的な上限値は仕様に従い、定性的には「短い音声＝同期、長い音声＝非同期」と覚える
• 対応する音声フォーマット（エンコーディング）とサンプルレートに制約がある。可逆な無圧縮系（LINEAR16 など）を推奨することが多く、フォーマットとサンプルレートを正しく指定しないと精度が落ちる
• 多数の言語・地域に対応するが、話者分離や一部機能は対応言語・モデルが限られる場合がある
• リクエスト数や音声処理時間にはプロジェクト単位のクォータがあり、必要に応じて引き上げを申請できる
• ストリーミング認識には1 ストリームあたりの時間上限があり、長時間の連続認識はストリームを区切って扱う

内部の仕組み

クライアントは音声データと認識設定（言語コード・モデル・エンコーディング・サンプルレートなど）を API に送り、Google のマネージドな機械学習モデルが推論してテキストを返します。利用者はモデルの学習や GPU インフラを意識しません。

• 同期認識: 短い音声を 1 リクエストで送り、その応答として確定テキストを受け取る
• 非同期認識: 長尺音声に対して処理を開始すると長時間実行オペレーションが返り、完了後に結果を取得する。多くの場合 Cloud Storage 上の音声を参照する
• ストリーミング認識: 双方向のストリームで音声チャンクを送り続け、サーバーから途中結果と確定結果が逐次返る。発話の途中でも暫定テキストが得られる
• 認識結果には信頼度スコアや、設定に応じて単語ごとのタイムスタンプ・話者ラベルが付与される

設計パターン / ベストプラクティス

• 長尺の録音は Cloud Storage に置いて非同期認識: ファイルを GCS に保存し、参照渡しで非同期処理する。同期認識の長さ制限を回避できる
• リアルタイム用途はストリーミング認識: 通話・ライブ字幕など即時性が要る処理はストリーミングを使い、途中結果を UI に反映する
• 音声適応で固有名詞・専門用語を強化: 製品名や人名など辞書外の語句はヒントとして与え、ドメイン特化の精度を上げる
• 入力フォーマットを規格化: 録音側でエンコーディングとサンプルレートを統一し、推奨フォーマットに揃えてから送る
• 後段処理と疎結合に組む: 文字起こし結果を Pub/Sub に流し、要約・翻訳・分析（自然言語処理）へつなぐ非同期パイプラインにする
• 話者分離が要るかを設計時に判断: 複数話者の議事録なら話者分離を有効化し、不要なら無効化して処理を簡素にする

運用・監視

• Cloud Monitoring で API のリクエスト数・エラー率・レイテンシを監視し、想定どおり処理できているか確認する
• Cloud Logging に API 呼び出しの記録が残る。失敗時はここを起点にエラー内容を調査する
• 認識精度が低い → まず言語コード・モデル・エンコーディング・サンプルレートの設定を見直す。次に音声適応のヒント追加を検討する
• 非同期ジョブが終わらない → 長時間実行オペレーションの状態を確認し、入力音声のサイズやフォーマットを点検する
• クォータ超過のエラーが出る → リクエスト頻度を調整し、必要ならクォータ引き上げを申請する
• 大量バッチはリトライとバックオフを実装し、一時的なエラーで全体が止まらないようにする

コスト

課金はおもに**処理した音声の長さ（時間）**に基づき、一定量までの無料枠が用意されています。話者分離など一部機能やモデルの違いで単価が変わる場合があるため、用途に応じて見積もります。

セキュリティ

• API 呼び出しはサービスアカウントで認証し、認証情報をコードに埋め込まない。アプリには必要最小限の IAM ロールだけを付与する
• 音声を Cloud Storage 経由で扱う場合、バケットの権限を最小化し、公開設定にしない
• 保存データ・通信は既定で暗号化される。要件に応じて**顧客管理鍵（CMEK, Cloud KMS）**を併用し、外部流出対策に VPC Service Controls を組み合わせる
• 音声は個人情報や機密を含みうるため、保管期間・アクセス権・監査ログを定め、不要になったデータは削除する
• 文字起こし結果も機微情報を含むことがあるので、入力音声と同等の取り扱いをする

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: 音声認識モデルの学習・運用をマネージドに任せ、API 呼び出しに集中できる。設定（言語・モデル）は宣言的に管理でき、ログとメトリクスで可観測性を確保する
• 信頼性（Reliability）: マネージドサービスとして冗長化されており、非同期認識は長時間実行オペレーションで結果を確実に受け取れる。クライアント側はリトライとバックオフで一時障害を吸収する
• コスト最適化（Cost Optimization）: 処理した音声時間に応じた従量課金で、専用 GPU を常時持つ必要がない。不要な録音や無音を削り、必要な機能だけを有効化して単価を抑える

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) API を有効化
gcloud services enable speech.googleapis.com

# 2) 認識用の音声を Cloud Storage に置く（長尺は GCS 経由が基本）
gsutil cp ./meeting.wav gs://my-audio-bucket/meeting.wav

# 3) gcloud で文字起こしを実行（日本語・GCS 上の音声を指定）
gcloud ml speech recognize-long-running \
  gs://my-audio-bucket/meeting.wav \
  --language-code=ja-JP \
  --include-word-time-offsets

# 4) 短い音声をローカルファイルから同期認識する例
gcloud ml speech recognize ./short-clip.wav \
  --language-code=ja-JP

# 5) 非同期ジョブの状態を後から確認する（OPERATION_ID は実行時に返る）
gcloud ml speech operations describe OPERATION_ID