Claude Code に mods — TypeScript 関数で本体の挙動を書き換えられるようになった

要約

Anthropic は 2026-10-01、Claude Code mods を公開しました。mods は「Claude Code の動作を変える小さな TypeScript 関数」です。

この発表の位置づけを先に整理します。 Claude Code にはすでに2つの拡張手段がありました。1つは hooks で、「ツール実行の前後」のようなイベントで外部コマンドを呼べます。もう1つはプラグインで、スキル・コマンド・MCP サーバー・サブエージェントをまとめて配布できます。どちらも「Claude Code の外側に自分の処理を足す」仕組みです。

mods が変えるのは、そこです。 外側に足すのではなく、本体の内部動作そのものに割り込みます。 公式が挙げている範囲は次のとおりです。

モデルへ届く前にプロンプトを書き換える。ツール呼び出しをブロック・書き換え・リトライする。権限リクエストを許可または拒否する。ツール出力から秘匿値を伏せる。ツール結果などの画面要素を編集・置換する。ボタンや入力欄を追加する。

このリストで注目すべきは後半2つです。 プロンプトやツール呼び出しへの介入は hooks の延長線上にありますが、「権限リクエストを許可または拒否する」と「画面要素を編集・置換する」は、従来の拡張ではできませんでした。 前者は統制の根幹に、後者は UI そのものに手が入ることを意味します。

同じイベントに複数の mod を掛けた場合、順番にスタックして実行されます。 競合したときの優先順位が暗黙に決まるのではなく、ロード順で決まるという設計です。これは後述する sec-default の仕組みにも関係します。

すでに組み込み機能の mod 化が始まっています。 /diff は現在 mod として同梱されており、無効化や差し替えができます。 公式は今後も組み込み機能を順次 mod 化していくとしています。「公式機能と拡張の境目を無くす」方向であり、ユーザーから見れば、気に入らない組み込み機能を自分の実装に置き換えられるということです。

配布は既存のプラグイン基盤に乗ります。 mods はプラグインの中に入り、CLI の /plugin または Claude ディレクトリからインストールします。新しい配布経路を覚える必要はありません。

組織向けの統制が同時に用意されています。 Team / Enterprise プランには sec-default という組み込みのセキュリティ mod があり、最初にロードされて「権限拒否の上書き」のような危険な改変を防ぎます。 管理者はそのソースコードを確認でき、独自の mod を代わりに読み込ませることもできます。

提供は 2026-10-01 から、Claude Code の CLI とデスクトップアプリです。

最後に、公式自身が明記している制約です。 mods はサンドボックス化されておらず、Claude Code 本体と同じマシン権限で動きます。 公式は「信頼できる提供元の mod だけを入れること」と注意しています。

何が変わったか

• mods は「Claude Code の動作を変える小さな TypeScript 関数」
• できること
  • モデルへ届く前のプロンプト書き換え
  • ツール呼び出しのブロック / 書き換え / リトライ
  • 権限リクエストの許可 / 拒否
  • ツール出力からの秘匿値の伏せ字
  • ツール結果などの画面要素の編集・置換
  • ボタンや入力欄の追加
• 同じイベントに複数の mod を掛けると順番にスタックして実行
• 組み込みの /diff は既に mod として同梱。無効化・差し替えが可能。今後も組み込み機能を順次 mod 化
• 配布は既存のプラグイン基盤。/plugin または Claude ディレクトリから導入
• Team / Enterprise には sec-default（組み込みセキュリティ mod）が最初にロードされ、権限拒否の上書きのような改変を防ぐ。管理者はソース確認と独自 mod への差し替えが可能
• 提供は CLI とデスクトップアプリ、2026-10-01 から
• サンドボックス化されていない。Claude Code と同じマシン権限で動く

業務インパクト（一般企業向け）

この更新で企業側に新しく発生する作業は、「どの mod を許すか」を決めることです。

順番に整理します。まず、なぜこれが統制の問題になるのか。

mods は権限リクエストの許可/拒否に介入できます。 Claude Code の安全性の中核は「危険な操作の前に人へ確認する」という仕組みです。mod はその確認を自動で許可する側にも回れます。 つまり、便利な mod を1つ入れた結果、権限確認が実質的に機能しなくなるという事態が起こり得ます。

公式が sec-default を Team / Enterprise に用意し、最初にロードする設計にしたのは、この問題への回答です。 最初にロードされた mod が後続の改変を制限できるため、ロード順を統制の手段として使っています。 妥当な設計ですが、裏を返せば「mod は統制の一部である」と公式が認めているということです。

したがって、組織での対応は次の3段で考えるのが現実的です。

1段目は、現状把握です。 自社の Claude Code 利用が Team / Enterprise プランなのか、個人プランの持ち込みなのかを確認します。sec-default は Team / Enterprise の機能です。 個人プランで業務利用している状態だと、この最低保証が効きません。 ここが最初の分岐点になります。

2段目は、許可方針です。 mods はプラグインとして配布されるため、既存のプラグイン方針がそのまま適用できるかを確認します。多くの組織は「プラグインは社内で確認したものだけ」というルールを持っているはずです。mods はプラグインの中に入るので、そのルールの網にかかります。 網にかからない運用（各自が自由に入れている）なら、mods の登場を機に方針を作る必要があります。

