ゲーム日本語化 プレイブック

8作を通じて変わらなかったのはこの14個だけ。エンジンやフォーマットの知識より先に、 この進め方を守ること自体が一番効く。

1. 翻訳より先に、実機に日本語を1文字出せ

   全体構造を100%理解する前に、1エントリだけ書き換えて起動テストする。表示できれば理解は合っている。 フォント・エンコーディング・改行・折り返しなど、後で致命傷になりかねない不確定要素を最初の30分で潰せる。 Lucius IIでは「フォント形式の解読」を身構えていたら、続編では標準ダイナミックフォントで 問題自体が存在しなかった。逆に何が問題になるかは、確認してみるまで分からない。

2. 独自拡張子・謎バイナリは、まず標準フォーマットの偽装を疑え

   先頭4バイトを見る前にカスタムパーサーを書き始めない。PK\x03\x04（ZIP）、 Rar!、7z\xBC\xAF のようなマジックナンバーは拡張子を偽装していても中身に残る。 Serious Sam 2の独自アーカイブ.groは中身がただのZIPで、unzipや zipfileで即座に読み書きできた。逆にここを疑わずに「独自バイナリ形式だ」と 決めつけると、既製ツールで一瞬で終わる作業に何時間もかけることになる。

3. データを書き換える以外に、実行時に割り込む道がある

   6作目までは全部「データファイルを書き換える」方式だった。だがVox Machinaeは Unity IL2CPPビルドで、テキストはシーンオブジェクトに散在し、フォントには 日本語グリフが1文字も無かった——データ改変ルートだと、抽出・書き戻し・フォント自作の 全部が高コストになる構成。そこでデータには一切触れず、プロセスに割り込んで 「表示直前の文字列」を差し替えるMODを書いた。 この方式だと、過去4作で一番時間を食った「フォント問題」が丸ごと消える （日本語は自前で画像として描いて重ねるので、ゲームのフォントを触る必要がない）。

   判断基準はこう。データ側の「抽出・書き戻し・フォント」のうち2つ以上が 重そうなら、実行時フックの調査を先にやる。逆にテキストが平文ファイル1枚に まとまっているならデータ改変の方が圧倒的に速い。詳細は 「実行時フック方式」の節。

4. 訳し始める前に「公式の日本語が既に入っていないか」を探せ

   家庭用機版で公式ローカライズされた作品は、PC版のデータにも日本語が残っていることがある。 Homefrontはメニュー・字幕とも公式訳がそのまま同梱されており、翻訳作業はゼロで済んだ （表示されていなかっただけ）。まず全アセットを「ひらがな・カタカナ・漢字の存在」で バイナリ検索する。[぀-ヿ一-鿿] にヒットするファイルがあれば、それは宝の地図。

   日本語が無くても、他言語の公式データが「更新版の設計図」になる。 Serious Sam 2では旧版（2007年）の非公式日本語化を今のバージョンに移植する際、 最新パッチで追加されたドイツ語版のファイル一覧をそのまま「現行版で翻訳が必要な ファイルパス・フォルダ構成の正解」として使った。ドイツ語は読めなくても、 どのファイルが存在し、どう配置されているかという構造情報だけで、 旧訳のパスがどこで変わったか（フォルダ名変更・新規追加コンテンツ）を機械的に洗い出せる。 言語が読めるかどうかと、構造の手がかりとして使えるかどうかは別問題。

   Space Engineersはこの原則が過去最大の当たりを引いた回。 テキスト（*.ja-JP.resx 約9,300件・92%訳済み）だけでなく 日本語専用のビットマップフォントまで丸ごと同梱されていた。 コンソール版のために作られた資産が、PC版では選べないまま眠っていただけだった。 「フォントも探す」のを忘れないこと——テキストが見つかった時点で満足すると、 すぐ隣にあるフォントを自作する羽目になる。

5. データが揃っているのに使えないなら、封印しているのはコードの方

   公式データを見つけても、ゲームがその言語を選べるとは限らない。 Space Engineersはja-JPのresxもフォントも揃っていたのに、 言語選択に日本語が出ず、設定を強制すると起動時にクラッシュした。 原因はMyTextsの静的コンストラクタに並ぶ言語登録が26言語で打ち切られていたこと （日本語はenum値だけ存在して登録行が無い）。1行分のILを足しただけで解決した。

   見分け方はこう。クラッシュのスタックトレースが「翻訳の読み込み」ではなく 「言語テーブルの参照」で止まっているなら、データではなくコードの問題。 逆に読み込みまで進んで文字が出ないならデータかフォントの問題。 翻訳を1件も書かないうちに、まず「その言語を選べる状態」を作る—— ここが通らないと、以降の実機確認が全部できない。

6. 構造の仮説は実機で裏を取るまで信用しない

   「パースできた」は「正しい」の証拠にならない。件数が変わる／文字化けする／クラッシュするのは 全部シグナル。Lucius IIでは同じデータを2回誤読し、2回とも実機の "MISSING TRANSLATION" や クラッシュで気づいた。パース終了位置がファイル境界・オブジェクト境界とちょうど一致するかを 最終検証にする。

7. 実機の起動可否は、自分で回せる仕組みにする

   依頼者に「起動しますか？」と聞くたびに1往復かかる。起動 → 生存確認 → 終了を スクリプト化すれば、同じ時間で10回試せる。Deadpoolでは3回続けて起動不能を出してから これを作り、そこから原因特定まで一気に進んだ。最初に作るべきだった。

   ただし正規の起動経路を使うこと。Deadpoolは実行ファイルを直接叩くと 正常なビルドでも1秒で 0xC0000005 になる（ランチャー経由が必須）。 これに気づかず障害オフセットまで採取して、丸ごと無駄にした。 新しい計測手段を導入したら、まず既知の正常ビルドで対照を取る。

8. 原因が分からない時は、変更を分解して対照実験を作る

   「AとBを同時に変えて壊れた」なら、Aだけ・Bだけの2本を作る。仮説を並べて考え込むより、 答えが2択になる実験を1本作る方が速い。Deadpoolの決め手は 中身を1バイトも変えず末尾に4バイト足しただけのビルドで、これが落ちたことで 「中身ではなくサイズが原因」と確定した。

   分解の軸は「中身」と「大きさ」、「量」と「書式」の2つが特に効く。 1件だけ足しても落ちるなら規模ではなく書式の問題、と即座に分かる。

   そして「1手で仮説を殺せる実験」があるなら、実装より先にそれをやる。 Vox Machinaeで選択肢ボタンの文字が消える不具合を「自分のMODが元テキストを 消しているせいだ」と診断し、診断用のコードを書き始めた。実際には 辞書から該当の2エントリを消すだけ——コード変更ゼロ、リスクゼロ——で 「MODが原因かどうか」は確定できた。やってみたら症状は変わらず、仮説は間違いだった （ゲーム本体が空文字列を渡していた）。 コストの高い検証を始める前に、「もし自分の仮説が正しいなら結果が変わるはずの、 一番安い操作」は何かを一度考える。

