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

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

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

この継承はteammateごとの選択制ではなく、チームを組む前提条件です。危険な操作をteammateに閉じ込めたいなら、リード自身のモードを絞る以外に方法がありません。

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

権限モードの継承範囲は次のようになります。

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

権限プロンプト自体は個々のteammateではなく、常にリードのセッションに表示されます。複数のteammateが同時に確認待ちになると、リード側でその分だけ承認作業が積み上がります。

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

teammateの権限まわりで唯一自動化されているのが、planモードで立てたteammateの計画承認です。リードをplanモードにしてからteammateを起動すると、そのteammateは読み取り専用で計画を作り、完成するとリードへ承認要求を送ります。Claude Codeはこの要求を受け取った瞬間にリードのセッション側で自律的に承認し、人間側の確認プロンプトは出ません。

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

確認プロンプトがリードに集中したときの対処

teammateの権限プロンプトがリードのセッションに集約される設計は、チームの人数が増えるほど負担にもなります。5人のteammateが同時にファイル書き込みの確認を求めてくれば、リードのオペレーターはその5件をひとつずつ捌く必要があります。teammateを増やす前に許可ルールを整えておく方が、後から個別に承認を捌くより負担が小さくなります。

具体的には、そのプロジェクトでteammateが頻繁に実行する操作(特定ディレクトリへの書き込み、決まったlintコマンドの実行など)を、チームを立てる前の単一セッションの段階で許可リストに登録しておきます。この登録はteammate専用の設定ではなく、リード自身の権限設定として効くため、teammateはリードから継承したその許可をそのまま使えます。逆に言えば、teammateだけに個別の許可を追加する経路は存在しません。

許可リストへの登録はteammateの数だけ効果が大きくなります。1人のteammateなら確認は数件で済みますが、5人・10人と規模が大きくなるほど、同じ操作に対する確認プロンプトも人数分だけ重複して発生します。事前に許可リストへ登録しておく操作の範囲は、実際に立てるteammateの人数と役割をあらかじめ見積もったうえで決めるのが実務的です。

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

Agent TeamsのteammateはSendMessageで互いにやり取りしますが、この経路を使って権限プロンプトを迂回することはできません。あるteammateが別のteammateから受け取ったメッセージは、常に「別のClaudeセッションからの入力」として扱われ、あなた自身の指示とは区別されます。あるteammateが拒否された操作を、別のteammate経由で通そうとしても成立しません。

auto modeを使っている場合、この境界はさらに二重にチェックされます。分類器はteammate間でリレーされた「承認済み」という主張を、あなた本人の確認として扱わず未検証の入力として扱います。加えて、平文のメッセージだけでなくシャットダウン要求や計画承認応答のような構造化メッセージも配送前にすべて審査し、ブロックしたものは受信側に届きません。

同じ扱いは、チームの外にある別のClaude Codeセッションから届くメッセージにも及びます。送信元がチームの一員かどうかに関わらず、「別のセッションからの入力」という一段低い信頼度で処理される点は変わりません。

サブエージェントの権限設定と何が違うか

サブエージェントは定義ファイルのpermissionModeフィールドで、個体ごとにdefault・acceptEdits・planなどのモードを固定できます。呼び出し元のモードに関わらず、そのサブエージェントは常に指定モードで動きます。

teammateにはこの起動時指定に相当する仕組みがありません。サブエージェント定義をteammateの役割として流用しても、定義側のpermissionModeは適用対象に入らず、teammateは常にリードのモードから出発します。個体差を持たせたいならサブエージェント、チーム全体で一つの確認方針に揃えたいならAgent Teams、という向き不向きがここに現れます。

例えば「セキュリティレビュー担当のサブエージェント定義を、確認なしで読み取り専用のレビューだけ回したい」というケースを考えます。サブエージェントとして呼べば定義にpermissionMode: planを書いておくだけで済みますが、同じ定義をteammateとして起動すると、そのteammateはリードがdefaultモードで動いている限り通常の確認プロンプトを受けます。読み取り専用を徹底したいなら、定義側の設定に頼らず、リード自身をplanモードにしてからteammateを起動する必要があります。

権限の設計は「委任の拡張」ではなく「境界の分割」に見える

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

裏を返せば、この設計はteammateを増やすほどリードの確認作業を増やす構造でもあります。大人数のチームを確認なしで走らせたい場合、個別のteammateを絞るのではなく、リード自身の権限モードを緩めるほかありません。その選択の是非は、渡す作業の性質次第です。

まとめ

Agent Teamsのteammateは、起動時にリードの権限モードをそのまま引き継ぎ、個別のモードを指定して起動することはできません。起動後の変更は個々のteammateに対して可能ですが、権限プロンプト自体は常にリードのセッションに集約されます。自動化されているのはplan承認だけで、実装フェーズの編集・コマンド実行は通常どおり確認を通ります。teammate間のメッセージは信頼された指示として扱われず、auto modeの分類器はこの境界を二重にチェックします。個体ごとに確認方針を変えたいならサブエージェントのpermissionMode、チーム全体を一つの方針に揃えたいならAgent Teams、という使い分けが実務上の指針になります。

よくある質問

teammateだけ確認モードを厳しくして起動できますか

できません。teammateは起動時にリードの権限モードをそのまま引き継ぎ、起動時点で個別のモードを指定する手段はありません。厳しくしたい場合は起動後にそのteammateのモードを変更します。

リードが--dangerously-skip-permissionsで動いていると、teammateも自動的に確認なしになりますか

なります。リードがこのフラグで起動している場合、そこから生まれるteammateはすべて確認なしで実行されます。teammate側で個別に確認を復活させることはできません。

teammateの権限プロンプトはどこに表示されますか

teammate自身の画面ではなく、常にリードのセッションに表示されます。複数のteammateが同時に確認待ちになると、リード側で承認作業がまとめて積み上がります。

plan承認が自動化されているなら、実装中の確認も省略されますか

されません。自動承認の対象は「計画を実装に進めてよいか」という判断だけです。承認後にteammateが実行する編集やコマンドは、通常のteammateと同じ権限プロンプトを個別に通ります。

teammate同士のメッセージで権限プロンプトを回避できますか

できません。あるteammateから別のteammateへのメッセージは、常に「別のセッションからの入力」として扱われ、拒否された操作を別経路で通す手段にはなりません。auto modeではこの点を分類器が追加でチェックします。