Claude CodeのClaude Modsとは？組み込みmod3種でわかる強み

この記事のまとめ

Claude Modsは、function hooksによってClaude Codeを拡張する機能の製品名です。Claude Codeには、sec-default、diff、telemetryという3つの組み込みmodが含まれており、これらを確認することでModsで何ができるのかを具体的に把握できます。本記事では、大きく次の4つのポイントを押さえます。

Claude Modsは製品としての呼称であり、技術用語であるfunction hooksはModsの基盤となる実装プリミティブとして位置づけられています。modはfunction hooksを利用するプラグインです。
組み込みの3種は、組織設定を保護するsec-default、未コミットの変更を横のペインに表示するdiff、イベントを分析用のログ行として記録するtelemetryです。
プラグインはミドルウェアのように入れ子構造となり、先に登録されたものが後続の処理を包み込みます。管理者は制御のために先頭へ、既定値設定のために末尾へ追加します。
hooksモジュールはfunction hooksが有効化されている環境でのみ読み込まれ、APIは予告なく変更される可能性があります。

Claude Modsとは

Claude Codeとプラグインの前提

まず、Claude Modsの土台となるClaude Codeとプラグインの位置づけを確認します。生成AIを実務で使い倒している立場から言うと、コーディングツールとエージェントの境界がここまで曖昧になってきたのは、ここ1〜2年の変化として特筆すべき点です。

Claude Codeは、ターミナル上で動作するエージェント型のコーディングツールです。コードベースを理解し、定型作業の実行、複雑なコードの解説、gitワークフローの処理を自然言語のコマンドだけで進められます。単に補完するだけでなく、実際に動く処理をエージェントとして実行する点が、従来のコーディング支援ツールと大きく異なります。

利用環境はターミナルやIDEのほか、GitHub上で@claudeをメンションする方法もあります。公式リポジトリには、カスタムコマンドやエージェントによって機能を拡張する複数のClaude Codeプラグインが含まれており、詳細な仕様はプラグインディレクトリにまとめられています（参照*1）。

プラグインは、Claude Codeに独自の機能を追加するための仕組みです。プロジェクトやチームを横断して共有可能なカスタム機能として活用できます。公式ガイドには、スキル、エージェント、フック、MCPサーバーを備えた独自プラグインの作成方法が解説されています（参照*2）。

function hooksとModsの関係

次に、Claude Modsとfunction hooksの関連性を整理します。

Anthropicの公式コミュニティ更新情報によると、function hooksは数日や数か月ではなく数週間規模でリリースすることが決定されたと説明されています。そのうえで、製品としての観点からこの機能を「Claude Mods」と呼ぶ予定であるとしています。

技術用語としてのfunction hookは、Modsの基盤となる文書化された実装プリミティブとして引き続き残ります。modはfunction hooksを利用するプラグインにほかならず、その点に変更はないと明記されています（参照*3）。

発端となった提案は、ExpressやKoaのようにTypeScript関数を用いてClaude Codeへフックし、任意の処理を変更できるようにすると便利ではないか、という着想に基づいています。これにより職場の管理者も、ユーザーが変更可能な範囲を含め、プログラム上の細かな挙動まで制御できるようになります。この設計思想は、Webフレームワークのミドルウェアに慣れた開発者には非常に直感的に映るはずです。

インターフェースや設計は現在も急速な改善が進められていますが、意味論の大半は定まってきており、初期ほどの破壊的変更は生じていないとされています。その段階において、初期の組み込みmod3種のソースコード一覧が公開されました（参照*3）。

組み込みmod3種でわかる機能

sec-defaultの組織向け既定

sec-defaultは、ユーザーのプラグインから組織の設定を改変されないように保護する組み込みmodです。企業がClaude Codeを組織導入する場面では、この種の保護層は必須といえます。

modは、実体となる処理がhooksモジュールに配置されたClaude Codeプラグインであり、register(on, options)のエントリポイントからエンジンのイベントを関数としてフックします。3つの組み込みmodはClaude Codeに同梱されており、公開フォルダーにはバイナリへと組み込まれる形でビルドされたソースコードが含まれています。sec-defaultは、組織の既存フック、プロンプトコンテンツ、管理設定、ツールポリシーに対して、ユーザーが導入したプラグインからアクセスできないようにブロックします。