9. どのファイルが使われているかは、壊して確かめる

   参照を辿るより破壊テストの方が速くて確実。候補ファイルを1つずつ壊して実機で変化を見る （詳細は次節）。Homefrontではフォントの供給元がIpDrv（ネットワーク用パッケージ）という 推測では絶対に辿り着けない場所にあり、総当たりの無効化テストだけが答えを出した。

10. 「本体のローカライズ」と「コンテンツ同梱のローカライズ」は別物

    本体のテキストを全部訳しても、シナリオ・キャンペーン・DLCの中身だけ英語のまま ということが起きる。Space Engineersでは本体がContent/Data/Localization/の resxを読む一方、シナリオは各シナリオのフォルダに自前のローカライズ一式を持っていて、 こちらには日本語ファイルだけが用意されていなかった。 依頼者から「進行表示だけ英語のまま」と指摘されて初めて気づいた。

    探し方は決まっている。コンテンツ側のフォルダ （Scenarios/／Campaigns/／Missions/／DLCフォルダ）を ローカライズ形式の拡張子で再帰検索する——本体で使われていた形式が そこにも転がっているなら、それが第二のローカライズ系統。 「本体の翻訳が終わった＝完了」と判断する前に、必ずこの検索を1回かける。

    そして既存言語のファイル一覧を数えると、抜けが機械的に分かる。 Space Engineersでは9言語×15コンテキストが揃っている中で日本語だけゼロ、 という形で欠落がはっきり見えた。

11. 利用者と同じ状態で検証せよ — 「新規開始」ではなく「旧セーブを続きから」

    自分の実機確認は毎回まっさらな新規開始だった。利用者は違う——前のバージョンで 始めたセーブを、更新後に続きから遊ぶ。Space Engineersではセーブが 「読む言語ファイルの一覧」と「表示中のクエストログの文字列」を保存しており、 パッチ前のセーブは訳文が揃っていても英語のままだった。自分の検証では一度も踏まず、 配布後の報告で初めて分かった。

    「まだ英語」と報告されたら、まずその文面を訳文ファイルで検索する。 入っていれば原因は翻訳ではなく読み込み側。そして検証手順に 「翻訳を外した状態でセーブを作る → 翻訳を戻す → 続きから読む」を1回入れる。 インストーラーも同じで、旧版を入れた状態からの上書き更新と アンインストール後に旧セーブを読めるかまで試す。

12. テキストの「面」ごとに別系統だと疑え

    メニュー・ムービー字幕・会話字幕・目標表示・収集アイテム——同じゲーム内でも供給元も フォントも別々のことがある。HomefrontもDeadpoolも実際に全部バラバラだった。 検証時は必ず面ごとに個別に確認する。「メニューが変わらない＝効いていない」と判断して、 実は同じ変更でムービー字幕だけ変わっていた、という取りこぼしを何度もやった。

    Deadpoolではフロントエンドとゲーム中で同じフォントの別コピーが使われていた。 メニューだけ完璧でゲーム中が全部豆腐、という症状になる。「効いていない」の原因は、 たいてい直した場所が足りないと考える。

13. 同じスタジオ・同じエンジンでも、実装は毎回作り直されると思え

    Lucius IIとIIIは両方Unityだが、テキストの格納方式もローカライズの仕組みも全くの別物だった。 HomefrontとDeadpoolは両方UE3だが、コンテナ形式もフォント系統も別物だった。 前作のコードやツールをそのまま移植できるという期待は捨て、毎回ゼロから「エンジン別の初動チェック」 をやり直す。使い回せるのはコードではなく「進め方」の方。

14. 小さいカテゴリで検証 → 大きいカテゴリへ

    メニューや実績など数十〜数百件の塊でパイプライン全体（抽出→翻訳→ビルド→実機確認）を 検証してから、字幕やアイテム説明など数百〜数千件のカテゴリに進む。手戻りの母数を最小化する。 Homefrontでも字幕は1ミッション分だけ先に適用して確認してから、残り全ミッションに広げた。

「このフォント／このテキストは、本当にゲームが読んでいるのか？」—— 参照関係を静的に辿って答えを出そうとすると、シークフリー化・重複コピー・実行ファイル内の 解決ロジックに阻まれて、いくらでも時間が溶ける。壊して観察する方が桁違いに速い。 Homefrontではフォント特定に静的解析で何時間も費やして失敗し、この手法に切り替えて解決した。

候補の列挙で漏らさない — 「クラス名で数える」

候補を挙げる段階の取りこぼしが、そのまま「原因不明」に化ける。Homefrontでは 拡張子（.upkだけ見て.mapを見落とし）、 圧縮パッケージ（ヘッダが読めず走査から漏れる）、 集計スクリプトのバグ（全件を1パッケージに誤集計）の3つで、それぞれ別の候補を見逃した。

Deadpoolでも同じ罠を踏んだ。SwfMovie というクラス名を生バイト検索したら 1,787パッケージ中8件しか見つからず、それを前提に「フォントは全部直した」と誤って結論した。 実際は圧縮パッケージの名前表が読めていなかっただけで、全パッケージを開いて エクスポートのクラス名で判定し直すと、直すべきフォントのコピーが別の場所に見つかった。 生バイト検索は「見つかった」の証拠にはなるが、「無い」の証拠には絶対にならない。

最終的に「ゲーム全体で該当クラスのオブジェクトは何個あるか」を数え、既知の内訳と 合計が合うかを確認して、初めて漏れが無いと言える状態になる。

原因は書き換えた中身ではなく、書き出し方だった。 本体を先頭から詰め直す実装だったので、大きくしたオブジェクトより後ろが全部ずれた。 ずれた中に自分の絶対ファイルオフセットを内部に持つバルクデータ （音声データ 133個ほか）が含まれていて、それを書き直す処理はどこにも無かった。

なぜ今まで無事だったかというと、それまで触っていたフォントがたまたま後ろの方に あったから。同じ操作でも、ファイル内の位置で結果が変わる。

解法 — 大きくなった分は末尾に逃がす

新しいペイロードが元の場所に入るならその場に上書き、 入らなければファイル末尾に置いて、そのオブジェクト自身のオフセット項目だけ書き換える。 他のオブジェクトは1バイトも動かない。元の場所に死んだ領域が残るが、誰も読まないので無害。 オブジェクトのデータがテーブル順に並んでいる必要は無い、という性質を使っている。

そして書き出した後にツール自身に検査させる。「意図したもの以外は動いていないか」を 毎回確認すれば、この落とし穴は二度と踏まない。

layout: 2 of 2830 exports moved (SubtitleFont, Texture2D_415)

実行ファイルと隣接フォルダを見れば、エンジンはだいたい一発で分かる。分かった時点でこの表を引く。

Unity（Mono/IL2CPP以外）や.NET製ゲームで、テキストの読み込みロジックそのものを確認したいが ilspycmd 等のフル逆コンパイラを用意できない・使いたくない場合、 dnfile（.NETメタデータの読み取り）と dncil（ILバイトコードのデコード）を 組み合わせれば、特定のメソッド1個の逐語的な挙動をピンポイントで確認できる。 C#のソースは出てこないが、命令列と文字列・呼び出し先メソッド名は正確に読めるので、 「区切り文字は何か」「最初に読んだファイルだけ特別扱いされていないか」のような 構造仮説の検証には十分。

