テキストフリーズとボイス収録 — 一行の変更が波及する範囲

英語版の収録から3週間後、ライターが1行だけ直したいと言ってきます。実際、直したほうが良い行です。表現が鋭くなり、2章あとのシーンとの小さな矛盾も解消されます。プロデューサーは4秒でOKを出します。テキスト文書の上では、1行は1行だからです。

その日のうちに制作進行が答えなければならないのは、その1行が何に触れているかです。9言語の翻訳済みテキスト、収録済みの英語音声、すでに録り終えた2言語の吹き替え、旧タイミングに合わせて作ったリップシンク、字幕ファイル、そして言語ごとのLQA。正直な答えは「1時間の作業」ではありません。「1週間とスタジオの押さえ直し」です。

テキストフリーズは、この計算をOKを出した後ではなく前に見えるようにするための仕組みです。脚本を良くするのを禁じるルールではありません。改善を、見た目どおりのコストで済む期間に寄せるための装置であり、本当に高価な1週間を払う価値のある変更をするときには、同意する全員がそれを払うと分かって同意している状態を作るためのものです。

1行の変更の下流に何があるか

フリーズを設計する前に、自分のプロジェクトの連鎖を一度書き出してみてください。ほとんどのチームは2〜3工程分、これを少なく見積もっています。ローカライズと収録が動き出したあとの1行は、次のすべてに繋がっています。

• 出荷する全言語への翻訳 — 言語ごとに発注・納品・レビューが発生し、ミニマムチャージがあるため1行の依頼は不釣り合いに高くつく
• 原語での収録 — 予約、声優のスケジュール、スタジオの枠、ディレクターの時間
• 吹き替えを行う各言語での収録 — 同じことが言語の数だけ、それぞれ別の制約付きで繰り返される
• 音声の後工程 — 編集、加工、ファイル命名、新しいテイクのビルドへの組み込み
• 旧音声に合わせて作ったすべて — リップシンク、カットシーンの尺、字幕キュー、そのセリフを起点に動くアニメーションイベント
• 全言語のLQA — 変更された行は、それが出るすべての場所で、もう一度文脈の中で確認し直す必要がある

収録が始まった瞬間に起きる、もう少し分かりにくい変化もあります。収録前は、テキスト文書が正の情報源です。収録後は、少なくともボイスのある行については音声が正になり、テキストのほうが「すでに物理的に存在するものの説明」に変わります。聞こえてくる音声と読める字幕がずれていれば、プレイヤーはすぐ気づいて報告します。特に、原語音声のまま自分の言語の字幕で遊ぶという相当大きな層がいます。

ボイスありコンテンツのフリーズを他と同じ日に置けないのはこのためです。儀式として厳しくしているのではなく、守っている対象がやり直しに時間も費用もかかるから前倒しになっているだけです。

一度に全部ではなく、段階的に凍らせる

全テキストを1つの日付で凍らせるのは最もよくある設計であり、最も高い確率で破られる設計でもあります。UIが完成する何か月も前にUI文字列を凍らせるほど早いか(例外が確実に発生します)、収録をまったく守れないほど遅いかのどちらかになるからです。そして日常的に破られるフリーズは、情報として機能しなくなります。あの日付は目安だと全員が学習し、日付に添えたコスト警告も読まれなくなります。

下流で何に繋がっているかに応じて、コンテンツの種類ごとに段階を分けてください。

• ボイスのある物語テキスト — 最初に凍らせる。全言語の収録に繋がっているため
• ボイスのない物語・アイテム・設定テキスト — 次。収録ではなく翻訳のリードタイムで決まる
• UI・システム文字列 — さらに後ろ。ただしそれを含む翻訳の受け渡しよりは前。性質上どうしても遅くまで動くので、変わらない前提を置かず、UI専用の最終パスを計画に入れる
• プラットフォーム指定文言・法的文言 — 提出期限で決まる独自の日付。社内スケジュールでは動かせない
• ストアページ・宣伝文 — 完全に別トラック。ビルドのフリーズに含めず、これのせいでビルドを止めない

