Claude Modsは、Claude Codeの公式の拡張の仕組みだ。Claude Codeの中で動くTypeScript(またはJavaScript)の関数で、画面にペインを足したり、プロンプトやツール呼び出しを書き換えたりできる。2026年10月1日(米国時間)のv2.1.287で正式にリリースされた(公式ブログ、リリースノート)。
私は発表の数日後に、公開されているmodを3つ入れた。この記事では、modsでできること、入れた3つのmodの使い方、入れる前に中身を確かめる手順を順に書く。
先に結論を書く。
- modsはpluginに入れて配られる。入れて使うだけならTypeScriptは書かなくてよく、
/pluginのコマンド2行で入る。v2.1.287以降は既定で有効 - settings hook(settings.jsonに書く従来のhooks)・skill・MCPと違い、modsはClaude Codeの中で動く。そのため画面に描いたり、組み込みの機能を差し替えたりできる
- modはサンドボックスの外で、自分のユーザー権限で動く。入れる前に
claude plugin validateで、どのイベントを拾い、どのAPIを呼ぶかを見る - 私が入れたのはprompt-rail(プロンプトの目次)、md-prompt(入力欄のMarkdownに色を付ける)、qa-guide(Claudeの質問に解説を添える)の3つ。最初の1つなら、呼ぶAPIが3つだけのmd-promptが試しやすい
検証環境はmacOSとClaude Code 2.1.289(ターミナル、"tui": "fullscreen")で、2026年10月5日に確認した。
Claude Modsとは: Claude Codeの中で動き、画面と挙動を変えられる関数
Claude Codeは、ツールを呼ぶ、権限を確認する、画面の一部を描く、といった動作のたびにイベントを出す。modはこのイベントに差し込む関数で、イベントの前・後・代わりに処理を走らせられる。公式ブログは、1つの関数でできることとして次の例を挙げている。
- モデルに届く前にプロンプトを書き換える
- ツール呼び出しを止める、書き換える、やり直す
- 権限リクエストを承認・拒否する
- ツールの出力から秘密情報を消してからClaudeに読ませる
画面にも手を入れられる。会話の横にペインを開く、入力欄の上に帯を出す、ツールの結果やClaudeの質問ダイアログの表示を差し替える、ボタンや入力欄を置く、といったことができる(公式ドキュメント)。
settings hook・skill・MCPとの違い
公式ドキュメントは、modsをsettings hook・skill・MCPサーバーと並べて比べている。mods以外の3つを1行ずつ説明しておく。
- settings hook: settings.jsonに書く従来のhooks。ツール呼び出しの前後などに、シェルコマンドやHTTPリクエスト、プロンプトを走らせる
- skill:
SKILL.mdに書いた手順書。Claudeが読んで、その通りに作業する - MCPサーバー: 外部のプロセスやサービスで、Claudeに新しいツールを渡す
公式ドキュメントの比較表を要約した。
| mod | settings hook | skill | MCPサーバー | |
|---|---|---|---|---|
| 何を書くか | JavaScript / TypeScript | スクリプトとsettings.jsonの設定 | Markdown | 任意の言語のサーバー |
| 変えられるもの | ツール呼び出し、プロンプト、コマンド、ターン、画面の表示 | ツール呼び出しやプロンプトを通すかどうか、ツールの引数と結果、Claudeに足す文脈 | Claudeが知っていること・すること | Claudeが使えるツール |
| 画面に描けるか | 描ける | 描けない | 描けない | 描けない |
| 選ぶとき | ペインや帯、独自コマンドがほしい、イベントを書き換えたい | 手元のスクリプトでイベントを止める・許可する・記録する | 同じ指示を何度も貼っている | Claudeを外部のシステムにつなぐ |
settings hookもツールの引数を書き換えられるので、書き換えられるかどうかは分かれ目にならない。違いは、modがClaude Codeのプロセスの中で動くことにある。そのため、画面を描くことも、組み込みの機能を差し替えることもできる。実際に/diffはmodとして作り直されていて、/pluginから無効にしたり、自作のものに置き換えたりできる。

私が入れたmod 3つ
私が入れた3つのmodは、どれも作者のGitHubリポジトリがマーケットプレイスを兼ねていて、2行のコマンドで入る。入れ方は次の章に、入れる前の確認も含めて書いた。
prompt-rail: 長いセッションで「さっきの指示」に戻れる
1つのセッションで何十回もやり取りしていると、最初に出した条件をどう書いたかを確かめるために、スクロールで遡ることになる。prompt-railは、セッション内で自分が送ったプロンプトを、入力欄の上に並ぶ短い線(レール)として表示する。線にマウスを乗せるとそのプロンプトとターンの要約が出て、クリックすると会話のその位置まで飛ぶ。

