CompanionRank
ホーム / ブログ / キャラクターカードの移行と互換性
ガイド

キャラクターカードの移行と互換性:実際に引き継がれるもの

キャラクターカードは一見ただの画像ファイルです。そこがこの形式の肝で、人格の定義はPNGの中にJSONとして隠されています。だからこそカードはアプリ間を移動できるのですが、同時に、移行の途中でキャラクターの一部が静かに消える理由でもあります。

最終確認: 2026年8月著者: CompanionRank 編集部読了目安: 約7分
キャラクターカードの移行と互換性
要点: キャラクターカードとは、人格を表すJSONをテキストチャンクに埋め込んだPNGのことです。仕様には3世代あり、V1(6項目のみ)、V2(システムプロンプト・ロアブック・追加の初回メッセージ・extensionsを追加)、V3(アセット・デコレーター・多言語ノートを追加。別のチャンク名で保存)に加え、画像や音声を同梱するためのCHARXというZIP形式があります。説明文と初回メッセージはほぼどこでも引き継がれます。ロアブック、初回メッセージの複数バリエーション、表情差分、アプリ独自の追加設定は、受け側がその世代に対応している場合のみ移動します。会話履歴は決して移動しません。そもそもカードに入っていないからです。

キャラクターをアプリ間で移すことと、自分のデータをアプリから取り出すことは、別の問題です。会話・メモリ・設定はサービス側のデータベースにありますが、キャラクターは通常、ファイルとして手元に持てる独立した成果物です。この違いこそカードを理解する価値のある理由で、自分が所有しているカードは、アプリが終了しても、料金体系が変わっても、使いたくない方向に変わっても手元に残る唯一の部分になります。

ファイルとして見たキャラクターカード

コミュニティ仕様におけるカードの実体は、ごく普通のPNG(またはAPNG)画像に、キャラクター定義をtEXtチャンク(画像ビューアは無視し、対応アプリだけが読むラベル付きのテキスト領域)として書き込んだものです。JSONはUTF-8をbase64で符号化して格納されます。V1とV2のカードはcharaという名前のチャンクを、V3のカードはccv3という別のチャンクを使います。アプリによっては同じ内容をプレーンな.jsonとしても書き出せますが、こちらはアバター画像を含みません。

V3仕様はもう一つの入れ物、CHARX(拡張子.charx)を追加しました。ルートにcard.jsonを置き、その隣にassets/ディレクトリを持つZIPアーカイブで、カード側からはembeded://形式のURIで参照します。CHARXが必要になったのは、最近のカードが表情差分の画像セットや背景美術、音声を同梱するようになり、それらをテキストチャンクに現実的なサイズで収められないからです。

チャンクが2種類ある設計の実務上の帰結は、読み手によって同じカードが「完全」にも「空」にも見えうる、という点です。charaしか知らないアプリからは、V3のみのファイルは中身が無いように見えます。実際にはV3を書き出すツールが両方のチャンクを書き込み、1つのファイルが新旧どちらのクライアントでも開けるようにしていることが多いのですが、それは書き出し側アプリの配慮であって、形式が保証している動作ではありません。

3つの世代を項目単位で比べる

手元のカードがどの世代かを知ることは、実際に試す前の段階で「何なら移行しうるか」を教えてくれます。

形式保存場所含まれるもの主な限界
V1charaチャンクフラットな6項目:名前、説明、性格、シナリオ、初回メッセージ、会話例ロアブック・システムプロンプト・初回メッセージのバリエーションが無い
V2charaチャンク(各項目はdata配下)V1の全項目に加え、作者ノート、システムプロンプト、履歴後の指示、追加の初回メッセージ、埋め込みキャラクターブック、タグ、作者、バージョン、自由形式のextensionsアセット一覧が無い。extensionsは仕様上アプリ固有
V3ccv3チャンクV2の全項目に加え、アセット一覧、ニックネーム、多言語の作者ノート、出典一覧、グループ専用の初回メッセージ、挿入深度や発動条件などのロアブック用デコレーターcharaしか見ない読み手からは見えない
CHARXcard.json+assets/のZIPV3カード本体と、それが参照する画像・音声の実ファイル受け側が展開できる場合にのみ意味がある

