InterMINDを支える4つの翻訳パイプラインの内側

mind.com の旧ページ /product/overview/how-it-works は、現在の姿から数回のメジャーリリース分も古くなっています。このページは、多くのベンダーのページと同じように、単一の「翻訳エンジン」を説明していました。「あなたが話す」から「相手が聞く」へ向かう大きな矢印が一本あるだけの図です。2年前の時点でも、これは単純化しすぎた図でした。今では誤りです。

実際には、InterMINDは4つの独立した翻訳パイプラインを動かしています。それぞれ解く問題が異なり、エンジンも、レイテンシの許容値も、品質の範囲も異なります。共有しているのは言語ピッカーだけで、エンジンは共有していません。

これが「どのように動いているのか」への、更新された答えです。

関連記事: 「対応言語は何言語ですか?」では、各パイプラインがカバーする範囲(23 / 23 / 30 / 17)を扱っています。この記事では、各パイプラインが何をするのか、そしてなぜそれぞれが独立した存在なのかを説明します。

「すべてを一つのエンジンで」が嘘である理由

ライブのミーティングプラットフォームは、少なくとも4つの仕事を同時にこなす必要があり、それらは互いに相容れない方向へ引っ張り合います。

リアルタイム音声 — 音声を入力すると、話者がまだ話している間に翻訳された音声が出力され、すべての視聴者がそれぞれの言語で聞きます。厳しい制約はレイテンシです。
リアルタイムのチャットテキスト — 短いメッセージを素早く処理しつつ、編集、引用、HTML構造を保ちます。
リアルタイムの共有ノート — 1文字ずつの共同入力に対応し、構造的な階層(リスト、見出し、チェックボックス)を翻訳後も維持する必要があります。
非同期のドキュメントファイル — チャットに投下された40ページのPDFです。レイテンシの制約はありません。厳しい制約は忠実度で、書式、表、ページ番号、フォントが対象です。

この4つすべてをこなそうとする巨大なLLM呼び出しを1つ作ることもできます。私たちは試しましたが、4つとも不得意でした。音声のレイテンシ予算ではモデルは考える余裕がなく、ドキュメントの忠実度予算ではモデルが考えなければなりません。チャットの編集には閲覧者の言語での差分が必要で、40ページのPDFには、トークンをストリーミングするどのモデルにも提供できない書式の保持が必要です。

そこで私たちは4つを動かしています。以下がそれぞれの説明です。

パイプライン1:リアルタイム音声翻訳

問題: ある参加者がフランス語で話します。別の参加者はドイツ語、3人目はブラジルポルトガル語、4人目は日本語で参加しています。全員が、話者の声を自分の言語で、自分の耳に、アイコンタクトを保てるほど短い遅延で聞く必要があります。

予算: 聞き手が待たされてはいけません。翻訳された音声の遅れが、人が重ねて話し始めるほど大きくなると、ミーティングは「もう英語に切り替えよう」という方向へ流れていきます。

音声は実際にどう流れるか

音声翻訳パイプライン:話者のブラウザがWebRTC経由で自社エンジン(フランス・OVHにあるMind APIのメディアサーバー)に音声を送信し、ASRを実行して、ルームに存在するすべての対象言語へ翻訳します。各視聴者は自分用の翻訳音声トラックを受け取り、ws-serverは要約用に文字起こしの単語を受け取ります。

明示しておきたい点がいくつかあります。

ASRはメディアサーバー上で動作します。 話者の音声はWebRTCを通じて自社エンジン(フランス・OVHにあるMind API)に届き、通話を運んでいる同じサーバー上で認識されます。ブラウザは音声を送り、言葉を受け取るだけです。別の音声ベンダーは介在せず、翻訳開始までに余計な中継もありません。(チャットのボイスノートは例外で、その音声のテキスト化には、デフォルトのAIゲートウェイの音声サービスであるAzure AI Speechを使います。)
翻訳は一括のファンアウトではありません。 エンジンは視聴者ごとではなく、ルームに存在する対象言語ごとに翻訳します。ある言語への翻訳は、その言語の最初の聞き手が翻訳ストリームを要求した時点で始まります。ドイツ語を選んだ3人の参加者は1つのドイツ語翻訳を共有し、アラビア語で聞いている人がいなければ、アラビア語への翻訳は行われません。そのため、4言語のミーティングと40言語のミーティングは、実際に誰が参加したかという範囲で同じコストになります。誰も聞いていない言語には翻訳しません。
合成音声は視聴者ごとです。 各参加者は、元の話者の映像にミックスされた、自分専用の翻訳音声トラックを受け取ります。「翻訳済みのマスターミーティング」を見ているのではなく、同じミーティングを見ていて、個人の音声チャンネルだけが選んだ言語に翻訳されています。だから、同じ部屋にいる2人がそれぞれヘッドホンを付けて、別々の言語を聞くこともできます。

