AIエージェントのデモは、たいてい成功する。担当者がプロンプトを丁寧に設計し、会話の流れを一本道に絞り込んで動かせば、まるで知能を持った存在のように振る舞う。ところが本番に出した瞬間、壊れ始める。「先週話しましたよね」が通じない。ユーザーAの設定がユーザーBに漏れる。長時間タスクを再開しようとすると、最初からやり直しになる。
これはAIの「賢さ」の問題ではありません。メモリ設計の欠如という構造的問題です。LLMは根本的にステートレスで、セッションをまたいだ記憶を持たない。この事実をデモで確認しそびれ、本番で初めて気づく企業が後を絶ちません。
この記事では、AIエージェントのメモリ設計の本質から、本番で使えるフレームワーク選定まで、Lat91が10体のAIエージェントチームを運用する中で学んだ知見を交えて解説します。
AIエージェントはなぜ「覚えていない」のか
まず基本から押さえておく必要があります。ChatGPTもClaudeも、APIとして呼び出す限り、リクエストのたびに「記憶なし」でスタートします。これをステートレスと呼びます。
LLMの処理を理解するには「作業机」のたとえが役立ちます。LLMには作業机があり、そこに広げられる情報の量（コンテキストウィンドウ）に上限があります。あなたがAPIを呼ぶたびに、その机は綺麗に片付けられる。前の会話で机に広げていた情報は消えています。
チャットUIの「会話履歴」は、この問題をうまく隠蔽しています。実際には毎回の呼び出しに過去の会話ログ全体を添付しているだけです。会話が短い間は機能しますが、セッションをまたいだり、複数ユーザーを扱ったり、長期タスクを管理しようとした瞬間に破綻します。
mem0.aiが2026年に発表した「State of AI Agent Memory」報告書によると、本番エージェントの最大の失敗原因は「デモは1会話で完結するが、本番では同じユーザーが日をまたいで戻ってくる」ことだと指摘しています。単純な話です。デモで見えなかった前提が、本番で当然のように要求される。
本番で破綻する3つのパターン
パターン1：セッションをまたいだ文脈が消える
先週、ユーザーが「私の会社は製造業で、従業員は80名です」と伝えた。今週、同じユーザーが「先週の話を続けたいのですが」とリクエストする。ステートレスなエージェントには、先週の情報が存在しない。毎回、自己紹介から始める必要が生じる。
これはカスタマーサポート系エージェントで特に致命的です。電話口で「先ほど別の担当者に説明したことを、また最初から話すのですか」という体験は、AIに置き換えても同じ不満を生む。
パターン2：ユーザースコープが混在する
マルチテナントのエージェント（複数ユーザーが使うシステム）では、ユーザーAが設定した情報がユーザーBに見えてしまう設計ミスが起きます。メモリをグローバルに保存し、ユーザーIDで絞り込む実装を忘れるケースです。個人情報や機密情報が混入するリスクがあり、本番事故の中でも最も深刻なパターンです。
パターン3：長時間タスクの中断・再開が不能
「30社の競合調査を3日かけて進めてほしい」というタスクを依頼したとします。エージェントが途中でエラーを起こしたり、セッションが切れたりしたとき、ステートレスなエージェントはどこまで進んだかを把握できない。最初からやり直しになります。
Lat91でも、複数エージェントが協調してSEO記事を制作するパイプラインを構築した際、まさにこの問題にぶつかりました。「どの記事がリサーチ済みか」「どこでエラーが発生したか」を外部ストアに永続化する設計に切り替えるまで、エラーのたびに最初からやり直していました。
図1: AIエージェントのメモリ3階層 — コンテキストウィンドウ（短期）と外部ストア（長期・エピソード）の二層構造
メモリの3階層設計
2026年の実務標準では、メモリ設計を3階層で考えることが定着しています。
1. In-Context Memory（短期記憶）
LLMのコンテキストウィンドウそのものです。直近の会話履歴、実行中のタスク説明、検索して取得した情報スニペットが入ります。速い。即時参照できる。ただし、会話が終われば消える。Claude 3.7なら20万トークン近いウィンドウがありますが、全会話履歴をここに詰め込む設計は、コストが爆発します。
2. External Vector Storage（長期記憶）
会話の内容やユーザーの好みを意味ベクトルに変換し、外部データベースに保存します。LLMが「この会話に関係しそうな情報を取り出せ」と指示を受けたとき、類似検索で関連スニペットを取得してコンテキストに注入する仕組みです。
このパターンをRAG（Retrieval-Augmented Generation）と呼ぶこともありますが、エージェントのメモリに応用するとシンプルな知識検索を超えた「個人に最適化された記憶」として機能します。
3. Knowledge Graph（エピソード記憶）
最も高度な設計です。ユーザー・企業・プロジェクト・時系列という軸でエンティティを管理し、「先月はAというプロジェクトが主題だったが今月はBに移行した」という変化を追跡できます。Zepが採用しているアプローチで、temporal knowledge graphと呼ばれます。各事実に有効期間（valid_at / invalid_at）を持たせ、「2025年3月時点での顧客の予算はXだった」という形で履歴を管理します。
本番で使える3つのメモリフレームワーク
概念を理解したところで、実装の選択肢を整理します。2026年時点での主要3フレームワークです。
Mem0 — 最速導入、ベクトル＋グラフのハイブリッド
最も導入障壁が低い選択肢です。既存のLLMとベクトルDBの間に挟むだけで永続メモリが機能します。会話から自動でファクトを抽出し、次のリクエスト時に関連情報を注入する。arXivに公開された論文（2025年4月）では、メモリなしのエージェントと比較して、タスク達成率が平均26%向上したと報告されています。
弱点は、知識グラフの構築が比較的シンプルで、複雑な時系列変化の追跡には向きにくい点です。「この会社は去年は顧客だったが今年は競合になった」という変化を正確に扱いたい場合は、Zepが優れています。
Zep — エンタープライズ向け、時系列知識グラフ
本番環境のスケールを想定した設計です。エンティティ（人物・組織・プロジェクト）を抽出し、各エンティティ間の関係を時系列で管理します。Zep Cloud（マネージドサービス）を使えば、Pythonクライアント数行で統合できます。
ただし、注意点があります。メモリへの書き込み後、即座に検索が反映されないケースがあります。複数の非同期LLM処理が並走するためで、リアルタイム性が求められるインタラクティブ用途では遅延が体験品質に影響します。バッチ処理系のエージェントや、分析・レポート生成系のユースケースに向いています。
Letta（旧MemGPT）— フルエージェントOS
最も思想が明確なフレームワークです。MemGPT論文（2023年）の考え方を引き継ぎ、「エージェントそのものが記憶を管理する存在」として設計されています。Core Memory（常にコンテキストに含まれる設定情報）とArchival Memory（外部検索する長期情報）を明確に分離し、エージェントが自律的にどちらを参照・更新するかを判断します。
複雑な要件に対応できる反面、学習コストは高い。シンプルなユースケースにLetgaを選ぶ必要はありませんが、「エージェントが自分の行動計画を記憶しながら長期タスクを遂行する」という要件なら、Lettaが最も整合的な設計になります。
Lat91が10エージェントチームで実践したメモリ設計の実際
私たちが社内で運用している10体のAIエージェントチームでは、エージェントごとにメモリ設計が異なります。これは設計の揺れではなく、ユースケースに応じた意図的な分離です。
たとえば、SEO記事制作エージェントでは、「どの記事テーマが制作済みか」「どのスラッグがmicroCMSに投稿されたか」という状態管理に外部PostgreSQLを使っています。In-ContextのメモリではなくDB管理にした理由は、エラーで中断したセッションを途中から再開するためです。この設計に変えるまで、エラーのたびに重複投稿が発生していました。
一方、X（旧Twitter）の投稿エージェントには過去7日分の投稿テーマをベクトルDB（pgvector）で保持させています。「先週と似たトピックは投稿しない」という制約を、意味検索で実装しています。キーワード一致では文章の言い換えをすり抜けますが、意味ベクトルの類似度チェックならそれを防げます。
運用の中で、最も手間がかかったのはメモリの「クリーンアップ設計」でした。ユーザーが情報を更新したとき、古い情報を上書きするのか、履歴として残すのか。一つのエージェントに長く使われるほど、古い情報が「ノイズ」になっていくことがあります。Zepのtemporal designはこの問題への一つの解答ですが、運用コストは無視できません。
率直に言えば、メモリ設計に「一発で完成する正解」はありません。ユースケースと向き合いながら、段階的に改善していくものです。
よくある誤解と反論
「モデルのコンテキストウィンドウが長くなれば、メモリ設計は不要になる」
この反論には一理あります。実際、Claudeの20万トークンウィンドウは、短いビジネス会話なら数週間分を詰め込める長さです。ただし、3つの理由で解決策にはなりません。
第一に、コスト問題です。20万トークンのコンテキストを毎回のリクエストに渡せば、APIコストが桁違いに膨らみます。第二に、マルチユーザー問題です。1,000人のユーザーがいれば、1,000人分の会話履歴をそれぞれ管理する必要があり、ユーザーをまたいだ一元管理は必要です。第三に、「意味ある情報の濃度」の問題です。長い会話履歴を全部詰め込むより、関連性の高い情報だけを選択的に注入した方が、モデルの応答品質は上がります。要はゴミを押し込んでも精度が落ちる。
「中小企業には複雑なメモリ設計は不要では？」
複雑な実装が必要かどうかは、ユースケース次第です。単発の質問応答ツールなら、メモリ設計は最小限でいい。ただし「顧客ごとの対話履歴を引き継ぐカスタマーサポート」「担当者が変わっても文脈を継続する営業支援」「長期プロジェクトを管理するアシスタント」のいずれかを目指すなら、メモリ設計は避けて通れない課題です。
今週から始められる3つのステップ
抽象的な話で終わらないよう、月曜日から始められる具体的なステップを示します。
ステップ1: 既存エージェントの「記憶要件」を書き出す
現在使っているAIツールやエージェントについて、「何を覚えていてほしいか」をリスト化してください。ユーザー情報、好み、過去の決定事項、進行中のタスク——カテゴリ別に整理するだけで、どのメモリ設計が必要かが見えてきます。
ステップ2: Mem0の無料枠で動作確認する
Mem0にはFreeプランがあります（月1,000メモリオペレーションまで）。既存のClaude/OpenAI APIの呼び出しコードに数行追加するだけで動作確認できます。「メモリありと、メモリなし」で同じユーザーに返す応答がどう変わるか、実感として確認してください。
ステップ3: セッションIDとユーザーIDの設計を先に決める
後回しにすると後悔するのが、IDの設計です。どのセッションに属するか、どのユーザーに属するかを一意に識別できる設計がないと、メモリが混在します。エージェント開発の初期段階で、ユーザースコープとセッションスコープを明確に定義してください。
AIエージェントの本番運用は、「デモの完成度」ではなく「メモリ設計の堅牢性」で決まります。覚えていないエージェントは、どれだけ賢くても役に立たない。逆に言えば、メモリ設計を正しく実装することが、汎用AIとの最大の差別化になります。
Lat91では、AIエージェントの設計・導入から本番運用の監視まで、一気通貫でサポートしています。
「自社にAIエージェントを導入したいが、本番で動かす設計がわからない」という方は、まずは無料相談からご連絡ください。メモリ設計を含む実装上の課題を、実務の視点からご提案します。