Warp Agent Modeをチームで使う前に：Permissions・MCP・Workflowsを分ける基準

3行まとめ

このテーマをもう少し広げて見るなら、AIコーディングエージェントを比べる前に：Codex・Claude Code・Cursor・Copilot・Windsurfの判断軸 と AIコーディングエージェントのprompt injection対策：Issue・Docs・MCPを読ませる前に決めること も合わせて確認してください。Warp Agent Modeをterminal agentとして評価する前に、他ツールとの比較軸を補えるため

Terminal

Agent Modeを作業の入口にする。

Profile

用途ごとに権限を分ける。

Commands

allowlistとdenylistを管理する。

MCP

外部toolの呼び出し範囲を決める。

Warpはterminalに近いAI agentなので、便利さより先に権限境界を決めます。

• Warp Agent Modeは、terminalで自然言語からcommand実行やcode作業へ進める入口です。チーム導入では、便利さより先にProfile、Permissions、command rules、Warp Drive、MCPの境界を決めます。
• 公式docsでは、Agent Profilesごとにautonomy、base model、tool access、command permissionsを設定でき、command allowlist、command denylist、MCP permissionsを分けられます。
• 最初はSafe profileでread、plan、確認系commandから始め、diff適用、外部tool、Run until completionは運用ルールが固まってから広げる方が扱いやすいです。

本文の事実確認には、Warp公式docsのAgents、Profiles & Permissions、Agent Mode Context、AI-Integrated Objects、MCPを使っています。Xで見かけるWarp Agent、terminal agent、MCP、allowlist/denylistへの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Autonomy

Always askとAlways allowを分ける。

Command

自動実行できるcommandを絞る。

Context

Warp Driveで共有する情報を選ぶ。

Review

diffとcommand結果を確認する。

Warp Agent Modeは、設定を分けるほどチームで説明しやすくなります。

• Warp Agent Modeをチームで使う時に最初に分ける運用境界
• Agent ProfilesとPermissionsをどう使い分けるか
• command allowlistとcommand denylistをどう設計するか
• Warp DriveのRules、Workflows、Notebooksをcontextとして使う考え方
• MCP serversを外部toolの入口として扱う時の注意点
• 導入初週にどこまで自動化するか

Warpはterminal体験にAI agentを重ねる製品です。自然言語で作業を頼めるため、shell commandの入力、調査、修正、test、reviewの流れを短くできます。一方で、terminalはfile、network、process、secret、Git stateに近い場所でもあります。

この記事では、Warp Agent Modeを「何でも自動で任せる機能」ではなく、「terminal作業を可視化しながら委任する入口」として整理します。チームで使うなら、誰が見ても説明できる権限設計が先です。

前提知識

項目	内容	見方
Agent Mode		自然言語でterminal作業を進める。
Profiles		model、autonomy、tool accessを分ける。
Permissions		read、diff、plan、commandを制御する。
Warp Drive		Rules、Workflows、MCP Serversを共有する。

Warpはterminal UIだけでなく、Agentの権限とcontext管理として理解します。

Warp公式docsでは、Agentsを自然言語でterminalやcoding workflowを進める仕組みとして説明しています。Agent Modeでは、作業を自然言語で依頼し、必要なcommand、context、task list、code diffを扱います。

Profiles & Permissions docsでは、Agent Profilesにより、Agentのautonomy、base model、tool access、command permissionsを用途ごとに設定できると説明されています。Permissionsは、file read、plan作成、code diff適用、command実行、running commandとのinteractionなどに分かれます。

この記事の扱う範囲

項目	役割
Agent Mode	terminal作業を自然言語で依頼する入口
Agent Profiles	用途ごとにmodel、autonomy、tool accessを分ける設定
Permissions	read、plan、diff、commandなどaction単位の権限
Command allowlist	確認なしで実行してよいcommand pattern
Command denylist	承認を必須にするcommand pattern
Warp Drive	Rules、Workflows、Notebooks、MCP Serversなどの共有context
MCP Servers	GitHub、Sentry、dbt、社内toolなどへ接続する外部tool入口

