キャラクターカード V2 と V3：変更点と移行方法について。キャラクターカード V2 と V3：
何が変わり、どう移行するか。

あるクライアントからキャラクターカードをエクスポートし、別の クライアントへインポートしたら、フィールドの半分が消えていた —— 挨拶が切れ、lorebook が消え、カスタムプロンプトが黙って 落ちる —— そんな経験があるなら、それがまさに V1 / V2 / V3 問題だ。Tavern のカード形式はコミュニティの遺産であり、 単一の委員会も、バージョン化された schema レジストリも、 すべてのキーを同一に実装するホストも存在しない。

ほとんどのクリエイターには本来関係のない話だ —— が、 Chub.ai、 RisuAI、 そして友人のセルフホスト SillyTavern に同時に置かなければならないライブラリを抱え始めた瞬間に変わる。 バージョンを間違えれば、何時間もかけて書いた成果が失われる。 本稿では、各バージョンが何を追加し、どこで V3 に頼って安全か、 どうやって壊さずに移行するかを順に追っていく。

V1 カードは最初の Tavern 形式：単一の JSON ペイロードを、 PNG の tEXt チャンク（キーワードは chara） に埋め込み、JSON 自体は Base64 エンコードされる。schema は フラットかつ最小限 —— 基本的には name、 description、 personality、 scenario、 first_mes、 そして数個の兄弟フィールドだけだ。これで何年もコミュニティを 支え、ほとんどのホストは今もフォールバックとして受け入れる。

しかし V1 には、lorebook、代替挨拶、作者やチューニング対象 モデルに関する構造化メタデータの居場所がなかった。基本以上は description の文中に押し込むしかなかった。その隙間を埋めようと したのが V2 だ。

V2 は PNG tEXt 配信を踏襲しつつ、ペイロードをトップレベルのエンベロープで 包む：

{
  "spec": "chara_card_v2",
  "spec_version": "2.0",
  "data": {
    "name": "...",
    "description": "...",
    /* every real field lives under data */
  }
}

このネストが見出しの変更だ —— フラットな形しか読まない旧 クライアントは何も得られないため、V2 カードはほぼ常に V1 風のトップレベル複製を互換シムとして同梱する。

data の下に、V2 はクリエイターが頼るようになった一連の フィールドを導入した：

• character_book —— カード内に直接埋め込まれた lorebook。独自のエントリ、 キー、トリガー順、挿入深度を持つ。
• alternate_greetings —— 追加の開幕メッセージの配列。ランダム、またはユーザーが 選択する。
• tags、 creator、 character_version —— ギャラリーと出所のための構造化メタデータ。
• system_prompt と post_history_instructions —— system メッセージと jailbreak 風の末尾指示のための明示的 スロット。description に詰め込む旧来の慣習を置き換える。
• V1 から引き継ぎつつ意味を整理したフィールド： personality、 scenario、 mes_example、 first_mes。
• extensions —— 任意のホストが私的設定を置ける自由形式オブジェクト。 V3 が後に拡張する非常口でもある。

ホスト側から見れば、2026 年時点でも V2 は安全な既定値だ。 SillyTavern は正典扱い、Chub.ai は V2 を保存・配信、RisuAI も V2 の大半をカバー（一部のフィールドは独自 UI 慣例で解釈）。 もし今日ひとつだけ選んでクロスプラットフォーム配布するなら、 答えはやはり V2 だ。

V3（ spec: "chara_card_v3" で識別）は、書き直しではなく洗練として理解するのが 正しい。V2 のエンベロープに少数の新機能を重ね、これまで 曖昧だった規則を引き締める。多くのクリエイターが触れる新表面：

• assets —— 表情・別立ち絵・音声などの追加メディアをカードと並べて 宣言する仕組み。ホスト固有のサイドカーファイルへの依存を 避けられる。
• group_only_greetings —— グループチャットに読み込まれた時のみ現れる開幕台詞。 1:1 では出ない。
• nickname —— 正式名とは別の、チャット内表示用の短い呼称。
• creator_notes_multilingual —— ロケールをキーにした作者メモのマップ。同じカードで EN、 JA、ZH の作者コメントを共存させ、ひとつを選んで他を隠す 必要をなくす。
• source —— 派生元やリミックス元の明示的な帰属 URL（または URL の 配列）。
• schema 全体の型をやや厳格化 —— 配列は配列、オプションは 明示、V2 にあった string-or-array の曖昧さも数か所固定された。

正直に言えば、V3 はまだ落ち着いていない。ホストごとに 実装するサブセットが異なり、仕様自体も公開で進化中だ。 V3 カバレッジは SillyTavern が先行し、他のホストは部分対応で、 認識できないキーは静かに V2 セマンティクスへ退く。だからこそ、 どのキーがどのホストで生き残るかを知る linter が役に立つ —— そしてそれが tavernai.cards の立ち位置だ。

V2 → V3 移行のほとんどは機械的だ： spec を上げ、新しいオプションキーを足し、出す。失敗する場所は 予測しやすい：

1. extensions 配下のカスタムキー。 V2 ではどのホストも何でも書ける。V3 ではそれらカスタム キーの一部に一級の対応物（例：asset 参照）が生まれ、 残りには対応物がない。素朴にマージすると同じデータが二か所に 存在し、ホストはどちらを優先するか予測不能になる。
2. 多言語フィールド。 creator_notes_multilingual は V3 の追加。これを知らないホストは素のプレーン creator_notes にフォールバックする。多言語マップだけを埋めてプレーンを 空にすると、旧クライアントでは何も表示されない。
3. PNG tEXt エンコーディング。 歴史的慣習は UTF-8 JSON を Base64 で包み chara キーワードに格納すること。生 UTF-8 を書く（Base64 なし）、 埋め込み前に非 ASCII を落とすツールが意外に多く、片方の ホストで開け、もう片方で静かに壊れるバグはたいていここから 来る。
4. 埋め込み lorebook と 外部 lorebook。 character_book はカードと共に移動する —— 可搬性には良いが、共有世界観には 痛い。三枚のカードで lorebook を共有しつつインラインで保つと、 同期すべきコピーが三つになる。多くのチームは結局、正典の 外部 lorebook と薄い埋め込みコピーをフォールバックとして 両立させる方向に落ち着く。
5. assets の相対パス。 V3 の asset 参照は相対も絶対も書けるが、解決基準は仕様で 完全に固定されていない。ホストごとの仮定も異なる。 カードを巡回させるなら絶対 URL（もしくは内容ハッシュ）が 安全だ。

tavernai.cards はまさにこのワークフローのために作られている：単一の正本で ロスターを保ち、V2 と V3 両方の仕様に対して lint し、 各ホストが実際に理解できる形でエクスポートする。

• Lint —— 公開前に挨拶の欠落、古い参照、ホスト非互換のフィールドを 検出。
• 自動移行 —— V1 から V2、V2 から V3 へ。ブラックボックスではなく レビュー可能な diff 付き。
• マルチ プラットフォーム同期 —— 同じカードを Chub、RisuAI、SillyTavern それぞれの方言で プッシュ。
• V2 / V3 双方向 エクスポート —— 同じソースから V3 カードと V2 互換ビルドを同時に出す。