11月6日、Kapwingが「5 Problems to Avoid When Building an Agentic Landing Page Translation System」と題した記事を公開した。この記事では、LLMを使ったランディングページ自動翻訳システムの構築で実際に踏んだ失敗と、その対策について詳しく紹介されている。
8,000ページに潜んでいたバグ
動画編集SaaSのKapwingは2024年、自社のツール紹介ページを21言語に自動翻訳して公開する大規模なi18nロールアウトを実施した。翻訳エージェントがページの文字列を抽出してLLMに渡し、翻訳済み静的ページを生成・デプロイするという構成だ。以前は翻訳代理店に1言語あたり約1万ドルを払い、数週間かけていた作業が、このシステムでは数セントで完了する。
SEO効果も大きく、翻訳ページは毎月数万人の新規ユーザーと数百人の新規購読者を獲得していた。
ところがその後、外国語ページのオーガニック流入が落ち始める。特にロシア語（-31%）とイタリア語（-32%）の落ち込みが顕著だった。調査の結果、8,000ページに及ぶ翻訳コンテンツには多数のバグと品質問題が潜んでいたことが判明した。
最も刺さる失敗：「it」に翻訳しろと指示していた
5つの問題の中で最もインパクトが大きく、見落としやすいのがロケールコードをそのままプロンプトに渡していたという問題だ。
Kapwingのシステムは内部でロケール変数として pt-br や it、id といった短縮コードを使っていた。翻訳プロンプトはそのまま：
Translate the given rich text to ${locale}.
という形になっており、イタリア語なら Translate the given rich text to it.、インドネシア語なら ...to id. という指示になっていた。
it はLLMにとって「イタリア語」ではなく英単語の "it" に見える。結果として翻訳が実行されないか、まったく別言語（イタリア語ページにヒンディー語のブロックが混入するなど）が出力されるケースが続発していた。
修正後のプロンプト：
Translate the given rich text from English to languageName(localecode "${locale}").
The output must be written in ${languageName}.
languageName として "Italian" や "Spanish (Mexico)" といった自然言語の完全形を使うことで、LLMが言語を正確に認識できるようになった。シンプルな修正だが、見落とすと数百ページ単位でサイレントに壊れ続ける。
残り4つの問題と対策
② ページのコピーを「指示」と誤認する
Kapwingは動画翻訳・吹き替えツールを提供しているため、CTAボタンに「Translate」「Summarize」「Write a script」といったラベルが並ぶ。LLMはこれを翻訳すべきテキストではなく自分への命令と解釈し、長文の説明文を返してしまうケースがあった。
修正は区切りを明示することで解決する。Translate [Translate Video] into French のように、翻訳対象をブラケットで囲むことでソーステキストと命令を明確に分離できた。
③ ハイパーリンクのi18n処理が壊れていた
Kapwingのサイトでは /tools/ 配下のページは各言語版が存在するが、ヘルプセンター（/help/）は英語のみだ。この「翻訳すべきURL」と「翻訳すべきでないURL」の振り分けロジックにバグがあり、数万件のリンク切れが発生していた。
LLMにURLが渡ってしまうと、URLそのものをアラビア語などに翻訳して404を量産するという事態も起きた。修正方針は「URLをプレースホルダに置換してから翻訳し、翻訳後に元のURLを復元する」という古典的なアプローチだ。
④ 安価なモデルによる誤訳
Kapwingはコスト削減のためAnthropicのClaude Haiku（バッチAPI経由で50%割引）を翻訳エンジンに使っている。ヘブライ語版ページでは "How to Tilt a Photo Online" が「傾ける」ではなく「歪める」という意味の単語に誤訳されるなど、意味が変わってしまうケースが5件確認された。
対策として、翻訳品質の見直しには別のLLMを使って問題のあるドキュメントを優先的に特定し、一部ページを新規翻訳し直す計画を立てている。元記事では具体的なモデル名として "Gemini" 系のサービスが言及されているが、正式なプロダクト名の表記については元記事を直接参照されたい。
⑤ LLMの「注釈」がそのまま本番に出力される
LLMが "This text is already in German, so no translation was needed." のような作業メモをそのまま翻訳文字列として保存してしまうケースがあった。
修正では、LLMに Translated または Unchanged というステータスを必ず返させる構造にし、メモや説明文が出力に混入しないようにした。さらに言語検出ライブラリ **Franc**（Node.js向けのオープンソース言語識別ライブラリ。テキストを渡すとISO 639-3形式の言語コードを返す）を導入し、翻訳完了後に言語の一致チェックやリンク数の検証を自動で行うパイプラインを整備した。
自動チェックの仕組み
現在のシステムがデプロイ前に実行するバリデーション：
- 翻訳後ページのリンク数がソースページと一致するか
- LLMが返したステータスが
Translatedになっているか - Francが検出した言語がターゲット言語と一致するか
- 翻訳テキストの長さが入力の合理的な倍率の範囲内か
これらのチェックは問題発生後に整備されたものだが、裏を返せば「バリデーションがなければバグはサイレントに通り続ける」という教訓でもある。LLMベースのパイプラインでは出力が「それらしく見える」ために人間のレビューで見落としやすく、特定言語のロケールコードでしか顕在化しないバグは数千ページ規模になるまで気づかれないこともある。自動品質チェックを翻訳パイプラインの一部として最初から組み込む設計が、こうしたリスクを抑える上で重要だ。
Kapwingはこれらの問題がGoogleからスパムまたはAI生成コンテンツと判定される要因になった可能性があるとみており、修正後のシステムがSEOおよびAEO（AI検索エンジン最適化）の回復につながることを期待している。
プロンプトのわずかな曖昧さが数千ページにわたってサイレントに壊れ続けるという構造は、LLMを使った大規模自動化全般に共通するリスクだ。ロケールコードの問題など、コードを書いた時点では正しく動いているように見えても、特定の言語コードで初めて顕在化するパターンは特に厄介である。
詳細は5 Problems to Avoid When Building an Agentic Landing Page Translation Systemを参照していただきたい。
