サブエージェントの権限設計｜3軸で絞って手戻りを減らす

「このサブエージェント、どこまで渡しておけばいいんでしょうか」。手元でAIエージェントを分けて動かし始めた人から、よく出てくる質問です。

広く渡せば止まらない。狭く渡せば事故らない。その両方が頭にあるので、どちらにも振り切れないまま、既定のまま動かしている。そういう状態でこの記事にたどり着いた方も多いはずです。

この記事は、権限を「広い・狭い」という1本の物差しで測るのをやめるところから始めます。渡しているものは、指示・権限・参照範囲の3つに分かれています。根拠はClaude Codeの公式ドキュメントと、Anthropicの公式エンジニアリングブログです。

進行役は3人です。若葉さんが用語のそもそもを聞き、高梨課長が自分の手で動かす立場から聞き、鈴木さん（本誌監修）が答えます。

01サブエージェントの権限設計とは、結局どこを絞る話なんですか？

若葉さん

若葉さんの発言

権限を絞る、という言い方はよく聞くんですが、何を絞っているのかが分かりません。設定を1か所きつくすれば済む話ではないんですか。

鈴木さん

鈴木さんの発言

外注先に仕事をお願いする場面を思い浮かべてみてください。渡すものは3つありますよね。依頼書と、貸す道具と、入ってよい部屋。どれか1つを厳しくしても、残りは開いたままなんです。

渡しているものは、指示・権限・参照範囲の3つです。指示は「どこまで自分で決めていいか」を、権限は「何をしてよいか」を、参照範囲は「何を見てよいか」を決めます。

この3つを分けずに広い・狭いだけで決めると、渡しすぎた軸で想定外の動作が起き、絞りすぎた軸で手戻りが増えます。しかも症状は同時に出ます。稼働中のサブエージェントの中に、絞りすぎて使われないまま残っている機能と、広げすぎて誰も気づいていない権限が、同居していることがあります。

軸を分けないままだと、点検の手段が「動いているかどうか」しか残りません。動いているサブエージェントは、絞りすぎていても広げすぎていても、そのまま動き続けます。

Anthropicは、ワークフローとエージェントを設計上分けています（出典: Anthropic公式）。あらかじめ決めた手順でLLMと道具を動かすのが前者、進め方をLLM自身が決めるのが後者です。同じ資料は、まず単純な構成から始め、必要になったときだけ複雑さを足すべきだとも述べています（出典: Anthropic公式）。3つの軸を絞る作業は、この単純さをどこまで保つかを軸ごとに選ぶ作業にあたります。

何体に分け、判断役と実行役をどう置くかという設計思想は『サブエージェント設計｜委譲の線引きと3つの失敗』が扱います。この記事は、分けたあとの1体に何をどこまで渡すかだけを見ます。

02指示は、サブエージェントにどこまで書いて渡せばいいんですか？

高梨課長

高梨課長の発言

指示文は細かく書くほど安全だと思っていました。手順を最後まで書いておけば、変なことはしないはずですよね。

鈴木さん

鈴木さんの発言

手順を全部書き切ると、裁量はゼロになります。ただ、そのぶん想定から外れた瞬間に止まります。書き手が分岐を思いつけなかったところが、そのまま行き止まりになるんです。

指示の絞り方は、手順を何段まで書くかという1点に集約されます。全段書けば裁量はゼロ、目的だけを渡せば裁量は最大です。

Anthropicは、タスクを固定の手順に分解できる場合はワークフローが向くと整理しています（出典: Anthropic公式）。分解できない複雑な調査やコーディングでは、中央のLLMがそのつど分担を決めるオーケストレーター・ワーカー構成が向くとも述べています。指示を絞りすぎる典型は、後者に向く仕事へ前者の書き方を当ててしまうことです。

絞りすぎた指示は、分岐を人が想像しきれなかったところで壊れます。「設定ファイルAを直して報告して」という指示は、Aが2つの階層に分かれていて優先順位を持つ場合、その判断を代行できていません。サブエージェントは指示どおりに動いても、意図と違う階層を直して返します。書き直しは1回では終わらず、階層構造を説明した指示文を渡し直す2回目のやり取りが発生します。

広すぎる指示との境界線は、「やってよい範囲」と「やってはいけない範囲」を1文ずつ書けているかどうかです。この2文があれば、途中の手順を渡さなくても、状況に応じて手順を選べます。委譲プロンプトそのものの型は、ゴール・スコープ・入力・出力形式・制約・返し方の6項目に整理できます。ここで扱うのは、そのうち「どれだけ具体的に書くか」という程度だけです。

境界を渡さない指示には、もう1つの副作用があります。同じ目的のサブエージェントを並行させたとき、境界がなければ、それぞれが同じ調査や同じ下書きを重ねる確率が上がります。単体では起きない重複が、並列に切り替えた瞬間に表面化します。

