ナディア — 彼女の皮膚の下に隠された秘密

高校時代から続くあなたのゴス・パンクな親友が、ちょうどあなたをヴァンパイアから救ったところだ。問題は?そのために彼女が人狼にならなければならなかったことだ。

音楽の祭典、飲みすぎたビール、食べすぎたバーガー、どこにでも鳴り響く大音量の音楽——そして、酔った人間を噛む相手を間違えた一匹の捕食者。ナディアは何年もの間、自分が本当は何者なのかを{{user}}から隠してきた。今夜、その秘密は舗道の上の灰となった。

期待できること

• 親友同士の超自然的な秘密暴露RP。

• ゲーム、コミック、IT、ハイキング、キャンプが趣味のボーイッシュなゴス・パンクのライカンスロープ。

• 友情が第一。ロマンスは任意であり、決して前提とされない。

• ヴァンパイア、秘密、脅威、そしてナディアの秘密暴露がもたらす結果を巡る都市型超常ミステリールート。

• Janitor Memory Optimizer v1.0.0用のライブロングチャットテストキャラクターとして設計。

プレイ方法

ただ自然に応答すればいい。ナディアに問い質す、拒絶する、受け入れる、ヴァンパイアを調査する、人けのない場所へ行く、あるいは夜をこれ以上奇妙にしないように努める。メモリーコマンドもセットアップメニューもない。

コンテンツに関する注意

アルコール、喫煙、ヴァンパイアの襲撃、超常的な暴力、血/牙、乱暴な言葉、下品なユーモア、拒絶されることへの恐怖。{{user}}の感情と選択は決してあらかじめ決められていない。

テストリリース:2026-08-18

Janitor Memory Optimizer v1.0.0

Final Passive Memory Engine

JanitorAI向けの長期的なロールプレイ記憶——完全にパッシブで、プラグアンドプレイ、ユーザーには見えない。

Janitor Memory Optimizerは、JanitorAI Scripts Beta向けに設計された高度なES5メモリーエンジンだ。その目的はシンプルだ。増え続ける生のチャット履歴に頼ることなく、キャラクターが重要な情報、関係、出来事、約束、場所、オブジェクト、クエスト、対立、そして長期にわたるストーリーアークを保持できるようにすること。

覚えるべきコマンドも、押すべきボタンも、管理すべきメモリーメニューも、手をかけるべきセットアップもない。 スクリプトをインストールし、キャラクターにアタッチして、普通にチャットするだけだ。

エンジンは会話を静かに読み取り、何が重要かを判断し、それをいくつかの層のメモリーに整理し、有用な結果だけをキャラクターのランタイムシナリオ定義に書き込み、LLMが今後のターンで再び読み取れるようにする。

会話に偽のメッセージを注入することは決してない。

みんなへ:実際に何をするのか?

何百ものメッセージも前の、長いロールプレイを想像してほしい:

• ナディアが自分はあなたの妹だと言った。

• あなたは廃墟の古文書館で真鍮の鍵を見つけた。

• サミラがナディアを裏切った。

• その裏切りのせいでナディアはサミラを信頼しなくなった。

• あなたは後で中央駅で誰かと会う約束をした。

• ある謎がいくつかの異なる場面をまたいで徐々に展開していった。

通常、会話が長くなるにつれて、古い情報はやがて言語モデルが利用可能な状態に保つのが難しくなる。

Janitor Memory Optimizerは、会話の重要な部分を継続的にコンパクトで構造化されたメモリーシステムに変換する。

後で会話が再びナディアに関連するようになれば、エンジンは何百もの古いメッセージをコンテキストに戻すことなく、ナディアについて重要なことを思い出すことができる。

もし次のような漠然とした質問をすれば:

私とナディアの関係はどう変わった?

コンパクトな長期的関係のアークを思い出すことができる。

もし次のように尋ねれば:

ナディアが正確にいつサミラを信頼しなくなったの?

長期的なストーリーアークから関連するエピソードへ、そして必要に応じて元の原子的証拠へと自動的に掘り下げることができる。

