Claude Media
Claudeでゲームの台詞と口調を点検する — キャラ別ガイドをProjectsに置く

Claudeでゲームの台詞と口調を点検する — キャラ別ガイドをProjectsに置く

キャラ別の一人称・語尾・禁句をスタイルシートにしてClaudeのProjectsに置き、新規台詞の逸脱を行単位で指摘させる手順です。ルールの書き方と点検の依頼文を載せます。

ゲームの台詞は、書く人が増えるほど口調がずれます。主人公は「俺」のはずが三章で「僕」になる。無口な剣士が急に長台詞を話す。ライターの交代や追加DLCのたびに、この種のずれが積もります。

ずれを人の目だけで拾うのは、台詞が数千行になると現実的ではありません。そこで、キャラ別の一人称・語尾・禁句を「口調ガイド」としてClaudeのProjectsに置き、新しく書いた台詞をその場で点検させます。ガイドの書き方、Projectへの置き方、点検の依頼文、外れやすい場面を順に見ていきます。

口調ガイドをProjectsに置くと何が変わるか

Projectsは、独自のチャット履歴と知識ベースを持つ作業スペースです。知識ベースに入れた資料は、そのProject内のすべてのチャットで文脈として使われます。ガイドを毎回貼り直さなくても、新しいチャットを開けばすぐ点検に入れます。

もう一つの置き場所が、プロジェクト指示です。応答の仕方を指定する欄で、口調を堅くする、特定の役割の視点で答えさせるといった使い方が想定されています。

役割分担は次のとおりです。

置き場所入れるもの理由
プロジェクト指示入れるもの点検の進め方、出力形式、判定の基準理由毎回同じ振る舞いをさせたい内容
知識ベース入れるものキャラ別のスタイルシート、承認済みの既存台詞理由参照される資料で、更新もある

Projectsは無料アカウントを含む全ユーザーが使えます。無料アカウントで作れるのは5つまでです。点検対象を作品ごとに分けるなら、この数を意識しておく必要があります。Projectsと通常のチャットの違いは、ClaudeのProjectsとChatGPTのGPTsの違いで比較しています。

なお、同じProjectでもチャット間で文脈は共有されません。あるチャットで「このキャラはこう直す」と決めた内容は、知識ベースに書き戻さない限り次のチャットに引き継がれません。決定事項はガイドへ戻す運用が前提になります。

キャラ別スタイルシートに書く項目

点検の精度は、ガイドの粒度でほぼ決まります。「元気な少女」のような人物像だけでは、Claudeは雰囲気で判断するしかなく、判定が揺れます。台詞の表面に現れる、機械的に照合できる項目から先に書きます。

  • 一人称と二人称:「俺」「おまえ」など、場面別の使い分けも含む
  • 語尾:使う語尾と、使わない語尾
  • 禁句:世界観に合わない外来語、現代語、他キャラの口癖
  • 文の長さ:短文中心か、長台詞もあるか
  • 相手別の変化:目上、敵、子ども、初対面での切り替え
  • 感情が動いたときの崩れ方:どう崩れるのが正しいか

最後の項目は見落とされがちです。普段は敬語の参謀が、激昂したときだけ一人称が変わるなら、それは逸脱ではなく演出です。この例外を書いておかないと、正しい台詞を誤検出します。NPCの人物設定そのものを固めたい段階なら、TRPGシナリオの作り方の設定づくりが先に役立ちます。

次は、スタイルシートの一例です。架空のキャラで、形式の見本として示します。

## ガルド(傭兵団の団長)
- 一人称: 俺 / 公式の場のみ「私」
- 二人称: 目下は「おまえ」、依頼人には「あんた」
- 語尾: 「〜だ」「〜だろう」。「〜ですわ」「〜だよね」は使わない
- 禁句: 「マジで」「ヤバい」「了解」(世界観の外の語)
- 文の長さ: 原則2文以内。作戦説明だけ最大4文
- 相手別: 子どもには語尾が柔らぐ(「〜だぞ」)。敵には名前を呼ばない
- 崩れ方: 怒りは一人称を変えず、語尾を削って体言止めにする
- 承認済み台詞: 「持ち場を離れるな。夜明けまでだ」(第1章)