2026年6月1日時点で公開されているWarp公式docsを確認しています。導入時には、利用中のWarp version、team plan、社内security policy、terminalで扱うsecret、MCP serverのscopeを別途確認してください。

注意点

この記事は、Warp Agentへ本番環境やprivate repositoryを無条件に任せるための記事ではありません。最初はreadとplanを中心にし、command実行やdiff適用は人間が確認できる粒度で始める前提です。

まず5つの境界に分ける

項目	内容	見方
Mode		shell入力とagent依頼を分ける。
Profile		用途ごとにautonomyを変える。
Command		自動実行と承認対象を分ける。
Context		RulesやWorkflowsを共有する。
MCP		外部toolの呼び出しを制御する。

境界を分けると、Agentが何をしたのか説明しやすくなります。

Warp Agent Modeをチーム導入するなら、最初に5つの境界を分けます。

境界	確認すること
Mode	shell commandとして入力するのか、Agentへの依頼として入力するのか
Profile	作業用途ごとにautonomy、model、tool accessをどう分けるか
Command	どのcommandを自動実行し、どのcommandで承認を求めるか
Context	Rules、Workflows、Notebooks、Environment Variablesをどう使うか
MCP	外部toolやdata sourceをどこまでAgentへ渡すか

この5つを分けないまま「Warp Agentを入れる」と、便利な瞬間は増えますが、あとで説明しにくくなります。特にcommand実行とMCPは、terminal外のsystemへ影響することがあります。

個人利用とチーム利用は違う

個人のlocal projectで使うなら、試行錯誤しながら設定を広げても戻しやすいです。チームではそうはいきません。誰かの設定が暗黙の標準になり、後から「なぜこのcommandが自動実行されたのか」「なぜこのMCP serverを呼んだのか」を説明できなくなることがあります。

最初に作るべき文書

チーム導入では、長い規程よりも短い運用メモが役に立ちます。たとえば次のような項目です。

項目	最初の書き方
Safe profile	Always askを基本にし、readとplanから始める
Command allowlist	ls、pwd、git status、test確認などから候補を選ぶ
Command denylist	rm、curl、wget、eval、deploy系を承認対象にする
MCP	必要なserverだけを追加し、token scopeを確認する
Diff	自動適用ではなくreviewを残す

迷った時の基準

迷ったら「そのactionが自動で走った理由を、あとから第三者に説明できるか」で判断します。説明できないものは、まだAlways askに寄せた方が安全です。

Agent Modeはterminal実行の入口にする

Prompt

作業を自然言語で依頼する。

Commands

必要なcommandを提案、実行する。

Blocks

会話とcommand結果を残す。

Visibility

実行内容を見ながら進める。

Agent Modeは魔法の自動化ではなく、terminal作業を対話的に進める入口です。

WarpのAgents docsでは、Agent Modeを自然言語でterminalやcoding workflowを進める入口として説明しています。作業内容を自然言語で伝えると、Agentがcommandやtaskを提案し、必要に応じて実行します。

この時に大切なのは、Agent Modeを「terminalの代わり」ではなく「terminal作業の入口」として見ることです。terminalを使う時と同じように、working directory、env、Git state、running process、secretの扱いを意識します。

Agent Modeに向いている作業

作業	向いている理由
調査	command結果を見ながら次の確認を進められる
log確認	error messageから原因候補を絞れる
test失敗の整理	failing test、stack trace、関連fileをつなげて見られる
小さな修正	diffを確認しながら進めやすい
手順化	繰り返しcommandをWorkflowやRuleへ移しやすい

Agent Modeに向かない初回作業

初回から大きなrefactor、production database操作、secretを含む調査、権限の強いMCP server操作を任せるのは避けます。Warpの操作自体が悪いわけではなく、まだProfileや承認条件が固まっていないためです。

terminalに近いからこその強み

terminalに近いAI agentは、IDE外の作業も扱いやすいです。CI log、package manager、migration、local server、CLI toolなど、普段の開発者が使う道具に触れます。

