ゲーム会社のAI翻訳ポリシー — 決めて書き残すべき論点
現場のどこかで、機械翻訳の出力はすでに使われています。企画書用に一文だけチャットAIに英訳させる。コミュニティ担当がプレイヤーへの返信を訳す。ベンダーの翻訳者が、編集前に一度ツールに通す。どれも自動的に悪いことではありませんが、どこにも文書化されていないなら、その会社にはすでにAI翻訳ポリシーが存在していることになります。その日いちばん急いでいた人が決めた、偶然のポリシーです。
会社にとって意味のある問いは「AI翻訳は良いか悪いか」ではありません。もっと狭く、答えの出る問いです。どこまで使ってよいのか。どのテキストなら社外のサービスに出してよいのか。ベンダーには何を開示させるのか。そして、社内の誰も読めない言語で事故が出荷されたとき、誰が責任を持つのか。
以下は「採るべき立場」ではなく「決めるべき論点」の一覧です。会社ごとに着地点が違って当然ですし、実際の判断を反映した緩いルールのほうが、全員が迂回する厳しいルールよりうまく機能します。
何かを決める前に、テキストを階層に分ける
「全面禁止」か「全面許可」かで決めようとすると必ず失敗します。リスクが一様ではないからです。海外から届いた不具合報告を読むために使うのは明らかに問題なく、返金ポリシーの文面に使うのは明らかに問題があります。先にテキストを階層に分けてしまえば、技術論だった議論が、小さく判断できる問いの列に変わります。
- 社内・使い捨て: 企画メモ、仮テキスト、読めない言語で届いた不具合報告の把握。リスクは低く、ここを一律許可にすると無意味な摩擦がなくなります
- プレイヤー向けだが直しやすい: パッチノート、SNS投稿、コミュニティ返信。機械出力+送信前に人が読む、という運用は十分に説明可能で、誤りも数分で直せます
- ビルドに載るテキスト: UI、システム文言、アイテム説明、チュートリアル。修正にはパッチが必要で、その言語のプレイヤー全員に見え、レビューに引用されます
- シナリオとキャラクターの口調: プレイヤーがローカライズの質を判断する場所であり、機械出力の劣化が最も静かに進む場所です。流暢で、もっともらしく、話者が誰かを間違えます
- 規約・安全・課金・ストア関連: 利用規約、プライバシー、レーティング申請、購入と返金の導線など、プラットフォームや当局が読む文面。ここでの誤りは品質問題ではなくコンプライアンス問題です
運用に耐えるポリシーは、だいたいこの形に落ち着きます: 社内・使い捨て -> 許可、レビュー不要 直しやすいプレイヤー向け -> 許可、公開前に人が読む ビルドに載るテキスト -> 資格のある人が執筆。機械の下訳は可 シナリオ・キャラ口調 -> 資格のある人が執筆。機械の下訳は推奨しない 規約・安全・ストア -> 資格のある人が執筆 + 法務レビュー
どのテキストなら社外に出してよいか
未発表のゲームテキストは、会社にとって最も機微な資産であることが少なくありません。ストーリー、キャラクター名、未発表機能、コラボ相手、日程。それを個人向けのチャットツールに貼り付ける行為は、情報開示の判断です。そしてその判断は、たいてい「自分がいま判断している」と気づいていない人によって行われます。
ポリシーが答えるべき問いは具体的です。どのサービスを承認するのか。いま契約しているプランで、入力が学習に使われるのか(個人向けと法人向けでこの点の扱いが違うことは珍しくありません)。入力はどれだけ保持され、どこで処理されるのか。アカウントは会社が管理しているのか個人のものなのか。最後の点は、退職時にアクセスを止められるかどうかも決めます。
その上に、すでに負っている義務が重なります。プラットフォームホルダーやパブリッシャーとの秘密保持条項は、この議論より前から存在していて、「便利なツールだから」という例外は書かれていません。情報解禁前であれば、貼り付けは送信です。
現実的な統制手段は禁止ではありません。正規の抜け道がない禁止は、見えないところでの利用を生むだけで、見える利用より確実に悪い状態です。機能するのは、会社が管理する有償の承認済みサービスを一つか二つ用意し、どの階層のテキストなら入れてよいかを明文化すること。そして、どのサービスにも入れてはいけない材料をはっきり線引きすることです。
ベンダーに何を要求するか
社内ルールは、契約で外へ延ばさない限り自社の社員で止まります。ベンダーとその再委託先は、同じテキストを自分たちの基準で扱います。社内利用だけ丁寧に統制して取引先には何も求めていない会社は、露出のごく一部しか統制できていません。
- どの工程で機械翻訳・AIを使うのかの開示。「使う/使わない」ではなく工程単位で
- 値付けの整合。ポストエディット(機械出力を人が編集する工程)は、その工程として値付けされていること
- 編集工程の明示。誰が編集し、どういう指示のもとで、何を拾うことが期待されているのか
- 秘密保持の流し込み。再委託先と、再委託先が使うツールにも同じ制約がかかること
- こちらのテキストが、ベンダー自身または第三者のモデルの学習に使われないこと
- 納品される翻訳メモリの中で、機械が下訳した部分が識別できること。未編集の出力が、そのまま何年も自社の参照資産になってしまう事態を避けるため
検査こそがポリシーの本体
どこかで機械の関与を許すポリシーは、その後段の検査と同じ強度しか持ちません。失敗の出方が「明らかにおかしい文」ではないからです。流暢で自信のある文が、特定の一点だけ静かに間違っています。プレースホルダーが一つ消えている。同じ用語がメニュー内で三通りに訳されている。否定が反転している。美しく読めて、原文と逆のことを言っている。
検査は機械的なものと人によるものに分けます。スケールの仕方が違うからです。機械的な検査 — プレースホルダーが正しい形で存在するか、未翻訳や空欄がないか、タグの対応が取れているか、項目の文字数上限に収まっているか、用語集どおりの訳語になっているか — は、全言語の全行に対して毎ビルド実行でき、量が増えてもコストがほとんど上がりません。機械が先に拾える項目に、ネイティブ話者の一時間を使う理由はありません。
希少なのは人によるレビューのほうなので、その範囲は「やるつもり」ではなく明示的に定義します。どの階層を、誰が、日程のどの時点で通しで読むのか。そして日程が遅れたときに何が起きるのか。範囲を定義しないと、残った時間に入るぶんだけが実施範囲になり、悪い月にはゼロになります。
そのうえで、人を指名します。言語ごと・リリースごとの最終承認は、チームではなく個人に帰属させ、記録に残します。責任の分散は、未レビューの出力がプレイヤーに届く最も確実な経路です。誰もが「どこか上流で確認されているはず」と思っていた、という形で起きます。
最後に、テキストがどう作られたかを記録します。半年後にプレイヤーから誤訳報告が来たとき、知りたいのは「単発のミスなのか、下訳のまま通した一群の症状なのか」です。当時に書き残していなければ、その問いには答えられません。
クレジットと、プレイヤーへの開示
ストアの申請プロセスには、AI利用に関する申告欄が追加されています。その文言や適用範囲は何度も変わってきているので、前回のリリース時に正しかった理解に頼らず、出荷する各ストアの現行ルールをそのつど確認してください。個人の記憶ではなく、申請チェックリストの項目にしてしまうのが確実です。
義務とは別に、自分たちが何を言うかも決めておきます。いくつかの言語圏のコミュニティは、機械翻訳と受け取った訳文に強く反応します。そしてその反応は、ほぼ必ず結果の品質が引き金です。良いテキストを出して工程を率直に説明する会社のほうが、弱いテキストを出して何も言わない会社より、どちらがどのツールを使っていたかに関係なく、結果的にうまくいきます。
人にはクレジットを出してください。翻訳者やLQA担当が名前を載せてもらえないことは、この業界で長く続いている不満です。会社がツールについては公にし、人については沈黙しているとき、その不満はいっそう強く響きます。名前のある人が訳した言語なら、その名前を載せます。
サポートとコミュニティ運営については、機械支援の返信にラベルを付けるかどうかを決め、例外を一つだけ固く決めます。間違えたときに実害が出る話題で、機械が下書きした文をレビューなしに出さないこと。返金、アカウント、購入、安全性に関する報告は、数分を節約する場所ではありません。
一枚に書いて、持ち主を決める
提出期限前夜に誰も見つけられないポリシーは、ポリシーではありません。チームの他の運用ルールと同じ場所に、A4一枚で、初日の業務委託の人が誰にも聞かずに従える言葉で置きます。
ルール本体より重要なことが二つあります。一つは例外手続きです。これがないと、最初の本当の緊急事態で、その時間に起きていた人が前例を作り、その前例は緊急事態より長生きします。承認者を決め、書面で申請させ、期限を切り、事後に振り返ること。もう一つは見直し期限です。ツールもストアの要求も、ベンダーの実務も受け手の期待も、リリース一回分の期間で動いてきました。期限のないポリシーは、静かに「過去の記述」に変わります。
AI翻訳ポリシー - <会社名> - 最終見直し YYYY-MM - 管理者: <氏名> 1. 階層 レビュー不要 : 社内メモ、受信した不具合報告の把握 送信前に人が読む : パッチノート、SNS投稿、コミュニティ返信 資格のある人が執筆: ビルド内のUI・システム文言・シナリオ 執筆 + 法務レビュー: 規約、プライバシー、ストア文言、レーティング申請、購入導線 2. 承認済みツール 会社管理アカウントのみ。個人アカウント・個人のAPIキーは不可。 未公開コンテンツ: 承認ツールAのみ。未承認サービスには一切入れない。 3. ベンダー 工程ごとのAI・機械翻訳の使用を開示。ポストエディットはその工程として値付け。 秘密保持は再委託先とそのツールにまで及ぶこと。 納品される翻訳メモリでは、機械が下訳した部分を識別できること。 4. 出荷前の検査 機械的検査は全言語・全行・毎ビルド。 ビルド内テキストは、言語ごとに資格のある話者が通読。 5. 最終承認 言語ごとに担当者を指名し、リリースごとに記録。 6. 例外 承認者: <役職>。書面・期限付き・振り返りで見直し。