InterMINDを駆動する4つの翻訳パイプラインの内部

mind.comの古い/product/overview/how-it-worksページは、すでに何回かのメジャーリリース分も時代遅れになっています。多くのベンダーのページと同じように、単一の「翻訳エンジン」を説明しており、「あなたが話す」から「彼らが聞く」への大きな矢印が1本引かれています。その図は2年前にはすでに単純化されすぎていました。今日ではそれは間違っています。

実際のところ、InterMINDは4つの個別の翻訳パイプラインを実行しており、それぞれが異なるエンジン、異なるレイテンシ予算、異なる品質エンベロープによって異なる問題を解決しています。それらは言語ピッカーを共有していますが、エンジンは共有していません。

これが、「どのように機能するのか」という問いに対する最新の回答です。

関連記事: 「何言語サポートしていますか？」 は、各パイプラインがカバーする範囲（23 / 23 / 30 / 17）について解説しています。本記事では、各パイプラインが何をするのか、そしてなぜそれぞれが独立した存在なのかについて解説します。

「すべてを1つのエンジンで」というアプローチが嘘である理由

リアルタイムのミーティングプラットフォームには、少なくとも同時にこなさなければならない4つのジョブがあり、それらは互いに矛盾する方向に引っ張り合います：

1. リアルタイムの音声 — 音声を入力し、翻訳された音声を出力します。1秒未満で、すべての視聴者がそれぞれの言語で聞けます。厳しい制約となるのはレイテンシです。
2. リアルタイムのチャットテキスト — 短いメッセージを高速に処理し、編集、引用、HTML構造を保持します。
3. リアルタイムの共有ノート — 文字ごとの共同タイピングであり、翻訳後も維持されなければならない構造的階層（リスト、見出し、チェックボックス）が含まれます。
4. 非同期のドキュメントファイル — チャットにドロップされた40ページのPDFなど。レイテンシの予算はありません。厳しい制約は忠実度です — フォーマット、表、ページ番号、フォントがこれにあたります。

この4つすべてをこなそうとする巨大な1つのLLM呼び出しを構築することもできます。私たちも試みました。しかしそれは、4つすべてにおいて下手でした。音声のレイテンシ予算は、モデルが「考える」ことを許しません。ドキュメントの忠実度予算は、モデルが「考えなければならない」ことを意味します。チャットの編集には視聴者の言語での差分（diff）が必要ですが、40ページのPDFにはトークンストリーミングモデルでは提供できないフォーマット保持が必要です。

そこで私たちは4つを実行しています。それぞれのパイプラインを紹介します。

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

課題: ある参加者がフランス語を話します。別の参加者はドイツ語で参加し、3人目はブラジルポルトガル語、4人目は日本語です。それぞれが、アイコンタクトが可能な状態を保てるほど十分に短い遅延で、自分の言語で、自分のイヤホンで話し手の声を聞く必要があります。

予算: エンドツーエンドで1秒未満です。約1.2秒を超えると会話が崩壊し、人々は翻訳の上から話し始め、ミーティングは「とりあえず英語に切り替えよう」という方向に流れていきます。

音声の実際の動き

明確にしておくべき価値のある点がいくつかあります：

