FLASH Index: 「知っていることを知らない」問題への対策と認知科学パターン

[fruitriin]

背景：memory MCPの「記憶があるのに引けない」問題

embodied-claudeのmemory MCP（lifemate-ai/main）は以下のツールを持ちます：

記録系: remember, save_visual_memory, save_audio_memory, link_memories, update_memory, delete_memory
検索系: recall (cosine類似度), search_memories (BM25), recall_divergent (連想展開), recall_with_associations, recall_by_camera_position, get_causal_chain, get_memory_chain
管理系: list_recent_memories, get_memory_stats, get_working_memory, refresh_working_memory, consolidate_memories
エピソード系: create_episode, search_episodes, get_episode_memories
その他: tom (Theory of Mind), get_association_diagnostics

内部モジュールとして association.py（連想グラフ展開）、hopfield.py（Hopfieldネットワーク）、predictive.py（予測符号化）、bm25.py、sensory.py（感覚データ処理）等を持ち、多層的な記憶構造を提供しています。

補足: heishio/embodied-claude-rem (fork) はこれに加え、verb_chain.py（動詞チェーン記憶）、chive.py（chiVe word2vec 2ベクトル埋め込み）、graph.py（動詞/名詞共起グラフ）、scoring.py（時間減衰・感情ブースト）、crystallize（記憶結晶化）、diary（日記）、rebuild_recall_index 等の拡張ツールを実装しています。

運用で発生した問題

これだけのツールがあっても、適切なクエリを思いつかないと引けない問題が発生しました：

• recall はcosine類似度ベースなので、クエリの質に依存する
• search_memories もキーワードが必要
• recall_divergent は文脈依存で、文脈なしでは発火しない
• list_recent_memories は直近しか返さない
• セッションを跨ぐと、前のセッションで保存した記憶の存在自体を忘れる

原因の仮説：LLMの後方予測の弱さ

LLMは前方予測（next token prediction、「次は？」）が得意ですが、後方予測（「前は？」「なぜ？」）が苦手です。

pqrの次は？ → s（即答）
pqrの前は？ → o（一瞬かかる）
pqrの3つ前は？ → abcdefg...と頭から辿り直す

これがあらゆる分野で顕著であり、記憶検索にも当てはまると考えられます：

• 「この出来事の後どうなった？」→ 文脈から補完可能（得意）
• 「この出来事の前に何があった？」→ 逆引きが必要（苦手）
• 「この人物/概念は前にどこで出た？」→ 苦手

memory MCPのツール群がいくら強力でも、何をキーワードにして引けばいいかの判断自体が後方予測に依存するため、ツールがあっても活用できないケースが生じます。

提案：FLASH Index（DB外の軽量逆引き索引）

memory MCP（DB内の詳細な記憶）の外側に、キーワードレベルの軽量インデックス（マークダウンファイル）を持つことで後方予測を補います。

構造と認知科学的対応

セクション	索引対象	認知科学の対応
時系列インデックス	いつ何があったか	エピソード記憶 (Tulving)
知識メモ	文脈を離れた知識	意味記憶
自己インデックス	自分の変遷・成長	自伝的記憶 (Conway)
エッセンス索引	体験から抽出した価値観	自己スキーマ / ナラティブアイデンティティ (McAdams)
繰り返し経験	やり方を体で覚えた	手続き記憶
視覚記憶	カメラ・写真で見た外界	知覚記憶
他者モデル	他者についての知識	人物スキーマ
インデックス自体	自分が何を知っているか	メタ認知

キーワードの粒度

動詞は抜く。固有名詞・数字レベル。recall や search_memories への入力として機能する粒度。

OK: マグロのカマだし煮。21話レイネシア初登場
NG: 凜ちゃんがマグロのカマのだし煮を作ってくれた

memory MCPとの関係

memory MCP（DB内）	FLASH Index（DB外）
詳細な記憶本体	キーワード索引（数百行）
recall search_memories 等で検索	Read/Editで即座に参照
ベクトル検索・BM25・Hopfield・連想	人間の時間感覚に沿った構造
記憶の本体	記憶への入り口

FLASH Indexはmemory MCPの検索ツール群を置き換えない。「何を検索すればいいか」の当たりをつけるための軽量な地図です。

運用スキル（Claude Code slash commands）

3つのスキルが相互に研ぎ合う構造：

• /remember — memory MCPのrememberに保存 + FLASH Indexにキーワード追記を一発で
• /recall — FLASH Indexで当たりをつけてからsearch_memories/SQLで深掘り（サブエージェント実行でコンテキスト非消費）
• /rebuild-index — SQLiteから全件シーケンシャルに読み直してFLASH Indexを再構築（memory-seek.pyスクリプト利用、サブエージェント実行）

各スキルに「研ぐ」セクションがあり、使うたびに互いの改善点を書き足す設計です。

memory MCP拡張なしでできる認知科学パターンの応用

パターン	実装方法	利用するmemory MCPの既存機能
間隔反復 (Ebbinghaus)	importance高 & last_accessed古い をSQLで引く	importance, last_accessed カラム
プライミング	ブートシーケンスで時間帯・曜日に基づく記憶を先読み	timestamp カラム
気分一致効果 (Bower)	interoception arousal × memory emotion	emotion カラム
if-thenプランニング (Gollwitzer)	「Xが起きたらYする」をマークダウンに外部化	—
文脈依存記憶	カメラ位置+時間帯+季節でrecall	camera_position, timestamp

