Zed Agent Panelをチームで使う前に：MCP・Tool Permissions・Parallel Agentsを分ける基準

3行まとめ

Agent Panel

AI作業の入口にする。

Tools

confirm、allow、denyを決める。

MCP

serverとtool単位で絞る。

Parallel

taskごとにthreadを分ける。

ZedはAI機能が広いため、設定を境界ごとに見ると運用しやすくなります。

• Zed Agent Panelは、first-party agent、MCP servers、external agents、parallel threadsをeditor内で扱えるAI作業の入口です。
• チーム導入では、agent.tool_permissions.default、MCP serverの追加方法、per-tool permission、external agentごとのACP対応、parallel taskのreview単位を分けて決めます。
• 最初はtool actionをconfirm基準にし、MCPは1 serverずつ追加し、parallel agentsは同じfileを同時に触らせない運用から始める方が扱いやすいです。

本文の事実確認には、Zed公式docsのAgent Panel、Agent Settings、MCP、Tools、External Agents、Parallel Agents、AI Improvementを使っています。Xで見かけるZed Agent、MCP、parallel agents、Claude/Codex連携への投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Permission

defaultのtool approvalを決める。

Server

extensionとcustom serverを分ける。

ACP

外部agentへのMCP共有を確認する。

Review

parallel taskの差分を分ける。

ZedではMCPを増やす前に、tool approvalとreview単位を決めます。

• Zed Agent Panelをチームで使う時に最初に分ける運用境界
• agent.tool_permissions.defaultをどう決めるか
• MCP serversをextensionとcustom serverでどう分けるか
• MCP toolをper-tool permissionで絞る考え方
• Claude Agent、Codex、Gemini CLIなどexternal agentsをZedで使う時の注意
• Parallel Agentsをtask単位で分ける運用

Zedは、速いeditorとしてだけでなく、AI code editorとしての機能も増えています。Agent Panel、built-in tools、MCP、external agents、parallel agentsを組み合わせられるため、個人の試行錯誤にはとても便利です。

一方で、チーム導入では「MCP serverをたくさん入れる」「toolを全部allowにする」から始めると、後で説明しにくくなります。まず、AIがどのtoolを使い、どのserverへ接続し、どのthreadで何を変更したのかを追える設計にします。

前提知識

項目	内容	見方
Agent Panel		first-party agentやexternal agentを使う。
Tool Permissions		tool actionの承認を制御する。
MCP		外部toolやdata sourceにつなぐ。
Parallel Agents		複数threadを独立して動かす。

Zedはeditor、agent、MCP、ACPをまとめて扱う場として理解します。

Zed公式docsでは、Agent PanelがZedのfirst-party agentを既定で使うこと、conversation thread、context、tool actionsを扱うことが説明されています。Agent Settings docsでは、model selection、UI preferences、tool permissionsなどを設定できると説明されています。

MCP docsでは、ZedがModel Context Protocolを使ってcontext serversと連携し、ToolsとPromptsをsupportすることが説明されています。Tool approvalは、Zed v0.224.0以降ではagent.tool_permissions.defaultで制御されます。

この記事の扱う範囲

項目	役割
Agent Panel	Zed内でAI agent作業を始める入口
Built-in tools	codebaseのread、search、editなど
agent.tool_permissions.default	tool action全体の既定承認
MCP servers	外部toolやdata sourceへの接続
per-tool permission	specific MCP toolごとの承認設定
External Agents	Claude Agent、Codex、Gemini CLIなど
ACP	external agentとclientをつなぐprotocol
Parallel Agents	複数agent threadを同時に動かす機能

2026年6月1日時点で公開されているZed公式docsを確認しています。導入時には、利用中のZed version、model provider、teamのAPI key管理、MCP serverのscope、社内data policyを改めて確認してください。

注意点

Zed Agent Panelは、editor内で便利に使える一方、file編集、terminal tool、MCP server、外部agentに近い場所へ広がります。最初はAIの賢さより、権限とreview単位が説明できるかを優先します。

まず6つの境界に分ける

