OCRエンジンとAI翻訳モデルの違い？画面翻訳の2ステップ分工
画面翻訳を使っていて、こんなモヤモヤを感じたことはありませんか。訳文がどこかおかしいのに、問題が読み取り側にあるのか、翻訳側にあるのか判別できない——。ツールが画面の文字を誤認識したのか、翻訳自体がズレたのか。この2つの故障原因では対処法がまったく違います。「文字を読む」と「翻訳する」を2ステップに分けて捉えれば、問題は一気にクリアになります。
画面翻訳は1ステップではなく2ステップ
多くの人は画面翻訳をブラックボックスだと思っています。画面を投げると、訳文が出てくる。しかし実際の処理は2段階に分かれており、それぞれ別のコンポーネントが担当しています。
VoriTrans を例に、全体の流れを見てみましょう。
- OCRエンジンは「読む」担当：画面の選択範囲にある画像内の文字を、編集可能なテキストに変換します。出力されるのは原文です。たとえば日本語のセリフ「宿は右です」。この段階は文字を認識するだけで、意味は理解しません。
- 翻訳モデルは「訳す」担当：OCRが出力したテキストを受け取り、選択した翻訳先の言語に翻訳します。出力されるのは訳文です。この段階は言語だけを扱い、画面は見えていません。
2段階はパイプラインの関係にあります。翻訳モデルの入力は、そのままOCRの出力です。ここから重要な結論が導けます。OCRが文字を誤認識したら、どんなに優秀な翻訳モデルでも正しく訳せない。ゴミを入れればゴミが出る。上流のエラーはそのまま訳文まで伝わります。
ステップ1：なぜ画面シーンでOCRは特に難しいのか
OCR（光学文字認識）自体は新しい技術ではありません。スキャン文書の認識はすでに成熟しています。ただ、画面はスキャン文書よりはるかに手強く、難所はすべて「映像」にあります。
スキャン文書はきれいな平面です。白地に黒文字、向きは固定、フォントサイズも揃っている。一方、画面はまったく違います。文字がグラデーション背景に重なっていたり、半透明の吹き出しに覆われていたり、手書き風フォントや縁取りのあるデザイン文字だったり、画面要素と重なっていることさえあります。縦書きの日本語なら、読む順序の処理も必要です。右の列から読むべきか左からかをOCRが間違えれば、文はめちゃくちゃになります。
だからこそツールには調整の余地があります。VoriTransの環境設定では複数のOCRエンジンを切り替えられ、デザイン文字や低解像度の画面への適性はエンジンごとに異なります。範囲選択のときに選択範囲を文字のある部分だけに絞れば、画面ノイズの干渉も減らせます。認識精度が思わしくないときは、まず画面の条件を疑い、それからエンジンを疑う。この順序で進めれば遠回りしません。
ステップ2：訳文の上限を決めるのは翻訳モデル
OCRが出力した原文テキストは翻訳モデルに渡され、訳文の品質はここから差がつきます。
翻訳モデルには2種類あります。ローカルモデルは自分のPC上で動き、応答が速く、ネットワークに依存しない。短いセリフはテキパキと処理しますが、代償として文脈理解は限定的です。ゲーム内のダジャレ、ミーム、呼びかけのようなものは、ローカルでは概して保守的な訳になりがちです。クラウドモデル（Qwen、DeepSeek、GLMといった大規模モデル）はパラメータ数が多く、長文・文脈・口調の処理が明らかに上達しますが、利用量に応じてクレジットを消費します。
強調しておきたいのは、翻訳モデルではOCRのミスを取り返せないという点です。認識テキスト自体に脱字や誤字があれば、クラウドの大規模モデルに渡るのは欠けた入力であり、訳文はやはりズレます。「より強いモデルに乗り換える」と「認識を修正する」は別の課題です。前者で後者の問題を解決しようと期待しないでください。
2ステップに分ければ、切り分けも改善も迷わない
分業を理解する実利は、使うときに発揮されます。問題の発生箇所を特定でき、改善も的を絞れます。
VoriTransのUIはまさにこの分業に沿って設計されています。「認識テキスト」と「翻訳結果」が2つのパネルとして並び、認識ステップの中間成果をその目で確認できます。切り分けのコツはシンプルです。
- 原文パネルの時点でおかしい：原因はOCRです。選択範囲を絞る、OCRエンジンを変える、画面が安定するまでの待機時間を調整する。あるいは用語集にOCR修正エントリ（元の語→置き換え語）を登録すれば、誤認識しやすい固有名詞を次回の翻訳から自動で直せます。
- 原文は合っているが訳文がおかしい：原因は翻訳モデルです。短いテキストならローカルとクラウドの両方で訳して比較しましょう。固有名詞（人名・地名・スキル名）の訳がブレる場合は、用語集の翻訳ルールで固定します。
小さな例を1つ。キャラクター名「ユキ」が何回か「ユヌ」と誤認識され、訳文もそれに引きずられました。用語集で「ユキ」をOCR修正エントリに設定すると、認識ステップが先に文字を修正し、翻訳ステップがその後「Yuki」に統一して訳します。2つのステップがそれぞれ自分の担当を直すだけで、互いに干渉しません。この精度こそ、2ステップ構造がもたらすものです。
1つの境界線：分業が扱うのは画面上の文字
2段階パイプラインが適用できるのは、画面に表示された文字です。字幕のないボイス、通話、音声だけのコンテンツには、OCRが読める文字が存在せず、翻訳モデルが引き継ぐものもありません。これはモデルの性能の問題ではなく、入力の時点で認識対象がないという話です。
ここを理解すれば、ツールの能力の境界線もはっきりします。文字が画面に現れている限り——ゲームのセリフ、漫画の吹き出し、動画の焼き込み字幕、ソフトのUI——2段階パイプラインが対応できます。文字が音の中にしか存在しないなら、別の手段が必要です。VoriTransが対応する翻訳先言語は105言語。2ステップのうち後段は選択した言語で出力し、認識側は原文の言語を自動判定します。
よくある質問
OCRと翻訳モデル、どちらがミスしやすい？
シーン次第です。画面がきれいで文字がはっきり読めるなら、OCRのミスは少なくなります。デザイン文字、低解像度、背景に文字が重なるシーンでは、認識が特に崩れやすい箇所です。切り分けるときはまず認識テキストパネルを確認しましょう。原文が正しければ、はじめて翻訳モデルを評価する段階になります。
より強い翻訳モデルに変えれば誤認識を取り戻せる？
できません。翻訳モデルの入力はOCRの出力そのものです。認識ステップで文字が欠けたり間違ったりしていれば、上流のエラーはそのまま伝わります。正しい順序は、まず認識を修正し（選択範囲・エンジン・OCR修正）、それから翻訳モデルのグレードアップを検討することです。
用語集はどのステップで効くのか？
どちらのステップでも使えます。「OCR修正」に設定すれば認識ステップの誤認識しやすい文字を直し、「翻訳ルール」に設定すれば翻訳ステップの訳語の統一を担保します。1つのエントリに設定できる用途は1つだけです。解決したい問題に合わせて選びましょう。
次に訳文がおかしいと感じたら、翻訳を責める前に認識テキストパネルをのぞいてみてください。2秒でどちらのステップの問題か判別できます。分業さえ押さえれば、画面翻訳の切り分けも改善も、もはや当てずっぽうではありません。
