AIキャラクターが「会話できる」ことと「あなたを覚えている」ことは別：記憶・状態・物語の結果を設計する3つの層

直前の発言に応じられるのは、単に文脈があるということだ。以前の好みに言及できて初めて記憶といえる。過去のやり取りが今日起こり得ることを変えて初めて、キャラクターは物語の状態を持つ。この3つを混同すると、「覚えているように話すのに、行動ではすべて忘れている」という問題が生じる。

最近の話題、ユーザーの呼び方、変わりにくい好み、明確な約束を保存し、繰り返しを減らす。すべての会話を永久に保存してはいけない。ユーザーは記憶を確認、訂正、削除できるべきであり、機微な情報にはより厳格な境界を設けるべきだ。

信頼、警戒、親密さ、借りを明示的にモデル化する。「ユーザーは良い人だ」と保存するより、「キャラクターがユーザーの約束履行を直接目撃した、trust +1」と記録し、状態の根拠を追跡できるようにする。

物語の状態は、イベントが発生するか、資源がまだ残っているか、約束を撤回できるか、どのノードに進めるかを決める。中核となる状態はルールで管理すべきであり、生成モデルがその場の思いつきで書き換えてはいけない。

たとえばユーザーが証拠を渡した場合、会話の層は議論を記憶し、関係の層は双方の信頼を変化させ、物語の層は証拠をもう所持していないことを記録して「証拠を提示する」を閉じる。3つの層が連携して初めて、結果に説得力が生まれる。

現在の状態を読み取り、このターンに必要な記憶を検索し、キャラクターの目標による制約に従って応答を生成し、記憶と状態変化の候補を提案する。その後、ルールによる検証を経て書き戻す。モデルがユーザーデータをすべて直接読んだり、中核イベントが成立したと独断で宣言したりしてはいけない。

memory: {fact, source, confidence, created_at, expires_at}
relationship: {character_id, dimension, value, reason}
story_state: {event_id, status, evidence, version}

会話できることは新鮮さを生み、覚えていることは関係を感じさせる。記憶がその後の機会を変えて初めて、物語を感じられる。

長期保存に適しているのは、変わりにくい好み、明確な約束、共有した経験、ユーザーが自ら覚えてほしいと求めた事実だ。一時的な感情、モデルによる性格の推測、未確認の機微な情報を、自動的に長期記憶へ入れてはいけない。

各記憶には、出典、確信度、時刻、有効期限のルールを含める。ユーザーが後から明確に訂正した場合は、新しい事実で上書きするか、矛盾を示すべきだ。モデルに無作為にどちらかを選ばせてはいけない。

キャラクターはプレイヤーを好きでも、秘密を守るとは信じていないかもしれない。能力を尊重していても、そのやり方を恐れているかもしれない。少なくとも、信頼、親密さ、警戒、借りなど、物語に関係する軸を分けるべきだ。軸を増やしすぎず、それぞれの書き込みと読み取りを明確に定める必要がある。

状態の変化には理由も必要だ。trust +1は、約束の履行や証拠の提供に結び付いていなければならず、モデルが友好的な台詞を1つ生成したからという理由ではいけない。そうすればチームはデバッグでき、ユーザーも結果を理解できる。

記憶そのものが物語を生むのではなく、ノードの条件が生む。プレイヤーに助けられたことを覚えているキャラクターは、危機の際に支援を可能にできる。プレイヤーが秘密を漏らしたことを覚えていれば、手がかりの共有を拒むかもしれない。読み取り時には現在のイベントや立場も確認し、古い記憶1つがすべての場面を永久に支配することを避ける必要がある。

異なるキャラクターが、同じ出来事について異なる記憶を持っていてもよい。システムは記憶を統一するために、物語上の対立を消してはいけない。同じキャラクターの記憶も薄れることはあるが、重要な約束や物語上の事実は確実に保持する必要がある。忘却は製品のルールで制御すべきであり、コンテキストウィンドウから偶然失われることに頼ってはいけない。

ユーザーは、システムが何を覚えているかを確認し、誤りを訂正し、保存したくない内容を削除できるべきだ。また、削除が物語の状態に影響するかも知る必要がある。会話ログ、長期記憶、物語の状態では保存期間が異なる場合があり、画面上でそれぞれ説明すべきだ。

機微なデータは、明確な機能を実行するために必要な範囲でのみ処理する。記憶が多いほど関係が本物らしくなるわけではない。誤った記憶を確信していると、かえって信頼を大きく損なう。

直後の言い直し、セッションをまたぐ想起、訂正、削除、矛盾する事実、有効期限、物語からの記憶の読み取りをテストする。さらに、誤った記憶候補を注入し、検証機構が書き込まないことを確認する。モデルのサービスを停止し、中核となる物語が引き続き正しく動作することも確認する。

最終的な受け入れ基準は、キャラクターが過去の細部をどれだけ話せるかではない。覚えるべき内容だけを覚え、適切なタイミングで行動に反映し、ユーザーに理解可能な制御を提供できるかだ。

プレイヤーが第3章で仲間の秘密を公表することを拒む。システムは元の会話全体を保存するのではなく、対象、「秘密を守る」という行動、発生した章、仲間が知っているかどうか、確信度、有効期限の条件を、構造化されたイベントとして書き込むべきだ。後に仲間がこのことを知った場合、上がるのは親密さではなく信頼かもしれない。誰も知らないなら、関係が理由なく変化してはいけない。

記憶を削除または訂正するときは、要約、ベクトルインデックス、関係の状態、キャッシュも同時に処理する。画面では削除済みと表示されているのに、キャラクターが台詞でまだ引用する事態を避けるためだ。テスターは、システムが覚えている情報の大まかな分類を確認し、長期記憶を無効にし、新しいセッションで撤回された内容を引き続き呼び出さないことを検証できるべきだ。

公開後の監視では、ヒット率だけを集計するのではなく、誤った想起、過度な繰り返し、機微な情報の残存、キャラクター間の情報の混線に注目する。情報を1つ正しく忘れることが、10回正確に言い直すことよりも信頼を築く場合がある。