ZedのExternal Agentsに引き継がれないコンテキストを渡す方法 (2026)

Zedがスレッドをホストし、エージェントがそれ以外すべてを所有する

決定的な一文は、ドキュメントの最初の段落にあります。「ZedはAgent PanelとThreads Sidebarでスレッドをホストし、External Agentは通常、独自のランタイム、認証、モデル選択、ツール、およびネイティブ設定を所有します。」

これは明確なアーキテクチャ上の分割であり、ほぼすべての「想定外の挙動」を説明してくれます。パネルはZedのものです。会話リストもZedのものです。エージェントはACPを介して通信する別プロセスであり、独自のすべてを持ち込みます。

境界表はほとんどの質問に「状況による」と答えている

Zedは「Configuration Boundaries（設定の境界）」の表を公開しています。含みを持たせた表現も含めて、書かれている通りに読んでみましょう：

2つの行は明確に否定されています。Zed Agentプロファイルは適用されず、Zed SkillsはZed Skillsとしては適用されません。それ以外はすべて「通常は」「〜の場合がある」「エージェントによる」となっています。

これは単に曖昧にしているわけではありません。Zedはサードパーティのプロセスが設定ファイルをどう扱うかを保証できないため、あえて明言を避けているのです。しかしこれは、「私の指示は読み込まれるのか？」という問いに対する答えが、Zed側からは本当に分からないということを意味します。そのため、エージェントごとに確認する必要があります。

読み込まれるはずだと思う1つのファイルでさえ、含みを持たされている

Claude Agentのセクションにはこう書かれています。「CLAUDE.mdなどのClaude固有のファイルは、Claude Agentによって直接読み込まれる場合があります。」

「読み込まれる場合がある（May be）」であり、「読み込まれる（are）」ではありません。理由は同じアーキテクチャ上の問題です。エージェントは独自のランタイムを介して独自の設定を読み込むため、ファイルが検出されるかどうかは、そのエージェントがどのように起動され、何をワーキングディレクトリとみなしているかに依存します。これは、一般的にwhy agents ignore your instruction filesの背景にある問題と同類です。

認証情報とリモートプロジェクトがさらなるレイヤーを加える

「ローカルのキーチェーンに保存されたZedのLLMプロバイダーAPIキーは、自動的にExternal Agentの認証情報と同じになるわけではありません。」また、リモートワークについては「External Agentは、ローカル、リモート、または独自のサインインフローを介して認証情報を読み込む場合があります」とあります。

つまり、Zed Agent用に設定されたAnthropicのAPIキーは「自動的にClaude Agentを設定するわけではなく」、Cursorのサブスクリプションは「ZedのLLMプロバイダー設定を設定しません」。各エージェントは独自に認証を行います。

Zed Skillsが引き継がれると思い込む。 引き継がれません。表にそう明記されています。Zed Agent用に書かれたスキルは、外部エージェントのスレッドではZed Skillsとして利用できず、エージェントが独自の同等機能を持っているかどうかは「エージェントによります」。

Zed Agentプロファイルを設定し、それが外部エージェントを制限することを期待する。 プロファイルは「インテグレーションで別途指定がない限り適用されません」。特にツールの権限は、Zedの設定ではなくエージェント自体に依存するため、ここで確認する価値があります。

Zedで一度MCPを設定して終わりにする。 ZedのMCPサーバーは「ACP経由で転送される場合があり」、ネイティブのMCP設定も「エージェントによって読み込まれる場合があります」。2つの「場合がある」があるため、実用的なアプローチとしては、想定するのではなくテストすることです。これはMCP layer being stateless by designのバリエーションと言えます。

古いスレッドをインポートして、そのままシームレスに引き継げることを期待する。 Zedは設定済みの外部エージェントから既存のスレッドをインポートできます。これは実際の機能です。「ZedはACP経由で選択された各エージェントに接続し、履歴にまだ存在しないセッションを追加します」。しかし、得られるものに注意してください。「インポートされたスレッドはアーカイブされたエントリです。開いて復元し、中断したところから再開します」。そして、何がスキップされるかにも注意してください。「関連付けられたワーキングディレクトリがないセッションはスキップされます」。

