ノベルゲームの文字数を数えて、翻訳計画を立てる
ノベルゲームの翻訳の話は、必ず同じ質問から始まります。テキストはどれくらいありますか。多くの開発者はプレイ時間から、あるいはスクリプトフォルダの容量から推測して答えますが、どちらも大きく外れます。プレイ時間には読む速度も演出も音楽も待ち時間も含まれます。ファイルサイズにはコマンドもタグもコメントも空白も含まれます。どちらも、必要とされている数字ではありません。
この数字は、ノベルゲームでは他のジャンル以上に重要です。テキスト主体のゲームでは、翻訳費用も日程もリスクの大半も、そこに比例するからです。そして、そもそもどの計画が選べるかもこの数字が決めます。ある規模までなら1人が通しで訳せますが、その数倍になると通しでは無理で、章や担当者で分割することになり、小さいスクリプトでは起きなかった一貫性の問題が発生します。
この記事では、その数字を誠実に出す方法と、その使い方を扱います。何をテキストとして数えるか、どう抽出して数えるか、分岐と重複をどう扱うか、日本語の文字数と英語のワード数の関係、そして数えた結果をどう実行可能な計画に変えるかです。
数える前に、何を数えるかを決める
合計1つだけでは、重要な判断が隠れてしまいます。区分ごとに数えてください。区分によって難易度も単価も、範囲から外れる可能性も違います。
- 本編スクリプト: 地の文とセリフ。ほとんどのノベルゲームで量の大半を占める
- 選択肢と分岐固有の短い行。量は少ないが、プレイヤーの注意が最も集中する場面に出る
- インターフェース: メニュー、コンフィグ、セーブ・ロード、バックログ、表示速度などの項目名
- 補足コンテンツ: 用語辞典、キャラクター紹介、TIPS、CGギャラリーのキャプション、おまけ
- システムメッセージとエラー文言。何かが失敗したときにしか見えないものも含む
- プラットフォーム側のテキスト: 実績の名称と説明、ストアページ、トレーラーの字幕
- 画像に描き込まれた文字: 章タイトル、看板、文字が焼き込まれたUI素材
数えられる形のファイルを取り出す
目標は、プレイヤーが読むものだけを含むプレーンテキストファイルです。それ以外は落とします。エンジンのコマンド、タグ、ラベル、コメント、変数の代入。そして話者名タグは、何千回も繰り返されて合計を膨らませるので、別枠で数えるか除外します。
使っているエンジンに翻訳用の書き出し機能があるなら、それを使ってください。ノベル向けのエンジンは一般に、翻訳対象の行だけを出力する仕組みを備えており、その出力は定義上ちょうど正しい範囲です。実際に翻訳工程が受け取るものそのものだからです。生のスクリプトファイルを数えると、決して翻訳されないものまで数えることになり、見積もりが2割ほど過大になる典型的な原因になります。
生のスクリプトから数える場合は、この順で落とします。まずコメント、次にエンジンのコマンドとタグ、次にラベルとジャンプ先、最後に空行。そして結果を数ページ読んでから信用してください。除去処理がセリフを半分食べていても、数字は自信たっぷりに出てきます。それに気づく方法は、出力を目で見ることしかありません。
# 1. 翻訳対象の行を書き出す(エンジンの書き出し機能があればそれを使う) # 2. 生のスクリプトからコメント・タグ・ラベル・空行を落とす # 3. 結果を1ページ読んで、消えすぎていないか確認する # 4. 数える wc -m export/script_ja.txt # 日本語原文: 文字数(単語で区切れないため) wc -w export/script_en.txt # 英語原文: ワード数 wc -l export/script_ja.txt # 行数。場面単位で分割するときに便利
分岐・ルート・重複行
分岐のあるノベルは、1回のプレイで表示される量より多くのテキストを抱えています。これが過小見積もりの最も一般的な原因です。翻訳の量は、プレイヤーが見る量ではなく、存在する総量で決まります。共通ルートと4人の個別ルートがあるなら、翻訳者は共通ルートを1回、個別ルート4本をすべて訳します。プレイヤーが何本読むかは関係ありません。
だから合計1つではなく、区画ごとに数えてください。共通ルートと各個別ルートを分け、その中でも章ごとに分ける。合計を出すより手間はかかりますが、すぐに元が取れます。この区画が、納品を日程に落とすときの単位であり、複数の翻訳者に分担させるときの単位であり、部分的な先行リリースが可能かを判断するときの単位でもあるからです。
重複は独立した列にする価値があります。完全に同一の行は、工程側でキー管理されているか、翻訳者が過去の訳文を再利用できるツールを使っていれば、1回訳せば済みます。これが翻訳メモリの働きです。一方、ほぼ同じだが少し違う行にはその恩恵がなく、むしろ完全に新しい文より厄介なこともあります。翻訳者はどこが違うかを毎回確認しなければならないからです。総数と重複を除いた数の両方を出し、その差は「当然受け取れる割引」ではなく判断材料として扱ってください。変数の差だけの行は1回と数えて構いませんが、変種ごとに文脈での確認は必要です。
日本語の文字数と英語のワード数は別の単位
翻訳は、言語ペアや相手によって、原文のワード単価で見積もられることも文字単価で見積もられることもあります。したがって両方の単位で話せる必要があり、同時に、その換算は推定であって計算ではないと理解しておく必要があります。
どこかで見た比率を定数のように当てはめないでください。日本語の文字数と、そこから出てくる英語のワード数の関係は、文体によって変わります。短いセリフ中心のスクリプトと、密度の高い地の文では挙動が違います。漢字と仮名の比率でも変わりますし、キャラクター名や敬称がどれだけ繰り返されるかでも、翻訳者の方針でも変わります。同じ文字数の2作品が、はっきり違う英語ワード数になることは珍しくありません。
現実的な方法は、比率を借りるのではなく自分で測ることです。代表的なサンプル(都合のよい1ページではなく、1シーン丸ごとか短い1章)をきちんと翻訳してもらい、両側を測る。そうすれば自分の文章に基づいた比率が得られ、残り全体に適用できますし、最初の本納品のあとで補正できます。このサンプル翻訳は、次の節で述べる別の理由でも、それ自体に払う価値があります。
同じ測定にはもう1つの用途があります。そこで得られた比率は、テキストボックスをどれだけ伸ばす必要があるかの目安でもあります。翻訳で分量が大きく増えるなら、レイアウトの問題は仮定ではなく現実です。そしてそれは、完成したスクリプトで気づくより、1章で気づくほうがはるかに安く済みます。
数字を計画に変える
数字が計画になるのは、独立して納品・確認・支払いができる単位に分割されたときです。章やルートが自然な境界になります。翻訳者がスクリプト全体を頭に入れなくても作業できる程度に完結していて、予算や日程が変わったときに区切りで止められるからです。
本格的な翻訳を始める前に、3つやってください。固有名詞・地名・用語・造語の表記を決めた用語集を作る。キャラクターの口調表を短く書く(丁寧さの度合い、口癖、相手ごとの呼び方)。そのうえで、パイロットとして1章だけ発注し、丁寧に読む。できれば対象言語を母語とする人と一緒に読みます。パイロットは、口調の問題、敬称の扱い、名前の選択を、修正コストが1章分で済むうちに表に出します。作品全体を訳し終えてから直すのとは、桁が違います。
そして凍結の方針を決めてください。長いスクリプト特有の失敗はここで起きます。翻訳済みの場面に手を入れるたび、すべての言語で手戻りが発生しますし、この規模の作品では文章を磨き続けたい誘惑が常にあります。原文スクリプトをいつ凍結するのか、何を例外と認めるのか、誰が例外を承認するのかを決める。翻訳中も動き続けるスクリプトは、管理可能な文字数を管理不能にする最も確実な方法です。
全部を1枚の表で管理してください。区画ごとに1行。地味ですが、半年かかる翻訳が追跡不能にならないのは、これのおかげです。
章,ルート,行数,文字数,状態,担当,納品日 ch01,共通,412,18240,翻訳済,A,2026-06-03 ch02,共通,388,17110,レビュー中,A, ch03,共通,455,20050,作業中,A, ch04,ミラルート,540,26980,未着手,, ch04,サエルート,502,24310,未着手,, ui,-,180,2400,翻訳済,B,2026-05-28 用語集,-,96,1850,承認済,B,2026-05-20
文字数が教えてくれないこと
文字数が予測できるのは、いま存在するテキストを翻訳する分だけです。実際のコストのいくつかはその外側にあり、丁寧に作った見積もりでも足りなくなる原因は、たいていそこにあります。
最大のものは原文修正による手戻りで、これは分量ではなく凍結の徹底度に比例します。文脈での校正 — 実際のテキストボックスで、実際の改行のまま、ゲーム内で訳文を読む作業 — はワード数ではなく場面数とルート数に比例し、分岐のあるノベルは文字数から想像するよりはるかに多くの状態を抱えています。画像に焼き込まれた文字は翻訳費ではなく制作費のかかる別作業です。ボイスがあるなら、それはまったく別の事業です。そして発売後に追加する章は、すでに対応を決めたすべての言語で新しい文字数を発生させます。
これは数えるなという話ではありません。数字を価格ではなく計画の道具として扱えという話です。どんな形の計画が可能か、どこで作業が割れるか、翻訳者の時間を無駄にせずどんな相談ができるか。それが分かっているだけで、見積もりを取り始める多くのプロジェクトより、はるかに良い状態にあります。