複数のAIエージェントやLLM（大規模言語モデル）を使い分けるチームが増えています。Claudeで書いたコード、ChatGPTでレビューした設計、社内の別モデルで検証した障害対応。これらの経緯を毎回セッションが忘れてしまい、同じ調査を繰り返した経験がある方に向けた記事です。
この問題は「AIメモリ」や「長期記憶機能」という言葉で語られますが、実装のほとんどはRAG（検索拡張生成、外部データを検索してプロンプトに埋め込む仕組み）の延長線上にあります。ドキュメントやチケットを検索して回答に混ぜるだけで、それを「記憶」と呼ぶのは正確ではありません。SREやインフラ担当者にとって本質的な問いは、記憶をモデルの外に置くか、それともベンダー固有の機能に頼るか、という設計判断です。
どんな場面でこの判断が必要になるか
典型的なのは、障害対応の後始末です。
ポストモーテム（障害の振り返り記録）を書いても、次にAIエージェントに同じ障害の類似ケースを聞いたとき、モデルはゼロから推論を始めます。「なぜこの回避策が存在するのか」「なぜこの構成だけTerraformのstate外で管理しているのか」という文脈は、モデルの知識ではなく、プロジェクトの履歴だからです。
もう一つの典型例は、モデルの切り替えです。Claudeで書いた設計判断を、来月GPT系のモデルに引き継ぐ場面や、コスト都合でローカルLLMに切り替える場面です。記憶がベンダー固有のセッション機能やチャット履歴に閉じていると、モデルを変えた瞬間に文脈が消えます。
こうした場面に心当たりがあるなら、記憶をどこに・どう持たせるかを一度整理する価値があります。
判断軸
記憶基盤を選ぶときに検討したい軸は4つです。
- 可搬性: 特定のモデルやベンダーに縛られず、別のモデルに引き継げるか
- 監査可能性: 誰が・いつ・なぜその記憶を書き込んだか、後から追跡できるか
- 鮮度管理: 古くなった前提や誤った学習結果を、明示的に無効化・更新できるか
- 運用コスト: 追加のインフラ（DBやMCPサーバーなど）を自前で維持する手間と、既存SaaS機能を使う手軽さのどちらを取るか
可搬性は特に重要な軸です。モデルが「明日消えてもよい」設計、つまりモデルは交換可能な演算資源で、履歴は別のレイヤーに残る、という考え方です。MCP（Model Context Protocol、AIモデルと外部ツール・データソースをつなぐ標準プロトコル）はこの可搬性を実現する手段の一つとして注目されています。特定モデルのAPIに直接依存せず、共通のインターフェースでメモリハブにアクセスできるからです。
監査可能性は、SREの障害対応プロセスと相性がよい軸です。ポストモーテムに「誰が承認したか」のログが必要なのと同様に、AIが書き込んだ「学習結果」にも由来のトレーサビリティが要ります。プレーンなMarkdownファイルにメタデータを構造化して持たせる方式なら、Gitでバージョン管理でき、差分もレビューできます。
鮮度管理は見落とされがちですが、インフラの世界では致命的になり得る軸です。「このワークアラウンドは3つのリポジトリが依存しているから残っている」という情報は、依存が解消されれば古くなります。記憶に有効期限やレビュー機構がないと、間違った前提を延々と参照し続けるリスクがあります。
選択肢の比較
記憶をどこに持たせるかには、大きく3つの方向性があります。
| 方式 | 可搬性 | 監査可能性 | 運用コスト |
|---|---|---|---|
| ベンダーのチャット履歴・組み込みメモリ機能 | 低い（モデル・製品に固定） | 低い（内部実装がブラックボックス） | 低い（追加インフラ不要） |
| RAG（Vector DBに検索用データを格納） | 中程度（DB自体は共有できるが検索対象は既存資料中心） | 中程度（検索元は追える、書き込みの経緯は追いにくい） | 中〜高（埋め込みモデル・Vector DBの運用が必要） |
| 外部共有メモリハブ（MCP経由でMarkdown＋メタデータを読み書き） | 高い（プロトコル経由でモデル非依存） | 高い（構造化メタデータとGit履歴で追跡可能） | 中程度（小さなHTTPサーバー＋ストレージの運用） |
ベンダー組み込みのメモリ機能は、導入コストが最も低い代わりに、そのベンダーのエコシステムから抜けにくくなります。契約更新や価格改定のタイミングで、記憶ごと乗り換えコストを背負うリスクがあります。
RAGは既存ドキュメントやコードベースを検索する用途には強みがありますが、「プロセスが生み出した知見」、つまりまだドキュメント化されていない暗黙知を蓄積する仕組みとしては設計目的が異なります。検索対象がすでに存在する資料に限られるためです。
外部共有メモリハブは、小さなHTTPサーバーを立て、各AIセッションがMCPサーバー経由で「一覧取得」「関連情報の取得」「新規情報の書き込み」という最小限のツールセットを使う構成です。実装自体は意図的にシンプルに保たれており、インフラ的には既存の監視・バックアップ体制に載せやすいのが特徴です。
ケース別の推奨
複数のAIツールやモデルを併用しており、かつ障害対応やインフラ変更の経緯を長期的に蓄積したいなら、外部共有メモリハブの方向を検討する価値があります。Gitで管理できるMarkdown形式であれば、既存のCI/CDパイプラインでレビューやリンティングも組み込めます。
単一のAIツール（例えば社内標準でClaudeのみ、GPT系のみ）に統一されており、モデル切り替えの予定がないなら、ベンダー組み込みのメモリ機能で十分な場合があります。追加インフラを持たない分、SREの運用負荷は増えません。
既存のドキュメントやコードベースをAIに参照させたいだけで、プロセスの意思決定履歴までは残す必要がないなら、RAGの構成で目的は達成できます。Vector DBの選定・埋め込みモデルのバージョン管理・再インデックスの運用コストは発生しますが、検索精度の面では成熟した選択肢です。
あえて見送るべき条件
次のような条件では、外部共有メモリハブの導入を急ぐ必要はありません。
- チームの人数が少なく、AIエージェントへの依頼内容を口頭やSlackで十分に共有できている
- AIツールの利用がまだ試験段階で、モデルの選定自体が固まっていない
- 記憶に書き込む「知見」を精査するレビュー体制（誰が承認するか）を用意できていない
特に3点目は重要です。記憶を外部化しても、書き込まれる情報の質を担保する仕組みがなければ、誤った前提が「正式な記憶」として扱われ続けるリスクがあります。これはモデルの記憶であっても、ベンダー機能の記憶であっても共通する落とし穴です。
まとめ
AIの記憶をどこに持たせるかは、モデル選定と同じくらいインフラ設計の判断です。
- 可搬性・監査可能性・鮮度管理・運用コストの4軸で、自分たちの利用状況を棚卸しする
- 複数モデルを併用し、履歴の引き継ぎが必要ならMCPのような標準プロトコル経由の外部メモリを検討する
- 単一ベンダー・単一モデルで完結しているなら、組み込み機能で十分なケースも多い
- どの方式を選んでも、記憶への書き込みをレビューする体制がなければ効果は限定的
まずは自分たちのAI利用が「単一モデル完結」か「複数モデル・複数ツール併用」かを確認するところから始めてみてください。それだけで、どちらの方向を検討すべきかの見当がつくはずです。