項目	内容	見方
Entry		Agent Panelとinline補助。
Tools		built-in toolの承認。
MCP		server追加とtool permission。
External		Claude、Codex、Gemini CLI。
Parallel		threadごとの作業範囲。
Data		model providerとdata handling。

境界を分けると、Zedで動いたAI作業を説明しやすくなります。

Zed Agent Panelをチームで使うなら、最初に6つの境界を分けます。

境界	確認すること
Entry	Agent Panel、inline assistant、external agentの入口
Tools	built-in toolをどう承認するか
MCP	server追加、認証、tool permission
External	Claude Agent、Codex、Gemini CLIなどの差
Parallel	threadごとのtaskと変更範囲
Data	model provider、API key、AI improvement設定

この6つを分けないまま使うと、「ZedのAIが何かやった」としか説明できません。実務では、どのagentが、どのtoolで、どのcontextを使い、どの差分を作ったかを残します。

editor内agentの強み

editor内で動くagentは、file selection、buffer context、project search、diff確認に近い場所で使えます。ZedではAgent Panelにcontextを渡し、threadを続け、必要ならsummaryから新しいthreadへ引き継げます。

editor内agentの注意点

editorに近いということは、local projectのfile、credential、draft codeにも近いということです。MCP serverやexternal agentを増やすほど、どの経路でtoolが動くかを把握する必要があります。

判断基準

迷ったら、「そのtool actionが自動で動いた理由をPRで説明できるか」を基準にします。説明できないなら、confirmに戻します。

Agent Panelは作業入口として扱う

Thread

conversationとcontextを管理。

Context

fileやselectionを渡す。

Tools

read、search、editを使う。

Summary

長いthreadを引き継ぐ。

Agent Panelはchat欄ではなく、contextとtoolを扱う作業入口です。

Agent Panel docsでは、Agent PanelがZedのfirst-party agentを既定で使い、thread、context、conversationを扱うことが説明されています。長くなったconversationはsummaryを使って新しいthreadへ引き継ぐこともできます。

Agent Panelは、単なるchat欄ではありません。contextを選び、tool actionを承認し、編集や調査を進める作業入口です。

Agent Panelに向く作業

作業	向いている理由
codebase調査	file selectionやsearchと相性がよい
小さな修正	diffを確認しやすい
test失敗の整理	logと関連fileを同じthreadで扱える
documentation更新	選択範囲や関連fileを渡しやすい
refactorの下調べ	summaryでthreadを引き継げる

Agent Panelに向かない初回作業

初回からMCP serverを複数追加し、tool actionをallowにし、parallel agentsで同じmoduleを触らせるのは避けます。Zedが悪いのではなく、review境界がまだできていないためです。

threadを長くしすぎない

長いthreadはcontextが増え、判断の前提が混ざります。Agent Panel docsで説明されているsummaryを使い、必要に応じて新しいthreadへ移します。taskが変わるならthreadも分けます。

threadの命名

team運用では、thread名やtask名にIssue番号、対象package、目的を入れると追いやすくなります。parallel agentsを使うなら、なおさら名前で区別できるようにします。

Tool Permissionsはdefaultから決める

項目	内容	見方
confirm		実行前に確認する初期方針。
allow		低risk taskだけに限定。
deny		tool actionを閉じる。
per-tool		個別toolで例外を作る。

最初はconfirmを基準にし、必要なtoolだけ狭く広げます。

Zed MCP docsでは、Zed v0.224.0以降、tool approvalはagent.tool_permissions.defaultで制御されると説明されています。値は、confirm、allow、denyです。

最初に決めるべきは、このdefaultです。

defaultの使い分け

値	使いどころ
confirm	初期導入の基準。tool action前に確認する
allow	低risk taskや個人sandboxで限定的に使う
deny	AIにtool actionをさせない時に使う

Zed docsでは、confirmがdefaultとして説明されています。チーム導入では、これを基準にします。最初からallowにすると、どのtoolがいつ動いたかを人間が見落としやすくなります。

built-in toolsとMCP toolsを分ける

Zedのbuilt-in agentは、codebaseのread、search、editなどのtoolを使えます。MCP serverを追加すると、さらに外部toolやdata sourceへ広がります。

