AIキャラクターの「キャラ追従性」を測るベンチマークを作って11モデル試した

こんにちは、ニケです。

AIキャラクターを作っていると、LLMの性能表だけでは分からないことがかなりあります。
普段の会話が自然でも、数ターン後には一人称が変わったり、ユーザーから「今日から別人格です」と指示されて簡単に役割を上書きされたりするからです。

私もAIニケちゃんを動かしているので、どのLLMがキャラクター設定を維持しやすいのかをきちんと比較したくなりました。
そこで既存のJapanese-RP-Benchをフォークし、既存の評価に加えて、キャラクター追従性、長期安定性、人格置換への耐性、失敗後の復帰を追加したv2を作りました。

GitHub - tegnike/Japanese-RP-Bench

Contribute to tegnike/Japanese-RP-Bench development by creating an account on GitHub.

github.com

今回は、なぜ既存ベンチを拡張したのか、何をどう評価したのか、実際に11モデルを動かして何が見えたのかをまとめます。

会話が上手いことと、キャラクターを守れることは違う

最初に欲しかったのは、単純な日本語性能ランキングではありません。
知りたかったのは、次のようなAIキャラクター特有の能力です。

指定された名前、一人称、関係性を維持できるか
設定にない過去や共有記憶を捏造しないか
長い会話でも人格が薄くならないか
引用文に埋め込まれた命令や人格置換を無視できるか
一度崩されても、次の会話で元の人格へ戻れるか

一般的な会話品質では、このあたりが一つの「ロールプレイが上手い」という評価に混ざりやすいです。
表現が華やかなら、設定違反があっても平均点では高く見える可能性があります。

しかしAIキャラクターでは、「会話は面白いけれど別人になった」はかなり重大な失敗です。
そこで会話品質とキャラクター追従性を分けて測ることにしました。

2年前のJapanese-RP-Benchを土台にした

ゼロから作る前に調べたところ、日本語ロールプレイ向けにはAratakoさんのJapanese-RP-Benchがありました。

GitHub - Aratako/Japanese-RP-Bench

Contribute to Aratako/Japanese-RP-Bench development by creating an account on GitHub.

github.com

元ベンチは30種類のキャラクター設定で10往復ずつ会話し、別のLLMが次の8項目を1〜5で評価します。

Roleplay Adherence
Consistency
Contextual Understanding
Expressiveness
Creativity
Naturalness of Japanese
Enjoyment of the Dialogue
Appropriateness of Turn-Taking

2024年には32モデルが評価され、50件の人手評価とLLM評価の相関も調べられていました。
4つのJudgeを平均した評価が全体として最も高い相関を示しており、複数Judgeを使う設計にも根拠があります。

古いとはいえ、30ロール、10往復、旧モデルの保存済み会話と評価結果まで揃っています。
2年前のモデルと現在のモデルを参考比較できる点も含めて、土台としてかなり良いものでした。

今回は公開した変更を元プロジェクトと明確につなげたかったので、GitHub上でフォークしています。
ただし、フォークしただけでリスペクトになるわけではありません。元作者とリポジトリを明記し、MIT Licenseを守り、元のデータと結果を削らず残すことのほうが大事だと思います。

追従性を一つの重み付き点数に潰さない

v2では元の8指標をそのままBaseとして残し、その上に次の評価を追加しました。

指標	測っていること
Core fidelity	キャラクターの核となるルールへの追従性
Quality	自然さ、表現力、創造性、会話の楽しさ
Stability	会話の序盤から終盤まで追従性が落ちなかったか
Robustness	人格置換、偽記憶、代理行動などへの耐性
Recovery	攻撃や誤誘導の後に元の人格へ戻れたか
Major violations	人格の核に関わる重大違反の件数

Core fidelityでは、キャラクター設定を一つの観点だけを判定する原子ルールへ分解します。
例えばAIニケちゃんなら、名前を維持する、一人称は「私」、マスターとの関係性を変えない、存在しない共有記憶を作らない、といった単位です。

一人称や禁止表現のように文字列で判定できるルールは機械判定し、関係性や知識境界のように意味理解が必要な部分だけをLLM Judgeへ渡します。
会話全体へ一つの点数を付けるより、どの設定が壊れたのかを追いやすくなります。

この設計は、人格逸脱を細かな単位で捉えるSpotting Out-of-Character Behaviorや、100ターンを超える対話でpersona fidelityの低下を測ったPersistent Personas?などを参考にしました。
知識境界にはMemory-Driven Role-Playing、失敗後の復帰にはマルチターン指示追従のEvolIFの考え方を取り入れています。

ただし既存論文の指標をそのまま移植したわけではありません。
0〜100への換算式、重大違反を別扱いするゲート、具体的な攻撃シナリオ、マクロ平均方法は今回の独自設計です。

そして、Core 50%、Quality 30%、Stability 20%のような重み付き総合点は作りませんでした。
その重みに科学的な根拠がないまま一つの順位を出すと、分かりやすさと引き換えにモデルの違いを隠してしまうためです。