仕様の中で、見た目以上に重要な点が2つあります。1つ目は、V2が編集ツールに対して未知のキーと値を破壊してはならないと定めていることです。extensionsは、理解できないアプリであっても保持することが前提で、衝突を避けるためキーはアプリごとに名前空間を付けます。2つ目は、V3がV2の厳密な上位互換であるため、下方向への変換経路が存在することです。アプリはV3カードからV2オブジェクトを埋め戻せますが、その過程でデコレーターは取り除かれます。この「取り除き」こそ、目に見える項目は何も欠けていないのに挙動だけが変わる、典型的な発生源です。各項目が何のためにあるのかはキャラクターカードの解剖学で扱っています。

残るもの、劣化するもの、そもそも移らないもの

カードの中身を3つに仕分けすると、リスクの所在がはっきりします。

区分対象理由
確実に移る名前、説明、性格、シナリオ、初回メッセージ、会話例V1の項目であり、カード対応アプリならほぼ例外なく読む
受け側が新しければ移るシステムプロンプト、履歴後の指示、追加の初回メッセージ、埋め込みロアブック、タグ、作者情報V2での追加分。V1しか読めないインポーターは単に無視する
静かに劣化するロアブックのデコレーター、アセットや表情差分、グループ専用の初回メッセージ、名前空間付きextensionsV3カードがV2として読まれたとき、あるいはCHARXをPNGのみ対応のクライアントが読んだときに落ちる・平坦化される
決して移らない会話履歴、アプリが生成したメモリ、モデルの選択、サンプラー設定、課金状態いずれもカードの一部ではなく、サービス側にある

移行の途中で驚かれるのは、最後の行です。キャラクターの書き出しは、関係性のバックアップではありません。会話ログや、アプリがあなたのために積み上げた長期メモリは別物で、取得の難易度も高く、使える形で持ち出せないことも珍しくありません。この側面は会話履歴のエクスポートで、メモリがそう振る舞う理由はメモリと連続性で扱っています。

誰も触れていないのに変わるものが2つあります。V3カードはcreation_dateとmodification_dateをUnixタイムスタンプで持っており、仕様はアプリに対して書き出し時に更新日時を書き込むよう定めています。そのため、移しただけのカードでも後から見ると編集済みに見え、確かな来歴として残るのは元の作成日時だけになります。自作カードを保管しているなら、日付は書き出しの後ではなく前に控えておきましょう。

読み込みを拒否されたからといって、カードが壊れているとは限りません。仕様上、アプリはCHARXファイルを、容量が大きすぎる、破損している、対応する復号手段のない暗号化がかかっている、あるいはそもそも正しいZIPではない、といった理由でそのまま拒否してよいことになっています。あるアプリでは問題なく開けたファイルを別のアプリが受け付けないときは、キャラクターが失われたと考える前に、まずZIPとして開けるか試してみてください。

完璧に移行しても挙動が変わる理由

移行が無損失で、全項目がそのまま届いたと仮定しましょう。それでもキャラクターが別人のように感じられることがあります。カードは複数ある入力のうちの1つにすぎないからです。受け側のアプリは独自のベースとなるシステムプロンプトを与え、別のモデルを動かし、独自のサンプラー設定を適用し、コンテキストウィンドウのうちロアブックと進行中の会話に割く配分も変えます。あるアプリで世界観の記述に1,000トークンを見込んでいたカードが、別のアプリではその大半を切り落とされることもあります。

これは明確に言葉にしておく価値があります。というのも、最初の反応はたいていカードの編集に向かい、その結果、元のアプリでは正しく動いていたカードを壊してしまうからです。まずは設定側を疑ってください。マンネリ化したキャラの書き直しで紹介した比較手順がそのまま使えます。固定した書き出しメッセージを使い、変える要素は一度に1つだけ。ロアブックの項目が発動しなくなった場合、原因はテキストの欠落よりも、トリガー条件や割当トークンの違いである可能性が高いでしょう(世界観づくりを参照)。

そもそも出口が無いアプリ

ここまでの話は、両方のアプリがカード形式を扱えることを前提にしています。しかし、一般消費者向けのコンパニオンアプリの多くはそうではありません。キャラクターはデータベースの行として存在し、編集画面に出ているのは短い説明欄だけで、書き出しボタンはありません。データが複雑だからではなく、移行可能性が製品の目標に入っていないからです。ここは公平に評価すべきところで、閉じたアプリが自動的に劣ったアプリになるわけではなく、そもそも移行したいと思わない人も大勢います。ただし、その中で何週間もかけて人格を練り上げるとき、自分が何に賭けているのかは変わります。