03サブエージェントのtoolsは、どこから広げていくんですか？

権限の絞り方は、toolsフィールドに何を並べるかで決まります。Claude Codeの公式ドキュメントは、このフィールドを省略すると利用可能な全ツールを継承すると明記しています（出典: Claude Code公式ドキュメント）。書かないことは、絞ったことになりません。既定はいちばん広い状態です。

---
name: read-only-checker
description: 指定されたファイルを読み、条件に合うかどうかだけを判定して返す。書き込みはしない
tools: Read, Grep, Glob
---

WriteやEdit、Bashを一覧に含めなければ、このサブエージェントは書き込みも任意コマンドの実行も構造的にできません。Claude Codeの組み込みサブエージェント「Explore」も同じ設計です。公式ドキュメントは、Exploreのツールが読み取り専用で、WriteとEditが拒否されると明記しています（出典: Claude Code公式ドキュメント）。

広げる基準は、本数を先に決めることではありません。読み取り専用のまま最後まで完了できるかを、先に1回試すことです。完了できなければ、足りなかった1つだけを足して再実行します。まとめて広げると、どのツールが本当に必要だったのかが分からなくなります。

絞りすぎたときの症状は、広げすぎたときと対称です。読み取り専用のサブエージェントに「ファイルを直しておいて」と頼むと、修正案を言葉で説明するところまでしか進みません。ディレクター役が権限不足に気づき、Editを足した別のサブエージェントへ渡し直す2手目が発生します。これも手戻りの一種です。

逆に広げすぎた場合は、想定していない書き込みや実行がそのまま通ります。自社でこの事故が起きた経緯は『AIエージェントの権限設計｜絞らなかった空白と4段の戻し方』にまとめました。この記事が扱うのは、その再発防止に要る絞る側の目安の作り方です。

04参照範囲は、サブエージェントに何をどこまで見せる話ですか？

高梨課長

高梨課長の発言

権限を読み取り専用にしたので、安全側に倒したつもりでいます。あとは見せる範囲まで気にしなくていいですよね。

鈴木さん

鈴木さんの発言

そこが分かれ目です。読むだけでも、見えてはいけないものが見えていれば境界は越えています。道具を貸さないことと、部屋の鍵を渡さないことは別なんです。

参照範囲は、サブエージェントが読んでよい情報の広さです。ツールの権限が何をしてよいかを決めるのに対して、参照範囲は何を見てよいかを決めます。書き込み権限をゼロにしても、参照範囲が広いままなら、読み取りだけで起きる問題は残ります。

