Transcribe＋Bedrockで会話内容の要約をしつつWebブラウザで録音もする

本記事では、Amazon TranscribeとAmazon Bedrockを組み合わせて、店頭での顧客対応をAIがアシストするシステムの構築事例を紹介します。顧客との会話をリアルタイムで文字起こしし、その内容をAIが要約・分析することで、接客品質の向上を実現しました。

特にTranscribeのストリーミング機能とBedrockの高度な言語理解能力を組み合わせることで、どのような効果が得られたのか、またそれを実現するために行ったフロントエンド側の技術的工夫についても解説します。

プロジェクトの背景

本プロジェクトは、顧客対応の質を向上させるための支援システムを構築することが目的でした。
冒頭の要件を満たすため、以下のAWSサービスを使用しました。

• Amazon Transcribe: リアルタイム文字起こし（ストリーミングモード）
• Amazon Bedrock: 文字起こし結果の要約・分析
• Amazon API Gateway & Lambda: バックエンドAPI処理
• Amazon DynamoDB: 文字起こし結果と要約データの保存
• Amazon S3: 音声データの保存

タブレット端末上で動作するWebアプリケーションとして実装し、フロントエンドはNext.jsを採用しました。

システム全体の流れは以下の通りです。

1. ブラウザでマイク入力を取得し、Amazon Transcribeにストリーミング送信
2. Transcribeから返ってきた文字起こし結果をAPI Gateway経由でLambdaに送信
3. Lambdaが処理してDynamoDBに保存（ここから後にBedrock経由で要約も生成）
4. 同時に音声データはブラウザ内のIndexedDBに一時保存
5. 会話終了後にS3へ音声データをアップロード

Amazon Transcribeを用いたリアルタイム文字起こしの実装

Amazon Transcribeのストリーミングモードとバッチモードの比較

Amazon Transcribeには、リアルタイム処理を行う「ストリーミングモード」と、録音済みファイルを処理する「バッチモード」があります。今回はリアルタイム性を重視してストリーミングモードを採用しましたが、両者にはリアルタイム性と精度のトレードオフにおける違いがあります。

リアルタイム性と精度のトレードオフ

ストリーミングモードはリアルタイム性に優れていますが、バッチモードと比較すると精度面で若干の低下があります。これは、ストリーミングモードでは文脈の前後関係が限られた状態で認識を行うためです。一方、バッチモードでは音声全体を分析できるため、特に専門用語や固有名詞などの認識精度が高くなる傾向があります。

本プロジェクトでは、商品の説明や契約内容の確認といったやり取りが含まれるため、認識精度は重要な要素でした。動作確認の段階では、ストリーミングモードのみでは十分な精度は得られませんでした。しかし、Amazon Bedrockによる要約処理と組み合わせることで、多少の誤字・脱字があっても、文脈から適切に解釈して要約を生成できることを確認できました。

デモシナリオとTranscribe文字起こし結果の比較

長大なため折りたたんでいます。

デモシナリオ

店員: いらっしゃいませ。本日はどのようなご用件でしょうか？

顧客: テレビを買い替えようと思っているんですが、おすすめを教えていただけますか？

店員: かしこまりました。おおよそのご予算と、どのような用途で使われるかを教えていただけますと、より適したご提案ができます。

顧客: 予算は50万円くらいで、主に映画観賞と家族でのテレビ視聴用です。リビングに置く予定です。

店員: ありがとうございます。リビング用でしたら、画面サイズはどのくらいをお考えですか？お部屋のサイズにもよりますが、40〜55インチくらいが一般的です。

顧客: 部屋は広めなので、50インチくらいがいいかなと思っています。

店員: わかりました。こちらの機種はいかがでしょうか。50インチで4K対応、映画鑑賞に適した高画質モデルです。価格も498,000円とご予算内です。スマートテレビ機能も搭載しているので、動画配信サービスも視聴できます。

顧客: いいですね。実際の映像はどうですか？

店員: こちらでデモをご覧いただけます。（テレビを操作して映像を表示）色の発色や暗部の表現が優れており、映画鑑賞に特に適しています。また、動きの速いシーンでもブレが少ないのが特徴です。

顧客: 音質はどうですか？

店員: 標準スピーカーでも十分クリアな音質ですが、より臨場感を求められるなら、同じメーカーのサウンドバーとの相性が良いです。セットで購入されると5,000円引きになるキャンペーンも実施中です。

顧客: 検討してみます。あと、保証はどうなっていますか？

店員: 製品保証は1年間ついています。当店の延長保証に加入されると、5年間の保証が付きます。料金は本体価格の10%です。

