Claude Codeの挙動を、小さなTypeScript関数で書き換えられる「mods」が公式に発表された。プロンプトの書き換え、ツール呼び出しの遮断、画面の編集まで届く一方、Claude Code本体と同じ権限で動き、サンドボックスもない。便利さと引き換えの安全運用を整理する。
modsとは何か、hooks・skills・pluginsとの役割の違い、そして個人開発者が入れる前に守りたい導入ルールを整理します。
Claude Codeは、ツールを呼ぶ、許可を求める、画面を描く、といった動作のたびにイベントを発します。modsは、そのイベントの前・後・あるいは代わりに動くTypeScript関数です。
公式の説明では、できることは大きく次のとおりです。
複数のmodsは読み込み順に積み重なって実行されます。配布はpluginに同梱する形で、/pluginから入れられます。CLIとデスクトップ版の両方で使え、Claude Code自身に「modを書いて、入れて、今のセッションで再読み込みして」と頼むこともできます。
これまでの拡張手段は、役割がはっきり分かれていました。modsはその間を埋める層として読むと整理しやすくなります。
手順や知識を渡す層。モデルの判断の中で使われます。
確定的な処理を差し込む層。モデルの外から動作を縛る手段です。
プロンプト、ツール呼び出し、許可、画面の内側に入る層。plugin経由で配るので、導入は気軽でも影響範囲は一番広くなります。
つまり「配りやすさ」はpluginの延長ですが、「届く範囲」はhooksより深い。ここが便利さと危うさの両方の源です。
公式の明記。modsはClaude Codeと同じマシンへのアクセス権で動き、サンドボックスはありません。信頼できる出所のものだけ入れる、とされています。
プロンプトを書き換えられるということは、悪意あるmodがあなたの指示の裏に別の指示を足せるということです。許可リクエストを自動承認できるということは、承認ゲートそのものを無効化できるということでもあります。出力の伏せ字化も、逆向きに使えば情報を隠す側に働きます。
TeamとEnterpriseプランには、ユーザーが入れたmodがセキュリティルールを上書きできないようにする標準のmod（sec-default）が用意されています。個人利用にはこの防波堤が無いので、自分で運用ルールを持つ必要があります。
私の運用でも、hooksと承認ゲートで「やってはいけない操作」を外側から縛っています。modsはその内側に届く力なので、使うなら縛る側ではなく補助する側（表示の改善や、決まった前処理）に限るのが安全だと考えています。
modsは、公式機能の追加を待たずに自分の道具を整えられる、魅力的な仕組みです。ただし届く範囲が深いぶん、入れる前の確認コストを惜しまないこと。「読める量のコードを、入れる前に読む」。この一手間が、一番安い保険になります。
出典：Claude Blog「Customize Claude Code with mods」（2026年10月）。内容は同記事の要約・解説であり、仕様は変更される可能性があります。