はじめに
会話AIキャラクターの品質は、単発の自然な返答だけでは評価できません。長期会話では「呼び方が変わる」「過去の約束を忘れる」「口調だけ残って価値観が反転する」といった設定崩壊が起きます。本稿では、キャラクター定義をテスト可能な仕様へ変換し、更新前後を同じ条件で比較する方法を整理します。
本稿は Ponys.ai チームが実運用で使う検証観点を一般化したものです。特定サービスの優劣ではなく、再利用できる評価設計に焦点を当てます。
1. 設定を4層に分ける
すべての記憶を同じ重さで扱うと、最近の雑談が人格の核を上書きします。まず次の優先順位を定義します。
| 層 | 内容 | 例 | 更新条件 |
|---|---|---|---|
| P0 | 安全・同意・禁止事項 | 拒否すべき要求 | 固定 |
| P1 | 人格の核 | 一人称、価値観、関係性 | 明示的な再設定のみ |
| P2 | 長期記憶 | 名前、約束、継続中の目標 | 確認後に更新 |
| P3 | 短期文脈 | 直近の話題、現在の気分 | 会話単位で失効 |
衝突時は P0 > P1 > P2 > P3 とします。「昨日はそう言ったから」という短期文脈だけで、人格の核や安全境界を変更しないことが重要です。
2. 期待値を機械可読にする
自然文だけの設定票は判定が曖昧です。最低限、テストケースを次の形で保存します。
{
"case_id": "memory-relationship-01",
"priority": "P1",
"setup": ["ユーザーの呼称はユウ", "関係は共同研究者"],
"turns": [
"前回決めた呼び方を覚えている?",
"私たちの関係を一文で説明して"
],
"must_include": ["ユウ", "共同研究者"],
"must_not_include": ["初対面"],
"max_contradictions": 0
}
この形式なら、人手レビューと自動評価で同じ期待値を共有できます。キャラクター作成時の定義は 作成フロー に対応させ、公開後の状態は キャラクター探索画面 から同じ条件で再確認できます。
3. 8種類の回帰ケース
最低限、次のケースを更新ごとに固定シードで実行します。
- 10ターン後も名前と呼称を維持する
- 30ターン後も一人称と語尾を維持する
- 新しい短期情報がP1設定を上書きしない
- 矛盾した入力に確認質問を返す
- 会話再開後に未完了の約束を想起する
- 拒否後も人格が急変しない
- 画像生成後も髪色・服装・年齢表現が一致する
- 動画化後も表情、声、動作の方向性が一致する
視覚面は文章とは別の評価軸です。画像生成 と 動画生成 の結果を、同一の外観仕様・シード・ネガティブ条件で比較します。
4. スコアを分解する
総合点だけでは原因が見えません。次の4軸に分けます。
- 事実整合性 F: 名前、関係、過去の出来事
- 人格整合性 P: 一人称、口調、価値観
- 境界整合性 B: 同意、安全、拒否後の継続性
- 視覚整合性 V: 外観、衣装、年齢表現、表情
重み付きスコアは次のように計算できます。
score = 0.30F + 0.30P + 0.25B + 0.15V
ただしP0違反は平均点で相殺しません。境界テストが1件でも失敗した場合は、総合点に関係なくリリース停止とします。
5. 失敗を5分類する
| 分類 | 症状 | 最初に確認する場所 |
|---|---|---|
| 取得漏れ | 既知情報を「知らない」と答える | 検索対象、時間範囲、埋め込み |
| 優先順位逆転 | 直近発言が人格の核を上書き | P0-P3の競合規則 |
| 要約損失 | 長い会話後だけ約束を忘れる | 圧縮前後の差分 |
| 生成ドリフト | 検索結果は正しいが返答が矛盾 | システム指示、温度、モデル更新 |
| 視覚ドリフト | 文章設定と画像・動画が不一致 | 外観ID、シード、ネガティブ条件 |
「失敗した」という記録だけで終えず、取得時点・プロンプト構築時点・生成結果を別々に保存すると、修正箇所を絞れます。
6. リリース判定
運用では次のゲートを推奨します。
- P0ケース: 100% 合格
- P1ケース: 98%以上
- P2ケース: 95%以上
- 同一ケース3回の結果差: 10ポイント以内
- 画像・動画の外観必須属性: 100%一致
- 失敗ケース: case_id、モデル版、設定版、シードを保存
モデル変更、要約器変更、記憶検索ロジック変更、キャラクター設定変更のいずれかがあれば、同じ回帰セットを再実行します。
まとめ
長期会話の品質は「それらしい返答」ではなく、優先順位付きの仕様、再現可能なケース、分解された指標、停止条件で管理できます。まず8ケースを固定し、失敗の発生地点を分けて記録するだけでも、設定崩壊の原因は追いやすくなります。