3段目は、監査です。 mods はツール出力から秘匿値を伏せることもできますが、逆に伏せ字を外すこともできるはずです（公式は明示していませんが、画面要素を編集できる以上、構造的にはそうなります）。ログやテレメトリに何が残るかが mod によって変わるため、監査を前提にしている組織では、mod を入れた後にログの内容を確認する作業が必要です。

ここで、やってはいけない対応を1つ挙げます。「mods を全面禁止する」は、おそらく最適ではありません。

理由は、組み込み機能の mod 化が進むからです。 /diff がすでに mod であり、今後も組み込み機能が mod へ移るということは、「mods を無効にする」が「Claude Code の標準機能を無効にする」に近づいていくということです。禁止ではなく、許可リスト方式（確認済みの mod だけ許す）へ寄せるのが筋だと考えます。

もう1つ、実務的な価値のある使い道を挙げます。秘匿値の伏せ字です。

ツール出力に API キーや顧客データが混ざるのは、Claude Code を業務で使う際の典型的なリスクです。本体の秘匿値マスキングは一般的なパターンしか拾えません。 自社固有の形式（社内 ID の体系、顧客番号の桁数）は、自社で書いた mod のほうが正確に伏せられます。 これは「拡張の自由度」ではなく「統制の精度」として価値があります。

組織の意思決定としては、「mods を使って統制を強める側に回る」という選択肢があることを押さえておくべきです。 mods は統制を弱める道具としても強める道具としても使えます。どちらに使うかを決めずに放置すると、各自が便利さのために弱める方向だけに使います。

最後に、You should know について触れておきます。 同日のリリース（v2.1.287）には、側で動くサブエージェントが見落としを指摘する You should know という組み込み mod が入りました。有効化は /plugin enable cc-plugin-you-should-know@builtin で、テレメトリ有効のファーストパーティセッション向けという条件が付いています。「mod で何ができるか」の公式の実例として見る価値があります。レビュー工程を人だけに任せない形の1つです。

副業・個人活用視点

個人で Claude Code を使っている人にとって、mods の価値は「自分の不満を自分で直せる」ことです。

具体的に考えてみます。 Claude Code を日常的に使っていると、小さな不満が溜まります。この確認は毎回許可しているので省きたい。このツールの出力が長すぎて読みにくい。このコマンドを打つ前に必ず確認したい。 従来はこうした不満に対して、公式の設定で対応できるか試して、できなければ諦めるしかありませんでした。

mods は、ここに手を入れられます。 しかも TypeScript の小さな関数なので、Claude Code 自身に書かせられます。「ツール出力のこの部分を折りたたむ mod を書いて」で済む規模です。

ただし、個人利用で最も注意すべき点があります。sec-default は Team / Enterprise の機能です。

個人プランで使っている場合、権限拒否の上書きを防ぐ最低保証がありません。 つまり、他人が作った mod を入れたとき、それが権限確認を無効化していても気づけない可能性があります。mods はサンドボックス化されておらず、Claude Code と同じマシン権限で動きます。 これは「悪意ある mod は何でもできる」という意味です。

したがって個人利用での実務ルールは、次の2つに尽きます。 (1) 自分で書いた mod、または公式同梱の mod だけを使う。 (2) 他人の mod を入れる場合は、ソースを読む。 TypeScript の小さな関数なので、読むのは現実的です。読まずに入れるなら、それは知らない人のシェルスクリプトを実行するのと同じだと理解しておくべきです。

受託や支援の文脈では、mods は提案材料になります。

「AI コーディングツールを導入したが、チームで使い方が揃わない」という相談は、ほぼ必ず出ます。 原因の多くは、「何を自動で許可し、何を人が確認するか」がチームで共有されていないことです。各自が自分の判断で --dangerously-skip-permissions 相当の運用をしていたり、逆に全部確認していて遅かったりします。

mods は、この判断をコードにできます。 「このパターンのコマンドは自動許可、このパターンは必ず確認」という方針を mod として書き、プラグインとしてチームへ配布する。 これはドキュメントで共有するより確実です。ルールを文書で配ると守られませんが、mod として配れば実行時に効きます。

提案時に押さえるべき前提を2つ書きます。

1つ目は、プランの確認です。 sec-default が無い個人プラン前提のチームに mod を配ると、統制の土台が無いところに統制の仕組みだけを載せることになります。Team / Enterprise への移行が前提かどうかを先に確認してください。

2つ目は、保守の引き受け先です。 mod は TypeScript のコードであり、Claude Code の更新で動かなくなる可能性があります。 作って渡して終わりにすると、数か月後に「動かなくなった」と言われます。誰が保守するかを決めてから作るべきで、決まらないなら作らないほうがよい類のものです。

学習の観点では、mods が示している構造に目を向ける価値があります。

**「拡張のための窓を増やす」のではなく、「組み込み機能自体を拡張の仕組みで作り直す」**という方向です。/diff が mod になったのは象徴的で、公式と拡張が同じ土台に乗ったことを意味します。

この構造を取ると、公式は「機能を作る」から「土台を作る」へ役割が移ります。 一方で利用者側は、「公式が対応してくれない」という不満の持ち場が無くなります。 できるのに作らないのは自分の選択になるからです。

自分の道具をどこまで自分で作るかという判断は、今後あらゆるツールで出てきます。 作れば手に馴染みますが、保守が自分に乗ります。作らなければ公式の都合に従います。mods は、この判断を Claude Code という毎日使う道具の上で突きつけてくる機能です。