Claude Code Agent Teams権限モデル — teammateへの継承範囲

teammateはリードの権限モードをそのまま継承する

Agent Teamsのteammateは、起動した瞬間にリードセッションの権限モードで動き始めます。リードが--dangerously-skip-permissions(内部的にはbypassPermissionsモード)で動いていれば、そこから生まれたteammate全員も確認なしで実行します。teammateごとに別のモードを指定して起動することはできません。

危険な操作をteammateに閉じ込めたいなら、リード自身のモードを絞るのが出発点です。継承は個別に選ぶ仕組みではなく、チームを組む前提条件だからです。

v2.1.287のclaude --helpには、モードの選択肢と、bypassを「選べるだけ」にするフラグが載っています。該当部分の抜粋です。

claude --help

--allow-dangerously-skip-permissions  Enable bypassing all permission checks
                                      as an option, without it being enabled
                                      by default. Recommended only for
                                      sandboxes with no internet access.
--permission-mode <mode>              Permission mode to use for the session
                                      (choices: "acceptEdits", "auto",
                                      "bypassPermissions", "manual",
                                      "dontAsk", "plan")

--allow-dangerously-skip-permissionsはモード切り替えの候補にbypassを加えるだけで、有効にはしません。teammateが引き継ぐのは、リードがいま動いているモードです。

引き継がれないモードが1つある

継承には例外があります。リードがdontAskモード(確認が必要な操作をすべて自動で拒否するモード)で動いていても、teammateはそのモードを引き継ぎません。CI向けの厳格な構成をそのままteammateに広げられるわけではない、ということです。

なお、-pを付けた非対話モードではteammateそのものが起動しません。Claudeが名前を付けたサブエージェントも、通常のサブエージェントとして動きます。

起動時に決まること、起動後に変えられること

権限まわりの操作は、タイミングで使える手段が分かれます。

「起動時に一括継承、起動後は個別調整」という順序が固定されている点が要になります。確認の頻度を抑えたいなら、teammateを立てる前に許可ルールを/permissionsで整えておくのが手前の一手です。

リードを--setting-sourcesで絞って起動した場合は、teammateも同じ設定ソースだけを読みます。v2.1.281より前は、分割ペインのteammateがすべての設定ソースを読んでいたので、古い版では絞り込みがそこだけ及びません。

plan承認だけが自動化された例外

teammateの権限まわりで唯一自動化されているのが、planモードで立てたteammateの計画承認です。リードをplanモードにしてからteammateを起動すると、次の順に進みます。

見落としやすいのは承認の範囲です。自動で通るのは「計画を実装に進めてよいか」という判断だけで、実装に入ったあとの編集やコマンドは、通常のteammateと同じ権限プロンプトを個別に通ります。計画承認を「以降の操作もまとめて許可した」と読み違えると、実装フェーズで想定より多くの確認が挟まります。

承認要求は、構造化メッセージとしてリードのメールボックスに書き込まれて届きます。ディスクが満杯だったり書き込み先のディレクトリに書けなかったりすると、送った側にエラーが返り、要求は送られません。シャットダウン要求や承認の応答も同じ仕組みです。

teammateを絞りたいとき、何が効いて何が効かないか

権限を絞る手段は複数ありますが、teammateに対して効くものと効かないものがあります。

効くのは次の3つです。

• リード自身のモードを絞る(継承の起点)
• 起動後に、個々のteammateのモードを変える
• サブエージェント定義を役割に流用し、定義のtoolsでteammateが使える道具を限る

3つ目は権限モードではなく道具の制限です。定義のtoolsに並べたものだけがteammateの手元に残り、インプロセスのteammateにはSendMessageが、TaskツールのあるセッションではTaskCreateなどのタスク系ツールが、それぞれ自動で加わります。

効かないのは、起動時のモード指定と、定義ファイルのpermissionModeで個体ごとに固定する書き方です。次の節で、サブエージェントとの違いを並べます。

サブエージェントのpermissionModeとは別物

サブエージェントは定義ファイルのpermissionModeで、default・acceptEdits・planなどのモードを個体ごとに指定できます。ただし固定が効くのは、メインの会話がbypassPermissions・acceptEdits・autoモードのいずれでもないときだけです。いずれかで動いていると、サブエージェントはそのモードで走り、定義側の指定は無視されます。指定を省くと、メインの会話のモードを引き継ぎます。

