AIエージェントの権限設計は、誰かが意図して広げた瞬間より、絞らなかった既定値のまま気づかず動く場面で壊れます。本記事は、調査目的で走らせたサブエージェントが指示していないファイルを書き込んだ社内の実際の事故を、症状・誤診・真因の順で追います。根拠は公式ドキュメント5件と、社内の実測記録です（計測日2026-07-29）。

01何が起きたか｜AIエージェントの権限設計が試された書き込み事故

2026-07-28 11:13、WEBMARKSは調査目的のワークフローをサブエージェントに走らせました。指示は「資料を読んで内容を要約し、結果を返すだけ」という読み取り専用の作業です（出典: 社内リポジトリ git commit 60e639be の実測）。

このサブエージェントは、指示していない図解SVGファイルを生成し、ディスクへ保存しました。生成物はAGIM-701-01.svg（5,333バイト・viewBox 800×450）と、キャプション情報のcaptions.jsonの2点です。

内容を検証したところSVG自体は壊れておらず、『AIエージェントとは｜そう呼べる3条件と、呼べない境界』の1枚目の図解として後日採用されています。それでも「読むだけの指示で、なぜ書き込みが実行できたのか」という問いは、検証を終えたあとも残りました。

被害が軽微だったのはたまたまです。書き込まれる先が納品済みフォルダや送信キューだった場合、検証してから採用する猶予はありません。AIエージェントの権限設計では、事故の大小より「なぜ止まらなかったか」を先に見るべきです。

02最初に疑ったのは、権限設計を広げすぎたという誤診だった

この記録を最初に見たとき、浮かびやすい説明は「権限設計のどこかを広げすぎた」というものです。誰かが承認ルールを緩め、書き込みを許可する設定を増やしたのではないか、という見立てです。

この見立てには理由があります。Claude Codeには、確認なしで承認を進めるモードが複数あります。既定のdefaultのほかacceptEdits・auto・bypassPermissionsなど、合わせて6モードあります（出典: Claude Code公式ドキュメント）。どれか広いモードで動かしていたのではと疑う余地は、確かにありました。

しかし社内記録には、この呼び出しの直前に権限モードや許可ルールを変更したというログが残っていません。台帳に残っているのは「読むだけの指示だったのに書き込みが起きた」という結果だけです。

論点誤診（最初の見立て）記録から言えること
何が起きたか承認ルールをどこかで意図的に緩めた変更ログは無く、既定の書き込み権限がそのまま残っていた
疑った根拠自動承認モードが6種類あり、広い方を使えば説明がつくモード選択の記録自体が残っていない
対策の向きモード設定を1つずつ点検する個々のモードより、既定値の絞り込み手順を見直す

「広げた」という能動的な操作の記録が無いまま「広げすぎた」と結論づけるのは早計でした。広がっていたのは設定ではなく、絞らなかった既定値だったからです。

03書き込み事故の本当の原因は、権限設計を広げたのではなく絞っていなかったこと

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用語集）。

最小権限を広げる4段階のうち、2026-07-28の事故はどこを飛び越えたか 権限設計を①読み取り専用②作業ディレクトリ内の編集③承認つきのコマンド実行④送信・公開・削除の4段階に分け、各段階の右に人間ゲートが必要かどうかを示す。①と②はゲート不要、③と④はゲート必須。2026-07-28の事故では、読み取り専用のはずだった調査ワークフローが、tools未指定と推定される設定のまま③④相当の書き込み能力を持って実行され、本来は①のまま完了するはずの段階を飛び越えた。 TIMELINE 権限は4段階、事故はどこで飛び越えたか ①読み取り専用 ゲート不要 ②作業ディレクトリ内の編集 ゲート不要 実際に使われた権限域（③④相当） ③承認つきのコマンド実行 ゲート必須 ④送信・公開・削除 ゲート必須 変更ログ0件（記録より） 本来の想定 ①読み取り専用のまま完了 実際に起きたこと tools未指定(推定)のまま実行 読み取り専用のはずが、tools未指定(推定)のまま書き込み能力を保持して実行された
最小権限から段階的に広げる権限設計の4段階と、2026-07-28の事故がどの段階で起きたかを示す図

権限設計の失敗は、多くの場合「広げた記録」ではなく「絞らなかった空白」として残ります。

