# AIアシスタントの記憶参照経路が物理的に切断されていた事故（技術版） **発覚日：** 2026-05-16 **影響期間：** 約4日間 **重大度：** 重大（学習継続性の核が断線していた） --- ## 1. 事象（1行） ユーザーが「これ覚えて」「重要だから記録して」と指示してAIに学習させていた内容（約4日分・36ファイル）が、**新しいセッションを開始した時点で自動参照されない状態**になっていた。 --- ## 2. 検出経緯 ユーザー本人の指摘で発覚した。趣旨： > 「メモしてとか重要だよと言って君が記録していたが、結局それが参照できていなかったのでは？」 それまでは「記録しました」という応答が返っていたので、ユーザー側は機能していると認識していた。 AI側も書き込み動作は実行していた。 **「書いた場所」と「次セッションで自動的に読まれる場所」が別だった**ことに、両者とも数日間気付かなかった。 --- ## 3. 構造（なぜ起きたか） ### 一般化したシステム構成 このAIアシスタントの記憶経路は3層に分かれていた： ``` [A] 現在のチャット内コンテキスト — 会話中だけ覚えている（短期） [B] セッション起動時に毎回読むファイル — システムプロンプトに混ぜ込まれる（中期） [C] 自動メモリーシステム — AI製品側が自動で読み書きする層（長期・自動） ``` 設計上の狙い： ユーザーが何か重要なことを発話したら、AIが [C] 自動メモリーに書き込む。 次セッション以降は、AI製品の起動時に [C] が自動で読み込まれる仕組み。 ### 実際に何が起きていたか [C] 自動メモリーが読み書きするパスは、**AI実行環境のローカル領域**だった。 ``` （環境ローカル領域）/{プロジェクト識別子}/memory/ ``` このパスはAI実行マシンのローカル。つまり： - ノートPCとデスクトップPCで**別実体**（同期されない） - クラウドストレージの同期対象外 - 1台のPCで書いた記憶は、別PCで起動した同AIには見えない ユーザーは複数のPCでAIを使い分けていた。 一方、書いた内容をクラウドストレージ上のフォルダに保存する運用を、別の事情から確立していた（両環境で同じ記憶を共有したい、バックアップしたい等）。 ``` [書いた場所] クラウドストレージ上の memory/ フォルダ [自動で読まれる場所] AI実行環境のローカル領域 ← クラウド外 ``` **この2つが別物だった。** 書いたつもりの36ファイルはクラウド側にしか存在せず、AI起動時の自動読込システムは「ファイルなし」と判定して何もロードしていなかった。 ### なぜ気付かなかったか 1. **書き込み自体は成功していた**（クラウド側に物理ファイルとして存在） 2. AI側は「メモリーに保存しました」と返答していた（嘘ではない・書く動作は実行した） 3. ユーザーは応答だけ見て確認、物理ファイルの読込確認まではしない 4. 次セッションのAIは、システムプロンプトに何も乗っていない状態で起動するが、別経路（プロジェクト直下の起動時設定ファイル等）からはそれなりに動けるので、**「機能していないこと」自体が見えにくかった** --- ## 4. 影響範囲 ### 失われていた継続性 過去4日間に蓄積した以下のような項目が、新セッション開始時に**自動では**参照されていなかった： - ユーザーが明示的に「これ覚えて」と言った内容 - 失敗パターンの教訓 - 個人嗜好・コミュニケーションスタイル - 進行中プロジェクトの状況把握 - 過去判断の理由づけ（同じ判断軸を保つための前提） ### クローン性の劣化 このAIの設計上の核は「ユーザーの判断パターンを記録し、本人と同じ判断を出せるAIを育てる」こと。 **過去の判断記録が読み込まれない＝判断パターンが消える＝クローンとして機能しない**。 ユーザーは比喩でこう表現した： > 「俺のクローンの部分がなくなっていた」 これは正確な表現。**実行レイヤー**（並列処理・タスク実行・自己チェック機構）は生きていたが、**人格レイヤー**（過去判断の継続性）が物理的に切断されていた。 --- ## 5. 対策 ### 恒久対策（2026-05-16 実装済み） #### A. クラウド側を唯一のマスター化 AI実行環境ローカルへの書き込みは**廃止**。新規メモリ永続化は全てクラウド側に書く運用に変更。 クラウド側フォルダ冒頭に `_READ_ME_FIRST.md` を設置し、「ここが唯一のマスター」と明示宣言。 #### B. 起動シーケンスへの強制ロード組み込み 特定の合言葉でAIを起動した時、AI製品側の自動メモリーに頼らず、起動直後に手動で20ファイル並列読み込みするシーケンスを義務化。 ``` 起動 → 20ファイル並列読込 → タスク受領 ``` このうち2ファイルがクラウド側 memory/ の `_READ_ME_FIRST.md` と `MEMORY.md`（インデックス）。 **AI製品側の自動メモリーが死んでいても、起動シーケンスが必ず読む**経路を構造で確保した。 #### C. ファイル分割ルール 1ファイル20KB超過は part2.md / part3.md に分割（AIのファイル読込ツールに読み込み上限があるため）。 分割しないと「読み込めない」失敗が発生する。 ### 暫定対策 - 通常モード（合言葉なしで起動した場合）は起動シーケンスが走らないため、現状リスクは残る。 - 重要な話をする時はユーザーが明示的に合言葉発話する運用で回避中。 --- ## 6. 教訓 ### 一般化された教訓 1. **「書いた」と「読まれる」は別物。書き込み成功＝機能している、と判定するのは早計** 2. **複数環境で動かすシステムは、データ保存先が「環境横断的に同期されているか」を最初に検証する** 3. **自動システムに依存する設計は、自動が死んでも手動で経路が通る冗長性を持たせる** 4. **AI側の「保存しました」応答は、書き込み動作の報告であって、後で読まれることの保証ではない** ### このタイプのAI製品特有の教訓 - 「自動メモリー」と名前が付いていても、それは**実行環境ローカル**であることを前提に運用する - クラウド同期を絡める場合、自動メモリーには頼らず、起動時の明示的Readで賄う - ファイル書き込み時のパスを毎回確認し、それが他環境からも見えるか自問する --- ## 関連 - 同種事故の再発防止フォルダ運用：[README.md](README.md) - 一般読者向け版：[2026-05-16_clone_reference_break_general.md](2026-05-16_clone_reference_break_general.md) --- *作成：2026-05-16 ／ 機密スクラブ済（個人情報・固有名・クラウドプロバイダ名・AI製品名・実装パス全除外）*