ゲームのプロセスにMODを読み込ませ、文字列が画面に出る直前のメソッドに割り込んで 差し替える方式。データファイルは1バイトも書き換えない。 Vox Machinae（Unity IL2CPP）で採用し、7,000件超を実機で表示させるところまで到達した。

仕組み — 元テキストを消して、日本語は自分で描く

核心は「ゲームには何も描かせず、自分で描く」こと。これで フォント問題が構造的に消える——ゲームのフォントに日本語グリフが1文字も無くても関係ない。

1. 「文字列がここを必ず通る」1点を見つける

   UIフレームワークには、たいてい表示テキストの最終的な設定先が1つある （Vox MachinaeではGooeyElement.SetSymbol(string)で、 86画面ぶんのメニューが全部ここを通っていた）。 ここにHarmonyのPrefixを当てれば、ゲーム全体のUIを1つのパッチで押さえられる。

2. 辞書に一致したら、元の文字列を空にする

   Prefixで引数を""に書き換えると、ゲームは何も描かなくなる。 同時に、その要素のTransformと訳文を自前の辞書に控えておく。

3. 日本語はGDIで画像にする

   OSのフォント描画（WindowsならDrawTextW）で訳文を BGRAビットマップにレンダリング → PNGにエンコード → Texture2Dに読み込む。 ゲームのフォント資産には一切触れない。 テクスチャは文字列＋サイズ＋色＋折り返し幅をキーにキャッシュする （毎フレーム生成すると即死する。色と幅をキーに入れ忘れると、同じ文が別の色・幅で 必要になった時に古い画像を使い回してしまう）。

4. その画像は「画面」ではなく「3D空間」に置く

   ここが方式の成否を分ける。UnityのOnGUI()は デスクトップのウィンドウにしか描かれず、VRゴーグルの映像には一切入らない。 当初Camera.main.WorldToScreenPoint()で投影してGUI.Labelで描いていたが、 VRで起動したら英語は消してあるのに日本語も出ない＝全部空欄になった （モニタ側では正常に見えるので、非VRだけで検証していると気づけない）。

   正解はテクスチャを貼った板（Quad）を、置き換えた要素の子として3D空間に置くこと。 ゲームのカメラが描くので両目の映像に入り、位置・向きも親に追従する。 非VRでも同じコードで動く。OnGUIは失敗時の退避用としてだけ残す。

5. 大きさ・位置・奥行きは、ゲーム自身の値から決める

   大きさ——UIフレームワークは「1文字の大きさ」を持っていることが多い （Vox MachinaeではGooey.letterHeight）。それを1行の高さとして 板の大きさ = テクスチャ画素数 × 文字高 ÷ レンダリング画素数で決める。 ただし要素のスケールが既にTransformに入っているなら二重に掛けない （掛けてしまい、板が2mmの点になって「描画されているのに見えない」状態を作った）。

   位置——要素はpivot（-1／0／+1のような値）で左右上下の揃えを持つ。 中央固定にすると隣のアイコンに重なるので、板の位置 = pivot × 板の大きさ ÷ 2 でずらす。画像内の行揃えも同じ値に合わせる。

   奥行き——UIの文字はモニターのガラスや筐体を透過して描かれていることが多い。 普通に深度テストする板を同じ位置に置くと描画はされているのに奥に隠れて見えない。 Unity標準のGUI/Text Shader（TextMeshのシェーダー）はZTest Always固定なので、 これを使い、描画順はゲームのUIマテリアルのrenderQueue + 1にすると 汚れや反射のオーバーレイまで含めて元の文字と同じ見え方になる。

6. 見えなくなった要素は「消す」ではなく「隠す」

   UI要素はプールされて使い回されるので、放置すると前の画面の訳文が残る。 ただし「見えないから破棄」は危険——要素は生成直後は不透明度0で、 そこからフェードインすることがある。破棄する実装にしたら、 作った次の瞬間に自分で消してしまい、メニュー項目が1つも出なかった （毎フレーム処理が、ゲームがフェードを進める前に走っていた）。

   板が要素の子なら、親が消えれば一緒に消えるので破棄は不要。 表示/非表示の切り替えだけにして、別用途に使い回された時は 文字列設定のフックが更新・削除するのが正しい。 不透明度も要素の「色のアルファ」まで掛ける——選択中だけ明るい、といった ゲーム本来の演出がそのまま再現でき、隠されているはずの文字が光る事故も防げる。

7. 板を置くレイヤーは「要素」ではなく「実際に描画している側」に合わせる

   要素はデータの入れ物にすぎず、描画しているのは親のレンダラーということがある。 Vox Machinaeの字幕要素はレイヤー2（Ignore Raycast）にあり、 コックピットのカメラがそのレイヤーを描かない場面で、字幕だけ消えた （船内では出るのにコックピットでは出ない、という分かりにくい症状になった）。 板のレイヤーは、要素ではなく描画器のGameObjectから取る。

最大の利点 — ゲーム自身に「今どの文字列を表示したか」を吐かせる

これが実行時フック方式で一番効く部分。割り込んだ場所で受け取った文字列を 全部ログファイルに追記しておけば（重複はHashSetで除去）、 あとはそのログと翻訳辞書を突き合わせるだけで 「まだ英語で出ている文字列」が機械的に列挙できる。 静的解析で「これが表示されるはず」と推測する必要がそもそも無くなる。 前半の破壊テストが「どのファイルが使われているか」を答えるのに対し、 これは「実際に画面に出た文字列は何か」を答える。

実際、この突き合わせが2つの根本原因を一撃で出した—— ①メニュー文字列が"BASIC|TRAINING"のようにパイプ区切りで改行していたこと、 ②確認ダイアログが"回答1|回答2|質問文"という1本の連結文字列で 渡されていたこと。どちらも辞書のキーが実際の文字列と違っていただけで、 訳文は最初から存在していた。推測を2回外した後に、ログを見て30秒で解決した。

配布の形

MODローダー本体・MOD DLL・翻訳辞書・ソースを1つのzipにまとめ、 ゲームフォルダに上書き展開するだけにする。データを書き換えないので バックアップも復元処理も要らない（アンインストールは削除するだけ）。 前半「配布パッケージの型」の追加方式が理想形のまま実現できるのは、この方式の副次的な利点。 ただしゲーム本体のアップデートでクラス名やメソッドが変わると動かなくなるので、 動作確認済みのバージョン番号をreadmeに明記し、ソースも同梱しておく。

1. 抽出は「ゲームが実際に使うキー」単位で

   行番号やファイル内の物理位置ではなく、ゲームがルックアップに使う値（連番ID・ハッシュ・ 検索キー文字列など）を主キーにしたJSON（{"id": {"key": ..., "en": "..."}}）に抽出する。 表示順と保存順が一致する保証はどのフォーマットにもない。

