n8nエージェントが忘れてしまう理由
Simple Memoryは窓であり、その窓は小さい
Simple Memoryノードの Context Window Length 設定は、含める過去のやり取りの数であり、デフォルトは 5 です。1回のやり取りとは、ユーザーのメッセージとエージェントの返信の1往復を指すため、デフォルトではおおむね過去10メッセージが保持されます。それより古いものは、エラーを出すことなく静かにウィンドウから消え去ります。エージェントは単に同じ会話の初期の内容を参照しなくなるだけなので、長いチャットは突然壊れるのではなく、徐々に質が低下していきます。
ワークフローデータ内に存在するため、存続しない
Simple Memoryは、セッションキーのもとでワークフロー自体のデータ内にチャット履歴を保存します。これはエディタ内では便利ですが、それ以外の場所では非常に脆弱です。履歴はインスタンスの動作状態に紐づいているため、再起動や再デプロイを行うと消失します。これは「開発環境では動くが、デプロイするとすべて忘れてしまう」という典型的な報告の原因であり、本番公開前に Postgres や Redis のチャットメモリに移行すべきという標準的なアドバイスが存在するのも、まさにこのためです。
キューモードでは完全に機能しなくなる
n8nのドキュメントには、この制限がはっきりと記載されています。インスタンスがキューモード（queue mode）を使用している場合、メモリの呼び出しが同じワーカーにルーティングされる保証がないため、このノードはアクティブな本番ワークフローでは動作しません。n8nを水平スケールした後に、なぜメモリの挙動が不安定（覚えている時もあれば、忘れている時もある）になったのか疑問に思っていたなら、それが原因です。リクエストが異なるワーカーに到達し、それぞれのワーカーが異なる会話内容を保持しているためです。
セッションキーが「誰が何を覚えているか」を決定する
メモリはセッションキーごとにグループ化されます。Chat Triggerを使用する場合、n8nは受信した sessionId からこれを自動入力します。これは通常、意図通りの挙動です。しかし、よくある2つの設定ミスにより、それぞれ対極の不具合が発生します：
- 静的なキーをハードコードしている場合：すべてのユーザーが1つのメモリを共有することになり、エージェントは会話を混同し、ユーザー間でコンテキストが漏洩します。
- 実行ごとにキーが変わる場合：すべてのメッセージが新しい会話として開始されるため、技術的にはメモリが動作していても、エージェントは記憶喪失のように見えます。
メモリのスコープはエージェントノードごと、ワークフローごと
メモリノードは1つの AI Agent ノードに接続されます。自動化全体で共有されるストアではありません。ワークフローAのサポートエージェントは、同じ顧客であっても、ワークフローBのオンボーディングエージェントが昨日出した結論について何も知りません。また、両方を規定するSOPにチームが何を書いたかも知りません。複数のエージェントを実行している場合、その断片化はさらに深刻になります。この一般的な問題については、multi-agent memoryで解説しています。
開発チームが最初に試すこと
Context Window Lengthを増やす
最も手軽な手段であり、一時的には効果があります。しかし、呼び出しのたびに保持されたすべてのメッセージのトークンコストが発生し、ウィンドウには依然として上限があり、揮発性も変わりません。忘れるタイミングを遅らせただけで、根本的な解決にはなっていません。
PostgresやRedisのチャットメモリへの切り替え
これは本番環境における正しいアプローチであり、移行すべきです。これにより、履歴は再起動後も存続し、キューモードでも動作します。ただし、それによって何が得られるかを明確に理解しておく必要があります。これはセッションをキーとする永続的な会話ログ（トランスクリプト）のストアであり、「入力された内容」を保持するものであって、「組織が知っていること」を保持するものではありません。製品ドキュメント、価格設定ルール、前四半期の決定事項、あるいはこの顧客が 3 月に起票したチケットの解決策などは含まれていません。そのセッションのメッセージ以外のことを尋ねても、何も答えられません。
システムプロンプトにコンテキストを詰め込む
ポリシー、トーンガイド、FAQなどをエージェントのシステムメッセージに貼り付ける方法です。実行するたびにそれらのトークン費用が発生し、テキストはすぐに古くなり、更新するにはワークフローを1つずつ編集する必要があります。これは、自動化においてre-explaining context to your AI（AIにコンテキストを何度も説明し直すこと）を永遠に繰り返すようなものです。
自前で検索（Retrieval）を構築する
次のステップとして、ベクトルストア、埋め込み（Embedding）パイプライン、そして検索用のサブワークフローを組み合わせることがよく行われます。これは機能しますが、チャンク分割、埋め込みの更新、ランキング、スコープ管理、有効期限の設定など、本格的な開発プロジェクトになります。また、これだけではメモリの問題は解決しません。その理由はwhy RAG isn't memoryで詳しく説明していますが、検索（RAG）はドキュメントを見つけるものであり、メモリは結論を保持するものだからです。
解決策：n8nエージェントに永続的なメモリレイヤーを提供する
チャットメモリと「メモリ（記憶）」は異なる役割を持ちます。セッション内の会話の継続性には Postgres や Redis のメモリノードを使用し、永続的な知識はワークフロー、ワーカー、またはセッションキーに依存しないレイヤーに配置します。それが MemoryLake の役割です。エージェントが読み書きできる単一のメモリであり、構築する任意のワークフローから MCP または API を介してアクセスできます。
ステップ 1: APIキーを作成する
キーを生成すれば、約 30 秒で最初のリクエストを送信できます。
ステップ 2: 最初のメモリをアップロードする
製品ドキュメント、SOP、価格設定やポリシーのルール、エスカレーションパス、過去の解決策など、エージェントが常に必要とするドキュメント、画像、ファイルをアップロードします。これらは、チャットバッファに置くべきではない知識です。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、そして n8n エージェントに、MCP または API を介してそのメモリへのアクセス権を付与します。ツールがサポートしている場合は MCP 接続を、そうでない場合はワークフロー自体からシンプルな HTTP リクエストを使用します。どのワーカーでの実行であっても、同じメモリにアクセスできます。独自ツールをエージェントに公開している場合は、adding memory to a custom MCP serverやmemory for stateless MCP serversが参考になります。
導入によって実際に変わること
現在のワークフローがどれだけ同じ内容を繰り返しているか計算してみてください。各実行に 1,500 トークンの貼り付けられたポリシーや製品コンテキストが含まれており、ワークフローが1日に 500 回実行される場合、毎日 750,000 トークン（月に約 22M トークン）が、決して変わることのないテキストの再送信に消費されていることになります。メモリレイヤーから関連する部分だけを検索すれば、通常はその数分の一のコストで済みます。
さらに大きなメリットは、エージェントの振る舞いです。顧客の過去のチケットを参照できるサポートエージェントは、アカウントIDを何度も聞き直すことをやめます。サポートエージェントと同じメモリを読み込むオンボーディングエージェントは、矛盾した案内をしなくなります。そして、来四半期にワークフローを再構築する際にも、知識は削除された古いバージョンに閉じ込められることなく、そのまま維持されます。
n8nエージェントメモリのベストプラクティス
会話ログと知識を別々に管理する
現在の会話の直近数回のやり取りにはチャットメモリノードを使用します。明日になっても変わらず正しい情報であるべきものには、メモリレイヤーを使用します。これらを混同すると、読み込むには大きすぎ、役に立つには浅すぎるデータストアになってしまいます。
実行ではなく、エンティティをキーにしてメモリを管理する
セッションキーは会話のためのものです。永続的なメモリは、顧客、プロジェクト、アカウントなど、ワークフローや月日を超えて同じ意味を持つものをキーにする必要があります。これにより、2つ目のワークフローが、1つ目のワークフローが終了した時点からシームレスに処理を引き継ぐことができます。
実行の最後に結論を書き戻す
実行が決定した内容（解決策、認められた例外、ユーザーが表明した好みなど）を保存する最終ステップを追加します。メモリを読み取るだけのエージェントは賢くなりませんが、メモリに書き込むエージェントは知識を蓄積していきます。書き込みは短く事実のみにとどめ、古い事実の上に新しい事実を積み重ねるのではなく、古い事実を置き換えるようにしてください。
まとめ
あなたの n8n エージェントは壊れているわけではありません。Simple Memory は、ドキュメント通りに動作しているだけです。つまり、ワークフローデータ内に直近のわずかなやり取りを保持しているため、再起動時に消失し、本番環境のキューモードでは動作しません。Postgres や Redis への移行は会話ログの永続性を解決しますが、より大きな課題は残されたままです。なぜなら、1つのセッションの会話ログは、ビジネスを理解していることとは根本的に異なるからです。
2つの役割を切り離しましょう。会話の継続性はチャットメモリノードに任せ、組織の知識はワークフローが MCP または API を介して読み取るメモリレイヤーに配置します。そうすれば、次に構築するエージェントは、5往復分の浅い空白のウィンドウから始めるのではなく、前のエージェントが学んだすべての知識を持った状態でスタートできます。