友人から、最近のゲーム翻訳ツールについて聞いた。
画面の一部を指定すると、その範囲に出てきた文字を読み取り、半透明のウィンドウに翻訳を重ねていく。多少ラグはあるが、翻訳部分にLLMを使えば単語を機械的に置き換えるだけでなく、会話として自然な意訳までしてくれるという。
その話を聞いた最初の感想は、「え、もう海外ゲームの日本語化パッチを待たなくても遊べる時代になってるの？」だった。
ところが調べているうちに、話はゲームから完全に脱線した。
画面を読むOCR。意味を取る翻訳モデル。元画面の上に戻すオーバーレイ。
これ、ゲームだけの話ではない。
そして、すでに12言語の高品質記事を作っている多言語記事システムがあるなら、その「高品質な12言語」を母艦にして、人気記事だけローカル翻訳モデルで追加言語へ薄く撒けば、API課金をほぼ増やさずにロングテール言語へ展開できるのではないか。
ゲームを翻訳する話をしていたはずなのに、気づいたら世界配信アーキテクチャの会議が始まっていた。
1. リアルタイムゲーム翻訳は、実は「4つの部品」でできている
リアルタイム翻訳オーバーレイを魔法として見るとすごい。
部品に分解すると、もっと面白い。
基本構造はこうだ。
- ゲーム画面の指定範囲をキャプチャする。
- OCRで画像内の文字をテキストにする。
- 翻訳エンジン、NMT、またはLLMで別言語へ変換する。
- 翻訳文を半透明オーバーレイとしてゲーム画面の上へ表示する。
公開されているWindows向けツールにも、この構成はすでに存在する。OverlayTranslateは画面領域をOCRして翻訳文を元の位置へ重ねる。SubLensはゲーム画面の範囲を継続監視し、新しい文字を検出すると翻訳し、透明オーバーレイへ出す。
昔なら「スクショを撮る→翻訳サイトを開く→貼る→戻る」だった。
今は「読む場所だけ決めたら、あとは字幕係が勝手に働く」に近い。
人類、ついに海外ゲームの横に常駐通訳を召喚し始めた。
2. Google Lensは便利だが、ゲーム常駐翻訳そのものではない
Google Lensは、写真やカメラに映ったものを認識し、画像内の文字を選択したり翻訳したりできる。
Google翻訳にも画像翻訳機能があり、PCでは画像をアップロードして画像内テキストを翻訳できる。スマートフォンではカメラ経由の翻訳もできる。ただし、小さい文字、ぼやけた文字、装飾フォントなどでは精度が落ちるとGoogle自身が注意している。
つまりLensは「画面を読む目」として非常に近い。
でも、友人が教えてくれたタイプのツールは一歩先だ。
Lensが「この画像を読んで」であるのに対し、ゲーム翻訳オーバーレイは「この範囲をずっと見張って、新しい字幕が来たら自動で処理して」である。
違いは翻訳能力だけではない。
継続監視、差分検知、キャッシュ、フォーカス判定、字幕位置への再描画といった地味な周辺処理が、ゲーム中の快適さを作っている。
派手なのはAI。
実際に生活を楽にしているのは、その周りの地味な配管である。
3. 「Google翻訳はLLMじゃないよね」は、2026年には少しややこしい
昔のGoogle翻訳をイメージすると、「Google翻訳とChatGPTは別物」という理解でだいたい合っていた。
Google翻訳は長く、翻訳専用のニューラル機械翻訳を中核にしてきた。
しかし2025年12月、GoogleはGoogle Translateのテキスト翻訳にGeminiの翻訳能力を導入したと発表した。スラング、慣用句、文脈依存の表現をより自然に処理する方向が強化された。
2026年2月には、訳語候補やニュアンスを説明する機能もGeminiの多言語能力を使って拡張された。
さらに音声ではGemini 3.5 Live Translateが70以上の言語で近リアルタイムの音声間翻訳を提供するとGoogleが発表している。
だから2026年現在、「Google翻訳はLLMではない」と一刀両断すると雑になる。
ただし逆に、「Google翻訳のすべての翻訳要求が毎回Geminiチャットへそのまま投げられている」と考えるのも雑だ。
Googleが公開しているのは、TranslateにGeminiの翻訳能力が統合されているという事実であり、内部の全ルーティング構成ではない。
境界線そのものが薄くなってきた、と考えるのが近い。
4. 無料Google翻訳と、自動化用APIは同じものではない
ここで「じゃあ記事も全部Google翻訳で無料にすればいいじゃん」と考えたくなる。
気持ちはわかる。
しかし、一般ユーザー向けGoogle翻訳を無料で使えることと、プログラムから大量に自動翻訳する正式APIが無制限無料であることは別問題だ。
Google Cloud TranslationのNMTは、現在、月最初の50万文字が無料クレジット対象で、それを超えると100万文字あたり20ドルが標準価格として示されている。
例えば1記事5,000文字を50言語へ翻訳すると25万文字。
2記事で50万文字。
人気記事を月10本、50言語へ撒けば250万文字になり、無料分を除いた200万文字に標準価格を当てると約40ドルになる。
安い。
だが「完全無料」とは違う。
そして翻訳用LLMはNMTとは別料金で、Google Cloudは入力と出力それぞれの課金を掲げている。
つまり無料を絶対条件にするなら、クラウド翻訳を無限に増やす設計ではなく、ローカル翻訳レーンを持つ方がきれいになる。
5. 完全無料レーンの本命は、ローカル翻訳モデル
そこで出てくるのがローカル翻訳モデルである。
Googleが公開しているMADLAD-400-3B-MTは、Hugging Face上で419言語対応として公開され、Apache 2.0ライセンスで提供されている。
自分のマシンで動かせば、翻訳のたびにAPI料金が発生するわけではない。
もちろん本当の意味でコストがゼロになるわけではない。
CPUやGPUを使う。
電気も使う。
処理時間も使う。
だが「1文字ごとにクラウド会社へ課金される」というスケールコストは消せる。
ここで重要なのは、419言語対応という数字を「419言語すべてで人間翻訳級」と読まないことだ。
低リソース言語では品質差が大きくなりうる。
つまりローカル翻訳は、「高品質12言語を置き換える道具」ではなく、「今まで経済的に試せなかった言語へ低コストで実験する道具」として使うのがいい。
6. ここで記事工場に話が飛ぶ――高品質12言語は捨てない
多言語記事システムですでに12言語をLLMで高品質に作っているなら、それを安い機械翻訳へ置き換える理由はない。
そこは母艦である。
仮に、
- 日本語
- 英語
- 韓国語
- 中国語簡体
- 中国語繁体
- スペイン語
- ブラジルポルトガル語
- インドネシア語
- タイ語
- ベトナム語
- フランス語
- ドイツ語
の12言語が、文脈整理、意訳、見出し調整、品質検査まで通っているとする。
これは単なる12個の翻訳結果ではない。
「意味を一度きれいに整理した12種類の中間表現」である。
追加言語を作るとき、必ず日本語から直訳する必要はない。
対象言語によっては英語版、スペイン語版、インドネシア語版などを親にした方が安定する可能性がある。
ただし、翻訳を重ねるほど誤差が累積する危険もある。
だから「近い言語だからこの親」と決め打ちせず、候補となる親言語を小規模評価し、数字・固有名詞・否定・意味保持が最も安定するルートを言語ごとに固定するのがいい。
7. 全記事×全言語にしない。「人気記事だけ」が重要
ここがこの設計の一番おいしいところだ。
記事が5,000本あるからといって、5,000本を100言語へ翻訳する必要はない。
まず人気記事だけでいい。
例えば直近30日のPVランキングを使い、
- 上位10記事は追加50言語
- 11〜50位は追加20言語
- その他は高品質12言語のみ
とする。
あるいはもっと単純に、毎日上位20記事だけ見て、まだ存在しない「記事×言語」の組み合わせをローカル翻訳する。
一度作った翻訳は資産として残る。
だから毎日少しずつ、人気記事から世界地図が塗られていく。
これは「全世界へ一斉フル装備で進軍」ではない。
「無料に近い斥候を大量に出して、反応があった場所だけ本隊を送る」である。
戦略としてだいぶ賢い。
そして財布にも優しい。
8. 言語を3階層にすると、需要が品質投資を決めてくれる
追加言語は3階層に分けると扱いやすい。
Coreは、現在の高品質12言語。LLM、厳格QC、全記事対応。
Growthは、実際にアクセスが出始めた追加言語。ローカル翻訳を基本にしつつ、対象記事数を増やす。
Experimentalは、まだ需要がわからないマイナー言語。人気記事だけを翻訳し、最初は検索インデックスを抑える選択肢も持つ。
そしてアクセス、読了、次記事遷移、再訪などで昇格させる。
Experimentalで誰も読まなければ、そのまま。
ポーランド語だけ伸びたらGrowthへ。
トルコ語が継続的に伸び、読者行動も良ければCore候補へ。
つまり人間が会議室で「次は何語が来ると思う？」と占う必要が薄くなる。
翻訳を市場調査そのものにしてしまう。
9. LLMを使わないQCを先に作ると、無料運用が崩れにくい
追加言語のたびにChatGPTへ「これ正しい？」と投げたら、翻訳を無料にした意味が薄くなる。
だから最初のQCはコードでやる。
確認できるものはかなり多い。
- 数字、%、通貨、日付が消えていないか
- URLが変わっていないか
- 見出し数が大きく崩れていないか
- MarkdownやHTML構造が壊れていないか
- タイトルやdescriptionが空でないか
- 原文言語が大量に残っていないか
- 対象言語の文字体系から極端に外れていないか
- 否定語の消失が疑われないか
- 固有名詞が異常変形していないか
- 文字数が原文に対して極端に短い、または長すぎないか
さらに必要なら、対象言語から英語などへローカルで逆翻訳し、意味の大崩れだけを異常検知する。
完璧な品質判定ではない。
しかし「壊れた翻訳を大量公開する」事故を減らすには効く。
LLMは異常候補だけに使う。
それなら高価な知能を全件検査員ではなく、再検査担当として使える。
10. 100言語化より大事なのは、「100言語をゴミにしない」こと
多言語化には最後の罠がある。
ページを大量に作れば検索流入も100倍、とはならない。
Google Search Centralは、多言語サイトでは言語ごとに別URLを持ち、hreflangなどで対応関係を示すことを推奨している。また各ページの本文とナビゲーションを一つの言語として明確にすることも勧めている。
一方、Googleは検索順位操作を主目的として、価値の薄いページを自動変換や翻訳で大量生成する行為をscaled content abuseの例に挙げている。
だからExperimental言語を作った瞬間に、何も考えず全ページを検索へ放流する必要はない。
まずはnoindexで品質と需要を観測する。
一定の品質ゲートを超えた言語だけindex対象へ移す。
読者が本当に読める。
本文だけでなくUIもその言語になっている。
言語別URLとhreflangが正しい。
意味が壊れていない。
そして実際に価値のある元記事を翻訳している。
ここまで揃って初めて「言語数」が資産になる。
結局、友人から聞いたのはゲーム翻訳の話だった。
「画面の文字を読み取って、LLMで自然に訳して、半透明で重ねるらしい」。
そこからGoogle Lensを調べ、Google翻訳とLLMの境界を調べ、API料金を見て、ローカル翻訳モデルへ行き着いた。
そして最後に出てきたのが、
「高品質12言語はそのまま残す。人気記事だけ、無料ローカル翻訳で追加言語へ薄く撒く。需要が出た言語だけ昇格させる」
という多言語配信設計だった。
ゲーム中に字幕を一枚重ねる技術を見ていたら、サイトの上に世界中の言語を一枚ずつ重ねる設計が生まれた。
技術の転用というのは、だいたいこういう脱線から始まる。