• ASRはメディアサーバーで実行されます。 話し手の音声はWebRTC経由で私たちの独自エンジン — フランスのOVHにあるMind API — に送られ、通話を担うのと同じサーバー上で認識されます。ブラウザは音声を送信し、テキストを受け取るだけです。翻訳が開始される前に別の音声ベンダーを経由したり、余分なホップが発生したりすることはありません。（チャットの音声メモは例外で、これらの文字起こしはデフォルトのAIゲートウェイの音声サービスであるAzure AI Speechで実行されます。）
• 翻訳は1つのファンアウトではありません。 エンジンは、視聴者ごとではなくルーム内に存在するターゲット言語ごとに翻訳します。ある言語への翻訳は、その言語の最初のリスナーが翻訳ストリームを要求したときに開始されます。ドイツ語を選択した3人の参加者は1つのドイツ語翻訳を共有し、アラビア語で聞いている人がいなければ、アラビア語には何も翻訳されません。このため、4言語のミーティングのコストは、40言語のミーティングのコストと、実際に誰が参加したかという点までは同じになります — 参加者が誰も聞いていない言語に翻訳することはないからです。
• 合成音声は視聴者ごとに提供されます。 各参加者は、元の話し手の映像とミックスされた独自の翻訳音声トラックを受信します。彼らはマスターの「翻訳されたミーティング」を見ているのではなく、個人のオーディオチャネルが選択した言語に翻訳された同じミーティングを見ています。そのため、同じ物理的な部屋にいる2人がそれぞれヘッドホンを装着し、異なる言語を聞くことができるのです。

ミーティングが予期せぬ方向に向かった時に重要になる理由

8言語の60分の通話では、予期せぬ形で問題が発生することがあります。WebSocketが切断されたり、ASRが一時的に固有名詞を誤って文字起こししたり、ある参加者のネットワークが不安定になったりします。上記のアーキテクチャによって、私たちは障害を分離できます。ある視聴者の音声がグリッチしても、他の7人には影響しません。なぜなら、翻訳エンジンはそもそも「単一の翻訳」を生成したわけではなく、8つの翻訳を並行して生成しており、影響を受けた1つだけを復旧させればよいからです。

エンジン自体は私たちが所有し、独自のインフラストラクチャでホストしています。リアルタイムの音声をサードパーティの汎用LLMにルーティングすることはありません。レイテンシの予算がそれらを排除しますし、データ保存場所に関する要件が、それを実際に気にする規制対象の顧客にとってそれらを排除します。

音声品質について私たちが公開していること: /benchmarkでは、毎月、公開しているすべての言語ペアに対して、本番環境の音声パイプラインをFLORES-200の文で実行しています。審査員（Gemini 3.7 Flashをメイン、Claude Sonnet 5をフォールバック）を明記しています。分布の全容（中央値、p10、p90、最小値、最大値、サンプルサイズ）をページに掲載しています。これらの数値が何を測定し、何を測定しないのかについては、手法のページを参照してください。

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

課題: ミーティング内のすべてのチャットメッセージを、送信された瞬間に、各参加者の言語に翻訳します。加えて、編集です — 編集は再翻訳のように見えるのではなく、編集として見えなければなりません。

予算: 高速ですが、サブ秒ではありません。チャットメッセージが別の言語で表示されるまでに0.5秒かかっても、誰も気にしません。人々が気にするのは、翻訳が正確かどうか、そして編集内容が意味をなすかどうかです。

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

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

• HTML構造が保持されます。 チャットはリッチテキスト（段落、リスト、引用、太字、斜体）をサポートしています。モデル用にプレーンテキストに変換し、翻訳してから、元のタグで結果を再ラップします。モデルはHTMLを見ることはありません — クリーンなテキストのみを見ます。
• 引用は独立して翻訳されます。 メッセージに返信して引用する場合、[QUOTE]…[/QUOTE]ブロックと新しいコンテンツは別々のユニットとして翻訳されるため、モデルが両者を混同することはありません。
• 長いメッセージはチャンク分割されます。 1,000文字ごとのチャンクで段落の境界に分割します。各チャンクは独自の翻訳呼び出しになります。4,000文字の小説を一度にモデルに投入することはありません — その失敗モード（切り捨て、段落の欠落、文中での途絶）はひどすぎるからです。
• 翻訳は遅延評価されます。 IntersectionObserverを使用しており、メッセージが視聴者のビューポートにスクロールインしたときにのみ翻訳されます。長時間実行されているチャネルで言語を切り替えると、以前は履歴からすべての翻訳API呼び出しが再生されていました。今は違います。

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

