NSFW AI ロールプレイが物語を忘れる理由と、記憶を修正する方法

キャラクターは目の色を覚えているのに、昨日の約束を忘れる。一晩かけて築いた関係が、初対面に戻る。その場にいなかった人物が秘密を口にする。長い NSFW ロールプレイに AI を使うなら、こうした誤りはぎこちない文章以上に、すぐ場面を台無しにします。

実用的な対策は、記憶の種類ごとに置き場所を分けることです。 人物の基本設定と変わらない境界はキャラクター定義へ、今いる場所、関係、直近の状況は短い現在状態のメモへ置きます。終わった場面は事実に基づく出来事の要約にし、過去の出来事は必要なとき lorebook や検索システムで呼び戻します。直近の会話は残し、キャラクターらしい話し方を保ちます。

大きなコンテキストウィンドウなら多く入りますが、間違った要約や古い関係の事実は直りません。別モデルへお金を払う前に、フロントエンドが実際に何を送ったかを確認します。必要な事実はプロンプトから消えていて、間違った事実は中に残っているかもしれません。

このガイドでは、記憶の情報源が見えて編集できる SillyTavern を使います。例は Mara、32 歳と Julian、35 歳の架空の成人恋愛物語です。文章の例で、モデルテストの会話記録ではありません。キャラクター設定、要約、永続メモを編集できるなら、他のフロントエンドでも同じ構成を使えます。

まず、どの種類の「忘れ方」なのかを見分ける

間違った返答がすべて記憶の問題とは限りません。出来事を知っていても、好みに合わない反応をすることがあります。事実は保っても話し方が変わることも、モデルやサービスの内容規則で場面を拒否することもあります。それぞれ別の変更が必要です。

記憶では、具体的な誤り 1 つから始めます。期待する事実を書き、その事実が成立した会話の部分を探します。次の要求に含まれた情報と比較します。SillyTavern の プロンプトのドキュメントには、返答の Prompt Itemization と任意の Prompt Inspector 拡張を含む、組み立てられたプロンプトの確認方法があります。

探すのは次の 3 状況です。

• 事実がない。 引き継ぐか検索で取得する必要があります。要求に入らない注意書きはモデルを助けられません。
• 事実はあるが古い版もある。 古い版を削除するか、時点を明確にします。さらに注意書きを足すと矛盾が増す場合があります。
• 正しい事実が矛盾なくある。 モデルが読み違えたり、それを越えて推測したり、他の指示を重く扱ったりしている可能性があります。文を明確にし、余計な情報を減らし、構成全体を変える前に短い続きを試します。

Mara が 2 回目のデート後、Julian を自宅へ誘ったとします。次の場面で彼が「初めてのデートに応じてくれるだろうか」と聞く。要求にデートがなければ履歴の喪失です。カードに「まだ会ったことがない」とあれば古い設定です。要求が 2 回のデートと今の関係を明確に示すなら、生成が渡された情報を使えていません。

この区別で次の作業が決まります。履歴の喪失には記憶項目、古い設定には編集、生成の誤りには続きの修正や焦点を絞ったプロンプトが必要です。区別前に記憶拡張をもう 1 つ入れても、構成が複雑になるだけで実際の原因は直りません。

これは初期診断で、各問題に原因が 1 つだけという保証ではありません。「もっと覚えて」と頼む代わりに、具体的な文を変更できる点が役立ちます。

5 種類の情報に、5 つの役割を与える

良い物語の記憶は、すべての文を残すものではありません。昨日の文章で次の場面を埋めず、必要な情報を残します。人間の共同執筆者に、人々が誰で、何が変わり、今何をし、どの過去がまだ影響するかを伝えるつもりで考えます。

恒久的なキャラクター設定：どんな人物か

物語全体で保つ情報はキャラクター定義へ置きます。年齢、人物像、中心的な性格、確立した好み、主な恋愛以外の持続する関係、AI が演じる役の境界です。

Mara なら、次のような定義が使えます。

Mara は 32 歳の修復記録を撮る写真家。観察力があり、皮肉の利いたユーモアを持ち、私的な感情を語るまで時間がかかる。姉妹の Leena は別の街に住む。愛情を直接言う前に、実際の手助けで示す。Julian の台詞、判断、感情はユーザーが操作する。