ただし、強みはそのままriskにもなります。shellの近くにいるagentほど、何を自動実行するかを先に決める必要があります。

Permissionsはaction単位で決める

項目	内容	見方
Read files		読むだけの作業から始める。
Create plans		計画作成を任せるか決める。
Apply diffs		diff適用はreviewを残す。
Execute commands		実行commandは承認条件を決める。

権限はまとめて開けず、actionごとに段階を決めます。

WarpのProfiles & Permissions docsでは、Agent Permissionsとして複数のactionを分けて設定できると説明されています。代表的には、fileを読む、planを作る、code diffを適用する、commandを実行する、running commandとやり取りする、といった種類です。

ここで避けたいのは、「AI agentを許可するか、しないか」という粗い設計です。実務では、readは許可したいがdiff適用はreviewしたい、plan作成は任せたいがcommand実行は承認したい、という組み合わせが多くなります。

permissionを4段階で見る

Warp docsでは、permissionごとに Agent Decides、Always ask、Always allow、Never のようなautonomy levelを選べると説明されています。チームでは、次のように段階を分けると扱いやすいです。

level	チームでの使いどころ
Never	そのprofileでは不要なactionを閉じる
Always ask	初期値。人間が確認してから進める
Agent Decides	低risk作業で様子を見ながら使う
Always allow	十分に狭い作業だけに使う

Apply code diffsはreviewを残す

Warp docsでは、Apply code diffsについて Agent decides が現時点では Always ask と同じように振る舞い、diff適用前にreview promptを出すと説明されています。これはチーム運用ではむしろ利点です。

AI agentが作ったdiffは、通ったかどうかだけでなく、なぜそう直したのか、どのfileへ影響したのかを人間が見ます。特にshared library、auth、billing、migration、CI設定は、Always allowに寄せすぎない方がいいです。

Create plansは早めに開いてよい

plan作成は、実行よりriskが低いことが多いです。Agentに調査とplanを作らせ、人間が「この範囲なら進めてよい」と判断する流れにすると、初期導入でも使いやすくなります。

設定例

action	初期設定の例	理由
Read files	Agent DecidesまたはAlways ask	secretやprivate fileの扱い次第
Create plans	Agent Decides	実行前の整理に使いやすい
Apply diffs	Always ask	reviewを残したい
Execute commands	Always ask	shell影響を確認したい
Interact with running commands	Always ask	serverやREPLの状態を壊さないため

allowlistとdenylistを運用に入れる

項目	内容	見方
Allowlist		read-only寄りのcommandから入れる。
Denylist		削除、download、evalを承認対象にする。
Priority		denylistを優先して考える。
Review		teamで定期的に見直す。

allowlistは速度、denylistは事故防止のために使います。

WarpのProfiles & Permissions docsでは、command allowlistとcommand denylistを分けて設定できると説明されています。allowlistは確認なしで実行してよいcommand pattern、denylistは承認を必須にするcommand patternです。

重要なのは、allowlistを増やすことが目的ではない点です。目的は、低riskなcommandで作業の摩擦を減らし、高riskなcommandで人間の確認を残すことです。

allowlistに入れやすいcommand

最初はread-only寄りのcommandから候補にします。

command候補	見ること
pwd	working directory確認
ls	file一覧確認
git status	Git state確認
git diff --stat	変更量確認
rg	text search
npm test -- --help	test commandのhelp確認

実際にallowlistへ入れるpatternは、team policyに合わせて狭くします。たとえば git 全体ではなく、git status や git diff のように具体的に分けます。

denylistに残すcommand

Warp docsでは、default denylistの例としてnetwork request、file deletion、shell code executionに関わるcommandが挙げられています。チームでは、次のような種類を承認対象に残します。

種類	例
削除	rm、cleanup script
network	curl、wget、外部API call
code execution	eval、unknown script
deploy	production deploy、release command
database	migration、seed、delete query
secret	credential export、token表示

denylistを優先して考える

Warp docsでは、denylistがallowlistやAgent Decidesより優先されると説明されています。これは運用上とても大切です。allowlistを広げても、denylistに該当するcommandは承認対象にできます。