各段階には、日付と、例外を承認できる担当者の名前が必要です。日付に持ち主がいなければ、そのフリーズはその場に居合わせた人によって運用されることになり、実際には若手には適用され、上位者には適用されない運用になります。

日付を伝えるときは、いつかだけでなく何を守っているかを添えてください。「3月2日がテキストフリーズです」と告知された日付は事務手続きとして扱われます。「3月2日以降、ボイスのある行の変更には収録2セッションと4言語の更新がかかります」と告知された日付は世界についての事実として扱われ、人は事実のほうを前提に計画を立てます。

フリーズを持たせるのは例外手続きのほう

絶対のフリーズは必ず迂回されます。個別の相談、貸し借り、共有シートへの静かな書き換え。そして迂回された変更は、承認された変更よりはるかに危険です。一部の言語にだけ反映され、他の言語には反映されないからです。迂回するより手続きを通すほうが楽になるように、例外の経路を意図して設計してください。

手続きに必要なのは4つです。誰が変更を申請できるか、申請に何を書かなければならないか、誰が承認するか、そして毎回議論するのではなく自動的に添付されるコストの提示。申請にはシーンの説明ではなく該当する文字列キーを書かせてください。説明だと誰かが脚本を探しに行くことになり、探している最中に別の行が編集されます。

件数を管理可能に保つのは分類です。3種類あれば足ります。

• クラスA — 事実誤り、法的な問題、プラットフォーム規定違反、意味が通らない誤り。無条件で受け入れ、コストは飲む。議論しない
• クラスB — 意味は通るが、ゲームの仕組みや物語の事実についてプレイヤーを実際に誤解させる。コストを算出し、予算権限のある人が見たうえで受け入れる
• クラスC — もっと良くできる。発売後のテキストアップデート、または次のピックアップ収録の枠にまとめる

分類は、その行を書いた本人以外が行ってください。書き手は自分の改善案をクラスCと判定するのが構造的に苦手です。自己愛の問題ではなく、改善の良さは本人にとって鮮明で、下流のコストは抽象的だからです。判断を制作側に置き、ライターが主張する側に回る形にすると、両方向で判断の質が上がります。本当に重要なクラスAの変更が、磨き込みの申請の山に埋もれて見落とされることも減ります。

承認したすべての例外を、コストつきの一覧として見える場所に残してください。二つの効果があります。累計コストが壁に貼り出されているとクラスCの申請は自然に減ります。そしてこの一覧は、次のプロジェクトで「なぜ今回よりフリーズを2週間早くするのか」と聞かれたときの根拠になります。

テキストの変更とボイスの変更は別の請求書

この2つは、変更について話すときに意識して分けておく価値があります。ひとまとめにすると、あらゆる変更が同じくらい高価に感じられ、チームが「とにかく却下」の方向に寄ってしまうからです。

テキストのみの変更 — ボイスのない行や、字幕のみで出す言語 — にかかるのは、翻訳、レビュー、組み込み、LQAの確認です。言語の数だけ実作業は発生しますが、範囲は閉じていますし、他人のカレンダーに依存しません。

ボイスのある行の変更は、それに加えてセッションが1つ必要になります。そしてセッションには下限があります。声優とディレクターに1行のために戻ってきてもらう費用は、20行のために戻ってきてもらう費用とほとんど変わりません。高いのは読む作業ではなく、日程調整、準備、最低予約枠だからです。この事実だけで工程全体の形が決まります。ピックアップ収録を変更1件ずつでやってはいけません。

代わりに、フリーズ日以降のリテイク候補を継続的にリスト化し、ピックアップ収録の枠をあらかじめカレンダーに載せておきます。変更が出てから空きを探すのではなく、声優のスケジュールまで確定させて先に押さえておくのです。ピックアップ収録の翌日に来た変更は次の枠まで待つ変更になりますが、次の枠の日付が分かっていれば、その待ちは危機ではなく単なる日程の事実になります。