最後の「承認済み台詞」は、基準になる実例です。ルールだけより、通った実例が数行あるほうが、境界線の位置が伝わります。

Projectにガイドと点検の指示を置く手順

Projectの作成から指示の保存までを、最短で通します。

手順

ガイドを置いて点検できる状態にする

  1. 1

    Projectを作る

    左側のメニューから「Projects」を開き、右上の「+ New Project」を押して名前と説明を付けます。この名前と説明はClaudeには渡らないので、点検のルールはここに書きません。

  2. 2

    スタイルシートを知識ベースに入れる

    Projectページの右側にある知識ベースで「+」を押し、ガイドのファイルを追加します。キャラが多いときは、1ファイルにまとめず、キャラ別かパーティ別に分けると更新しやすくなります。

  3. 3

    プロジェクト指示を保存する

    「Set project instructions」を開き、点検のやり方を書いて「Save instructions」を押します。指示はそのProjectのすべてのチャットに適用されます。

  4. 4

    点検用のチャットを開く

    新しいチャットを開き、台詞を貼って点検を依頼します。以後の使い方は次の節です。

プロジェクト指示には、点検の流れと出力形式を書きます。次のような内容が出発点になります。

あなたはゲームの台詞校正者です。知識ベースの口調ガイドだけを基準に、
貼られた台詞を点検してください。
 
- 台詞ごとに「話者 / 判定(合格・要修正・判断保留) / 該当ルール / 修正案」を表にする
- 該当ルールは、ガイドの項目名と該当部分を引用して示す
- ガイドに書かれていない事柄は「判断保留」とし、好みで直さない
- 合格した台詞は修正案を書かない
- 最後に、ガイドへ追記すると今後の判定が安定する項目を挙げる

「判断保留」を用意するのが要点です。選択肢が合格と要修正の二つだけだと、ガイドに根拠がない台詞でも、Claudeはどちらかに倒す必要があります。逃げ道を作っておけば、ルールの穴が表に出てきます。

新規台詞を点検させる依頼文

点検のチャットでは、台詞に文脈を添えて貼ります。同じ台詞でも、誰に向けた言葉かで合否が変わるからです。過去の記録と照らして矛盾を見つける型は、社長挨拶の原稿を過去の発言録と突き合わせる手順にも通じます。

次の台詞を点検してください。第3章、酒場でのイベント。
ガルドが依頼人の商人に報酬の条件を伝える場面です。
 
1. 「了解した。前金は三割でいいな」
2. 「あんたの積み荷は、俺たちが責任を持って運ぶ。それで十分だろう」
3. 「マジで助かったぜ、あんた」

この3行に対して、ガイドの例どおりなら次のような指摘になるはずです。以下はClaudeの実際の出力ではなく、ガイドの内容から読み取れる想定の指摘です。

台詞想定される判定根拠となるガイドの項目
1想定される判定要修正根拠となるガイドの項目禁句「了解」
2想定される判定合格根拠となるガイドの項目二人称「あんた」(依頼人)、語尾「〜だろう」
3想定される判定要修正根拠となるガイドの項目禁句「マジで」

実際に使うときは、出力がこの形になっているかを確かめます。根拠の欄にガイドの引用がなければ、Claudeが好みで判断している可能性があります。引用を必須にしておけば、判定の裏付けを人が確認できます。

台詞が長いときは分けて貼る

数百行を一度に貼ると、後半の点検が雑になりがちです。場面や章ごとに区切り、1回に数十行程度で回すほうが、指摘の質を保てます。1回に貼る行数を減らせば、根拠欄に引用があるかを人が確かめやすくなります。行数の上限は定められていないので、指摘の質を見ながら調整します。

直させるときは「ずらす」範囲を指定する

修正案は、元の台詞の意図を残したまま口調だけを直す形で頼みます。「意味や情報は変えず、語尾と語彙のみ修正」と添えると、台詞の中身まで書き換わる事故を避けられます。

点検が外れやすい場面

落とし穴

ガイドが長くなると、参照されない項目が出る

