ちゃんとループが閉じる翻訳レビューの仕組みを設計する

何らかの形で翻訳レビューをしているチームは多くても、それを一文で説明できるチームは少ないものです。誰が何を、どんな順序で見るのか、問題が見つかったら何が起きるのか。この明確さがないと、レビューは同じことを三人が黙って重複してチェックするか、逆に本当にゲームを壊す部分を誰も見ないか、どちらかに偏りがちです。

ループが閉じるレビューの仕組みには四つの要素が必要です。誰が何をレビューするかの明確な分担、文脈内でのレビューかスプレッドシートでのレビューかの使い分け、判断を記録して再議論を防ぐ仕組み、そして承認された修正が実際にファイルへ反映される保証です。

言語面のレビューと機能・フォーマット面のレビューを分ける

この二つは求められるスキルも失敗のパターンもまったく異なり、混同すると、希少な能力を持つ人が誰でもできる作業に時間を使うことになります。言語面のレビュー(自然に読めるか、語調は合っているか、用語は正しいか)には、対象言語のネイティブか、それに近い読解力を持つ人が必要です。機能・フォーマット面のレビュー(プレースホルダーが壊れていないか、行がUIに収まるか、実際の画面で想定どおりの場所に文字列が表示されるか)にはビルドを動かせる人が必要で、その言語を読める必要はまったくありません。

この両方を同じ人、多くの場合は翻訳者に任せてしまうと、フォーマットの問題は発見が遅れ(翻訳者はゲーム内表示を見る機会が少ない)、言語面の問題はたまたまファイルを見た人次第で発見にムラが出ます。分離すれば、フォーマットチェックは書き出しのたびに、場合によっては自動で、早く頻繁に回せる一方、言語面のレビューは実際のネイティブ読者による独立した工程としてスケジュールできます。

文脈内でのレビューとスプレッドシートでのレビュー

スプレッドシートや書き出しファイルでのレビューは速く安価です。翻訳者やレビュアーは午後の時間で数百行を通せますし、大量のバッチを見る現実的な方法はこれしかありません。しかし、単独で切り出された文字列のレビューは、それが表示される画面を見ないため、丸ごと見落とすカテゴリの問題があります。カジュアルなキャラクターに対する丁寧すぎる語調、単独では違和感がなくても前の行と並ぶと不自然に読める文、内容としては正しくてもシーンの感情の流れに合っていない翻訳などです。

文脈内レビュー(ビルドをプレイする、あるいは最低でも実際の文字列が入ったスクリーンショットやUIモックアップを見る)はこれらを拾えますが、遅く、サンプルにしか現実的に適用できません。実務的なパターンは、量と一貫性のためのスプレッドシートレビューと、新規コンテンツ・カットシーン・視認性の高いものに対する文脈内レビューを組み合わせ、互いにフィードバックし合う形です。スプレッドシート上で不自然に読める行は、まさに文脈内で確認する価値がある行です。

• 新規または大幅に書き直された台詞: 出荷前に文脈内レビュー
• 大量のUI文字列やアイテム・アビリティ名: 一貫性のためのスプレッドシートレビュー
• スプレッドシートの工程で不確かとフラグが立ったもの: 文脈内レビューへエスカレーション
• チュートリアルと最初の1時間の画面: 量にかかわらず常に文脈内でレビュー

判断を記録し、同じ議論を繰り返さない

長く続くプロジェクトでは、同じ問いが何度も浮上します。この用語は訳すべきか原文言語のまま残すべきか、このキャラクターはプレイヤーに丁寧語で話すべきかカジュアルに話すべきか、このイディオムは許容できるのか差し替えが必要なのか。答えが誰かの記憶や古いチャットのメッセージにしか残っていないと、次のレビュアーはゼロから議論を蒸し返すことになり、答えは気づかないうちに揺れていきます。

短く検索可能な記録 — 用語集の項目、スタイルガイドのメモ、文字列自体に付けたコメント — があれば、一度きりの判断を恒久的なルールに変えられます。凝ったものである必要はなく、用語名、選んだ訳語、その理由を一行にまとめるだけで、同じ会話が三度目に起きるのを止めるには十分なことがほとんどです。

# style-guide.md 抜粋
term: "Guild"
ja: "ギルド"(借用語として維持、訳さない —
      ジャンルの慣習に合わせる、2026年3月決定)

ループを閉じる: 承認された修正を実際のファイルへ

スプレッドシートの承認コメントやチケットのクローズで終わるレビューは、その文言変更がビルドの読み込むファイルに反映されるまでは、実は何も直していません。当たり前に聞こえますが、ここがもっとも壊れやすいステップです。レビューツール上では修正が合意されたのに、誰かが元のファイルへの反映を忘れ、次の書き出しで元の問題がひっそりと復活する、というパターンです。

もっとも安全なのは、承認されたレビューコメントを、プルリクエスト(コードの変更提案とレビューの仕組み)で承認された変更と同じように扱うことです。ファイルへの変更と判断の記録が一つの動作として同時に起きるようにし、誰かが二番目のステップを覚えていることに依存する二つの別々のステップにしないことです。レビューがどのツール上で行われるにせよ、ワークフローは「承認」と「ファイルへの反映」を実質的に同じ出来事にする、あるいはその間に修正がひっそり抜け落ちる隙間ができないくらい近づける必要があります。