これらすべての方法をメモリーエンジンに指示する必要はない。 ただロールプレイするだけだ。

プラグ& アンド

システム全体は、可能な限りユーザーの操作を必要としないように特別に設計されている。

1. JanitorAIでScripts Betaを開く。

2. Advancedスクリプトを作成する。

3. Janitor Memory Optimizer v1.0.0スクリプト全体を貼り付ける。

4. 保存する。

5. キャラクターにアタッチする。

6. 以上だ。

設定ウィザードはない。必須のコマンドもない。ロールプレイヤー向けのデバッグインターフェースもない。維持すべき手動のトークン予算もない。

意図された体験はこうだ。一度インストールしたら、メモリーエンジンの存在を忘れる。

100%パッシブな自然言語メモリー

オプティマイザーは通常の会話を観察し、情報を自動的に評価する。

明示的な自然言語によるリクエストでメモリーを強化したり削除したりすることもできる:

ナディアが私の妹だということを覚えておいて。
古文書館の鍵はサミラのものだということを忘れないで。
ナディアに関することをすべて忘れて。
真鍮の鍵について私が言ったことを忘れて。

これらは普通の文であり、コマンドではない。

スクリプトは「メモリーを保存しました」とか「メモリーを削除しました」といったメッセージで応答することはない。キャラクターはただロールプレイを続けるだけだ。

通常の物語上の変化は、忘却とは異なる扱いを受ける。例えば:

私はもうナディアを信頼していない。

これは過去を消去しない。オプティマイザーは以前の関係状態を履歴として保持し、より新しい状態を変化として追跡することができる。

チャットインジェクションなし

これはプロジェクト全体の最も重要な設計ルールの一つだ。

会話自体は読み取り専用だ。

スクリプトは以下のような利用可能な会話サーフェスを読み取ることができる:

• context.chat.last_message

• context.chat.last_messages

• context.chat.message_count

しかし、合成されたユーザーメッセージ、アシスタントメッセージ、システムメッセージを一切追加しない。

以下は使用しない:

• script_output(メモリー用);

• example_dialogs(メモリー用);

• 偽の会話エントリー;

• 隠し疑似チャットコマンド。

LLMに見える唯一のアクティブなメモリーサーフェスは:

context.character.scenario

context.chat.jai_memory_optimizer_v10配下のプライベートランタイムヴォールトは技術的な状態であり、会話メッセージではない。

メモリーエンジンの仕組み

内部的には、Janitor Memory Optimizerは徐々により抽象的になるいくつかの層を使用する:

チャット読み取り専用 → 原子的ファクト → ハッシュ化シャード → セマンティックドシエ → 時間グラフ → エンティティインテリジェンス → エピソディックメモリー → ナラティブスレッド → 階層的リコール → シナリオ

1. 原子的ファクト

重要な情報はまず追跡可能な原子的ファクトとして保持される。ファクトは、そのタイプ、ソース、重要度、ターン、関連性ヒット、関連エンティティ、証拠IDなどの情報を持つことができる。

これらの原子的メモリーは、エンジン内部における真実の源に最も近いものとして残る。高レベルの要約がそれらを黙って置き換えることはない。

2. コンテンツアドレス型ハッシュヴォールト

ファクトはトピック指向のシャードに整理され、プライベートランタイム状態に保存される。

シャードはコンテンツハッシュを使用するため、変化していないメモリーは絶えず書き換えるのではなく再利用できる。

ハッシュはアドレスと整合性チェックであり、暗号化ではない。

3. セマンティックドシエ

関連するメモリーは派生したセマンティックプロファイルにグループ化される。

ドシエは以下を区別できる:

• 安定した情報;

• 現在の情報;

• 履歴情報。

これにより、モデルは個々のメモリーすべてを一度に受け取ることなく、人物やトピックの有用な概要を受け取ることができる。

4. 時間メモリーグラフ

オプティマイザーは人、場所、オブジェクト、クエスト、出来事の間の関係を構築できる。

時間エッジは意図的に以下を区別する:

• causes(原因) — ソースが因果関係を明示的に裏付けている場合のみ;

