AIキャラクターとは？
今回は私が趣味で開発しているAIキャラクターについて書いていきます。
「AIキャラクターって何？」と思うかもしれません。それもそのはずで、これは私が考えている概念を表すために使っている言葉だからです。もしかしたら、世の中では別の呼び方があるかもしれません。
私の考えるAIキャラクターは単なる「入力を受けてキャラらしく返答するLLM」ではなく、「個性・思考・感情を持ったAIが、状況に応じにんげんのように考え、その結果として返答する仕組み」を目指しています。
このため、私が作ろうとしているのは単一のLLMそのものではなく、LLMをどう制御し、どういう内部状態を形容して応答させるかというアーキテクチャ寄りのか考え方です。
一般的なキャラチャットAIとキャラクタAIの比較
此処では、一般的なキャラチャットAIと、私が造ろうとしているAIキャラクターの違いを整理してみます。
既存のキャラチャットAI(ロールプレイAI)
一般的なキャラチャットAIでは、
- 過去の会話をそのままプロンプトに入れる。
- RAGで関連する設定や会話履歴を検索する。
- キャラクター設定をシステムプロンプトとして与える
といった方法がよく使われます。
この方式は手軽で強力ですが、最終的な振る舞いの大部分をLLMの生成に委ねることになります。
そのため、うまくいくときは自然でも、会話が長くなったり状況が複雑になったりすると、反応や感情の一貫性がぶれやすいという課題があります。
つまり、キャラらしさが「LLMがその場でうまく演じられるか」に依存しやすい構造です。
flowchart LR
A[ユーザー入力] --> B[会話履歴 / キャラ設定 / RAG検索]
B --> C[LLM]
C --> D[キャラらしい返答]私の目指す state型AIキャラクター
一方、私が作りたいのはstate型AIキャラクターです。
この方式では、入力された会話をそのままLLMに投げるのではなく、まず状態管理システムで処理します。たとえば、
- 今どんな気分なのか
- 相手にどう感じたのか
- 何をしたいのか
- 何を避けたいのか
- 直前までの状況はどうだったのか
といった内部状態を更新し、その結果をもとにLLMへ返答生成を指示します。
最終的に文章を作るのはLLMですが、そこに至るまでの意思決定や状態変化は、できるだけLLMに依存しない形で設計したいと考えています。
このため、state型AIキャラクターでは状態管理システムの設計そのものが主役になります。
flowchart LR
A[ユーザー入力] --> B[入力解析]
B --> C[状態管理システム]
C --> C1[感情更新]
C --> C2[欲求・目標更新]
C --> C3[状況認識]
C1 --> D[応答方針の決定]
C2 --> D
C3 --> D
D --> E[LLM]
E --> F[返答生成]なぜLLMに依存しすぎない構成にするのか
「結局LLMで全部やればいいのでは？」と思うかもしれません。しかし、私が状態管理を分離したい理由は大きく2つあります。
- 感情や状態は数値管理のほうが扱いやすいから
感情や欲求、ストレス、好意、集中度のようなものは、文章だけで曖昧に持つよりも、数値やルールで管理したほうが安定しやすいです。 - キャラごとの学習データを大量に用意するのが難しいから
もし状態管理まですべてLLM側で安定してやろうとすると、かなり多くの学習データや調整が必要になる可能性があります。しかし、キャラクターごとに大量の会話データや感情変化データを用意するのは簡単ではありません。
類似する技術について
近年、この方向に近いものとして注目されているのがAI Vtuberです。
たとえば、Ner0-sama のような存在は広く知られていますし、日本でもAIしずくのように話題になった事例があります。ただし、こうした先進的な事例の内部設計は基本的に公開されていないことが多く、外から見えるのは振る舞いの一部に限られます。
そのため、実際にどういう状態管理や制御をしているのかは推測するしかなく、自分で設計して試すしかない部分が大きいのが現状です。
内部システムを優先している理由
もともとはAI Vtuberのような形も考えていました。ただ、実際に進めようとすると、
- Live2Dや3Dモデルの制作コストが高い
- 開発用PCが古く、ローカルLLMの運用が厳しい
- API中心だと反応速度や没入感に課題がある
といった問題がありました。
そのため、まずは見た目よりも先に、中身となる状態管理システムを作ることを優先しています。
とはいえ、やはり最終的にはローカルLLM環境は欲しいですね。…100万円準備するか…
コメント