なぜエージェントは「言ったこと」を知っていて「行ったこと」を知らないのか
記憶製品は会話の書き起こし（トランスクリプト）に基づいて構築されている
お使いのツールにおいて、記憶がどこから来ているかを見てみましょう。ChatGPTの記憶はチャットから派生しています。Claudeの記憶は会話から派生しています。Codexは過去のチャットから記憶を生成します。そのドキュメントでは、保持されるものを「要約、永続的なエントリ、最近の入力、および過去のチャットからの裏付けとなる証拠」と説明しています。コーディングエージェントは、あなたが作成したファイルを読み込みます。
これらはすべて、あなたがモデルのために生成した言語の下流にあります。これは本物であり、有用な種類の記憶です。心理学者が「意味記憶」または「宣言的記憶」と呼ぶもの（事実、好み、永続的なルール）にほぼ相当します。しかし、それはイベントの記録、つまり、どのアプリケーションで、どの順番で、どれだけの時間、実際に何を行ったかという一連のプロセスではありません。
「行う」側の半分には、自然なキャプチャポイントがない
チャットに好みを入力する場合、キャプチャは無料です。テキストがすでに存在しているからです。しかし、管理パネルをクリックしたり、2つのスプレッドシートを照合したり、支払いを承認する前にダッシュボードを確認したりする作業中には、エージェントがアクセスできる場所には何も書き残されません。
これが、欠落している半分が欠落したままになっている理由です。ベンダーがそれを望んでいないわけではありません。それを収集するには画面をキャプチャする必要があり、それは同意、ストレージ、セキュリティの要件がまったく異なる、完全に別の製品になるからです。また、これがギャップが解消されない理由でもあります。モデルが向上したからといって、その副産物としてこのギャップが埋まることはありません。
モデルがアクティビティを要約すると、証拠も一緒に失われる
画面キャプチャを記憶に変換する明白な方法は、モデルに画面を監視させ、要約を作成させることです。8月6日のプレプリント『Activity Frames: Deterministic Screen-Activity Compilation for Agent Memory and Replay』（Nossa Iyamu, arXiv 2608.05784）は、その逆を主張し、その違いを測定しています。
そのパイプラインはモデルを一切使用しません。ローカルのキャプチャストリームを「型定義されたアクティビティフレーム、つまりアプリケーション、サイト、タイミング、入力ボリューム、および生の行への証拠ポインタを保持する境界のあるエピソード。ループ内にモデルが存在しないため、出力はバイト単位で同一であり、キャッシュ可能で、機械的に監査可能」に分割します。51日間のアクティブな日数にわたる著者の128,756フレームのコーパスにおいて、1日分の生キャプチャをコンパイルすると、プロンプト対応のコンテキストブロックが68ミリ秒で86倍小さく生成され、そのブロックを読み取ったエージェントは、独立したオラクルに対して98.4%の精度（Wilson 95%信頼区間 91.7–99.7%）でその日に関する質問に回答しました。「同じキャプチャのLLM要約では66〜80%であったのに対し」です。
見出しよりも重要な2つの注意点があります。これはプレプリントであり、査読済みの論文ではありません。また、コーパスは1人の専門家の個人データであり、この数値はそのセットアップにおけるもので、あなたのチームにそのまま当てはまるわけではありません。さらに、66〜80%という数値は、同じキャプチャストリームの言語モデル要約に対する論文独自の比較であり、実際に提供されている製品の測定値ではありません。
これらの注意点を超えて残るものは、構造的なポイントであり、これはドキュメント処理を機能させるものと同じです。要約は、それを生成したものへのポインタを持たない、情報の失われた成果物（ロスのあるアーティファクト）です。フレームは証拠ポインタを保持します。それらを検証することができます。
アクティビティがキャプチャされる場合、それは正確に1つのツールに格納される
OpenAIはすでにこのカテゴリを提供しています。macOS上のChatGPT Proサブスクライバー向けのオプトインの研究プレビューとしてドキュメント化されているChronicleは、最近の画面アクティビティからCodexの記憶を構築します。そのドキュメントは驚くほど具体的です。画面キャプチャはローカルの一時ディレクトリに保存され、6時間後に削除されます。生成される記憶は「必要に応じて読み取りや変更が可能な、暗号化されていないMarkdownファイル」であり、Codexのホームディレクトリに保存されます。これらを生成するために、「スクリーンショットフレーム、スクリーンショットから抽出されたOCRテキスト、タイミング情報、およびローカルファイルパス」がOpenAI'sのサーバーで処理されます。OpenAIはまた、バックグラウンドエージェントが「レート制限を急速に消費する」こと、およびChronicleを使用すると「画面コンテンツからのプロンプトインジェクション攻撃のリスクが高まる」ことを明言しています。
これは、ベンダーが難しい機能について誠実である例であり、設計の選択肢は擁護できます。しかし、出力がどこに格納されるかに注目してください。それはCodexのローカルメモリストア、つまり1台のマシン上にあり、Codexからのみ読み取り可能です。論文に付随するオープンソースプロジェクトは、これと鏡写しの選択をしています。ローカルのSQLiteデータベースにキャプチャし、ローカルでコンパイルし、MCP経由で提供します。その出力も同様に、キャプチャを行ったマシン上に存在します。
したがって、今日の最善のケースであっても、あなたが行ったことの記録は、1台のラップトップ上の1つのクライアントからしか読み取れません。一方で、あなたが実際に火曜日の午前中について尋ねるアシスタントは、別のものかもしれません。
人々が試みること
ルーティンを再説明する。 デフォルトの方法です。11のステップを説明し、エージェントはまずまずの仕事をこなしますが、翌週にはまた同じ説明を繰り返すことになります。この論文の動機全体は、このコストにあります。エージェントは「ユーザーがすでに実行したルーティンを再導出するために、最先端モデルのフル推論コストを支払っている」のです。
エージェントに成果物（アーティファクト）を指し示す。 Gitのログ、チケットの履歴、ブラウザの履歴、エクスポートされたレポートなどです。本当に便利で、最も安価で近い近似値ですが、成果物は「結果」を記録するものであり、「プロセス（シーケンス）」を記録するものではありません。コミットは「何が変更されたか」を伝えますが、その前に行われた20分間の確認作業については教えてくれません。
汎用画面レコーダー。 Rewindスタイルのツールや、より新しいローカルファーストのレコーダーは、あなたのために検索可能な履歴を作成します。現在、一部のツールはこれをエージェントに公開しています。試す価値はありますが、それぞれに対して問いかけるべき質問は同じです。「出力には生のキャプチャへのポインタが含まれているか、それともあなたの午後の活動に対するモデルの主観的な印象にすぎないか？」
Chronicle。 MacのProサブスクライバーで、主な作業がCodex内で行われる場合、これが「行う」側の半分に到達する最短の道です。有効にする前に、レート制限とプロンプトインジェクションに関するドキュメントを読む必要があります。その適用範囲はCodexに限定されています。
事後に自分でランブック（手順書）を書く。 最も再現性の高いオプションですが、誰も継続できません。これが、自動キャプチャが試みられ続ける本当の理由です。
リスト全体の共通点に注目してください。記録が収集されていないか、あるいは1つのツールしか読み取れない場所に収集されているかのどちらかです。
解決策：両方の半分がアクセスできる1つの場所に記録を保管する
2つの事実があり、これらはしばしば混同されます。エピソードのキャプチャは「キャプチャの問題」です。あなたの同意のもとで何かを監視する必要があり、メモリレイヤーがそれを変えることはありません。その後、記録がどうなるかは「ストレージとアクセスの問題」であり、今日、価値の大部分が漏洩しているのはここです。
したがって、作業を明確に分けましょう。「行う」側の半分が必要な場合は、キャプチャツールを選択し、そのプライバシーに関するドキュメントを適切に確認してください。そして、そのコンパイルされた出力（および、すでに持っている宣言的な半分、仕様、決定事項、制約事項）が、1つのクライアントのローカルディレクトリやチャットの書き起こしの中ではなく、使用するすべての助手（アシスタント）が読み取れる場所に存在することを確認してください。
MemoryLakeは、その2番目のタスクのためのメモリレイヤーです。ドキュメント、決定事項、コンパイルされた記録が保存される1つのストアであり、ClaudeやCodexなどのMCP対応ツールから直接、またChatGPTからはAPIを介して読み取ることができます。そうではない点について正確に言うと、MemoryLakeは画面を監視しません。エピソード履歴が必要な場合、キャプチャツールの代わりにはなりません。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを送信します。チャットウィンドウに貼り付けるのではなく、環境変数やシークレットマネージャーに保管してください。
ステップ 2: 最初の記憶をアップロードする
現在再説明しているドキュメント、画像、ファイルを投入します（ランブック、仕様、制約事項、決定記録、エクスポートされたレポートなど）。コンパイルされたMarkdownや構造化された出力を生成するキャプチャツールを実行している場合、その出力もここに属します。要約の要約としてではなく、生成されたままの状態でアップロードしてください。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、およびその他のAIエージェントに、MCPまたはAPIを介してメモリへのアクセス権を付与します。ChatGPTにはMCPクライアントがないため、APIを介して必要な情報を取得し、プロンプトまたはモデルを呼び出すワークフローに注入します。このステップのポイントは、同じ記録が複数のツールに対応できる点にあります。これは、ローカルのキャプチャストアが単独では行えない部分です。
これが実務で何を変えるか
最初の違いは、コストのかかる半分が再導出されなくなることです。ルーティンの記録がキャプチャツールから得られたものであれ、あなたが一度10分かけて書き留めたものであれ、それを読み取るエージェントは、再構築するのではなく、実際に起こったことから開始します。論文のデモンストレーションはこれの極端なバージョンです。コンパイルされたルーティンは「モデルをループから外して決定論的に再生」され、モデルトークンはゼロです。
2つ目は、出所（プロベナンス）が維持されることです。これは、AIシステムが自信満々に何かを語るときに常に現れる議論と同じです。有用な記録は、測定されたものと推論されたものを区別します。その区別こそが要約によって破壊されるものであり、あなたに関するもっともらしい事実を捏造するAIシステムを見破るのが非常に難しい理由です。推論と観察が、同じ確信度で同じ文の中に現れるからです。
3つ目は、記録がそれを作成したツールよりも長生きすることです。キャプチャストアは設計上、マシンローカルです。共有レイヤーを導入することで、今四半期に蓄積したメモは、エディタを切り替えたり、ラップトップを変更したり、2つ目のエージェントを追加したりした後でもそのまま残ります。そして、複数のツールからアクセス可能な1つのメモリは、単一のクライアントのメモリ機能とは異なる特性を持ちます。
また、すでに実行しているものと連携します。Codexのメモリ、Claude Codeのプロジェクトメモリ、ChatGPTの保存されたメモリは、引き続きローカルでの役割を果たします。それらにできないのは、お互いのメモリを読み取ることです。これこそが、マルチエージェントのセットアップが引き継ぎのたびにコンテキストを失う最大の理由です。
エピソード記憶のベストプラクティス
何かを有効にする前に、何をキャプチャするかを決める
画面キャプチャは中立的なデフォルトではありません。ストレージと保持に関する詳細を読み、何がマシンから送信されるかを確認し、クライアントの業務、資格情報、または規制対象のデータが日中に画面に表示されるかどうかを考慮してください。画面コンテンツからのプロンプトインジェクションに関するChronicle独自のドキュメントの警告は、二度読みする価値のある一文です。あなたがアクセスしたページに、エージェントが従うべき指示が含まれている可能性があります。
何かを指し示すポインタを持つ記録を優先する
証拠ポインタを持つフレームであれ、ファイルパスを引用するランブックであれ、それを余儀なくさせたインシデントを引用する決定記録であれ、検証可能な記憶は、検証不可能な複数の記憶よりも価値があります。要約は、何かが実際に起こったかどうかを知る必要があるその瞬間までは、効率的に感じられるものです。
2つの半分を分離しつつ、隣接させておく
決定したことと行ったことは異なる記録であり、1つのナラティブに統合すべきではありません。両方を保存し、どちらがどちらであるかをラベル付けし、質問が必要とする方を検索で取得できるようにします。これらを一緒に圧縮してしまうと、「最初にダッシュボードを確認した」が「ダッシュボードの確認を好む」に変わってしまいます。
ルーティンをキャプチャストアだけに存在させない
ルーティンが自動化するほど重要であるなら、短いバージョンをドキュメントとしても書き留めておきましょう。キャプチャストアはマシンローカルであり、オプトインであり、時には研究プレビューです。共有ストアにある5行のランブックは、これら3つの事実すべてを乗り越えて存続し、新しいチームメンバーが読むこともできます。
「エージェントはすでにこれを知っている」を検証すべき主張として扱う
ここでの失敗モードは静かに進行します。エピソード記録を持たないエージェントは、それを公表しません。あなたのワークフローのもっともらしいバージョンを作成します。手続き的な作業を委任する前に、ステップを説明させ、どこにも書き留めていないステップがないか特に注意して確認してください。
結論
エピソード記憶は、まだ誰も構築を完了していないエージェントメモリの半分です。今日の機能は会話の書き起こしに基づいて構築されているため、言ったことを保持し、行ったことは保持しません。これは論文自体のフレームワークであり、その存在理由でもあります。「行う」側の半分に対する2つの実用的な試みは、どちらも画面をキャプチャすることで機能し、どちらも結果を1台のマシン上の1つのツールに残します。OpenAIのChronicleはCodexのローカルメモリストアに、オープンソースのコンパイラはMCP経由で提供されるローカルデータベースに保存します。
実用的な教訓は、待つことではありません。プライバシーのトレードオフが許容できる場合はキャプチャを有効にし、証拠ポインタを保持しないモデルの要約よりも、それを保持する記録を優先し、蓄積するすべてのもの（コンパイルされたアクティビティ、および画面にまったく表示されなかった仕様や決定事項）が、複数のアシスタントが読み取れる場所に格納されるようにしてください。記録は、それを作成したツールよりも価値があります。