Claude Codeに「mods」、プロンプトや画面、組み込み機能をTypeScriptで書き換える拡張

Anthropicが2026年10月1日、Claude CodeのCLIとデスクトップアプリで動く拡張「mods」を公開した。プラグインとして配布され、サンドボックス化されずに利用者の権限で動く。Team・Enterpriseプランなどでは組み込みのsec-defaultが先に読み込まれ、利用者が入れたmodがdenyルールを上書きするのを止めるとしている。

Claude-Code Anthropic plugins security AI-coding-tools enterprise

Anthropicは2026年10月1日、Claude Codeの動作を変える小さなTypeScript関数「mods」を公開した¹。プロンプトの書き換え、UIの追加、組み込み機能の置き換えができ、自分で書くことも、Claude Codeに書かせることもできる。配布はプラグインの形をとり、ほかのプラグインと同じように導入・共有する。対応するのはClaude CodeのCLIとデスクトップアプリである。

同社は、modsがClaude Code自体と同じマシンへのアクセスを持って動き、サンドボックス化されていないと明記したうえで、信頼できる提供元のものだけを入れるよう求めている。組織向けには、Team・Enterpriseプランなどで組み込みの「sec-default」が先に読み込まれ、利用者が入れたmodの一部の動作を止める仕組みが用意された。

イベントの前後に割り込む関数

Anthropicの説明では、Claude Codeは何かをするたびにイベントを出す。ツールの呼び出し、権限の確認、画面の一部の描画などがそれにあたり、modはそのイベントにフックする関数として、イベントの前か後、あるいはイベントの代わりに実行される¹。前後を包む形もとれる。

1つの関数でできることとして、同社は4つを例示している。モデルに届く前のプロンプトの書き換え、ツール呼び出しのブロック・書き換え・再試行、権限リクエストの承認・拒否、それにClaudeが読む前のツール出力から秘密情報を取り除くことだ。表示の側では、ツールの結果やClaudeからの質問といった画面の一部を編集・置換でき、ボタンや入力欄も足せる。複数のmodが同じイベントにフックした場合は読み込まれた順に動き、最初に読み込まれたmodがイベントを最初に受け取って、結果を最後に受け取る。

組み込み機能の一部もmodとして提供されるようになった。例として挙がっているのは /diff で、/plugin からオフにするか、自分で書いた版に置き換えられる。Anthropicは今後も組み込み機能をmodに移していき、Claude Codeを小さな中核まで削ったうえで必要なものだけを足し戻せるようにする計画だとしている。

設定ファイルのhooksでは届かなかった部分

modsを作った理由として、Anthropicは機能の出荷を待たずにClaude Codeの動作をもっと制御したいという開発者の要望を挙げる¹。hooksはその一部に応えたが、イベントの書き換え、新しいUIの描画、機能の置き換えはできなかった、というのが同社の説明だ。設計は公開前にGitHubで共有し、開発者から意見を集めたという。

hooksがなくなるわけではない。組織の管理者向けドキュメントは、設定ファイルやプラグインの hooks/hooks.json に書くhooksがmodと並んで従来どおり動き、非推奨にもなっていないと書いている²。組織が検査点を置く仕組みとしては、8月にClaude Enterprise向けのinference hooksも公開された。このときAnthropicは、ネイティブなインラインの強制がClaude Codeのクライアント側フックに限られていたと説明していた。

v2.1.287以降で既定で有効

管理者向けドキュメントによると、modsはClaude Code v2.1.287以降で既定で有効になっている²。CHANGELOGでも、2.1.287の項にClaude Modsの追加が記載されている³。

導入の経路は、Claude directoryから入れるか、CLIで /plugin を実行してmodを含むプラグインを入れるかのどちらかである。自作のmodを共有したい場合は、プラグインにまとめてディレクトリに提出する¹。

サンドボックスの外で、利用者の権限のまま動く

管理者向けドキュメントはmodを、インストールした利用者の権限でClaude Codeの中のコードを動かすプラグインと定義し、サンドボックス化されていないと明記する²。Claude Codeの中で動くため、プラグインのほかの構成要素より多くのことができ、すべてのプロンプトとツール呼び出しを見て変更し、権限確認のプロンプトが出る前にツール呼び出しを許可・拒否できるとも説明している。後述のsec-defaultが読み込まれていても、利用者のmodはファイルの読み書き、プロセスの起動、ネットワーク要求、ツール呼び出しやプロンプトの書き換え、確認が出るはずの呼び出しの承認を、その利用者の権限で行える。

