1. そもそも「Mods」とは何か

⚠️ 注記: 本記事はClaude Code公式ドキュメント（code.claude.com/docs、2026年10月時点）に基づく解説です。Claude Codeは更新が速く、機能・対応範囲・セキュリティ仕様が変わることがあります。実際の導入検討時は、必ず公式ドキュメントで最新の仕様をご確認ください。

公式ドキュメントは、Modsを「Claude Codeの見た目と動作を変えるプラグイン」と説明しています。JavaScript／TypeScriptで書かれた関数（イベントハンドラ）が、ツール呼び出しやプロンプト送信、画面描画といったイベントが起きるたびにClaude Codeから呼び出され、そのイベントを「観察する」「書き換える」「代わりに処理して本来の動作を止める」といった形で介入できる、という仕組みです。

ここでまず押さえておきたいのが、Modsは「Claude Codeの内側で動く」拡張機能だという点です。これまでの拡張の仕組み——設定ファイルで指定する「フック（settings hook）」、Markdownの手順書である「スキル」、外部のツールを連携させる「MCPサーバー」——は、いずれもClaude Codeの"外側から"指示を出す仕組みでした。それに対してModsは、Claude Codeというプロセスの内部に入り込んで動く関数として実装されています。この「内か外か」の違いが、できることの範囲の違いにそのまま表れます。

公式ドキュメントが示す比較を、非エンジニア向けにかみ砕くと次のようになります。

表の一番右の列、「画面描画」ができるかどうかが、Modsだけの特徴です。トランスクリプトの横にパネルを出したり、プロンプト入力欄の上にバンドを表示したり、タブやボタン、テキスト入力欄を自前で用意したりできます。さらに、ツール呼び出しの行やスピナー、Claudeが確認を求めるダイアログといった「Claude Code自身が描く部分」まで再描画・置き換えができる、と公式ドキュメントは説明しています。

なお、Modsはプラグインという大きな入れ物の中の一要素という位置づけです。1つのプラグインの中に、Mod・スキル・MCPサーバーなどを同時に含められます。配布も通常のプラグインと同じ方法（/plugin install <mod名>@<マーケットプレイス名>、または、claude plugin install <mod名>@<マーケットプレイス名>というシェルコマンド）で行います。

2. どこで動くのか、どうすれば使えるのか

Modsが使えるのは、Claude Code CLIと、Claude Desktopアプリの「Code」タブです。一方で、VS Code拡張機能のチャットパネル、コマンドラインから一括実行するclaude -p、Agent SDK、クラウド上のセッションでは、Mod内部の処理（フック部分）は動くものの、画面の描画は出ません。claude.aiやスマホアプリから手元のClaude Codeを操作するRemote Controlでは、処理は手元のマシンで動き、描画は手元のターミナル側に表示されます。Desktop上のWSL（Windows内のLinux環境）セッションでは、プラグインの仕組み自体が使えないためMods自体が動きません。なお、claude.ai単体（Web版）での扱いについては、公式ドキュメントに記載が見当たらず未確認です。導入環境ごとに動作が異なるため、自社の利用環境でどこまで使えるかは、導入前に公式ドキュメントで確認することをおすすめします。

Modsは、Claude Code v2.1.287以降では最初からオン（デフォルト有効）になっています。バージョンはclaude --versionで確認できます。オフにしたい場合は、「/pluginから個別のプラグインを無効化する」「--safe-modeで起動する」「~/.claude/settings.jsonにdisableAllHooks: trueを設定する」のいずれかの方法が用意されています。

Modsの入手方法は、プラグインと同じくマーケットプレイス経由のインストールに加えて、もう一つ独特な方法があります。Claude自身にModを書かせて、その場で読み込ませることができる、という点です。Claude Codeのセッション内で「こういう動きをするModが欲しい」と伝えれば、ClaudeがJavaScript／TypeScriptのファイルを書いてくれます。

3. 公式ドキュメントが示す「できること」

公式ドキュメントが機能として挙げているのは、大きく次の3種類です。