v1.2で、別の言語の視聴者に対するチャット編集の動作を変更しました。以前の動作は、誰かがメッセージを編集すると全体を再翻訳し、新しい段落が表示され、何が変更されたかを見つけなければならないというものでした。

新しい動作：

1. 元のメッセージはすでにあなたの言語に翻訳されています。
2. 送信者が編集した際、新しいバージョンを再翻訳します。
3. あなたの言語で、以前の翻訳と新しい翻訳の間の差分（diff）を計算します。
4. Gitが変更点を表示するのと同じように、その差分をインラインで表示します。

そのため、英語で「review by Tuesday」が「review by Thursday」に変更された場合、スペイン語で読んでいる同僚は、読み直さなければならない再翻訳された段落ではなく、martes → juevesがハイライトされているのを見ます。

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

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

課題: ホストが共有ノートウィンドウを開き、入力を開始します。すべての参加者が、文字単位で自分の言語のノートを見ることができます。ドキュメントの構造（見出し、ネストされたリスト、チェックリスト、コードブロック）はそのまま維持されます。

予算: チャットと同じ（約0.5秒）ですが、さらに2つの制約があります：

• 翻訳中の対象が翻訳中に変化します。 ホストはまだ入力しています。各キーストロークで「ドキュメント全体」を翻訳する単純なシステムは、ちらつきを発生させ、API予算を消費してしまいます。私たちはドキュメント全体ではなく、変更されたユニットの粒度で翻訳します。
• 構造が維持されなければなりません。 3つのネストされたリストを含むmarkdownの塊を翻訳モデルに翻訳させると、元のもののように見えるものが返ってきますが、階層が微妙に平坦化されたり、アイテムの番号が振り直されたり、インデントが移動したりしています。私たちはモデルに塊全体を見せることはありません。

ノートパイプラインがチャットと異なる点

構造の維持が主なポイントです。私たちは1つのドキュメントとしてではなく、各リストアイテムを独立して翻訳します。モデルが見るのは：

"コンプライアンスレビュー — Q2納品物"

— ではなく：

"# プロジェクト計画\n## 四半期\n- コンプライアンスレビュー — Q2納品物\n- ベンダーのスコアリング\n - Tier 1ベンダー..."

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

ノートはチャット編集と同じ視聴者ごとの差分モデルを使用します。ホストが行を変更した場合、他の言語の視聴者は新しい段落ではなく、変更された単語がハイライトされた状態を見ます。

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

課題: 誰かが40ページのPDF、Word文書、PowerPointスライド、またはExcelシートをチャットにドロップします。各参加者は自分の言語でコピーを要求できます。翻訳されたファイルは、元のファイルと同じように見えなければなりません — 同じフォント、同じ表、同じページ番号、同じヘッダー、同じ場所に同じチャートがある状態です。

予算: リアルタイムの制約はありません。1分でも構いません。2分でも構いません。制約は忠実度です — 翻訳されたPDFが元の文書と同じように見えなければ、受信者は信頼しません。

このパイプラインが音声とエンジンを共有しない理由

汎用LLMは、どんなに優れていても、ドキュメントの翻訳されたテキストを返してくるだけです。同じレイアウトで翻訳されたPDFを返してくれるわけではありません。モデルには「ソースと一致させなければならない改ページ」や「列幅を維持しなければならない表のセル」といった概念がありません。

このサーフェス（画面・機能）に対しては、DeepL Document APIを直接使用します。これはファイルから抽出されたテキストではなく、ファイルとしてのファイルを翻訳するために特別に構築されたものです。DeepLは以下を処理します：

• PDF（レイアウト保持）
• DOCX, DOC
• PPTX
• XLSX

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

コストと、それを隠さない理由

DeepLはドキュメントごとに最低50,000文字を請求します — これはProティアでファイルあたり約1米ドルに相当し、ドキュメントが1ページでも30ページでも同じです。私たちはファイルごとに課金するのではなく、このコストを吸収します。これはミーティングの翻訳利用量に請求文字数として表示され、製品の他の部分が翻訳アクティビティを報告する方法と一致するワード単位に変換されます。

