AIエージェントの記憶ライフサイクルをどう設計するか？

身近なAIツールは、すでに記憶を扱い始めている

　AIエージェントのMemoryは、研究上の概念だけではなくなっています。CodexやClaude CodeのようなAIコーディングツールを使っていると、すでに「記憶に近い仕組み」の存在を感じる場面があります。たとえば、長い作業の途中で会話履歴が圧縮され、次の作業に必要な文脈だけが引き継がれることがあります。また、CodexではAGENTS.md、Claude CodeではCLAUDE.mdのようなファイルに、「このリポジトリではpnpmを使う」「テストはこのコマンドで実行する」といったプロジェクト固有のルールを書いておくことがあります。さらに、Claude Codeの自動メモリのように、作業中に得られたビルドコマンド、デバッグ上の気づき、開発上の好みなどを、後続の作業で再利用できる形で保持する仕組みも登場しています。

　これらは、AIが毎回ゼロから作業するのではなく、過去の文脈やルールを次回以降に引き継ぐための仕組みです。最近では、後述するDreamingのように、保存された記憶をあとから整理・再編成する考え方も出てきています。

　ただし、個人がAIツールを使う場合と、企業が業務エージェントを実装する場合では、設計すべき範囲が異なります。個人利用では、用意されたMemory機能やプロジェクト固有の指示ファイルで足りる場面もあります。一方、業務エージェントでは、すでに存在する会話履歴、チケット履歴、業務DB、RAG文書、実行ログとMemoryをどう接続するかを設計する必要があります。

マネージドMemory機能だけで足りる場合、足りない場合

　この節では、現状のマネージドMemory機能が担える範囲と、業務アーキテクチャ側に残る設計を切り分けます。マネージドMemory機能は、会話をまたいだ文脈保持や、ユーザーごとの継続的な体験を実現するうえで有効です。一方で、既存の会話履歴、チケット履歴、業務システム上のデータ、RAG文書、実行ログまで含めたMemory設計を、すべて自動的に代替するものではありません。

　実際、最近のマネージドなエージェントサービスには、会話から意味のある情報を抽出し、統合し、必要に応じて取り出す長期Memory機能が用意され始めています。

　AzureにおけるマネージドMemoryは、主にMicrosoft Foundry Agent ServiceのMemory / Memory Store APIが担う長期メモリ機能と考えると理解しやすくなります。これは、会話から得られるユーザー文脈、過去セッションの要約、繰り返し使う手順を抽出・保存・検索し、セッションをまたいだ継続性を支えるものです。たとえば、User profile memory、Chat summary memory、Procedural memoryのように、ユーザーの嗜好、過去会話の要約、繰り返し使う手順を扱うMemoryタイプも用意されています。

　一方、RAG文書や組織知識は、Foundry IQのようなナレッジ層や検索基盤で扱う方が適している場合があります。Foundry IQは、組織が管理する構造化・非構造化データを、エージェントが利用できる知識として扱うための層です。つまり、AzureのMemory機能は、業務データ全体を置き換えるものではなく、エージェントが継続的な文脈を持つためのMemory層として位置づけるのが自然です。正式な契約条件、顧客ステータス、最新の権限、価格、在庫、障害状況のようなデータは、Memoryやナレッジベースに固定化するのではなく、必要なタイミングで業務DBやAPIへ問い合わせる必要があります。

　Amazon Bedrock AgentsのMemoryでも、同じmemoryIdに紐づくセッション要約を、次回セッションで利用できます。なお、AWSではBedrock AgentsのMemoryとは別に、短期Memoryと長期Memoryを扱うAmazon Bedrock AgentCore Memoryも提供されており、AWSのMemory機能全体を論じる場合は、こちらも別枠で整理する必要があります。

　このようなマネージドMemory機能は、会話をまたいだ継続性、ユーザーの嗜好や制約の保持、過去セッションの要約再利用、繰り返し使う作業手順の保持に有効です。単一のエージェントが、同じユーザーとの会話を自然につなげる用途であれば、マネージドMemory機能だけで実現できる範囲もあります。たとえば、ユーザーの呼び方、好みの説明粒度、過去に相談したテーマ、繰り返し使う作業手順、セッションをまたいで継続するタスクの文脈を保持する用途では、マネージドMemoryは有効に機能します。

　この点で、Oracle AI Agent MemoryやOracle AI Databaseのように、Memoryを独立した会話機能ではなく、データベース基盤上の情報管理として扱うアプローチも登場しています。Oracle AI Databaseは、ベクトル、リレーショナル、グラフ、JSONなど複数のデータモデルを扱えるため、会話の文脈、事実、関係性、業務データを近い場所で管理する考え方と相性があります。これは、Memoryを単なる会話要約ではなく、業務データと接続された永続的な情報層として捉える方向性です。

　ただし、どの製品やアプローチを選ぶ場合でも、業務エージェントのMemory設計が自動的に完結するわけではありません。Memoryに残っている情報は、必ずしも今回の判断で使ってよい前提とは限らないためです。担当者が変わった、契約条件が更新された、運用ルールが変わった、過去の対応が例外処理だった、といった状況では、過去のMemoryをそのまま使うと誤った判断につながります。したがって、Memoryを検索するだけではなく、現在の業務データやルールと照合し、今回使ってよい前提かどうかを判定する設計が必要です。

　さらに、業務エージェントでは、扱うデータの種類と性質が大きく増えます。現在の会話状態、過去の対応履歴、顧客や担当者の情報、関係性や変更履歴、業務知識、手順やRunbook、監査ログは、すべて同じMemoryとして扱えるものではありません。この違いを整理するために、次節では既存データをMemory候補、正式な参照元、検索対象、ログに分けて考えます。

　つまり、マネージドMemoryは、業務エージェントの記憶設計を不要にするものではありません。会話をまたいだ継続性を支える部品としては有効ですが、業務判断に使ってよい情報の範囲、正式データとの優先順位、検索されたMemoryの有効性確認、監査や評価のためのログ保持は、Memory、ナレッジ層、検索、正式参照元、権限管理、ログ管理を組み合わせたアーキテクチャとして設計する必要があります。業務エージェントにおけるMemory設計とは、単に過去の会話を覚えさせることではなく、会話、業務DB、RAG文書、チケット履歴、実行ログを、用途ごとに分けて接続する情報設計なのです。