2. キーに「ゲームが表示前に捨てる記法」を混入させない

   原文が英語そのものを検索キーにする方式（＝英文→訳文の辞書）の場合、 抽出時に1文字でも余計なものが混ざると、そのエントリは永久に一致しない。 しかもエラーは何も出ず、ただ英語のまま表示されるので 「まだ訳していない箇所」と見分けがつかない。

   Vox Machinaeでこれを大規模にやった。台本の台詞には Frank:<a3>text というボイス収録用のマーカーが付いていて、 しかもコロンとマーカーの間に空白が有る行と無い行が混在していた。 抽出の正規表現が空白無しの形しか想定していなかったため、空白有りの行では マーカーが本文の先頭に貼り付いたままキーになり、 1,736件が「訳文は完成しているのに絶対に一致しないキー」として登録されていた。 値の側にもマーカーが残っていたので、キーだけ直すと今度は画面に <a3>が表示される、というおまけ付きだった。

   対策は2つ。①抽出直後に、キーの集合を 「記号・タグらしきものを含む行」で機械的にふるいにかけて目視する。 ②HTMLエンティティ（"／'）の復元を忘れない—— これを忘れると、実際には一致している数千件が「未翻訳」として誤検出され、 存在しない問題を追いかけることになる（実際に1,800件の偽陽性を出した）。

   そして症状の読み方を変える。「訳したはずなのに英語で出る」時、 原因は訳文ではなくキーである可能性の方が高い。

3. 1つの表示欄に、複数の論理項目が連結されて来ることがある

   UI部品が受け取る文字列は、必ずしも画面で読める文字列と同じではない。 Vox Machinaeの確認ダイアログは "回答1|回答2|質問文"という1本の連結文字列で渡ってきていた （区切りは|）。質問文だけを辞書のキーにしていたので永久に一致せず、 正しいキーは"||質問文"——先頭の||は 回答ラベルが2つとも空という意味だった。

   同じゲームのメニューでは|が改行として使われており （"BASIC|TRAINING"）、同一記号が文脈で別の意味を持っていた。 区切り文字を見つけたら、意味を1つだと決めつけない。 実際に渡ってきた文字列をログで確認するのが唯一確実な方法。