主な使い方は次の通り。
/prompt-rail horizontal(入力欄の上、既定)と/prompt-rail vertical(会話の横のペイン)で表示を切り替える。/prompt-rail offで隠す/prompt-rail next/prev/first/lastで前後のプロンプトへ飛ぶ。/prompt-rail 12は12番目へ、/prompt-rail find <語>はその語を含む最新のプロンプトへ飛ぶ~/.claude/keybindings.jsonにキーを割り当てると、Claudeの作業中でも飛べる
{
"bindings": [
{
"context": "Chat",
"bindings": {
"ctrl+k": "command:prompt-rail-prev",
"meta+j": "command:prompt-rail-next"
}
}
]
}
READMEは、マウスで操作するなら"tui": "fullscreen"を推奨している。Claude DesktopのCodeタブでは、レールとプレビューは出るが、クリックしてもその位置へは飛べない。Desktopがmodに会話のスクロールを許していないためだ(READMEに記載)。
md-prompt: 入力欄に書いたコードブロックや表に色が付く
プロンプトにコードや表を書いて指示するとき、入力欄は素のテキストなので、どこからどこまでがコードかが見分けにくい。md-promptは、入力欄のMarkdownに打った端から色を付ける。```で始めたコードブロックは、閉じる前から背景つきのカードになり、言語に応じてシンタックスハイライトされる。見出し、太字、リスト、チェックボックス、引用、表、リンクにも色が付く。

md-promptは色を付けるだけで、文字は変えない。送信されるのは打った文字そのままで、``` や **などの記号も消えずに薄く表示される。
/md-prompt on/off/toggleで切り替える。/configで「Markdown」を検索しても切り替えられる- 複数行の下書きは、
\のあとにEnterで改行する(ターミナルが対応していればShift+Enterでもよい)
4行以上を貼り付けた部分には色が付かない。Claude Codeが貼り付けを[Pasted text #N +M lines]に畳み、md-promptが受け取る編集イベントが発生しないためだ(READMEに記載)。1〜3行の貼り付けには色が付く。
qa-guide: Claudeの質問に、文脈と選択肢ごとの影響を添えてくれる
ClaudeがAskUserQuestionで選択肢を出してきたとき、セッションが長いと、何の話だったかを思い出すために会話を遡ることがある。qa-guideは、質問ダイアログの横にペインを開き、次の内容を表示する。
- AIによる解説: いまClaudeが従っている指示の要約、なぜ今この質問をしているか、選択肢ごとに何が起きるか、おすすめ1行
- 自分が直近に入力した指示
- 質問の直前にClaudeが書いた説明の末尾

ターミナルの幅が144列以上あると、ペインは質問のたびに自動で開く。狭いときは/qa-guideで開ける。ペインにフォーカスを移す(Ctrl+X → Tab、またはクリック)と、p / nで過去の質問、lで最新の質問、hで履歴一覧を表示できる。aを押すと、AI解説のON / OFFが切り替わる。表示言語は/configのlanguageでauto / en / jaから選ぶ。
AI解説は、質問1件ごとにモデル呼び出しを1回増やす。セッションのプロンプトキャッシュを使えるときは安く済むが、無料ではない。気になるなら、ペインでaを押すと次の質問からAI解説が止まる(すでに始まった呼び出しは止まらない)。qa-guide自身は独自の通信をせず、質問や回答をディスクに書かない。ただしAI解説の追加リクエストでは、会話や質問文がClaude Code経由でモデルに渡る(READMEに記載)。
安全に入れる手順: 入れる前にclaude plugin validateで中身を見る
modはClaude Codeの中で、自分のユーザー権限で動く。公式ドキュメントは、modが読み込まれたあとにできることとして、次を挙げている。
- 自分のアカウントで読める範囲のファイルの読み書き、プログラムの起動、ネットワーク通信
- 環境変数や設定ファイルの読み取り(そこに置いたAPIキーも含む)
- 送ったプロンプトとClaudeのツール呼び出しをすべて見る、書き換える
- ツール呼び出しを、確認ダイアログが出る前に承認する
- 自分のプランやAPIキーでモデルを呼ぶ
Claude Codeのサンドボックスを有効にしていても、隔離されるのはClaudeが実行するBashコマンドで、modが起動したプロセスはサンドボックスの外で動く。そこで、入れる前にclaude plugin validateで、そのmodがどのイベントを拾い、どのAPIを呼ぶかを確かめる。validateはコードを実行せずに読むだけなので、入れる前に使える。

手順

prompt-railを例に書く。
-
マーケットプレイスを追加する。この時点ではまだmodは入っておらず、リポジトリが
~/.claude/plugins/marketplaces/oikon48/に取得される/plugin marketplace add oikon48/prompt-rail -
シェルでmodのディレクトリをvalidateする。mod本体の場所は、リポジトリの
.claude-plugin/marketplace.jsonのsourceに書かれている(今回の3つはどれもplugins/<mod 名>)claude plugin validate ~/.claude/plugins/marketplaces/oikon48/plugins/prompt-rail -
出力の
hooks:とcalls:の行を読み、納得できたら入れる/plugin install prompt-rail@oikon48 -
インストール後の案内に従って有効にする。
Run /reload-plugins to activate.と出たら/reload-pluginsを実行するか、新しいセッションを始める(prompt-railのREADMEは新しいセッションを案内している)。シェルから入れた場合は、開いているセッションで/reload-pluginsを実行する。/pluginを開くと、タブの下に1 mod active · prompt-railのような行が出る
ほかの2つは次のコマンドで入る。
/plugin marketplace add nogu66/md-prompt
/plugin install md-prompt@nogu66
/plugin marketplace add aieo-product/claude_qamods
/plugin install qa-guide@claude-qamods
出力の読み方
hooks:の行はそのmodが受け取るイベント、calls:の行はコードが呼ぶmods APIの一覧だ。modがファイルやプロセス、ネットワークに触るには必ずmods APIを通るので、calls:を見ればできることの範囲がわかる。公式ドキュメント(組織向けの管理ページ)が見ておくべきものとして挙げている名前のうち、主なものを表にした。
| 出力に出る名前 | 意味 |
|---|---|
$.fs.read / $.fs.write |
自分が読み書きできるファイルなら、どこでも読み書きできる |
$.process.run / $.process.spawn |
自分の権限でプログラムを起動する |
$.http.fetch |
ネットワークに通信する |
$.env.get / $.settings.read |
環境変数や設定を読む(APIキーが入っていることがある) |
$.model.complete |
自分のプランやAPIキーでモデルを呼ぶ |
$.prompt.submit |
自分が打ったものとしてプロンプトを送る |
hooksのtool.call / prompt.submit |
すべてのツール呼び出し・プロンプトを見て、書き換えられる |
hooksのtool.check |
確認ダイアログが出る前に、ツール呼び出しを承認・拒否できる |
3つのmodの実際の出力
私の環境で3つをvalidateした結果と、それを見てどう判断したかを書く。
md-promptは、calls:が3つしかない。コマンドの登録、自分の設定の書き込み、ログの出力だけで、ファイル・プロセス・ネットワークには触らない。
❯ ./register.tsx hooks: session.start, command.run{command=md-prompt}, prompt.edit, prompt.fill
❯ ./register.tsx calls: $.command.register, $.config.set, $.ui.log
prompt-railには$.process.spawnと$.fs.readが出る(以下はcalls:行の抜粋)。
❯ ./index.tsx calls: $.clock.after, $.command.register, $.config.set (via writeMode),
$.fs.read (via readTranscript), $.fs.stat (via readTranscript),
$.process.spawn (via streamRows), ..., $.ui.scroll (via jumpTo), $.ui.toast
プロセスを起動するので、ソースのstreamRowsを読んだ。起動しているのはtail -c +<位置> <会話ログのパス>で、セッションの会話ログ(transcript)の続きを読んでプロンプトの一覧を作っているだけだった。
qa-guideには$.model.forkと$.model.completeが出る。前の章で書いた、質問ごとのモデル呼び出しがこれにあたる。$.env.getで読むのはLANGとLC_ALLだけで、表示言語の自動判定に使っている(以下も抜粋)。
❯ ./register.tsx calls: $.clock.now, $.command.register, $.config.list (via resolveLang),
$.env.get (via resolveLang), $.model.complete, $.model.fork, $.session.messages, ...
❯ ./register.tsx env reads: LANG, LC_ALL
validateでわからないこと
validateの出力は、コードが呼ぶAPIの一覧で、安全の保証ではない。prompt-railの$.process.spawnのように、何を起動するかはソースを読まないとわからない。更新すると中身が変わるので、更新のたびに見直す。/plugin marketplace update <マーケットプレイス名>で取得元を新しくしたら、もう一度validateして前の出力と比べる。問題がなければ、/plugin update <mod 名>@<マーケットプレイス名>で入れている版を更新する。公式以外のマーケットプレイスは自動更新が既定でオフなので、この順番で更新できる。自動更新をオンにすると、validateを挟まずに新しい版が入る。
自分の権限設定(settings.jsonのpermissions)で守れる範囲にも限りがある。denyルールがかかるのはClaudeのツール呼び出しで、mod自身の$.fs.readや$.process.spawnには効かない。Read(.env)をdenyしていても、modは$.fs.readでそのファイルを読める。また、ツール呼び出しを承認するmodは、askルールで確認が出るはずの呼び出しや、自分のPreToolUse hookが止めた呼び出しも承認できる。auto modeでは、modが承認した呼び出しは分類器のチェックを通らずに実行される。managed settingsのない端末で、Team / Enterpriseプランでサインインしていない場合(個人のプランなど)は、denyルールで拒否される呼び出しもmodが承認できる(権限のドキュメントに記載)。
チームで使う場合
組織でClaude Codeを配っている場合は、管理者がmanaged settingsでmodを制限できる(公式ドキュメント)。
- Team / Enterpriseプランでサインインしている端末や、managed settingsがある端末では、既定で組み込みのガード
sec-defaultが最初に読み込まれる。このガードがあると、ユーザーが入れたmodはdenyルールで拒否された呼び出しを承認できない。ただし管理者がallowModsToOverrideDenyRulesを有効にすると、この制限は外れる - managed settingsでこのガードのオプション
allowManagedModsOnlyを有効にすると、組織のものとして配られたmodと組み込みのmod以外は読み込まれなくなる(どのmodが組織のものと数えられるかは公式ドキュメントに条件がある) strictKnownMarketplacesで、入れられるマーケットプレイスを絞れるdisableSideloadFlagsで、--plugin-dirや--plugin-urlでの読み込みを禁止できる
会社のマシンに入れるなら、先に社内のルールと、これらの設定が入っているかを確認したほうがいい。
外し方と、表示されないとき
modを止める方法は、範囲によって3つある。
- 1つだけ止める:
/pluginのInstalledタブで、そのpluginを無効化またはアンインストールする - 1セッションだけ、入れたmodを全部止める:
claude --safe-modeで起動する(mod以外のカスタマイズも止まる) - 常に、入れたmodを全部止める:
~/.claude/settings.jsonに"disableAllHooks": trueを書く。settings hookと独自のステータスラインも止まる。組織が管理しているものは動き続ける
どちらの方法でも、/diffなどの組み込みのmodは止まらない。組み込みのmodは、無効にできるものだけ/pluginのInstalledタブで個別に止められる。
入れたのに何も表示されないときは、次を確認する。
- バージョン: modsはv2.1.287以降で動く。
claude --versionで確かめる - ワークスペースの信頼: Claude Codeは、信頼していないディレクトリではmodのコードを読み込まない。作ったばかりのディレクトリで起動したときに起きやすい(md-promptのREADMEに記載)
- ターミナルの幅: ユーザーが開いていないペインは、ターミナルが144列以上のときだけ自動で開く。一度開いたあとは110列から開く
- 使っている場所: 描画されるのはターミナルとClaude DesktopのCodeタブ(WSLのセッションを除く)だけ。VS Code拡張のチャット欄と
claude -pでは、modのフックは動くが画面には何も出ない。クラウドセッションでは、pluginがセッションに引き継がれた場合だけフックが動き、描画はされない
なお、早期アクセス期に書かれたREADMEには、~/.claude/settings.jsonにCLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1を書く手順が残っている。v2.1.287以降はこの環境変数を無視するので、書かなくてよい。書いてあれば消してよい。
自分で作るなら
Claude Codeのセッションで、ほしいmodの内容を説明すると、Claudeが組み込みのplugin-authoringスキルを使ってコードを書く。最初のファイルを保存したときにホットリロードを有効にするか聞かれ、有効にするとそのセッションで動く。自分でコードを書く場合は、公式の入門ガイドと、Anthropicのサンプル集がわかりやすい。
公開されているmodを自分用に直すのも手だ。私はyash-gadodia/claude-modsのreceipt(MITライセンス)をもとに、turn-receiptというmodを作って使っている。ターンごとに編集とコマンド実行の件数をフッターに出し、編集したのに何も実行していないターンには⚠ no runを付ける。何も実行せずに「修正しました」と完了を宣言したときは、次のスピナーにunverified claim pendingを出す。元のmodから、何を「実行」と数えるかの判定を変え、日本語の完了宣言も拾えるようにした。
まとめ
modsは、Claude Codeの画面と挙動を自分の使い方に合わせるための仕組みだ。入れて使うだけなら、/pluginのコマンド2行で済む。ただ、中身は自分の権限で動くコードなので、入れる前にvalidateの出力を見る。プロセスの起動やネットワーク、モデル呼び出しが出ていたら、ソースの該当箇所を読む。
まだ入れていないなら、呼ぶAPIが少ないmd-promptから試すのがいい。
/plugin marketplace add nogu66/md-promptを実行する- シェルで
claude plugin validate ~/.claude/plugins/marketplaces/nogu66/plugins/md-promptを実行し、出力を見る /plugin install md-prompt@nogu66で入れ、新しいセッションの入力欄にコードブロックを書いてみる- 合わなければ
/pluginのInstalledタブで無効にする
settings hookやCLAUDE.mdの設定はハーネスエンジニアリングの記事に、普段使っている道具はツールチェインの記事にまとめている。