ひとことで言うと
音声をテキストに変換する ASR サービスです。処理方式は2つだけ——S3 に置いたメディアファイルを処理するバッチと、リアルタイムに流し込むストリーミング。単語ごとにタイムスタンプと信頼度が付いた JSON が返ります。
要するに、速記者です。会議の録音を後から起こす仕事（バッチ）と、その場で同時に打つ仕事（ストリーミング）では、同じ速記者でも使える道具が変わります。字幕ファイルの整形は後からしかできないし、PII を「伏せずに印だけ付ける」のは同時通訳の側にしかない。この非対称が Transcribe の設計であり、試験の出題点でもあります。
なぜ生まれたか
音声を扱うアプリの前提には、いつも「音のままでは検索も分析もできない」という壁がありました。テキストにさえなれば、既存の NLP も検索も LLM もそのまま使えます。公式の位置づけも「単体の文字起こしサービスとして、あるいは任意のアプリに音声認識を足すために使う」というものです。
生成AI の文脈でこれが効くのは、FM の入口はテキストであるという一点です。コールセンターの通話、会議録音、動画の音声——いずれも Bedrock に直接は入りません。AIP-C01 の D1 が「マルチモーダルデータの前処理」として Transcribe を名指ししているのは、RAG の材料や FM への入力を作る最初の一手だからです。
| 何が不便だったか | Transcribe の答え |
|---|---|
| 音声のままでは検索・分析・FM への入力にできない | ASR で単語ごとのタイムスタンプ・信頼度付き JSON にする |
| 専門用語・固有名詞が普通の辞書に無い | カスタム語彙（ヒントを与える）／カスタム言語モデル（文脈ごと学習させる） |
| 複数話者が1本の音声に混ざる | 話者ダイアライゼーション（1チャンネル内の話者を分離）／チャンネル識別（2チャンネルを別々に） |
| 転写に個人情報がそのまま残る | PII リダクション（バッチ・ストリーミング両対応）／ストリーミングは識別だけも可能 |
| 言語が事前に分からない | 言語識別・複数言語識別 |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| 録音を後からテキスト化 | StartTranscriptionJob（S3 のメディアファイル） | D1 |
| リアルタイム文字起こし | StartStreamTranscription（HTTP/2・WebSocket） | D1 |
| 通話・会議を RAG の材料にする | バッチで転写 → チャンキング → 埋め込み | D1 |
| FM へ渡す前に個人情報を落とす | ContentRedaction で PII をリダクト | D1 |
| 専門用語の精度改善（軽い方） | カスタム語彙（単語のヒント・発音を与える） | D1 |
| 専門用語の精度改善（重い方） | カスタム言語モデル（最大 2 GB のテキストで学習・任意で最大 200 MB のチューニングデータ） | D1 |
| 不適切語の伏字 | 語彙フィルタリング（バッチ・ストリーミング両方） | D1 |
| 議事録の話者分け | 話者ダイアライゼーション（バッチ・ストリーミング両方） | D1 |
| 動画の字幕 | 字幕（Subtitles）はバッチのみ | D1 |
| 通話分析（感情・要約・カテゴリ） | Transcribe Call Analytics（別系統。音声そのもののリダクトもここ） | D1 |
試験でどう問われるか
Transcribe が単独の主役になる問題はほぼありません。「音声を含むデータをどう GenAI パイプラインに載せるか」というシナリオで、前処理の1ステップとして正しい位置に置けているかが問われます。実質的な出題点はバッチとストリーミングの機能差で、ここだけは覚えていないと当てられません。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 通話録音を RAG に載せたい | 音声のままでは埋め込めない → Transcribe でテキスト化してからチャンキング・埋め込み | 音声ファイルを直接ベクトルストアに入れる案／Comprehend に音声を渡す案（Comprehend の入力はテキスト） |
| リアルタイム通話支援 | 待てない → ストリーミング（HTTP/2 または WebSocket） | バッチ（S3 に置いて StartTranscriptionJob）。仕組み上リアルタイムにならない |
| 「PII は伏せず、どこにあるか印だけ付けたい」 | PII の識別だけはストリーミングの機能（リダクトせずフラグを立てられる） | バッチでの識別。バッチにあるのはリダクションであって識別ではない |
| 動画に字幕を付けたい | 字幕はバッチのみ（WebVTT / SubRip） | ストリーミングで字幕ファイルを生成する案 |
| 業界特有の用語が化ける | 単語のリストで足りるならカスタム語彙／文脈から直したいならカスタム言語モデル | 「カスタム言語モデルと言語識別を併用する」。CLM を使うと言語識別は使えず、言語コードの明示が必須 |
| 音声を FM に直接渡すか | 音声・動画・文書をまとめて扱い、要約や分類まで任せたい → Bedrock Data Automation | 「Transcribe で転写してから FM に投げる」が常に最適とは限らない（要件に「動画のシーン要約」等があれば BDA 側） |
| 通話の感情・要約まで欲しい | Transcribe Call Analytics（通話特性・要約・カテゴリ・リアルタイム課題検知） | 素の Transcribe ＋ 自前の後処理（動くが、選択肢に Call Analytics があればそちら） |
| 音声そのものから PII を消したい | 音声のリダクトは Call Analytics の機能 | 素の Transcribe の ContentRedaction。これが消すのは転写テキストであって音声ではない |
1問拾える境目: PII 関連で機能の所在が3つに割れています——転写のリダクションはバッチとストリーミングの両方、PII の識別（フラグだけ）はストリーミングのみ、音声のリダクトは Call Analytics のみ。加えて、公式は「リダクション機能は HIPAA のような医療プライバシー法における非識別化の要件を満たさない」と明記しています。「PHI を扱うので Transcribe でリダクトすれば匿名化できる」という選択肢は外れます（PHI の識別は Transcribe Medical 側の機能）。
実務でどう使うか
- バッチとストリーミングでは受け付けるメディア形式が違います。 バッチは AMR / FLAC / M4A / MP3 / MP4 / Ogg / WebM / WAV、ストリーミングは FLAC / Ogg Opus / PCM のみ。公式は「推奨形式に WAV は含まれない（ストリーミングでは PCM 符号付き16bit リトルエンディアン）」とわざわざ書いています。既存の WAV 資産をそのままストリーミングに流す前提の設計は組み替えになります
- ストリーミングではサンプルレートの指定が必須です（バッチは任意）。いずれの場合も実際の音声と値が一致していないとジョブが失敗します
- チャンネルは最大2つまで。 3チャンネル以上のメディアは非対応です。1チャンネルに複数話者ならダイアライゼーション、2チャンネルに分かれているならチャンネル識別、と使う機能が変わります
- 出力先を指定しないと転写は 90 日で消えます。 自分の S3 バケットを指定しなければサービス管理のバケットに置かれ、一時 URI の有効期間は 15 分、ジョブの失効（90 日）で削除されます。長期保管する設計なら最初から自分のバケットを指定します
- リージョンでバッチとストリーミングの提供が割れています。 両方使えるリージョンが多い一方、バッチのみ・ストリーミングのみのリージョンが実在します。加えて Transcribe 本体・Transcribe Medical・Call Analytics でリージョン対応が違うと公式が明記しているので、構成を決める前に対象リージョンを確認します
- カスタム言語モデルの学習データは最大 2 GB、チューニングデータは最大 200 MB。 公式の優先順は「正確なドメイン内の書き起こしが 10,000 語以上あればそれを学習データに（チューニングは不要）」で、学習データとチューニングデータを重複させないことが明記されています（重複させるとモデルが偏る）
- 課金は転写した音声の秒数で、1 秒単位・最低時間なし。PII リダクションとカスタム言語モデルには追加料金がかかります
転写の品質は下流すべてに伝播します。固有名詞が化けた転写を埋め込むと、ベクトル検索は「その用語では二度とヒットしない」状態になります。RAG の検索精度が落ちたときに埋め込みモデルとチャンクサイズだけを疑うと、原因（音声側）に永久に到達しません。カスタム語彙とカスタム言語モデルは、そのための入口の修理です。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Transcribe Call Analytics | 通話に特化した別系統。通話特性・要約・カテゴリ・リアルタイム課題検知・音声のリダクトはこちらにしかない。素の Transcribe にあるのは転写とその周辺だけ |
| Amazon Transcribe Medical | 医療音声専用（US 英語のみ）。PHI の識別はこちらの機能で、素の Transcribe には無い |
| Amazon Bedrock Data Automation | BDA は音声・動画・文書・画像を生成AIでまとめて構造化する。「転写だけ欲しい」なら Transcribe、「シーン要約・分類まで任せたい」なら BDA |
| Amazon Polly | Polly はテキスト→音声。Transcribe は音声→テキスト。方向が逆 |
| Amazon Comprehend | Comprehend の入力はテキスト。音声を渡すことはできない。Transcribe → Comprehend の順に並ぶ |
| カスタム語彙 と カスタム言語モデル | 語彙は単語のヒント（発音など）を与えて認識率を上げる。CLM は文脈を学習する（「ice floe」と「ice flow」のどちらが起きやすいかを覚える）。用語リストで足りるなら前者 |
想起チェック
Q1. 「通話中に PII の場所を画面に表示したい。伏字にはしない」。バッチとストリーミングのどちらですか。
ストリーミングです。PII をリダクトせず識別（フラグ付け）だけする機能はストリーミングにしかありません。バッチにあるのはリダクションです。
Q2. カスタム語彙とカスタム言語モデルの使い分けの基準は？
ヒントで足りるか、文脈が要るかです。カスタム語彙は単語（と発音）を与えて認識されやすくするもの、カスタム言語モデルは語の使われ方と語同士の関係を学習するもの。ドメイン特有の言い回しごと直したいなら CLM で、学習データは最大 2 GB です。
Q3. カスタム言語モデルを使うリクエストで、一緒に使えなくなる機能は何ですか。
言語識別です。CLM を含めるリクエストでは言語識別を有効にできず、言語コードを明示的に指定する必要があります。
Q4. 会議録音を RAG に載せたら検索がまったく当たりません。Transcribe 側で最初に疑うのはどこですか。
固有名詞・専門用語の転写精度です。用語が化けていれば、その語では埋め込みも検索も一致しません。カスタム語彙かカスタム言語モデルで入口を直します。チャンクサイズや埋め込みモデルはその後の話です。