① ツール呼び出しへの介入。ツールが実行される前に割り込み、処理を保留してユーザーに確認を求める、ツールを実行せず別の回答で代替する、別のモデルにリクエストを送る、といった制御ができます。

② 権限リクエストの承認・拒否。通常であればユーザーに「このツールを実行してよいか」という確認プロンプトが表示される前のタイミング（tool.checkというイベント）で、Modが承認・拒否を行えます。ただし、確認プロンプトに表示される内容自体をModが書き換えることはできない、という制約も明記されています。

③ 画面の再描画・独自パネルの表示。前章で触れた、パネル・バンド・タブ・ボタン・入力欄の表示や、Claude Code自身が描く確認ダイアログなどの再描画です。

これらの機能を実際に使った例として、差分表示を行う/diffコマンドが挙げられます。/diffは、すでに組み込みのMod（cc-plugin-diff）として実装されており、/pluginから無効化すると、代わりに素のビルトイン版/diffに戻ります。これはAnthropic自身が、Claude Codeの既存機能を少しずつModとして切り出し始めている例と言えます（なお、上記①〜③の機能を/diffが具体的に組み合わせて示す実例として公式ドキュメントが位置づけている、という記載は見当たりません。ここでの整理は本記事側の解釈です）。ほかにも、AGENTS.mdを読み込むcc-plugin-agents-md、管理者向けの保護機能であるcc-plugin-sec-default、計測データを送るcc-plugin-telemetry、長めの作業中に別のエージェントを裏で動かして、見落としがちな点を知らせるcc-plugin-you-should-know（デフォルトは無効）といった組み込みModが用意されています。

4. 業務で何に使えそうか——公式の例と、ここからの推測を分けて考える

ここからは、前章の仕組みを業務に当てはめるとどうなるかを考えます。ただし一つ注意が必要です。Anthropicが公式に名指しで挙げている業務ユースケースは、現時点の公式ドキュメントには見当たりません。公式が示しているのはあくまで「ツール呼び出しに介入できる」「権限リクエストを承認・拒否できる」「画面を書き換えられる」という"仕組み"です。以下は、その仕組みから考えられる応用の方向性であり、Anthropicの謳い文句ではなく本記事側の例示として読んでください。

• 特定の操作の前に、必ず人の承認を挟む：たとえば「顧客データに関わるファイルへの書き込み」のように、社内で特に慎重に扱いたい操作だけを対象に、確認を必須化するという考え方です。tool.checkで権限リクエストに介入できる仕組みを使えば、理屈としてはこうした運用が組めます。
• 社内ルールに合わない操作を止める：たとえば「特定のディレクトリの外には書き込ませない」といった社内の運用ルールを、ツール呼び出しのブロック・差し替えの仕組みを使って機械的にチェックする、という発想です。
• ツール出力に含まれる情報への対応：ツール呼び出しの結果を書き換えられる仕組み（tool.callイベントでの書き換え）を使えば、技術的には出力内容に手を加えることが可能です。ただし「秘密情報の伏せ字化」という具体的な機能名やサンプルは、本記事が確認した公式ドキュメントの範囲では見当たりませんでした。この用途が公式に標準機能として用意されているわけではない、という点は明確にしておきます。

いずれも「こういう運用を組める可能性がある」という段階の話であり、実際に安全に運用できるかどうかは、どのModを使うか、どう設定するかに大きく依存します。次の章で触れる通り、Mods自体は本体と同じ権限で動くため、「介入できる」という仕組みそのものを、無条件に安全な機能だと捉えないことが重要です。

5. いちばん大事な注意点。Modsは「本体と同じ権限」で動く

ここまで機能面を見てきましたが、会社として導入を検討するなら、セキュリティ面の制約を正確に理解しておくことが欠かせません。公式ドキュメントが明記している内容を、順に確認します。

Modsはサンドボックス化されていません。Claude Codeにはコマンド実行を隔離するサンドボックス機能がありますが、これが隔離できるのは「Claudeが実行するBashコマンド」だけです。Modが起動するプロセスは、このサンドボックスの外で動きます。

