誤訳の報告が届いたら — 受け皿・仕分け・再発防止の作り方
プレイヤーから「ショップ画面のドイツ語がおかしい」とコメントが来ます。別の人は「チュートリアルの一行が本来と逆の意味になっている」と言っています。読めない言語のレビューに大量の高評価が付いていて、機械翻訳にかけてみると翻訳の質を責めているらしい、ということもあります。
最初に来るのは、たいてい気まずさと無力感が混ざった感覚です。問題は実在しているのに、自分には見えないからです。主張の真偽を確かめられず、それが一行だけの話なのか、まとめて品質の低い一括分納品の兆候なのかも分からず、そもそも報告者が正しいのか、半分正しいのか、単なる好みの話なのかも判断できません。
この状態は解消できます。その言語を習得する必要はありません。誤訳報告を扱えるものに変えるのは、受け取りの仕組みです。報告が落ちてくる場所、毎回必ず聞く少数の項目、仕分けの基準、そして三回先のパッチで同じ誤訳が戻ってこないようにする記録。この記事ではその一つひとつを順に見ていきます。
報告が落ちてくる場所を用意する
誤訳の大半は、気づいたプレイヤーが誰にも言わないまま終わっています。気づいた瞬間に、言う場所が見当たらないからです。もっとも効果の大きい一手は、目に見えて手間の少ない窓口を作り、プレイヤーがすでにいる場所でそれを告知することです。固定投稿、パッチノートの一行、そしてできればゲーム内の設定メニューの項目。
窓口の種類そのものより、摩擦の少なさが重要です。メールアドレスよりフォームのほうが優れているのは、必要な項目をこちらから聞けるからです。すでにコミュニティサーバーを運営しているなら専用チャンネルもよく機能します。プレイヤーの負担がほぼゼロで、しかも同じ言語の他の人が「自分もそう思う」「いや自分は気にならない」と反応してくれるからです。うまくいかないのは、クラッシュ報告や機能要望と同じ総合窓口に混ぜることです。必要な処理がまったく違います。
これとは別に、ストアレビューを言語別に読む習慣を作っておきます。ほかに窓口がないとき、翻訳への不満はレビューに書かれます。特定の言語にレビューが固まっているときの信号強度は、個別のメッセージ一通よりはるかに強く、たいていは運の悪い一行ではなく系統的な問題が起きています。
報告を使えるものにする3項目
使えない報告に欠けている情報は、ほぼ毎回同じです。これは後から追加で質問するのではなく、フォームの形で先に防ぐべきものです。実際のところ、追加質問に二度目の返信が来ることはほとんどありません。
必須は3つです。どこに出るか(スクリーンショットが最強です。説明では伝わらない見切れやレイアウト崩れまで写るため)、いま何と書いてあるか、そして本来どうあってほしかったか。3つめが、みんなが省略し、しかも報告を修正に変える唯一の項目です。これがないと、何かが間違っていることは分かっても、正解の形が分かりません。
「少しイラッとしたプレイヤーが最後まで書き切れる」長さに収めてください。この3項目より先はすべて任意で構いません。言語とゲームのバージョンは、選択式や自動入力にしておく価値があります。手で打たせるタイプの摩擦こそが、報告を取りこぼす原因だからです。
誤訳報告フォーム — このくらい短く 1. プレイ中の言語: [選択式] 2. その画面のスクリーンショット: [アップロード] 3. 現在の表示: [自由記入] 4. 本来どうあるべきか(または現在の文が その言語でどういう意味に読めるか): [自由記入] 5. ゲームのバージョン(設定画面に表示): [自動入力] 6. その他あれば(任意)
直す前に仕分ける
「翻訳がおかしい」という形で届く報告は、実際には担当者も対処も違う4種類の問題です。これを混ぜたまま処理することが、開発者が自分の手でテキストを改悪してしまう典型的な経路になります。
- 本当の誤訳 — 原文にないことを言っている、あるいは重要な意味が落ちている。テキスト自体を変える必要があるのはこの分類だけで、必要なのはあなたではなく翻訳者です。
- 好み・語調の相違 — 意味は合っているが、報告者ならこう書く、丁寧すぎる、砕けすぎている、このキャラはこんな喋り方をしない、というもの。複数の話者が同意する場合は動く価値がありますが、強い意見が一つあることは根拠になりません。
- 翻訳の顔をした実装バグ — 変数がそのまま表示されている、ボタンで文字が切れている、別の場所の文字列が出ている、フォールバックで違う言語が出ている、文字コード起因の文字化け。翻訳は正しく、壊れているのはビルドです。これはあなたの担当で、たいてい最速で片づく成果でもあります。
- 文化・文脈上の指摘 — 訳としては正確でも、その地域では受け取られ方が悪い語、名前、記号、ジョーク。辞書ではなく、その市場の人との会話が必要です。
読めない言語の報告をどう判断するか
つい取りたくなる近道は、報告者が書いてくれた修正案をそのままテキストファイルに貼って出すことです。これは避けてください。実力を評価できない他人からの製品への変更を、自分の側の誰もレビューできない経路で受け入れていることになります。そうする人の大半は善意で、提案の多くは実際に良いものですが、ごく一部は元より悪く、さらにごくわずかに、意図的に不快な文言が何か月もゲームの中に残ることがあります。
現実的なルールは、「報告された行は、出荷前に必ず別の独立した話者が確認する」です。すでに翻訳者と取引があるなら、報告をためて月に一度まとめて送ります。これは安く済みます。新規翻訳を頼んでいるのではなく、短い20行への判定を頼んでいるだけだからです。翻訳者がいない場合でも、少量の有償レビューはこの工程全体の中でもっとも安い買い物のひとつです。
機械翻訳はここで一つの用途にだけ役立ちます。その報告がどの分類に入るかの当たりをつけることです。現在の行と提案された行の両方を機械翻訳にかければ、意味の違いなのか文体の好みなのかはたいてい見えるので、優先順位を決めるには十分です。最終的な文言を決めるには足りません。良い翻訳で効いてくる差異は、まさに機械翻訳がならしてしまう部分だからです。
もう一つ、強く重みを置いてよい信号があります。一致です。同じ言語の無関係な3人が同じ行を報告してきたら、確定として扱ってかまいません。逆に1人が20行報告してきた場合は、本当に品質の低い一括分納品かもしれませんし、単に主張の強い1人かもしれません。見分ける方法は、リスト全体を丸ごと受け入れるか却下するかではなく、その一括分から数行を抜き出してレビューにかけることです。
一度直したものを、戻らないように記録する
出したパッチの中にしか存在しない修正は、いずれ取り消される修正です。戻り方はいつも同じです。テキストファイルを書き出しから再生成した、翻訳者が古いベースを元にした更新分を納品した、誰かがバックアップから復元した。そして直したはずの行が静かに元の状態へ戻ります。誰も気づきません。もうその行を見ている人がいないからです。
対策は、素朴な記録です。修正1件につき1行。キー、言語、修正前、修正後、誰が確認したか、日付。データベースである必要はありません。スプレッドシートでも、リポジトリの中のテキストファイルでも構いません。毎回同じ場所であること、そして誰かのDMの中ではなくプロジェクトと一緒に置かれていることだけが条件です。
この記録があると、二つのことができるようになります。一つは、テキストを一括更新したあとに修正済みの行だけを再確認できること。プレイヤーより先に回帰に気づけます。もう一つは、繰り返し出てくるものを用語集に還流できることです。同じ用語が毎回違う訳になっているなら、必要なのは個別修正の何度目かではなく用語集の1行です。報告を「処理する」のと「減らす」の違いは、ここにあります。
fix-log.csv — 確認済みの修正を1件1行で key,lang,old,new,reported_by,confirmed_by,date,note shop.buy_button,de,...,...,player#4471,translator,2026-08-18,命令形にすべき箇所 tutorial.step_03,fr,...,...,3件の報告,translator,2026-08-18,意味が反転していた item.potion_desc,de,...,...,player#1180,未確認,2026-08-18,用語集に追加予定
報告してくれた人に結果を返す
誤訳を報告するのは、プレイヤーにとって時間を使って何も得しない行動です。その人がもう一度報告してくれるか、そしてその言語の他の人がわざわざ報告する気になるかは、次に何が起きるかでほぼ決まります。修正が数週間先でも受領はすぐ返す。確認に出していると率直に伝える。そして出荷したら戻ってくる。パッチノートに「プレイヤーからの報告により、ドイツ語のいくつかの文言を修正しました」と一行書くことは、その修正そのものよりも、その言語コミュニティの健全さに効きます。
クレジットは安価で、ここでは異様に効きます。パッチノートやクレジット画面の短い謝辞リストは、一度きりの報告者を「気にして見てくれる人」に変えます。そういう人たちは、小規模チームにとって母語話者QAにもっとも近い存在です。
「直さない」と言わなければならないこともあります。報告を永久に放置するより、言うほうが確実に良い対応です。誤りではなく好みの問題であるとき、あるいは技術的に今は現実的でないとき、短く正直に伝えてください。ここは意味としては正しい、この言い回しは意図して選んでいる、この文字は画像に焼き込まれているので次のアート更新で直す、といった具合です。はっきりした「いいえ」は、報告者にほぼ確実に受け入れられます。許されないのは沈黙のほうです。沈黙は、その人がいちばん恐れていたこと — 開発側は自分の言語をどうでもいいと思っている — として読まれてしまいます。