モデルが書く人物を示すもので、毎回、姉妹の Leena、職業、性格の説明を登場させる指示ではありません。永遠に感情的な距離を保つという意味でもありません。性格の中心的な傾向にも、成長の余地を残します。

SillyTavern の キャラクター設計ドキュメントは、毎回の生成に含む定義項目と、長い恒久設定が会話履歴の余地を減らすことを説明しています。必須の人物情報を置き、長い世界設定や付随的な過去は別へ移します。

カードを増え続ける会話記録にしないでください。すべてのデート、口論、衣装を追加すると、人物像と出来事を区別しにくくなります。再利用する定義も、1 つの物語専用になります。開始カードは整理し、変化する関係はそのチャットの記憶へ置きます。

現在状態：今、何が事実か

現在状態は変わります。部屋を移り、口論が解決し、訪問者が帰り、関係が深まったり休止を求めたりします。恒久的な特徴ではないため、永遠の人物像のように保存しません。

今の場面には、例えばこう書きます。

現在の場面：金曜の夜、2 回目のデート後の Mara の自宅。Mara と Julian は打ち解けているが、他の人と交際しない約束は話していない。Mara は今コーヒーを勧め、Julian はまだ答えていない。Leena はいない。未回答の申し出から続け、初対面の紹介をやり直さない。

素早く読める短さで、初期化を防ぐ具体性があります。未回答の申し出は、物語が止まる地点を示すため重要です。なければ、要約でユーザーの次の選択を飛ばしてしまうことがあります。

SillyTavern では、チャット固有の Author's Note が置き場所の 1 つになります。Author's Note ガイドは位置と挿入頻度の設定を説明しています。場面の注意書きに使うとき、頻度 0 では挿入されず、1 ではユーザー入力ごとに入ります。実在する設定で、モデルに適した位置は確認しながら調整します。

大きな現在状態メモを一晩同じままにしないでください。自宅を完璧に説明していても、外へ出れば間違いになります。古い部屋の下へ新しい部屋を追記せず、場面の変化時に置き換えます。

出来事の要約：実際に起きたこと

終わった場面は出来事の要約へ置きます。誰が何をしたか、何が変わり、何を合意し、何が未解決かを示します。美しい場面を書き直すのではなく、出来事の記録です。

この例なら次です。

金曜、2 回目のデート：Mara と Julian は夜の展示へ行った。Julian はスタジオ用に借りた真鍮の鍵を返した。Mara は Leena との難しい話を避けていたと打ち明けた。Julian は、自分から Leena に連絡せず話を聞くと申し出た。日曜の午後、スタジオで会うことにした。後で Mara はコーヒーを飲みに自宅へ誘った。他の人と交際しない約束は話していない。

鍵を返した結果、Julian はもう持っていません。Leena の約束により、突然電話すべきではありません。日曜の面会は将来の予定で、完了した訪問ではありません。最後の文は不確定な点を残し、暖かな夜を正式な交際の約束へ変えません。

展示の光の描写が繰り返されても、それを省いて変化を残せます。物語のための選択的な記憶で、無損失の保存ではありません。正確な台詞を後で使いたいなら、元の会話を保管します。

lorebook の項目：関連するときだけ出すこと

lorebook は、ときどき重要になる場所、共有の物、脇役、過去の重大な出来事に便利です。台所の会話ごとにスタジオを詳しく説明する必要はありません。

SillyTavern の World Info ドキュメントは、キーなどで条件付き挿入を行う設定を説明しています。実務上重要なのは、保存と有効化の違いです。保存しても、内容が挿入されなければ次の返答には役立ちません。

真鍮の鍵には、単独で意味が通じる項目を作ります。

スタジオの真鍮の鍵：最初のスタジオ訪問時、Mara は Julian に貸した。金曜の展示で返却済み。現在、Julian はスタジオの鍵を持っていない。受け渡しは初期の信頼の表れで、いつでも自由に入る恒久的な許可ではない。

ホテルの鍵、ピアノの鍵盤、重要な決断などが出る物語で、「key」だけでは不要な反応が増えます。「studio key」「brass key」のような、自然に話題にする特徴的な語を使います。非表示のタイトルやキーワード一覧が出来事を説明すると期待せず、挿入する内容自体で意味が通るようにします。