ZedのExternal Agentsにはコンテキストがまったくないと結論づける。 否定的な行だけを読めばそう思ってしまうのも無理はありませんが、それは間違いです。各外部エージェントは、独自の指示システム、独自のメモリ（存在する場合）、独自のネイティブ設定を持ち込みます。重要なのは、それらがZedのものではなくエージェントのものであるということです。コンテキストは存在します。ただ、エディタから提供されていないだけです。

1つのエージェントに統一することで解決しようとする。 これは機能しますが、そもそもExternal Agentsを導入した理由を放棄することになります。この機能は、あるタスクにはClaude Agentのスレッドを立ち上げ、別のタスクにはCodexのスレッドを立ち上げる、といった使い分けをするために存在します。2つの指示レイヤーを維持する手間を避けるために1つのエージェントに絞り込むのは、柔軟性の対価を払いながらそれを使わないのと同じです。

同じ指示ファイルをすべてのエージェントの場所にコピーする。 誰でも思いつく回避策ですが、もって1ヶ月でしょう。やがて1つのコピーだけに修正が加えられ、他はそのままになり、同じエディタ内の2つのエージェントがあなたのコーディング規約について自信満々に食い違うことになります。それぞれが与えられたファイルを忠実に読み込んでいるため、エラーはどこにも表示されません。

ステップ1：推測するのではなく、境界をテストする

使用する外部エージェントごとに、表の曖昧な表現を鵜呑みにするのではなく、意図的なテストを1回実行してみましょう。

エージェントが読み込んでいると思われるファイルに、特徴的で無害な指示を書き込みます。特定のフォーマットの好みや、優先して使う無意味な変数名など、気づきやすいものなら何でも構いません。Agent Panelから外部エージェントのスレッドを開始し、その指示が反映されているかどうかが分かる質問を投げかけてみてください。

エージェント独自の指示ファイル、ネイティブのMCP設定、エージェントがネイティブにサポートしているスキルなど、各レイヤーで個別にこれを行います。最終的に、あなたの環境で実際に機能するもののエージェントごとの簡単な表ができあがります。これは、エージェントのインストール方法や起動方法に依存するため、Zedのドキュメントには書けない内容です。

その際、ワーキングディレクトリも確認してください。Zedのスレッドインポートは「関連付けられたワーキングディレクトリがないセッション」をスキップします。これは、このインテグレーションにおいてワーキングディレクトリが重要な役割を果たしている（そして指示ファイルの検出は通常、それに対する相対パスで行われる）という強いヒントになります。

ステップ2：各エージェント独自のレイヤーをネイティブに設定する

エージェントが何を読み込むかが分かったら、Zedではなく、そのエージェント側で設定を行います。

Claude Agentの場合、独自の認証（Claude Agentスレッドで /login を実行）とClaudeネイティブの設定を意味します。Codexの場合、「インストールされているバージョンや環境に応じて、ChatGPTログイン、Codex APIキー、OpenAI APIキー、またはCodexネイティブの設定」を意味します。Gemini CLIの場合、独自のGoogleまたはVertex AIサインイン。OpenCodeの場合、独自の認証、モデル選択、サブスクリプションの挙動。Poolsideの場合、pool login です。Zedはこれらすべてをエージェント所有のものとしてドキュメント化しており、エディタ側で一元管理しようとすることは、このアーキテクチャに逆らう最も手っ取り早い方法になってしまいます。

ACPエージェントを開発している場合や、レジストリにないエージェントを実行している場合、Custom Agentsのパスによって設定ファイルに agent_servers エントリが追加されますが、これにも同じ境界ルールが適用されます。

ステップ3：両方のエージェントが必要とする知識を、両方の外部に置く

ステップ1と2で、各エージェントは動作するようになります。しかし、同じプロジェクトを説明するN個の並行した指示レイヤー（エージェントごとに1つ）を維持管理しなければならないという問題が残ります。

これがマルチエージェントエディタの実際のコストであり、Zedのバグではありません。「External Agentが独自のネイティブ設定を所有する」という仕様の、ごく自然な結果です。N個のコピーを1つに統合できる唯一の方法は、どのエージェントも所有していないストレージを使用することです。

メモリーレイヤーがそれを実現します。これはZedの設定でもエージェントの設定でもないため、境界表のどの行が適用されるかを気にする必要はありません。MemoryLakeは3つのステップでセットアップできます。

ステップ1：APIキーを作成する