有料プランでは、知識ベースが文脈の上限に近づくと、RAGモードが自動で有効になります。このとき、Claudeはプロジェクト知識の検索ツールで関連しそうな部分だけを取り出して使います。ガイドに加えて既存台詞の全集まで入れると、点検の際に特定キャラの項目が拾われない場合があります。ファイル名をキャラ名にして内容を分けておくと、検索で取り出されやすくなります。

RAGのしくみ自体は、うまく働けば容量が最大10倍になる利点があります。ただし、点検では「禁句リストの一行が抜けた」だけで見逃しが起きます。RAGが有効になると表示が出るので、その表示が出たら、禁句の一覧は短い独立ファイルに切り出し、プロジェクト指示でも「禁句を必ず照合する」と明記します。

落とし穴

ガイドにない状況で、もっともらしく直してしまう

幼少期の回想で語尾が変わる、変身後だけ人格が入れ替わる。こうした例外がガイドに書かれていないと、判定が揺れます。判断保留の選択肢を指示に入れておき、保留が出たらガイドに追記する流れにします。

もう一つ、見落としやすい点があります。プロジェクト指示とガイドで、同じ内容を別の言い方で二重に書くと、片方だけ更新して食い違いが起きます。口調のルールは知識ベースの1か所に集め、指示には「ガイドを基準にする」とだけ書くのが安全です。

複数のライターで使うとき

Team・Enterpriseプランでは、Projectを組織内で共有できます。権限は2段階です。

  • Can view:内容、知識ベース、指示を見て、Project内でチャットできる。編集はできない
  • Can edit:プロジェクト指示と知識ベースを編集できる

ライター全員に「Can view」を渡し、ガイドの更新担当だけに「Can edit」を渡す運用が合います。全員が編集できると、気づかないうちにルールが書き換わり、点検の基準が動いてしまいます。管理者が共有機能を切っている組織では、共有自体が使えません。

個人のアカウントでは共有できないので、ガイドをファイルとして配り、各自のProjectにアップロードしてもらう形になります。この場合は、ガイドの版がずれないよう、ファイル名に日付や版数を入れます。

逸脱を見つけたら、ルールの側を直す

点検を回していると、同じ種類の指摘が繰り返されます。このとき台詞を直して終わりにせず、ガイドのほうも直します。

前と後

ガイドの禁句欄を書き換える例

BEFORE

直す前

禁句: 現代的な言葉

AFTER

直した後

禁句: 「マジで」「ヤバい」「了解」「ありがとうございます」(敬語の定型は第5章まで使わない)

「現代的な言葉」のような抽象語は、判定のたびに解釈が揺れます。実際に指摘された語を具体例として足していくと、ガイドが育ちます。点検の最後に「ガイドへ追記すべき項目」を出させておけば、この更新作業の下書きまで得られます。

Projectの記憶機能も関係します。Projectごとに独自の記憶があり、そのProjectの記憶は他のProjectには引き継がれません。点検用のProjectを作品ごとに分けておけば、別作品のキャラの癖が混ざる心配は小さくなります。記憶に頼らず、決定事項はガイドへ書く運用が確実です。

点検を日常の工程にする

最後に、運用の目安を挙げます。

  • 新しい章の台詞を書いたら、納品前にProjectへ貼って点検にかける
  • 指摘をまとめてガイドを更新し、版数を上げる
  • 新キャラを追加するときは、先にスタイルシートを書いてから台詞を書く

ガイドがあれば、人の校正者も同じ基準で読めます。Claudeの点検は、校正者の代わりというより、一次チェックを早く回すための道具です。判断保留や微妙な演出は、最終的にシナリオ担当が決めます。

まとめ

口調の一貫性は、雰囲気ではなく照合できるルールに落とすと点検しやすくなります。一人称・語尾・禁句・例外を書いたスタイルシートを知識ベースに、点検の流れと出力形式をプロジェクト指示に置く。この二段構えが基本です。

判定の根拠にガイドの引用を必須にし、迷う台詞は判断保留に逃がします。指摘が繰り返されたら、台詞より先にガイドを直します。

この記事を共有:XはてブLinkedIn