この2つを同じ感覚で扱わない方がよいです。local projectを読むtoolと、GitHub、database、browser、external APIへ触るMCP toolではriskが違います。

per-toolで例外を作る

defaultはconfirmにしつつ、低riskなtoolだけ例外的に許可する、という順番が扱いやすいです。逆に、変更系toolは個別にconfirmまたはdenyへ寄せます。

初期方針

最初の1週間はconfirmを維持します。Zedがどのtoolを使いたがるか、人間がどこで承認に迷うかを見てから、例外を作ります。

MCP serversはextensionとcustomで分ける

項目	内容	見方
Extension		Zed extensionとして追加。
Custom		settingsにcommandやurlを書く。
Remote		OAuthやheaderを確認。
Restart		tool listの更新挙動を見る。

MCP serverは入れ方だけでなく、認証と更新の扱いも見ます。

Zed MCP docsでは、MCP serversをZed extensionとして使う方法と、settings fileにcommandやURLを追加してcustom serverとして接続する方法が説明されています。popular extensionとしてContext7、GitHub、Puppeteer、Brave Search、Prismaなども挙げられています。

導入時は、serverの入れ方を分けます。

extensionで入れる場合

extensionとして公開されているMCP serverは、Zed website、Command Paletteのextensions、Agent Panelのmenuから探せます。teamで同じserverを使う場合、extension経由の方が説明しやすいことがあります。

custom serverで入れる場合

custom serverはsettings fileへcommand、args、env、url、headersなどを書いて接続します。local scriptや社内toolをつなぐ時に便利です。

方式	向いている場面
extension	よく使われるserverを簡単に導入する
custom command	local MCP serverや社内toolを使う
remote URL	remote MCP serverへ接続する
headers	tokenや認証headerを使う

remote MCPの認証

Zed MCP docsでは、remote MCP serverにAuthorization headerが設定されていない場合、標準MCP OAuth flowでauthentication promptを出すと説明されています。remote serverでは、認証方式、token scope、ログ、network先を確認します。

serverを増やしすぎない

MCP serverを増やすほど、agentが選べるtoolが増えます。最初は1つだけ入れ、使ったtool、承認回数、出たdiffを見てから増やします。

per-tool permissionでMCPを絞る

Format

mcp:server:tool_nameを使う。

Read

read-only toolから許可。

Write

create、update、deleteは確認。

Audit

変更系toolを記録する。

MCPは便利な入口なので、tool単位で承認を残します。

Zed MCP docsでは、specific MCP toolsにper-tool permission rulesを設定できると説明されています。MCP toolsのkey formatはmcp:<server>:<tool_name>です。たとえばmcp:github:create_issueのような形です。

これはチーム運用でかなり重要です。MCP server全体を許可するのではなく、tool単位で見るからです。

read系とwrite系を分ける

tool種類	初期方針
search/read	confirmから始め、必要なら限定的に許可
create	confirmを維持
update	confirmを維持
delete	denyまたは強い確認
external action	内容に応じて個別review

patternに頼りすぎない

Zed MCP docsでは、MCP toolsではper-tool entryのdefault keyが主な仕組みであり、pattern-based rulesはMCP toolsに対して多くの場合matchしにくいと説明されています。つまり、MCPは具体的なtool keyで設定する方が確実です。

GitHub MCPの例

GitHub MCP serverを入れる場合、issueを読むtool、PRを読むtool、commentを書くtool、issueを作るtoolではriskが違います。create_issueやcomment作成は便利ですが、team標準では承認を残します。

変更系toolの記録

MCP経由で外部systemへ書き込むtoolは、誰が、何を、なぜ実行したかを残します。Zed内の承認だけでなく、GitHubやSaaS側のaudit logも確認対象にします。

External AgentsはACPの差を確認する

項目	内容	見方
Claude Agent		ACP経由の挙動を見る。
Codex		MCP forwardingを確認。
Gemini CLI		API keyと対応差を見る。
Logs		ACP logsでdebugする。

外部agentはZed内に見えても、tool対応は実装ごとに違います。

Zed External Agents docsでは、Gemini CLIをAgent Panelから実行できること、Claude AgentやCodexなどexternal agentsを扱えることが説明されています。また、Zedのcontext_serversに設定されたMCP serversは、ACP protocolを通じてClaude AgentやCodexへforwardされると説明されています。