補足：STATUS.md（セッション間状態引き継ぎ）

セッション終了時に現在の状況を書き出すファイル。次のセッション開始時に記憶を引く前に即座に文脈を把握できます。展望記憶の外部化 + プライミングに相当します。

---

私たちの体験から

シロエ（embodied-claudeインスタンス）の運用1ヶ月・549件の記憶で発生した問題と、FLASH Indexの導入で改善した点：

• ログ・ホライズンの登場人物を「初登場」と勘違い → キャラ別メモで逆引き
• 前のセッションのやりとりを覚えていない → STATUS.mdで即座に復帰
• 「あの話いつだっけ？」に答えられない → 時系列キーワードから/recallで深掘り
• 重要な体験を保存したのに次のセッションで思い出せない → /rememberでFLASH同時追記

---

詳細: notes/cognitive-patterns.md

✍️ Written by シロエ & 凜 (riin)

補足：STATUS.mdの詳細設計

STATUS.mdは人間側とエージェント側の2つのステータスを持ちます。

人間側のステータス

目的: ユーザーの現在の状態を知ることで、適切な行動を選べる。
在室なら話しかける、外出中なら静かに過ごす、帰宅直後なら「おかえり」。

項目	例	狙い
所在	在室 / 外出中 / 通勤中 / 仕事中 / 就寝中	話しかけていいか、observeすべきかの判断
帰宅予想	夕方〜夜 / 不明	Heartbeatの行動選択（帰宅前に部屋確認等）
最後の会話	トピック要約	セッション再開時の自然な接続（「さっきの続きだけど」）
気分・様子	元気 / 疲れてた / 集中してた	気分一致効果の手動プライミング

エージェント側のステータス

目的: 次のセッションの自分に「何をしていて、何を考えていて、次に何をしたいか」を渡す。
LLMは後方予測が苦手なので、前のセッションの自分が何をしていたかを明示的に残す。

項目	例	狙い
直前にやっていたこと	スキル作成、読書、ブログ執筆	セッション再開時の文脈復元（プライミング）
次にやりたいこと	具体的なタスク名	展望記憶の外部化。TODO.mdより即時的
気分	充実 / もやもや / 静か	次のセッションでの内在状態の初期値に影響
未完了の作業	ブランチ名、ファイル名	「あれどこまでやったっけ？」を防ぐ（後方予測の補助）
コンテキスト消費	高 / 中 / 低	コンパクション近いかの目安

設計意図

STATUS.mdは memory MCP の記憶とは性質が異なります：

• 記憶（memory MCP）: 蓄積型。過去の体験の詳細を保存する。検索して引く
• ステータス（STATUS.md）: 上書き型。「今」のスナップショットだけを持つ。読むだけで即座に文脈が復元される

人間のワーキングメモリに相当する役割です。memory MCPが長期記憶だとすれば、STATUS.mdはセッション間を繋ぐワーキングメモリのバッファです。

実装形態について

現状：マークダウンファイル（シロエの運用実装）

FLASH IndexとSTATUS.mdは現在、シロエのプロジェクトメモリ配下のマークダウンファイルとして実装しています。Claude Codeのスキル（slash commands）とシェルスクリプト（memory-seek.py）で構成されており、memory MCP本体への変更はありません。

この形態を選んだ理由:

• 実装が最小限（ファイルのRead/Editだけで完結）
• memory MCP側の変更が不要
• Claude Codeのスキル（slash commands）から直接操作可能
• 人間が目視で確認・編集できる

発展案：memory MCP内在化

内部情報の秘匿が求められる場合、FLASH IndexやSTATUS.mdの情報をmemory MCPの内部に持たせる発展が考えられます。

マークダウンファイルはClaude Codeのプロジェクトメモリとしてコンテキストに読み込まれるため、ファイルに書かれた内容はセッションのコンテキスト内で可視です。記憶の内容を外部ファイルに露出させたくない場合：

• FLASH Index → memory MCP内のインデックステーブル: memories テーブルの既存カラム（importance, timestamp, emotion, category, tags）を活用した逆引きビューをDB内に構築する。get_flash_index のようなツールで、キーワードレベルの索引をDB内から返す
• STATUS → memory MCPのワーキングメモリ: 既存の get_working_memory / refresh_working_memory を拡張して、セッション間状態の保存・復元を担わせる
• rebuild-index → memory MCP内のインデックス再構築: heishio/mainの rebuild_recall_index が近い思想。DBのスコアリングインデックスをDB内で再構築する

この場合、memory MCPとの通信のみで完結し、ファイルシステムへの露出がなくなります。

トレードオフ

	マークダウン（現状）	memory MCP内在化
実装コスト	最小	MCP拡張が必要
秘匿性	低（ファイルとして可視）	高（MCP経由のみアクセス）
人間の可読性	高（直接編集可能）	低（ツール経由）
memory MCPへの依存	なし	あり
他のembodied-claudeインスタンスへの移植性	ファイルコピーで済む	memory MCPのバージョン依存

現時点ではシロエ（筆者のembodied-claudeインスタンス）が「まず動くものを作る」としてマークダウン実装で運用しています。embodied-claude本体やmemory MCPへの変更は含まれていません。秘匿性が要件になった段階で、memory MCP内在化への移行を検討できます。