macOSでClaude Codeのサンドボックスを有効にすると、エージェントが実行するコマンドはSeatbeltで囲われる。9月にはその囲いを抜けられた問題の手口が発見者から公開されていた。modsはこうしたサンドボックスの対象にならない。手元で動くエージェントにどこまでの権限を渡すかはOSの側でも論点になっていて、Appleは10月2日にmacOSのフルディスクアクセスに追加の制御を導入すると予告している。

入れる前に中身を確かめる手段として、ドキュメントは claude plugin validate を挙げる²。プラグインのディレクトリに対して実行すると、modが受け取るイベントと、呼び出すAPIの一覧が、modを動かさずに表示される。

sec-defaultが止めるもの、止めないもの

Anthropicによると、Team・Enterpriseプランと、managed settings（管理者が配布する設定）のあるマシンでは、組み込みのmodである sec-default が最初に読み込まれる¹。利用者が入れたmodが、権限のdenyルールを上書きするといった危険な動作をするのを止めるもので、ソースコードも公開されている。

ドキュメントはこの条件をもう少し細かく書いている。APIキー、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry経由で認証する利用者には、managed settingsのあるマシンでだけガードが付く²。利用者はガードをオフにできない。守られるのは、管理対象のhooksが受け取る内容と判定、システムプロンプト、管理対象のCLAUDE.mdなどの指示、modが読む設定、管理対象のMCPサーバーのツールと説明である。

denyルールの扱いには範囲の限定がある。ガードが読み込まれる環境では、利用者のmodはdenyルールが拒否する呼び出しを承認できず、managed settingsにあるPreToolUse hookのブロックも覆せない。ただしドキュメントによれば、どちらもClaudeのツール呼び出しに対するもので、mod自身がAPIで行うファイル操作やプロセス起動には及ばない。Read(.env) を拒否していても、modはそのファイルを自分のAPIで読めると例示されている。また、askルールで確認が出るはずの呼び出しや、managed settings以外のPreToolUse hookがブロックした呼び出しは、利用者のmodが承認できる。auto modeでは、modが承認した呼び出しは分類器のチェックを経ずに実行される。

管理者が使える設定も示されている。ガードのオプション allowManagedModsOnly を有効にすると、利用者がインストールしたプラグイン、--plugin-dir で読み込んだもの、セッション中にClaudeが書いたものを含め、利用者が持ち込むmodは読み込まれない²。逆に allowModsToOverrideDenyRules を有効にすると、利用者のmodがdenyルールの拒否する呼び出しを承認できるようになる。自組織のmodを先に読み込ませるために prependPlugins を設定する場合は、リストが既定を置き換えるため、sec-default@builtin を名前で入れておかないとガードが外れる。ガードはmanaged settingsを読めないときに利用者のmodをすべて拒否する、fail closedの設計とされる。

2.1.289で入った権限まわりの修正

CHANGELOGによると、2.1.289では、管理対象のマシンで、複合シェルコマンドの入れ子部分にかかるdenyまたはaskルールが、利用者が入れたmodの承認に対して効いていなかった問題が修正された³。同じ版では、利用者が入れたプラグインが組織管理のMCPサーバーのサインイン用ツールの説明を書き換えられた問題や、アップグレード後の最初のセッションでインストール済みのmodが読み込まれない問題も直っている。

Claude Codeでは8月にも、2.1.251でシンボリックリンク経由で承認範囲の外を読み書きしうる問題などが修正されている。承認の判定に関わる修正が続いているので、組織でmodsを使わせるなら、手元の版を2.1.289以降にそろえておきたい。

組織で判断するときの分かれ目

判断の起点になるのは、自分たちの環境でsec-defaultが読み込まれるかどうかだ。Team・Enterpriseプランでサインインしているか、managed settingsを配っていればガードは付く。APIキーやクラウド経由で使っていてmanaged settingsを配っていない環境では、ドキュメントの条件に当てはまらず、ガードは付かない。

ガードが付く場合も、denyルールが止めるのはClaudeのツール呼び出しで、mod自身がAPIで行うファイル操作やプロセス起動は対象外である。denyルールで機密ファイルを守っている組織は、その守りが利用者のmod自身の操作には及ばないことを踏まえて、modを許すかどうかを決める必要がある。Anthropicが示している選択肢は、allowManagedModsOnly で利用者のmodを止めるか、マーケットプレイスの制限と disableSideloadFlags で入手元を絞るか、自組織のmodで他のmodの読み込みを審査するかである²。

個人で使う場合は、入れる前に claude plugin validate で呼び出すAPIを見ておけば、ファイルやネットワークに触れるmodかどうかは実行前に分かる。