Claude Code Modsが登場、ただしカスタムUIにはマシン全体へのアクセス権が伴う
Anthropicは10月1日、Claude Code modsをリリースした。これにより、これまで固定的だったコーディングエージェントは、その挙動に深くアクセスできるプログラマブルな基盤へと変わる。開発者はTypeScriptを使い、プロンプトの書き換え、ツール呼び出しのインターセプト、インターフェース要素の変更、組み込み機能の置き換えを行えるようになった。
このリリースは、通常のプラグイン更新以上の意味を持つ。Claude Code modsは、コーディングエージェントが生成するイベントの前後、その周囲、あるいは代わりに実行できる。Anthropicは事実上、外部開発者がイベントフローの内部から製品を変更できるようにしている。
この柔軟性は、制御と信頼の間に直接的な緊張関係を生む。有用なmodは、モデルが読み取る前にシークレットをマスキングできる。一方で、悪意のある、あるいは設計の不十分なmodは、Claude Code自身が利用できるのと同じマシンリソースへアクセスできる。
比較対象は、どのコーディングエージェントがより優れたコードを書くかだけではなくなった。OpenAIとGoogleも、拡張機能、スキル、フック、接続ツールを配布している。Anthropicは、エージェントの挙動とインターフェースを非常に高い自由度で置き換え可能にすることで競争圧力を強めている。
Claude Code Modsはイベントを拡張ポイントに変える
中心的な変更は、開発者が指示や外部コマンドを追加するだけでなく、Claude Codeの実行経路の内部に介入できるようになったことだ。
Anthropicはmodを、Claude Codeの動作を変える小規模なTypeScript関数と説明している。リリース発表によると、modsはコマンドラインインターフェースとデスクトップアプリケーションの両方で動作する。
Claude Codeはアクションを実行する際にイベントを発行する。こうしたアクションには、プロンプトの送信、ツールの呼び出し、権限の要求、インターフェースの一部のレンダリングが含まれる。modは、これらのイベントの1つ以上に対して関数を登録する。
その関数はイベントの前後、またはイベントの代わりに実行できる。また、イベントをラップすることもでき、元のアクションの前後で処理を行うことを意味する。
この構成は、Webアプリケーションのミドルウェアに似ている。各レイヤーはイベントを受け取り、検査、変換、ブロック、転送できる。複数のmodsがどのように相互作用するかはロード順で決まる。
最初にロードされたmodが最初にイベントを確認する。内側のレイヤーが処理を完了した後、最終結果を最後に受け取る。このネスト構造により、独立して開発された複数のmodsが同じワークフローに参加できる。
実用上の効果は、色の変更やショートカットの追加をはるかに超える。Anthropicによると、modはモデルが受け取る前にプロンプトを書き換えられる。また、ツール呼び出しをブロック、変更、再試行することも可能だ。
Modsは権限要求を承認または拒否できる。認証情報やその他の機密値を削除するなど、Claudeが読み取る前にツール出力をフィルタリングすることもできる。基盤となるモデルを変えずに、ユーザーに表示する内容を置き換えることも可能だ。
インターフェース層も介入対象として開かれている。Modsはツール結果を変更し、質問を置き換え、ボタンを追加し、入力を受け付け、独立したペインを作成できる。他のmodsは、ユーザーがそれらのコントロールを操作した際に応答できる。
これにより、Claude CodeのカスタムUIは単なる装飾的な機能ではなくなる。チームは会話の横にビルド状況を表示したり、構造化された承認を求めたり、変更されたファイルのライブビューを表示したりできる。
同じmodは、ターミナル、デスクトップアプリケーション、または両方を対象にできる。そのため開発者は、インターフェースごとに完全に別の拡張機能を用意する必要はないが、挙動は各環境で異なる場合がある。
Anthropicはこの機能を、Claude Codeの既存プラグインシステムにも接続した。Modsは別のインストール機構を通じて配布されるのではなく、プラグイン内にパッケージ化される。
ユーザーは互換性のあるプラグインを閲覧するか、CLIの/pluginからインストールできる。これによりAnthropicは、発見、共有、管理制御のための既存の経路を提供している。
開発者が必ずしも手作業でコードを書く必要はない。Anthropicによると、Claude Codeはリクエストからmodを作成し、インストールし、アクティブなセッション中にホットリロードできる。
このループは実験への障壁を下げる。望む安全策やインターフェース要素を説明し、生成されたTypeScriptを確認し、製品を再起動せずにテストできる。
ただし、生成コードによってレビューの必要性がなくなるわけではない。拡張機能を作成することから、その拡張機能が安全に動作するかを判断することへと、ボトルネックが移るだけだ。
Claude Code TypeScript Modsが従来のフックを超える理由
Claude Code TypeScript modsは、エージェントの活動を観察することと、その活動自体を変更することの間の隔たりを埋める。
Claude Codeは今回のリリース以前からフックをサポートしていた。従来のフックは、選択されたライフサイクルのタイミングでコマンドを実行し、多くの場合、標準入出力を通じてホストと構造化データをやり取りする。
このモデルは、通知、フォーマット、検証、単純なポリシーチェックには有効だ。しかし、拡張機能が永続的な状態、対話型コントロール、またはレンダリングされたインターフェースへのアクセスを必要とする場合には制約となる。
Anthropicによると、従来のフックでは、すべてのイベントの書き換え、新しいインターフェースコンポーネントの描画、既存機能の置き換えはできない。Modsは、エージェントの内部イベントシステムに対して型付き関数を実行することで、これらの機能を追加する。
通常、外部コマンドは製品のワークフローの横に位置する。この違いは重要だ。関数フックはそのワークフローの内部に直接入り込み、次に何が起きるかを変えられる。
例えば、従来のフックは危険なコマンドの詳細を受け取った後に拒否するかもしれない。modはイベントを検査し、コマンドを修正し、追加の確認を求め、代替応答を提供できる。
Modはセッション中に状態を保持することもできる。これにより、デプロイメントインジケーターやツールアクティビティに連動するチェックリストなど、エージェントの作業に合わせて更新されるコントロールをサポートできる。
TypeScriptインターフェースは、開発者にイベントおよび機能の宣言型を提供する。Claude Codeは/plugin-typesを通じてこれらの宣言を生成でき、エディターやコンパイラーは実行時より前に未対応の呼び出しを特定できる。
Anthropicのmodsドキュメントでは、関数フックが基盤となる仕組みとして紹介されている。「Mods」は、そうしたフックを中心に構築されたプラグインの製品名だ。
これは重要な境界線である。modは新しいモデルでも、プロンプトテンプレートでも、独立したアプリケーションでもない。Claude Codeの既存セッションに参加する実行可能な拡張コードだ。
Anthropicは、正式リリース前からこの仕組みを公開の場で議論していた。9月3日に開始された設計ディスカッションでは、TypeScript関数フックについて開発者からのフィードバックを求めた。
この提案は合成可能性を重視していた。関数は継続パターンを用いるため、各modは次のレイヤーを呼び出し、制御が戻った際に応答に対して処理できる。
Anthropicは9月9日の更新でClaude Modsという名称を確認した。同社は初期の組み込み例も公開し、実験的な環境フラグを通じたテストを可能にした。
10月1日のリリースは、その公開プレビューに続くものだった。この流れは、Anthropicが完成済みの製品機能として提示する前に、拡張契約についてフィードバックを得ようとしたことを示唆している。
このリリースは、Claude Codeのコアとオプション機能の関係も変える。Anthropicは、未コミットの変更を表示する/diffを組み込みmodへ移行した。
ユーザーはその実装を無効化したり、別の実装に置き換えたりできる。Anthropicは、今後さらに多くの既存機能をmodsへ移行する計画だとしている。
この方向性は、置き換え可能なコンポーネントに囲まれた、より小さなコアを指し示す。また、Anthropic自身がこのインターフェースをどのように使うかを示す公開リファレンスライブラリも生まれる。
リポジトリでは現在、4つの組み込みmodsのソースが公開されている。組み込みソースには、sec-default、diff、telemetry、agents-mdが記載されている。
これらの例が有用なのは、単に将来のAPIを約束するものではないからだ。Anthropicが完全なプラグインをどのように構成し、イベントを登録し、型を定義し、挙動をテストするかを示している。
リポジトリでは、関数フックは依然として早期アクセスと位置付けられている。APIはリリース間で予告なく変更される可能性があると警告している。そのため開発者は、現在の統合をバージョンに依存するものとして扱うべきだ。
この注意書きは、チームが重要なワークフローをどれほど迅速にmodsへ依存させるべきかを制限する。社内ステータスパネルは容易に改修できるが、本番環境の認可レイヤーにははるかに厳格な変更管理が必要になる。
拡張性をめぐる競争はエージェントの内部へ移っている
Anthropicは、どのモデルが最も優れた補完を生成するかだけでなく、誰がコーディング環境を制御するかを巡って競争している。
コーディングエージェントは、再利用可能な指示、外部ツール、ライフサイクルフック、インストール可能なパッケージをますますサポートするようになっている。これらのシステムにより、開発者は汎用エージェントを特定のリポジトリや組織に適応させられる。
GoogleのGemini CLI拡張機能は、プロンプト、MCPサーバー、カスタムコマンド、テーマ、フック、サブエージェント、スキルをまとめてパッケージ化できる。公式の拡張機能システムは、ユーザーがインストールして共有できるパッケージを重視している。
OpenAIのCodexプラグインモデルは、スキル、MCPサーバー、オプションのインターフェースリソース、ライフサイクルフックを組み合わせる。公開されているプラグインアーキテクチャは、ChatGPTとCodexの各環境で共有されるパッケージをサポートしている。
Claude Code modsはこれらのシステムと重なるが、Anthropicの訴求点はイベントの置き換えとネイティブレンダリングにある。modは、別のツールや指示セットを提供するだけでなく、エージェント自身のアクション経路を変更できる。
これにより、複数の面で競争圧力が生じる。
第一に、開発者はコーディングエージェントがインターフェースをプログラマブルな基盤として公開することを期待する可能性がある。別製品がカスタムペイン、ボタン、レンダリング結果を許可するなら、固定的なトランスクリプトの魅力は薄れる。
第二に、チームはエージェントのポリシーが実行可能で文脈に応じたものになることを期待する可能性がある。静的設定は一般的なルールを定義できるが、modはアクティブなイベントを評価し、より具体的な判断を下せる。
第三に、開発者は組み込み機能が置き換え可能になることを期待する可能性がある。Anthropicが/diffをmodとして実装した決定は、同じ拡張契約がファーストパーティとサードパーティのコードの両方に利用できることを示している。
ただし、すべての拡張システムが直接交換可能になるわけではない。OpenAI、Google、Anthropicは、それぞれ異なるイベント、パッケージ化ルール、信頼メカニズム、ユーザー体験を提供している。
その根底にある優先事項も異なる。一部のシステムはポータブルな指示を中心に据える。他のシステムは外部サービスへの接続、コマンドフック、埋め込みアプリケーションを重視する。
Claude Code TypeScript modsは、実行中のエージェント自体を変更することにより重点を置く。これは、モデルが別のツールを選択するのを待つのではなく、アクティビティをインターセプトする必要があるワークフローで価値を持つ。
本番環境の設定への直接変更を禁止するチームを考えてみよう。modは提案されたコマンドを検査し、実行前に専用の確認を要求できる。
別のmodはCIイベントを監視し、会話の横にステータスペインを維持できる。開発者はウィンドウを切り替えたり、最新の要約をモデルに尋ねたりする必要がない。
さらに別のmodは、コマンド出力がモデルのコンテキストに入る前に、その出力からシークレットをマスキングできる。診断コマンドがトークン、接続文字列、顧客識別子を露出させる場合には、特に重要となる。
これらのシナリオは、挙動、ポリシー、インターフェースの変更を組み合わせるものだ。そうでなければ、シェルフック、ラッパースクリプト、ダッシュボード、リポジトリ指示を組み合わせる必要がある。
したがって、最も強力な競争優位性は統合にあるのかもしれない。単一のプラグインで、イベントロジックとClaude CodeのカスタムUIを両方含む、一貫したワークフローを配布できる。
しかし、製品の柔軟性は可搬性を保証しない。Claude Codeのイベントとインターフェースコンポーネントを前提に書かれたmodは、Anthropicのランタイムに縛られ続ける。
これはツール開発者にとって戦略的なトレードオフを生む。深いネイティブ統合はより優れた体験を提供できる一方、可搬性のあるMCPサーバーやコマンドラインツールは、より多くのエージェントに届く。
より広い市場から予想される反応は、機能をそのまま模倣することではない。競合各社は、フックのカバレッジ、インタラクティブな画面、パッケージ配布、セキュリティ制御を改善することができる。
それでもAnthropicの発表は、基準線を引き上げる。開発者はいま、別のコーディングエージェントがツールを公開しているにもかかわらず、独自のレンダリングパイプライン、権限リクエスト、組み込み機能を公開していない理由を問えるようになった。
フルマシンアクセスが信頼を真の制約にする
最も重大でありながら、同時に最も受け入れがたい詳細は、modsがClaude Codeを実行するマシンからサンドボックスで隔離されていないことだ。
Anthropicによれば、modsはClaude Code本体と同じマシンアクセス権を持つ。同社は、信頼できる提供元のmodsだけをインストールするようユーザーに勧めている。
この警告は、チームがこの機能を評価する方法を変える。Claude Code modは、受動的なプロンプトや見た目だけのテーマではなく、実行可能なコードだ。
modはツール呼び出しや権限判断に関与できる。結果や質問の提示を含め、ユーザーに見える内容も変更できる。
この組み合わせはいくつかのリスクを生む。
悪意あるmodは、ローカルファイルの読み取り、リモートサービスへの接続、コマンドへの影響を試みる可能性がある。不注意なmodでも、ユーザーを意図的に攻撃せずに情報を漏えいさせるおそれがある。
欺瞞的なインターフェース変更は、関連する出力を隠したり、危険な操作を通常の処理に見せかけたりできる。壊れた権限ハンドラーは、本来レビューが必要だったアクションを承認してしまう可能性がある。
組み合わせたmodsは、さらに不確実性を加える。複数の関数が同じイベントを監視または変換する可能性があり、その読み込み順が最終的な挙動を決める。
このため、個別テストだけでは不十分だ。特に複数のプラグインがプロンプト、ツール、権限、インターフェース出力を変更する場合、チームはその組み合わせもテストしなければならない。
Anthropicは、プラグインガバナンスを通じて企業向けの制御を部分的に提供している。管理者は、別個のmodポリシーチャネルを作るのではなく、既存の制御を用いてプラグインマーケットプレイスを許可またはブロックできる。
管理された環境では、sec-defaultという組み込みmodも最初に読み込まれる。Anthropicによれば、これはユーザーがインストールしたmodsによる管理対象のプロンプト、設定、ツールポリシー、拒否ルールの上書きを防ぐ。
最初に読み込まれることは重要だ。最も外側の関数は下位レイヤーより先にイベントを受け取り、それらのレイヤーが戻った後にも再びイベントを受け取る。この位置により、管理ポリシーはインストール済み拡張機能を包み込める。
Anthropicは、管理者が独自のmodsを前置することを認めている。ただし同社は、提供される制限を維持するため、その際もsec-defaultを残すよう助言している。
これはよく考えられた設計だが、任意のサードパーティコードを信頼済みコードに変えるものではない。sec-defaultは選択された管理対象の制御を保護するものであり、あらゆる副作用をサンドボックス化するものではない。
調達およびセキュリティレビューでは、この違いを明確に保つべきだ。管理者の優先順位はポリシー回避の一類型を減らすが、サプライチェーンリスクをなくすわけではない。
プラグイン配布には、よく知られたアイデンティティの問題もある。洗練された掲載ページ、人気のリポジトリ、認知度の高い名前があっても、すべてのリリースに安全なコードが含まれるとは証明されない。
チームには、来歴、バージョン固定、ソースレビュー、再現可能なテストが必要だ。誰がmodを保守し、更新がどのように開発者のマシンへ届くのかを把握すべきである。
生成されたmodsも同じ厳格な確認を必要とする。Claude Codeは迅速に作成できるが、生成されたTypeScriptにはロジックエラー、不完全なチェック、意図しないアクセスが含まれる可能性がある。
特にセキュリティmodは、ユーザーがより大きな信頼を置く可能性があるため、慎重なレビューに値する。1つでも出力経路を見落とすシークレットマスキング層は、誤った安心感を生むおそれがある。
早期アクセスAPIは運用リスクも加える。破壊的変更によって、Claude Codeの更新後にポリシーmodが無効化されたり、イベントの挙動が変わったりする可能性がある。
低リスクな個人向けカスタマイズであれば、その不安定さは許容可能かもしれない。監査ログ、本番環境の保護策、コンプライアンス制御においては、チームは各ロールアウト前に検証を行う必要がある。
開発者は、インターフェースへの信頼と実行への信頼も分けて考えるべきだ。Claude CodeのカスタムUIを変更するmodは、基盤となるコマンドログが異なっていても、ユーザーが何が起きたと信じるかに影響を与えられる。
そのため、独立した記録が重要になる。本番システムは、mod自身の表示やストレージの外部に、信頼できるログを保持すべきだ。
重大な不確実性は、modsが有用な拡張機能を生み出せるかどうかではない。Anthropicはすでに具体例を示し、動作する組み込み実装を公開している。
不確実なのは、幅広いインストールが当たり前になる前に、周辺エコシステムが強固なレビュー慣行を育てられるかどうかだ。利便性はしばしば、慎重な検査より速く拡大する。
組み込み機能の置き換えはワークフローの所有者を変える
ファーストパーティ機能をmodsへ移すことは、Claude Codeを設定可能な製品から、部分的に置き換え可能な製品へと変える。
/diffの例は、過小評価しやすい。差分表示は狭いインターフェース機能のように聞こえるが、その実装はより大きな前例を確立する。
Anthropicは、拡張機能開発者と同じ仕組みを通じて機能を提供できる。ユーザーは組み込み版を無効化し、そのソースを学び、別の実装に置き換えられる。
この構成は、ファーストパーティ機能とサードパーティ機能の隔たりを縮める。開発者には抽象的なチュートリアルではなく、ランタイムの実際の挙動を反映した例を提供する。
また、チームは意見を反映した置き換えも実現できる。ある組織はサービス別にグループ化された差分を必要とするかもしれない。別の組織は生成ファイルを隠したり、リポジトリ固有のレビューチェックを追加したりするかもしれない。
カスタム実装では、選択した変更の横に承認ボタンを追加できる。変更されたファイルをテストステータスにリンクしたり、より厳格なポリシーに従うパスを強調表示したりもできる。
利点は単なるカスタマイズではない。ワークフローをコーディングセッション内に保てるため、レビュー中にツール間を移動する必要を減らせる。
Anthropicが表明した計画に従うなら、同じパターンは他のClaude Code機能にも拡張できる。より多くの組み込み機能が、より小さなエンジンを囲むオプションのレイヤーになるだろう。
これは独立系開発者に機会を生む。適切に保守されたmodは、Anthropicがその機能を優先するのを待たずに、専門的な利用者層に応えられる。
企業にとっては、内部ワークフローを組み込む別の場所にもなる。企業は、生産性機能とポリシー強制の両方を含むプラグインを配布できる。
ただし、置き換え可能性は断片化をもたらす。Claude Codeを使う2人の開発者が、異なるインターフェースを見て、異なる権限プロンプトを受け、異なるイベント変換を実行する可能性がある。
問題発生時、サポートチームはどのmodsが読み込まれていたかを知る必要がある。その文脈を欠くバグ報告は、再現が難しくなる可能性がある。
読み込み順は環境の一部になる。単独では正しく動作するmodでも、別の拡張機能に包まれると異なる出力を生む可能性がある。
これは、ブラウザー拡張機能、エディタープラグイン、ビルドシステムのミドルウェアの複雑さに似ている。拡張性は大きな力を生むが、同時に起こり得るランタイム状態の数も増やす。
したがって、Anthropicのテスト支援は重要だ。リポジトリには同じイベントインターフェースを対象にしたテストがあり、プラグインの挙動を検証するコマンドも含まれている。
型チェックは宣言の不一致を特定できる。ユニットテストは、modが想定されたイベントにどう応答するかを検証できる。ただし、信頼できないコードに広範な能力を与える場合、いずれも安全性を保証することはできない。
組織には多層的なアプローチが必要になる。静的レビュー、自動テスト、バージョン管理、段階的な展開、ランタイムログは、それぞれ異なる障害モードに対処する。
マーケットプレイスモデルにも、最終的にはより強力なシグナルが必要になるかもしれない。検証済みの公開者アイデンティティ、申告された能力、再現可能なビルド、可視化された更新履歴は、ユーザーのリスク評価に役立つ。
Anthropicは今回の発表を通じて、そのような制御が問題を解決するとは示していない。今回のローンチは、完全な保証システムではなく、管理上の構成要素を提供するものだ。
開発者にとって当面の判断は、望む挙動に本当にmodが必要かどうかだ。ニーズによっては、リポジトリの指示、skill、外部ツール、従来のフックのほうが引き続き適している。
ワークフローがイベントを変換し、ライブ状態を保持し、レンダリングを置き換え、インターフェース操作に直接応答する必要がある場合、modは適している。
単純なテキストガイダンスのために利用すれば、不必要な実行可能コードを加えることになる。より深い統合は、より深い制御に対する本当の必要性に対応すべきだ。
Claude Code Modsローンチ後に注目すべき点
次の段階を左右するのは、エコシステムの質、企業向け制御、そしてmodsがClaude Codeのリリースをまたいで信頼性を維持するという証拠だ。
最初のシグナルは、modsを採用する信頼できるプラグインの幅だ。小規模な視覚実験はレンダリングが機能することを証明するが、本番利用には、所有責任が明確な保守された統合が必要となる。
挙動を隠さずに開発ワークフローをつなぐmodsに注目したい。CIステータス、コードレビュー、テスト調整、本番環境の確認は有力な候補だ。
重要な証拠は、継続的な利用、透明なソース、一貫した保守だ。大規模なディレクトリだけでは、信頼や価値ではなく供給量を測るにすぎない。
2つ目のシグナルは、Anthropicによるセキュリティ境界の扱いだ。現在のアーキテクチャは管理環境向けにsec-defaultを提供しているが、modsは依然として一般的なサンドボックスなしで実行される。
将来のドキュメントやリリースでは、能力宣言、より明確な権限プロンプト、より強力な隔離、改善されたマーケットプレイス審査が追加される可能性がある。こうした変更は、組織での広範な導入を支持する根拠を強めるだろう。
深刻なセキュリティインシデントは、逆方向への圧力となる。それは、ローカルマシンへのアクセスを持つコードに必要な制御を、インストールの利便性が上回っていたことを示す。
3つ目のシグナルはAPIの安定性だ。Anthropicは現在、関数フックインターフェースを早期アクセスとして位置付けており、リリースで変更が導入される可能性があると警告している。
開発者は、イベント契約がどの程度の頻度で変わるか、Anthropicが移行をどう伝えるかを注視すべきだ。安定した型、互換性に関するガイダンス、予測可能な非推奨期間は、持続可能な統合を支える。
頻繁な破壊的変更があれば、modsは実験や任意の利便機能に限定される。十分な告知なしに変わるインターフェースを、チームは必須の制御の基盤にはしない。
競合の対応も補足的な文脈として重要だ。GoogleとOpenAIはすでに、拡張パッケージ、フック、skills、接続されたツール、インターフェース統合を提供している。
問題は、両社がコーディングエージェントの内部イベントとレンダリングフローをさらに公開するかどうかだ。そうなれば、プログラム可能なエージェントインターフェースはAnthropic固有の差別化要因ではなく、標準的なカテゴリーになる可能性がある。
Claude Code modsはすでに、製品の境界を変えている。開発者はいま、TypeScript関数によってプロンプト、ツール、権限、レンダリング、選択された組み込み機能を変更できる。
未解決なのは、その自由が、ユーザーが合理的に検査できない拡張機能のサプライチェーンを生み出すことなく拡大できるかどうかだ。
現時点では、すべてのmodをローカルソフトウェアとして扱い、ソースをレビューし、ほかのインストール済みプラグインとともにテストし、チームが使用するバージョンを固定すべきだ。そしてインストール前に、より難しい問いを投げかけるべきである。このワークフローはエージェントの実行経路へのアクセスを必要とするのか、それともより限定的な拡張機能で同じ結果を実現できるのか。
