XUnity.AutoTranslator が翻訳されないとき

XUnity.AutoTranslator は無料で、MIT ライセンスで、今も開発が続いていて、Unity 向けの実行時翻訳ツールとしては単独で最良のものです。ゲームが文字列をテキストコンポーネントへ渡す瞬間をフックし、描画される前に翻訳へ差し替える、という仕組みで動きます。この設計のおかげでゲームのファイル形式をいっさい知らずに済むのですが — 同時に、失敗するときに静かに失敗する理由でもあります。クラッシュはしません。ゲームがただ日本語のまま動くだけです。

下の 5 つで「翻訳されない」という報告のほとんどが説明できます。順番に確認してください。それぞれ直し方が違うので、当て推量で行き来していると何日分もの夜が溶けます。

まずは画面ではなくログを読む

このプラグインは自分が何をしているかをよく喋りますが、それを言う場所はログだけです。BepInEx で入れているなら BepInEx/LogOutput.log を見てください。Unity 自身のログはその隣、古いビルドなら <Game>_Data/output_log.txt、新しいビルドなら %APPDATA%/../LocalLow/<Company>/<Game>/Player.log にあります。

• そもそもログに XUnity.AutoTranslator の読み込みが出ていますか？ 出ていないなら、問題は翻訳側ではなくローダー側です — 失敗パターン 1 です。
• エンドポイントの初期化が出ていて、その後にエラーが続いたせいで停止された、と書かれていませんか？ それは失敗パターン 5 です。
• 翻訳は BepInEx/Translation/<lang>/Text/_AutoGeneratedTranslations.txt に書き込まれていますか？ そのファイルが正しい訳で埋まっているのに画面に出ないなら、ネットワーク側は正常で、表示側が問題です。
• ゲーム中に ALT+1 を押すと翻訳アグリゲーターのウィンドウが開きます。目の前の行がそこに出ていれば、フックはそれを見ています。空のままなら、フックは一度も見ていません。

この最後の分かれ目 — 「翻訳はされているが表示されない」か「そもそも見えていない」か — が分岐点です。以下はすべてここにぶら下がります。

1. ゲームが IL2CPP ビルドである

Unity はまったく異なる 2 つのランタイムでゲームを出荷します。Mono はゲームの C# を通常の .NET アセンブリとして <Game>_Data/Managed/ に置き、その中に Assembly-CSharp.dll があり、型名もメソッド名もそのまま残ります。IL2CPP はその C# を事前に C++ へ変換してネイティブの GameAssembly.dll にコンパイルします。型システムのうち生き残った分は <Game>_Data/il2cpp_data/Metadata/global-metadata.dat に詰め込まれます。

実行時フックはメソッドを見つけて差し替える必要があります。Mono ならそれは普通のリフレクションの問題です。IL2CPP にはリフレクションできるマネージドメソッドが存在しません — コードはネイティブで、名前、フィールド、メソッドのアドレスへ戻る唯一の道は global-metadata.dat を解析してレイアウトを再構築することです。それは設定項目ではなく、まったく別のローダーです。

• 5 秒で見分ける方法： ゲームの exe の隣に GameAssembly.dll があり、il2cpp_data フォルダーもあれば IL2CPP です。DLL が詰まった Managed/ フォルダーがあれば Mono です。
• IL2CPP には IL2CPP 版の BepInEx と、それに合わせてビルドされた XUnity.AutoTranslator のリリースが必要です。Mono 版は読み込まれません — ログに何も出ないだけなので、「プラグインが壊れている」のとまったく同じに見えます。
• ビット数も重要です。 64 ビットのゲームには 64 ビットのローダーが要ります。組み合わせが違えば、同じように静かに失敗します。
• メタデータファイルが解析できないゲームもあります。 パッカーや改ざん対策の層が global-metadata.dat を暗号化したり構造を変えたりしていると、それを読むことに依存するツールは — フックも含めて — そこで止まります。

2. プラグインは動いているのに、テキストが出てこない

ログにプラグインが出ていて、エンドポイントも初期化され、_AutoGeneratedTranslations.txt も増えている — なのに画面は変わらない。フックが翻訳した文字列をゲームが捨てているか、ゲームがフックの届かない経路でテキストを設定しています。

TextGetterCompatibilityMode

多くのゲームは、たった今設定したテキストを読み戻します — 長さを測るため、後ろに足すため、何かと比べるため。コンポーネントが翻訳済みの文字列を持ってしまうと、その読み戻しは翻訳を返し、ゲーム自身のロジックは自分が書いていないテキストを処理することになり、結果は行が元に戻る程度からレイアウトの崩壊まで幅があります。AutoTranslatorConfig.ini の TextGetterCompatibilityMode は、プレイヤーには翻訳を見せたまま、ゲームには元の文字列を返すようにします。読み取りのたびにコストがかかるので既定ではオフですが、テキストがちらつく、元に戻る、反映されないときに最初に試すべきスイッチです。

