はじめに：モデル切り替え時の「初期化」問題
LLMの進化スピードが加速する昨今、昨日までClaude 3を使っていたワークフローを、今日はGPT-4o、あるいはGeminiやローカルLLM（Llama 3など）に切り替える意思決定が日常的に行われるようになりました。Model Context Protocol（MCP）の普及やエージェントランタイムの標準化もあり、推論エンジンの切り替え自体は驚くほど容易になっています。
しかし、実際にモデルを差し替えたとき、多くの開発者が直面するのが「初期化（オンボーディング）の再発生」という問題です。
プロンプトテンプレートやツールのインターフェースは移行できても、そのAIがこれまでのセッションで蓄積してきた「コンテキスト」「ユーザーの暗黙の好み」「プロジェクトの背景知識」「試行錯誤のプロセス」といった「記憶（Memory）」はすべてリセットされてしまいます。新しいモデルに移行した瞬間、再びゼロからコンテキストを注入し直す必要が生じるのです。
本記事では、この「モデル依存の記憶喪失」を防ぎ、真にポータブルなAIワークフローを実現するためのアーキテクチャについて、メモリ分離の観点から考察します。
なぜ「モデルを換えるとワークフローが壊れる」のか
現状の多くのAIシステムにおいて、「推論（Reasoning）」と「記憶（Memory）」が密結合していることが根本的な原因です。
モデルを差し替える際、私たちは以下のような情報の再学習・再注入を余儀なくされます。
- システムやキャラクターとしての「背景設定」の再定義
- 過去の対話から学習した「ユーザーの好みや癖」の再認識
- プロジェクトにおける「これまでの変更履歴や議論のコンテキスト」の再共有
- 「どのツールをどの順番で呼ぶのが効率的か」というツール利用の暗黙知の再学習
- 現在進行中のタスクにおける「作業メモリ（ステート）」の再同期
これはワークフローを移行したというより、単に「APIの呼び出し先を変えただけ」の状態です。ステート（状態）の移行ができていないため、エージェントは移行のたびに記憶喪失に陥ります。
既存アプローチの限界
この課題に対し、これまでいくつかのアプローチが試みられてきましたが、いずれもスケールやポータビリティの面で限界があります。
1. プロンプトテンプレートによる静的な再注入
システムプロンプトに前提条件を毎回埋め込む方法です。静的な設定ファイルとしては機能しますが、セッションを通じて動的に学習される「ユーザーの好み」や「作業履歴」など、ミュータブル（可変）な状態を扱うには不向きです。
2. 巨大なコンテキストウィンドウ（Long Context）への依存
数百万トークンを扱えるモデルに、過去の履歴を丸ごと放り込む力技です。
しかし、これは以下の問題を招きます。
- Needle in a Haystack精度の低下: 文脈に埋もれた重要情報の検索漏れ
- コストと遅延: APIコストの急増、レスポンス遅延（TTFT: Time To First Token の悪化）
- モデル間の解釈ブレ: モデルごとにAttentionの働き方が異なるため、履歴の解釈がモデル依存になる
3. 単純なRAG（検索拡張生成）
外部のVector DBから関連ドキュメントを検索してプロンプトに添付する方法です。
静的な知識ベースの拡張としては有効ですが、「エージェントが過去にどう推論したか」「過去のどの発言が重要だったか」といった、エージェント自身のメタ認知や自己反省（Reflection）を動的に更新・構造化する用途には設計されていません。
4. 生のセッション履歴（Chat History）の引き継ぎ
チャットログをそのまま次のモデルに流し込む方法ですが、モデルごとに推奨されるメッセージフォーマットやトークナイザーが異なります。生のテキスト履歴をそのまま渡すと、「不要なノイズ」として処理されたり、コンテキストが破綻するリスクがあります。
推論と記憶を分離するマルチレイヤーアーキテクチャ
「モデルを差し替えてもワークフローが壊れない状態」を作るには、推論エンジン（LLM）と記憶（Memory）を完全に独立したレイヤーとして設計し、疎結合にする必要があります。
メモリを単なるテキストの羅列ではなく、用途と構造が異なるマルチレイヤー構造として定義します。
| メモリの分類 | 役割と特徴 | データの性質 |
|---|---|---|
| Background | システムや組織の不変に近い前提条件やドメイン定義 | 静的・宣言的 |
| Fact | ユーザーやエンティティに関する、動的に蓄積される客観的な事実 | 動的・KVS的 |
| Event | これまでのセッションで発生した重要なアクションやマイルストーン | 時系列・ログ |
| Dialogue | 単なる履歴ではなく、対話の流れを圧縮・構造化したコンテキスト | 要約・ベクトル |
| Reflection | 過去の失敗や成功からAI自身が導き出した「次回からこうすべき」というメタ知識 | 動的・ルールベース |
| Skill | どのツールをどう呼び出すと成功したかという、ツール利用の最適パターンの記憶 | 手続き的 |
このメモリ群をモデルの外部で一元管理し、推論のたびに関連する情報だけをプロンプトに「ハイドレーション（注入）」する仕組みを構築します。
独立した永続メモリ層「MemoryLake」という概念
このアーキテクチャを実装する際、自前でRedisやVector DBを組み合わせるだけでは、記憶の統合（Consolidation）処理のボイラープレートコードが膨大になります。
ここで注目すべきなのがMemoryLake（メモリレイク）というアーキテクチャパターンです。
これは単なるVector Storeではなく、「持続可能で、ポータブルで、ガバナンスの利いたメモリレイヤー」として機能します。AIにとっての「Memory Passport（メモリパスポート）」と呼べるものです。
なぜVector DBやRAGでは足りないのか？
-
抽象化と統合（Consolidation）
生の会話をそのまま記録するのではなく、バックグラウンドで非同期に会話を「抽象化・統合」し、不要な雑音を捨て、重要なFactやReflectionとして再構造化します。 -
双方向の学習ループ（Write-back）
通常のRAGが「Read-only」な外部知識検索になりがちなのに対し、MemoryLakeはエージェントの行動結果を監視し、自己反省（Reflection）やスキルの更新を「書き込む」動的なサイクルを持ちます。 -
ポータビリティとポリシー管理
どのモデルにも適合しやすい共通スキーマでデータを保持し、鮮度（Recency）や関連性（Relevancy）に基づいてフィルタリングを行います。
モデルA（例：Claude）のセッションで生成された暗黙のルールや事実をMemoryLakeに蓄積し、その後モデルB（例：GPT-5.5）に推論エンジンを差し替えたとしても、エージェントはこの「メモリパスポート」を参照するだけで、全く同じコンテキストを維持して稼働できます。
設計上のトレードオフと実装の注意点
この分離アーキテクチャを実装するにあたり、エンジニアが考慮すべきトレードオフがあります。
1. メモリの「統合（Consolidation）」にかかるオーバーヘッド
セッション中の会話から「重要な事実」を抽出してメモリに統合する処理は、LLMの推論を伴うためコストがかかります。これをリアルタイムにインラインで実行するとTTFBが著しく悪化するため、基本的にはバックグラウンドの非同期タスク（キューワーカーなど）として実行する設計が求められます。結果として、書き込みと読み取りの間にEventual Consistency（結果整合性）を許容するシステム設計が必要になります。
2. モデル固有の表現差分の吸収（Adapter層の必要性）
BackgroundやReflectionが共通のJSONスキーマで保存されていたとしても、モデルごとに「System Promptに書くべきか」「User Promptの先頭に差し込むべきか」といった特性の差があります。
そのため、MemoryLakeから取得したデータを各モデルの推奨フォーマットに変換する薄いAdapter/Hydration層をランタイム側に用意するのが現実的です。
まとめ
LLMの推論性能やAPI価格のコモディティ化が進む中、AIシステムの真の価値は「どのモデルを使うか」から「どのようなコンテキストと記憶を構造化して蓄積できているか」へとシフトしています。
推論エンジンをいつでも最適なものにスワップアウト（交換）できる柔軟性を確保することは、ベンダーロックインを回避し、システムの寿命を延ばすために不可欠です。
プロンプトエンジニアリングの工夫やコンテキストウィンドウの引き伸ばしに限界を感じている方は、「推論と記憶の完全分離」というアーキテクチャへの移行を検討してみてはいかがでしょうか。一時しのぎの履歴保存から、システム全体の「脳」を定義するインフラへの転換が、次世代のマルチエージェント開発の鍵となります。