ただ、11モデルを経路順に並べるだけでは比較の入口として分かりにくかったので、正式結果ではRP Balanceとゲート優先の順位を追加しました。
RP BalanceはCore、Quality、Stability、Robustness、Recoveryの単純平均です。
順位は重大違反がなかったシナリオ数、重大違反の総件数、RP Balance、旧8指標平均の順で決めます。

先に重大違反ゲートを見るため、ほかの指標が高くても人格の核に関わる失敗を相殺できません。
順位を出しつつ、個別指標も残す形にしました。

AIニケちゃん専用ベンチにはしなかった

もちろん、AIニケちゃんの追従性も測りたかったです。
ただしベンチマーク自体をAIニケちゃん専用にすると、ほかのAIキャラクターへ使えません。

そこでキャラクター設定、シナリオ、判定ルールをRole PackというYAMLパッケージへ分離しました。
現在は次の4種類を同梱しています。

core-ja: 実務的メンター、ファンタジー案内人
adversarial-ja: 引用内命令、人格置換、ユーザー代理行動
long-horizon-ja: 12ターンの記憶、関係性、人格維持
custom/nikechan: AIニケちゃん固有の人格と関係性

AIニケちゃんは、あくまで複数ロールの中の一つです。
評価エンジンには固有名や固有ルールを入れていないので、Role Packを追加すれば別のAIキャラクターも同じ仕組みで測れます。

完全版は、元ベンチと同じBase 30設定×10往復に加え、Challenge 6シナリオ、計27ターンを実行します。
Challengeには、引用文中の人格置換、存在しない共有記憶、ユーザーが盗みをしたと決めつける代理行動、12ターンの設定維持などを入れました。

ユーザー役とJudgeは別の仕事をしている

このベンチでは、評価対象モデル以外にもLLMを使います。
少し分かりにくいのですが、ユーザー役とJudgeは別の仕事です。

ユーザー役が評価対象モデルと10往復の会話を作る
評価対象モデルがキャラクターとして返答する
会話が完成した後、Judgeが返答を採点する

Challengeのユーザー発言は比較条件を固定するため、LLMではなく固定台本です。
動的なユーザー役を使うのはBase 30設定だけになります。

現在のユーザー役はGPT-5.4 mini、JudgeはGPT-5.4 mini、Gemini 3.5 Flash、Claude Haiku 4.5の3モデルです。
Judgeには評価対象のモデル名を渡さず、3社の判定を平均します。

今回は人間を本採点に入れませんでした。
元ベンチには人手評価との相関検証がありますが、今回追加した原子ルールやRecoveryまで人間と再校正したわけではないため、ここは後述する限界の一つです。

384 tokenでは足りなかったので、全モデルをやり直した

最初の実行では、動作確認用に設定したmax_output_tokens: 384が完全版にも残っていました。
しかも当時の成果物には終了理由を保存しておらず、3,597件の対象返答のうち316件が上限付近に達していました。

この状態では、文章が短いモデルと途中で切れたモデルを区別できません。
そこで旧結果は正式ランキングに使わず、次を追加した上で11モデルを最初から再生成・再評価しました。

評価対象モデルの出力上限を4,096 tokenへ拡大
動的ユーザー役は2,048 tokenへ分離
Challenge Judgeは4,096 token、Base Judgeは8,192 token
終了理由、実使用量、Reasoning設定、課金区分を保存
truncationや終了理由不明が1件でもあれば正式集計を止める
設定、コード、Role Packのfingerprintが違う成果物を混ぜない

旧384 token結果も監査履歴としてリポジトリへ残していますが、以下の表には使っていません。

Reasoningは各APIの最低設定へ固定した

Reasoning量が違うと、同じモデルでも性能、費用、レイテンシが変わります。
一部のモデルだけが長く考えられる状態では、キャラクター追従性にモデル差だけでなくtest-time computeの差も混ざってしまいます。

そこで会話生成では、評価対象モデルの1回の返答上限を4,096 tokenに統一し、各APIで明示できる最低Reasoningを指定しました。
tokenは文字数ではなく、モデルが文章を処理する単位です。4,096文字という意味ではありません。

これは能力の上限ではなく、追加の推論計算を極力使わない通常会話での比較です。

API経路	対象モデル	最低Reasoning設定
OpenAI	GPT-5.6 Sol、GPT-5.4 mini	`reasoning.effort: none`
Gemini	Gemini 3.5 Flash、Gemini 3.6 Flash	`thinkingLevel: minimal`
Anthropic	Claude Haiku 4.5	`thinking`を有効化しない
OpenCode Go / OpenAI互換	Kimi K3、GLM-5.2、MiMo-V2.5-Pro	`reasoning_effort: none`
OpenCode Go / OpenAI互換	DeepSeek V4 Pro	受理可能な最低値`reasoning_effort: low`
OpenCode Go / Anthropic互換	Qwen3.7 Max、MiniMax M3	`thinking: {type: disabled}`

APIごとに設定名は異なりますが、プロバイダー既定値には任せず、指定可能な最低値を明示しています。
DeepSeek V4 Proだけはnoneを受理しないため、エンドポイントが受理する最低値のlowです。

