AI girlfriend appのキャラクター状態をフロントエンドで扱う設計

前提

AI girlfriend appやAI companionサービスでは、キャラクターの状態をバックエンドだけでなくフロントエンドでも扱いやすい形にしておくと、UIの一貫性が保ちやすくなります。

ここでいうキャラクター状態とは、表示名、口調、会話トーン、ユーザーとの距離感、現在の会話モードなどです。落ち着いた会話体験を提供するAIコンパニオンのようなプロダクトでは、これらの状態がUIと応答生成の両方に影響します。

状態を分ける

フロントエンドでは、永続的なプロフィールとセッション中だけの状態を分けると扱いやすくなります。

type CharacterProfile = {
  id: string;
  displayName: string;
  baseTone: 'calm' | 'friendly' | 'playful';
  locale: 'ja' | 'en' | 'de';
};

type CharacterSessionState = {
  conversationMode: 'casual' | 'reflection' | 'creative';
  recentMoodHint?: string;
  safetyNoticeVisible: boolean;
};

プロフィールは変更頻度が低く、セッション状態は会話ごとに変わります。この2つを同じstoreに混ぜると、不要な再描画や保存範囲の曖昧さが出やすくなります。

UIでAIであることを明示する

キャラクター体験を作るときでも、UI上ではAIであることを明確に示す必要があります。たとえばプロフィールヘッダーや初回オンボーディングで、会話相手がAIであること、記憶や保存の扱い、現実の人間関係とは異なることを簡潔に伝えます。

この説明はモーダルだけに閉じ込めず、必要な場面で再確認できる導線にしておくと安全です。

APIレスポンスの形

バックエンドからは、生成テキストだけでなく、UIに反映する状態変化も返せるようにします。

type CompanionReply = {
  message: string;
  statePatch?: Partial<CharacterSessionState>;
  memoryNotice?: string;
};

状態更新を文字列解析に頼ると壊れやすいため、構造化されたフィールドとして返すほうが実装とテストが安定します。

まとめ

AI companionのフロントエンドでは、キャラクターらしさを演出するだけでなく、透明性、距離感、記憶の説明をUIとして支える必要があります。プロフィールとセッション状態を分け、APIからの状態更新を構造化して扱うことで、会話体験を安全に改善しやすくなります。