サインインし、ダッシュボードからAPIキーを生成します。この認証情報はエージェントではなくあなたのものであるため、Zedのドキュメントにあるような認証の断片化（Zedのキーチェーンキー、Claude Agentの認証、Codexの認証がすべてバラバラであること）を回避できます。これはそれらすべてから独立しています。

ステップ2：最初の記憶（メモリー）をアップロードする

これまで重複して作成していたプロジェクトの知識（コーディング規約、アーキテクチャの決定とその理由、ドメイン用語、新しいスレッドを立ち上げるたびに繰り返し伝える恒常的な好みなど）を登録します。2つの異なるエージェントの指示ファイルに書き込んだ内容はすべて、その候補になります。

各エージェントに本当に固有の設定は、それぞれの場所に残しておきます。これは事実（ナレッジ）のためのものであり、連携設定のためのものではありません。

ステップ3：AIとエージェントを接続する

各エージェントをこのストアに向けます。タスクの途中でClaude AgentのスレッドからCodexのスレッドに切り替えても、プロジェクトを一から説明し直す必要がなくなります。これこそが、Agent Panelが容易にし、境界がコストを高くしていた部分です。

最初の変化は、エージェントの切り替えコストが非常に低くなることです。Zedの最大の売りは、スレッドごとに最適なエージェントを選択できる点にあります。しかし、それが活きるのは、スレッドを切り替えてもコンテキストを再構築する必要がない場合だけです。現状では、通常は再構築が必要になってしまいます。

2つ目は、境界表が「想定外の挙動」の原因ではなくなることです。永続的な知識が外部に存在する場合、含みを持たせた行の重要性は大幅に低下します。認証やツールの権限は依然として重要ですが、特定の指示ファイルが読み込まれるかどうかを気にする必要はなくなります。なぜなら、事実（ナレッジ）はそこにはないからです。

3つ目は、スレッドのインポートが本当に便利になることです。インポートされたスレッドはアーカイブされたエントリとして届き、開いて再開できます。プロジェクトの知識が共有レイヤーにある場合、古いスレッドを再開する際に、元のコンテキストがどれだけ会話履歴に残っていたかに依存しなくなります。これは、共有レイヤーが一般的なcross-agent memory（エージェント間メモリ）に役立つ理由と同じです。

• 境界表は仕様書ではなく、チェックリストとして扱う。 2つの行は明確に否定されています。残りは、テストによって確認するエージェントごとの事実です。
• 認証はエージェントごとに設定し、共有されないものと考える。 ZedのキーチェーンキーはClaude Agentを設定しません。CursorのサブスクリプションはZedのプロバイダー設定を設定しません。
• Zed Skillsを移植しようとしない。 外部スレッドではZed Skillsとして適用されません。代わりに、エージェントがネイティブの同等機能を持っているか確認してください。
• MCP転送は想定するのではなく、検証する。 ZedのMCPサーバーはACP経由で転送される場合があり、ネイティブ設定も読み込まれる場合があります。2つの「場合がある」に対して、1回のテストを行う価値があります。
• ワーキングディレクトリに注意する。 ワーキングディレクトリがないセッションはインポート時にスキップされます。また、指示ファイルの検出は一般的にこれに依存します。
• インポートされたスレッドはアーカイブとして扱う。 開いて復元します。履歴にすでに存在するスレッドはスキップされるため、再インポートは安全です。
• プロジェクト知識の信頼できる唯一の情報源（Single Source of Truth）を維持する。 もしある段落が CLAUDE.md と Codexの指示ファイルの両方に存在する場合、それはどちらのファイルにも置くべきではありません。
• アップデート後に再テストする。 Codex'sの認証オプションは「インストールされているバージョンや環境に応じて」異なるため、これらの境界線が変化する可能性が高いことを示しています。

ZedのExternal Agentsのドキュメントが異例なほど信頼できるのは、過剰な約束を拒んでいるからです。「通常は」「〜の場合がある」「エージェントによる」が正しい回答であり、そうでないふりをすることは、後で想定外のトラブルを発生させるだけです。

実用的な解釈としては、各エージェントにその連携設定を所有させ、エディタ側で一元管理しようとするのをやめ、本当に共有すべき唯一のもの（チームがプロジェクトについて知っていること）をエージェントから完全に切り離すことです。