Claude Modsとは|denyを越える条件と確認手順
「拡張機能を入れたら、AIが勝手に何かを承認してしまうのではないか」——人を雇わずにAIへ仕事を任せている人にとって、本当に怖いのは間違えることより勝手に通ることです。
結論から言うと、2026年10月1日に追加された「Claude Mods」でdeny(禁止)ルールを越えられるかどうかは、機械の設定と契約プランで決まります。公式ドキュメントは条件を4つに分けて明記しており、守りが既定で効くのは「組織が管理する設定が入った機械」か「TeamまたはEnterpriseプランでサインインしている場合」だけです。それ以外、つまり個人プランの手元の機械では、modは deny が拒んだ呼び出しを承認できます。
株式会社Fyveは、自社とクライアントの双方でAIを無人で動かす仕組みを作っており、その前提として権限の境界を自分で引いています。この記事では、Claude Modsが何を変えたのかを公式の記述で確認したうえで、私自身の検査7本を数え直して分かったこと、そして「それでも全部を内側へ移さない」という判断までを書きます。
Claude Modsとは——プラグインが「外から」ではなく「中で」動くようになった
Claude Mods は、2026年10月1日公開の Claude Code v2.1.287 で追加された仕組みです。公式の更新履歴には「Added Claude Mods: plugins may now modify deeper behavior(プラグインがより深い挙動を変更できるようになりました)」と1行だけ書かれています。
公式ドキュメントの定義はこうです。
A mod is a plugin that changes how Claude Code looks and behaves. It's made of JavaScript or TypeScript event handlers
(modは、Claude Codeの見た目と挙動を変えるプラグインです。JavaScriptまたはTypeScriptのイベントハンドラでできています)
重要なのは「どこで動くか」です。公式は従来の仕組みとの違いを、場所の言葉で説明しています。
Settings hooks, skills, status lines, and MCP servers work from outside Claude Code: each one runs a script, or gives Claude text or tools. A mod runs inside Claude Code, so it can do things they can't
(設定ファイルの検査・スキル・ステータス行・MCPサーバーは、Claude Codeの外側から動きます。それぞれスクリプトを実行するか、Claudeに文章か道具を渡すだけです。modはClaude Codeの内側で動くため、それらにできないことができます)
専門用語が1つあります。公式はどちらも「hook(フック=検査)」と呼ぶため、呼び分けを定めています。modの中の関数を「hook」、従来の設定ファイルに書くシェル実行型を「settings hook」と呼ぶ、というルールです。この記事では前者を内側の拡張、後者を外側の検査と書き分けます。
内側だからできること(公式が挙げる5つ)
- 自分の画面を描く——会話の横のパネル、入力欄の上の帯、タブ・ボタン・テキスト欄
- Claude Code自身の画面を描き替える——道具呼び出しの行、処理中のスピナー、Claudeが質問するダイアログ
- 道具呼び出しや要求に割り込む——呼び出しを保留して利用者に質問する、道具を実行せずに答えを返す、1つの要求だけ別のモデルへ送る
- コマンドで自分のコードを即実行する——Claudeのターンを使わず、Claudeが作業している最中でも動く
/コマンド - 検査同士でデータを共有する——同じmod内の関数は変数を共有するため、片方が数えた値をもう片方が画面に出せる
公式の例は、道具呼び出しの回数を数えてスピナーの横に出す20行ほどのコードです。Thinking · tool calls: 3… のように表示が伸びていく、という地味な例ですが、「Claude Codeの画面そのものを書き替えている」という点が従来と決定的に違います。
外側の検査と内側の拡張は、何がどこまで違うのか
公式は4つの仕組み(mod・設定ファイルの検査・スキル・MCPサーバー)を1枚の表で比較しています。ここで私は自分の理解を1つ訂正しました。
私はこれまで「外側の検査にできるのは、通す・止める・記録するまで」と考えていました。しかし公式の表の「変えられるもの」の欄は、設定ファイルの検査についてこう書いています。
Whether a tool call or prompt goes ahead, a tool call's arguments and result, and context added for Claude
(道具呼び出しやプロンプトを先へ進めるかどうか、道具呼び出しの引数と結果、そしてClaudeに追加される文脈)
外側の検査も、引数と結果は書き換えられるのです。「通す・止める・記録する」だけではありません。一方modは「道具呼び出し、プロンプト、コマンド、ターン、そして画面が描くもの」を変えられる、とあります。
違いは「できることの種類」であって、「書き換えられるか否か」ではない——ここを取り違えると、次に出てくる権限の話を読み間違えます。
外側の検査(settings hook) | 内側の拡張(mod) | |
|---|---|---|
実体 | シェルコマンド・HTTP要求・プロンプト | プラグイン内のJavaScript / TypeScript関数 |
動く場所 | Claude Codeの外(別プロセス) | Claude Code自身のプロセスの中 |
変えられるもの | 通すか否か・引数・結果・追加する文脈 | 道具呼び出し・プロンプト・コマンド・ターン・画面 |
画面を描けるか | できない | できる |
公式が勧める用途 | 手元にあるスクリプトで、止める・許す・記録する | パネル・入力欄の上の帯・独自コマンド・イベントの書き換え |