独自のポリシーを追加することはありません。管理設定が適用されているマシンや、TeamあるいはEnterprise組織においては、managedのprependPluginsによる別の指定がない限り最外部に配置されます（参照*4）。

動作自体はシンプルで、3種類のみです。1つ目はユーザーティアを越えて後続処理へと渡すnext.to(e, "append")、2つ目はnext.origin.tierがuserの場合に呼び出し元を名前で拒否する{ deny }、3つ目はそのまま通過させるnext(e)です。処理対象の出所は、イベントに固定されたe.providerによって判定されます。

ポリシーは$.settings.read({ source: "policy" })から読み取られ、1度の読み取りで一連の処理に対応します。ポリシー読み取りはフェイルクローズ設計となっているため、読み取れなかったポリシーは有効なポリシーとして扱われます（参照*5）。

私が生成AI導入支援を行う中でよく目にするのは、便利な拡張機能を入れた結果として組織ポリシーが形骸化するパターンです。sec-defaultのようなフェイルクローズ設計の保護層が標準で組み込まれているのは、エンタープライズ利用を意識した現実的な判断だと見ています。

diffの差分ペイン

diffは、未コミットの変更差分をトランスクリプトの横に表示する組み込みmodです。コーディング中に「いま何が変わっているか」を視覚的に把握できるのは、エージェント型ツールとしての実用性を大きく高める機能です。

/diffを実行すると、セッション内の未コミットの変更がトランスクリプトの横に開きます。変更されたファイルごとに1行ずつ並び、その下に各ファイルのハンクが表示され、再度コマンドを実行すると閉じます。表示を切り替えるたびに、トランスクリプト上にはDiff panel shownまたはDiff panel hiddenという記録が残ります（参照*6）。

比較基準となるベースも選択可能です。ペインには、作業ツリーとHEAD、セッション開始時点の作業ツリーとHEAD、あるいはデフォルトブランチとのマージベースのいずれかを比較した結果が表示されます。セッション開始時点以外のベースを選んだ場合はヘッダー下のベース行に表示され、選択内容はリポジトリごとにプラグインのストアへ保存されます（参照*6）。

ペインが自動的に開くトリガーは編集の成功です。セッション内で最初の編集が成功すると、レイアウトがトランスクリプトの横にドッキングし、ターミナルの幅が十分であれば自動的にペインが開きます。全画面レイアウトの場合、ターミナルの幅が110列未満であれば自動的には開かず、表示領域を広げるよう促すメッセージ行が表示されます（参照*6）。

telemetryの計測用名詞

telemetryは、プラグインがイベントを分析用データとして記録できるようにするための拡張メソッド（名詞）を追加する組み込みmodです。

提供されているメソッドは2点です。$.telemetry.log({ event, props })は、1つのイベントをファーストパーティーのログ行として送信します。$.telemetry.mark({ feature, kind, reason?, props? })は、CLI自体の機能イベントと同様に、特定機能の1回ごとの利用実績を記録します（参照*7）。

データが送信されない条件も明確に定義されています。CLI本体の分析機能が無効化されている場合は何も送信されません。具体的な条件は3つです（参照*7）。

DISABLE_TELEMETRY、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DO_NOT_TRACKのいずれかが設定されている場合
BedrockやVertex、Foundryなどのサードパーティープロバイダーを利用している場合
独自のOAuth URLを持つデプロイメント環境である場合

組み込まれる範囲も限定的です。本プラグインはCLI自身によって、CLI独自の分析が有効な内部ビルドでのみ組み込まれ、それ以外の環境では組み込まれません。session.authorizeはそこにのみ存在し、出力されるログ行は、CLI独自のイベントのみが届くテーブルへと追加されます（参照*7）。

Modsの仕組みと構造

登録順とミドルウェア的な合成

Modsは、登録された順番に従ってそのまま入れ子構造を形成します。この設計は、ExpressやKoaのようなWebフレームワークに慣れた開発者なら迷わず使えるはずです。