つまり、チームでは「allowlistをどう広げるか」だけでなく、「denylistをどこに残すか」を明文化します。

Run until completionは別扱い

Warp docsでは、Run until completionが現在のtaskに対して強い自律性を与える機能として説明され、denylistを無視する旨も記載されています。これは便利ですが、チーム標準の初期設定として扱うには強すぎます。

個人のsandbox taskや、十分に狭いlocal作業なら使える場面はあります。ただし、shared repository、productionに近い操作、secretを含むtaskでは、標準運用にしない方が説明しやすいです。

Warp Driveは共有contextに使う

Rules

coding規約やreview方針。

Workflows

繰り返すcommandや手順。

Notebooks

調査メモや運用手順。

Env vars

設定値の参照を整理する。

Warp Driveは、毎回promptへ貼る情報をteam資産に変える場所です。

Warp DriveのAgent Mode Context docsでは、Agent ModeがWarp Drive内のWorkflows、Notebooks、Rules、MCP Servers、Environment Variablesなどをcontextとして使えると説明されています。AI-Integrated Objects docsでも、RulesやMCP ServersなどがAgentの理解を助けるobjectとして整理されています。

ここでのポイントは、毎回promptへ貼っていた情報を、共有contextとして管理できることです。

Rulesに入れるもの

Rulesは、Agentの振る舞いを揃えるために使います。

Rule候補	例
coding style	TypeScriptでは既存patternを優先する
testing	変更後は該当testを先に走らせる
security	secretを表示しない、commitしない
review	diffの理由とriskを短く説明する
repo convention	directoryごとの責務を守る

Rulesを入れすぎると、Agentの判断が重くなります。最初は「守らないと事故になるもの」と「reviewの質が上がるもの」に絞ります。

Workflowsに入れるもの

Workflowsは、繰り返すcommandや手順の保存に向きます。たとえばlocal test、lint、storybook起動、schema生成、log確認などです。

ただし、deployやmigrationのような高risk作業は、Workflow化しても自動実行にはしない方がよいです。Workflowは「手順を共有する場所」であり、「無条件に実行する許可」ではありません。

Notebooksに入れるもの

Notebooksには、調査メモ、障害時の切り分け、設計判断、手順の背景を残します。Agentがcontextとして参照できるため、属人化しやすい運用知識をteam資産にできます。

contextの棚卸し

月に一度は、Rules、Workflows、Notebooks、MCP Serversを棚卸しします。古い手順や使われていないRuleが残ると、Agentの判断を曇らせます。AI向けcontextも、codeと同じく保守対象です。

MCP serversは外部toolの入口にする

項目	内容	見方
Server		GitHubやSentryなどの入口。
Allowlist		自動呼び出し可能なserverを選ぶ。
Denylist		承認が必要なserverを残す。
Secrets		tokenやAPI keyを分離する。

MCPは便利な拡張口なので、server単位で権限を管理します。

WarpのMCP docsでは、MCP serversを使ってAgentへ外部toolやdata sourceを渡せると説明されています。MCPにより、GitHub、dbt、Sentry、社内toolなど、terminal内だけでは完結しない情報や操作にAgentが触れられます。

便利ですが、MCPは「外部toolへの入口」です。serverを追加するたびに、どのdataへ読めるのか、どのactionを実行できるのか、token scopeは何かを確認します。

MCP serverごとに決めること

項目	確認すること
purpose	何のために使うserverか
data scope	読めるrepository、project、ticket、logの範囲
write scope	issue作成、comment、deployなどの書き込み有無
token	API keyやaccess tokenの権限
approval	自動呼び出しにするか、承認対象にするか
logging	呼び出し履歴をどこで確認するか

MCP allowlistとdenylist

WarpのProfiles & Permissions docsでは、MCP allowlistとMCP denylistを設定できると説明されています。commandと同じく、MCPでも自動呼び出しできるserverと、人間承認を残すserverを分けます。

server種類	初期方針
read-only docs	必要ならallowlist候補
issue tracker	readから始め、writeは承認対象
observability	logやalert閲覧はscopeを狭くする
database	原則承認対象
internal admin	必要性をreviewしてから追加

