ZedのAgentが忘れる理由
すべてのスレッドは独自のコンテキストから始まる
Agent Panelは、複数の並行Agentスレッドに加えて、CLIやTUI作業用のTerminalスレッドをサポートしており、それぞれが独立したコンテキストと履歴を持っています。この独立性こそが並行Agentを実用的なものにしている一方で、あるスレッドで確立した内容は次のスレッドからは一切見えないことを意味します。以前のスレッドを明示的に@メンションしたり、「New From Summary（要約から新規作成）」を使って現在の会話の要約を新しいスレッドに引き継ぐことはできますが、どちらも手動で行う必要があり、忘れないようにしなければなりません。
コンパクション（圧縮）は容量を管理するものであり、知識を管理するものではない
Zedは、長いAgentスレッドが設定されたトークンしきい値に近づくと、自動的にスレッドをコンパクション（圧縮）し、以前のメッセージを要約して、確認可能な「Context Compacted」というエントリを残します。/compactを実行すればオンデマンドで圧縮でき、agent.auto_compactでその挙動を制御できます。これは長いセッションにおける優れたエンジニアリングであり、メモリと混同しがちです。しかし、コンパクションはすでにスレッド内にあるものを短縮するだけです。スレッドの外に何かを移動させるわけではなく、要約はスレッドの終了とともに消滅します。
.rulesは指示であり、蓄積ではない
Zedはワークツリーのルートからプロジェクトのルールファイルを読み込み、すべてのAgent Panelのやり取りに自動的に含めます。ファイル名の優先順位リスト（.rules、.cursorrules、.windsurfrules、.clinerules、.github/copilot-instructions.md、AGENT.md、AGENTS.md、CLAUDE.md、GEMINI.md）をチェックし、最初に一致したものを使用します。これは本当に便利であり、新しいスレッドでも開発の規約が維持される理由です。
しかし、ルールファイルはあなたが書くものであり、Agentが書き込むものではありません。Agentが午後4時に発見したことが、午後5時にそこに反映されることはありません。放置すれば古くなり、熱心にメンテナンスすれば、やり取りのたびにトークンを消費し、本当に重要な10個の事実を埋もれさせてしまうテキストの壁になってしまいます。
Zedにおけるメモリは自分で構成するもの
Zedはcontext_serversの下でMCPサーバーをサポートしています。これらは拡張機能としてインストールするか、コマンド引数やURL、オプションの認証ヘッダーを使用してローカルまたはリモートサーバーとして直接設定でき、MCPのツールやプロンプトをAgentに公開します。権限はagent.tool_permissions.defaultによって管理されます。これが公式に推奨されている永続化への道です。メモリサーバーを接続すれば、Agentはスレッドの寿命を超える知識を読み書きできるようになります。最初から接続されているものは何もありません。
Zedユーザーが最初に試すこと
以前のスレッドを@メンションする
どのスレッドに答えがあったかを覚えているときは、正確で便利です。しかし、スレッドが30個になり、リトライに関する決定がどのスレッドに含まれていたか分からなくなった瞬間に、スケールしなくなります。
New From Summary（要約から新規作成）
ゼロから始めるよりはマシですが、本質的に情報の欠落を伴う引き継ぎです。要約は会話の大枠を維持しますが、結果的に重要となる詳細（ワークアラウンドが存在する正確な理由や、挙動が変更されたバージョンなど）を削ぎ落としてしまいます。
より大きな.rulesファイル
最も一般的な解決策ですが、明確な限界があります。やり取りのたびにファイル全体のトークンコストが発生し、更新は人間の規律に依存し、時間的な制約を持つ情報を表現できません。これはナレッジベースのふりをしたブリーフィング文書に過ぎません。これは、why Claude Code forgets project context（Claude Codeがプロジェクトのコンテキストを忘れる理由）で説明されているのと同じ限界です。
リポジトリ内のスクラッチパッド用Markdownファイル
チームでnotes.mdを管理し、それを@メンションします。これはしばらくの間は驚くほど機能しますが、やがて誰も整理しない追記専用のログと化し、矛盾するエントリが存在し、どれが最新なのか分からなくなります。
解決策：永続メモリサーバーをZedに組み込む
ZedはMCP経由でメモリが提供されることを想定しているため、スマートな解決策は、ファイルのふりをしたものではなく、そのタスク専用に構築されたメモリレイヤーを提供することです。MemoryLakeは、アーキテクチャ、決定事項、規約を一度保存すれば、すべてのスレッド（および使用する他のすべてのAgent）が同じソースから読み取れるようになります。
ステップ1：APIキーを作成する
キーを生成し、約30秒で最初のリクエストを実行します。
ステップ2：最初のメモリをアップロードする
プロジェクトの真のコンテキストを保持するドキュメント、画像、ファイルを投入します。アーキテクチャのメモ、ADR（アーキテクチャ決定記録）、ランブック、API仕様、インシデント報告書、そしてスレッドが何度も再導出しがちな決定事項などです。
ステップ3：AIとAgentを接続する
Claude、Codex、OpenClaw、およびその他のAgentに、MCPまたはAPIを介してそのメモリへのアクセス権を付与します。Zedの場合は、他のMCPエントリと並んでコンテキストサーバーとして設定し、チームの好みに合わせてツールの権限を設定します。これにより、新しいAgentスレッドは空の状態ではなく、すでにプロジェクトを理解した状態で開くようになります。ターミナルでも作業する場合は、adding memory to Claude Code（Claude Codeにメモリを追加する）やsetting up cross-AI memory with MCP（MCPでAI間メモリを設定する）で、他のクライアントから同じレイヤーをカバーする方法を説明しています。
実際に何が変わるのか
並行Agentを使用すると、忘却のコストが倍増します。コンテキストを再構築するのに、スレッドあたり例えば1,500トークンと2分かかるとします。1日に6つのスレッドを実行すると、毎日9,000トークンと12分が前置き（前提条件の説明）に費やされることになります。これは、コードを書き始める前に、月に約270,000トークンを消費している計算になります。大きな.rulesファイルはこのコストを削減するのではなく、無条件のものにします。そのうちの2行しか必要としないスレッドも含め、すべてのスレッドでファイル全体のコストを支払うことになるからです。
行動面での違いはさらに大きくなります。スレッドがメモリを共有している場合、スレッド2はスレッド1が発見したマイグレーションの順序制約を把握しているため、それを「親切に修正」してしまうようなことはありません。これは、multi-agent memory（マルチエージェントメモリ）と同じ種類の問題であり、それが1つのエディタ内で発生しているだけです。並行Agentを実行しているチームが、他の誰よりも早くこの問題に直面するのはそのためです。
ZedのAgentメモリに関するベストプラクティス
指示と知識を分離する
.rulesは、スタイル、レビューの期待値、禁止されたパスなど、Agentがどのように動作すべきかのために残しておき、システムに関する事実はメモリに保持します。ルールは毎回読み込む価値があるほど短く保たれ、知識はすべてのやり取りに負担をかけることなく増やすことができます。
スレッドの開始時ではなく、終了時にメモリを書き込む
長いスレッドの価値ある出力は、通常「何が決定され、なぜそうなったのか」という1〜2文です。スレッドを閉じる際にそれを保存することを習慣にしましょう。そうしないと、次のスレッドがそれを再発見するためにコストを支払うことになります。コンパクションはこれを代行してくれません。スレッド内で要約するだけで、スレッドとともに消えてしまうからです。
エントリを整理し、日付を記録する
決定がいつ下されたかを記録し、新しい事実を古い事実の横に積み重ねるのではなく、置き換えられた事実を更新します。Agentは読み取った内容を信頼するため、古いエントリは存在しないエントリよりも害を及ぼします。これは、スクラッチパッドが矛盾ログに変わるのを防ぐのと同じ規律です。
結論
ZedのAgentがプロジェクトのコンテキストを忘れるのは、スレッドが設計上隔離されていること、コンパクションがスレッドの枠を超えずに内部で動作すること、.rulesが静的な指示ファイルであること、そしてメモリが最初から同梱されているものではなく、MCPを介して明示的に接続するものであるためです。これらは、並行Agentを備えた高速なエディタにおける欠陥ではなく、役割分担です。
この役割分担は、あなたが自分の役割を果たして初めて機能します。アーキテクチャ、決定事項、規約をメモリレイヤーに配置し、それをコンテキストサーバーとして接続すれば、Zedを選んだ理由である「スピード」が、前のスレッドがすでに知っていたことを再説明するために浪費されることはなくなります。