InterMINDを動かす4つの翻訳パイプラインの内部
mind.comの古い/product/overview/how-it-worksページは、すでにいくつかの主要なリリースで時代遅れになっています。そこでは、多くのベンダーのページと同じように、単一の「翻訳エンジン」として説明されています。「あなたが話す」から「彼らが聞く」への大きな矢印が1本描かれているだけです。その図は2年前の時点ですでに簡略化されていましたが、今日では誤りです。
実際には、InterMINDは4つの独立した翻訳パイプラインを実行しており、それぞれが異なるエンジン、異なるレイテンシ予算、異なる品質エンベロープで異なる問題を解決しています。これらは言語ピッカーを共有していますが、エンジンは共有していません。
これが「どのように動作するのか」という問いに対する最新の回答です。
関連記事: "何言語サポートしていますか？" では、各パイプラインがカバーする内容（24 / 24 / 30 / 17）について解説しています。本記事では、各パイプラインが何をするのか、そしてなぜそれが独立した存在なのかを解説します。
「すべてを1つのエンジンで」が嘘である理由
ライブミーティングプラットフォームには、少なくとも同時にこなすべき4つのタスクがあり、それらは互いに矛盾する方向へ引っ張り合います：
- リアルタイム音声 — 音声を入力し、翻訳された音声を1秒未満で出力し、すべての視聴者をそれぞれの言語で対応します。最大の制約はレイテンシです。
- リアルタイムチャットテキスト — 短いメッセージ、高速、編集や引用、HTML構造が保持されます。
- リアルタイム共有ノート — 文字ごとの共同タイピング。翻訳後も維持される必要がある構造的階層（リスト、見出し、チェックボックス）を伴います。
- 非同期ドキュメントファイル — チャットにドロップされた40ページのPDF。レイテンシ予算はありません。最大の制約は忠実度 — フォーマット、表、ページ番号、フォントです。
1つの巨大なLLM呼び出しでこれら4つすべてをこなそうとすることは可能です。私たちも試みました。しかしそれは、どれにも不向きでした。音声のレイテンシ予算が意味するのは、モデルに思考する余裕がないということです。一方、ドキュメントの忠実度予算が意味するのは、モデルが思考しなければならないということです。チャットの編集には視聴者の言語での差分（diff）が必要ですが、40ページのPDFにはトークンストリーミングモデルでは提供できないフォーマット保持が必要です。
そこで私たちは4つ実行しています。それぞれについて説明します。
パイプライン1：リアルタイム音声翻訳
課題： ある参加者がフランス語で話します。別の参加者はドイツ語、3人目はブラジルポルトガル語、4人目は日本語で参加しています。それぞれが、アイコンタクトが可能な状態を保てるほど十分に短い遅延で、自分の言語で、自分の耳で話者を聞く必要があります。
予算： エンドツーエンドで1秒未満。~1.2秒を超えると会話が崩壊し、翻訳に被せて話し始めたり、ミーティングが「とりあえず英語に切り替えよう」という方向に向かっていき始めます。
音声が実際にどのように移動するか
明示的に言及しておくべき点がいくつかあります：
- ASRは話者のブラウザで実行されます。中央サーバーではなく、Mind SDKをローカルで使用します。これによりラウンドトリップが節約され、翻訳が開始される前に可能な限り低い遅延でソース言語のトランスクリプトが得られます。
- 翻訳は1つのファンアウトではありません。 翻訳エンジンへのWebSocket接続のプールを保持しており、ルーム内に存在するターゲット言語ごとに1つの接続を確立します。3人の参加者がドイツ語を選択した場合、ドイツ語は1つの接続を共有します。アラビア語を選択した人がいなければ、アラビア語の接続は開かれません。プールは5分後にアイドル接続を切断します。このため、4言語のミーティングも、実際に誰が参加したかという点までは40言語のミーティングと同じコストになります。参加者が誰も聞いていない言語に翻訳することは決してないからです。
- 合成音声は視聴者ごとに提供されます。 各参加者は、元の話者の映像とミックスされた独自の翻訳音声トラックを受信します。彼らはマスターの「翻訳されたミーティング」を見ているのではなく、個人のオーディオチャンネルが選択した言語に翻訳された同じミーティングを見ています。そのため、同じ物理ルームにいる2人がそれぞれヘッドフォンを差し込み、異なる言語を聞くことができるのです。
ミーティングで問題が起きた場合にこれが重要な理由
8言語の60分の通話において、事態は興味深い形で壊れます：WebSocketが切断されたり、ASRが一時的に固有名詞を誤って転記したり、ある参加者のネットワークがジッターを起こしたりします。上記のアーキテクチャにより、私たちは障害を分離できます：ある視聴者の音声がグリッチしても他の7人には影響しません。なぜなら、翻訳エンジンはそもそも「1つの翻訳」を生成したわけではなく、8つの翻訳を並行して生成しており、影響を受けた1つだけを復旧させればよいからです。
エンジン自体は私たちが所有し、独自のインフラストラクチャでホストしています。リアルタイム音声をサードパーティの汎用LLMにルーティングすることはありません。レイテンシ予算がそれらを排除し、データ常駐の観点が、それを実際に重視する規制対象の顧客にとってそれらを排除します。
音声品質について私たちが公開していること： /benchmarkでは、公開しているすべての言語ペアについて、本番環境の音声パイプラインをFLORES-200の文に対して毎月実行しています。評価者は明記されています（プライマリ：Gemini 2.5 Flash、フォールバック：Claude Sonnet 4）。中央値、p10、p90、最小値、最大値、サンプルサイズを含む完全な分布がページに記載されています。これらの数値が何を測定し、何を測定しないかについては、方法論を参照してください。
パイプライン2：リアルタイムチャット翻訳
課題： ミーティング内のすべてのチャットメッセージを、送信された瞬間に、すべての参加者に対してそれぞれの言語に翻訳すること。さらに編集 — 編集は再翻訳ではなく、編集として見えなければなりません。
予算： 高速ですが、サブセコンド（1秒未満）ではありません。チャットメッセージが別の言語で表示されるまでに0.5秒かかっても誰も気にしません。人々が気にするのは、翻訳が正しいかどうか、そして編集が意味をなすかどうかです。
チャットパイプラインが実際に行うこと
各メッセージは、音声パイプラインが使用するのと同じ翻訳エンジンを通りますが、前処理と後処理が異なります：
- HTML構造が保持されます。 チャットはリッチテキスト（段落、リスト、引用、太字、斜体）をサポートしています。モデルのためにプレーンテキストに変換し、翻訳してから、結果を元のタグで再ラップします。モデルはHTMLを見ることはありません。クリーンな散文を見るだけです。
- 引用は独立して翻訳されます。 メッセージに返信して引用する場合、
[QUOTE]…[/QUOTE]ブロックと新しいコンテンツは別々のユニットとして翻訳されるため、モデルが両者を混同することはありません。 - 長いメッセージはチャンク化されます。 段落の境界でチャンクあたり1,000文字に分割します。各チャンクは独自の翻訳呼び出しです。4,000文字の小説を一度にモデルに入力することはありません — その失敗モード（切り捨て、段落の欠落、文中での切断）は見苦しすぎます。
- 翻訳は遅延して行われます。 IntersectionObserverを使用しており、メッセージが視聴者のビューポートにスクロールされたときにのみ翻訳されます。長時間実行されているチャネルで言語を切り替えると、以前は履歴からすべての翻訳API呼び出しが再生されていました。今は違います。
興味深い部分：差分としての編集
v1.2で、別の言語の視聴者に対するチャット編集の動作を変更しました。以前の動作は、誰かがメッセージを編集すると全体を再翻訳し、新しい段落が表示されて何が移動したかを見つける必要がありました。
新しい動作：
- 元のメッセージはすでにあなたの言語に翻訳されていました。
- 送信者が編集した際、新しいバージョンを再翻訳します。
- あなたの言語で、前の翻訳と新しい翻訳の差分を計算します。
- その差分をインラインで表示します — 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は私たちがミーティングのために構築したようなライブ音声パイプラインを実行しません。問題は異なり、ツールも異なります。「InterMINDの翻訳を支えるもの」の正直なバージョンは「パイプラインごとに適切なエンジン」であり、「すべてを当社のエンジンで」ではありません。
このパイプラインがカバーし、音声がカバーしない言語
ドキュメントパイプラインは30言語に到達し、音声は24言語です。追加される言語には、ブルガリア語、ギリシャ語、エストニア語、インドネシア語、リトアニア語、ラトビア語、スロバキア語、スロベニア語が含まれます。（アラビア語は、音声品質が当社の基準を下回っていたため、以前はこのリストに含まれていましたが、現在はリアルタイムピッカーに含まれており、他のすべての言語と同様に、そのペアごとのスコアが/benchmarkで公開されています。現在、ヒンディー語については非対称性が逆転しており、音声ではライブですが、ファイルではまだ利用できません。）
その非対称性は現実のものです。これは、ミーティング内のフランス語の参加者が、ミーティングをエストニア語で聞くことはできなくても、契約書PDFをエストニア語で要求できることを意味します。私たちは、1つの数字でごまかすのではなく、ピッカーでそれをフラグとして表示します。その理由については、言語カウントの投稿を参照してください。
パイプラインが交わる場所
4つのパイプラインは孤立して実行されるわけではありません。ミーティングルームはそれらが互いに触れ合う場所であり、その境界は重要です：
- ドキュメント添付付きのチャットメッセージは、テキストに対してチャットパイプラインをトリガーし、ファイルに対してドキュメントパイプラインをトリガーします。別の言語の参加者には、メッセージが即座に翻訳されて表示され、添付ファイルの翻訳はダウンロード可能なものとして非同期的に到着します。
- トランスクリプトの行を引用する共有ノートは、ノートと音声の間を横断します。トランスクリプトは音声パイプラインが送信者の言語に対して生成したものであり、ノート翻訳は他のすべての人の言語でその引用の視聴者ごとのコピーを生成し、ソースの帰属を保持します。
- ミーティング後にエクスポートされたトランスクリプトは、全会話に対してチャットスタイルのテキストパイプラインを実行し、参加者がダウンロードできる言語ごとのファイルを生成します。これはチャット翻訳と同じコードパスですが、バッチ処理される点が異なります。
言語ピッカーは1つのUIにすぎません。その下にあるインフラストラクチャは、互いに通信し合う4つのパイプラインです。
私たちが意図的に行わないこと
- 「統合された翻訳モデル」はありません。 私たちは、音声、チャット、ノート、ドキュメントを行う1つのモデルを構築していません。レイテンシと忠実度のトレードオフに勝者はいません。サーフェスごとに適切なエンジンを使用します。
- サイレントな再ルーティングはありません。 今日ファイルパイプラインがヒンディー語に翻訳できない場合、音声エンジンに静かにフォールバックして動作したふりをすることはありません — ファイルピッカーはそのギャップを隠すのではなく、フラグとして表示します。
- 「200言語に翻訳します」とは言いません。 当社のエンジンは24言語を出力します。ライブサーフェスは24言語すべてを出荷し、ドキュメントは30言語です。そして、マーケティングに適した単一の数字の代わりに、監査人の前に立たなければならないペアごとの品質が、弱いペアを含めて
/benchmarkで公開されています。
自分で試してみる
- ライブデモを試す — 24の製品言語のいずれかで、あなたの音声に対してライブ音声パイプラインを実行します。
/benchmarkでスコアを出力するのと同じパイプラインです。 - ベンチマークを見る — 実際のトラフィックにおけるペアごと、月ごとの品質。ピッカー内のすべてのペア（強いものも弱いものも）にディープリンク可能です。
- 方法論を読む — 数値が何であり、何ではなく、評価者は誰なのか。
4つのパイプライン、4つのエンジン、1つのミーティングルーム。これが、古いhow-it-worksページに代わる正直な回答です。
— Mind.com チーム
情報源：DeepL — サポートされている言語、DeepL — 利用回数と請求（ファイルあたり50,000文字の最低要件）、FLORES-200。内部パイプラインの事実は出荷されたコードに対して検証済み、2026年8月確認。