翻訳パッチ（日本語化パッチ）の作り方

翻訳パッチはゲームのコピーではありません。翻訳者の作業そのもの — 行と、どの行がどこに属するかを示すのに足りる情報 — を、ほかの人が自分の手持ちのコピーへ適用できる形にしたものです。呼び名は市場ごとに違います：日本なら「日本語化パッチ」、韓国なら한글패치、中国なら汉化。できあがるものはどこでも同じですし、それを作る仕事も同じです。

パッチには 2 種類あり、この分かれ道がすべてを決める

テキストに手を付ける前に、自分が 2 つのうちどちらを作るのかを決めてください。以降のほぼすべての判断が、ここから決まります。

実行時オーバーレイは、ゲームが動いている最中に翻訳します。ゲームと並んで何かが動き — エンジン内のプラグイン、ゲームのメモリーを読むテキストフック、画面を取り込んでピクセルを読むもの — 描かれる直前の行を捕まえて翻訳へ差し替えます。ディスク上のゲームは何も変わりません。Unity では XUnity.AutoTranslator がよく知られた例で、RPG Maker では MTool がこの方式です。

パッチ済みビルドは、翻訳をゲーム自身のファイルへ入れます。エンジンが実際に読み込むデータからテキストを読み出し、翻訳し、書き戻す。結果として、横で何も動かさなくても単体で起動して遊べるゲームフォルダーができます。これが RuneTranslate の作るものであり、Translator++ も解析できるエンジンでは同じものを作ります。

率直なトレードオフは、こうです：

• オーバーレイはゲームごとの作業が要りません — エンジンにフックできるかできないか、それだけです — が、何も残りません。プレイのたび、マシンのたびに全行が翻訳し直され、プレイヤー全員が自分でオーバーレイを入れて設定する必要があります。
• オーバーレイが届くのは、描かれるその瞬間のテキストだけです。絵に焼き込まれたテキスト、フックしているコンポーネントを通らないテキスト、独自のレンダラーが描くテキストは未翻訳のまま残ります。
• パッチ済みビルドは、エクスポートの手順とテスト一周分のコストがかかり、ゲームが更新されたらやり直しになります。代わりに手に入るものは永続的です：翻訳はファイルが保持しているので、あなたの作業を適用した人にとって、そのゲームはオフラインでただ翻訳済みです。
• パッチ済みビルドは編集できる記録も残します。半年後に 1 行だけ直すのに、ほかを翻訳し直す必要はありません — オーバーレイには直す対象が無く、消すキャッシュがあるだけです。

自分ひとりで、一度きり、解析できないエンジンのゲームを翻訳するなら、オーバーレイは妥当な答えですし、恥じることは何もありません。作ったものをほかの人に渡すつもりなら、パッチ済みビルドの側が要ります — パッチはファイルとして存在して初めて配れるからです。

始める前に必要なもの

• 自分が持っているゲームのコピー。インストールして遊べる状態にしておきます。先に数分プレイしてください — 文脈を見たことがなければ、その訳が正しく読めるかは判断できません。
• どのエンジンを使っているかの知識。テキストがどう出てきてどう戻るか、そのすべてがここで決まります。
• 自分が実際に読めるターゲット言語。機械翻訳が用意してくれるのは下訳であって、パッチではありません。
• ゲームをもう 1 本置けるディスク容量。パッチ済みビルドは別のフォルダーで、元のゲームには手を加えません。