8言語が参加する60分の通話では、さまざまな不具合が起こります。WebSocketの切断、ASRによる固有名詞の一時的な誤認識、参加者の1人のネットワークの不安定化などです。上記のアーキテクチャのおかげで、障害を切り分けられます。ある視聴者の音声に不具合が出ても、残り7人には影響しません。翻訳エンジンはそもそも「唯一の翻訳」を作っておらず、8つを並列に作っていて、影響を受けた1つだけが復旧すればよいからです。

エンジン自体は自社製で、自社のインフラ上でホストしています。リアルタイム音声を、サードパーティの汎用LLMには通しません。レイテンシの予算がそれを許さず、データレジデンシーの観点から、実際にそれを重視する規制対象のお客様にも適さないためです。

音声品質について公開していること: /benchmarkでは、公開されているすべての言語ペアについて、本番の音声パイプラインをFLORES-200の文に対して毎月実行しています。評価者は明示されています(主にGemini 3.7 Flash、代替としてClaude Sonnet 5)。中央値、p10、p90、最小値、最大値、サンプルサイズといった分布の全体がページに掲載されています。これらの数値が何を測り、何を測らないかについては、方法論をご覧ください。

パイプライン2:リアルタイムチャット翻訳

問題: ミーティング内のすべてのチャットメッセージを、送信されると同時に、すべての参加者にそれぞれの言語で翻訳します。さらに編集もあり、編集は再翻訳ではなく編集として見える必要があります。

予算: 音声より緩やかです。チャットメッセージが別の言語で少し遅れて表示されても、誰も気にしません。人が気にするのは、翻訳が正しいか、そして編集が理解できるかどうかです。

チャットパイプラインが実際に行うこと

各メッセージは、音声パイプラインが使うのと同じ翻訳エンジンを通りますが、前処理と後処理が異なります。

HTML構造は保持されます。 チャットはリッチテキスト(段落、リスト、引用、太字、斜体)に対応しています。モデルに渡す際にはプレーンテキストに変換して翻訳し、結果を元のタグで包み直します。モデルがHTMLを目にすることはなく、見るのはきれいな文章だけです。
引用は独立して翻訳されます。 メッセージに返信して引用すると、[QUOTE]…[/QUOTE] ブロックと新しい内容は別々の単位として翻訳されるため、モデルが両者を混同することはありません。
長いメッセージは分割されます。 段落の境界で、1チャンクあたり1,000文字に分割します。各チャンクがそれぞれ1回の翻訳呼び出しです。4,000文字の長文を一度にモデルへ渡すことはしません。切り詰め、段落の欠落、文の途中での途切れといった失敗は、あまりにひどいからです。
翻訳は遅延実行です。 IntersectionObserverを使い、メッセージがビューポートにスクロールして入ったときに初めて翻訳します。以前は、長く続くチャンネルで言語を切り替えると、履歴にあるすべての翻訳API呼び出しが再実行されていました。今はそうなりません。

興味深い部分:差分としての編集

v1.2で、別の言語の閲覧者に対するチャット編集の挙動を変えました。以前の挙動は、誰かがメッセージを編集するとメッセージ全体を再翻訳し、新しい段落が表示されるので、何が変わったのかを自分で探す必要があるというものでした。

新しい挙動は次のとおりです。

元のメッセージは、すでにあなたの言語に翻訳されています。
送信者が編集すると、新しいバージョンを再翻訳します。
あなたの以前の翻訳とあなたの新しい翻訳の差分を、あなたの言語で計算します。
その差分をインラインで表示します。Gitが変更点を見せるのと同じ方法です。

