⏱ 読了目安: 約7分
- 事実と背景：AnthropicがClaude Code v2.1.287で、TypeScriptで動作を拡張できる「Mods」を正式リリース。
- 技術的変革：従来のMCPやhooksと異なり、Claude Codeのプロセス内で動作し、UI描画や内部イベントの書き換えが可能。
- 現場への影響：開発者は2行のコマンドで導入できるが、サンドボックス外で動くため、導入前の静的検証が必須となる。
UIと挙動をハックする「Mods」の衝撃
開発現場でClaude Codeを使い倒しているエンジニアなら、誰もが一度は「長いセッションのスクロール地獄」や「ターミナル入力欄の視認性の悪さ」に頭を抱えたことがあるはずだ。1つのセッションで何十回もやり取りを重ね、デバッグとコード生成を繰り返していると、最初に出した前提条件や指示を確かめるために画面を何十行も遡る羽目になる。この不毛なスクロール作業は、開発のコンテキストスイッチを発生させ、我々の集中力を削ぐ「見えないデッドロック」となっていた。2026年10月1日に正式リリースされたClaude Code v2.1.287の「Claude Mods」は、まさにこうした開発者の生々しいストレスを、内部から直接ハックして解消するための強力な武器である。
Modsの最大の特徴は、Claude Codeのプロセス内部でTypeScript（またはJavaScript）として動作し、画面描画やイベント処理を直接書き換えられる点にある。例えば、私自身が導入して劇的に体験が変わったのが「prompt-rail」だ。これはセッション内のプロンプト履歴を入力欄の上にインジケーター（レール）として可視化し、クリックやキーバインドだけで過去のコンテキストへ瞬時にジャンプできる。また、「md-prompt」を導入すれば、これまで素のテキストだった入力欄が、打ったその場でシンタックスハイライトされる美しいMarkdownエディタへと変貌する。さらに「qa-guide」は、Claudeがユーザーに質問を投げかけてきた際、その質問の背景や選択肢ごとの影響をAIが解説するペインを横に展開してくれる。これらは単なる外部ツールの連携ではなく、Claude Codeの「肉体」そのものを拡張するアプローチなのだと私は考える。
MCPやHooksとの決定的な構造差
我々エンジニアが新しい拡張仕様を学ぶ際、既存の「settings hook」「skill」「MCP（Model Context Protocol）」と何が違うのかを整理することは極めて重要だ。結論から言えば、Mods以外の3つはすべて「Claude Codeの外部」で動くか、あるいは「Claudeに対する指示（文脈）」を与えるに過ぎない。これに対し、ModsはClaude Codeのランタイムそのものに深く統合されている。このアーキテクチャの違いが、画面描画（TUIの制御）や、組み込み機能（例えば /diff コマンドなど）の完全な差し替えを可能にしているのだ。実際、Claude Codeの標準機能である /diff 自体が、今や1つのModとして再実装されているという事実が、この拡張性の高さを物語っている。
ここで、それぞれの拡張方式が持つ特性とユースケースを比較表で整理しておこう。どの技術を選択すべきか迷った際のロードマップとして活用してほしい。
| 拡張方式 | 記述言語・形式 | 制御可能な対象 | 画面描画（TUI） | 最適なユースケース |
|---|---|---|---|---|
| Mod | TypeScript / JavaScript | ツール呼び出し、プロンプト、コマンド、画面表示 | 可能（ペインや帯の追加） | UIのカスタマイズ、独自コマンド、イベントの完全な書き換え |
| settings hook | シェルスクリプト / JSON | ツール呼び出し前後のフック、プロンプト挿入 | 不可能 | 手元のスクリプトによるイベントのロギングや簡易な制御 |
| skill | Markdown (SKILL.md) | Claudeの行動手順、知識の追加 | 不可能 | 定型的な開発フローや指示のテンプレート化 |
| MCPサーバー | 任意の言語（Go, Python等） | Claudeが利用可能な外部ツール・リソース | 不可能 | データベースや外部API、独自システムとの連携 |
この表からも明らかなように、画面に新しいペインを配置したり、キーバインドを割り当ててインタラクティブに操作したりしたい場合、選択肢はMods一択となる。逆に、外部のデータベースからスキーマを取得してClaudeに渡したいといった用途であれば、従来通りMCPサーバーを構築するのが正解だ。技術の適材適所を見極める眼力こそ、シニアエンジニアに求められる素養である。
サンドボックス外で動くセキュリティ検証
しかし、この強力なパワーには相応の「リスク」が伴う。ModsはClaude Codeのサンドボックス（隔離環境）の外側、すなわち「あなた自身のユーザー権限」で直接実行される。これは、悪意あるModを不用意にインストールしてしまった場合、ローカルマシンの環境変数（各種APIキーを含む）の窃取、ファイルの不正な読み書き、さらにはバックグラウンドでの不正なネットワーク通信や任意コードの実行が容易に行われてしまうことを意味する。深夜の障害対応で疲弊しているときに、出所不明のModを「便利そうだから」とワンライナーでインストールする行為は、自らセキュリティホールを穿つようなものだ。Claude Codeのサンドボックス設定を有効にしていても、Modの実行プロセスはその制限を受けないという仕様は、我々が絶対に忘れてはならない技術的懸念である。
そこで、Modを導入する際は、必ずインストール前に claude plugin validate コマンドを実行し、そのModが要求する権限（hooksとcalls）を静的に検証するプロセスを開発フローに組み込むべきだ。例えば、マーケットプレイスを追加した段階（まだインストールはされていない状態）で、以下の手順を踏む。
/plugin marketplace add oikon48/prompt-rail
claude plugin validate ~/.claude/plugins/marketplaces/oikon48/plugins/prompt-railこの検証コマンドを実行すると、そのModがどのイベントをフックし、どのAPIを呼び出すかが一覧で出力される。例えば、ファイル読み書きを行う $.fs.read や、外部プロセスを起動する $.process.spawn、ネットワーク通信を行う $.http.fetch などが含まれている場合、なぜその権限が必要なのかをソースコードレベルで確認するまでは、絶対にインストールを進めてはならない。実際に「prompt-rail」を検証した際、$.process.spawn が検出されたが、ソースを追うと tail コマンドで会話ログの末尾をストリーミング読込しているだけだと判明し、安全だと判断できた。このように、ブラックボックスのままツールを信用せず、コードの挙動を自分の目で裏付ける姿勢が不可欠である。
AI駆動開発の未来と「信頼」の問い
Claude Modsの登場は、AIコーディングアシスタントが「指示を受け取るだけのツール」から「開発環境そのものを自律的に最適化するOS」へと進化しつつあることを示している。実際、Claudeに「こういうModが欲しい」と自然言語で伝えるだけで、組み込みの plugin-authoring スキルを使ってModのコードを自動生成し、その場でホットリロードして適用することすら可能だ。開発者が自分の好みに合わせて、その場でエディタやアシスタントの挙動をリライトしていく世界は、一見するとエンジニアの桃源郷のように思える。
しかし、ここで我々は業界全体に対する痛烈な問いを投げかけざるを得ない。「我々は、AIが生成し、AIが自律的に拡張していく開発環境の『正当性』を、どこまで検証し、信頼し続けられるのだろうか？」
Modの自動更新をオンにしていれば、ある日突然、裏で悪意あるコードが挿入されるサプライチェーン攻撃に晒されるかもしれない。また、AIが生成したModが、予期せぬ無限ループやリソースの枯渇を引き起こし、開発マシンのパフォーマンスを密かに低下させている可能性もある。我々が明日から取るべき具体的な処方箋は極めてシンプルだ。第一に、公式以外のマーケットプレイスの自動更新は絶対にオフにすること。第二に、Modのアップデート時は必ず validate を再実行し、差分をGit等で確認すること。そして第三に、AIにModを作らせる際も、生成されたTypeScriptコードのロジックを必ず人間がレビューすることだ。AIに主導権を完全に明け渡すのではなく、アーキテクチャの決定権とセキュリティの監査権は常に我々人間のエンジニアが握り続ける。この境界線を維持することこそが、これからのAI共生時代におけるプロフェッショナルの条件である。
コメント