この例をチャットへ入れるには、次のようにします。

1. World Info で物語用の lorebook を作るか選び、項目を追加します。鍵の段落を Content へ貼り、Key に studio key, brass key を入れます。項目を有効にします。
2. Character Management → Chat Lore でその lorebook を選び、現在の会話へ結び付けます。すでに結び付いている場合は編集画面が開きます。デスクトップでは Shift+Click、モバイルでは長押しで選択画面を開き直します。
3. 続きで「brass key」に触れ、返答の Prompt Itemization を開きます。組み立てた要求に返却済みの段落があるかを見ます。存在は挿入の証拠で、正しく使われた証拠ではありません。

検索型の記憶：大きな保管記録から役立つものを探す

検索型は、全項目を毎回挿入せず、現在の会話に関係する内容を探します。章が多い物語に便利でも、話題の類似が自動的に「最新の事実」を意味しないため、古い状況を戻す場合があります。

SillyTavern の Chat Vectorization ドキュメントには過去の会話検索とプロンプトキャッシュとの兼ね合いが、Data Bank ガイドには添付文書と範囲が説明されています。役割の違う有用なツールですが、完璧な連続性のスイッチではありません。

重要な出来事が少ない短い恋愛物語なら、編集済み要約と明確な項目から始めます。それでは扱いにくい実際の想起問題が出てから検索を加えます。例えば 12 章の細部が 30 章で必要な場合です。今日の関係を常に使えるメモへ 1 文置く方が、毎ターン検索で再発見させるより簡単です。

人物設定、現在状態、過去の出来事には別の役割があり、直近の会話が話し方を保ちます。

何かを導入する前に使える小さな構成

フロントエンドを全面的に作り直さず、苦戦するチャットを修正できます。最初はキャラクター定義、現在状態メモ 1 つ、読みやすい要約 1 つで十分です。消え続ける事実の置き場所ができます。

先に会話のコピーを保存します。周囲の記憶を編集するため、前の状態へ戻したくなるかもしれません。SillyTavern の チャットファイル管理ガイドには、書き出しとチェックポイントがあります。テキストは読むのに便利で、JSONL は再インポート用のメタデータを保ちます。画像と添付は別です。

次に 3 つ編集します。

1. 古い開始条件を除く。 「Mara と Julian は会ったことがない」「Julian はまだ信頼されていない」などを探します。カードが意図的な開始テンプレートで、後の出来事が優先されると明確な場合だけ残します。そうでなければ、進行中の物語を開始地点へ引き戻します。
2. 現在状態を数段落以内で書く。 場所、いる人物、今の関係、直近の動作、最後の未回答の選択を含め、次の返答に影響しない細部は外します。
3. まだ重要な古い出来事を要約する。 約束、解決、発見、予定を含めます。モデルに穴埋めさせず、未確定の問いには「未確定」と付けます。

この例では、次を手動の現在状態メモとしてコピーできます。

Mara、32 歳と Julian、35 歳の進行中の物語。何度か会っており、2 回目のデート後、Mara の自宅にいる。互いに関心があるが、他の人と交際しない合意はない。Mara は Leena との対立を話し、Julian は Mara の代わりに Leena へ連絡しないと約束した。日曜のスタジオ面会は予定で、まだ行われていない。Mara はコーヒーを勧め、答えを待っている。Julian の行動を決めず、ユーザーが示す次の行動に対する Mara の反応を書く。

「Julian はコーヒーを受け入れ、どのマグを勧めるか聞く」と、背景を増やさない控えめな一文で続けます。Mara が自宅にとどまり、知り合いとして扱い、未解決の家族問題を適切な位置に置くかを見ます。モデルの全能力ではなく、修正した状態が普通の続きに十分かを確認します。

まだ初期化するなら実際の要求を再確認します。メモが無効、別の lorebook が矛盾、別チャットや persona を使用、といった可能性があります。要求が正しいなら、悪い返答が次のターンの例になる前に編集か再生成します。誤りが実際に起きたかのように続けると、孤立した生成ミスが物語の履歴になります。

雰囲気ではなく変化を保つ要約を書く