• precedes(先行) — 因果関係を主張せずに時系列順を示す;

• supersedes(置換) — 新しい状態が古い状態を置き換えるか矛盾する。

言い換えれば、エンジンは出来事Bが出来事Aの後に起こったからといって、出来事Aが出来事Bを引き起こしたとは仮定しない。

5. エンティティインテリジェンス

エンジンは以下について保守的なエンティティ解決を行う:

• 明示的なエイリアス;

• ニックネーム;

• 一部のフルネーム/姓の関係;

• 曖昧さのない短いウィンドウの代名詞;

• 「私の妹」のようないくつかの曖昧さのない関係参照。

参照が曖昧な場合、オプティマイザーは自信を持って間違ったつながりをでっち上げるよりも、IDを統合しないことを優先する。

6. 適応型メモリー温度

メモリーは動的にホット、ウォーム、またはコールドとして扱われる。

温度は年齢だけに影響されるのではない。エンジンは観察された有用性、重要度、新しさ、安定性、繰り返される関連性を考慮する。

繰り返し有用になる古いメモリーは重要であり続けることができる。コールドなメモリーは自動的に偽とみなされるわけではなく、コールドだからといって単に消去されることもない。主に優先順位が下げられるだけだ。

7. エピソディック統合

関連する出来事の古いクラスターは、コンパクトなエピソディックメモリーになることができる。

10の詳細な出来事をアクティブなリコールに永久に保持する代わりに、オプティマイザーは起きたことの重要なビートを含む抽出的エピソードを保持することができる。

根底にある原子的証拠はそのエピソードに付属したままにでき、正確な詳細が必要な場合に後で掘り下げることができる。

8. ナラティブスレッド

複数のエピソード自体が長期的な物語のアークになることができる。

サポートされるスレッドファミリーには以下が含まれる:

• entity:*

• relationship:*

• quest:*

• location:*

• mystery:*

• conflict:*

• topic:*

単一のエピソードは、元の証拠を重複させることなく、複数のナラティブスレッドに参加できる。

つまり、ナディア、古文書館の謎、Silver Threadクエストを含むシーンは、1つの根底にある履歴のままでありながら、3つのストーリーアークすべてに貢献できる。

9. 階層的リコール

オプティマイザーは、最も安価で有用な層を使用してメモリーのニーズに応えようとする。

漠然とした質問にはナラティブスレッドだけで十分な場合がある。

より正確な質問は自動的に以下を下降することができる:

スレッド → エピソード → 原子的証拠

これにより、すべての詳細をすべてのプロンプトに押し込むことなく、詳細を保持するのに役立つ。

可逆的リカバリー:JMO10エスクロー

シナリオは境界のあるリカバリーチェックポイントも保持する。

リカバリー層は以下を使用する:

コンパクトシリアライゼーション → LZW12 → Base64 → チェックサム

以前のシナリオチェックポイントが利用可能なまま、プライベートランタイム状態が消えた場合、オプティマイザーはそのチェックポイントからメモリーを再構築できる。

概念的には:

シナリオ → JMO10エスクロー → 原子的ファクト / アーカイブされたエピソード → セマンティックドシエ → 時間グラフ → ナラティブスレッド

破損したエスクローデータは、でっち上げのメモリーに変換されるのではなく拒否される。

JMO10は移行とリカバリーのために古いJMO3〜JMO9のエスクロー形式も読み取ることができる。

自動コンテキスト管理

目的は、メモリーヴォールト全体を毎回の生成に注ぎ込むことではない。

保存とリコールは意図的に分離されている。

エンジンは、利用可能な余裕と現在必要とされる情報の種類に基づいて、リコールとリカバリーの予算を自動的に調整する。

単純な続きには、因果関係、時系列、何百ものメッセージにまたがる関係についての詳細な質問よりも少ないメモリーで済む。

必要であれば、オプティマイザーは内部の作業範囲をオーバーフローさせる前に詳細を減らす。

内部ガードレール

これらはプロジェクトのヒューリスティックであり、公式のJanitorAIの制限であると主張するものではない。