そして、追い詰められた場面で議論する前に、方針を一つだけ先に決めておいてください。収録済み音声と改善後のテキストが食い違ったとき、字幕はどちらに合わせるのか。多くのチームでは答えは「字幕は音声に合わせる」です。目に見えるずれはプレイヤーが報告するバグですが、少し洗練されていない言い回しはバグではないからです。どちらを選ぶにせよ、一度決めて文書化してください。行ごとに判断すると、音声と一致する字幕としない字幕が混在するビルドになり、どちらか一方に統一するより悪い結果になります。

翻訳と収録は並走するので、波及は掛け算になる

フリーズが必要になるほど詰まったスケジュールでは、全言語が同じ工程にいることはありません。原文が変わったとき、言語4は翻訳の途中、言語6は納品・レビュー済み、言語2は旧セリフの吹き替えを収録済み、ということが普通に起きます。つまり同じ原文の修正でも、言語ごとにコストも対処も違います。そして典型的な失敗は、手が届きやすい言語にだけ反映し、そうでない言語を忘れることです。

これを抑えるのは3つの習慣です。第一に、原文をその場で書き換えるのではなく変更IDを振ってバージョン管理し、下流の各担当が「自分が作業したバージョンから何が変わったか」を問い合わせられるようにすること。第二に、翻訳会社と収録の進行担当が購読する変更ログを、決まった周期で発行すること。変更がない週も「今週は変更なし」と書いて送ってください。沈黙は曖昧ですが、明示的な「変更なし」は情報です。第三に、収録状況を文字列レコード自体に持たせること。そうすれば、その行を見た人は、変更を提案する前にそれがいくらかかるかを見られます。

# 変更のコストが見える文字列レコード

key:            ch03.mira.betrayal.012
原文:           You knew. The whole time, you knew.
原文ステータス: FROZEN (2026-03-02)

ボイス:         en  収録済 2026-03-18 (スタジオA / 声優確定)
                ja  収録済 2026-04-02
                de  予定   2026-05-11
                fr, es, pt-BR, ko, zh-Hans, ru  字幕のみ

翻訳:           ja 納品済 | de 納品済 | fr レビュー中
                es 作業中 | pt-BR, ko, zh-Hans, ru 未着手

音声に合わせた資産: カットシーン CS-0311(リップシンク)、字幕キュー 03-14

変更コスト:     収録のやり直し2セッション + 予約1件の変更
                9言語の更新 + 9言語のLQA + カットシーン1本の再編集

この領域で最も被害が大きい習慣は、原文の変更を共有スプレッドシートの書き換えだけで済ませ、何も告知しないことです。効率的に感じられますが、これが「8言語では正しく、9言語目だけ古いまま出荷される」の作られ方です。その9言語目の会社は、たまたまその朝に作業用ファイルを書き出していただけです。原文の変更は、下流が手元に持っているものとの差分が静かに生まれる「状態」ではなく、告知しなければならない「イベント」として扱ってください。

フリーズ日が来る前に決めておくこと

ここまでのほとんどは、事前に用意すれば安く、混乱の最中に発明しようとすると高くつきます。スケジュール上の最初のフリーズ日より前に、以下が文書として存在し、制作側だけでなくライターにも共有されている状態にしてください。

• 段階ごとのフリーズ日と、それぞれが何を守っているか、例外を承認するのは誰か
• 例外申請のフォーム、3つのクラス、そして分類する人(執筆者本人以外)
• 提出までのピックアップ収録の枠がカレンダーに載っていて、声優のスケジュールも確定していること
• 音声と字幕が食い違ったときにどちらを優先するかの方針
• 変更ログの発行周期と配布先(すべての翻訳会社と収録の進行担当を含む)
• 言語ごとの「納品済み」の定義。翻訳が終わっただけの言語を、文脈レビュー済みと取り違えないため

これらはどれも、変更をゼロにするための仕組みではありません。フリーズ日を迎えてから一行も変わらないプロジェクトは、たいてい自分たちのプレイテストを聞くのをやめています。目指すのは「不意打ちの変更がゼロ」であることです。起きた変更はすべて、誰かがコストを見たうえで選び、必要なすべての場所に、すべての言語で反映され、あとから確認されている。それが守れるスケジュールであり、リリースを守るフリーズと、全員が黙って無視するフリーズの分かれ目です。