たとえば英語で「review by Tuesday」が「review by Thursday」に変わると、スペイン語で読んでいる同僚には、再翻訳された段落を読み直す代わりに、martes → jueves がハイライトされて表示されます。

これには、チャットのパイプラインを、リクエストのたびに翻訳するステートレスなエンドポイントではなく、閲覧者ごとのステートフルなキャッシュとして扱う必要がありました。ドキュメントと音声にはこれは不要ですが、チャットには必要です。

パイプライン3:リアルタイム共有ノート翻訳

問題: ホストが共有ノートのペインを開いて入力を始めます。すべての参加者が、見出し、入れ子のリスト、チェックリスト、コードブロックといったドキュメントの構造を保ったまま、自分の言語のノートを1文字ずつ見ます。

予算: チャットと同じですが、追加の制約が2つあります。

翻訳対象が翻訳の最中に変化します。 ホストはまだ入力中です。キーストロークのたびに「ドキュメント全体」を翻訳する素朴なシステムでは、ちらつきが生じ、APIの予算も消費します。私たちはドキュメント全体ではなく、変更された単位の粒度で翻訳します。
構造が維持されなければなりません。 入れ子のリストが3つあるMarkdownの塊をそのまま翻訳モデルに渡すと、元のように見えるものが返ってきますが、階層が微妙に平坦化されたり、項目が番号を振り直されたり、インデントが移動したりします。そのため、モデルに塊全体を見せることはしません。

ノートのパイプラインがチャットとどう違うか

構造の保持が最大のポイントです。ドキュメント全体ではなく、各リスト項目を個別に翻訳します。モデルが見るのは次のものです。

"コンプライアンスレビュー — 第2四半期の成果物"

次のようなものではありません。

"# Project plan\n## Quarter\n- Compliance review — Q2 deliverables\n- Vendor scoring\n - Tier 1 vendors..."

外側のドキュメント、つまり <ul>、見出し、インデントは、元のドキュメントと同じ構造を使ってクライアント側で再構築され、各リーフノードが翻訳に置き換えられます。モデルが階層を「改善」してしまうことはありません。

ノートでも、チャットの編集と同じ、閲覧者ごとの差分モデルを使います。ホストが1行を変更すると、他の言語の閲覧者には、新しい段落ではなく変更された単語がハイライトされて表示されます。

パイプライン4:非同期ドキュメント翻訳

問題: 誰かが40ページのPDF、Word文書、PowerPointのスライド、Excelシートをチャットに投下します。各参加者は、自分の言語でのコピーをリクエストできます。翻訳後のファイルは、フォント、表、ページ番号、ヘッダー、グラフの配置まで、元のファイルと同じ見た目でなければなりません。

予算: リアルタイムの制約はありません。1分でも、2分でも構いません。制約は忠実度です。翻訳されたPDFが元のファイルと同じ見た目でなければ、受け取った人は信頼しません。

なぜこのパイプラインは音声とエンジンを共有しないのか

汎用のLLMは、たとえ非常に優秀でも、ドキュメントの翻訳されたテキストを返します。同じレイアウトの翻訳されたPDFは返せません。モデルには「元と揃える必要があるページ区切り」や「列幅を保つ必要がある表のセル」という概念がありません。

この領域には、DeepL Document APIを直接使っています。これは、ファイルから抽出された文章ではなく、ファイルをファイルとして翻訳するために作られたものです。DeepLが扱うのは次の形式です。

PDF(レイアウトを保持)
DOCX、DOC
PPTX
XLSX

ドキュメントはDeepLのパイプラインにアップロードされ、サーバー側で書式を保ったまま翻訳されて、同じ形式で返されます。その結果を自社のオブジェクトストレージにアップロードし、ダウンロード可能な添付ファイルとしてチャットに表示します。

これにかかるコストと、それを隠さない理由

DeepLは、ドキュメント1件あたり最低50,000文字を課金します。Proティアでおよそ1米ドルで、ドキュメントが1ページでも30ページでも変わりません。このコストは、ファイルごとに請求するのではなく、私たちが負担しています。ミーティングの翻訳使用量には課金文字数として表示され、製品の他の部分が翻訳アクティビティを報告する方法に合わせて、単語単位に換算されます。