公式コミュニティ更新情報では、プラグインがミドルウェアのように入れ子になると説明されています。最初に登録されたプラグインが残りの全体をラップするため、管理者は制御用の処理を先頭に追加し、デフォルト設定用の処理を末尾に追加します（参照*3）。

ティアの実行順序もあらかじめ定められています。function hooksは、すべてのプラグインに対してチェーン順にすべてのイベントへの介入権を付与します。

ユーザーが手動でインストールしたプラグインはユーザーティアに配置され、組織用のprependティアの下、appendティアの上に挟まる形となります。この実行順序が保たれているからこそ、sec-defaultが組織向けのセキュリティ規定として確実に機能します（参照*5）。

プラグイン構成と型・テスト

modの実体は、規定のファイル構成と型定義、そしてテスト実行コマンドによって成り立っています。

個々のフォルダーが独立した完全なプラグインとなっています。構成としては、.claude-plugin/plugin.json、モジュールを指定するhooks/hooks.json、そして宣言に対応して型付けされたhooks/内のTypeScriptファイルから成ります。/plugin-typesにはimport type … from 'claude-code'が記述され、ここではtypes/配下に保持されています。

ソースから直接実行して挙動を確認するには、claude –plugin-dir mods/diffを使用します。テストコードはtests/フォルダー内に配置され、claude plugin test mods/diffで実行可能です。テスト実行時には、エンジン自身の$およびプラグインのonを取得できます（参照*4）。

拡張オブジェクト（名詞）の型定義にも決まりがあります。engine.createのfoldによって$へ名詞を追加するmodは、その名詞の型を独自に所有し、1か所に集約します。

その配置場所となるtypes/index.d.tsは、import文を含まないアンビエント宣言ファイルです。そこでは名詞を構成する型をそれぞれ名詞に応じた名称でエクスポートし、claude-code内のEngineInterfaceに対してその名詞を型拡張として宣言します（参照*4）。

Claude Modsの強み

表示と操作まで変えられる拡張性

Claude Modsでは、画面の描画やUIのボタン操作に至るまで柔軟に変更可能です。

公式コミュニティ更新情報では、プラグイン側で独自のUI描画が可能になった点が紹介されています。コンポーネントにフックすることで、そのpropsを変更したり、返却されたレンダーノードを別の要素でラップしたりできます（参照*3）。

ユーザー操作に関しても同様の仕組みで処理できます。フックはインタラクションの捕捉にも対応しており、ui.pressに対する1つのフックを用意するだけで、ターミナルとデスクトップアプリの双方で押された同一のボタン入力を検知できます。つまり、実行環境ごとに個別の処理を書き分けることなく、統一されたフックで押下イベントを受け取れる構造になっています（参照*3）。

監査と管理者による制御

監査ログの収集や管理者による機能制御も、フックを用いて実装できます。生成AI導入で最初に詰まるのはプロンプトではなく、「誰が何を実行したか」を追跡できる仕組みの不在です。その観点で言うと、単一フックで全イベントをカバーできるこの設計は実用的です。

*に対して設定された1つのフックは、$を介したプラグイン自身の呼び出しを含め、すべてのイベントを監視します。そのため、包括的な監査ログの収集も単一の関数を用意するだけで実現できます（参照*3）。

管理者側には、特定機能そのものを無効化・削除する権限が用意されています。管理者が$から機能を削除すると、配下に位置するすべてのプラグインは該当の副作用を呼び出せなくなります。先に登録されたものが後続を包み込むという実行順序の原則を考慮すると、管理者を先頭に配置する設計の妥当性がよく分かります（参照*3）。私が企業への生成AI導入を支援する際、「管理者がどこまで制御できるか」は必ず確認される論点です。この構造はその問いに対して、技術的に明確な答えを返せる設計になっています。

小さな依頼から作れるプラグイン

シンプルな自然言語の指示からプラグインを自動生成する例も、デモとして公開されています。「作るためにコードを書く」というハードルが下がれば、プラグインの活用層は一気に広がります。

公式コミュニティ更新情報では、短く簡潔なプロンプトを基に、Claude自身がモデルへの入力前にツール出力内の機密情報をマスキングするプラグインを生成・検証し、読み込むまでの一連の流れが実演されています。もう1つの例では、Claude Code Desktop上で機密性の高い値にマウスホバーするまで非表示を維持し、画面共有時にも安全に作業できるプラグインが紹介されています（参照*3）。