4. 抽出の正規表現は「行の先頭」しか見ていないことが多い

   台本形式のデータは条件分岐やマクロの中に台詞が埋め込まれている。 Vox MachinaeのTwine台本では、2回目以降の会話や分岐後の台詞がこう書かれていた—— (if: $i1engineroom is 1) [Hans: <h4>Here's an unfamiliar face.]]。 抽出器が「行頭が話者名:で始まる行」しか拾っていなかったため、 この形の863行を丸ごと取りこぼしていた。 症状は「NPCに2回目に話しかけると必ず英語」—— 一度目は普通の行、二度目以降は分岐の中、という構造がそのまま現れる。

   対策。話者は行頭だけでなく[・]・)の直後でも 受け付け、本文は次の]までとする。 (の直後は除外すれば(if:／(set:のような マクロ名を話者と誤認しない。「1行に複数の台詞」もあり得るので、 行ごとに全部の出現を走査する。

   そして完了判定を「抽出できた件数」ではなく「原文側の総数」で行う。 修正後は総数が5,744→6,607に増えた。母数が増えるということは、 それまでの「100%カバー」は分母が間違っていたということ—— カバー率は分母を疑ってから読む。

5. 実行時に穴埋めされる文は、テンプレートとして照合する

   原文に{0}や___のような穴があり、 ゲームが実行時に埋めてから表示することがある。埋まる中身は 入力機器や相手の名前で変わるので、完成後の文字列を辞書に登録しても追いつかない （press W,とpress Left Stick Up,で別物になる）。

   Vox Machinaeではこの形の辞書エントリが139件あったのに、一度も一致していなかった。 非VRで動いて見えたのは、プレイ中に拾ったキーボード専用の完成文字列を 個別に登録していたから——「動いている」が「仕組みとして正しい」とは限らない。

   実装は単純。穴を含むキーを、穴を(.+?)に置換した アンカー付き正規表現に変換し、辞書が外れた時だけ順に試す。 literal部分が長い順に並べる（「Then {0} to fire at the target.」が 「Then {0} to fire.」に食われないように）。 literalが短すぎるキーは除外する（{0}.は全文に一致してしまう）。

   捕まえた値は、そのまま埋め戻さず日本語に馴染む形に整える。 press W, and S,→［W］・［S］、 press Space, and hold it→［Space］長押しのように 動詞を落として名詞化し、日本語側は{0}で…／{0}を押して…と書く。 逆に日本語を{0}してくださいと書いてはいけない—— ［Right Stick Button］してくださいになる。

6. 原文には触らず、訳文だけを別ファイルに重ねる

   原文ファイルを直接編集せず、キー → 訳文のオーバーレイを別に持ち、ビルド時に合成する。 オーバーレイは<file>.part01.json のように150〜200件で分割してよい （全部をソート順にマージする）。1回のセッションが中断しても成果がチャンク単位で残り、 原文はいつでも正典として参照できる。同じ英文が複数キーに現れるファイルでは、 英文 → 訳文の対応表を別に用意して一括展開する方が速い。

7. 未翻訳は必ず原文へフォールバック

   ビルド時、オーバーレイに無いキーは英語（原文）でそのまま埋める。 こうすることで、翻訳がまだ半分でも赤字の "MISSING TRANSLATION" のような プレースホルダーがプレイヤーの目に触れることがない。作業を段階的に配布・検証できる。

   ただし「キーが載っていること」を翻訳済みの印にすること。 「訳文が空でないこと」で判定すると、意図的に空にすることができなくなる（次項）。

8. 連結される文字列は、日本語で語順が変わる

   Key1 + <ボタン> + Key2 のように分割された文字列は、英語の "Press / W / to get up off your ass." をそのまま置き換えると 「押せ W でケツを上げろ。」という不自然な日本語になる。日本語は助詞がボタンの後に来るので、 前半を空にして後半に動詞を移す（「W を押してケツを上げろ。」）。 分割文字列を見つけたら、まず実際の連結順を確認してから訳す。

9. 置換トークンの検証を自動化する

   <br>、*強調語+、{ButtonStart}、`c のような ランタイム置換記法は、原文と訳文でトークンの集合が一致するかを機械的に照合する。 目視では必ず漏れる。Deadpoolではこの照合が製品版側のバグまで見つけた （同じキーが3回代入されていて最後の1回が勝つ、という構造だった）。

   同時に「想定した文字集合の外」の検出も入れる。 訳文に紛れ込んだキリル文字（ラテン文字そっくりで目視では気づけない）を、 この検査だけが捕まえた。

10. 固有名詞は最初に決めて最後まで貫く

    キャラクター名・地名などは初出時にカタカナ表記を確定し、以降は用語集代わりに 検索して同じ表記で統一する。数百件に分けて訳す作業ほど表記ゆれが起きやすい。 キャラクターごとの一人称・語尾も最初に決めると、数千行でも人格がぶれない。

11. 口調のゆれは、後からでも機械的に監査できる

    最初に決めていても、数千行を分割して訳せば必ずぶれる。 Vox Machinaeでは依頼者から「AIキャラのBLUEが時々タメ口になるのが気になる」と 指摘された。全2,000行を読み直す代わりに、次の3段階で機械的に潰した。

    ①台本から話者ごとに台詞を抽出（話者名:で始まる行を集める）。 ②各訳文の文末を正規表現で丁寧語／常体に分類 （です・ます・ください・ました ／ だ・だな・くれ・んだ・ろ など）。 ③キャラごとに多数派を「そのキャラの正しい口調」と見なし、少数派だけを列挙して手で直す。

    正解を自分で決めずに多数決で決めるのが要点——作品の設定を完全には 知らなくても、訳文自身の統計が答えを持っている。 14人ぶんで224件の外れ値が出て、修正後はBLUEが1,316件中0件のブレになった。 なおこの監査は「訳し終わった後」に一度かける工程として組み込むとよい。 指摘されてから慌ててやるより、全キャラ一括の方が明らかに安い。

    ただし構造上直せないものがある。英文→訳文の辞書は 1つの英文に1つの訳文しか持てないので、 "What?"のような短い台詞を口調の違う複数キャラが話す場合、 どちらかを諦めるしかない（キーを(話者, 英文)にする設計変更が要る）。 自動修正スクリプトには「複数話者が使っている行はスキップする」判定を必ず入れる—— 入れないと、Aを直した瞬間にBが壊れる。

12. フォントの文字セットは「表示され得る全テキスト」から作る

    収録する文字はメニューのテキストだけでなく 字幕・アイテム説明・実績など全ての日本語ソースを合わせた和集合から決める。 Homefrontでは字幕データの文字を集計に入れ忘れ、「奉仕」の奉だけが別の字で表示される という分かりにくいバグになった（グリフが無いとフォールバック文字が描かれる）。 訳文ファイル群から機械的に文字集合を作るようにしておけば、訳を足すたびに自動で追随する。

    集合を正しく作っても、器（アトラス）の容量不足で同じ症状が再発する。 Serious Sam 2では約1,800字の文字集合を正しくフォント生成ツールに渡していたにもかかわらず、 既定のアトラスサイズ（256×128）では68字しか収まらず、残り全部が無言で代替文字に すり替わっていた——エラーは出ず、ツールのログに一行 Not all characters fitted in the texture (68/1810) と出るだけだった。 「映」のような何の変哲もない常用漢字が、収まりきらなかった1742字の中にたまたま含まれていた、 というだけの話。文字集合を渡した後は、生成ツールの側が「全部収まったか」を 明示的に報告しているか確認する。黙って一部を落とすツールは想定より多い。

13. 訳し終わらないものは、意図的に残したと記録する

    商標・著作権表記、製品版に紛れ込んだ開発用プレースホルダ （<deleted - need line> のような文字列）は、訳すとかえっておかしくなる。 「未着手」ではなく「意図的に原文のまま」だと明示して、readmeにも書いておく。 Deadpoolは6,059行中23行がこれに当たった。

14. 翻訳を並列サブエージェントに投げるなら、必ず数十件ごとに保存させる

    「全部読んでから訳して最後にまとめて書き込む」やり方は、 並列実行時に全滅する。Serious Sam 2では未翻訳の数百〜千行超のテーブルファイルを 5本の翻訳サブエージェントに同時に投げたところ、全員が「読了→翻訳完了→さあ書き込み」 の直前でAPIのセッションレート上限に同時到達し、5本とも訳文を1行も保存できずに 全滅した。指示に「30〜50件ごとに訳しては即座にファイルへ反映し、既に反映済みの キーはスキップして再開できるようにする」という一文を足しただけで、 再実行では同じ規模の作業が普通に完走した。大量処理を並列化するなら、 「作業単位を小さくちぎってその都度確定させる」ことを明示的に指示する。 これを怠ると、同じ共有レート制限に複数のエージェントが同時に刺さり、 1つの失敗ではなく全滅という形で表面化する。

アトラスを拡張する

1. ブロック圧縮テクスチャは、ブロック単位でコピーできる

   DXT5/BC3は4×4ブロックの行優先なので、512×512のページを1024×2048の左上に置くのは ブロック行の単純コピーで済む。再エンコードが一切要らない＝出荷ピクセルが完全に保存される。 新しく足すグリフの分だけエンコーダを書けばよく、アルファのみのフォントなら 「エンドポイントを255/0固定、8段階の量子化」で十分な品質が出る。

2. グリフ座標はピクセル値。テクスチャを大きくしても壊れない

   多くのエンジンはStartU / SizeX のように描画時にテクスチャ寸法で割るので、 同じピクセル位置に同じ絵があれば、寸法を変えても既存グリフの座標はそのまま正しい。 これが「拡張」を安全にしている根拠なので、対象エンジンでもそうなっているか先に確認する。

3. ベースラインは出荷グリフから測る

   足す文字を既存の英字と揃えるには、実測が要る。. A B の インク下端が揃う行がベースライン。大文字の高さを測れば、そこから逆算して 日本語のem値が決まる（Deadpoolは大文字17px → Noto Sans JPのcap 733/1000 → em 24pxでほぼ一致）。

4. 升目が足りるか先に計算する

   収録文字数 ≦ (アトラス幅 ÷ 升目) ×(高さ ÷ 升目)。ここが足りないと升目を小さくする＝ 文字が小さくなる、というトレードオフになる。寸法変更が許されるかも先に確認する （エンジンのテクスチャグループ設定に上限がある。そのゲーム自身が使っている最大寸法までなら安全）。

ビットマップフォントを自作する

1. 字幅は必ず可変にする（ここを固定にすると全角化する）

   升目状に配置するのは実装が楽だが、1文字あたりの幅を升目そのままにすると 英数字まで全角幅で描画される。各文字の実インク領域（textbbox）を測り、 矩形は升目原点＋実寸で登録する。

2. 矩形は「送り幅」で登録する。インク幅で詰めると隣とくっつく

   多くのエンジンは矩形の幅をそのまま字送りに使う。インク領域ぴったりで登録すると サイドベアリングがゼロになり文字同士が接触する。矩形＝送り幅（advance）とし、 インクはその中に左サイドベアリング分だけ内側に置く。 エンジン側に字送りパラメータがあれば1〜3px入れる（拡大率に比例させること）。

3. 用途別に複数サイズを作る

   1種類のサイズで全部を賄おうとすると必ず破綻する。字幕に合わせて大きくすると メニューやアイテム説明など固定枠のUIで溢れる。Homefrontでは 小（メニュー用）と大（字幕用）の2枚のアトラスを作り、フォントごとに割り当てた。 どのフォントがどの画面で使われるかは破壊テストで特定する。

実機確認は1回が高コストで、しかも見落とす。 そこで実機で起きうる失敗を、機械的に検査できる形に翻訳しておく。 Deadpoolでは毎ビルド次の3つを自動で確認し、problems: 0 でなければ導入しない運用にした。

本体のテキストを訳し終えて実機で確認し、配布まで済ませた後に、 依頼者から「シナリオ上の進行情報だけ英語のまま」と指摘された。 原因は翻訳漏れではなく、ゲームがローカライズ系統を2つ持っていたこと。 これは珍しい構成ではないので、独立した工程として書いておく。

ローカライズの仕組みを持たないコンテンツをどう扱うか

同じゲームの中でも、ローカライズ対応のシナリオと、テキストを スクリプトに直書きしたシナリオが混在していた。後者は書き換えるしかないが、 同じ場所に「表示する文字列」と「オブジェクトを引くための識別子」が混在しているのが 危険なところ。Space EngineersのFrostbiteでは、同じ <ConstantScriptNode><Value>に 目標文とFrostbite Bombing Drone Mk2（出現させるプレハブ名）が並んでいた。 後者を訳すとシナリオが静かに壊れる。

配布後、プレイ中の人から「左上の進行表示がまだ英語」とスクリーンショット付きで報告された。 翻訳漏れを疑ったが、その文面は原文も訳も揃っていて、自分の環境では日本語で出る。 真因はセーブデータが言語の状態を2か所で凍結していたことだった。 報告者は旧版（シナリオ未対応）で遊び始め、新版に更新して続きから遊んでいた。

Windows向けにインストーラーを同梱するなら、.bat単体ではなく .bat（起動用の薄いラッパー）＋実処理スクリプトの2枚構成にする。 実処理側はPowerShell（UTF-8 BOM付き）でもPythonでもよい。

全体像 — 3系統のフォント

フロントエンドとゲーム中で同じフォントの別コピーが使われているのが最大の罠。 UI_GFxCLIK_p.xxxだけ直すとメニューは完璧になり、ゲーム中だけ全部豆腐になる。 全1,787パッケージを開いてクラス名で走査すると、実グリフとレイアウトを持つ DefineFont3は全部で12個しかなかった。

Coalesced.int — XOR難読化コンテナ

TransGame/Localization/Cooked/PC/ にある1ファイルに、 30個のローカライズファイルが丸ごと入っている。 構造は件数 → (名前, 中身) の繰り返しという単純なもので、 文字列は長さの符号でエンコードが切り替わる。

鍵は61文字の文字列で、実行ファイルの.rdataにUTF-16でそのまま入っていた。 統計で復元した鍵と一致したので、解析が正しいことの確認にもなった。 そして負長＝UTF-16で書けば日本語コードポイントがそのまま通る—— 言語スロットを増やす必要も、エンコード変換も要らない。

UE3パッケージ（ver 846/181）で踏んだ点

Scaleform の DefineFont3 — 出荷フォントと比較して初めて分かった点

自作エンコーダで出荷フォントを書き戻し、バイト差分を取って2つのバグを見つけた。 推測では絶対に当たらない値だった。

UCanvas の Font と DXT5 アトラス

ゲーム中のセリフ字幕は Scaleform ではなく UCanvas が描いている。 UI_TransEngineFonts_p.xxxにあるのはピクセルを持たない抜け殻で、 本物はStartup_int.xxxにシークフリーで焼き込まれていた（371文字＋512×512 DXT5）。 出荷時のCharRemapはコード0〜8482しか持たないので、 日本語が透明になり?と!だけ残るという症状になる。

配置の規則は実測で決まる。矩形は Y + VerticalOffset に描かれ、 ベースラインは行頭から24px（. A B のインク下端が揃う行）。 USizeは送り幅であってインク幅ではない——ここを間違えると字が隣とくっつく。 アトラスは1024×2048に拡張し、出荷ページをDXT5ブロック単位で左上にコピーしてから 日本語1,496字を下に詰めた。出荷ピクセルは1バイトも再エンコードしていない。

道具立て

全体像 — 4つの面がすべて別系統

言語コードは実行ファイル側で弾かれる → 既定言語を上書きする

GCEngine.ini（ドキュメント\My Games\HOMEFRONT\GCGame\Config\）の Language=jpn は設定しても無視される（PC版は日本語が未対応言語）。 そこで既定言語 int の中身そのものを日本語に差し替える方式にした。 Coalesced_jpn.bin を Coalesced_int.bin として配置するだけでは足りず、 中に埋め込まれたファイルパス文字列（...\Localization\JPN\...）も INT に書き換える必要がある（そうしないと参照が解決できず、 画面に ?int?ui_frontend.MainMenu.ResumeGame? のような生キーが出る）。

フォントの供給元は IpDrv_LOC_int.upk だった

ゲーム全体でFontオブジェクトを持つのは17パッケージ・150個。そのうち EngineFonts.upk / UI_Fonts.upk / PC_UI_Fonts.upk は ランダムバイトで丸ごと破壊しても平然と起動する＝一切読まれていない。 実際に描画に使われていたのは IpDrv_LOC_int.upk（IpDrv は 本来ネットワーク用パッケージの名前）で、ここを無効化すると メニュー・ムービー字幕・会話字幕の全てが同時に消えた。 名前からは絶対に推測できないので、破壊テスト以外に特定手段が無かった。

UE3 パッケージ（ver 576/100）のバイト構造

まずGildorの decompress.exe で解凍する（配布状態は圧縮されており、 UE Explorer等は「compressed packages are not supported」で開けない。umodelは透過的に 解凍して読むので気づきにくい）。以下は解凍後のエクスポートデータの構造。

ArrayPropertyに要素型の情報が埋まっていないのがこのバージョンの特徴で、 要素の型はクラス定義側を知らないと分からない（UE ExplorerがFontの配列を 読めないのもこれが理由）。逆に言えば、型さえ分かれば手書きパーサーで十分扱える。

会話字幕 — 10言語が全部入っていて、インデックスで選ばれる

各 SoundNodeWave の LocalizedSubtitles に、 英・日・独・仏・伊・露・波・チェコ・西・蘭の10言語が最初から格納されていた。 しかも各要素にLanguageExt（言語名）が無く、純粋に配列の並び順で選択している。 つまり日本語（添字1）を先頭（添字0）と入れ替えるだけで日本語字幕になる。 2要素の入れ替えなので配列全体のサイズが変わらず、オフセット修正が完全に不要だった。

対象は Maps\SP\<ミッション>\*_LOC_int.upk の261パッケージ。 うち81パッケージ・1764件に日本語が存在した（残りは効果音のみで字幕を持たない）。 入れ替え対象は「添字1」と決め打ちせず実際に日本語文字を含む要素を正規表現で探して 先頭と交換する実装にした（既に適用済みのファイルを二度処理しても安全になる）。

Coalesced_*.bin の構造（読み書き可能）

.iniファイルとローカライズファイルをまとめて格納したもの。構造は単純で、 パース→編集→再構築が問題なくできる。無編集で往復して元ファイルとバイト単位で一致することを 確認してから編集に入ると安全（文字列ごとにASCII／UTF-16が混在しているので、 元のエンコーディングを保持して書き戻す必要がある）。

公式の日本語データにキーそのものが存在しないケースもあった （PC版限定の「NEWS」項目は家庭用機版に無いため）。この構造が書けるようになっていれば、 キーを1つ追加するだけで解決できる。

道具立て

アーカイブの実体はZIP、上書きはロケールフォルダの重ね置き

拡張子.groの独自アーカイブはPK\x03\x04で始まるただのZIP。 優先順位はファイル名のアルファベット順（後勝ち）で、パッチファイル名が採番規則に 沿っていたのでファイル名ソート＝適用順のまま扱えた。ローカライズは Content/<Game>/Locales/<言語名>/以下に、上書きしたい元のパスを まるごと再現した相対パスで同名ファイルを置くだけで成立する仕組み （str_strCurrentLocaleを言語名に設定すると読み込まれる）。 2007年の実装がこの重ね置き方式のまま現行版でも通用するかは、 現行パッチに同梱されていたドイツ語ロケールの実例で確認できた （公式が同じ仕組みで最近ドイツ語を追加していた）。

旧訳と現行版の差分は「Diffで機械的に」出す

2005年オリジナル版と現行パッチ後の英語原文を全ファイルdiffしたところ、 2,700行超あるゲーム内テキストのうち実質的な文面変更はスペルミス修正2件だけで、 残りは改行コードの正規化のみだった。つまり旧訳の9割以上はそのまま現行パスに 置き直すだけで再利用できると判断でき、机上の勘ではなく実際のdiff結果を根拠にできた。 一方でフォルダ名変更（1ステージ）・新規追加コンテンツ（マルチプレイ専用ステージ、 新設の図鑑機能）は旧訳に対応が無いため新規翻訳が必要と機械的に切り分けられた。 「移植」案件では、真っ先に新旧の原文差分を取ってから作業量を見積もる。

フォント — 詳しくは前半セクション参照

同梱のSeriousEditor2.exeにビットマップフォント生成機能があったため、 形式のバイナリ解析は一切不要だった。手順・UTF-16の罠・アトラス容量の罠は 前半の「フォントを用意する」節に一般化して書いた通り。9種類のフォント （通常/HD/メニュー用/サーバー一覧用/コンソール用など用途別）を同一の文字集合・ 同一ツールで作り分けた。

未翻訳の取りこぼしは「機械的に洗い出す」

旧訳のテーブルファイル（key=value形式、UTF-8 BOM付き）は一見ほぼ翻訳済みに見えたが、 値に日本語文字を1文字も含まない行を機械的に抽出したところ、 3ファイル合計で1,500行超が未翻訳のまま放置されていることが分かった （メニュー項目・HUDメッセージ・アイテム取得通知など）。目視や「だいたい訳してある」 という印象では気付けない規模。「翻訳済みらしきファイル」でも、 未翻訳行の自動検出を1回はかけてから完了と判断する。

道具立て

テキストの供給元は2系統

原文テキスト自体はvm_Data/StreamingAssets/Stories/*.html（Twine形式）に 平文で入っていたので、翻訳の抽出はデータから、表示の差し替えは実行時から、という ハイブリッドになった。メニュー系の文言は.assets内に散っていたため、 長さプレフィックス付き文字列としてバイナリ走査して回収した。

「訳したのに英語で出る」の3つの原因

これが本件の全て。どれも訳文は最初から完成しており、キーが違っていただけだった。 そして3つとも、実行時ログと辞書の突き合わせで判明した—— 静的解析や推測では1つも当てられなかった。

VR対応 — 「画面に描く」では映らない

依頼者の初VR起動で翻訳が1文字も表示されないことが判明した。 OnGUIはデスクトップのウィンドウにしか描かれないので、 元の英語を消した結果、ゴーグルの中は空欄になっていた。 非VRのスクリーンショットでは完璧に見えており、それまでの検証では一度も踏まなかった。

対処は訳文のテクスチャを板にして、置き換えた要素の子として3D空間に置くこと。 一般化した手順・大きさと奥行きの決め方・切り分け方は前半の 「実行時フック方式」に書いた。この作品固有の値は次の通り。

口調の統一 — 14キャラを統計で揃える

依頼者から「AIキャラの口調が時々変わる」と指摘され、 話者ごとの台詞抽出 → 文末の丁寧語／常体の自動分類 → 多数派に少数派を寄せる という手順で224件を修正した（手法の一般化は前半に記載）。 タグ修正で復活した1,669件は、この監査を受けていなかったため、 キーの修正後に監査をやり直す必要があった—— 「表示されていなかったテキスト」は品質チェックからも漏れている、という当たり前だが 見落としやすい話。

最終状態

道具立て

封印の正体 — 言語テーブルが26言語で打ち切られていた

設定ファイルで言語を日本語（enum値26）に強制すると、起動時に KeyNotFoundException at MyLanguage.LoadLanguage で落ちた。 VRage.dll の MyTexts 静的コンストラクタを読むと、 AddLanguage(...) が English から ChineseChina まで26回並んで終わっていた。 MyLanguagesEnum.Japanese = 26 は定義されているのに、登録行だけが無い。

選択肢に出ない理由も同じところにあった。 MyTexts.LoadSupportedLanguages() は Localization/*.resx のファイル名から ja-JP を拾い、 カルチャ名→言語IDの辞書を引くという実装で、その辞書も同じAddLanguageが作っている。 つまり1行足すだけで「一覧に出る」と「読み込める」が同時に直る。

最大の罠 — NGenネイティブイメージ

ILパッチを当てて起動してもまったく同じ場所で同じように落ち続けた。 デプロイ済みDLLのMD5は正しい。PowerShellでリフレクションして m_languageIdToLanguage を覗くとちゃんと27件あって日本語も入っている。 それでもゲームだけが旧挙動——という状態で1時間溶かした。 詳細と回避策（MVIDを変える／効いていれば壊れる仕掛けで1手で確定させる）は 前半の「.NET / IL解析が必要な時」に一般化して書いた。

ローカライズの構造 — .resx を3段に重ねる

この重ね方のおかげで未訳キーは自動的に英語で出る—— 「未翻訳は必ず原文へフォールバック」を自前で実装する必要がない。 逆に言えばja-JP側にキーが無いこと自体が「意図的に英語のまま」の表明になるので、 訳さないと決めたものは書かないのが正しい（235件をこの扱いにした）。

翻訳の内訳

フォント — 出荷状態ですら269字が足りていなかった

FontDataJP（4ページ・1,450グリフ）に対して、 同梱の公式日本語テキストが使っている文字のうち269字にグリフが無い。 つまりこのゲームは、日本語を有効にできたとしても最初から一部が豆腐になる状態だった。 自分の訳文を足すと不足は306字になったので、新しいページ（FontDataJP-4.dds）を 1枚追加して全部そこに置いた。出荷済みの4ページは1バイトも触っていない。

シナリオは第二のローカライズ系統を持っていた

本体を配布した後で「進行表示だけ英語」と指摘されて発覚した。 シナリオのテキストはContent/Data/Localizationではなく 各シナリオのLocalization/フォルダにあり、 <Context>.sbl（マニフェスト）＋<Context>.resxの対で、 言語ごとに<Context>.<lang>.sbl／.resxを並べる方式。 9言語ぶんが揃っている中で日本語だけ0枚だった。一般化した話は前半の 「コンテンツ同梱のローカライズを見つける」の節に書いた。

Frostbite（DLC）だけはこの仕組みを持たず、目標文がビジュアルスクリプトに 直書きされていた。同じノード種別に出現させるプレハブ名も入っていたため、 出力先が表示系の関数かどうかをグラフで辿って25件だけを書き換えた。

配布後の報告で分かった2つのこと

プレイ中の人から「左上のクエストログ（"Good.bot: Remote Control"）が英語」と報告された。 文面は訳文ファイルに入っていたので、翻訳漏れではなかった。

• セーブが言語を凍結していた——MyLocalizationSessionComponentが開始時の .sbl一覧をCampaignPathsとしてセーブし、ロード時はそれしか読まない。 MyHudQuestlogは解決済みの文字列を保存・復元する。 対処はVRage.Game.dllのMyLocalization.LoadBundle先頭に 「隣の.ja.sblを足す」メソッド呼び出しを注入（補助メソッドは .NET Framework の cscでC#からビルドし、dnlibで命令・例外ハンドラごと複製して埋め込んだ）＋ インストーラーでの既存セーブのクエストログ置換（846→907件の対応表）。 英語のまま始めたセーブから、次のクエストが日本語で出ることを実機で確認した。
• スクリプト直書きはFrostbite以外にもあった——関数ノードの引数という第二の置き場所に。 vs_build.pyで全シナリオと共通スクリプトを対象に、定数59・複製1・直書き引数77の 計137か所（30ファイル）に広げた。Scrap RaceのHUDボードが 「建造フェーズ開始まで 4 分」と表示されるところまで確認。

道具立て

以降は3作それぞれの解析結果を、判明した順・確定した仕様のまま詳細に残したもの。 新しいUnity製ゲームに当たった時は、特に「Lucius II」「Lucius III」の節を先に見ると 具体的なコード例（UnityPyの使い方、IL解析の実例）がそのまま使える。

エンジンが変わったので、資産の扱いに関わるコードは全滅した。逆に、 作業の進め方とQAの仕組みはそのまま効いた。前作で一番時間を食ったのは 「フォント形式の解読」だったが、Lucius IIではそのフォント問題自体が存在しなかった （標準ダイナミックフォント）。代わりに時間を食ったのはバイナリテーブル構造の解読だった — 山場は「フォント」から「データ構造」に移った、というのが実際の結果。

その後Homefrontでは「使われている資産の特定」、Deadpoolでは「パッケージの書き戻し方」、 Serious Sam 2では「同梱エディタでのフォント再生成」、Vox Machinaeでは 「訳文は正しいのにキーが違う、の究明」が山場になった。 毎回どこが山場になるかは事前に分からないというのが7作通じての結論。

テキストの格納

ゲーム内テキストは ほぼ全部が1ファイルに入っていた。台詞だけでなくメニュー・アイテム説明・ チュートリアル・章タイトル・謎かけ・ナレーションまで含めて965行。

FONT v2 形式（完全仕様）

最大の壁だった。Data/fonts/*.font は Esenthel 独自のビットマップアトラス形式。 原版は漢字 20,940 字を持ちながらひらがな・カタカナが1文字も無い（中国語対応時に漢字だけ足したため）。 以下は既存3フォントをバイト単位で誤差ゼロにパースできた確定仕様。

矩形の関係式は rect幅 = width + padd_l + padd_r、 rect高 = height + padd_t + padd_b。ミップは 最小4×4にパディングされる （ここを外すとサイズ計算が合わない）。グリフは文字集合を渡した順に並ぶ、ソートされていない。 アトラスは白抜き文字で、RGBとアルファの両方に同じカバレッジが入っている。

誤った仮説を2回引いて、2回とも実機のクラッシュか "MISSING TRANSLATION" で気づいたので、 以下は最終的に正しかった仕様と、その過程で踏んだ地雷を分けて書く。

構成（確定）

ローカライズテーブルの構造（バイト単位で確定）

文字列は全て u32 LE 長さ + UTF-8バイト列 + 次の4バイト境界までゼロ埋め。 エントリはカテゴリキー・翻訳数・翻訳配列・検索キーの4部構成で、カテゴリキーは 同じ値（"HUD" 等）が何百回も繰り返し出現する。

パース開始位置は data.find(b"ItemDescrpition") - 4。 終了はraw dataの末尾ちょうどで、境界を1バイトも余さず消費できていれば、パーサーが正しい証拠になる。

検索の仕組み — なぜ original を触ってはいけないか

CutsceneHandler.CheckSub() → Localizator.Get.Translate(text)。 Translate() は渡された文字列を正規化して Dictionary<string, LocalObject> を引き、 translations[CurrentLanguage] を返す。辞書のキーは原文（英語）そのもので、 字幕データやミッション文字列は常に英語のまま渡される。 正しい対処は常に translations[0] だけを書き換え、original には一切触れないこと。

書き換えの安全な手順（UnityPy）

import UnityPy

env = UnityPy.load(path)          # 読み込みと書き込みは別ファイルにすること
target = None
for obj in env.objects:
    if obj.type.name == "MonoBehaviour":
        try:
            raw = obj.get_raw_data()   # TypeTree不要、生バイト列がそのまま取れる
        except Exception:
            continue
        if b"ItemDescrpition" in raw:
            target = obj
            break

raw = target.get_raw_data()
new_raw = rebuild(raw, translate_fn)   # 独自パーサーでエントリ単位に再構築
target.set_raw_data(new_raw)

result = env.file.save()               # オブジェクトテーブルを自動で再計算
with open(tmp_path, "wb") as f:
    f.write(result)
# tmp_path はここで初めて os.replace() で元のファイルへ

翻訳の規模（確定）

テキストの格納（激変）

Lucius3_Data/StreamingAssets/Localization/ に7言語のファイルが アセットパック外の平文で置かれている。UnityPyも逆コンパイラも不要。 CSVと名乗ってはいるが中身は id|original|translation という単純なパイプ区切り （引用符エスケープなし）。UTF-8・BOM無し・CRLF。

言語メニューは動的列挙 — ファイルを1個足すだけで日本語化できた

Menu_LanguageSelector.Start() はドロップダウンの選択肢を、 フォルダをスキャンして集めたファイル名一覧でそのまま埋めている。 ハードコードされた言語リストが存在しないため、日本語.csv を1つ置くだけで 設定メニューに「日本語」が自動的に増える。既存ファイルには一切触れず、 新規追加だけで完結した（バックアップという概念そのものが不要になった唯一のケース）。

UIの再翻訳タイミングに注意

言語を切り替えた直後は選択中の項目名だけが更新され、周囲のラベルは英語のままだった。 設定パネルを確定してメニューに戻ると画面全体が正しく再翻訳される。 LocalizeComponent は常時ポーリングせず、パネルの再表示（OnEnable）を トリガーに翻訳し直す設計と見られる。この遅延を「翻訳が効いていない」と早合点しないこと。