曖昧な要約は自然に聞こえても、必要な細部を落とします。「Mara と Julian は心温まる夜を過ごし、距離が縮まった」では、次の場面を決めるほぼすべてが不明です。秘密を明かしたか、約束したか、口論は解決したか、次の面会を決めたかが分かりません。

良い要約は観察と解釈を分けます。カメラを預けるほど信頼すると言ったなら、その具体的な信頼を残し、「完全に信頼」と一般化しません。手紙を隠していると疑ったなら疑いで、手紙を発見したことにはしません。成人向けの物語には示唆やためらいが多く、記憶ではその違いを滑らかに消さず残します。

拡張の必須出力形式とは別に、手動で使える要約依頼は次です。

終了した場面を、進行中の架空の物語の連続性メモとして要約する。確立した行動、関係の変化、約束、返却・譲渡した物、発見、現在地、未完了の予定を維持する。私的な告白には立ち会った人物を示す。確定した出来事と、推測、想像した可能性、将来の意図を区別する。会話で成立していない動機、約束、出来事を追加しない。最後に未解決の動作を記す。簡潔で平易な文を使い、曖昧な代名詞ではなく名前を残す。

文章作成の補助で、テスト済みの万能プリセットではありません。手動のテキスト要約に適しています。構造化 JSON を要求する拡張には、その形式を保つ必要があります。文章の依頼へ置き換えると、記憶作成が壊れる可能性があります。

意図的に間違えた要約を考えます。

展示の後、Mara と Julian は恋人になった。Mara は姉妹である Leena についてすべてを話し、スタジオへ入る権利を与えた。Julian は助けようと Leena へ電話すると決めた。自宅へ行き、コーヒーを飲んだ。

ほぼすべての文が物語を変えています。「恋人になった」は約束の創作、「すべて」は告白の誇張、「入る権利」は鍵の返却の無視、「決めた」は Julian の選択の創作、「飲んだ」は未回答の申し出を飛ばしています。

美しい言い回しを求めず、会話を参照して修正します。有用なのは上の事実に基づくメモです。自動要約を読むときは、本の紹介文のように聞こえるかではなく、実際の判断を保ったかを確認します。

起きていない重要なことも明記する

重要なのが、まだ起きていない事実の場合もあります。独占的な交際を話していない、Julian は Leena と会っていない、Mara は手紙の内容を明かしていない、日曜の訪問は未実施、といった点です。

モデルが安易に物語を飛ばすのを防ぎます。混同する現実的な危険がある場所に使い、起きたことのない全出来事の巨大な一覧にはしません。「独占的な交際の話はまだない」は重要ですが、「火星へ行ったことがない」はこの恋愛には不要です。

感情が変わった具体的な原因を 1 つ残す

乾いた記録は、出来事を保っても重要な理由を失うことがあります。「Julian が鍵を持ち続けたいと頼まず返したため、Mara は安心した」のように、感情の変化の原因を正確な 1 文で残します。新しい恒久的な性格を宣言せず、次の書き手が反応できます。

「Mara は今幸せ」と比べてください。何について、どれくらい、どの場面でかが不明です。具体的な原因なら後でも複雑な感情を持てます。曖昧なラベルは、次の更新まで 1 つの気分へ平坦化する誘因になります。

保管記録と次の場面の短い要約を分ける

詳しい出来事の保管記録と、短い有効な要約は両立します。保管記録は「この章で何が起きたか」、有効な要約は「次の返答が何を守るべきか」に答えます。長さを同じにする必要はありません。

10 場面後の全履歴には、初対面、スタジオ訪問、展示、自宅の会話、日曜の予定が入るかもしれません。自宅の場面に必要なのは、今の関係、関連する約束、会話の停止位置です。鍵が話題に出たら、その履歴を取得します。

これなら記憶作りが宿題になりません。2 メッセージごとに全物語を書き直さず、意味のある変化を保存し、小さな現在状態メモを保ち、普通の会話の細部は場面が終わるまで直近履歴へ残します。

単純な更新型要約には標準の Summarize を使う

主な目的が「この会話のあらすじを使えるようにする」なら、標準の Summarize 拡張は最初の選択として合理的です。Extensions で開き、動く情報源を選びます。Main API は有効な接続を使います。Current summary の最初の結果を読み、頼る前に修正します。

