ノベルゲーム・テキスト主体の物語ゲームのローカライズ

ノベルゲームやセリフ主体の物語ゲームは、主に文章量の面で他の多くのジャンルとは異なるローカライズの問題を抱えます。アクションゲームがUIとアイテムのテキストで数千語程度であるのに対し、中規模のノベルゲームは数十万語に達することが珍しくなく、分岐ルートを含めると100万語を超えることもあります。このジャンル向けのエンジン — オープンソースで最もよく知られるのはRen'Pyで、セリフの多いRPGツクール製作品も同じ形の問題に直面します — は一般に、台本やセリフを話者情報付きの構造化されたテキストファイルとして扱う設計になっており、これはこの文章量にとって理にかなった形ですが、それでも文章量そのものが特定の技術的仕組みよりも中心的な課題になります。

この記事では、セリフが補助的な要素ではなくゲームの大半を占めるときに何が変わるかを扱います。大規模化したときの一貫性、テキストボックスの制約、日本語特有の組版の考慮事項、そして翻訳が始まった後に台本が編集される場合に差分の追跡が譲れない理由です。

大規模化したときの一貫性こそが本当の課題

数十万語規模になると、台本全体を1人の翻訳者が頭の中に収めることは不可能で、小規模なチームでも各自が別の章やルートを並行して担当することになります。意図的な対策なしにこれをやると起きるのが「ぶれ」です。あるキャラクターの話し方が途中から変わってしまう、アイテム名や地名が2通りに訳される、同じ人間関係のはずなのに敬称や呼び方が一貫しない、といった具合です。

解決策は才能を増やすことではなく、構造を増やすことです。人名・地名・繰り返し登場する用語を集めた、権威ある扱いをされ、用語が登場した瞬間に更新される共有の用語集。担当するキャラクターのために、そのキャラクターに関わる全翻訳者が見つけられる場所に置かれたキャラクターボイスのメモ(丁寧さのレベル、口癖、好んで使う語彙)。そして、ある1章の中の正しさだけでなく、章をまたいだ一貫性を specifically チェックするレビュー工程 — 軽量なものでも構いません。

話者情報はデータであって装飾ではない

きちんと構造化されたノベルゲームの台本では、すべてのセリフに話者が紐づいており、その紐づけは画面上の名前タグが誰であるかを示す以上の意味を持ちます。翻訳者にどのキャラクターの声で書くべきかを伝え、キャラクター固有の語彙集がどのキャラクターを参照すればよいかの手がかりになり、そもそも自動的な一貫性チェックを可能にするのもこのデータです。誰が話しているかがデータとして分からなければ、あるキャラクターのシーン途中でのトーンの変化を検出することはできません。

話者情報はシーンの文脈から暗黙的に読み取るものや地の文に埋め込むものではなく、構造化されたデータとして保持してください。話者が付いていない迷子のセリフや、内容としては正しくても台本全体で表記形式が揺れている話者タグは、その上に構築されたあらゆるツールを静かに壊します。

テキストボックスの長さ制限は本物の制約であって目安ではない

セリフは通常、固定サイズのテキストボックス内に表示され、画面の一部を立ち絵が占めることもあります。リサイズされうるUIラベルとは違い、ノベルゲームのダイアログボックスには1行あたりの文字数や行数に実務上の上限があることが多く、それを超えるとぎこちないスクロールになったり、はみ出したり、自動縮小されて読めなくなったりします。ボックスに無理なく収まるように書かれた英語の原文が、より長くなる言語に翻訳された途端に収まらなくなることは頻繁に起きますし、逆に簡潔な日本語のセリフが英語に翻訳されて大幅に長くなるという逆方向のケースも起こり得ます。

これは早い段階で、実際のテキストボックス・実際のフォントで、現実的な長さのダミーテキストを使って直接テストしておく価値があります。10万語を翻訳した後にボックスが溢れることが判明するのと、1行目で判明するのとでは、修正コストがまったく違います。

ルビ・ふりがなと日本語特有の組版

日本語が原語であれ訳文であれ関わってくる場合、ルビ(漢字の上に小さく振られる読み仮名)は後付けではなく明示的に計画しておく価値があります。ルビはキャラクター名や造語、あるいは演出上あえて標準とは異なる読み方をさせたい漢字によく使われ、フォントとレンダリング両方の対応に加え、台本のフォーマットの中でルビの対象文字と読みのペアを表現する手段が必要です。ふりがなを創造的に使うプロジェクトであれば(名前を漢字通りではない読み方にする、など)、その対応関係は書式ではなくコンテンツそのものであり、ふりがなという概念が存在しない言語へ翻訳する場合であっても、翻訳・テキスト処理のパイプラインを通じて壊れずに残す必要があります。

ここでこそ差分管理が重要になる理由

物語系の台本は、他のどんな種類のゲームテキストよりも、翻訳開始後に改訂される頻度が高いです。ライターがシーンを引き締めたり、プロットの矛盾を直したり、テンポのためにセリフを書き直したりして、その修正は既に一部または全部が翻訳済みの台本に反映されます。どの行が実際に変わったのかを正確に検出する手段がなければ、チームは念のため章全体を再翻訳する(無駄が多い)か、実際に変わった行を見落とすリスクを負う(もっと悪い結果です。プレイヤーが不一致に気づくまで、古い翻訳が改訂済みの原文の隣に残り続けます)かのどちらかになります。

ここで台本をバージョン管理された構造化データとして扱うことが直接的に効いてきます。各行を確実にフィンガープリント(識別)できる仕組みがあれば、ある行の原文への修正を「この章のどこかが変わった」という曖昧な信号ではなく、その行固有の変更として検出できます。どんなツールを使うにせよ、台本が手作業での差分確認が現実的でなくなる規模になる前に、この性質は必ず備えておくべきです。

• 人名・地名・繰り返し登場する用語のための、積極的に更新される共有用語集
• 話者情報がすべての行で構造化データとして保持され、文脈からの推測に頼らない
• 本物の翻訳が始まる前に、現実的な長さのダミーテキストでテキストボックスの上限を検証済み
• 日本語が原語・訳文いずれかに関わる場合のルビ・ふりがなの明確な計画
• 行単位の変更検出があり、台本の改訂が翻訳を静かに孤立させない