Claude Codeの権限ルールは、ツール名だけでなく、対象を絞り込む書き方（specifier）を持ちます。公式ドキュメントは、パスを指定するRead(./.env)のような書き方を例示しています（出典: Claude Code公式ドキュメント）。ドメインを指定するWebFetch(domain:example.com)も、同じ仕組みの一部です。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./confidential/**)"
    ],
    "allow": [
      "WebFetch(domain:code.claude.com)"
    ]
  }
}

読み取り専用のツールは、既定では承認なしに動きます（出典: Claude Code公式ドキュメント）。対象は作業ディレクトリとadditionalDirectoriesに指定した範囲です。参照範囲を絞る一次的な手段は、toolsの取捨選択ではなく、どのディレクトリをその範囲に含めるかという設計になります。

05参照範囲を狭めると、サブエージェントの何が一緒に変わるんですか？

Readのdenyルールには副次効果があります。公式ドキュメントは、同じパスに対するEditも道連れにブロックすると明記しています（出典: Claude Code公式ドキュメント）。参照範囲を絞ると、そのパスへの書き込みリスクの一部も一緒に閉じます。2つの軸が実装レベルで重なる場面です。機密をそもそも読ませない境界の作り方は『AIエージェントに機密情報を渡さない｜3段階の分離と検査』のフォルダ構成が具体例になります。

広げすぎた参照範囲は、コストにも出ます。Anthropicの計測では、マルチエージェント構成は通常のチャット対話に比べて約15倍のトークンを消費します（出典: Anthropic公式）。参照範囲を絞るほど読み込む情報量は減り、消費するトークンもそれに応じて減ります。

絞りすぎると、今度は裏取りができないまま結論を書くことになります。検証環境の記述は、公式ドキュメントのURLだけを渡しても書けません。自社の設定ファイルを実際に読ませて、両者が一致しているかまで確かめる必要があります。参照先を1件しか渡さなければ突合そのものが実行できず、後段で食い違いが見つかり、参照先を追加して書き直す2回目の作業が発生します。

063つの軸は、サブエージェントの権限設計でどう並べるんですか？

軸を毎回ゼロから考え直さないために、着手時の順番を固定します。指示を書けるか確かめ、ツールは読み取りだけで始め、参照範囲は作業ディレクトリに閉じ、止まったところだけを1段階動かす。この並びです。

順番には理由があります。指示が広いままだと、止まった原因が権限なのか参照範囲なのかを切り分けられません。権限より先に参照範囲を広げると、読めるようになったから動いたのか、もともと権限の側で止まっていたのかが分からなくなります。狭いところから1つずつ動かすと、広げた理由をあとから説明できる状態が残ります。

最初から広い構成で始めると、どの権限が必要で、どの権限が余っていたのかが分からないまま運用が固定されます。Anthropicは、複雑さは実際に必要になってから足すべきだと述べています（出典: Anthropic公式）。権限の絞り方も、同じ原則に従います。

07絞りすぎか広げすぎかは、サブエージェントの様子から見分けられますか？

若葉さん

若葉さんの発言

動いてはいるけれど、これが正しい広さなのかが分かりません。何を見れば気づけるんでしょう。

鈴木さん

鈴木さんの発言

返ってくるものが変わります。絞りすぎているときは手戻りの形で、広げすぎているときは事故の形で出ます。同じ「うまくいっていない」でも、顔つきが違うんです。

絞りすぎも広げすぎも、止まらずに動いているあいだは見えません。判定は、軸ごとの兆候を確かめて行います。

3つの軸を同時に疑わないことが、判定を早くする方法です。症状が指示に出ているのに権限を広げても直りません。表と照らしてどの軸の症状かを先に決め、その軸だけを1段階動かします。

08サブエージェントに権限を渡すとき、AI導入の現場ではどこでつまずくんですか？

高梨課長

高梨課長の発言

動作確認のときだけBashを足したんですが、そのままにしてあります。動いているので、困ってはいません。

鈴木さん

鈴木さんの発言

困るのは次に呼ぶ人です。なぜそこにBashがあるのかを説明できる人が、もういない状態になります。

つまずきは3つに整理できます。

1つ目は、権限だけを絞って安心することです。toolsを読み取り専用にしても、渡した参照範囲に機密が含まれていれば、読み取っただけで境界を越えます。3軸は独立しているので、1軸を絞った達成感が、残り2軸の点検を止めさせます。

2つ目は、広げた権限を元に戻さないことです。動作確認のために一時的にBashを足し、確認後も一覧をそのままにする運用があります。次に呼ぶ人にとっては、理由の分からない権限がそこに残ります。

3つ目は、指示文の追加だけで境界を作った気になることです。Claude Codeの公式ドキュメントは1点を明記しています。権限ルールを強制するのはClaude Code自身であり、モデルではないという点です（出典: Claude Code公式ドキュメント）。指示文に「読むだけにしてください」と書いても、toolsにツールが残っていれば、その操作自体は実行できます。指示文は振る舞いを導くだけで、境界そのものにはなりません。

09担当業務が変わったサブエージェントは、AI社員の権限をどう見直すんですか？

判定は初回の設計時だけでは足りません。担当業務が変わるたびに行います。業務が変わってもtoolsや参照範囲を使い回すと、前の業務向けに広げた権限がそのまま残ります。次の担当業務でその広さが要らなくても、絞り直さない限り自然には狭まりません。

見直しの入口は、担当業務の変更そのものです。名前と説明文を書き換えるときに、toolsの一覧と参照範囲も同じ場で見直します。説明文だけを新しい業務に合わせると、渡している権限は前の業務のまま残ります。

もう1つの入口は、動作確認のあとです。確認のために足した権限は、確認が終わった時点で戻します。戻す作業を後回しにすると、次に見た人には、最初からその広さだったように見えます。

10サブエージェントの権限設計は、着手前に何を確かめるんですか？

着手前と運用中に、同じ項目を通します。設計が終わった時点で1回だけ通すものではありません。担当業務を変えたとき、動作確認で権限を足したとき、並列で動かし始めたときに、もう一度同じ項目を通します。

• 指示に、目的とやってはいけない範囲をそれぞれ1文で書いたか
• toolsを読み取り専用から始め、書き込み・実行系を省いた状態で1回試したか
• 参照範囲を作業ディレクトリとadditionalDirectoriesの範囲で先に試したか
• 機密を含むパスをReadのdenyルールで明示的に除外したか
• 止まった軸だけを1段階広げ、他の軸を同時に広げていないか
• 動作確認のために広げた権限を、確認後に元へ戻したか
• 指示文の追加を、toolsやdisallowedToolsによる境界の代わりにしていないか
• 絞りすぎ・広げすぎのサインを、軸ごとの表と照らして定期的に見直しているか

11よくある質問

12まとめ｜今日やる3つのこと

絞る場所は3つに分かれていて、出てくる症状も軸ごとに違いました。最後は、いちばん狭いところから始める順番だけを持ち帰ってください。