公式 Summarize ガイドには Pause と Restore Previous もあります。更新が約束を創作したり、既存の約束を落としたりした場合に有用です。自動更新を止めて直すか、以前の要約へ戻して正しい変更を加えられます。

更新間隔は儀式的な数字ではなく、会話に合わせます。短い 20 返答は話をほとんど進めず、長い 20 返答には対立、告白、移動が入るかもしれません。重要な過去が有効な履歴から消える前と、次の返答に必要な情報が変わった後に更新します。

最初は場面終了時に手動で要約します。2～3 個を読み、構成が何を省きやすいかを見ます。その後、普段の返答の長さに合う自動間隔を設定します。1 週間後に全要約が関係を変えたと気付く代わりに、有用な基準を持てます。

更新型は便利でも、古い要約を繰り返し圧縮すると小さな事実が落ちます。持続する約束は、毎回残ることを期待せず独立項目へ保護します。要約には「Leena についての約束は継続中」と書き、別項目で正確な範囲を残せます。

要約に話し方のすべてを背負わせません。有用な出来事を保ち、直近のメッセージと小さな会話例で、皮肉の利いたユーモア、リズム、丁寧さを保ちます。全出来事に長い文体指示を混ぜると読みづらく、複数が有効になったとき会話を圧迫します。

別々の場面の編集可能な記憶には Memory Books を使う

1 つの更新型要約では管理しづらくなったら、ST Memory Books が役立ちます。変化し続ける要約だけに頼らず、個々の場面を保存し、重要なものを編集できます。長い恋愛では、最初のデート、家族の告白、鍵の返却を、別々の読める記録にできる実務上の違いがあります。

最近の SillyTavern コミュニティの議論では、投稿者が特に STMB などの記憶拡張で体験が改善したと述べています。要約拡張の議論でも、編集可能な lorebook の記憶と自動要約の間で選ぶ利用者がいます。個人の好みで、全モデルを改善する統制された証明ではありません。

プロジェクト自身の 開始ガイドから始めます。導入、lorebook の選択、最初の手動記憶が説明されています。適切な本と Current SillyTavern Settings のプロファイルを選び、開始・終了の操作で完了場面を指定し、記憶を 1 つ作ります。自動化の前に結果を開きます。

ローカルや Text Completion の接続なら、現在の前提条件を読みます。追加の接続要件と構造化出力の期待があり、良い会話を書けても、記憶作成用 JSON に失敗するモデルがあります。最初を動かす間は、標準の出力形式を保ちます。

最初には、短い完了済み出来事を選びます。例の展示でのやり取りは、始まり、返却、告白、予定があるので適しています。未完了の自宅の会話まで一晩をまとめると、完了した出来事と今後の可能性を混同しやすくなります。

手動で動いたら、Memory Books のユーザーガイドで自動作成、場面選択コマンド、他の操作を確認します。開始時の推奨間隔は 20～30 メッセージで、全場面がその長さに合う保証ではありません。最初の自動項目を読み、自分の書き方へ合わせます。

通常の場面の変化は拡張に保存させ、歪むと連続性を損なう少数の展開を手動で直します。展示なら、誰が鍵を返し、家族問題を誰が聞き、日曜が未実施か、交際の約束が本当に成立したかを確認します。

要約ツールを 3 つ同時に入れないでください。少し違う要約が加わると、同じ夜の 3 版が要求内で競合します。出来事の記憶システム 1 つと明確な現在状態メモから始め、説明できる別の問題を解決するときだけ加えます。

文体ではなく出来事を修正します。返却した鍵と未完了の予定は、記憶でもそのまま残します。

キャラクターを書き換えず、関係を最新に保つ

NSFW ロールプレイでは、信頼、親しさ、不確実さの積み重ねに依存する場面が多く、関係のずれは特に困ります。場所を覚えていても関係を忘れると、技術的には筋の通る、感覚的にはまったく違う場面になります。

記録を 2 つ使います。一方は関係を変えた出来事、他方は今の関係です。前者は履歴、後者は現在です。

過去の出来事：

展示後、Mara は Julian を自宅へ招いた。2 人きりで安心でき、Leena の話を無理に聞かなかったことに感謝すると言った。2 回目のデートだった。どちらも独占的な交際を提案していない。

現在の関係：

