トレーナーが「頭が真っ白になった」と語った日、作業台から抜け落ちていたもの

アカライブキャラクターAI掲示板のユーザーYariPokéが共有した、ポケモンのロールプレイの一場面です。トレーナーの「サトシ」がアローラ地方メレメレ島の1番道路に到着した途端、こう語ります。「確かに、昨日まではスゴくすごいバトルをしたりして駆け巡っていたハズなんだよね。港から降りた途端、頭の中を消しゴムでゴシゴシ拭かれたみたいに真っ白になっちゃった！」ピカチュウは半眼でサトシの横顔を仰ぎ見ます。サトシが「クールに記憶を消せって意味だよね」と自分の名前にかけた冗談を言うと、ピカチュウは片方の耳をパタリと垂らし、額に前足を当てます。するとすぐに、「600匹のオッパイ」の話へと繋がっていきます ¹。

投稿の下部には、「脳がリセットされてるのを見るのはもう何度もある気がする」という一行のコメントが付いています ¹。これは、AIキャラクターが自らの記憶の空白を、物語内の台詞、つまり「記憶喪失」という設定として自然に処理してしまった瞬間です。これはバグ報告ではありませんが、現象を非常に正確に捉えた場面です。キャラクターがわざと忘れっぽい振りをしたのではなく、実際に以前の会話内容がAIの「作業台」から外された後、残された設定のみでその空白を説明した結果に近いからです。

作業台という比喩：AIは記憶せず、毎回読み直す

AIキャラクターが突然、前後で矛盾した発言をしたとき、私たちはしばしば「AIが忘れてしまった」と感じます。技術ブログ『junhyunp.github.io』は、この感覚をモデルの怠慢ではなく、構造的な問題として説明しています。大規模言語モデル（LLM）のAPIは、本質的に状態を保存しないステートレス（stateless）構造です。会話が自然に続いているように見えますが、実際にはリクエストのたびに、以前の会話全体を新しい質問と一緒に丸ごと送信し直しているのです ²。モデルが記憶して会話を続けているのではなく、ユーザーが毎回記憶の内容を再度聞かせているような状態です。

問題は、会話のターンが積み重なるほど、リクエストごとのサイズがどんどん大きくなることです。この限界を「コンテキストウィンドウ（context window）」と呼びます。『トゥックトゥック build』ブログの著者イ・ジェフ氏は、コンテキストウィンドウを机の上の「作業台」に例えています。作業台には、今の質問だけでなく、以前の会話、添付ファイル、事前に与えられた指示、ツールの実行結果、AIが作成中の回答まで、すべてが載せられます ³。机の空間が限られているのと同じく、作業台にも限界があり、その大きさは「トークン（token）」という単位で測られます。トークンは、AIが文章を処理する最小単位の断片であり、文字数と一対一で対応するわけではありません ³。

上限を超えると、サービスごとに空間を確保する方法が異なります。イ・ジェフ氏によれば、古い会話の一部を作業台から外すか、以前の内容を短く要約して再アップロードするか、関連部分のみを選択して取り込むか、新しい会話を要求するかのいずれかの方法が、製品によって使い分けられています ³。『junhyunp.github.io』の説明によると、APIを直接呼び出す場合は上限超過がエラーとして明確に示されますが、チャットボットサービスでは、前半部分を自動で要約・削除した後、ユーザーに何も表示せず会話を継続します ²。切り詰められた事実を知る術がないため、ユーザーは「なぜさっき言ったことを忘れたのだろう？」という疑問にたどり着くことになります。

システムプロンプトは残り、逸話は消去される

では、なぜキャラクターの性格は残ったまま、逸話や冒険の経験だけが消えてしまうのでしょうか。それは、作業台を構成する要素の管理可能性が異なるためです。『junhyunp.github.io』ブログの表によれば、システムプロンプト（役割・ルールの設定）はリクエストごとに固定で含まれ、制御可能性が高い項目です。一方、会話履歴（これまでの質問と回答のすべて）は、新しい会話を開始したり、要約によって調整できる対象です ²。つまり、「あなたはトレーナーのサトシで、パートナーはピカチュウ」という基本ペルソナ指示文は毎回再び載せられますが、「昨日、どの道路でバトルをし、マオという少女に出会った」のような細かな物語は、切り詰めや圧縮の対象となります。

キャラクターチャットサービスでは、こうした切り詰めがランダムというより、管理規定に従って行われることが多いです。『notes.io』に共有された『キャラクターチャット長期記憶の圧縮・統合ガイドライン 第2版』というドキュメントがそれを示しています。このガイドラインは、長期メモリスロットの本文の上限を、日付・期間および空白・句読点を含めて最大300文字に制限しています。第1次圧縮が、複数日付やシーンに散らばった原本を事案単位で整理する段階であるなら、第2次圧縮は、すでに洗練された複数の事案記憶を再び読み込み、同じ事案アーク・関係の変化・秘密・状態変化をより大きな単位で統合して、記憶の数を減らす最適化段階として定義されています ⁴。

このドキュメントが重要基準とする質問は明確です。「この情報を削除したとき、後のロールプレイにおける事実・関係・行動・情報状態は実際に変わるか？」 ⁴。変わらないなら、削除するか他の記憶に吸収させることができます。例えば、「一回限りの周辺キャラクターの反応」「単純な移動・食事・服装」「すでに終わった事案の詳細プロセス」「戦闘や行動の詳細な順番」は、縮小対象として明示されています ⁴。一方、「保存アンカー」と分類される、関係変化の決定的転換点、現在有効な約束・条件、未回収の伏線、永続的変化、ユーザー確定の設定は、他の記憶へ明確に引き継がれない限り削除されません。

