Cloud Speech-to-Text (Chirp)

解決する課題

Chirp は Speech-to-Text V2 から選べる大規模な音声認識モデルで、自前のモデル学習なしに幅広い言語を高精度に文字起こしできます。

• 多言語の音声を、言語ごとに別モデルを切り替えず1 つの大規模モデルで扱いたい
• 利用者が少ない低リソース言語や方言でも、できるだけ高い認識精度を得たい
• 音声認識モデルの学習・チューニング・GPU 運用といったインフラ負担を避けたい
• 会議・通話・動画などの音声を文字化し、検索・分析・字幕生成・要約の入力にしたい

主要概念と用語

• Chirp: Google の大規模音声モデル（Universal Speech Model 系）をベースにした音声認識モデルの呼称。Speech-to-Text V2 でモデルとして選択する
• Speech-to-Text V2: Chirp を含む新しい音声認識基盤。後述の Recognizer など V1 と異なるリソースモデルを採用する
• Recognizer（認識器）: 言語・モデル・既定の認識設定をまとめた再利用可能なリソース。リクエストはこの Recognizer を指定して送る
• モデル（model）: 認識に使うモデルの指定。Chirp 系を選ぶと大規模モデルで推論する。用途や対応言語に応じて使い分ける
• 言語コード（language code）: 認識対象の言語・地域の指定。Chirp は多数の言語に対応し、複数候補からの自動判別に対応する構成もある
• ロケーション（location）: 認識処理を行うリージョン指定。モデルやリージョンの対応関係に従って選ぶ
• バッチ認識 / ストリーミング認識: 録音ファイルをまとめて処理するバッチと、音声を送りながら逐次結果を受け取るストリーミング
• 句読点の自動付与・単語タイムスタンプ: 結果を読みやすくする句読点挿入と、単語ごとの時刻情報。対応可否はモデルや言語に依存する

仕様・制限・クォータ

• Chirp はSpeech-to-Text V2 の機能であり、リクエストではモデルとして Chirp 系を指定し、Recognizer を介して呼び出す
• 対応する言語・方言は非常に多いが、句読点付与・タイムスタンプ・話者分離などの付加機能は、モデルや言語によって対応範囲が異なる
• 利用できるモデルとリージョンの組み合わせには制約があり、選んだロケーションで使えるモデルかを事前に確認する
• 入力は音声データで、リクエストに含める方法と Cloud Storage 上のファイルを参照する方法がある。長尺音声はバッチ認識で扱う
• ストリーミング認識には1 ストリームあたりの時間上限があり、長時間の連続認識はストリームを区切る
• リクエスト数や音声処理時間にはプロジェクト単位のクォータがあり、必要に応じて引き上げを申請できる

内部の仕組み

クライアントは音声データと認識設定（言語コード・モデル・ロケーションなど）を Speech-to-Text V2 API に送り、Google のマネージドな大規模音声モデルが推論してテキストを返します。利用者はモデルの学習や GPU インフラを意識しません。

• Recognizer を起点に呼ぶ: 言語・モデル・既定設定をまとめた Recognizer を作成し、リクエストでそれを指定する。設定を一元化して再利用できる
• 大規模モデルによる認識: Chirp は多言語をまたいで学習された大規模モデルを基盤とし、低リソース言語でも比較的高い精度を狙える設計になっている
• バッチ認識: 長尺音声をまとめて処理する。多くの場合 Cloud Storage 上の音声を参照し、結果を後から受け取る
• ストリーミング認識: 音声チャンクを送り続け、サーバーから途中結果と確定結果が逐次返る方式
• 結果には信頼度スコアや、設定に応じて単語ごとのタイムスタンプが付与される

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

• 多言語・低リソース言語はまず Chirp を候補に: 対応言語の広さと精度の高さを活かし、言語横断の文字起こしで第一候補にする
• Recognizer に設定を集約: 言語・モデル・既定の認識設定を Recognizer にまとめ、アプリ側の指定を簡潔に保つ
• 長尺録音はバッチ認識: 録音ファイルは Cloud Storage に置き、バッチで処理して長さ制限を回避する
• モデルとリージョンの対応を設計時に確認: 使いたい言語・機能・ロケーションで Chirp が利用可能かを先に検証する
• 後段処理と疎結合に組む: 文字起こし結果を Pub/Sub などに流し、要約・翻訳・分析（自然言語処理）へつなぐ非同期パイプラインにする
• 入力フォーマットを規格化: 録音側でエンコーディングとサンプルレートを統一し、推奨フォーマットに揃えてから送る

運用・監視

• Cloud Monitoring で API のリクエスト数・エラー率・レイテンシを監視し、想定どおり処理できているか確認する
• Cloud Logging に API 呼び出しの記録が残る。失敗時はここを起点にエラー内容を調査する
• 認識精度が低い → まず言語コード・モデル・ロケーションの設定と入力音声フォーマットを見直す
• 「モデルが使えない」エラー → 選んだリージョンとモデルの対応を確認し、対応ロケーションへ切り替える
• バッチジョブが終わらない → ジョブの状態を確認し、入力音声のサイズやフォーマットを点検する
• クォータ超過のエラーが出る → リクエスト頻度を調整し、必要ならクォータ引き上げを申請する

コスト

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

セキュリティ

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

関連サービス・比較

Chirp は Speech-to-Text の中で選べるモデルの一つです。従来の Speech-to-Text（V1 の標準モデル）と比べると、多言語と低リソース言語への強さが特長になります。

ハンズオン / CLI例

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

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

# 3) Chirp 用の Recognizer を作成（言語とモデルを指定）
gcloud ml speech recognizers create my-chirp-recognizer \
  --location=us-central1 \
  --model=chirp \
  --language-codes=ja-JP

# 4) 作成済み Recognizer の設定を確認
gcloud ml speech recognizers describe my-chirp-recognizer \
  --location=us-central1