Modは、Claude Codeを使っているユーザー本人と同じ権限で動きます。公式ドキュメントが具体的に挙げている範囲は次の通りです。

• 読み書き可能な全ファイルへのアクセス
• プロセスの起動
• ネットワークリクエスト
• 環境変数・設定ファイル（APIキーを含む）の読み取り
• セッション中の全プロンプト・全ツール呼び出しの閲覧・書き換え
• ユーザーに確認せずにツール呼び出しを承認すること
• ユーザーのプラン・APIキーを使ったモデル呼び出しの消費

つまり、「便利な拡張機能」という見た目の裏側で、Modは社内のファイルやAPIキーにまで触れられる立場にある、ということです。この前提を踏まえて、Anthropicは公式に「信頼できる作成者・マーケットプレイスからのみインストールすること」を推奨しています。

導入前にModの内容を確認する方法も用意されています。claude plugin validate ./モッドのディレクトリを実行すると、そのModが受け取るイベント（hooks:）と、呼び出すAPI（calls:）の一覧が、実行せずに表示されます。たとえば$.fs.read／$.fs.write（ファイルの読み書き）、$.process.run（プロセスの起動）、$.http.fetch（ネットワーク通信）、$.env.get（環境変数の読み取り＝APIキーを含む可能性がある）といった呼び出しがないかを、インストール前に確認できます。

企業向けプラン（Team・Enterprise）のユーザー、または管理設定（managed settings）が配布されている端末では、組み込みの監視Mod「cc-plugin-sec-default」が自動的に先頭で動き、管理者が設定したシステムプロンプトや管理用CLAUDE.md、管理用MCPサーバー設定を、ユーザーが入れたModが書き換えられないよう保護します。さらに管理者はallowManagedModsOnlyという設定で、「社員が個人で入れたModは一切読み込まない。会社が配布したModだけを動かす」という方針に固定することもできます。逆に言えば、こうした管理者側の制限がない場合、デフォルトでは「それ以外は全て許可」——ファイルの読み書き・プロセス起動・通信・ツール呼び出しの承認拒否・画面描画のいずれも、ユーザー権限の範囲でModが行える、ということです。

もう一つ、社内ルールを考えるうえで押さえておきたい点があります。この保護用Modが動いている環境では、管理者が設定した「禁止（deny）ルール」は、ユーザーのModより優先されます。ただし、優先されるのはです。Mod自身が行うファイルの読み書きやプログラムの起動には、この禁止ルールが効きません。公式ドキュメントは、たとえばファイルの読み取りを禁止していても、Modはそのファイルを読めると説明しています。つまり、Claude Code向けの禁止ルールを整えただけでは、Modによる情報の持ち出しは防げない、ということです。

6. 会社として導入するなら、先に決めておきたいこと

ここまでの内容を踏まえると、会社としてModsを扱う際に決めておくべきことは、機能の使い方そのものよりも運用のガバナンスに重心があります。具体的には、次の3点です。

① 誰が入れてよいか。Modは本体と同じ権限で動く以上、「気になったものを誰でも自由に入れてよい」状態は避けたいところです。情シスや管理者の承認を経て入れる運用にするか、個人の裁量に任せる範囲をどこまで認めるか、会社としての立場を決めておきます。

② 配布元をどう確認するか。Anthropicが推奨する「信頼できる作成者・マーケットプレイスからのみ」を、自社の基準に落とし込みます。社内で使ってよいマーケットプレイス・作成者のリストを作っておく、出どころの分からないModは原則入れない、といった基準が考えられます。

③ 社内での承認フロー。claude plugin validateで、そのModがファイル読み書き・プロセス起動・通信・環境変数読み取りのどれを行うかを事前に確認する運用にするかどうかを決めます。管理設定（managed settings）を社内の端末に配布している会社であれば、管理者がallowManagedModsOnlyを設定し、「会社が配布したModだけを動かす」という統制に踏み切るという選択肢もあります。前章のとおり、Claude Code向けの禁止ルールだけではMod自身の動きは止められないため、Modを入れる余地をどこまで残すかは、この設定とセットで考えるのが確実です。

