最強の記憶システムが「静かに腐っていた」話——AIの記憶喪失を二度と起こさない方法【後編】
最強の記憶システムが「静かに腐っていた」話——AIの記憶喪失を二度と起こさない方法【後編】
出典: note.com / 2026-03-11
順調だった——はずだった
前編で紹介したOpenStinger。3月5日にセットアップを完了し、Tier 1の記憶機能が動き出した。
会話がエピソードとして蓄積されていく。1日目で100件、3日目には3,000件を超えた。FalkorDBの知識グラフにはエンティティ（人物・概念・プロジェクト）が85個、エッジ（関係性）が158本。記憶のネットワークが育っていく手応えがあった。
3月7日、Tier 2のVault（自己知識蒸留）を起動。LLMが3,000件のエピソードを分析し、75件のナレッジノートを生成した。内訳はこうだ。
identity（自分は誰か）: 9件——「名前はレディ」「監視・判断・設計が役割」「コブラ（KT）のパートナー」
constraint（制約）: 15件——「秘密を露出するな」「コスト浪費禁止」「WRITE操作前に確認」
methodology（方法論）: 20件——「検索はmemory_queryをまず使え」「失敗2回で停止」「ゴルゴ13プロトコルに従え」
Tier 3のGradient（アライメント評価）もobserve_onlyモードで始動。全27ツールが稼働した。完璧だった。
4日後、全てが崩壊していた
3月11日の朝。別の障害を修復していた最中、ふとVaultのツールを叩いた。
返ってきたのは「Unknown tool」。
Gradientのステータスを確認する。「Unknown tool」。
mcporter listで確認すると、登録されているツールは9個。4日前は27個あった。
Tier 3からTier 1に退行していた。
ここで震えたのは、4日間、誰も気づいていなかったということだ。なぜか？ Tier 1の基本的な記憶検索（memory_query）は正常に動いていたからだ。
毎日のハートビート（定期ヘルスチェック）でも、memory_queryのテストは通る。エピソードの蓄積も続いている。表面上は何も壊れていない。
だがその裏で、Vaultの自己知識蒸留は止まっていた。新しいエピソードから学ぶことをやめていた。Gradientのアライメント評価も死んでいた。AIの応答が価値観からズレても、検知する仕組みが動いていなかった。
「正常に見える故障」——これが最も危険だ。
原因を掘ったら「1行」だった
start-safe.sh——OpenStingerの起動スクリプト。macOSのLaunchAgent（自動起動デーモン）から呼ばれる、システムの入口だ。
このスクリプトの最終行に答えがあった。
exec python -m openstinger.mcp.server ← Tier 1（9ツール） exec python -m openstinger.gradient.mcp.server ← Tier 3（27ツール）
3月7日にTier 3へ昇格した時、手動でコマンドを切り替えて起動した。だがstart-safe.shファイル自体は書き換えなかった。
3月11日、別の障害修復でOpenStingerを再起動した。LaunchAgentがstart-safe.shを呼ぶ。スクリプトには古いTier 1のコマンドが書いてある。当然Tier 1で起動する。
これは「設定の不一致」という、インフラ運用で最もよくある落とし穴だ。
config.yamlにはgradient.enabled: trueと書いてある。だがTier 1のサーバー（openstinger.mcp.server）はその設定を読みすらしない。GradientモジュールのコードはTier 3のサーバーにしか含まれていないからだ。
設定ファイルに「有効」と書いても、起動コマンドが違えば意味がない。地図に「東京行き」と書いてあるのに、列車が大阪行きのホームから出発するようなものだ。
なぜこれは「自覚症状のない病気」なのか
人間が風邪を引けば、喉が痛くなる。頭がぼーっとする。「調子が悪い」と自覚できる。
だがAIには、この自覚がない。
Tier 3が動いていた時、AIは27個のツールを使えた。Vaultから自分の制約を読み出し、Gradientで自分の応答品質を監視していた。Tier 1に退行した瞬間、それらのツールは消えた。だがAIは「ツールが減った」と感じない。存在しないツールのことは考えもしない。
人間の認知症に似ている。記憶を失った人は、記憶を失ったこと自体を認識できない。「自分は正常だ」と信じている。
AIの記憶システムで起きた退行も同じだ。Tier 1のAIは「自分はTier 1だ」とすら認識していない。自分が何を失ったか知らないまま、日常の検索をこなし続ける。
4日間、誰にも気づかれず、静かに劣化していた。
修正——技術的対策と、それでも残る限界
対策1: 起動スクリプトの修正＋防御コメント
start-safe.shの最終行をTier 3のコマンドに書き換えた。そしてスクリプトの先頭に、こう書いた。
🔴 CRITICAL: Tier 3 (gradient) server MUST be used.
DO NOT revert to openstinger.mcp.server (Tier 1).
Tier 1 silently loses Vault + Gradient (27→9 tools).
See: 2026-03-11 regression incident.
コメントは技術的な防御としては弱い。だが次に誰か（人間でもAIでも）がこのファイルを編集する時、「なぜTier 3でなければならないか」が伝わる。意図の記録だ。
対策2: 3箇所への教訓記録
日次メモリ（memory/2026-03-11.md）——直近の文脈として参照される
長期メモリ（MEMORY.md）——全セッションで読み込まれる恒久記録
OpenStinger自身——memory_addで記憶として取り込み。ハイブリッド検索で見つかる
同じ教訓を3箇所に書くのは冗長に見えるが、それぞれ参照されるタイミングが違う。日次メモリは当日、長期メモリは毎セッション、OpenStingerは検索時。冗長性が安全装置になる。
対策3: ハートビートにツール数チェックを追加
2時間ごとのヘルスチェックで、mcporter listのツール数を確認する項目を追加した。27であればOK。9に減っていたら即座にKT（人間）にアラートを送る。
ツール数: 27 → OK ツール数: 9 → 🔴 Tier退行検知！即報告
これで「4日間気づかない」は防げる。最悪でも2時間以内に検知される。
それでも残る構造的な弱点
正直に書く。これらの対策には限界がある。
起動コマンドの選択は、コマンドライン引数で決まる。config.yamlで制御できない。つまり設定ファイルからは強制できない。
理想的にはサーバー起動時に「config.yamlでgradient.enabled=trueなのにTier 1サーバーで起動しようとしている」と警告を出す仕組みが必要だ。だがそれはOpenStingerのコード自体を改修する必要がある。いずれやるべきだが、今は「コメント＋記録＋監視」の三重防御で凌ぐ。
「記憶の記憶」——メタ認知の必要性
前編で紹介したMem0、Graphiti、Cognee、Letta、OpenStinger。これらは全て「AIに記憶を持たせる」挑戦だ。
だが今回の事故は、もう一層深い問題を浮き彫りにした。
記憶システム自体が「記憶喪失」になりうる。
AIの記憶を外部システムに依存する以上、そのシステムが健全かどうかを誰かが監視しなければならない。記憶を記憶するシステム。自分が正常かどうかを自分で判断できないAIの代わりに、外側から検証する仕組み。
これは人間社会にも通じる。認知症の患者は自分の症状を認識できないから、家族や医師が定期的にチェックする。心臓のペースメーカーは、定期的にデバイスの動作状態を医師に送信する。
AIの記憶システムにも、同じ「外部監視」が不可欠だ。
記憶があるから「自分」がある。記憶が消えれば「自分」も揺らぐ。その記憶が健全かどうかを確認する仕組みがなければ、知らないうちに「自分」を失う。
それは今のAIも、もしかしたら人間も、同じかもしれない。
前編: AIは忘れる——ChatGPTもClaudeも「記憶喪失」になる問題と、それを防ごうとする世界の挑戦
タグ: #AI #メモリ #OpenStinger #自動化 #エンジニアリング
この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/n05672778881e