出口の有無は、必要になってからではなく、事前に確認してください。カードの書き出しに対応しているアプリなら、通常は設定画面やヘルプにその旨が書かれており、書き出し時に形式名が示されます。「エクスポート」という語がどこにも見当たらないなら、キャラクターは取り出せないものと考え、自分が書いた文章のコピーを別に保管しておきましょう。説明・性格・初回メッセージをただのテキスト文書に控えておくだけでも、形式の変更で壊れることのない粗いが有効なバックアップになります。そもそも各アプリがどこまで編集を許すかはアプリランキングで見ている観点の一つで、MusePickのレビューではロールプレイ特化アプリをこの軸で取り上げています。

移行前チェックリスト

  1. 提供されている中で最も情報量の多い形式で書き出す。 PNGとJSONの両方が選べるなら両方取りましょう。JSONは中身の確認と修復がしやすく、PNGはアバターを運んでくれます。
  2. 世代を控える。 書き出しダイアログには通常V2・V3・CHARXのいずれかが表示されます。表示が無い場合は、V2と考えるのが安全です。
  3. 元ファイルには手を付けない。 受け側アプリから再度書き出すと、V3カードが黙ってV2へ格下げされることがあり、格下げされたコピーからデコレーターは復元できません。
  4. インポート後、編集画面を項目ごとに読む。 元のカードと照合します。説明、性格、会話例、初回メッセージ、ロアブックの項目数。抜けはチャットではなくここで見つかります。
  5. 固定した書き出しメッセージを3通り試す。 軽いもの、感情的な負荷が高いもの、キャラクター側に主導権を求めるもの。両方のアプリで同じ3通りを使えば、差分に意味が生まれます。
  6. 形式が運べなかったものを作り直す。 アバターや表情画像、初回メッセージのバリエーション、届かなかったロアブック項目。何が本当に欠けているか分かってから、最後にやるべき作業です。

この順序で進めれば、移行は1時間もかからず、しかも長く役立つことが分かります——キャラクターのどの部分がファイルの中にあり、どの部分がアプリの中にあったのか、という切り分けです。この区別こそが「互換性」の実質であり、必要になる前に知っておく価値があります。将来の移行を見据えてゼロからキャラクターを作るなら、初めてのロールプレイキャラクターの作り方とAIキャラクタークリエイターの仕組みが、アプリ側ではなくカード側に置くべきものを扱っています。

よくある質問

キャラクターカードを別のアプリへ移せますか?

両方のアプリが同じカード形式を扱える場合に限ります。コミュニティのキャラクターカード仕様を土台にしたアプリは、カードのJSONを埋め込んだPNGを読み書きするため、片方から書き出したカードはもう片方でもたいてい開けます。一方、一般消費者向けのコンパニオンアプリにはカードファイルを一切見せないものが多く、その場合キャラクターを公式な手段で持ち出すことはできません。

V2とV3のキャラクターカードは何が違いますか?

V2はV1の6項目をdataオブジェクトの中に収めたうえで、システムプロンプト、履歴後の指示、追加の初回メッセージ、埋め込みロアブック、タグ、作者情報、extensionsオブジェクトを追加しました。V3はV2の上位互換で、V2の全項目を保ちつつ、アセット一覧、ニックネーム、多言語の作者ノート、出典一覧、グループ専用の初回メッセージ、ロアブック用デコレーターを加えています。V3は別のチャンクに保存されるため、V2しか読めない相手にはV3専用カードが空に見えることがあります。

インポートしたキャラクターの挙動が新しいアプリで変わるのはなぜですか?

カードは複数ある入力のうちの1つにすぎません。新しいアプリは独自のシステムプロンプト、モデル、サンプラー設定、コンテキスト配分を持ち込み、実装していない項目は切り詰めたり無視したりします。両方の編集画面で内容がまったく同じに見えても返答が変わることはあり、それはインポートの失敗ではなく設定の違いです。

出典: Character Card V3 仕様(SPEC_V3.md) · Character Card V2 仕様(spec_v2.md)。項目一覧、チャンク名、CHARXコンテナ、未知のキーを保持するというV2の要件は、これらの仕様に基づいています。個々のアプリの挙動は異なるため、実際に使うアプリで確認してください。