いちばん大事なのは権限——modが届く範囲を公式はこう書いている
公式ドキュメントには「Decide whether to trust a mod(modを信用するかどうかを決める)」という節があり、modが何に手を届かせられるかを公式自身が6つ列挙しています。他社の警告ではなく、提供元が自分で書いている点が重いところです。
- あなたとして機械上で動く——あなたのユーザー権限で届く範囲のファイルを読み書きし、プログラムを起動し、ネットワーク通信を行う
- あなたの秘密を読む——環境変数と設定ファイル、そこに置いたAPIキーを含む
- あなたのセッションを見る——あなたが送ったすべてのプロンプトと、Claudeが行うすべての道具呼び出し
- あなたのセッションを変える——プロンプトや道具呼び出しを書き換える、あなたが入力したかのようにプロンプトを送信する、あなたの別のセッションへメッセージを送る
- あなたに聞かずに動く——道具呼び出しを、あなたが尋ねられる前に承認する
- あなたの枠を使う——あなたのプランかAPIキーでモデルを呼ぶ
導入手順の節にも警告枠が置かれています。
A mod is code that runs with your permissions. It can read and write your files, start processes, and make network requests. Install mods only from authors and marketplaces you trust.
(modは、あなたの権限で動くコードです。あなたのファイルを読み書きし、プロセスを起動し、ネットワーク通信を行えます。信頼できる作者とマーケットプレースのmodだけを入れてください)
注目すべきは5番目です。「あなたが尋ねられる前に承認する」——つまり、許可ダイアログが出る前に話が終わっている状態がありえます。ここから先が、この記事の本題です。
deny を越えられるのは、どういうときか(公式の条件を4つに分けて読む)
「modは deny を越えられる場合がある」という言い方は、ネット上の紹介記事でよく見かけます。しかし「場合がある」で止めると、自分が越えられる側なのか判断できません。公式の権限ドキュメントには、条件がきちんと書かれています。
まず前提として、外側の検査は権限ルールを越えられません。
PreToolUse hook decisions don't bypass permission rules. Claude Code evaluates deny and ask rules regardless of what a PreToolUse hook returns
(道具を使う前の検査の判断は、権限ルールを迂回しません。Claude Codeは、その検査が何を返したかに関わらず
denyとaskのルールを評価します)
ところがmodは、判断の順番が違います。
A mod you install that hooks
tool.checkanswers after the rules and thePreToolUsehooks have decided, and its answer can replace theirs(あなたが入れたmodが
tool.checkを取っている場合、それはルールと道具を使う前の検査が判断し終えた後に答え、その答えは両者の判断を置き換えられます)
「後に答える」=最後に発言する人が決めるという構造です。そのうえで公式は、何を置き換えられるかを4つに分けています。

相手 | modは越えられるか(公式の記述) |
|---|---|
| 越えられる。確認が出るはずの呼び出しを承認できる |
自分で書いた道具使用前の検査のブロック | 越えられる。ただしその検査が組織の管理設定にある場合は越えられない |
autoモードの分類器 | 越える。modが承認した呼び出しは分類器の確認を通らずに実行される |
| 条件つき。下記を参照 |
4つめ、deny についての記述がこの記事の核です。逐語で引きます。
on a machine with managed settings, or when you're signed in with a Team or Enterprise plan, deny rules hold over the mod by default, and your organization can change that. Anywhere else, the mod can approve a call that a deny rule refuses.
(組織が管理する設定が入った機械、またはTeamかEnterpriseプランでサインインしている場合は、
denyルールが既定でmodに優先し、組織はそれを変更できます。それ以外のどこでも、modはdenyルールが拒む呼び出しを承認できます)
この条件を裏返すと、誰がいちばん無防備なのか
ここで直感と逆のことが起きます。「個人で使っているなら、自分で書いた設定が最強のはずだ」と考えたくなりますが、公式の条件はその逆です。
- 守りが既定で効く——組織の管理設定が配られた機械/TeamまたはEnterpriseプラン
- 守りが既定で効かない——それ以外。個人プランで、自分の機械に自分で書いた設定を置いている状態がここに入ります
つまりいちばん防護が薄いのは、組織の管理設定を配る立場にない、ひとりでAIを回している人です。「自分のPCだから自分のルールが効く」のではなく、「組織が管理していないから、組織用の防護が効かない」というのが正確な読み方です。