顧客: わかりました。このテレビにします。延長保証も付けてください。

店員: ありがとうございます。では、こちらの商品と延長保証をご用意いたします。配送と設置のご希望日はございますか？

顧客: 今週の土曜日の午前中にお願いできますか？

店員: 確認いたします...土曜日の午前中で承りました。それでは、レジにてお手続きをさせていただきます。

Transcribe文字起こし結果

以下はTranscribe文字起こし結果に発話者（店員、顧客）を補ったものです。

店員: いらっしゃいませ。本日はどのような用件でしょうか。

顧客: テレビを買い換えようと思っているんですが、おすすめを教えていただけますか?

店員: かしこまりました。おおよそのご予算とどのような用途で使われるかを教えていただけますと、より適したご提案ができます。

顧客: 予算は50万円くらいで、主に映画鑑賞と家族でのテレビ視聴用です。リビングに置く予定です。

店員: ありがとうございます。リビング用でしたら、画面サイズはどのくらいお考えですか? お部屋のサイズにもよりますが、40から55インチくらいが一般的です。

顧客: 部屋は広めなので50インチくらいがいいかなと思っています。

店員: 分かりました。こちらの機種はいかがでしょうか。50インチで4k太陽映画鑑賞に適した高画質モデルです。価格も498,000円とご予算内です。スマートテレビ機能も搭載しているので、動画配信サービスも視聴できます。

顧客: あの、いいですね。実際の映像はどうですか?

店員: こちらでご覧いただけます。色の発色や暗部の表現が優れており、映画鑑賞に特に適しています。また動きの速いシーンでもブレが少ないのが特徴です。

顧客: 音質はどうですか?

店員: 標準スピーカーでも十分クリアな音質ですが、より臨場感を求めるなら、同じメーカーのサウンドバーとの相性がいいです。セットで購入されると50000円引きになるキャンペーンも実施中です。

顧客: 検討してみます。あと保証はどうなっていますか?

店員: 製品保証は一年間続いています。当店の延長保証に加入されると、五年間の保証がつきます。料金は本体価格の10セです。

顧客: 分かりました。このテレビにします。延長保証もつけてください。

店員: ありがとうございます。では、この商品と延長保証をご用意いたします。配送と設置のご希望日はありますか?

顧客: 今週の土曜日の午前中をお願いします。

店員: 確認します。土曜日の午前中で承りました。それではレジにてお手続きをさせていただきます。

デモシナリオとTranscribe文字起こし結果の主な差異

1. 店員の発言（製品説明）

   • トランスクリプト: 「50インチで4K対応、映画鑑賞に適した高画質モデルです。」
   • 文字起こし: 「50インチで4k太陽映画鑑賞に適した高画質モデルです。」
   • 差異: 「4K対応」が「4k太陽」と誤認識されている

2. 店員のデモ説明

   • トランスクリプト: 「こちらでデモをご覧いただけます。（テレビを操作して映像を表示）」
   • 文字起こし: 「こちらでご覧いただけます。」
   • 差異: 「デモを」が欠落、説明文が文字起こしには含まれていない

3. キャンペーン内容

   • トランスクリプト: 「セットで購入されると5,000円引きになるキャンペーン」
   • 文字起こし: 「セットで購入されると50000円引きになるキャンペーン」
   • 差異: 金額が「5,000円」から「50000円」に誤認識されている

4. 保証料金の表現

   • トランスクリプト: 「料金は本体価格の10%です。」
   • 文字起こし: 「料金は本体価格の10セです。」
   • 差異: 「10%」が「10セ」と誤認識されている

5. 会話の流れ

   • 文字起こしでは「あの、」という顧客の言葉が追加されている
   • 文字起こしでは顧客の質問と店員の回答の区切りが一部不明確

また、以下の表記の違いがありました。特に、検証中は算用数字で表示してほしい箇所が算用数字になることがありました。

• 「わかりました」→「分かりました」
• 「買い替えよう」→「買い換えよう」
• 「40〜55インチ」→「40から55インチ」
• 「1年間」→「一年間」
• 「5年間」→「五年間」
• 「こちらの商品」→「この商品」

Transcribe文字起こし結果をAmazon Bedrockで要約することにより、以下の結果を得られました。

検証で使用したLLMはClaude 3.5 Sonnetです。

プロンプト: 以下のTranscribe文字起こし結果を読み込み、会話内容を箇条書きで要約してください。

出力結果:

• 顧客はテレビの買い替えについて相談
• 予算は10万円程度、主な用途は映画鑑賞と家族でのテレビ視聴
• リビングに設置予定で、部屋が広いため50インチサイズを希望
• 店員は498,000円の50インチ4K高画質モデルを提案
• 提案されたテレビはスマートテレビ機能搭載で動画配信サービスも視聴可能
• 顧客は映像品質と音質について質問
• 店員はサウンドバーとのセット購入で5,000円引きになるキャンペーンを案内
• 製品保証は1年間、延長保証(本体価格の10%)で5年間に延長可能
• 顧客はテレビと延長保証の購入を決定
• 配送・設置は今週土曜日の午前中に予定

Bedrockによる要約結果では、Transcribeの「50000円引き」を「5,000円引き」に、「4k太陽映画鑑賞」を「4K高画質モデル」に、「本体価格の10セ」を「10%」に修正し、さらに漢数字を算用数字に統一するなど、文字起こしの誤りや表記ゆれを自動的に修正しています。

Web Audio APIによる音声キャプチャ

Transcribeへの音声ストリーミングを効率的に行うため、Web Audio APIのgetUserMediaメソッドを使用しました。以下の設定を適用することで、ノイズを抑制した音声録音を実現しました。

キー名	設定値	説明
sampleRate	16,000Hz	Transcribeの推奨値に合わせて設定
channelCount	1 (モノラル)	音声認識に適した単一チャネル設定
echoCancellation	true	音声のエコー（反響）を抑制
noiseSuppression	true	背景ノイズを低減
autoGainControl	true	音量レベルを自動調整

ReactでのTranscribeのイベント制御と状態管理

Next.jsアプリケーションでは、録音の開始・停止をReactのイベントとして管理する実装としました。また、Context APIを使用することでアプリケーション全体で録音の状態や文字起こし結果を共有できるようにしました。

Context APIを用いた録音状態の管理

Context APIを用いて録音状態、文字起こし結果などをアプリケーション全体で管理します。これにより、複数の画面やコンポーネント間で一貫した録音体験を提供できます。

録音開始と停止のハンドリング

録音開始のイベント処理の主な処理フローは以下のとおりです。

処理ステップ	説明
画面遷移の実行	router.push()を使用して即座に次画面へ遷移
会話IDの生成	UUIDで一意の識別子を生成
録音処理の開始	AudioWorkletの初期化とTranscribeへのストリーミング開始

録音停止時には、開始時とは逆の順番でクリーンアップを行います。

このアプローチにより、ユーザー待ち時間を感じることなくバックグラウンドで録音処理を開始・停止できます。

AudioWorkletによる画面遷移に強い録音システム

MPAの課題として、ページ遷移によってオーディオ処理が中断されることが懸念されました。この問題を解決するため、SPAとAudioWorkletとContext APIを組み合わせた実装を行いました。

AudioWorkletの特徴と利点

AudioWorkletを用いることで、オーディオ処理をメインスレッドから分離して実行できます。これにより、UIのレンダリングなどの影響を受けずにTranscribeへの音声転送が可能となりました。

従来のScriptProcessorNodeと比較して、AudioWorkletは別のスレッドで動作するため、メインスレッドがブロックされても音声処理が継続します。これはページ遷移が頻繁に発生するSPAにとって大きな利点でした。

グローバルインスタンス管理によるページ遷移対策

SPA環境であっても、ページコンポーネントが再マウントされるとコンポーネント内のステートやリファレンスが失われます。そこで、AudioWorkleノードをContextとして保持する実装としました。

この実装によって、ページが切り替わっても、バックグラウンドでの音声録音とTranscribeへの送信を継続できることを確認しました。

IndexedDBを活用した録音データの保持とS3へのアップロード

Amazon Transcribeとの連携だけでなく、音声データの保存も重要な要件でした。ブラウザ内のIndexedDBを活用して一時的に音声データを保持し、会話終了後にAmazon S3へアップロードする仕組みを実装しました。

まとめ

今回の取り組みで特に重要だったのは次の3点です。

1. リアルタイム性と精度のバランス: Transcribeのストリーミング機能ですぐに文字起こしを分析できる利便性を確保しつつ、Bedrockを活用することで多少の誤認識があっても適切な要約・分析を実現できました。
2. 画面遷移に強い音声処理: AudioWorkletとContext APIの組み合わせにより、画面遷移があっても音声ストリーミングが途切れない仕組みを実装できました。
3. 長時間録音の安定化: IndexedDBを活用したデータの一時保存と効率的なメモリ管理により、2時間程度の長時間でも安定した録音と文字起こしを可能にしました。