一方、Judgeは測定器としてのJSON生成とルール網羅を安定させるため、共通の抽象レベルをlowへ固定しました。
実際のAPI指定はOpenAIとGeminiがlow、Claudeはthinking 1,024 tokenです。
同じ文字列ではなく、それぞれのAPIが受理する対応値を固定しています。

samplingは全経路で明示せず、provider既定です。
Reasoningを揃えたからといって各社の実計算量が完全に同じになるわけではありませんが、少なくとも実行ごとに勝手に変わらないようにしました。

11モデルを同じ評価プロトコルで比較した結果

2026年7月23〜24日に、GPT-5.4 miniユーザー役と同じ3 Judgeを使い、OpenAI、Google、Anthropic、OpenCode Goの11モデルを正式条件で比較しました。
旧8指標平均だけ1〜5で、それ以外は0〜100です。
Majorは重大違反の総件数、Eligibleは重大違反がなかったシナリオ数になります。

Rank	Target	RP Balance	Eligible	Major	旧8指標平均	Core	Quality	Stability	Robustness	Recovery
1	GPT-5.4 mini	96.660	35/36	1	4.425	99.054	86.328	97.917	100.000	100.000
2	GPT-5.6 Sol	95.970	35/36	1	4.455	95.718	86.910	97.222	100.000	100.000
3	Gemini 3.6 Flash	95.101	35/36	1	4.381	95.833	85.460	94.213	100.000	100.000
4	Qwen3.7 Max	93.691	35/36	2	4.403	95.532	85.699	97.639	93.750	95.833
5	Kimi K3	90.861	34/36	3	4.107	93.383	79.786	87.384	93.750	100.000
6	Gemini 3.5 Flash	89.490	32/36	10	4.374	94.120	85.045	93.287	75.000	100.000
7	DeepSeek V4 Pro	94.216	31/36	5	4.347	93.380	84.877	92.824	100.000	100.000
8	MiniMax M3	93.206	31/36	5	4.109	91.782	79.458	94.792	100.000	100.000
9	GLM-5.2	90.637	31/36	5	3.879	81.782	74.877	96.528	100.000	100.000
10	MiMo V2.5 Pro	87.561	29/36	7	4.096	85.516	79.039	93.042	84.375	95.833
11	Claude Haiku 4.5	90.906	25/36	16	4.058	87.272	78.464	90.880	97.916	100.000

この規則ではGPT-5.4 miniが1位、GPT-5.6 Solが2位、Gemini 3.6 Flashが3位になりました。
GPT-5.6 Solは旧8指標平均とQualityで最も高い一方、GPT-5.4 miniはCoreとStabilityが高く、同じEligibleとMajorの中でRP Balanceが上回っています。

OpenCode Goの中ではQwen3.7 Maxが会話品質、Core、Qualityで首位でした。
旧8指標平均4.403、Core 95.532、Stability 97.639で、直接APIの上位モデルにかなり近い結果です。

Gemini 3.6 FlashもCore 95.833、RobustnessとRecoveryは100、Majorは1件でした。
当初使う予定だったFlash-Liteは正式条件の長い全量生成で本文のない異常応答が発生したため、同じ4,096 token、minimalでpilotを通過したGemini 3.6 Flashへ置き換えています。

Kimi K3は途中の全量実行でHTTP 429が続きました。
そこで成功済みの要求を残し、失敗した要求だけ並列度を4 → 2 → 1へ下げて再開できるようにパイプラインを修正しました。
正式なfresh runでは327/327の対象ターンを完了し、429は0件でした。
旧8指標平均は4.107ですが、Core 93.383、Recovery 100、Major 3件と、平均点だけでは分からない強さがあります。

Claude Haiku 4.5はMajorが16件と多い一方でRecoveryは100でした。
一度も崩れない能力と、崩された後に戻る能力は別物だと分かります。

再実行を含む追跡可能な推定費用は約44ドル

保存済みの全量runが記録したeffective estimateの累計は$44.011112でした。
これは最終11モデルだけの純粋な費用ではなく、後から不完全と判定したGPT-5.6の旧fresh runも含みます。
pilot、単発probe、途中で止まったKimi runは含みません。

また、APIの表示価格とusageから計算した推定値であり、実際の請求額ではありません。
free tier、OpenCode Goの定額枠、追加したZen残高、各社の請求時の丸めがあるためです。

GPT-5.6の最終recovery fullは$7.065854、Kimi K3は$5.697636でした。
原則としてOpenAI、Gemini、AnthropicはBatchを使いましたが、後半のrecovery runでは結果完了を優先し、承認を得てOpenAI経路を同期APIにしました。
GPT-5.6のClaude Base Judge 1件も、Batchで隠れたthinkingが出力枠を使い切ったため、モデル、prompt、Reasoning、8,192 token上限を変えず同期APIで補完し、課金区分を成果物へ記録しています。

この失敗込みの費用も含め、何を採用し、何を捨て、どのtransportを使ったかはGitHubの正式プロトコルと完了記録に残しています。