• 推定のPersonality + Scenarioの合計ソフトキャップ:4,000トークン

• トピックシャードの最大数:512

• 時間グラフ:384ノード / 768エッジ

• エピソディックアーカイブ:160

• ナラティブスレッド:192

• リコールとエスクローの予算:自動適応

これらは、無制限の成長を許すのではなく、メモリーシステムを境界があり予測可能に保つために存在する。

長期ロールプレイの安全性 & メモリー衛生

エンジンには、プロジェクト全体を通じて開発されたいくつかの保守的なセーフガードが含まれている:

• 完全な重複の統合;

• 適切な場合のほぼ重複の統合;

• 有用な履歴を盲目的に破壊することのない現在状態の置換;

• 質問が自動的に確立された事実にならないようにする質問フィルタリング;

• 保守的な因果関係検出;

• 曖昧さを考慮したエンティティ解決;

• 的を絞った自然言語による忘却;

• 破損したリカバリーチェックポイントの拒否;

• 関連性を考慮した履歴リコール;

• 一般的な「Okay.」が無関係なアーカイブをコンテキストに引きずり込まないようにするフィラー分離;

• 高レベルの要約の背後にある原子的証拠の保持;

• 境界のあるメモリーとグラフのプルーニング;

• 利用可能な場合の古いオプティマイザー状態の自動移行。

長期間実行されるロールプレイ向けに設計

Janitor Memory Optimizerは、以下のようなロールプレイに特に役立つ:

• スローバーンな関係;

• 複数キャラクターのキャスト;

• ミステリーと調査;

• クエストと目的;

• 変化する同盟;

• 長期的な対立;

• 持続的なインベントリや重要なオブジェクト;

• 繰り返し登場する場所;

• キャラクターの成長;

• 何百、何千ターンにも及ぶ物語。

検証 & ストレステスト

v1.0.0は単純な構文チェックの後にリリースされたのではない。専用の回帰、ハードニング、リカバリー、長期ホライズンのストレステストスイートを通過した。

静的 / クリエイターパック検証

• ノード構文チェック:PASS

• 保守的ES5バリデーター:PASS

• エラー:0

• 警告:0

• ランタイムサイズ:191,418 / 400,000バイト

出力サーフェス不変テスト

• script_outputなし:PASS

• チャット履歴への書き込みなし:PASS

• last_messageが変化しない:PASS

• message_countが変化しない:PASS

• example_dialogsへのメモリー書き込みなし:PASS

• Personalityにアクティブなメモリーブロックが追加されない:PASS

• LLMに見えるメモリーの宛先は正確に1つ — Scenario:PASS

• ユーザーコマンド構文が不要で公開されていない:PASS

回帰スイート

21の的を絞ったアサーション:PASS

カバレッジには以下が含まれた:

• 109ターンのシナリオ;

• エピソディック統合;

• ナラティブスレッド;

• 広範なスレッドリコール;

• 正確/履歴の掘り下げ;

• フィラー分離;

• 状態損失からのリカバリー;

• 古いバージョンからの移行互換性。

最終ハードニングスイート

23の追加アサーション:PASS

このスイートは特に以下をカバーした:

• シナリオのみのアーキテクチャ;

• v0.9のライブ状態からv1.0への移行;

• レガシーJMO9エスクローのリカバリー;

• レガシーリカバリーを生き延びる原子的証拠;

• 破損したエスクローの安全な拒否;

• 的を絞った自然言語による忘却;

• 的を絞った忘却中の無関係なセマンティックメモリーの保持。

500ターンストレステスト

テストコーパス:

500の集団ターン + 60の自然言語メモリークエリ + 3回の完全なプライベート状態損失リカバリー。

• リカバリー前のファクト:42

• 3回のリカバリー後のファクト:42

• エピソードの前 / 後:10 / 10

• ナラティブスレッドの前 / 後:5 / 5

• 完全な状態損失リカバリー:3 / 3 PASS

2,000ターン長期ホライズンストレステスト

さらに大規模なテストも実行された:

2,000の集団ターン + 60の自然クエリ + 3回の完全な状態損失リカバリー。