このカテゴリのもう半分は、そもそもフック済みの API を通らないテキストです：独自のテキストエンジンで描くゲーム、文字を直接メッシュへ流し込むゲーム、セリフをスプライトへ焼き込んでいるゲーム。これに設定はありません — 割り込む地点が存在しないからです。絵に焼き込まれたテキストはまったく別の問題で、フックではなく画像翻訳が必要です。

3. 一部のテキストだけ翻訳される

メニューは翻訳されるがセリフはされない。あるいはセリフは翻訳されるのにボタンは日本語のまま。これはほぼ必ず、有効になっていない UI フレームワークが原因です。プラグインはそれぞれを別々にフックしていて、すべてが既定でオンになっているわけではないからです。

• 既定でオン： UGUI（Unity 標準の UI）、NGUI、TextMeshPro、UIElements（EnableUGUI、EnableNGUI、EnableTextMeshPro、EnableUIElements）。これらで最近のゲームのほとんどはカバーされます。Utage のようなビジュアルノベル向けフレームワークも、独自のスイッチを持つのではなくこれらを通して描画するため、ここに含まれます。
• 既定でオフ： IMGUI とレガシーの TextMesh コンポーネント。IMGUI は Unity の即時モード GUI で、毎フレーム描き直すため、フックすると毎フレーム翻訳することになります。動かないからではなく、性能のために無効化されています。
• フラグは `AutoTranslatorConfig.ini` の EnableIMGUI、EnableTextMesh などにあります。ゲームが使っているものを True にして再起動してください。
• 古いゲームや日本の同人 Unity ゲームが IMGUI の典型例です。 メニューが既定のスタイルのままの灰色の箱に見えるゲームは、その強い手がかりです。

すべて有効にしても何も変わらないなら、そのテキストはそもそも Unity のテキストコンポーネントを通っていません — 失敗パターン 2 に戻ります。

4. 長い行は翻訳されずに飛ばされる

MaxCharactersPerTranslation の既定値は 200 です。それより長いものは飛ばされます。切り詰められるのでも、再試行されるのでも、プレイ中に気づくような形でログに出るのでもありません — 飛ばされるので、その行は元の言語のまま描かれ、どこも壊れて見えません。

これは一番長く探し回られる失敗パターンです。証拠が弱すぎるからです：ゲームのほとんどは翻訳されていて、ある段落だけされていない。犠牲になるのはたいていビジュアルノベルです — 長いナレーションや改行のない独白は簡単に 200 文字を超えますし、それこそ一番翻訳してほしかったテキストです。

AutoTranslatorConfig.ini で値を上げて再起動してください。ただしリクエスト 1 件あたりのコストも上がることは頭に入れておいてください：無料のエンドポイントにはそれぞれリクエスト長の上限があり、それを単体で超えるリクエストは拒否され始めます。値を大きくしすぎると、静かなスキップが目に見えるエンドポイントのエラーに変わるだけです。ふつうのビジュアルノベルの地の文なら 500〜1000 のあたりで足ります。

5. エンドポイントが失敗したか、レート制限に当たった

XUnity の既定のエンドポイントは、ブラウザーがアクセスするのと同じやり方で使う無料の公開翻訳サービスです。契約に基づくものではなく、変わります。リクエストが連続して失敗すると、プラグインは叩き続ける代わりにそのセッションの残りはエンドポイントを停止します — 意図的で正しい判断ですが、同時に、ゲームを再起動するまでそれ以降がすべて静かに未翻訳のままになるということでもあります。

• ログで停止の行を確認する。 それが出ているなら、必要なのは待つことではなく、何かを変えたうえでの再起動です。
• キューを遅くする。 MaxTranslationsQueuedPerSecond と遅延の設定があるのは、レート制限に引っかかる原因がバーストだからです。ビジュアルノベルを早送りすると、数秒で数百のリクエストが飛びます。
• エンドポイントを切り替える。 ひとつの無料サービスが調子の悪い日でも、別のサービスはたいてい大丈夫です。
• キー付きのエンドポイントを使う。 本物の DeepL や有料 API のキーは、この種類の問題をまるごと消します。代わりに有料の API キーが必要になりますが。
• プラグインを更新する。 無料エンドポイントのプロトコルが変わったときの修正は、リリースとして届きます。2 年前のビルドを、その後動いたサービスに対して走らせるのは「前は動いていたのに」のよくある原因です。

おまけ：翻訳はされるのに□で表示される

これは翻訳の失敗ではまったくありません。ゲームは元の言語に必要なグリフだけを含むフォントアトラスを積んで出荷されていて、あなたのターゲット言語はそこに無いグリフを必要とするので、足りない文字はすべて□や空白として描かれます。XUnity にはまさにこのための OverrideFont と OverrideFontTextMeshPro があります。見分け方に注意してください：□はグリフ欠け、`?` という文字はその手前のどこかで起きたエンコーディングの問題です。別のバグであり、フォントの設定で直るのは前者だけです。

確認していく順番