secretをpromptへ貼らない

MCP serverのtokenやAPI keyは、promptへ貼らず、server設定やsecret管理の仕組みで扱います。Agentがtokenを直接見る必要がある設計は避けます。

MCPを増やす順番

最初から多くのMCP serverを入れると、Agentがどのtoolを使ったのか追いにくくなります。まずはread-only docsやissue参照のような低riskなものから始め、write actionを持つserverは後から追加します。

RulesとWorkflowsで再現性を上げる

Rules

Agentの振る舞いを揃える。

Workflows

手順を保存して使い回す。

Notebook

判断理由と手順を残す。

Profile

安全度ごとに切り替える。

同じ作業を同じ形で頼めることが、team運用の強みになります。

Warp Agent Modeをチームで使う価値は、単にcommandを速く打てることだけではありません。同じ作業を同じcontextで頼めるようになることです。

RulesとWorkflowsを整えると、「詳しい人だけが知っている手順」をAgentにも共有できます。これは新人向けonboardingにも、障害対応の初動にも効きます。

Rulesは行動方針

Rulesには、Agentに守らせたい行動方針を入れます。たとえば「変更前に関連testを確認する」「既存helperを優先する」「secretやcustomer dataを出力しない」といった内容です。

Workflowsは手順

Workflowsには、繰り返し使う手順を入れます。たとえば「frontend testを走らせる」「API schemaを再生成する」「local server logを見る」などです。

RulesとWorkflowsを混ぜると、後から保守しにくくなります。Ruleは判断基準、Workflowは実行手順として分けます。

Profileは安全度

Profileは、作業の安全度で分けます。

Profile例	用途
Safe	read、plan、manual approval中心
Coding	小さなdiff作成とtest確認
Review	PR reviewやlog確認
Local sandbox	個人の実験用
Admin	原則作らないか、強い承認を残す

名前で判断できるようにする

Profile名は、かっこいい名前よりも意味がわかる名前にします。safe-read-plan、coding-small-diff、review-only のように、どの権限が開いているか想像できる名前が向いています。

最小構成の始め方

項目	内容	見方
Safe profile		Always askを基本にする。
Read only		調査とplanから始める。
Small commands		ls、grep、test確認を候補にする。
MCP off		必要になるまで外部toolを閉じる。

初回は速さより、何が自動で動くかを説明できる状態を優先します。

最初の構成は、速さよりも説明しやすさを優先します。

項目	初期方針
Profile	Safe profileを作る
Read files	Always askまたはAgent Decides
Create plans	Agent Decides
Apply diffs	Always ask
Execute commands	Always ask
Command allowlist	いったん空、またはread-only候補だけ
Command denylist	defaultに加えてteam固有のrisk command
MCP	初日は追加しない
Rules	secret、review、test方針だけ

最初のtask

初回taskは、既存コードを壊しにくいものを選びます。

• READMEの古い手順を確認する
• failing testの原因候補を整理する
• git status と関連fileを見て変更範囲を説明する
• 小さなlint errorを1件直す
• PRのdiffを読ませてriskを列挙する

大きなfeature実装やrefactorは、初回taskに向きません。Profileと承認条件が期待通りに働くかを先に見ます。

command候補を増やす

数回使ってから、allowlist候補を増やします。誰か一人の好みではなく、teamで合意した低risk commandだけにします。git status、git diff --stat、rg、npm test -- --help のような確認系から始めると説明しやすいです。

やらないこと

初期導入では、Run until completionを標準化しません。deploy、migration、外部API書き込み、secret確認、production logの広範な取得も対象外にします。

導入初週の進め方

1. 1日目

   Safe profileでreadとplanを確認。

2. 2日目

   command allowlist候補を洗い出す。

3. 3日目

   denylistと承認条件を決める。

4. 5日目

   RulesとWorkflowsをteamで共有。

5. 7日目

   MCP serverの必要性をreview。

初週は完全自動化ではなく、説明できる運用を作ります。