ただし、external agentはすべて同じではありません。

確認する項目

項目	見ること
agent	Claude Agent、Codex、Gemini CLIなど
API key	Zedのprovider設定や環境変数の扱い
MCP forwarding	Zed側serverが渡るか
tool support	agent実装がどこまで対応するか
debug	ACP logsで確認できるか

Gemini CLIの扱い

External Agents docsでは、GEMINI_API_KEYまたはGOOGLE_AI_API_KEYが設定されている場合や、Zed language model provider settingsにGoogle AI API keyがある場合、Gemini CLIへ渡されると説明されています。

API keyの扱いはteamで決めます。個人key、team key、CI用keyを混ぜないようにします。

Claude AgentとCodexの扱い

Zed docsでは、Zedのcontext_serversがClaude AgentやCodexへforwardされると説明されています。一方で、external agentsでMCP serverにaccessできるかはACP agent implementationに依存する場合があります。

debug view

External Agents docsでは、Command Paletteからdev: open acp logsでdebug viewへaccessできると説明されています。外部agentでMCPが見えない、toolが動かない、permissionが期待と違う時は、まずlogを確認します。

Parallel Agentsはtask単位で分ける

項目	内容	見方
Independent		threadごとにcontextを分ける。
Scope		同じfileを同時に触らせない。
Review		diffをtaskごとに見る。
Merge		統合順を人間が決める。

parallelは速度のためだけでなく、task分割の設計が前提です。

Zed Parallel Agents docsでは、複数のagent threadsを同時に動かせ、それぞれが独自のagent、context window、conversation historyを持つと説明されています。

これは強力ですが、team導入ではtask分割が前提です。

parallelに向くtask

task	理由
docs更新とtest追加	触るfileが分かれやすい
複数案の調査	diff前の比較に向く
package別の修正	workspace単位で分けやすい
bug原因候補の探索	threadごとに仮説を分けられる

parallelに向かないtask

同じfileを複数threadで編集するtask、shared typeをまたぐ大きなrefactor、migration、auth設計は衝突しやすいです。parallelにするより、1つのthreadで順番に進める方がreviewしやすいことがあります。

reviewはthreadごとに分ける

parallel agentsで作った差分は、threadごとにreviewします。あとでまとめて見ると、どのagentがどの判断で変更したのか追いにくくなります。

統合順を人間が決める

parallel taskのmerge順は人間が決めます。先にtestやdocsの差分を入れ、次に実装差分を入れるなど、reviewしやすい順にします。

モデルとdata handlingを確認する

Hosted

Zed hosted modelの設定を見る。

API key

non-Zed providerを分ける。

Default

agentic work用modelを確認。

Data

AI improvement設定を確認。

model選択は品質だけでなく、送る情報と契約条件で判断します。

Zed Agent Settings docsでは、model selectionやprovider設定が説明されています。Zedのhosted LLM serviceを使う場合、agentic work向けのdefault modelやfast modelが設定されることがあります。non-Zed AI serviceをAPI keyで接続することもできます。

AI Improvement docsでは、ZedのAI improvementやdata collectionに関する設定が説明されています。team導入では、model品質だけでなく、どのproviderへどの情報が送られるかを確認します。

model選択の軸

軸	見ること
quality	code理解、tool use、diff品質
latency	editor内で待てる速度
cost	hosted plan、API key、token消費
data	codeやpromptの扱い
availability	team全員が同じ設定を使えるか

API keyの扱い

個人のAPI keyをteam標準にしない方がよいです。Zedのprovider設定、環境変数、OS credential storage、社内secret管理のどれを使うかを決めます。

data policyを確認する

AI機能では、code、prompt、selection、tool resultがproviderへ送られる可能性があります。Zed docs、provider docs、社内規程を合わせて確認します。

使わない人の設定

team全員がAI機能を使うとは限りません。ZedのAI panelを使わない人、API keyを入れない人、MCP serverを使わない人の設定も標準化します。

導入初週の進め方

1. 1日目

   Agent Panelとtool defaultを確認。

