キャラクターがぶれ続ける、ありきたりに聞こえる、性格から外れた行動をとる——そんなとき、直すべき場所はほぼ必ず、チャットの仕方ではなくカードのほうにあります。カードは、モデルが返信のたびに読む恒久的な指示なので、その質がキャラクターの良し悪しの上限を決めます。その構造を理解すれば、キャラクター作りは当てずっぽうから、原因を突き止められる作業へと変わります。これはAIキャラクタークリエイターの仕組みを直接ふまえた内容です。
中核となる項目
正体
名前、年齢層、役割、一行のコンセプト。これが他のすべての錨になります。切れ味のよいコンセプト——「いまは経営難の書店を営む、引退した舞台マジシャン」——は、ばらばらの事実を一ページ並べるよりも多くを語ります。性格・舞台設定・声を、一度に暗示してくれるからです。
性格
具体的な特徴を三つか四つ、できれば互いに緊張をはらむように。「あたたかいが警戒心が強い、度を越して好奇心旺盛、感傷が大の苦手」なら、モデルが演じるべきふるまいが手に入ります。長い形容詞の羅列(「やさしい、賢い、面白い、思いやりがある、忠実…」)は、具体性とコントラストを欠くために、ぼやけて何も残りません。
話し方
もっとも使われていないのに、もっとも強力な項目のひとつです。文の長さ、かしこまり具合、ユーモア、口ぐせを書き——そのうえで、そのキャラクターの声による会話例を一つか二つ入れてください。モデルは例を強く真似るので、一行のサンプルが、一段落の説明より効くことがよくあります。これがキャラクターの声と口調の核心です。
生い立ち
屋台骨となる事実だけ——いまのふるまいを説明するものです。どこの出身か、何をしているか、形成期の出来事を一つか二つ。段落が増えるほど注意を奪い合い、より大事な指示を押しのけかねないので、簡潔さを長所として扱ってください。
関係性と状況
あなたがそのキャラクターにとって何者か、いまの状況、関連する舞台設定。これが対話を地に足のついたものにし、キャラクターがすべてのメッセージを唐突な出だしのように扱うのを防ぎます。
境界線
そのキャラクターが何をして何をしないか、対立にどう対処するか、性格を保ち続けるかどうか。明確な境界線は、ぎこちないぶれを防ぎ、アプリ自身のコンテンツフィルター(これは別の層です)とも作用し合います——プライバシーと年齢確認をご覧ください。
この項目分けは単なる慣習ではありません——公開されたファイル形式そのものです
ここまでの「正体、性格、話し方、生い立ち、状況、境界線」という項目分けは、単なる説明のための工夫ではありません。多くのロールプレイ・コンパニオンアプリが実際に読み書きしている、キャラクターカードのファイル形式で公開・文書化されている項目と、ほぼ重なっています。もっとも広く使われているバージョンはCharacter Card V2と呼ばれ、カードをspec(chara_card_v2に設定)、spec_version(2.0)、そして実際のカード内容を保持するdataオブジェクトという3つのトップレベルキーを持つJSONオブジェクトとして保存します。data の中には、ここまでの解剖図とほぼ一対一で対応する項目が並びます——nameとdescriptionが正体と生い立ちを、personalityとscenarioが性格と状況を、first_mesとmes_exampleが話し方を固定する第一声と会話例を担い、専用のsystem_promptとpost_history_instructionsフィールドは、多くのツールが境界線や恒常的な指示を配置する場所で、自由記述のdescriptionの中にではなく、それと並ぶかたちで保持されます。V2ではさらに、alternate_greetings、埋め込み可能なcharacter_book(キャラクター専用のロアブック)、tags、creator、character_version、そしてアプリ固有のデータのための自由形式のextensionsオブジェクトが追加されました。
より新しい改訂版であるCharacter Card V3(spec: "chara_card_v3"、spec_version: "3.0")は、後方互換性のためV2のすべての項目を保持したうえで、複数の埋め込み画像や感情差分スプライト、グループ専用の挨拶、ニックネーム欄、複数言語での制作者メモ、作成・更新のタイムスタンプへの対応を加えています。また、CHARXと呼ばれるコンテナ形式も導入されました。これはzipアーカイブで、ルートにcard.jsonというファイルとしてカードを置き、そのサブフォルダにキャラクターの画像や音声アセットを収め、JSONからはembeded://パスで参照する仕組みです。CHARX形式でなくても、どちらのバージョンも、PNGのテキストチャンクの中にJSONをこっそりbase64エンコードして埋め込んだ、一枚のPNG画像として持ち運べます——V2ならchara、V3ならccv3というチャンク名です。共有サイトからダウンロードしたキャラクターの「画像」が、そのままカード一式であることが多いのは、これが理由です。
ここまでの話は、カードの書き方そのものを変えるものではありません。ですが、このガイドの項目立てがアプリをまたいでこれほど一貫して感じられる理由を説明してくれます——クリエイター画面の見た目がまったく違っていても、多くのツールは根底にある同じスキーマを読み書きしているのです。
実利的な利点もあります。スキーマが公開され共有されているからこそ、ある項目入力式のクリエイターで丁寧に書いたカードは、別のアプリにもたいてい問題なくエクスポート・インポートでき、一から書き直す必要がありません。ふるまいを左右する項目——personality、system_prompt、mes_example——は、アプリ側が独自のUIをその周りに組み直していても、そのまま引き継がれます。だからこそ、「出来の悪い」カードは、別のプラットフォームに移しただけでは魔法のようによくなりません。もとのpersonality欄があいまいな形容詞の寄せ集めだったり、会話例が欠けていたりすれば、書き出されたJSONは同じ弱点を別の場所でそのまま再現するだけです。直すべきなのは、やはりこのガイドにある方法——具体的な特徴、本物の会話例、はっきりと述べた境界線——であって、アプリを変えることではありません。
ひと目でわかる解剖図
| 項目 | 役目 | よくある失敗 |
|---|---|---|
| 正体 | コンセプトの錨になる | あいまい、またはありきたりな役割 |
| 性格 | ふるまいを駆動する | 長く平板な形容詞の羅列 |
| 話し方 | 声を定める | 説明はするが見せていない |
| 生い立ち | ふるまいを説明する | 長すぎる経歴 |
| 状況 | 場面を地に足のついたものにする | 空欄のままにする |
| 境界線 | ぶれを防ぐ | 矛盾している、または欠けている |
よいカードと悪いカードを分ける原則
- 具体はありきたりに勝る: 具体的なディテールは、モデルに演じる手がかりを与えます。
- 一貫は網羅に勝る: 矛盾のない短いカードは、自分自身と戦う長いカードより優れています。
- 語るだけでなく、見せる: 会話例は説明よりも価値があります。
- 無駄のなさは肥大に勝る: どの一行も注意を奪い合うので、ふるまいを変えないものは削りましょう。
おかしくなったキャラクターの原因を突き止める
何かがずれているときは、症状を項目に対応づけましょう。
- ありきたりな返信 → 弱い、または羅列的な性格。
- ゆらぐ声 → 欠けた話し方の例。
- 性格から外れた行動 → 不明確な境界線。
- あなたが誰かを忘れる → 薄い状況、または記憶と連続性で扱っている記憶の問題。
実際に使ってみる
カードを無駄なく書き、実際の会話で試し、うまくいっていない特定の項目を編集する——テキストをただ積み増すのではなく。この反復のループこそ、はじめてのロールプレイキャラクター作りで示した手順そのものであり、より良いロールプレイプロンプトの書き方にあるその場でのテクニックと組み合わさります。よく作り込まれたカードを実際の製品で見たいなら、MusePick のレビューでキャラクター重視のアプリのクリエイターを取り上げていますし、ランキングでは、アプリごとにカードをどこまで自由にいじれるかを比較しています。
よくある質問
キャラクターカードとは何ですか?
キャラクターカードとは、AIペルソナを定義する、目に見えないシステムプロンプトです——その正体、性格、話し方、生い立ち、状況、そして境界線を定めます。アプリは返信のたびにこれをモデルへ送るので、その質がキャラクターの一貫性の上限を決めます。
なぜ短いキャラクターカードのほうがうまくいくことが多いのですか?
カードに書かれたすべてが、モデルの注意を奪い合います。具体的な特徴と会話例を備えた、無駄のない一貫したカードは、矛盾や埋め草を含む長いカードよりたいてい優れています。矛盾や埋め草は、本当に効くべき指示を薄めてしまうからです。
口調がすぐ崩れてしまうキャラクターは、どう直せばいいですか?
話し方の項目に、そのキャラクターの声による会話例を一つか二つ加えてください。モデルは例を強く真似るので、どう話すかを見せるほうが、言葉で説明するよりも確実に口調のぶれを直せます。