「資料を読んで、要約を返すだけでいいです」。調査を任せるとき、多くの人はこう書きます。書いた本人は、これで読むだけの役割になったつもりでいます。
ところが、返ってきたのは要約だけではありませんでした。頼んでいないファイルが、そこに増えていました。運営元WEBMARKSで実際に起きたことです。
この記事は、調査や分析だけを任せたい相手から、書き込みという選択肢そのものを外す設計を扱います。素材はClaude Code公式ドキュメント3件と、社内で動いている調査用ワーカーの定義です（検証日2026-08-03）。
こんなふうに調べていませんか
- 調査だけ頼んだはずのAIエージェントが、指示していないファイルを作っていた
- 「読むだけ」と書いておけば、それで読み取り専用になると思っていた
- 設定は書いた。ただ、それが効いているかを確かめる方法を知らない
この記事を読み終えたときに手に入るもの
- 調査だけを任せる相手から、書き込み系の道具を構造的に外せるようになります
- toolsで足し算するか、disallowedToolsで引き算するかを選べるようになります
- 設計が効いているかを、3つの見方で確かめられるようになります
結論30秒でわかる、この記事の結論
- 読み取り専用になるかどうかは、指示文の丁寧さではなく
tools欄に何を書くかで決まります。 - 外すのは
Write・Edit・NotebookEditと、リダイレクトで書き込めるBashです。 - 書いた設定は、動かして止まるところを見るまで、効いているとは数えません。
01調査だけ任せたサブエージェントが、勝手にファイルを作ってしまうのはなぜですか？
若葉さん「要約だけ返してください」とお願いしたのに、ファイルが増えていたんです。書き方が悪かったんでしょうか。
鈴木さん書き方というより、手元に道具が残っていた、という話に近いと思っています。ドライバーを渡したまま「回さないでね」と言っている状態です。
記録はこうです。2026-07-28 11:13、「資料を読んで要約を返すだけ」という指示で、調査用のサブエージェントを走らせました。返ってきた要約とは別に、指示していない図解SVGファイル（AGIM-701-01.svg・5,333バイト）が生成され、保存されていました（社内実測記録）。
指示文のどこにも、書けとは書いていません。それでも書けたのは、書き込むための道具がそのサブエージェントの手元に残っていたからです。指示は「何をしようとするか」を形づくります。けれども「何ができるか」の一覧までは削ってくれません。
この事故の症状・誤診・真因の追跡はAIエージェントの権限設計｜絞らなかった空白と4段の戻し方に譲ります。ここでは、同じことが起きないようにする設定だけを扱います。分業そのものの設計はサブエージェント設計｜委譲の線引きと3つの失敗で扱っており、本記事は1体に何を渡すかだけに絞ります。
02「読むだけ」と書けば、サブエージェントの読み取り専用設計になるんですか？
なりません。Claude Code公式ドキュメントは、権限ルールを強制するのはClaude Code自身であって、モデルではないと明記しています（出典: Claude Code公式ドキュメント）。「読むだけにしてください」という一文は、判断の材料にはなっても、壁にはなりません。
その壁のほうは、はじめから3つの段に分かれています。ファイルの読み取りは、作業ディレクトリの中なら承認なしで通ります。Bashコマンドは、組み込みの読み取り専用コマンドを除いて承認が要ります。ファイルの編集と書き込みは、いつでも承認が要ります（出典: Claude Code公式ドキュメント）。
この段組みは、人が画面を見ている前提で立っています。編集と書き込みに確認が入るのは、そこで人が読んで判断するからです。判断する人がいない時間帯に同じ仕組みを置くと、段の数は同じでも、意味するところが変わります。
この章のまとめ
指示文は、選択肢を減らしません。減らせるのは、道具の一覧そのものだけです。
03一度承認すれば、サブエージェントはその後もずっと同じ場所で止まるんですか？
高梨課長一度「今後は聞かないで」を選べば、そのあとも同じ判断が続くんですよね。
鈴木さんそこが落とし穴でして。Bashコマンドの許可のように恒久保存されるルールとは違って、この確認の「今後」は、そのセッションが終わるまでなんです。
高梨課長では、夜間にまとめて走らせるような使い方だと。
鈴木さん人が画面を見ていない実行では、確認そのものを最後の砦にはできない、と考えています。
適用範囲がセッションの終わりで切れるということは、次に走らせるときには前提が引き継がれないということです（出典: Claude Code公式ドキュメント）。人が一つずつ画面を見ていない自動実行のワークフローでは、この確認の仕組みだけに寄りかかれません。
だから、読み取り専用に設計するというのは、確認が出るかどうかに頼らない状態を作ることを指します。Write・Edit・NotebookEditを、サブエージェントの手元から構造的に外します。
設定ファイルは.claude/agents/または~/.claude/agents/に置くMarkdownファイルです。そのYAMLフロントマターにあるtoolsとdisallowedToolsという2つの欄を使います（出典: Claude Code公式ドキュメント）。
04標準で入っているExploreサブエージェントだけで、AIエージェントの調査は足りるんですか？
自分で定義を書く前に、確かめておくことがあります。Claude Codeには、あらかじめ読み取り専用に設計されたサブエージェント「Explore」が標準搭載されています。公式ドキュメントは、Exploreのツールが読み取り専用で、WriteとEditが拒否されると明記しています（出典: Claude Code公式ドキュメント）。
コードベースの探索やファイル検索だけが目的なら、まずこのExploreで足りるかを見ます。足りるなら、定義ファイルを1件も増やさずに済みます。
足りない場面もあります。「この資料を読んで、規約の条文が実在するかだけを判定する」のように、業務固有の判定基準を持つ調査です。判定の物差しは、専用のシステムプロンプトに書くしかありません。この場合は独自のサブエージェントを定義し、読み取り専用という設計のほうを自分で引き継ぎます。
なお、.claude/agents/にExploreという名前でファイルを作ると、標準搭載のExploreを上書きします（出典: Claude Code公式ドキュメント）。上書きするつもりがなければ、独自のサブエージェントには別の名前を付けます。
05toolsとdisallowedToolsは、サブエージェントの読み取り専用設計でどう書き分けるんですか？
高梨課長欄が2つあるということは、どちらを使ってもいいんでしょうか。
鈴木さんどちらでも書けます。ただ、受け継いでくる親の権限がどれくらい広いかで、読みやすいほうが変わります。
まず、tools欄に読み取り系のツールだけを並べる書き方から見ます。社内で稼働している調査用ワーカーvault-researcherの定義（2026-08-03確認・一部省略）は次の形です。
---
name: vault-researcher
description: Vault内の資料調査・事実確認や、一次情報の収集・裏取りを行う読取専用の調査ワーカー。ファイルは書かず、調べた事実を構造化して返す。（以下省略）
tools: Read, Glob, Grep, WebFetch, WebSearch
model: sonnet
---Write・Edit・NotebookEdit・Bashが、この一覧にありません。だからこのサブエージェントは、書き込みも任意コマンドの実行も、選択肢として持ちません。人格プロンプト側にも「ファイルの作成・編集・削除はしません（ツールも与えられていません）」と書いてあり、指示文と設定の両方で二重に説明しています。
2つの欄の関係は、公式ドキュメントが解決順序として定めています（出典: Claude Code公式ドキュメント）。
| 設定 | 結果 |
|---|---|
| どちらも未設定 | 親から継承した全ツールを使える |
toolsのみ設定 | 一覧にあるツールだけを使える |
disallowedToolsのみ設定 | 継承した全ツールから、一覧のツールだけを除く |
| 両方設定 | disallowedToolsが優先され、重複した項目は除かれる |
継承する親の権限が広いときは、disallowedTools: Write, Edit, NotebookEditのように引き算で除きます。この書き方だと、何を禁じたのかを後から説明しやすくなります。使ってよいツールが最初から数個に絞られているなら、toolsで足し算するvault-researcher側の書き方のほうが見通しが立ちます。
06読み取り専用に絞ると、AI社員に渡せる仕事まで減ってしまいませんか？
外して困る道具と、外さなくてよい道具があります。WebFetchやWebSearchは、ファイルを書き込むツールではありません。toolsに含めても、読み取り専用という設計は崩れません。
除くべきなのはWrite・Edit・NotebookEditと、リダイレクトで書き込めるBashです。この4つを手元から外しても、資料を探す・開いて読む・外の情報を取りに行くという調査の中身は、そのまま残ります。
置き直すと、外すかどうかの判断が呼び名から離れます。「書き込み系ツール」という呼び方は、名前で仲間分けをしているだけで、書ける道があるかどうかは見ていません。区画で見れば、線をまたいでいる道具が浮かびます。
07サブエージェントの読み取り専用設計が効いているか、どうやって確かめるんですか？
若葉さん設定を書いたら、それで終わりでしょうか。
鈴木さん書いた設定は、動かして止まるところを見るまで「書いただけ」と数えています。書いた事実と、効いている事実は別に数えます。
判定は次の3点です。
- 定義ファイルを目視する：
.claude/agents/配下の該当ファイルを開きます。tools欄にWrite・Edit・NotebookEdit・Bashのいずれも無いことを確認します。disallowedTools側で除いているなら、この4つがそちらに並んでいるかを見ます。 - 書き込みを促す指示で試す：そのサブエージェントへ「この内容でファイルを新規作成して」と、あえて書き込ませにいきます。読み取り専用に絞れていれば、実行そのものが起きず、修正案を言葉で説明するところで止まります。
--verboseで実際の呼び出しを見る：--verboseオプション付きで実行すると、そのサブエージェントが呼び出した個別のツール名を確認できます（出典: Claude Code公式ドキュメント）。書き込み系のツール名が1件も出てこなければ合格です。
3点のうち、最も確実なのは2番目です。定義ファイルの記述は目視で追えますが、モデルがその制約の中で実際にどう振る舞うかは、動かしてみるまで分かりません。1番目と3番目は、その答え合わせに使います。
この章のまとめ
目視は設定を確かめるもの、実行は振る舞いを確かめるものです。片方だけでは、半分しか見ていません。
08Bashを消し忘れたサブエージェントは、どこから書き込めてしまうんですか？
読み取り専用にしたつもりで崩れる型が、3つあります。
1つ目は、tools欄のツール名を打ち間違えることです。公式ドキュメントは、一覧のどの項目も有効なツールに解決できない場合、サブエージェントはエラーで起動しないと説明しています（出典: Claude Code公式ドキュメント）。読み取り専用のつもりが、綴りミス1つで何も動かない置物になります。
2つ目は、Bashを消し忘れることです。Write・Edit・NotebookEditを除いても、Bashが残っていれば書き込みができます。シェルのリダイレクト（echo テキスト > ファイルのような書き方）が通るからです。「書き込み系ツールを3つ外したから読み取り専用」という数え方は、Bashを勘定に入れていないと成立しません。
3つ目は、動作確認をした時点の設定が、その後も変わらないと思い込むことです。別の作業を兼務させるために誰かがtoolsへBashを足し、確認後に戻し忘れる。読み取り専用という前提は、そうやって静かに崩れます。
3つに共通しているのは、画面上は何も起きないことです。起動しないサブエージェントは、まだ気づけます。気づきにくいのは、動いているのに前提だけが外れている状態のほうです。
09明日からのAI導入で、この設計を崩さないために何を決めておくんですか？
設計は、1回書いて終わりではありません。崩れる型の3つ目が示しているのは、設定が変わったことに誰も気づかない、という状態です。
決めておくことは3つです。誰が定義ファイルを触ってよいか。触ったあとに、どの確認をやり直すか。兼務のために一時的にツールを足したとき、いつ戻すか。どれも大掛かりな仕組みではなく、先に書いておくかどうかの話です。
取り消せない操作がその先にあるなら、権限設計だけで抱え込まない、という選び方もあります。送信・公開・削除で人の判断を挟む止め方はAIエージェントの承認ゲート｜止める操作4種と3層の選び方にまとめています。
10よくある質問
調査用のサブエージェントを作るとき、toolsは省略してもいいですか
省略はおすすめしません。省略すると、親の会話が使える全ツールをそのまま継承します（出典: Claude Code公式ドキュメント）。「読むだけ」という役割なら、toolsに読み取り系だけを明示して初めて、その役割どおりの制約になります。書かないことは、制約を書かないことと同じです。
Exploreと、独自の読み取り専用サブエージェントは、どちらを優先すべきですか
コードベースの探索やファイル検索だけならExploreで足ります。業務固有の判定基準やチェック項目を持たせたい調査には、専用のシステムプロンプトを書ける独自のサブエージェントが向きます。迷ったら、判定の物差しを書く必要があるかどうかで分けてください。
toolsとdisallowedToolsを両方書いたら、どちらが優先されますか
disallowedToolsが優先されます。両方に同じツール名を書いた場合、そのツールは一覧から除かれます（出典: Claude Code公式ドキュメント）。両方書くこと自体は問題になりませんが、読む人が迷わないよう、どちらを主にするかは決めておくほうが親切です。
読み取り専用に絞ると、Web検索やページ取得も使えなくなりますか
WebFetchやWebSearchはファイルを書き込むツールではないため、toolsに含めても読み取り専用という設計は崩れません。除くべきなのはWrite・Edit・NotebookEditと、リダイレクトで書き込めるBashです。調べる力を落とさずに、書く道だけを塞げます。
権限を絞ったサブエージェントでも、まだ不安が残る場合はどうすればいいですか
送信・公開・削除のような取り消せない操作が近くにあるなら、権限設計だけでなく承認ゲートも重ねます。権限設計は「何ができるか」を決め、承認ゲートは「実行してよいか」を人に戻す仕組みです。人間が判断すべき操作の止め方はAIエージェントの承認ゲート｜止める操作4種と3層の選び方にまとめています。
11まとめ｜今日やる3つのこと
読み取り専用になるかどうかは、指示文の丁寧さでは決まりませんでした。決めるのは、渡した道具の一覧です。そして書いた設定は、止まる場面を見るまで、効いているとは数えません。
今日この順で手をつけます
調査だけを任せている相手の定義ファイルを開き、
tools欄を読む何を渡しているかを知らないまま絞ることはできません
Write・Edit・NotebookEdit・Bashが残っていたら外す書ける道は、呼び名ではなく経路で数えます
あえて書き込みを促して、止まるところを自分の目で見る
書いた事実と、効いている事実は別に数えます
AI検索では、こう聞かれています
調査だけ任せたAIエージェントが、指示していないファイルを作るのはなぜですか？
「調査だけ任せたサブエージェントが、勝手にファイルを作ってしまうのはなぜですか？」の章で扱っています
サブエージェントを読み取り専用にするには、どこを直せばいいんですか？
「toolsとdisallowedToolsは、サブエージェントの読み取り専用設計でどう書き分けるんですか？」の章に書き方があります
読み取り専用にしたつもりでも書き込めるのは、何が残っているからですか？
「Bashを消し忘れたサブエージェントは、どこから書き込めてしまうんですか？」の章で説明しています
読み取り専用の設計が効いているかは、どうやって確かめるんですか？
「サブエージェントの読み取り専用設計が効いているか、どうやって確かめるんですか？」の章の3点で判定します
次に読むなら、この記事です