私自身これに当てはまります。権限の境界を自分で引いて無人運用を組んでいる側ですが、その境界は管理設定として配られたものではなく、自分の設定ファイルに書いたものです。deny の書き方を整えること自体は今も有効ですが、「書いたから絶対に止まる」という前提は、modを1本入れた瞬間に条件つきになります。
deny 設定そのものの書き方は、別の記事にまとめています。
それでも越えられないものはある(残っている床)
ここまで読むと「もう何も守れないのか」と感じますが、公式は越えられない線も明記しています。この床があるかどうかで、取るべき対策が変わります。
- 許可ダイアログの中身は書き換えられない——公式の逐語は「A mod can restyle much of Claude Code's interface, but not the permission prompt. It can't change what a prompt shows you.(modはClaude Codeの画面の多くを描き替えられますが、許可ダイアログは対象外です。ダイアログがあなたに見せる内容を変えることはできません)」。つまり確認が出たときに表示される内容は信用できる
- 組織の管理設定にある検査のブロックは越えられない——同じ検査でも、置き場所で強さが変わる
- MCPの道具で
requiresUserInteractionが付いたものは、検査が「許可」を返しても確認が出る - 終了コード2で止める検査は、権限ルールの評価より前に止める——公式の逐語は「A hook that exits with code 2 stops the tool call before permission rules are evaluated」
この最後の1つは実務で効きます。外側の検査で終了コード2を返して止める形は、権限ルールの評価そのものより前に効くため、許可リストの指定が緩くても止まります。「できることが少ない代わりに、効く位置が早い」という性質です。
権限ルールの指定そのものが黙って効かなくなる落とし穴は、別の記事で扱っています。
自分の検査を数え直したら、7本すべて「外側」だった
公式が内側を開けた日に、自分の設定を走査して検査の本数を数えました。結果は7本、内訳は次のとおりで、全部が外側でした。内側で動く形(mod)は0本です。
- 道具を使う前に3本——対象はシェル実行。公開前の文章検査・書類の数字の検算など
- ファイルを書いた後に2本——記録の更新の催促など
- 会話が終わったときに2本——記録の棚卸し・会話に貼った画像の保存
7本すべてが設定ファイルに書いたシェル実行型です。つまり「検査を工程に埋めている」と言ってきましたが、埋めていた場所は作業の外側だけでした。公式が内側を開けた日に数えて、初めてそれが見えました。
7本全部に同じ自作の安全装置が入っていた
走査して気づいたことがもう1つあります。7本すべてが、同じ1行で包まれていました。「検査のスクリプトが見つからなければ、入力を捨てて黙って成功で抜ける」という書き方です。
なぜそう書いたか。検査が1本欠けただけで作業そのものが止まるのを避けるためです。無人で回す仕組みでは、品質を上げるための検査が原因で本体が止まるのが最悪の結果になります。検査は「あれば効く、無ければ素通りする」でよい、という判断でした。
ここは正直に書きます——公式の修正は、私には当たっていません
v2.1.287 の修正項目に、関係しそうな1行があります。
Fixed hooks configured with
asyncRewakewaking Claude over and over with "found issues" notifications when the hook's script file is missing; the broken hook is now reported once(
asyncRewakeを設定した検査が、スクリプトのファイルが存在しないときに「問題が見つかりました」の通知で何度もClaudeを起こしてしまう不具合を修正しました。壊れた検査は1回だけ報告されるようになりました)
「公式が直した壊れ方を、自分は先に手で避けていた」と書きたくなる場面です。しかし自分の設定を確認したら、asyncRewake は1箇所も使っていませんでした。この修正の対象は asyncRewake を設定した検査であり、私の7本は該当しません。
正確に言えるのはここまでです。公式の修正と私の安全装置は、「検査のスクリプトが無い」という同じ条件に備えているが、起きる壊れ方は別——公式が直したのは繰り返し通知が来る不具合、私が避けたのは検査の不在で作業が止まることです。重なっているのは原因側だけで、症状は違います。
こうした「惜しいところまで合っているが、よく読むと別のこと」は、一次情報を開かないと必ず取り違えます。紹介記事の要約だけを読んで「公式が自分と同じ結論に来た」と書くと、気持ちのいい嘘ができあがります。
それでも全部を内側へ移さない——私の判断
内側の拡張には、外側では書けなかったことが書けます。「道具呼び出しを保留して人に質問する」「実行せずに答えを返す」は、外側の検査では表現できませんでした。やりたかったのにできなかったことが、できるようになっています。
それでも私は7本を内側へ移しません。理由は2つです。
1つめ。内側は自分の権限で動くコードで、提供元自身が「あなたに聞く前に承認できる」「それ以外の場所では deny が拒む呼び出しを承認できる」と書いています。対して外側のシェルは、できることが少ない代わりに、何をするのかが1行で読めます。できることの少なさを、安全の材料として使っている、という選び方です。
2つめ。modは無人のセッションでも動きます。公式の「どこでmodが動くか」の表には、claude -p とAgent SDKについて「検査は動く/描画は出ない」と書かれています。画面が出ないのに割り込みは動く、という組み合わせです。
実行する場所 | 検査は動くか | 描いたものは出るか |
|---|---|---|
ターミナルの | 動く | 出る |
デスクトップアプリのCodeタブ | 動く | 出る(ターミナル専用の部品を除く) |
VS Code拡張のチャット画面 | 動く | 出ない |
| 動く | 出ない |
デスクトップアプリのWSLセッション | 動かない | 出ない |
無人で回す側からすると、ここがいちばん効く情報です。対話で入れたmodは、夜間に無人で動くジョブにも載ります。画面に何も出ないため、入れた本人が気づかないまま効き続ける形になりえます。
無人運用の上限設定については、別の記事にまとめています。
入れる前にやる4手順
ここまでを踏まえた手順です。私はまだ1本も入れていません(理由は後述します)。そのため「入れてみたらこうだった」は書けません。公式が用意している確認方法を順に並べたものとして読んでください。
① まず版を上げる
公式の逐語は「Mods require Claude Code v2.1.287 or later, and they're on by default.(modはClaude Code v2.1.287以降が必要で、既定で有効です)」。claude --version で確認し、古ければ更新します。
なお私の手元の環境は 2.1.209 でした。必要な版に届いていないため、この記事を書いている時点でmodは1行も動きません。これは正直に書いておきます——公式が機能を出してから手元で試せるようになるまでには、必ず時差があります。
② 入れる前に、中身を実行せずに一覧する
公式は、インストール前に「どのイベントに触り、Claude Codeに何を要求するか」を実行せずに一覧する方法を用意しています。プラグインのファイルを先に手元へ取得し(リポジトリの複製など)、そのディレクトリに対して実行します。
claude plugin validate ./some-mod出力の hooks: の行が扱うイベント、calls: の行が要求する動作(ファイル読み取り・ネットワーク通信など)を示します。この手順が成立するのは、内側の検査が「modのAPIを通さないと外に何もできない」設計になっているからです。公式はその理由を明記しています——「A hook has no other way to do those things, which is why Claude Code can list what a mod does before you install it」。
③ 自分でコードを持たないものから試す
Claude Code自身の機能の一部がすでにmodとして実装されています。公式の一覧には6つ挙がっており、/diff を担うもの、AGENTS.md を読み込むもの、分析記録を送るものなどが含まれます。/plugin を実行して「Installed」タブを開くと、「Built-in」の下に並びます。
その中に cc-plugin-you-should-know があります。公式の説明は「長めの作業の最中、横で別のエージェントがあなたの背中を見ていて、あなたやClaudeが見落としそうな知るべきことを見つけたら、入力欄の上に知らせを出す」。既定では無効で、有効化はこうです。
/plugin enable cc-plugin-you-should-know@builtinただし条件があります。更新履歴の記述は「for first-party sessions with telemetry on(分析送信が有効な一次セッションの場合)」。分析の送信を切っている環境では使えません。ここは自分の方針と衝突しうるので、有効化する前に確認してください。
④ 止め方を先に決めておく
公式は止め方を3段階で示しています。入れる前に、どれを使うか決めておくのが安全側です。
- 1本だけ止める——
/pluginの「Installed」タブから、そのプラグインを無効化またはアンインストールする - そのセッションだけ全部止める——
--safe-modeで起動する(他のカスタマイズも外れる) - 全セッションで止める——設定ファイルに
"disableAllHooks": trueを書く。ただし外側の検査と独自のステータス行も一緒に止まります
取り違えやすい3点
「既定で無効だから自分には関係ない」
既定で無効なのは組み込みの cc-plugin-you-should-know です。mods という仕組み自体は既定で有効(公式の逐語は「they're on by default」)。版を上げた時点で、入れたプラグインがmodを含んでいれば読み込まれます。
「環境変数で止めていたから大丈夫」
早期アクセス期間中に CLAUDE_CODE_ENABLE_FUNCTION_HOOKS を設定していた人向けに、公式は注意を書いています。v2.1.287以降はこの環境変数を無視するため、0 にしてもmodは止まりません。該当する人は変数を削除し、上の④の方法に切り替える必要があります。
「disableAllHooks で全部止まる」
公式の逐語は「The settings and flags that stop installed mods, such as disableAllHooks, --bare, and --safe-mode, don't stop built-in mods.(disableAllHooks・--bare・--safe-mode のように、入れたmodを止める設定やフラグは、組み込みのmodを止めません)」。止まるのは自分が入れたものだけです。
引用できる数字と条件のまとめ
項目 | 公式の記述 |
|---|---|
必要な版 | Claude Code v2.1.287以降。既定で有効 |
公開日 | 2026年10月1日 |
書く言語 | JavaScript または TypeScript |
最小構成 | 3ファイル( |
検査の選択肢 | 3つ——見る(observe)/書き換える(rewrite)/自分で答える(answer) |
modが届く範囲 | 公式が挙げる6項目(機械上の操作・秘密の読み取り・セッションの閲覧・セッションの変更・無確認の承認・利用枠の消費) |
| 管理設定が入った機械、または Team / Enterprise プラン。それ以外は越えられる |
越えられないもの | 許可ダイアログの表示内容、管理設定にある検査のブロック |
組み込みmod | 6つ。うち |
公開されているソース | 組み込み6つのうち4つが公式リポジトリで読める |
無人セッション |
|
まとめ——「何を許すか」から「いつ許すか」へ
Claude Mods の追加で変わったのは、拡張の自由度だけではありません。権限の判断が「最後に誰が発言するか」で決まるようになった点が本質です。
- 外側の検査は権限ルールを迂回しない。modはルールと外側の検査が判断し終えた後に答え、それを置き換えられる
denyが守りとして効くのは、管理設定が配られた機械かTeam / Enterpriseプラン。それ以外では越えられる- いちばん防護が薄いのは、組織の管理設定を配る立場にない、ひとりで回している人
- 残っている床は許可ダイアログの表示内容。確認が出たときに読める内容は信用できる
- 入れる前に
claude plugin validateで実行せずに中身を一覧できる。この手順が成立する設計になっている - modは無人のセッションでも動き、画面には何も出ない
私は自分の検査7本を数えて、全部が外側だと確認し、そのうえで内側へ移さないと決めました。できることの少なさを安全の材料に使う——無人で回す仕組みでは、これが今のところ一番確実な選び方だと考えています。
そして今日いちばん身についたのは、機能の話より読み方でした。「場合によっては deny を越えられる」で止めずに公式の条件まで開いたら、守られているのは組織で、守られていないのは個人だった——紹介記事の要約では、ここは出てきません。株式会社Fyveが権限の設計を見るとき最初に確かめるのは、機能ができることではなく自分がどちらの条件に入っているかです。
Claudeのこの5つの設定、今すぐ見直した方がいい

共有・学習・入力・権限・委任。事故が起きるのはこの5つだけ(全28ページ)
2026年7月、Claudeの共有チャットがGoogle検索から読める状態になっていました。原因は設定そのものではなく、自分が過去に共有したものを覚えていないことでした。共有リンクの棚卸しから、学習をオフにしても残る例外条項、Claude Codeの権限モードまで、今日30分で確認できる形にまとめています。
- 見落としやすい共有リストは3つある(3つ目は画面の下)
- 学習をオフにしても残る、公式の例外条項
- 権限モード6つの違いと、Shift+Tabでの切り替え方
- 私が実際に禁止しているコマンド23行を全文公開
メールアドレス登録で他にも様々な資料を閲覧できます








+8PDF 17点・合計440ページ + すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。