つまり、「バトルして回っていたらしい」という抽象的な現在の状態は、保存アンカーに近く残りますが、そのバトルが具体的に何番道路で、誰とどのように進んだのかは、統合・削除の対象になり得ます。ガイドラインはまた、「メモリの数の削減よりも、検索性能と連続性が優先」と明記しており、無条件に情報を減らすのではなく、AIが後のロールプレイで必要な情報を正確に復元できるかを基準としています ⁴。この規定に従って圧縮された結果を作業台に載せると、AIはキャラクターの名前と基本的な性格を維持しつつ、冒険の詳細は空白の状態で回答を作成しなければなりません。

ピカチュウの台詞は、AIが「理由を創作」したものではない

改めてサトシの台詞に戻れば、この場面で起きたことがより鮮明になります。トレーナーが「昨日、スゴいバトルをして回っていたらしい」という抽象的な印象だけが残った状態で、「真っ白になった」という発言を生み出しました。これは、AIが突然自分の記憶メカニズムを自覚して、ギャグの台詞を創作したわけではありません。作業台には、基本ペルソナ指示文と、圧縮・切り詰めを経た空っぽの物語空間、そしてユーザーの入力しかありません。モデルは、その入力の中で最も自然な次の文を生成しただけです。「記憶の空白」という状況は、入力条件の中にすでに存在しており、キャラクター設定上それにふさわしい反応が、「真っ白になった」という台詞や、ピカチュウのため息、耳を垂らす動作として出力されたのです ¹。

コメントに記された「脳がリセットされてるのを見るのはもう何度もある気がする」という証言も、この観点から見れば誇張ではありません ¹。ステートレス構造において、会話の長さが上限を超えると、前半部分が静かに切り詰められるのは、モデルの故障ではなく、サービスの基本動作です ²。ロールプレイは、通常の質問・回答よりも会話履歴が膨大になりやすく、キャラクター設定と世界観ルールがシステムプロンプトで固定されるため、「人格は維持されるが、物語は初期化される」という体験が繰り返される条件が揃っています。

リセットをなくすことはできないが、頻度を減らすことはできる

技術的な構造を理解すれば、対処も明確になります。まず重要な前提があります。以下の手法は、「メモリリセット」という構造そのものをなくすものではありません。作業台の上限という物理的条件はそのままなので、切り詰めを完全に防ぐのではなく、「重要な情報の喪失頻度」を減らし、切られた後の復元を容易にすることに焦点が当てられています。

実際の対処法は、『junhyunp.github.io』と『トゥックトゥック build』ブログの提言を通じて整理できます ²³。まず、話題が完全に変わった場合や、古い指示と新しい目標が常に衝突する場合は、新しい会話を開始して、関係のない履歴とコストを減らす方が望ましいです ²³。会話が長くなった場合は、「これまで確定した内容、まだ決めていない内容、次の回答でも守るべき条件を分けて整理して」というように、現在の状態を要約してもらうとよいでしょう ²³。イ・ジェフ氏は、この整理結果を自分で確認することで、AIが誤って理解した部分も早期に発見できるとし、その後、その要約に基づいて新しい会話できれいな作業台を広げる方が効率的だとアドバイスしています ³。

キャラクターのロールプレイのように守るべき設定が多い作業では、重要な条件を直近のメッセージで改めて言及する方法が効果的です。「最初に言った通りでいいよ」と曖昧に指示するより、必ず守るべき条件を短く再提示する方が正確です。前半で切り詰められても、直近のメッセージに残っていれば、再び作業台に載せられるからです ²³。イ・ジェフ氏は、この条件を「必ず守る条件」のような別のブロックに分離し、本文の中に埋もれないようにすることを推奨しています ³。

サービス側の補完策も存在します。『OpenClaw』のようなAIアシスタントは、セッション終了時に消滅する短期コンテキストメモリと、セッション間で維持される長期永続メモリ（MEMORY.md）を区別して管理し、長い会話でトークン制限に達した場合は、/compact コマンドで会話を要約して核心的な文脈を保存します ⁵。外部ストレージを活用したり、メモリ機能を設けたりする方法も同じ文脈です。ただし、メモリに保存された情報でも、現在の作業台にロードされなければ、AIは認識できないため、保存の有無と実際の活用は別々に理解する必要があります ³。

サトシの場面に戻りましょう。もしユーザーがピカチュウと「本当に昨日のバトルの内容」を続けたかったのであれば、最も簡単な方法は、台詞を打つ前に、マオ・金髪の少女との初対面、現在所有している小遣い3000円と空のモンスターボール5個といった条件を、新しい作業台で改めて明示することだったかもしれません。AIが自らの記憶の空白を「消しゴムで拭いたみたいに真っ白になった」という台詞で物語の中に盛り込んだおかげで、ユーザーはそれを「脳のリセット」と呼んで笑うことができましたし、私たちも作業台が満杯になると何が起きるのかを、最も直感的な場面で確認することができました ¹。キャラクターが忘却を演じたのではなく、作業台から外れた情報を残された設定で埋めた結果であり、ユーザーは今後、重要な条件を直近のメッセージに残し、中間要約を活用して新しい作業台から再スタートすることで、この空白を管理できるようになります。