Mara と Julian はデートを重ね、好意を示すことに抵抗がない。まだ互いの好みを知る段階。独占的な交際の合意はなく、相手の将来の判断を決め付けない。

後で約束したら第 2 記録を更新し、第 1 は過去の出来事に残します。「日曜：独占的な交際に合意」と新たに記録し、現在状態で新しい関係を示せます。金曜の不確実さは履歴で、現在への競合指示ではありません。

関係全体を数値に縮めないでください。信頼 100 中 80 では、秘密、借りた物、家族への紹介のどれを信頼するかが分かりません。意図したゲーム要素には使えても、実際の関係を示す文の代わりには向きません。

同意と好みも具体的にします。「予定変更は約束前に話したい」は新しい誘いの扱い方で、「日曜の訪問に同意した」は 1 つの合意です。どちらも、その後のすべてに無制限に合意した意味ではありません。

物語へ説教を挿入することではありません。要約で消さず、意味のある選択を残すためです。未回答の問いがあるから関係は面白くなります。良い記憶は、ユーザーの代わりに答えず、その問いを引き継ぎます。

古い記憶が新しい出来事を上書きするのを防ぐ

検索は正しい話題でも間違った時点を返すことがあります。スタジオの話で、初期の口論と後の和解が同時に出ると、順序や解決が不明なまま、解決済みの対立が再開するかもしれません。

履歴には出来事名と明確な変化を付けます。「最初の訪問：許可なく照明スタンドを動かし、Mara は不快に感じた」は、「Mara はスタジオで Julian に不快を感じる」より適切です。後者は恒久的な現在の状態に読めます。

解決を別の出来事にします。

2 回目のスタジオ訪問：Julian は機材を動かしたことを謝り、他の物に触れる前に確認した。Mara は謝罪を受け入れた。前の対立は解決済みだが、仕事の道具を動かす前に聞いてほしいという好みは残る。

口論の解決で好みは消えません。関係は改善し、スタジオの規則は残ります。否定的な記憶を全部消したり、古い問題をすべて無視するよう頼んだりするより有用です。

古い項目が何度も有効になるなら、現在形を履歴へ書き換えます。古い状態以外の価値がなければ無効にし、有効な現在状態を 1 か所へ保ちます。新しいメモへ「前の記憶を無視」を何重にも入れる必要はありません。

予定に状態を付ける習慣も有用です。「予定」「完了」「中止」「変更」で読みやすさが大きく変わります。「日曜にスタジオで会う」は今の動作と混同され得ますが、「未実施の予定：日曜午後に面会」は誤解しにくくなります。

日曜になったら訪問か中止を記録し、未実施の予定を更新します。2 週間飛んだなら、期限を過ぎた誘いを現在状態から除きます。そうしないと、人物が先へ進んだ後も、古い面会が緊急の次の行動として戻ってきます。

秘密は、実際に知っている人物だけのものにする

重大な連続性の誤りは、語り手を通じた秘密の漏れです。Mara が Julian に Leena との対立を説明したと正しく記録しても、後の集合場面で、誰も教えていない Leena が会話の細部を知ることがあります。

出来事の記憶と人物の知識は別です。保管記録は出来事全体を知れても、各人物は見聞きした部分にだけ反応すべきです。秘密を含む記憶に、その違いを書きます。

例えば次です。

金曜の夜の私的な会話：Mara は、Leena の手紙に返事をしていないと Julian に話した。Julian は直接聞いた。Leena は手紙を送ったことは知るが、Mara が Julian に話したことは知らない。他の人はいなかった。

次の場面は Leena の立場で書きます。不安そうな Mara に気付き、手紙が届いたかを聞けます。物語で教えられない限り、Julian の約束は知りません。

複数人物のロールプレイでは名前を明記します。女性 3 人と男性 2 人がいる章で「彼女が彼に彼女の話をした」は不安定です。「Mara が Julian に Leena の話をした」は文学的ではなくても、はるかに有用です。

出力で完璧に分離する保証ではありません。確認できる明確な境界を渡します。それでも漏れるなら、続ける前に返答を直し、別の要約で公開情報として扱っていないかを調べます。

秘密を全部消して解決しないでください。Leena の知識は直っても、Julian が覚えるべきことも消えます。全員から私的な情報をなくすのではなく、同じ出来事に正しい立会人を残すことが目的です。