この領域にDeepLを選んだのは、ファイルをファイルとして翻訳することがまさにDeepLの本業であり、それより優れたものを自作しようとはしなかったからです。逆は成り立ちません。DeepLは、私たちがミーティング向けに作ったようなライブ音声のパイプラインを動かしてはいません。問題が違えば、道具も違います。「InterMINDの翻訳は何で動いているのか」への誠実な答えは、「パイプラインごとに適したエンジン」であり、「あらゆる場面で自社エンジン」ではありません。

このパイプラインがカバーし、音声がカバーしない言語

ドキュメントのパイプラインは30言語に対応しており、音声は23言語です。追加分には、ブルガリア語、ギリシャ語、エストニア語、インドネシア語、リトアニア語、ラトビア語、スロバキア語、スロベニア語が含まれます。(アラビア語もこのリストに入っており、追加分の1つです。音声品質が基準を下回っている間、リアルタイムのピッカーからは外されていますが、言語ペアごとのスコアは/benchmarkで公開され続けており、その数値が復帰の決め手になります。ヒンディー語では逆方向の非対称性があり、音声では利用可能ですが、ファイルではまだ対応していません。)

この非対称性は実在します。つまり、ミーティングに参加しているフランス語話者は、エストニア語でミーティングを聞くことはできなくても、契約書のPDFをエストニア語でリクエストできます。私たちは、単一の数字でならして見せるのではなく、ピッカーでこれを明示しています。その考え方は対応言語数についての記事で説明しています。

パイプラインが交わるところ

4つのパイプラインは、孤立して動いているわけではありません。ミーティングルームは、それらが互いに触れ合う場所であり、その継ぎ目が重要です。

ドキュメントが添付されたチャットメッセージでは、テキストにはチャットのパイプラインが、ファイルにはドキュメントのパイプラインが動作します。別の言語の参加者は、メッセージが即座に翻訳されて表示され、添付ファイルの翻訳は非同期でダウンロード可能な形で届きます。
文字起こしの1行を引用した共有ノートは、ノートと音声をまたぎます。文字起こしは、音声パイプラインが送信者の言語向けに生成したものです。ノートの翻訳は、その引用の閲覧者ごとのコピーを、他のすべての人の言語で、出典の表記を保ったまま作ります。
ミーティング後にエクスポートされる文字起こしでは、会話全体に対してチャットと同様のテキストパイプラインが動作し、参加者がダウンロードできる言語別のファイルを生成します。これはチャット翻訳と同じコードパスで、バッチ処理されているだけです。

言語ピッカーはUIの1つの部品です。その下にあるインフラは、互いに連携する4つのパイプラインです。

意図的に試みないこと

「統合翻訳モデル」は作りません。 音声、チャット、ノート、ドキュメントを1つのモデルでこなすものは作っていません。レイテンシと忠実度のトレードオフに、勝者はいません。私たちは、領域ごとに適したエンジンを使います。
黙ってルーティングし直すことはしません。 ファイルのパイプラインが現時点でヒンディー語に翻訳できない場合、音声エンジンにこっそり切り替えて、うまくいったふりをすることはしません。ファイルのピッカーが、隠さずにそのギャップを示します。
「200言語に翻訳します」とは言いません。 私たちのエンジンが出力するのは24言語です。ライブの領域は23言語、ドキュメントは30言語で、マーケティング向けの1つの数字ではなく、監査人の前でも通用すべき言語ペアごとの品質を、弱いペアも含めて/benchmarkで公開しています。

ご自身でお試しください

ライブデモを試す — ライブ音声パイプラインを、あなたの音声に対して、23ある製品対応言語のいずれかで実行します。/benchmarkのスコアを出しているのと同じパイプラインです。
ベンチマークを見る — 実際のトラフィックに基づく、言語ペアごと・月ごとの品質です。ピッカーにあるすべてのペアが、強いものも弱いものも、ディープリンクで参照できます。
方法論を読む — 数値が何であり、何ではないのか、評価者は誰なのかを説明しています。