DIALØGUEのリリースで学んだ、多言語AIプロダクトの本当の難しさ
DIALØGUEは7言語に対応していますが、本当の多言語対応は文字列の翻訳ではありませんでした。オーディエンスの現地日付、TTSの一貫性、UIの言語ドリフト、そして「どこで品質を優先してあえて遅くなるか」を決めることでした。
今、AIが私たちに与えている最も魅力的な力の一つは、「言語を一気に増やせること」だと思います。そう感じるのは、私自身がそれを繰り返しているからです。私は48時間でDIALØGUEに5言語を追加し、その後ブログアーカイブ全体を4日で10言語に翻訳しました。
あの2本の投稿は、スピードの話でした。今回の投稿は、スピードではカバーできないものの話です。
翻訳はデモで最も見せやすく、そして最も過大評価しやすい部分です。
機械は、ある言語から別の言語へテキストを驚くほど速く移せます。でも、それでプロダクトがネイティブに感じられるようになるわけではありません。私の経験では、本当の多言語対応の仕事は4つの場所に現れます。時間、声、UIシステム、そしてフォールバックの振る舞いです。そこで初めて、プロダクトは「丁寧に作られている」と感じられるか、「なんだか偽物っぽい」と感じられるかが決まります。
実際には、こんな違いでした。
| Translation Work | Product Work | |
|---|---|---|
| カバーするもの | 文字列、コピー、ラベル | 日付、レイアウト、声、フォールバック |
| 間違いに気づく人 | バイリンガルのレビュアー | そのロケールのすべてのユーザー |
| AIが助けられること | 翻訳を高速で生成する | プロダクトレベルの適合は判断できない |
| 修正コスト | 文字列を訳し直す | コンポーネントを設計し直す |
| 問題に気づくタイミング | コードレビュー | 誰かが実際に使った後 |
最初のバグは翻訳ではなく、時間だった
これを痛感した修正の一つは、コピーとはまったく関係ありませんでした。
定期配信の番組では、DIALØGUE（ダイアログ）がエピソードタイトルを自動生成します。もっとも素直な実装は、番組名に「今日の日付」を足すことです。
一見すると harmless です。でも、オーディエンスが東京にいて、サーバーはまだカリフォルニア時間で考えているとなると話が変わります。
日本のリスナーがデイリー番組を開いた時点で東京ではすでに3月14日なのに、サーバーがそう認識していないせいでタイトルがまだ3月13日のままだったら、プロダクトは一気にズレて見えます。壊れているわけではない。ただ、雑に見えるんです。
だから私は、エピソードタイトルがサーバーのデフォルトではなく、オーディエンスのロケールとタイムゾーンに基づいた現地日付を使うように変えました。
これは小さな実装ディテールです。でも、まさにそこが本質でした。
多言語プロダクトは、単に言葉の問題ではありません。コンテキストの問題です。
ローカルコンテキストのない言語は、たいてい「少し丁寧になっただけの間違い」です。
Lesson 1: Voice はプロダクトの一部
このことは、DIALØGUEを深く作っていくほどはっきりしました。
このプロダクトは、dialogue、pacing、personality、audioの上に成り立っています。つまり、普通のSaaSインターフェースよりも品質の基準がずっと高いということです。
新しいテンプレートを追加したとき、私はすぐに「多言語対応は単にこういう話ではない」と学びました。
- テンプレート名を翻訳する
- ランディングページのコピーを翻訳する
- そのまま shipping する
あるテンプレートでは、次のすべてを考える必要がありました。
- host profiles
- audience profiles
- dialogue guides
- TTS 用の voice instructions
- 言語ごとの localized naming conventions
こうした設計は英語版にはすでにありましたが、日本語版やベトナム語版も必要でした。なぜなら、ホスト同士の chemistry は装飾ではなく、プロダクトそのものの一部だからです。
もしあなたのプロダクトがコンテンツを生成するなら、voice は飾りではありません。voice はインフラです。
文法的には正しくても、死んだように感じられるものはあります。
私はこれを中国語の各バリアントや、spoken content 全般で強く感じました。標準中国語は技術的には正しくても、文脈によっては硬すぎることがあります。英語では自然な会話のリズムが、別の言語で直訳気味のプロダクト表現になると、急に官僚的に聞こえることもあります。ある市場では通じるジョークが、別の市場ではただの平板な説明文になってしまうこともあります。
だから今の私は、tone guides や host profiles をとても重視しています。すべての出力を「ブランドっぽく」したいからではありません。voice drift は、多言語AIプロダクトを最速で generic に見せてしまう要因の一つだからです。
そして generic は、高くつきます。
Lesson 2: UIの文字量は翻訳の問題ではなく、プロダクトの問題
これは、実際にアプリをリリースするまでは小さく見えます。
でも、いざ出すと一気に everywhere になります。
DIALØGUEのiOSアプリをローカライズしたとき、それは数画面を翻訳するだけの作業ではありませんでした。7言語、253個の文字列になりました。
それでも、仕事は終わりませんでした。
私は input components を組み直して、アプリの言語ピッカーがUI言語を本当に一貫して制御するようにする必要がありました。placeholders、buttons、pricing labels、status text、全部です。そうしないと、「半分だけ翻訳されたアプリ」問題が起きます。
- ある画面は選んだ言語を反映する
- 別の画面では英語のプレースホルダーが残る
- status labels は元の言語のまま
- technically には多言語対応しているのに、体験としてはそう見えない
英語ではすっきりしたボタンが、ドイツ語では急に窮屈になります。 短く収まっていた価格表示が、フランス語では折り返します。 パンチのある設定ラベルが、日本語では別の振る舞いをします。
もしあなたの localization workflow がテキスト生成で終わっているなら、こうした問題に気づくのはかなり遅く、しかも少し恥ずかしいタイミングになります。
だから私は、多言語対応は「完全なプロダクトシステム」として扱うべきだとますます思うようになりました。
- copy
- layout
- spacing
- truncation rules
- component behavior
- screenshot QA
言葉は機械が生成できます。でも、Simulator を開くのは人間です。
Lesson 3: フォールバックの振る舞いが、プロダクトの成熟度を露わにする
これはテキストプロダクト以上に、音声プロダクトで重要です。
最近のDIALØGUEで最も有益だった修正の一つは、外から見るとかなり地味でした。TTS thresholding と、セグメントごとの一貫性です。
最初の whole-script TTS gate は楽観的すぎました。長いPodcastは実際の入力上限を超え、複数回の失敗リトライを無駄にしてからフォールバックしていました。ある run では、システムが自分で立て直すまでに約12秒の避けられたはずのレイテンシが発生していました。
英語でも十分に annoying です。
でも多言語フローではもっと悪い。voice consistency 自体がもともと保ちにくいからです。
修正は「もっと良いモデルを使う」ではありませんでした。product work でした。
- whole-script synthesis の threshold を下げる
- 長いエピソードを早めに per-segment mode に切り替える
- 各セグメントの energy を保つための opening / middle / closing guidance を加える
- 次のセグメントが別番組のように聞こえないよう、直前の dialogue を数行 continuity context として渡す
これがフォールバックの振る舞いです。これが maturity です。
言語固有のTTS音声が変だったら、どうなるのか。 生成された回答が言語を混ぜ始めたら、どうなるのか。 ローカライズされたフローの途中で untranslated error message が出たら、どうなるのか。 長いスクリプトが model limit を超えたら、どうなるのか。
そういう瞬間に、多言語対応がただの feature なのか、本当の foundation なのかが出ます。
システムが助けようとしているのが明らかなら、ユーザーは意外と寛容です。 でも、プロダクトが careless に見えると、その寛容さは一気に減ります。
Lesson 4: Coverage が割に合わない瞬間を知る
ビジネス上の問いは、「もう1言語サポートできるか」ではありません。
本当の問いはこうです。
- その言語は本当に usage や distribution を開くのか
- UI と output の両方で、納得できる quality bar を維持できるのか
- support debt を増やさずに failure cases を扱えるのか
もし答えが no なら、あなたが出しているのは multilingual capability ではありません。multilingual surface area です。そして品質のない surface area は、静かに trust を削っていきます。
Lesson 5: 多言語プロダクトには専用の eval layer が必要
これは、DIALØGUEとブログアーカイブの両方から得た最大の takeaway かもしれません。
多言語品質は、特にスケールしてくると、勘だけでは判断できません。
必要なのは explicit checks です。
- locale ごとの日付とタイムゾーンの挙動
- 用語の一貫性
- UI overflow
- fallback language rules
- セグメントをまたいだ TTS consistency
- host / personality drift
- 実際の user flow における output quality
つまり、多言語プロダクトにも evals が必要なんです。
そして私は、ここで AI builders が罠にハマりやすいと思っています。モデルがどれだけ多くを出力できるかに魅了されすぎて、「良い」とは何かを durable に定義する時間が減ってしまうんです。
小さい規模なら、まだ manage できます。
でも規模が大きくなると、それは dangerous になります。
今の私の立ち位置
私は、多言語AIプロダクトに対して以前よりずっと optimistic です。
AI はたしかに economics を変えます。個人や小さなチームが shipping できる範囲を、本当に広げます。少し前なら unrealistic に見えたプロダクトの ambition を、実際に可能にします。
でも同時に、product judgment に求められる水準も引き上げます。
言語展開が簡単になった瞬間に、差を生むのは quality になるからです。そして多言語プロダクトの quality は、翻訳だけからは生まれません。context、voice、interface fit、fallbacks、review loops、そして「native enough」とは何かを正直に定義することから生まれます。
それが、DIALØGUEが私に教えたことでした。対応言語が増えるほど、あなたは実質的により多くの product management をしている。そう呼ぶかどうかに関係なく。
もしあなたのプロダクトが本当に多言語なら、仕事は文字列を訳したところで終わりません。むしろそこから始まります。
その考え方の結果を見たいなら、DIALØGUE は今、7言語で live しています。そして使う人が増えるほど、多言語レイヤーはまだまだ新しいことを教えてくる気がしています。たいてい、少し humbling なやつです。
もしあなたも多言語プロダクトを作っているなら、ぜひ知りたいです。最も難しいバグが翻訳とはまったく関係ないと気づいた瞬間は、いつでしたか？
Cheers, Chandler
よくある質問
多言語AIプロダクトを作るうえで、一番難しい部分は何ですか？
翻訳そのものではありません。今のAIは、その部分を驚くほど上手くこなします。本当に難しいのは、その周辺です。タイムゾーンを意識した日付表示、TTSセグメント間の voice consistency、文字数の違いで崩れる UI components、そして特定の locale で何かが失敗したときの fallback behavior。これらは言語の問題ではなく、プロダクトの問題です。
AIプロダクトにもっと多くの言語を追加すべきですか？
品質を維持できるなら、です。言語を1つ増やすたびに、継続的な product work が発生します。layout QA、voice tuning、locale ごとの日付や数字の formatting、そして fallback paths。もしあなたのプロダクトが podcasts、long-form writing、conversational AI のように nuance と generated content に依存しているなら、単純な transactional interface よりもずっと基準は高くなります。
多言語AI機能はどうテストすればいいですか？
明示的な eval layer を作ることです。DIALØGUEなら、locale ごとの日付、TTS segment consistency、7言語すべてでの UI overflow、そして生成されたホスト dialogue における personality drift を確認します。2言語や3言語を超えたら、勘だけには頼れません。surface area が大きすぎて、手動 spot-check だけでは足りなくなります。
AI は localization を簡単にしますか、それとも難しくしますか？
両方です。初期翻訳は劇的に速く、安くなります。でも同時に、「もう終わった」という false sense of completion も生みます。言葉が正しくなっただけで、プロダクトの準備ができたように思えてしまう。でも本当の仕事、つまり context、voice、UI fit、fallbacks には、やはり human judgment が必要です。AI は multilingual coverage の floor を引き上げましたが、ceiling は今でも product craft のままです。