エンジンの見分けは、たいていゲームフォルダーを見るだけで済みます。JSON が入った www/data や data フォルダーなら RPG Maker MV か MZ、<Game>_Data フォルダーなら Unity、game/*.rpy や .rpa アーカイブなら Ren'Py、.xp3 アーカイブなら Kirikiri です。解析できるものの一覧と、それぞれの見分け方はエンジン一覧のページにあります — RuneTranslate は 17 のエンジンと形式に対応していて、フォルダーを指定すれば検出は自動です。

作業の流れ

エンジンが何であれ、パッチ作りは同じ 5 つの手順を同じ順番で踏みます。飛ばしたくなるのは手順 3 です。飛ばさないでください。

1. 抽出 — ゲーム自身のファイルから、翻訳できる文字列をすべて、作業できる一覧に読み出します。
2. 翻訳 — その一覧を機械翻訳のプロバイダーに通し、完全な下訳を得ます。
3. 確認 — 機械が確実に間違える行を見ていきます：名前、敬称、用語、プレースホルダーを含むもの。
4. エクスポート — 翻訳をゲームの形式へ書き戻し、遊べるビルドを作ります。
5. テスト — そのビルドを起動して、実際に遊びます。

抽出

抽出こそ、エンジンの知識が効いてくるところです。セリフがそのままテキストファイルに入っていることは、めったにありません：RPG Maker はイベントのコマンドコードに、Unity はバイナリのアセットファイル内の TextAsset のペイロードや MonoBehaviour のフィールドに、Kirikiri は暗号化アーカイブの中のスクリプトに、Unreal は .pak の中の .locres テーブルに入れています。よい抽出器は、何を渡さないかも知っています — シーン名、変数のキー、比較の被演算子、アセットのパスはどれも文字列に見えますが、翻訳すればどれもゲームを壊します。絵に描き込まれたテキストは別の問題で、別のツールが要ります：画像翻訳をご覧ください。

翻訳

手で直し始める前に、機械翻訳の下訳を一通り作ってください。空の列を眺めるのではなく、文章を直す作業になります。RuneTranslate はプロバイダーを 9 つ備えています — Google、無料の DeepL、DeepL の Classic / 次世代モデルは API キーがまったく要りません。残りは DeepL の API、OpenAI、Anthropic Claude、DeepSeek、OpenAI 互換のエンドポイント、Ollama や LM Studio 経由のローカルモデルです。無料プランでもそのすべてと、すべてのエンジンが使えます。絞られるのはスループットと、プロジェクトを 2 つ以上抱えられない点です。どのプロバイダーがどんなゲームに向くかはプロバイダーの比較で扱っています。

確認

パッチを適用する価値のあるものにするのは、この手順です。機械の出力は流暢で、決まった場所で自信たっぷりに間違えるので、上から順に全部読むのではなく、その場所を狙って作業してください：

• キャラクター名。 機械は見かけるたびに違う訳を当て、ときには言葉として訳してしまいます。表記は一度で決めてしまいます。
• 敬称と口調。 -san / -chan を残すか落とすかはプロジェクト全体の判断で、行ごとの判断ではありません。あるキャラクターが丁寧に話すかどうかも同じです。
• 用語。 スキル、アイテム、地名、システム、そのゲームが作った言葉すべて。メニューとツールチップと戦闘ログで同じスキル名が 3 通りに書かれていると、壊れたゲームに見えます。
• プレースホルダーと制御コード。 \C[1]、{player}、[name] のようなものは、そのまま残らなければいけません。翻訳されたプレースホルダーは誤字ではなく、クラッシュか空白です。
• そのまま返ってきた行。 たいていは擬音語で、たいていはプロバイダーがその行を諦めた印です。

用語の統一

文章の拙さより、表記のぶれで放棄されるパッチのほうが多いです。プレイヤーは硬い文章は許しますが、ひとつの会話の中で同じキャラクターが「ユウキ」「ゆき」「スノウ」になるのは許しません。誰が喋っているのか追えなくなるからです。解決策は用語集です：原文の語と、それが必ずなるべき訳語の一覧を作り、翻訳の前に適用して、プロバイダーに即興の余地を与えません。最初の 1 時間で出会う名前から早めに作り始め、進めながら足していきます — 用語集のガイドでは、タグのマスクとどう関わるか、そしてなぜ最後の置換作業ではなく最初に置くべきかを扱っています。

フォント

日本語のゲームは日本語のフォントを積んでいて、日本語のフォントにはキリル文字、ギリシャ文字、ハングル、タイ文字、あるいはポーランド語・トルコ語・ベトナム語のアクセント付き文字のグリフが無いことがよくあります。そうした言語へ翻訳すると、ゲームは空の四角を描きます — 翻訳は正しく、フォントがそれを描けないだけです。自動で処理されるエンジンもあります：Ren'Py のエクスポートは対応できるフォントを同梱し、ゲームのフォントをそこへ割り当て直します。自動でない場合は、書き出したビルドの中のフォントファイルを差し替えれば、たいてい直ります。文字どおりの疑問符はまったく別の不具合です — グリフ欠けではなく、エンジン自身の文字列エンコーディングがその文字を拒否しています — 見当違いの直し方を探しに行く前に、この違いは知っておく価値があります。どちらもよくある質問で扱っています。

ビルドをテストする

エラーが出なかったエクスポートは、テスト済みのパッチではありません。起動して、静かに壊れるところを確認してください：

• タイトル画面まで進み、ニューゲームが始まる。ここで落ちるビルドは、たいていテキストではなかった行 — 翻訳されてしまった識別子 — が原因です。
• メッセージボックスにテキストが収まっている。翻訳は日本語より長くなります。枠からはみ出したり切れたりしている行を探してください。
• メニュー、アイテム名、ツールチップ — 幅の決まったボタンから長い単語があふれる場所です。
• 元のゲームのセーブデータがまだ読み込め、パッチ済みビルドで作った新しいセーブも読み込める。
• 冒頭だけでなく、ゲームの奥にある場面をひとつ。抽出の漏れはエラーではなく、未翻訳が続く区間として現れます。

成果を配る

ここが、あなたのパッチを人に渡せるかどうかを決める部分です。あなたが作ったのは翻訳 — 行そのものです。ゲームはあなたのものではなく、翻訳済みのコピーをまとめて配ることは、他人のゲームを配布することを意味します。パッチの誠実な形は作業だけを渡すことで、受け取った人がそれぞれ、自分がすでに持っているコピーへ適用します。

RuneTranslate は、まさにそれを .rtpatch ファイルとして書き出します。中身はユニット ID、それぞれの訳が対応する原文の行、そしてあなたの訳です。ゲームのファイルもアセットもバイナリも入っていません — 入っているのはあなたのテキストだけなので、メッセージに添付できるほど小さく、誰にでも安心して渡せます。

受け取る側の手順は 3 つです：

1. 同じゲームの自分の手持ちのコピーからプロジェクトを作ります。これで同じ行が相手のマシン上で抽出されます。
2. あなたの .rtpatch を読み込みます。これで、その行があなたの訳で埋まります。
3. 自分のゲームファイルから、自分の遊べるビルドを書き出します。

照合はまずユニット ID で行われ、ID がずれているとき — ゲームの更新や抽出器の変更 — は原文の行そのものでの照合にフォールバックします。このフォールバックがあるので、ゲームが更新されてもパッチは使えます。読み込みの際にはエンジンとターゲット言語が一致しているかを確認してから適用するので、Unity のゲーム用に作られたパッチを、うっかり Ren'Py のプロジェクトへ落とすことはできません。無料プランでは、パッチの共有は 3 日間のローリングウィンドウで書き出し 1 回・読み込み 1 回に制限されます。パッチ作りのそれ以外の部分は、機能として絞られていません。

同じファイルは、チームで作業するための手段でもあり — ひとりがストーリーを、もうひとりがメニューを訳して、それぞれのパッチを 1 つのプロジェクトへ統合します — ゲームが更新されたときに自分の作業を守る手段でもあります：新しいバージョンから抽出し直し、古いパッチを読み込めば、実際に変わった行だけを見ればよくなります。

ゲーム自体を再配布してよいかどうかは権利者が決めることで、あなたでも私たちでもありません。パッチを配り、どのバージョンのゲームに対して作ったのかを伝え、ゲーム自体は各自で用意してもらってください。

エンジンごとの事情

ここまでが仕事の形です。エンジンごとに違うのは、テキストがどこにあるか、エクスポートが何を作るか、そして何が手の届かないままかで、それはエクスポートに驚かされた後ではなく、始める前に読む価値があります：Unity、RPG Maker、Ren'Py、残り 14 についてはエンジン一覧をどうぞ。

RuneTranslate は Windows 10 / 11、そして Wine や Proton 上の Linux と Steam Deck で動きます。初回起動時に無料の Patreon サインインが必要で、無料プランでもすべてのエンジンとすべてのプロバイダーが開きます。ふだん最初に手が伸びるオーバーレイやツールキットと比べたいなら、比較ページに、それぞれで実際に何が得られるのかをまとめています。