AIエージェントのメモリとは？セッションをまたぐ作業文脈の考え方

AIエージェントのメモリとは、セッションをまたいで作業の前提、判断、調査履歴、ユーザーの好みを参照できるようにする記憶層です。Claude Code、Codex、CursorのようなAIコーディングエージェントを毎日使うほど、この層の有無が作業開始の速さに直結します。

AIエージェントは、1つのチャットの中では非常に強力です。しかし、セッションが変わった瞬間に、前回どのファイルを読んだか、どのエラーを見たか、どの方針を捨てたかを失いやすいという問題があります。

Claude Code、Codex、CursorのようなAIコーディングエージェントを毎日使うほど、この問題は目立ちます。毎回プロジェクト構成を説明し直し、昨日読んだIssueを貼り直し、なぜその実装方針にしたかをもう一度説明することになります。

persistent memoryは、AIエージェントがセッションをまたいで参照できる記憶のことです。単にチャットログを保存するだけではなく、次の推論に必要な情報を取り出しやすい形にしておくことが重要です。

たとえば、ユーザーの好み、プロジェクトの設計方針、よく使うコマンド、以前に失敗した実装、調査済みのGitHub Issueなどがメモリ候補になります。これらがあると、エージェントは毎回ゼロから始めずに済みます。

AIエージェントの性能が上がるほど、問題は『答えられるか』から『前提をどれだけ正しく持っているか』に移ります。Claude CodeやCodexは強力ですが、セッションをまたぐと、昨日の調査、捨てた方針、読んだIssue、別agentで見つけた懸念を知りません。

だから、AI memoryは単なる便利機能ではなく、複数agentで仕事をするための作業基盤になります。特に開発では、コード差分だけでなく、調査、ブラウザ、画面、agentとの会話が判断の材料になります。

永続メモリで難しいのは、記録する範囲を小さくすることではありません。むしろ、作業の文脈を復元するには、チャットログだけでは足りません。画面、ブラウザ履歴、アプリ利用、キーボード入力、複数エージェントの会話履歴まで含めて、あとから辿れる材料を持つ必要があります。

ただし、記録したものをそのまま毎回プロンプトへ入れるわけではありません。Contextbergの考え方は、広くローカルに保存し、Activity、Hourly Report、LTMのような層に整理して、AIには必要な粒度だけを渡すことです。Raw dataは保管と検証のために残し、AIが読むcontextは圧縮・選別された作業文脈にします。

この違いが重要です。『全部を記録する』ことと『全部を毎回AIに読ませる』ことは別です。Contextbergは前者をローカルで実現し、後者を避けるために、検索可能な記録、時間単位の要約、長期メモリ、MCP toolsという出口を分けています。

現在のAI memoryは、同じmemoryという言葉を使っていても、誰のためのmemoryかが違います。Mem0はAIアプリに組み込むmemory layer、Lettaはstateful agentを作るためのagent runtime、agentmemoryはAI coding agentのセッション記憶、ContextbergはユーザーのPC作業環境側に置くlocal work memoryです。

AgentMemory系を探している人の疑問は、『Claude CodeやCodexが前回の作業を覚えるには何が必要か』です。その答えがagent内のhookやmemory serverで足りる場合もあります。ただ、ブラウザで調べたページ、画面に映っていた状態、別agentでの判断まで含めたいなら、memoryはagent側だけでなくPC作業環境側に必要になります。

上の比較で見える通り、Contextbergの強みは『memoryを持つagentを作る』ことではなく、『人間の作業環境で発生した文脈をagentに渡せる形で持つ』ことです。そのため、会話履歴だけでなく、ブラウザ履歴、スクリーンショット、アプリ利用、agent履歴を同じタイムラインで扱います。

つまり、Contextbergが広い信号を持つのは『何でもAIに投げる』ためではありません。あとから作業を説明できるだけの材料をローカルに残し、必要なときに必要な粒度へ整えて返すためです。この設計だから、現状でもagentmemory系を検討している読者に対して、ブラウザ調査と画面状態まで含めた別の答えを出せます。

AIエージェントの会話履歴は重要ですが、開発の判断は会話の前にかなり進んでいます。Stack Overflowを読む、GitHub Issueを追う、ログを見る、VS Codeで試して消す、ドキュメントを比較する。こうした前段はチャット履歴には残りません。

つまり、本当に必要なのはagent chat historyだけではなく、work contextです。どの画面を見て、どのページを読み、どのアプリで何をしていたかまで含めて初めて、次のエージェントが判断の背景を追えます。

今後は、AI agent memory、Claude Code memory、Codex MCP、MCP memory server、cross-agent memory、local-first AI memoryのような言葉が増えていくはずです。ただ、読者にとって大事なのは検索語そのものではなく、その裏にある困りごとです。

つまり、AIエージェントがコードを書く能力だけでなく、前回の作業、調査したページ、別agentで決めた方針、画面に出ていた状態をどれだけ思い出せるかが問われるようになります。Contextbergが扱いたいのは、この『作業を覚えているAI』のための個人コンテキスト層です。

よいAI memoryは、保存量ではなく再利用のしやすさで評価します。必要な場面で必要な粒度の情報が返るか、古くなった情報を消せるか、ユーザーが中身を確認できるか、秘密情報を除外できるかが重要です。

また、どのエージェントからでも使えるかも大きな差になります。Claude Codeだけに閉じたmemoryはClaude Codeでは便利ですが、CodexやCursorへ移った瞬間にまた説明し直しになります。複数エージェント時代には、memoryをエージェント側ではなくユーザーの作業環境側に置く発想が必要になります。

最後に、クラウド前提かローカルでも動くかです。memoryは通常のプロンプトよりも個人情報や業務情報を含みやすいので、local-first、OpenAI互換エンドポイント、OpenRouter、自前APIキー、ローカルLLMなどの選択肢があるかは導入判断に直結します。

AI memoryは一度入れると、日々の作業判断に影響します。だから、単に保存できるかではなく、どの粒度で、どの出口から、どれだけ安全に取り出せるかを見るべきです。