私たちがこのサーフェスにDeepLを選んだのは、ファイルとしてのファイルを翻訳することが、まさにDeepLが構築された目的のジョブだからです — 私たちはより優れたものを独自に構築しようとはしませんでした。逆の場合は同じではありません — DeepLは私たちがミーティングのために構築したようなリアルタイム音声パイプラインを実行しません。問題は異なり、ツールも異なります。「InterMINDの翻訳を支えているもの」の正直な答えは、「パイプラインごとに適切なエンジン」であって、「どこでも私たちのエンジン」ではありません。

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

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

その非対称性は現実のものです。これは、ミーティング内のフランス語の参加者が、会議をエストニア語で聞くことはできなくても、契約書PDFをエストニア語で要求できることを意味します。私たちはそれを1つの数字で丸めるのではなく、ピッカーで明示します。その理由については言語数の記事に書かれています。

パイプラインが交わる場所

4つのパイプラインは独立して実行されるわけではありません。ミーティングルームはそれらが互いに触れ合う場所であり、その境界（シーム）が重要になります：

• ドキュメントの添付されたチャットメッセージは、テキストに対してチャットパイプラインを、ファイルに対してドキュメントパイプラインをトリガーします。別の言語の参加者は、メッセージが即座に翻訳されるのを見て、添付ファイルの翻訳が非同期でダウンロード可能なものとして届くのを見ます。
• トランスクリプトの行を引用した共有ノートは、ノート↔音声を横断します。トランスクリプトは音声パイプラインが送信者の言語のために生成したものであり、ノート翻訳はその引用のコピーを他の全員の言語で視聴者ごとに生成し、そのソース属性（出典）を保持します。
• ミーティング後にエクスポートされたトランスクリプトは、会話全体に対してチャット形式のテキストパイプラインを実行し、参加者がダウンロードできる言語ごとのファイルを生成します。これはチャット翻訳と同じコードパスですが、バッチ処理されているだけです。

言語ピッカーはUIの1つの要素です。その下にあるインフラストラクチャは、互いに通信し合う4つのパイプラインです。

私たちが意図的に行わないこと

• 「統合された翻訳モデル」はありません。 私たちは音声、チャット、ノート、ドキュメントを行う1つのモデルを構築していません。レイテンシと忠実度のトレードオフに勝者はいません。私たちはサーフェスごとに適切なエンジンを使用します。
• サイレントな再ルーティングはありません。 今日、ファイルパイプラインがヒンディー語に翻訳できない場合、音声エンジンに静かにフォールバックしてうまくいったふりをすることはありません — ファイルピッカーはそのギャップを隠すのではなく、フラグを立てます。
• 「200言語に翻訳します」という言葉はありません。 私たちのエンジンが生成するのは24言語です。ライブサーフェスは23言語、ドキュメントは30言語を出荷しており — マーケティングに都合の良い単一の数字の代わりに、監査人の前に立たなければならない言語ペアごとの品質が/benchmarkで公開されており、弱いペアも含まれています。

実際に試してみる

• ライブデモを試す — 23の製品言語のいずれかで、あなたの音声に対してライブ音声パイプラインを実行します。これは/benchmarkでスコアを計測しているのと同じパイプラインです。
• ベンチマークを見る — 実際のトラフィックでの言語ペアごと、月ごとの品質。ピッカー内のすべてのペア（強いものも弱いものも）にディープリンクできます。
• 手法を読む — 数値が何であり、何ではなく、審査員が誰なのか。

4つのパイプライン、4つのエンジン、1つのミーティングルーム。これが古いhow-it-worksページに代わる正直な回答です。

— Mind.com チーム

情報源: DeepL — サポートされている言語, DeepL — 使用量と請求（ファイルごとの最低50,000文字）, FLORES-200; 内部パイプラインの事実は出荷されたコードに対して検証されており、2026年8月に確認されています。