電話音声では、8,000 Hz の LINEAR16 が標準的な PSTN 音声に一致します。MULAW（G.711）もサポートされており、トランスコードを行わない SIP トランクでは重要になります。
ストリーミングセッションの制限
開発者が最初につまずくのがここです。ストリーミングセッションは 305 秒が上限です。~5 分を超える通話では、自分で再接続し、文字起こしをつなぎ合わせる必要があります。Google 自身のドキュメントもこの制限を認めており、再接続はアプリケーション層で管理するよう推奨しています。
本番システムにとって、これは決して小さな要求ではありません。以下はすべて自分の責任になります。
- 期限切れが近いことを検知し、セッションが切れる前に再接続を開始する
- 切り替えの空白時間に音声をバッファリングする
- セッション境界をまたいで中間結果をつなぎ合わせ、継ぎ目で単語を失わないようにする
Google Cloud Speech Recognition が力を発揮する場面
高品質なスタジオ音声や近接収録音声
Google の音響モデルは、YouTube 動画、放送音声、音声検索クエリなど、膨大な量のウェブ音声で学習されています。背景ノイズが少なく、マイクに近い位置で収録されたクリーンな音声であれば、精度は非常に高くなります。
大規模なバッチ文字起こし
品質管理やコンプライアンスのために録音済みの通話を数千件単位で文字起こしするなら、バッチ API はコスト効率がよく精度も高いです。拡張モデル phone_call と組み合わせれば、電話品質の音声でも安定した結果が得られます。
多言語対応の要件
単一の API で 125+ 言語という点はなかなか他に代えがたい強みです。地域によって対応言語のリストが変わるグローバル製品を作るなら、1 社に統合することでスタックはシンプルになります。
GCP エコシステムとの統合
インフラがすでに GCP 上にある場合（音声ルーティングに Pub/Sub、処理パイプラインに Dataflow、分析に BigQuery）、Speech API はきれいに組み込めます。IAM ロール、VPC Service Controls、Cloud Audit Logs もそのまま適用されます。
コンタクトセンター用途で Google Cloud Speech Recognition が苦戦する点
1. 発話終了検出が会話向けに最適化されていない
本番の音声 AI で最大の難所は、発信者が話し終えたタイミングを見極めることです。早すぎれば相手をさえぎり、遅すぎれば沈黙が不自然に感じられます。
Google の VAD（音声区間検出）は一般的な音声向けにチューニングされており、会話型の電話音声向けではありません。コンタクトセンターのチームからは、singleUtterance モードの調整に加えて独自の無音検出ロジックを重ねる必要があるという声が日常的に上がっています。これを正しく作り込むには相当なエンジニアリング工数がかかり、それでも会話専用に設計されたモデルには及びません。
2. 305 秒のストリーミング制限が運用上の複雑さを生む
前述のとおり、セッションの再接続は自分で管理しなければなりません。平均処理時間 4–8 分の通話を数千件同時に扱うコンタクトセンターにとって、これは決して軽視できない信頼性上の課題です。再接続のたびに文字起こしの欠落とレイテンシのスパイクが起こり得ます。
3. 会話状態やインテントが組み込まれていない
Google Cloud Speech-to-Text が返すのは単語です。意味もインテントもエンティティも会話状態も返しません。NLU は自分で上に重ねる必要があり、一般的には Dialogflow CX か別のモデルを使うことになりますが、その分レイテンシ、コスト、統合面の負担が増えます。
単純な IVR の置き換えであれば、その構成でも問題ないでしょう。しかし、微妙なニュアンスを含む顧客対応をこなし、予約を取り、文脈を保ったまま適切なキューへ転送する AI 音声エージェントとなると、あらかじめ接続されていない配管を大量に自分でつなぐことになります。
4. ストリーミングのレイテンシは競争力はあるが最速ではない
Google のストリーミングレイテンシは、音声の長さとモデルにもよりますが、最終結果でおおむね 300–800ms の範囲です。文字起こしだけの用途なら許容範囲でしょう。発信者が話し終えてから ~1 秒以内に AI が応答しなければならないリアルタイム音声エージェントでは、1 ミリ秒が効いてきます。低レイテンシのリアルタイム出力に特化した STT サービスは、この差を縮めてきました。
5. カスタム語彙には有料のアダプテーションが必要
製品名、社内用語、医療用語、英数字の識別子といったドメイン固有の語には、フレーズヒントかカスタムモデルが必要です。フレーズヒントは無料ですが効果は限定的です。カスタムモデル（AutoML Speech 経由）は追加の学習コンピューティング費用がかかり、ラベル付きデータも必要です。小規模なコンタクトセンターでは、語彙の問題に見合わない投資になることが少なくありません。
Google Cloud Speech Recognition と AssemblyAI と専用設計の音声 AI
AssemblyAI（このキーワードで #9 にランクイン）は、会話音声での高い精度、感情分析の内蔵、トピック検出を備えた開発者フレンドリーな STT API を掲げています。NLU 層を自前で作らずに、文字起こしとアノテーションの両方が欲しいプロダクトチームにとっては、すぐに使い始められる分こちらのほうが優れています。
とはいえ、Google Cloud Speech と AssemblyAI には同じ根本的な制約があります。どちらも文字起こしサービスであって、音声エージェントではないという点です。
| 機能 | Google Cloud STT | AssemblyAI | 専用設計の音声 AI（例: Finn） |
|---|---|---|---|
| 文字起こし | ✓ | ✓ | ✓（内蔵） |
| リアルタイムストリーミング | ✓ | ✓ | ✓ |
| インテント / NLU | ✗ | 一部 | ✓ |
| 会話状態 | ✗ | ✗ | ✓ |
| ターンテイキング / バージイン | ✗ | ✗ | ✓ |
| CRM / カレンダー連携 | ✗ | ✗ | ✓ |
| 通話全体を自律的に処理 | ✗ | ✗ | ✓ |
| 1 秒未満の応答レイテンシ | 一部 | 一部 | ✓ |
目的が音声の文字起こしであれば、Google Cloud Speech Recognition は妥当な選択です。目的がコンタクトセンターのオペレーターを置き換える、あるいは補強すること（着信対応、リードの選別、予約受付、人手を介さない FAQ 対応）であれば、STT の完全に上位に位置するレイヤーが必要になります。
Google Cloud Speech Recognition のセットアップ: クイックスタート
API を評価している開発者向けに、最小構成の手順を示します。
1. API を有効化して認証情報を作成する
よくある質問
ストリーミングセッションの制限はどれくらいですか?
Google Cloud Speech-to-Text は 1 回のストリーミング認識セッションの長さに上限を設けているため、長い通話はセッションを開いたままにするのではなく、分割して複数セッションにまたがってつなぎ合わせる必要があります。
電話音声はどのように扱われますか?
電話帯域向けにチューニングされたモデルがあり、これは重要です。広帯域音声で学習したモデルは、8kHz の通話では明らかに精度が落ちます。
リアルタイム音声エージェントに向いていますか?
文字起こしとしてなら向いています。制約になるのはたいてい認識品質ではなく、セッション管理とリージョンまでのラウンドトリップです。