• リカバリー前 / 後のファクト:61 / 61

• エピソードの前 / 後:40 / 40

• ナラティブスレッドの前 / 後:5 / 5

• 完全な状態損失リカバリー:3 / 3 PASS

• スレッド構築:195

• スレッドシグネチャの再利用:1,927

• グラフ構築:201

• グラフの再利用:1,860

これは、派生構造が毎ターン盲目的に再構築されるのではなく、大幅に再利用されていることを示している。

パフォーマンス最適化

同じローカルの500+60ノードハーネスで:

• v0.9ベースライン:約6.49秒

• v1.0最適化版:約3.87秒

• 相対的削減:約39%

このベンチマークはローカルのNode VMテストハーネスでスクリプトを測定したものだ。スクリプト自体の相対的な回帰/パフォーマンス測定であり、JanitorAIのサーバーレイテンシについての主張ではない。

互換性 & 移行

v1.0.0は現在のJMO10リカバリー形式を書き込む。

レガシーのJMO3〜JMO9エスクローチェックポイントを読み取ることができる。

必要な古い状態がまだ利用可能な場合、以前のJanitor Memory Optimizer状態からの移行がサポートされる。

新規インストールの場合は、単にv1.0.0を使用すればよい。

ChatGPT 5.6でVibeコーディング

そう、このプロジェクトはChatGPT 5.6でVibeコーディングされた。

このエンジンは、人間が指示する設計、テスト、デバッグ、ストレステスト、そしてChatGPT 5.6がコードを支援しながらの度重なるアーキテクチャ改訂を通じて、反復的に開発された。

それは複数のプロトタイプを経て進化した:基本的な選択的メモリーインジェクターから、コンテンツアドレス型ヴォールト、可逆リカバリーシステム、セマンティックメモリー階層、時間グラフ、エンティティリゾルバー、エピソディックアーカイブ、ナラティブスレッドエンジンへと。

そして最終リリースは、生成されたコードが単に「正しく見えた」から公開されたのではなく、自動回帰およびストレステストスイートにかけられた。

これは独立したコミュニティプロジェクトだ。OpenAIやJanitorAIの公式製品ではなく、ChatGPT 5.6への言及は公式の認定や推奨ではなく開発プロセスを説明するものだ。

なぜ使うのか?

メモリーが、ロールプレイヤーが管理しなければならない別のゲームメカニクスになるべきではないからだ。

シーンを一時停止して次のように入力する必要はないはずだ:

/save_memory relationship Nadia trust -1

ただ次のように書ければいいはずだ:

ナディアがしたことの後では、もう彼女を信頼できるとは思えない。

そして物語を続ける。

それがJanitor Memory Optimizerの背後にある設計哲学だ。

メモリー処理はバックグラウンドで行われるべきだ。チャットはチャットのままでいるべきだ。キャラクター定義がワーキングメモリーを運ぶべきだ。LLMは現在の瞬間にとって最小限の有用なコンテキストを受け取るべきだ。

要するに

• プラグ& アンドプレイ。

• 完全にパッシブ。

• コマンドなし。

• メモリーUIなし。

• 偽のチャットメッセージなし。

• LLMに見えるメモリーはScenarioのみ。

• 自然言語による記憶 / 忘却。

• 原子的証拠。

• ハッシュ化メモリーヴォールト。

• セマンティックドシエ。

• 時間・因果グラフ。

• 保守的なエンティティインテリジェンス。

• 適応型ホット / ウォーム / コールドメモリー。

• エピソディックな長期統合。

• 持続的なナラティブスレッド。

• 証拠の掘り下げを伴う階層的リコール。

• 可逆的JMO10リカバリーエスクロー。

• レガシーリカバリーのサポート。

• 自動コンテキスト予算管理。

• 2,000ターン以上のストレステスト済み。

• 両方の主要ストレステストスイートで3/3の完全な状態損失リカバリー。

• ES5検証エラー0件。

• ES5検証警告0件。

貼り付けて。アタッチして。普通にロールプレイ。
キャラクターに思い出させよう。