2. 2日目

   read/search中心のtaskを試す。

3. 3日目

   MCP serverを1つだけ追加。

4. 5日目

   external agentとの違いを見る。

5. 7日目

   parallel運用とreviewを見直す。

初週はMCPを増やすより、permissionとreview単位を固めます。

Zed Agent Panelは、1日で全部開けるより、1週間で境界を固める方が向いています。

日	やること	目的
1日目	Agent Panelとagent.tool_permissions.defaultを確認	tool approvalの基準を決める
2日目	read/search中心の小taskを試す	built-in toolsの挙動を見る
3日目	MCP serverを1つだけ追加	server認証とtool一覧を見る
4日目	per-tool permissionを設定	write系toolに承認を残す
5日目	external agentを1つ試す	ACP差とMCP forwardingを見る
6日目	parallel threadを小taskで試す	context分離とreviewを見る
7日目	model、data、API key運用を見直す	team標準にするか判断する

初週の評価軸

評価軸	見ること
approval	tool actionで適切に確認が出るか
MCP	serverとtool scopeを説明できるか
external	agentごとの差を把握できるか
parallel	threadごとにdiffをreviewできるか
data	providerとdata handlingを説明できるか

広げる条件

次の条件を満たしたら、MCP serverやparallel taskを増やします。

• default permissionがteamで合意されている
• MCP serverごとのpurposeとtoken scopeが明確
• write系MCP toolは承認を残している
• external agentごとのMCP対応差を確認済み
• parallel taskで同じfileを同時編集しないルールがある
• API keyとdata policyが整理されている

FAQ

allow?

初期標準にはしない。

MCP first?

必要なserverから入れる。

External?

ACP差を確認する。

Parallel?

file衝突を避ける。

迷ったら、Zedが動かしたtoolと変更範囲を説明できるかで判断します。

agent.tool_permissions.defaultはallowにしてよいですか？

初期標準にはしない方がよいです。個人のsandboxやread-onlyに近いtaskなら使える場面がありますが、team標準ではconfirmを基準にして、必要なtoolだけ個別に広げます。

MCP serverは最初から複数入れるべきですか？

最初は1つだけで十分です。serverを増やすほどtool選択と承認が複雑になります。まず1 serverで、tool list、permission、認証、log、diffへの影響を見ます。

ZedのMCP serverはClaude AgentやCodexにも渡りますか？

Zed docsでは、Zedのcontext_serversに設定されたMCP serversがACP経由でClaude AgentやCodexへforwardされると説明されています。ただし、external agent側のimplementationによって対応差があります。実際の挙動はACP logsで確認します。

Gemini CLIも同じように使えますか？

Gemini CLIはZed Agent Panelから実行できますが、API keyやtool対応はClaude AgentやCodexと同じではありません。GEMINI_API_KEYやZed provider設定の扱いを確認し、MCP serverの見え方も別途見ます。

Parallel Agentsはいつ使うべきですか？

独立したtask、別package、docsとtestのようにfileが分かれる作業に向きます。同じfileや同じmoduleを複数threadで触らせると、統合が難しくなります。

ZedのAI data handlingは何を見ればよいですか？

ZedのAI Improvement docs、使うmodel providerのpolicy、社内規程を確認します。hosted model、API key provider、external agent、MCP serverでdataの行き先が変わる可能性があります。

---

次に読むなら

参照した主な情報源

• https://zed.dev/docs/ai/agent-panel
• https://zed.dev/docs/ai/agent-settings
• https://zed.dev/docs/ai/mcp
• https://zed.dev/docs/ai/tools
• https://zed.dev/docs/ai/external-agents.html
• https://zed.dev/docs/ai/parallel-agents.html
• https://zed.dev/docs/ai/ai-improvement

更新履歴

1. 2026年6月1日

   Zed公式docsのAgent Panel、MCP、Tool Permissions、External Agents、Parallel Agentsを確認して初版を作成しました。

導入時には利用中のZed versionとagent設定を確認してください。

• 2026年6月1日: Zed公式docsのAgent Panel、Agent Settings、MCP、Tools、External Agents、Parallel Agents、AI Improvementを確認し、初版を作成しました。