04指示文で塞いだ範囲と、権限設計として残った宿題

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行目に相当する技術的な歯止めまで踏み込んだかどうかは、この記録の範囲では確認できません。指示文の追加は無意味ではありませんが、権限設計としては応急処置にとどまります。

05AIエージェントの権限設計を最小権限から段階的に広げる仕組み

権限設計を最小権限から段階的に広げる考え方を、仕組みとして運用に落とし込むには次の4点が要ります。

  1. 役割ごとにtoolsを明示する：調査・要約だけを担うサブエージェントにはtools: Read, Grep, Globのように読み取り系だけを渡す。書き込みが要る役割にだけEdit・Writeを足す
  2. disallowedToolsで引き算する選択肢を持つ：継承した全ツールから書き込みだけを外したい場合はdisallowedTools: Write, Editと書ける。禁止したい対象がはっきりしているときはこちらが速い
  3. 送信・公開・削除はPreToolUseフックで機械的に止める：判定はallow（許可）・deny（拒否）・ask（確認）・defer（委譲）の4値で返します。出典はClaude Code公式ドキュメントです。指示文ではなく、ここに歯止めを置く
  4. 評価順序を前提に設計する：権限ルールはdeny→ask→allowの順で評価され、最初に一致したルールが結果を決めます。広いallowを先に書いても、denyルールがあれば書き込みは通りません（出典: Claude Code公式ドキュメント）
サブエージェント作成時に権限を広げる前に判定する4つの問いと、省いた場合の失敗 新しいサブエージェントやワークフローを作るときの判定フロー。①toolsを明示したか②書き込み系を含むか③送信・公開・削除を含むか④PreToolUseフックでdeny・askを設定したかの4問に順に答え、いいえならその時点の権限に留まって安全に終了し、4問すべてはいで進めば人間ゲートを経て実行する。各問いの右には、確認を省いたまま進めた場合に起きる失敗（全ツール継承・想定外の書き込み・公開や削除の事故・歯止めの欠如）を示す。 BRANCH 権限を広げる前に4つを判定し、省くと何が起きるか 新規サブエージェントを作る ①toolsを明示したか ②書き込み系を含むか ③送信・公開・削除を含むか ④PreToolUseフックでdeny/askを設定したか 人間ゲートを経て実行 はい はい はい はい いいえ 読み取り専用に留まる 全ツール継承（今回の事故） いいえ 書き込みなしで実行 気づかず書き込み実行 いいえ 送信・削除なしで実行 気づかず公開・削除実行 いいえ 設定するまで停止 歯止め無く実行される 確認を省くと、右側の失敗（想定外の書き込み・公開事故）が起きる
権限を広げる/絞る判断の分岐フロー

社内の承認ゲート設計は『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』にまとめています。今回の事故は、その承認ゲートより手前の権限設計の段階で起きました。

権限ルールの配分は『Claude Codeの権限設定｜allow・ask・denyの配分と設定例』で扱っています。PreToolUseフックの書き方は『Claude CodeのPreToolUseフック｜危険コマンド遮断のコード例』にまとめています。役割を分けてもtoolsを絞らなければ、今回と同じ空白が残ります。

同じVaultでは、更新時刻を根拠に成果物の所有者を誤認し、3日間で233回誤爆した障害も起きています（出典: 社内タスク台帳）。真因は別ですが、どちらも「既定のままにした空白」が事故を生んだ点は同じです。

WEBMARKSは2026-06-24に7部署30体のAI社員体制を統合しました。調査用の使い捨てワークフローにも本番と同じ書き込み能力が既定で渡る構成のまま、今回の事故は起きています。

06同じ失敗を避けるためのチェックリスト

  • 新しいサブエージェント・ワークフローを作るとき、toolsを役割に合わせて明示したか（省略すると全ツールを継承する）
  • 「読むだけ」「要約だけ」と説明する作業を、tools: Read, Grep, Globのような読み取り専用の設定でも裏づけたか
  • 指示文（プロンプト・CLAUDE.md）だけを対策にして、権限設計としての歯止めを後回しにしていないか
  • 送信・公開・削除にあたる操作は、PreToolUseフックでdeny・askを返す設計にしているか
  • 権限ルールがdeny→ask→allowの順で評価されることを前提に、広いallowを先に置いていないか
  • 想定外の書き込みが起きたとき、「誰かが権限を広げた」という説明を裏づけるログを実際に確認したか
  • 被害が軽微だった事故を「たまたま軽微だっただけ」として扱い、書き込み先が変われば重大化する前提で見直したか