「資料を読んで、要約して、返すだけ」。そう書いて走らせたAIエージェントが、頼んでいないファイルをディスクに書いていました。WEBMARKSで実際に起きたことです。
エラー画面は出ていません。作業も終わっています。生成物の中身を確かめても壊れていませんでした。それでも説明のつかない点が残ります。読むだけの指示で、なぜ書き込みが通ったのか。
この記事は、その事故を症状・誤診・真因の順で追います。最初に犯人あつかいされたのは、誰かが広げた自動承認の設定でした。ところが、広がっていたのは設定ではありませんでした。
本記事の検証環境：Claude Codeのサブエージェント実行／社内リポジトリ git commit 60e639be の記録／2026-07-28の事故・2026-07-29計測。
こんなふうに調べていませんか
- 読むだけのつもりで走らせたAIエージェントが、勝手にファイルを作っていた
- 権限をどこまで絞ればいいのか、決め方が分からないまま運用が広がっている
この記事を読み終えたときに手に入るもの
- 「広げた記録が無い」を安全の根拠にしなくなります
- 指示文で導ける範囲と、権限でしか止められない範囲を分けて言えるようになります
- 新しいサブエージェントに渡すツールを、役割の側から決められるようになります
結論30秒でわかる、この記事の結論
- 権限設計は、広げた日ではなく、絞らなかった日に壊れます。
- 指示文はふるまいを導きますが、できることの範囲そのものは動かしません。
- 直すのはモードの点検ではなく、既定値を絞る手順のほうです。
進行役は3人です。高梨課長が自分の手で設定を書く側を、大森部長が任せる範囲を決める側を、鈴木さん（本誌監修）が答える側を担当します。
01「読むだけ」と指示したのに、AIエージェントの権限設計はどこで破られたんですか？
高梨課長読むだけの指示なら書き込みは起きない、と思っていました。指示の書き方が悪かったということでしょうか。
鈴木さん書き方の話にすると、同じことがまた起きます。何をするつもりかと、何ができるかは、別の場所で決まっているんです。
2026-07-28 11:13、WEBMARKSは調査目的のワークフローをサブエージェントに走らせました。指示の内容は「資料を読んで内容を要約し、結果を返すだけ」。読み取りだけで完結する作業です（出典: 社内リポジトリ git commit 60e639be の実測）。
このサブエージェントは、指示していない図解SVGファイルを生成し、ディスクへ保存しました。残されたのは AGIM-701-01.svg（5,333バイト・viewBox 800×450）と、キャプション情報の captions.json です。
台帳を開くと、はっきり分かることと、まったく分からないことが混ざっていました。分けて並べます。
| 台帳の項目 | 残っている内容 |
|---|---|
| 走らせた日時 | 2026-07-28 11:13 |
| 指示の内容 | 資料を読んで要約し、結果を返すだけ |
| 実際の生成物 | 図解SVGファイルと、キャプション情報 |
| 直前の権限モード変更 | 記録なし |
| 呼び出し時のツール指定 | 記録なし |
上の3行と下の2行は、性質が違います。上は起きたことの記録で、下は起きなかったことの記録ではありません。書いていないだけで、確かめていない欄です。 ここを「異常なし」と読み替えた瞬間、調査は誤診へ向かいます。
この章のまとめ
最初にやるのは原因の推定ではありません。記録がある欄と、そもそも記録を取っていない欄を、線を引いて分けることです。
02被害が軽微だったAIエージェントの書き込みは、なぜ「たまたま」なんですか？
生成されたSVG自体は壊れていませんでした。内容を検証したうえで、『AIエージェントとは』の記事の1枚目の図解として後日採用されています。結果だけを見れば、無害どころか役に立った書き込みです。
大森部長実害が出ていないなら、運用を止めてまで直す話でしょうか。
鈴木さん今回は、たまたま当たった場所が作業中のフォルダでした。同じ動きでも、当たる場所が変われば結果は変わります。私たちが選べるのは動きのほうで、当たる場所ではありません。
書き込まれた先が納品済みのフォルダや送信キューだったら、と考えると景色が変わります。そこでは、生成物を検証してから採用するという猶予がありません。人の目に触れる前に、外へ出てしまう場所だからです。
つまり被害の大小を決めたのは、設計ではなく着地点です。設計の側は何も変わっていません。AIエージェントの権限設計では、事故の大小より「なぜ止まらなかったか」を先に見ます。
軽微で済んだ事故ほど、記録に残らないまま流れます。今回それを残せたのは、生成物が目に見えるファイルだったからにすぎません。
03「自動承認を広げすぎた」という見立ては、AIエージェントのどこで外れるんですか？
この記録を最初に見たとき、いちばん浮かびやすい説明は「権限設計のどこかを広げすぎた」です。誰かが承認ルールを緩め、書き込みを許可する設定を増やしたのではないか、という見立てになります。
この見立てには理由があります。Claude Codeには、確認なしで承認を進めるモードが複数あります。既定のdefaultのほかacceptEdits・auto・bypassPermissionsなど、合わせて6つです（出典: Claude Code公式ドキュメント）。広いモードで動かしていたのでは、と疑う余地は確かにありました。
ところが社内記録には、この呼び出しの直前に権限モードや許可ルールを変更したというログが残っていません。台帳にあるのは「読むだけの指示だったのに書き込みが起きた」という結果だけです。
| 論点 | 誤診（最初の見立て） | 記録から言えること |
|---|---|---|
| 何が起きたか | 承認ルールをどこかで意図的に緩めた | 変更ログは無く、既定の書き込み権限がそのまま残っていた |
| 疑った根拠 | 自動承認のモードが複数あり、広い方を使えば説明がつく | モード選択の記録自体が残っていない |
| 対策の向き | モード設定を順番に点検する | 個々のモードより、既定値の絞り込み手順を見直す |
「広げた」という能動的な操作の記録が無いまま「広げすぎた」と結論づけるのは早すぎました。広がっていたのは設定ではなく、絞らなかった既定値のほうだったからです。
誤診がやっかいなのは、対策の向きまで一緒に間違える点です。設定を点検する作業を延々と続けても、そもそも触られていない設定からは何も出てきません。
この章のまとめ
「広げた記録が無い」は、安全の証明ではありません。絞った記録があるかどうかを、別に確かめてください。
04AI社員に渡すツールは、権限設計のどこで絞れるんですか？
Claude Codeの権限は3層に分かれます。読み取り専用の操作は、作業ディレクトリ内なら承認が要りません。Bashコマンドは、組み込みの読み取り専用コマンドを除いて承認が要ります。ファイルの編集・書き込みは、常に承認が要ります（出典: Claude Code公式ドキュメント）。
問題は3層目、ファイル書き込みの扱い方にありました。サブエージェントの定義にはtoolsという項目があり、そのサブエージェントが使えるツールを絞り込めます。公式ドキュメントは、この項目を省略すると全ツールを継承すると明記しています（出典: Claude Code公式ドキュメント）。読み取りだけに絞りたいなら、次のように書き出す必要があります。
---
name: investigate-only
description: 資料を読んで要約を返す。ファイルは作らない
tools: Read, Grep, Glob
---toolsを書かなければ、WriteやEditを含む既定の全ツールプールがそのまま渡ります。今回の呼び出しがこの項目をどう設定していたかは、台帳に残っていません。それでも、症状と一致する既定のふるまいが公式ドキュメントに明記されている以上、最有力の説明として扱えます。
最小権限の原則は、この種の事故を防ぐ情報セキュリティの基本概念です。OWASPは、ユーザー・プロセス・プログラムには役割に必要な最小限のアクセス権だけを与えるべきだと説明しています（出典: OWASP公式）。NISTのSP 800-53 Rev.5も、必要最小限の権限だけを与える設計だと定義しています（出典: NIST用語集）。
05指示文に「作らない」と書けば、AIエージェントの権限設計は要らないんですか？
WEBMARKSがこの事故のあとに実施した対応は、調査系ワークフローの指示文に「読んで返すだけ・ファイルを作らない」という一文を明記することでした。生成されたSVGは検証のうえで採用し、運用ルールの側を直す判断です。
高梨課長指示文を直したなら、もう同じことは起きない気がします。何が足りないんでしょう。
鈴木さん足りないのは、やろうとしても届かない状態です。指示文は行き先を書いた紙で、権限は鍵です。紙は読んでもらう前提でしか効きません。
この対応には限界があります。Claude Codeの公式ドキュメントは、権限ルールを強制するのはClaude Code自身であり、モデルではないと明記しています。プロンプトやCLAUDE.mdの指示は、Claudeが何をしようとするかを形づくります。ただし、Claude Codeが何を許可するかは変えません（出典: Claude Code公式ドキュメント）。
つまり「ファイルを作らない」という指示文は、ふるまいを導く一文であって、書き込みツール自体を使えなくする境界ではありません。境界として働くのは、toolsの絞り込み、disallowedToolsの指定、そしてツール呼び出しの直前に発火するPreToolUseフックです。
| 対策の種類 | 具体例 | 強制力 |
|---|---|---|
| 指示文（プロンプト・CLAUDE.md） | 「読んで返すだけ・ファイルを作らない」を明記 | ふるまいを導くだけ。ツール自体は使える |
| 権限設計（tools／disallowedTools） | tools: Read, Grep, Globで明示的に絞る | Claude Code自身がツールをその場から外す |
| PreToolUseフック | 書き込み系ツールにdenyを返すスクリプトを登録 | ツール呼び出しの直前で機械的に止める |
今回の記録に残っているのは、この表の1行目までです。2行目・3行目にあたる技術的な歯止めまで踏み込んだかどうかは、記録の範囲では確認できません。指示文の追加が無意味ということではありませんが、権限設計としては応急処置にとどまります。
06AIエージェントの権限設計を最小権限から広げるとき、何から手をつけるんですか？
広げ方には順番があります。読み取り専用から始め、作業ディレクトリ内の編集、承認つきのコマンド実行、そして送信・公開・削除へと、必要になった分だけ段を上げていきます。
今回の事故を、この段に当てはめてみます。調査ワークフローは、いちばん下の段だけで足りる作業でした。ところがツール指定を書かなかったために、実際には上の段に相当する書き込み能力を持ったまま走っています。段を上げたのではなく、最初から上の段にいた、という形です。
仕組みとして運用に落とすには、次の4点が要ります。
- 役割ごとに
toolsを明示する：調査・要約だけを担うサブエージェントにはtools: Read, Grep, Globのように読み取り系だけを渡し、書き込みが要る役割にだけEdit・Writeを足します disallowedToolsで引き算する選択肢を持つ：継承した全ツールから書き込みだけを外したい場合はdisallowedTools: Write, Editと書けます。外したい対象がはっきりしているときは、こちらが速い書き方です- 送信・公開・削除は
PreToolUseフックで機械的に止める：指示文ではなく、ここに歯止めを置きます - 評価の順序を前提に設計する：ルールの並べ方しだいで、書いたつもりの制限が効かなくなります
この章のまとめ
段を上げるのは、上げる理由が出てきたときです。理由の側から広げると、記録も一緒に残ります。
07足し算と引き算では、AI社員の権限設計はどちらから書くんですか？
渡すものを決める書き方は2通りあります。要るものだけを並べる足し算と、継承した全ツールから外すものを名指しする引き算です。
足し算はtools: Read, Grep, Globのように、その役割に要るものだけを列挙します。書いていないものは渡らないので、足りなければ作業が止まって気づけます。調査・要約のように、要るものを数え上げられる役割に向いた書き方です。
引き算はdisallowedTools: Write, Editのように、外したい対象を名指しします。何をするか読みきれない役割でも、避けたい操作がはっきりしているなら、こちらのほうが速く書けます。
迷ったときは足し算から入ります。引き算は、名指ししそこねた操作がそのまま残る書き方だからです。今回の事故は、そのどちらも書かないまま走った状態で起きています。
08deny・ask・allowの評価順は、AIエージェントの権限設計の現場でどう効いてくるんですか？
PreToolUseフックの判定は、allow（許可）・deny（拒否）・ask（確認）の3つの値で返します（出典: Claude Code公式ドキュメント）。止めるか、通すか、人に聞くか。この3つを、ツールが動く直前に選べるということです。
権限ルールはdeny→ask→allowの順で評価され、最初に一致したルールが結果を決めます。広いallowを先に書いても、denyルールがあれば書き込みは通りません（出典: Claude Code公式ドキュメント）。
この性質は、現場では安心材料として働きます。許可を広めに置いた設定が先にあっても、拒否のルールを足せば、そこから先へは進まないためです。逆に言えば、拒否のルールを書いていない範囲は、広い許可がそのまま効きます。
askは、人間ゲートを機械の側に埋め込む書き方です。止めるほどではないが、無言で通すのも避けたい操作を、確認へ寄せられます。送信・公開・削除のように、やり直しがきかない操作と相性のよい値です。
09使い捨てのAI社員にも、本番と同じ権限設計を渡していませんか？
WEBMARKSは2026-06-24に7部署30体のAI社員体制を統合しました。調査用の使い捨てワークフローにも、本番と同じ書き込み能力が既定で渡る構成のまま、今回の事故は起きています。
大森部長数が増えたら、ひとつずつ権限を決めるのは現実的でしょうか。
鈴木さん数が増えるほど、既定値で配るほうが危なくなります。役割の型ごとに渡すものを決めておけば、増えても決め直す必要はありません。
同じVaultでは、更新時刻を根拠に成果物の所有者を誤認し、3日間で233回誤爆した障害も起きています（出典: 社内タスク台帳）。真因は別ですが、どちらも「既定のままにした空白」が事故を生んだという点では同じ形です。
社内の承認ゲート設計は『AIエージェントの承認ゲート』にまとめています。今回の事故は、その承認ゲートより手前、権限設計の段階で起きました。権限ルールの配分は『Claude Codeの権限設定』で、PreToolUseフックの書き方は『Claude CodeのPreToolUseフック』の記事で扱っています。役割を分けても渡すツールを絞らなければ、今回と同じ空白が残ります。
この章のまとめ
使い捨ての役割ほど、既定値のまま走ります。短命な仕事にこそ、渡すものを書いてください。
10同じ空白を残さないために、AIエージェントの権限設計は何で点検するんですか？
最後に、次に同じ動きが起きる前に確かめられる形へ畳みます。点検する対象は設定そのものではなく、設定を書いたときの決め方です。
新しいサブエージェントやワークフローを作るとき、渡すツールを役割に合わせて書いたか。「読むだけ」「要約だけ」と説明している作業を、読み取り専用の設定でも裏づけたか。指示文だけを対策にして、権限側の歯止めを後回しにしていないか。
送信・公開・削除にあたる操作を、フックで止める設計にしているか。拒否のルールが先に評価される前提で、広い許可を置いていないか。想定外の書き込みが起きたとき、「誰かが権限を広げた」という説明を裏づけるログを、実際に開いて確かめたか。
そして、被害が軽微だった事故を「軽微だった」で閉じていないか。着地点が変われば重大化する、という前提で見直したかどうかです。
11よくある質問
「読むだけ」と書いた指示は、意味が無かったということですか
意味はあります。何をしてほしいかを伝える役目は、指示文にしかできません。今回はっきりしたのは、指示文が「できることの範囲」を変えないという点です。公式ドキュメントも、権限ルールを強制するのはClaude Code自身でモデルではないと明記しています。指示文で行き先を伝え、権限で行けない場所を決める。この2つを分けて持つと、片方が抜けたときに気づけます。指示文だけの状態は、鍵をかけずに貼り紙を出している状態にあたります。
ツールを絞ると、あとから作業が止まって困りませんか
止まる場面は出ます。ただ、止まったときに何が足りないかがその場で分かるので、必要な分だけ足せます。逆に、最初から全部渡しておくと、足りているのか渡しすぎているのかを判定する機会がありません。読み取り系だけを渡して始め、書き込みが要る役割にだけEdit・Writeを足す。この順で足していけば、渡した理由が記録として残ります。
記録が無いのに、原因をツールの未指定だと言い切れるんですか
言い切ってはいません。呼び出し時にツール指定をどう書いていたかは、台帳に残っていないままです。ここで根拠にしているのは、症状と一致する既定のふるまいが公式ドキュメントに明記されているという点だけです。だから記事でも「最有力の説明」という扱いにしています。原因を確定させたいなら、次に必要なのは推測ではなく、呼び出し時の設定を記録に残す運用のほうです。
承認ゲートと権限設計は、どちらから手をつければいいですか
先に来るのは権限設計です。承認ゲートは「止める場所を決めて、人が判断する」仕組みで、そこへ到達する前の段階で使えるものを絞るのが権限設計にあたります。今回の事故は、承認ゲートより手前で起きました。渡すツールを絞ってから、残った操作のうち送信・公開・削除にあたるものをゲートで受ける。この順に置くと、ゲートで見る対象そのものが減ります。
12まとめ｜今日やる3つのこと
広げた記録が無いことを、安全の根拠にしない。この記事はその一点でした。権限設計の失敗は、多くの場合「広げた記録」ではなく「絞らなかった空白」として残ります。自社が同じ空白の上にいるかどうかは、いま動いているサブエージェントの定義を開けば分かります。
今日この順で手をつけます
いちばん最近作ったサブエージェントの定義を開き、渡すツールが書いてあるか見る
書いていなければ、全部渡している状態です
「読むだけ」と説明している役割を挙げ、その説明と設定が一致しているか確かめる
説明と設定がずれている場所が、次の事故の候補です
送信・公開・削除にあたる操作を書き出し、止める場所を機械側に置けるか検討する
指示文の外に歯止めを移す作業です
AI検索では、こう聞かれています
読むだけを指示したAIエージェントに、ファイルを書き込まれるのはなぜですか？
「「読むだけ」と指示したのに、AIエージェントの権限設計はどこで破られたんですか？」の章で説明しています
サブエージェントに渡すツールは、どこまで絞ればいいんですか？
「AI社員に渡すツールは、権限設計のどこで絞れるんですか？」の章で扱っています
指示文に「ファイルを作らない」と書けば、AI社員は止まりますか？
「指示文に「作らない」と書けば、AIエージェントの権限設計は要らないんですか？」の章に答えがあります
広げる順番はどう決めればいいんですか？
「AIエージェントの権限設計を最小権限から広げるとき、何から手をつけるんですか？」の章で説明しています
次に読むなら、この記事です
