AIエージェントの「記憶」機構を深掘り：公式ドキュメント外のバイナリ解析で真の仕組みを解明
本記事は、複数のAIエージェント（Claude Code、Codex、Cursor、Grok Build、Gemini CLI、Antigravity）が持つ「メモリ機能」の動作原理を、単なる公式ドキュメントの読解に留まらず、より高度なフォレンジック手法を用いて徹底的に調査した記録である。調査の目的は、AIエージェントがどのように長期的な記憶を保持し、利用しているかという「仕組み」を解明することにある。
筆者は、以下の5つの手段（A. CLIヘルプ、B. 同梱ドキュメント、C. ローカルDBスキーマ、D. 実行ファイル識別子、E. 実行ログ）を用いて、各製品の内部構造を解析した。特に、ローカルデータベースのスキーマ解析（手段C）や、実行ファイルからの識別子抽出（手段D）により、公式には公開されていない設計思想が明らかになった。
Codexの記憶機能の調査では、機能が「安定版（stable）」と表示されていても、既定で無効化されている（false）という事実が判明した。また、SQLiteのスキーマから、処理が遅いのではなく、そもそもジョブが起動していないという根本的な問題点が指摘された。一方、GoogleのAntigravityは、最も洗練された設計を持ち、記憶のトリガーを「常に」「モデル判断」「手動」「パターン一致」の4種類から選べるなど、高い柔軟性を持つことが判明した。さらに、記憶専用のモデルや、知識層（Knowledge Base）といった、文書とは別の情報管理レイヤーが存在することも確認された。
しかし、機能の設計が高度である一方で、実際にセッションをまたいだ記憶の引き継ぎや、型指定（Decimal型など）の維持といった実用面では、複数の製品で課題が残っていることが示された。本記事は、AIエージェントの「記憶」が単なる機能ではなく、複雑なデータベース構造、専用モデル、そして複数の処理ステップからなる「システム」であることを、具体的な技術的手法を交えて解説している。
背景
近年、AIエージェントの進化に伴い、単発の対話だけでなく、過去のやり取りや外部知識を参照しながら長期的にタスクを遂行する「記憶（メモリ）」機能が必須となっている。しかし、この記憶機構の内部構造や、どの情報がどのように利用されているかという技術的な詳細情報は、ベンダーによって秘匿されがちであり、本記事はそれを技術的に掘り下げた。
重要用語解説
- CLI: Command Line Interface（コマンドラインインターフェース）の略。GUI（グラフィカルユーザーインターフェース）ではなく、テキストコマンドを入力して操作する環境。AIエージェントの機能や設定を詳細に確認する際に用いられる。
- SQLite: 軽量な組み込み型データベースシステム。サーバーを必要とせず、単一のファイル（.sqlite）として動作するため、ローカル環境でのデータ保存や、エージェントの作業履歴（トラジェクトリ）の記録に利用される。
- Memory Corpus: AIエージェントが参照する「記憶」専用の知識層。一般的な文書データ（Document Corpus）とは別に、過去の対話や重要な決定事項を構造化して保存する、専門的な情報データベースの区分けを指す。
今後の影響
本記事が示すように、AIエージェントの「記憶」機構の透明性が高まることは、AIの信頼性向上に直結する。今後は、単に「記憶がある」という宣伝文句ではなく、どの情報が、どのようなトリガーで、どのモデルを介して参照されたのかという「根拠（Citation）」の提示が標準となり、AIの利用における信頼性と監査可能性が求められるようになる。