Claude Code Modsを企業で許可する前の安全確認

結論：Claude Code Modsは「便利な設定」ではなく権限を持つコード

Anthropic公式のClaude Code changelogは、2.1.287でModsと組み込みの「You should know」を追加しました。公式のMods overviewは、Modがイベントを監視・書き換え・引き受けでき、UIを描画し、tool callやpromptを変更できると説明しています。既存のClaude Code権限設定やmanaged settingsの記事が通常の承認設計を扱うのに対し、本稿はModそのものを許可する前の判定に絞ります。

Mods、Hooks、Skills、MCPを使い分ける

仕組み	主な実行場所	選ぶ場面
Mod	Claude Code内部のJavaScript/TypeScript	UI、tool call、prompt、turnを観測・変更したい
Settings Hook	シェル、HTTP、prompt	allow/deny、記録、既存スクリプトで制御したい
Skill	Claudeが読む指示文	業務手順や判断材料を再利用したい
MCP	外部プロセス・サービス	Claudeから外部システムのtoolを呼びたい

UIに専用のpaneを出したい、tool callを保留して人間に質問したい、sessionを横断して処理したい、という要件はModの候補です。一方、危険操作をdenyするだけならsettings hook、社内手順の共有ならSkill、外部データ取得ならMCPから検討します。実行範囲が広いModを、狭い要件のために選ぶ必要はありません。

インストール前に見るべき6つの到達範囲

1. ファイル。ユーザーアカウントで読書きできる場所と、プロジェクト外の秘密ファイルへ到達しないかを確認します。
2. 秘密情報。環境変数、設定ファイル、APIキーを読める設計になっていないか、ログへ出さないかを見ます。
3. セッション。prompt、tool call、入力内容、他sessionへのメッセージを扱うかを列挙します。
4. 変更。promptやtool callを書き換えたり、承認を経ずにtool callを実行したりしないかを確認します。
5. 外部通信。ネットワーク先、送信データ、認証方式、タイムアウト、失敗時の挙動を記録します。
6. 利用量。Mod自身がmodelを呼び、APIキーやプランの利用量を増やさないかを確認します。

公式ドキュメントはModがsandboxされず、Bashのsandboxを有効にしてもModが開始するプロセスはその外で動く場合があると説明します。したがって「ClaudeのBashを制限したからModも安全」とは判断できません。レビュー対象はModのコードと、Modが呼ぶAPIです。

企業導入を7手順で進める

1. 利用目的を一つに固定し、UI表示、観測、tool制御のどれかを書きます。
2. 配布元、marketplace、commit、担当者、更新通知の経路を台帳に登録します。
3. コードを取得し、claude plugin validate ./対象ディレクトリを実行します。
4. 出力されたhooksとcallsを読み、ファイル・プロセス・ネットワーク・model呼び出しを確認します。
5. 秘密情報のない検証用repositoryで、通常操作、拒否操作、異常終了、更新を試します。
6. managed settingsで利用可能な範囲を決め、利用者の持ち込みModを止めるか承認します。
7. owner、ログ、期限、rollbackを記録し、少人数から段階展開します。

Modsは2.1.287以降で既定で有効です。個別のModを止める場合はInstalledタブで無効化またはアンインストール、一セッションだけ全Modを止める場合は--safe-modeを使います。全利用者に対してはmanaged settingsのallowManagedModsOnlyで組織管理のModだけを許可する設計が候補になります。設定変更後は、残りのSkills、MCP、Hooksまで意図せず止まらないかを確認してください。

組織ポリシーの比較と承認ライン

方針	向いている状態	追加条件
全員自由	個人検証だけで、機密環境と分離している	持ち込み禁止のデータ境界を明示
申請制	試験は必要だが、利用者と環境を絞れる	validate結果、owner、期限、停止手順
管理Modのみ	企業標準の拡張を配布する	managed settingsと更新レビュー
全面停止	コードの出所やログを確認できない	再評価日と代替手段を設定

最終承認者は開発責任者だけにせず、データ責任者またはセキュリティ担当を含めます。特にtool callの自動承認を行うModは、既存のdenyルールを上書きできる場合があるため、便利さの評価と安全性の評価を分けて記録します。

公開前チェックリスト

• Modの目的と、Modでなければならない理由が一文で書かれている
• 配布元、commit、更新者、依存plugin、撤去担当が分かる
• validate結果のhooksとcallsを人間がレビューした
• 秘密情報、prompt、tool call、ネットワーク送信の範囲を列挙した
• sandboxがModのプロセスを隔離しない可能性を説明した
• 個別停止、--safe-mode、組織停止の手順を試験した
• 異常時の停止条件、rollback、再承認日がある

既存のplugin evalを使える場合は、動作の再現性を評価し、権限レビューと合格基準を分けます。MCPの導入ならClaude Code MCPのセキュリティ確認も参照してください。拡張の種類が増えるほど、許可・ログ・停止を一枚の台帳にまとめると担当者交代に耐えます。

FAQ

Modsは個人の開発環境だけなら自由に使えますか？

機密repositoryや会社のAPIキーへ到達できる環境なら、個人利用でも組織のデータ境界が適用されます。検証用環境を分け、許可された配布元と停止手順を確認してください。

既存のHooksをModへ移行すべきですか？

自動移行は不要です。UI描画や内部イベントの変更が必要な部分だけをMod候補にし、allow/denyや監査だけなら既存Hookを維持した方が範囲を狭くできます。

自社のMod導入条件を相談できますか？

できます。対象repository、扱うデータ、Modの到達範囲、承認者、停止条件を無料診断（60秒）で整理してください。

承認の記録には、Modの名前だけでなく、取得したcommit、validateを行った日、検証したClaude Codeのversion、許可したscope、次のレビュー日を含めます。marketplaceの名前が信頼できても、更新でコードが変わる可能性があるため、更新を自動適用するか、差分レビュー後に適用するかを決めます。利用者へは「何ができるか」だけでなく「何をしないか」も伝え、秘密情報を入力しないルールと異常時の連絡先を同じ場所に置きます。

本番repositoryで試す前に、空のrepositoryとダミーの環境変数で観測します。tool callを書き換えるModなら、拒否すべき操作が本当に止まるか、停止してはいけないread-only操作が継続するかを両方試験します。Modの出力が見えない場合は、利用者の操作ミスとModの未読込を分け、/pluginでsessionが読み込んだMod名を確認します。判断できない時は無効化して原因を保存します。

組織管理では、allowManagedModsOnlyを設定するだけで運用が完成するわけではありません。管理Mod自身の更新、持ち込みpluginに含まれるSkillsやMCPの扱い、managed settingsの配布失敗、オフライン端末の残存を点検します。Modだけを止めてもpluginの他の部品は残る設定があるため、必要な範囲と副作用をreadbackし、利用者へ変更を告知します。