別の展開を試す前に、物語の分岐を分ける

別の結末を試せるのもロールプレイの魅力です。日曜の誘いを受ける分岐と、時間を求める分岐を作りたくなるかもしれません。定義と選択前の履歴は共有できますが、その後の出来事について変化する記録は共有しません。

「日曜を受諾」「日曜を延期」と明快に名付けます。各々に小さな現在状態メモを持ち、新しい記憶を作る前に、どの memory book が結び付くか確認します。同じ本へ書くと、受諾した分岐に、誘いを断った記憶が戻ることがあります。

チェックポイントで分岐時の会話は残せますが、すべての拡張や外部記憶が同じように自動分離されるとは考えません。分岐後に有効な本を確認します。コピーやロックの機能に頼る前に、拡張自身の現在のドキュメントを調べます。

混入したら、分岐後に作られた項目を特定します。該当するものを意図した分岐の記憶元へコピーし、無関係なものをそこで無効にします。分岐前でも、本当に変わっていない履歴だけ共有します。恒久的な性格は共有でき、分岐固有の会話の結果は共有できません。

再開では、何を意図するかを区別します。「同じ人物との新しい会話」は元の設定から、「同じ物語を新チャットで続ける」は現在状態と関連記憶を引き継ぎ、「同じ登場人物の別物語」は独立した履歴が必要です。全部を単なる新チャットとして扱うと、その版ではなかったデートを覚えることになります。

別端末へ書き出し・同期するなら、チャットと必要な記憶元を運びます。会話が見えても、添付 lorebook、文書、拡張の状態が移った証拠にはなりません。移動先で有効な情報源を開き、続ける前に明確な事実 1 つを確かめます。

別の展開でも過去は共有できます。その後の出来事は別の記憶が必要です。

モデルを変えるとき、全物語を推測させない

事実が同じでも、モデルを変えると話し方が変わることがあります。入る履歴の量やプリセットの解釈も変わります。新しいモデルに前のモデルの見えない記憶は引き継がれず、フロントエンドが送るものだけを見ます。

切り替え前に小さな引き継ぎを用意します。人物設定、今の関係、関連する直近場面、未実施の予定、短い話し方の例を含めます。次の場面に本当に必要でなければ、全保管記録は除きます。

Mara なら次です。

既存の物語を続ける。Mara は 32 歳の写真家で、皮肉の利いたユーモアと実際の行動で気持ちを示す傾向がある。Julian は 35 歳でユーザーが操作する。2 回目の外出後の交際中で、初対面ではない。今は Mara の自宅で、Julian はコーヒーを受け入れた。日曜のスタジオ訪問はまだ予定。Mara の代わりに Leena へ連絡しないと約束した。Mara の台詞は簡潔で、小さな冗談でかわしてから正直に答える。Julian の返答は決めない。

話し方の例は、短いオリジナルの 1 文で構いません。「欠けたマグは、好きな人用。上等な磁器は、良く見せたい人用」。大量の文体命令にせず、リズムと人物像を伝えます。

切り替えを比べるなら同じ引き継ぎを使い、コーヒー場面の続き 1 つを求めます。場所、未実施の予定、知っている範囲、話し方を比較します。2 時間丁寧に会話を整えた旧モデルと、挨拶 1 行だけの新モデルは比較しません。

別のテキストモデル選びには、ロールプレイのモデルガイドがあります。プロンプト内の事実が間違っているなら、先に記憶を修正します。高性能でも悪い要約に従い、整理した場面なら安価なモデルで十分な場合があります。

内容規則は別に確認します。拒否はデートを忘れた証拠ではありません。暖かいが大人向けの表現が弱い続きも、自動的に記憶失敗ではありません。記憶ツール、プロンプト、モデルのどれを変えるかは、渡した状態と実際の返答を見て決めます。

モデル変更には同じ物語の事実と短い話し方の例を渡します。初対面からやり直しません。

重要な細部を失わず、記憶の費用を減らす

トークン課金の API では、毎要求に含むテキストが入力使用量に加わるため、長いコンテキストには費用があります。記憶作成にも別のモデル呼び出しが必要な場合があります。拡張の導入が無料でも、運用まで無料とは考えないでください。