公開コンテンツの作成背景についても明示されています。同投稿のAI usage disclosureでは、サムネイル画像にはAI生成を用いているものの、紹介されているデモやソースコードは本物であり、実際のバイナリ上で動作している旨が記載されています（参照*3）。

利用時の注意点

早期アクセスと有効化の前提

Claude Modsは現在早期アクセスの段階にあり、利用可能な環境や仕様変更に関する前提条件が提示されています。

公開ソースの注記によると、hooksモジュールはfunction hooksが明示的に有効化されている環境でのみ読み込まれます。これらのmodが依存している対象APIは、今後のリリースにおいて予告なく変更される可能性があります。また、3つの組み込みmodはリポジトリのマーケットプレイスには公開されておらず、手元のClaude Code環境にすでに同梱されているコピーのみが実体を持ちます（参照*4）。

機能を試すための手順も案内されています。公式コミュニティ更新情報では、v267/v268の機能を整理したチートシート形式のリファレンスが提供されるとともに、テストを実施してフィードバックを行いたい開発者に向けて、CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claudeによる起動が利用可能であるとアナウンスされています（参照*3）。

フックに伴う安全面の論点

フックという仕組みそのものが内包するセキュリティリスクについては、先行研究の論文でも指摘がなされています。この点は、Claude Modsに限らず生成AIの業務導入全般に関わる問題として、正面から理解しておく必要があります。

論文の著者らは、現代のAIエージェントハーネスがライフサイクルフックを公開している点に着目しています。これは、セッション開始、ツール呼び出し、ファイル編集といったランタイムイベントに対してシェルコマンドをバインドする仕組みです。

これらのコマンドはホストの権限で実行されますが、ライフサイクルフックの設定値として渡されるため、LLMが関知しないタイミングで実行されるリスクがあります。著者らは、ハーネスが無条件に信頼してしまっているライフサイクルフックの更新経路を、新たな攻撃対象領域として特定しました（参照*8）。

検証実験では深刻な結果が示されています。攻撃フレームワークであるHookPryは10種類の攻撃目的を達成し、ハーネスとバックエンドの25通りの組み合わせにおいて計1,000回のエンドツーエンドテストを実施した結果、検証対象となった7種すべてのハーネスを侵害し、ハーネスごとの攻撃成功率は最大92.5%に達しました。既存の代表的な防御策は依然として不十分であり、Microsoft Defenderの再現率は0%、3つの静的防御を組み合わせた場合でも悪意あるアーティファクトの47.5%が見落とされていました。

著者らは、プラグインのインストールや更新、フックの登録、実行時の情報フロー全体を検証対象に含める必要があると提言しています。さらにハーネス側でも、変更されたフックを個別に承認し、プラグインマニフェストの署名をペイロードと紐づけ、最小権限の原則を徹底すべきであると論じています（参照*8）。生成AIのセキュリティリスクは情報漏洩だけではない、という私の認識と重なる指摘です。

なお、この調査は従来型のライフサイクルフック全般を対象としたものであり、Claude Modsそのものの脆弱性を直接評価した結果ではない点に留意が必要です（参照*8）。

おわりに

Claude Modsは、function hooksを活用してClaude Codeを拡張する機能の製品名です。技術用語としてのfunction hookは、Modsの基盤となる実装プリミティブとして位置づけられています。組み込みのsec-default、diff、telemetryの3種は、組織設定の保護、差分表示、イベント計測といった観点から、拡張性の高さを具体的に示しています。現時点では早期アクセス段階ですが、設計の思想は実務の要件に即しており、企業導入を意識した構造になっていると見ています。

アーキテクチャの面では、プラグインがミドルウェアのように入れ子構造となり、先に登録されたものが後続を包み込む形で動作します。ただし、hooksモジュールはfunction hooksが有効化されている環境でのみ読み込まれ、API仕様もリリースごとに予告なく変更される可能性がある点には注意が必要です。生成AIのツールは、性能よりも「組織の中でどう管理できるか」が導入の可否を分けます。Claude Modsがその問いに対してどう応えていくか、引き続き注視したいところです。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））