1. GameAssembly.dll があるかどうかで Mono か IL2CPP かを確かめ、対応するローダーを入れたかを確認する。
2. BepInEx/LogOutput.log を開き、プラグインが読み込まれ、エンドポイントが初期化されたことを確認する。
3. ゲーム中に ALT+0 を押すとプラグイン自身のウィンドウが開く——何も出なければプラグインは読み込まれていない。ALT+1 で Translation Aggregator が開く。空ならフックはテキストを見ておらず、埋まっていれば見えている。
4. フックは見えているのに画面が変わらないなら、TextGetterCompatibilityMode をオンにする。
5. 一部しか翻訳されないなら、IMGUI とレガシーの TextMesh を有効にする。
6. 特定の長い行だけ未翻訳なら、MaxCharactersPerTranslation を既定の 200 から上げる。
7. セッションの途中から全部止まったなら、エンドポイント停止の行を探し、キューを遅くするか別のエンドポイントにして再起動する。

フックが仕事の形に合っていないとき

上の失敗はどれも同じ根に行き着きます：実行時フックは、その場に居合わせて割り込めるテキストしか翻訳できません。ゲームがプラグインの知る API で文字列を設定しないなら、あるいはプラグインが読み込まれる前にテキストが描かれたなら、あるいはランタイムがフックできるメソッドを見せていないなら、設定できることは何もありません。ツールは正しく仕事をしていて、テキストが単に手の届かない場所にあるだけです。

構造的な代替案は、フレームではなくファイルの側で作業することです。ファイルレベルのツールはゲーム自身のアセットを開き、文字列を取り出し、翻訳し、翻訳済みのゲームのコピーを書き出します — エンジンが読み込むより前に、テキストがすでにターゲット言語になっているわけです。フックも、割り込む地点も、フレームワークごとのフラグも要りませんし、文字数の上限はその形式が持てるだけあります。RuneTranslate が Unity とほかの 16 のエンジン・形式でやっているのがそれです。

トレードオフは本物で、向きが逆です。ファイルレベルのツールが届くのはファイルの中にあるテキストだけです — Unity なら TextAsset、MonoBehaviour の文字列フィールド、StreamingAssets のスクリプト、ローカライズテーブル、そしてアセットバンドル（AES 暗号化された Addressable バンドルを含む）です。遊びながら翻訳するのではなく、プレイ前にエクスポートの手順が要ります。そして、ゲームが実行時に断片から組み立てるテキストにはどうにもできません。Unity がベストエフォートのエンジンなのは、まさにこのためです：どのゲームが何を外部化しているかは大きくばらつくので、プロジェクトを開いてみて初めて、自分がどちらを持っているのかが分かります。

• C# のコードにコンパイルされたテキストが、はっきりした境界です。Mono ビルドでは RuneTranslate が同梱のサイドカーでゲームのアセンブリから文字列リテラルを読み取り、その呼び出し元がそれを何に使っているかで判断するので、シーン名やアニメーターのパラメーターを翻訳することはありません。IL2CPP ビルドでは、コンパイル済みのコードは対象外です。
• IL2CPP のアセット内テキストは問題ありません。 コンポーネントの文字列フィールドは、ゲームのメタデータから型情報を再構築して IL2CPP でも読み取ります — フックが必要とするのと同じ global-metadata.dat を、別の目的で使うわけです。
• XUnity 自身の出力も読みます。 すでに中身のある _AutoGeneratedTranslations.txt があるなら、RuneTranslate はそのファイルを解析し、キーはそのままに値を翻訳できます。すでにやった作業が捨てられることはありません。
• フォントはエクスポート時に処理されます。 フォールバック用のフォントアセットをゲームへ注入するので、元のフォントがカバーしていなかったターゲット言語もきちんと描かれます。

プロバイダーは 9 つ、うち 3 つは API キーがまったく要りません — Google、無料の DeepL、DeepL の Classic / 次世代モデル — さらに DeepL の API、OpenAI、Anthropic、DeepSeek、OpenAI 互換のエンドポイント、Ollama や LM Studio 経由のローカルモデルがあります。無料プランでもすべてのエンジンとすべてのプロバイダーが開きます。絞られるのはスループットと、同時に持てるプロジェクトが 1 つという点です。Windows 10 / 11、あるいは Wine や Proton 上の Linux と Steam Deck に対応。初回起動時に無料の Patreon サインインが必要です。できあがるのは、手元に残るプレイできる翻訳済みビルドです。

どちらの方法が常に正しいということはありません。スクリプト全体が同梱の JSON テーブル 1 つに入っているゲームは、昔からファイルレベルの仕事です。セリフを実行時にコードで組み立てるゲームは、これからもフックの仕事です。自分が今どちらを持っているかを知ることが、作業のほとんどです。

次に読むもの

• Unity ゲームを翻訳する方法 — Unity が何を外部化していて何をしていないかを含む、完全な手順解説。
• Unity エンジンのページ — 対応形式と現時点の制限をひとまとめに。
• RuneTranslate と XUnity.AutoTranslator の比較 — 2 つの手法を並べて、それぞれが勝つケースを。
• 翻訳プロバイダーの選び方 — 日本語の文章をうまく扱えるのはどれで、無料なのはどれか。
• 用語集の基本 — スクリプト全体でキャラクター名と用語の表記を揃える。
• 対応エンジン一覧 — そのゲームが結局 Unity ではなかった場合に。