Warp Agent Modeは、1日で完全な標準運用にするより、1週間で小さく広げる方が向いています。

日	やること	目的
1日目	Safe profileでreadとplanを試す	何を読むか、何を提案するか確認
2日目	command allowlist候補を集める	低risk commandを見極める
3日目	denylistと承認条件を決める	事故につながる操作を止める
4日目	小さなdiff作成を試す	review promptとGit diffを見る
5日目	RulesとWorkflowsを共有する	teamの作業手順を揃える
6日目	MCP server候補を洗い出す	外部toolの必要性を判断
7日目	設定と事例をreviewする	権限を広げるか戻すか決める

初週の評価軸

初週は、AIの賢さだけを見ない方がいいです。むしろ、次の評価軸を見ます。

評価軸	見ること
説明性	何を自動実行したか説明できるか
review容易性	diffやcommand結果を追えるか
再現性	同じtaskを同じ手順で頼めるか
安全性	risk commandで承認が残るか
team fit	既存のGit、CI、review運用に合うか

広げる条件

次の条件を満たしたら、少しずつ権限を広げます。

• command allowlistのpatternが狭く書けている
• denylistにteam固有のrisk commandが入っている
• diff適用前のreviewが残っている
• secretやprivate dataをpromptへ貼らない運用になっている
• MCP serverのscopeを説明できる

FAQ

YOLO mode?

個人task以外では慎重に扱う。

MCP first?

必要な外部toolだけ追加する。

Rules first?

team規約は早めに入れる。

Diff apply?

reviewの残し方を先に決める。

迷ったら、自動実行された理由を後から説明できるかで判断します。

Warp Agent Modeは最初からAlways allowでよいですか？

チーム標準としてはおすすめしません。個人のlocal sandboxなら試せますが、shared repositoryや外部toolへ触る作業では、Always askから始める方が説明しやすいです。

command allowlistは広くしてよいですか？

広くしすぎない方がよいです。git .* のような広いpatternではなく、git status、git diff のように用途を絞ります。自動実行したい理由が説明できるcommandだけを入れます。

denylistがあるなら安心ですか？

denylistは重要ですが、それだけで十分ではありません。新しいscript名、社内CLI、package script、MCP server経由のactionなど、denylistに見えにくい経路もあります。Profile、Rules、review、loggingを組み合わせます。

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

最初から大量に入れる必要はありません。Agent Modeの基本動作、command承認、diff reviewが安定してから、必要なserverだけを追加します。read-onlyに近いserverから始めると扱いやすいです。

RulesとAGENTS.mdはどう分けますか？

WarpのRulesはWarp Drive側のcontextとして管理しやすく、project ruleはcodebaseに近い場所で共有しやすいです。すでにrepositoryにAGENTS.mdやWARP.mdを置く運用があるなら、project固有の規約はrepository側、個人やteam横断の方針はWarp Drive側に分けます。

AiderやClineと比べて何が違いますか？

Aiderはterminal-firstでGit repo編集に強く、ClineはIDE内のagent体験やMCP連携を中心に見やすいです。Warp Agent Modeはterminal体験そのものにAgentを重ねるため、command、running process、Warp Drive context、Profile権限が設計の中心になります。

---

次に読むなら

参照した主な情報源

• https://docs.warp.dev/agents/agents-overview
• https://docs.warp.dev/agents/using-agents
• https://docs.warp.dev/agent-platform/capabilities/agent-profiles-permissions/
• https://docs.warp.dev/knowledge-and-collaboration/warp-drive/agent-mode-context
• https://docs.warp.dev/knowledge-and-collaboration/warp-drive/ai-objects
• https://docs.warp.dev/agent-platform/capabilities/mcp/

次に読むなら

更新履歴

1. 2026年6月1日

   Warp公式docsのAgent Profiles、Permissions、Agent Mode Context、MCPを確認して初版を作成しました。

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

• 2026年6月1日: Warp公式docsのAgents、Profiles & Permissions、Agent Mode Context、AI-Integrated Objects、MCPを確認し、初版を作成しました。