たとえば「読み取り専用のレビューだけを回すセキュリティレビュー担当」を考えます。サブエージェントなら定義にpermissionMode: planと書けば足ります。teammateにするなら、定義側の設定に頼らず、リードをplanモードにしてから起動します。リードがdefaultモードのままなら、そのteammateは通常の確認プロンプトを受けます。

autoモードのメイン会話では、分類器がサブエージェントのツール呼び出しをメイン会話の許可・ブロックのルールで評価します。サブエージェントが終わると、成果物と最終報告も配送前に審査されます。

プラグインが配るサブエージェントは、そもそもpermissionMode・hooks・mcpServersが無視されます。必要なら定義ファイルを.claude/agents/か~/.claude/agents/へコピーします。

定義を使うなら、フォルダの信頼にも注意

プロジェクトの.claude/agents/にある定義は、そのフォルダを信頼済みにしていないと、停止していたteammateを呼び戻すときに再適用されません。親フォルダを信頼していても数に入りません。再適用されないteammateは、次の通知とともに、定義のtoolsも指示も持たない状態で戻ってきます。

Its agent definition was not restored: the folder its definition file came from is not trusted (source: projectSettings), so the teammate is running with the team-essential tools and no custom instructions.

定義のtoolsと指示は失われ、残るのはインプロセスのteammateに共通して加わるツールだけです。対処は、通知が示すフォルダでclaudeを一度起動し、信頼ダイアログを承認することです。

組織の許可リストはteammateのモデル選びにも及ぶ

権限モード以外にも、リードから引き継ぐものがあります。teammateは、リードの推論の強さ(effort)を引き継ぎます。teammateに選ばれたモデルは、組織のavailableModelsの許可リストで照合されます。

許可リストに阻まれると、リードのモデルに置き換える前に、環境変数CLAUDE_CODE_SUBAGENT_MODELの値が試されます。それでも通らなければ、opusのようなファミリー名はその系統で許可された最新のモデルに、それ以外の値はリードのモデルに置き換わります。

ファミリー名の置き換えが働くのは、Anthropic APIとClaude Platform on AWSを使う環境です。プロバイダ固有のモデルIDを使う環境や、その系統に許可されたモデルがない場合は、ファミリー名もリードのモデルになります。

確認プロンプトがリードに集まるとき

teammateの権限プロンプトは、常にリードのセッションに出ます。承認の窓口がリード1か所に絞られる反面、teammateを増やすほどリードの画面に確認が並びます。

確認の量を左右するのは、リードのモードと、チームを立てる前に整えた許可ルールです。

もう1つ、リードとの会話履歴はteammateに引き継がれません。teammateが受け取るのは、リードが渡す起動時の指示文だけです。権限に関わる条件を会話で伝えていても、teammateには届きません。

teammate間のメッセージは信頼された指示として扱われない

teammateはSendMessageで互いにやり取りしますが、この経路で権限プロンプトを迂回することはできません。Claude Codeは受け取った側に、メッセージが別のClaudeセッションから来たもので、あなたからのものではないと伝えます。teammateは、あなたに代わって権限プロンプトを承認することも、同意を与えることもできません。拒否されたteammateが、別のteammateに頼んで検査を回避することも成立しません。

同じ扱いは、チームの外にあるあなた自身の別のClaude Codeセッションから届くメッセージにも及びます。

auto modeでは、分類器がこの境界を2つの観点で見ます。

• 他のエージェントから中継された「承認済み」という主張は、あなた本人の確認ではなく、未検証の入力として扱う
• 平文のメッセージに加え、シャットダウン要求やplan承認の応答のような構造化メッセージも、配送前にすべて審査する。ブロックされたメッセージは受信側に届かない

権限の設計は「委任の拡張」というより「確認責任の分割」に近い

Agent Teamsの権限モデルは、ワーカーに仕事を任せる仕組みというより、1つの確認責任をどこで分けるかの設計に見えます。継承を一括にして起動時の個体差をなくし、承認の窓口をリードに一本化し、エージェント間のメッセージを一段低い信頼度に固定する。3つの制約は、teammateが増えても「誰が何を承認したか」を追える方向にそろっています。

代償もあります。確認なしで大人数のチームを走らせるには、個別のteammateを緩めるのではなく、リードのモードを緩めるしかありません。どこまで緩めるかは、渡す作業の性質次第です。

まとめ

確認の責任はリードに集まる設計なので、手を入れる先はリードのモードと事前の許可ルールになります。個体ごとに確認方針を変えたい仕事は、teammateではなくサブエージェントに回す、という切り分けが素直です。