サイトアイコン IT & ライフハックブログ｜学びと実践のためのアイデア集

自分の声で日本語から英語へ通話翻訳するシステム設計｜要件定義から実装、評価、運用まで

greeden
green snake

Photo by Pixabay on Pexels.com

日本語で話した内容を英語へ翻訳し、登録した本人に近い声で相手へ届ける通話システムは、音声認識、翻訳、音声合成、通話制御を連携させて実現します。

難しいのは個々の機能を動かすことより、会話を妨げない速さ、誤訳への備え、声の適切な管理を一つの運用として成立させることです。

この記事では、特定製品に依存しない設計の考え方を、要件定義から試作、本番運用まで順に説明します。

完成品の使い方を知りたい場合は、Pixel 10のマイボイス通訳の設定と使い方も参考になります。

最初に決めるシステムの範囲

MVP（Minimum Viable Product）とは、利用者に価値を届けられる最小限の製品です。

通話翻訳では、初期段階から双方向通話と多言語対応を同時に目指すより、日本語から英語への片方向変換に絞ると検証しやすくなります。

通話翻訳MVPで先に決める項目
項目 最初の選択 確認すること
入力 日本語の音声 雑音や話速が変わっても認識できるか
出力 英語の合成音声と翻訳文 聞き取りやすさと意味の正確さを両立できるか
通話方式 WebRTCまたはSIPの片方 利用する端末と既存の電話設備に合うか
声の再現 同意を得た本人の声だけ 登録、利用、削除の手続きを説明できるか
失敗時の動作 原音、標準音声、文字表示への切り替え 会話を中断せずに継続できるか

「本人の声」とは、録音をそのまま再生することではありません。

登録音声から話者の特徴を抽出し、その特徴を条件として別言語の音声を合成します。

出力が本人と完全に同じになるとは限らないため、要件では「本人らしさ」と「聞き取りやすさ」を分けて評価します。

通話翻訳を構成する基本用語

VCは必須ではありません。

話者の特徴を指定できるTTSだけで受入基準を満たせるなら、処理時間と運用項目を増やさないために省略できます。

音声が相手へ届くまでの流れ

  1. 端末が日本語の音声を小さな単位で取得します。
  2. VADが発話の開始と区切りを検出します。
  3. ASRが確定前の途中結果と確定結果を順に返します。
  4. MTが意味のまとまりごとに英語へ翻訳します。
  5. TTSが英語を合成し、再生可能な部分から通話へ戻します。
  6. 通話基盤が合成音声を相手側へ届け、遅延や失敗を記録します。

発話の終わりを長く待ってから全処理を始めると、相手へ届くまでの待ち時間が増えます。

一方で、短く区切りすぎると文脈が不足し、翻訳が不自然になる場合があります。

例えば「来週の火曜日に、二名で予約したいです」という発話を一語ずつ訳すのではなく、日時と人数を意味のまとまりとして扱います。

分割単位は固定せず、通話場面、言語の組み合わせ、利用する音声認識と翻訳の特性に合わせて調整します。

要件定義で合格条件を明文化する

機能要件

非機能要件

遅延や可用性の数値を先に固定しても、端末、回線、言語、モデル、通話目的が違えば同じ体感にはなりません。

最初は利用場面を再現したテストで基準値を取り、その結果から受入条件を決めます。

コンポーネントの責任を分ける

主なコンポーネントと責任
コンポーネント 責任 記録する情報
通話ゲートウェイ 端末や電話網との音声送受信 接続状態、切断理由、音声欠落
分節処理 発話区間と翻訳単位の決定 区間長、確定までの時間
音声認識 日本語音声から文字への変換 途中結果、確定結果、処理時間
翻訳 日本語から英語への変換 原文、訳文、辞書の版
音声合成 訳文から英語音声への変換 再生開始時間、生成失敗
話者管理 同意、登録、利用、削除の管理 操作主体、目的、日時

各コンポーネントを分ける目的は、サービスの数を増やすことではありません。

障害や品質低下が起きたときに、どの処理で問題が生じたかを特定し、別の実装へ交換できる境界を作ることです。

音声モデルの選択肢や関連技術を調べる場合は、音声モデルとリアルタイム音声処理の解説も確認できます。

APIは同意と処理状態を表せる形にする

次のJSONは製品固有の仕様ではなく、設計時に必要な項目を確認するための例です。

話者プロフィールの登録例

{
  "user_id": "u_123",
  "consent_record_id": "consent_456",
  "locale": "ja-JP",
  "retention_policy": "policy_a"
}

音声ファイルをAPIへ直接埋め込むか、保護された保管先を参照するかは、ファイル容量、権限、監査要件を確認して決めます。

通話開始の例

{
  "caller_id": "u_123",
  "mode": "one_way",
  "source_language": "ja-JP",
  "target_language": "en-US",
  "speaker_profile_id": "speaker_789",
  "fallback": "standard_voice"
}

ストリーミング接続では、入力音声、認識途中結果、確定文、訳文、合成音声、エラー、遅延を別々のイベントとして扱うと状態を追いやすくなります。

非同期パイプラインの実装例

次の疑似コードは、分節した音声を順番に処理する骨格です。

音声形式、再試行、タイムアウト、認証、切断処理は利用するSDKと通話基盤に合わせて追加します。

