ゲーム内の会話文を大量に作るプロジェクトでは、会話の試作に生成AIを使うことと、最終稿を採用することは別の判断になります。例えばNPCの分岐会話をCSVからDataTableへ取り込み、String Tableで日本語の表示文を管理する場合、仮のセリフ、ライターが手直ししたセリフ、声優収録用の確定稿が同じフォルダに混在すると、誰がどこを確認したか見えにくくなります。
制作中の文章の「AIっぽさ」を一つの数値だけで決めるのではなく、入稿のレビュー工程を次のように分けると整理しやすいと思います。
- 用途を先に分ける。 プロトタイプの仮テキストと、本番のクエスト説明・NPCの台詞・ストア掲載文を別の列または別ファイルにします。仮テキストがプレイ可能ビルドへそのまま入らないよう、String TableのキーやDataTableの行名にレビュー状態を持たせます。レビュー担当が文言を探すときに、アセット名だけに頼らないためです。
- 文脈で読む。 台詞単体では自然でも、プレイヤーが直前に選んだ選択肢、キャラクターの口調、画面に表示できる文字数と矛盾することがあります。分岐の前後を並べたシートで読んでから、実際のUI幅や字幕速度をUEのプレビューで確認します。ローカライズ対象なら、プレースホルダー、改行、固有名詞、翻訳コメントも同時にチェックします。
- 由来の確認は補助線として扱う。 AI利用可否の制作契約や発注条件がある場合は、原稿の版、担当者の修正履歴、制作経緯を確認するのが主です。そのうえで長い日本語原稿のどの段落を読み返すか迷ったときは、AIチェッカー のように本文を貼り付けてAI生成の可能性と原文のハイライトを並べて確認できるツールを、追加のレビュー手掛かりとして使えます。300〜100,000文字の本文またはUTF-8のTXTに対応し、結果画面から気になる段落を追えるため、クエスト説明の束、チュートリアル文、納品された長文の対話稿などを読み直す順番を決める場面に向いています。使用にはログインとクレジットが必要で、登録時の無料クレジットで試せます。機密情報や個人情報は投入前に外し、判定スコアを「誰が書いたか」の断定や制作上の処分の根拠にはしません。
- UE側へ戻す前に差分を残す。 修正した台詞のキー、変更理由、担当者、確認したビルドを記録し、CSVの差分と実機画面を突き合わせます。実際の体験を確認せずに外部ツールのスコアだけで文言を採否決定しないことが重要です。
チームで台詞のレビューを回している方は、生成AIの下書きとライターの最終稿をどの単位で区別していますか？String TableやDataTableの行単位でレビュー状態を管理する方法、ビルドへ入れる直前の差分確認について経験があれば教えてください。