特定のモデル価格なしでも、構成の大きさを考えられます。説明用の要求が入力 40,000 トークン、絞ったものが 12,000 なら、50 返答では、キャッシュなどを考える前に 2,000,000 対 600,000 トークンです。算術の例で、測定した請求や節約の保証ではありません。

重要なのは、どの 28,000 トークンを除いたかです。重複する部屋描写や古い場面なら、必要なものを保った短い要求かもしれません。Julian の約束の唯一の記録なら、安くても悪い結果になります。意味のある変化を保つ圧縮に価値があります。

毎メッセージの要約も、費用を増やし、不要な途中記憶を作ります。コーヒーを勧めるだけなら不要でも、Leena の告白には必要でしょう。場面終了や対応する間隔から始め、まとまりのある項目になったかを読みます。

検索する内容がターンごとに変わると、キャッシュが複雑になります。公式 Chat Vectorization ドキュメントもこの兼ね合いを指摘しています。繰り返しのプロンプト内容で有利になる API なら、検索有効後の実使用量を比較し、見えるメッセージが少ないほど安いとは考えません。

個人の執筆では、肥大化したカードを削り、現在状態を短くし、重複する自動要約を避けるのが通常最も単純です。アプリでは記憶生成が毎ターン、バックグラウンド、決まった境界のどれかも把握します。要求の形と費用が異なります。

検索ミスを避けるために、すべての事実を常時有効にしないでください。毎回全記録を送る状態へ戻ります。常に使う余地は人物設定、現在状態、少数の必須制約に充て、他は関係するときに出します。

記憶ツールが動くように見えても物語が壊れる場合

成功通知は記憶の作成を示すだけかもしれません。内容の正しさ、有効化、モデルでの適切な使用は別です。失敗した事実を、段階順にたどります。

まず保存項目を開きます。「Julian は鍵を持つ」なら、検索を調整する前に内容を直します。設定で誤った項目を真実にはできません。返却がないなら、追加するか、適切な場面範囲から作り直します。

次に情報源と有効化を確認します。この本は現在のチャットへ結び付くか、会話に出ないキーワードが必要か、フィルターが人物を除くか、設定予算内に余地があるか。全体の上限を全部上げず、その項目に実際に適用される設定を調べます。

次に最終要求を見ます。保存され、有効化条件を満たしても、他の情報源に押し出されることがあります。「真鍮の鍵を返した」という特徴的な事実と、「Julian はスタジオの鍵を持つ」という古い矛盾を探します。両方あれば、正しそうな記憶が問題を起こす理由が分かります。

最後に生成した続きを読みます。正しい事実があり矛盾がなければ、直近場面の現在状態をより直接的にします。それでも失敗するなら、別の生成やモデルが適切かもしれません。闇雲にツールを変えず、欠落・破損した記憶を先に除外できています。

調査の問いは小さくします。「なぜモデルは記憶が苦手か」は難しく、「返したと書くのに、なぜ Julian に鍵を持たせたか」なら、情報源、トリガー、要求、修正へ進めます。次の場面までに終えられる修正になります。

長い成人向け物語で繰り返せる習慣

開始前は全履歴でなく現在状態を読みます。場所、今の関係、未実施の予定、誰が次を決める番かを確かめます。30 秒の確認で、古い場面が新しい 10 メッセージへ影響する前に気付けます。

執筆中は通常の会話をそのままにします。約束、発見、解決、新しい境界、物の譲渡、予定の完了など、変化があるとき記憶を保存します。自動ツールでは些細なやり取りを全部校正せず、その変化の周辺の項目を確認します。

場面終了時は、出来事と現在状態を分けます。起きたことを出来事の記憶へ残し、現在状態は今止まった地点で置き換えます。古い「現在」の場面 3 つの下へ、新しい「現在」を追記しません。

分岐前に変化する記憶をコピー・分離し、モデル変更前に短い引き継ぎと話し方の例を用意し、端末移動前に情報源の到着を確認します。それぞれ別の初期化を防ぎ、どれにも長いカードは不要です。

求める結果は控えめでも重要です。約束を覚え、関係がやり直されず、前の停止地点から次の場面が始まること。気になる事実 1 つを修正するところから始めます。正しい記憶元と実際の要求で確認できれば、次の返答を判断する確かな基準になります。