async def translate_call(audio_stream, speaker_profile):
    async for segment in segment_speech(audio_stream):
        recognized = await recognize_japanese(segment)
        if not recognized.is_final:
            continue

        translated = await translate_to_english(recognized.text)

        async for audio_chunk in synthesize_english(
            translated.text,
            speaker_profile=speaker_profile,
        ):
            yield audio_chunk

この形だけでは、次の発話の認識と前の発話の再生を並行できません。

実装時は区間ごとのキューを用意し、順序を保ちながら、認識、翻訳、合成を重ねて動かします。

ただし、並行処理を増やすとキャンセルや順序逆転への対処も必要になるため、まず直列の処理で正しさを確認してから最適化します。

WebRTCとSIPを接続するときの注意点

アプリ同士の通話はWebRTC、既存の電話網との接続はSIPや電話事業者の回線を使う構成が考えられます。

両者をつなぐ場合は、音声形式の変換だけでなく、エコー、音量差、無音判定、切断、保留、番号入力を含む通話全体を確認します。

品質は処理ごとと会話全体の両方で測る

音声認識、翻訳、音声合成が個別に良くても、会話の目的を達成できるとは限りません。

例えば住所の一文字を誤るだけで配送確認は失敗しますが、雑談なら意味が通じる場合があります。

評価指標と確認したい内容
対象 指標の例 確認したい内容
音声認識 単語誤り率、固有名詞の正答 対象業務の言葉を文字にできるか
翻訳 人による意味評価、用語保持 依頼、否定、日時、数量が正しく伝わるか
音声合成 聞き取りやすさ、自然さ、話者類似度 通話回線でも無理なく聞けるか
応答時間 中央値、遅い側の分布、処理別時間 待ち時間の原因を特定できるか
会話 目的達成率、聞き返し回数、人への切替率 利用者が用件を完了できるか

テスト脚本には、レストラン予約、配送確認、氏名や住所の読み上げなど、失敗の影響が異なる場面を含めます。

評価結果は全体平均だけでなく、雑音、話速、端末、回線、固有名詞の種類ごとに分けます。

声と通話内容を守る運用

話者プロフィールは本人を識別し得る情報として慎重に扱います。

音声を集める前に、利用目的、保存するもの、保存期間、削除方法、利用できる人を説明し、同意を記録します。

録音や音声合成に関するルールは地域と利用場面で異なるため、公開前に対象地域の法令、契約、社内規程を確認します。

障害を前提に本番運用を設計する

平均値だけを監視すると、一部の利用者が経験する長い遅延を見落とします。

中央値と遅い側の分布を併記し、失敗した通話を個別に追える識別子を付けます。

段階的な導入手順

第1段階は会話とデータの定義

  1. 対象の通話場面を一つ選びます。
  2. 頻出する固有名詞、日時、数量、確認表現を集めます。
  3. 成功条件と、人へ切り替える条件を決めます。

第2段階は片方向の試作

  1. 音声認識、翻訳、標準音声による合成を直列でつなぎます。
  2. 実際の端末と回線で区間別の遅延と誤りを測ります。
  3. 辞書と分節を調整し、文字による確認画面を加えます。

第3段階は本人らしい声と双方向化

  1. 同意、登録、削除の手続きを実装します。
  2. 本人らしさと聞き取りやすさを別々に評価します。
  3. 片方向で基準を満たした後、相手側の英語から日本語への経路を追加します。

第4段階は本番運用

  1. 監視、通知、再試行、フォールバックを整備します。
  2. 小さな利用者群から開始し、会話の失敗例を分類します。
  3. 品質、遅延、費用、安全性を見ながら対象業務を広げます。

よくある質問

話者プロフィールを登録すれば、必ず本人と同じ声になりますか

同じ声になるとは限りません。

録音環境、発話内容、対象言語、合成方式によって結果が変わるため、本人らしさと聞き取りやすさを利用者評価で確認します。

遅延が大きい場合は何から確認しますか

通話全体の時間だけでなく、分節、音声認識、翻訳、音声合成、ネットワークの時間を分けて測ります。

発話の区切り待ちが長いのか、処理が遅いのかを判別してから、分節調整、近い処理拠点、軽い構成などを検討します。

翻訳精度を一つの点数だけで判断できますか

一つの点数だけでは判断できません。

固有名詞、否定、日時、数量が正しく伝わるかを会話脚本で確認し、最終的には用件を完了できたかで評価します。

掲載したコードをそのまま本番で使えますか

掲載例は処理の順序を示す骨格です。

本番では認証、権限、タイムアウト、再試行、切断、監視、データ保護を利用環境に合わせて実装します。

開発を始める前の確認事項

通話翻訳は、音声モデルだけで完成する機能ではありません。

最初の利用場面を狭く定め、会話の成功条件を測り、同意とフォールバックを組み込むことで、試作を運用可能なシステムへ近づけられます。

翻訳方式の違いを知りたい場合は、同時通訳サービスと逐次翻訳の違いを扱った比較記事も併せて読むと、製品利用と独自開発の論点を分けやすくなります。

この記事に関連する株式会社greedenの取り組み

通話翻訳の構想は、音声処理だけでなく、外部連携、同意管理、監視まで一つの運用として設計する必要があります。株式会社greedenは、要件整理から実装、テスト、リリース後の改善まで、Webシステム開発を一気通貫で支援します。

モバイルバージョンを終了