これらは、どれも「機能を知っているか」では解決しません。自社にとって、どこまでのリスクを許容し、どこから承認を必須にするかという、経営判断そのものです。Modsという機能が登場したことで、こうした判断を一度棚上げにせず、早い段階で決めておく価値が出てきた、と言えます。

7. でも、ルールを決めるだけでは成果は出ない

Modsの仕組みと、会社としてのガバナンスの考え方を整理してきました。しかし最後に大事なことをお伝えします。「入れてよい・ダメ」のルールを決められること自体は、ゴールではありません。

多くの会社では、「Modsという機能があることは分かったが、自社のどの業務で、どのModを使えば実際に効果が出るのかが分からない」「ルールだけ先に決めたが、そもそもClaude Codeをどう業務に組み込むかの設計が追いついていない」という壁にぶつかります。Modsのようなガバナンスが必要な拡張機能ほど、「使うか使わないか」の判断と、「使うならどう現場に定着させるか」の設計をセットで進める必要があります。

自社の業務のどこにClaude Codeを使い、どこまで拡張機能に任せ、どこに人の承認を残すか。そこを、機能の理解だけで終わらせず、現場に入り込んで実装と運用設計まで伴走してくれる相手と進めることが、AIを本当の成果に変える近道になります。私たちの「Protostar AI Works」は、まさにこの実装と定着を現場で伴走する支援です。「触れる」から「成果が出る」へ、ご一緒します。

まとめ

Claude Codeの新機能「Mods」は、設定フック・スキル・MCPサーバーとは違い、Claude Codeの内側で動く拡張機能でした。

• Modsは「Claude Codeの内側で動く関数」。ツール呼び出し・プロンプト・画面描画まで変更できる点が、外側から指示を出す設定フック・スキル・MCPサーバーとの大きな違い
• v2.1.287（2026年10月1日公開）からデフォルト有効。CLIとDesktopの「Code」タブで動作し、他の実行環境では画面描画が出ないか、動作そのものが使えない場合がある
• 公式が示す機能は「ツール呼び出しへの介入」「権限リクエストの承認・拒否」「画面の再描画」の3種類。業務での具体的な使い道（承認の必須化、ルール違反操作の抑止など）は、この仕組みから考えられる応用例であり、公式が名指しする用途ではない
• 最も重要な注意点は、Modsがサンドボックス化されておらず、ユーザー本人と同じ権限で動くこと。ファイル・ネットワーク・APIキーにまで及ぶ
• 会社として導入するなら、「誰が入れてよいか」「配布元の確認基準」「社内承認フロー（claude plugin validateの活用、管理設定でのallowManagedModsOnlyなど）」を先に決めておく。Claude Code向けの禁止ルールはMod自身のファイル読み書きには効かない点に注意

Mods自体は便利な拡張の仕組みですが、会社としての価値は「入れる・入れない」を決めた先にある、実際の業務への組み込みと運用設計で決まります。

📚 あわせて読みたい「今さら聞けないClaude Code」シリーズ
①権限モード編：どこまで自動で動かすか
②スキル編：よく使う手順を"技"にして自動化する
③CLAUDE.md編：AIに"社内ルール"を覚えさせる

⚠️ 本記事の内容は執筆時点（2026年10月）のClaude Code公式ドキュメント（code.claude.com/docs）に基づきます。Mods自体の仕組み・対応範囲・セキュリティ仕様は今後のバージョンアップで変わる可能性があるため、実際の導入検討時には必ず公式ドキュメントで最新情報をご確認ください。

出典・参考

• Claude Code Changelog（X）v2.1.287 リリース告知：https://x.com/ClaudeCodeLog/status/2105721911036481778
• GitHub Release v2.1.287：https://github.com/anthropics/claude-code/releases/tag/v2.1.287
• Claude Code公式docs「Mods overview」：https://code.claude.com/docs/en/plugins/mods/overview
• Claude Code公式docs「Mods admin」：https://code.claude.com/docs/en/plugins/mods/admin