フックとプラグイン

《 Claude完全ガイド 目次へ 》

10秒でいうと

フックはClaudeの判断に関係なく必ず走るシェルコマンドです。
スキルが「読んでもらう指示」なのに対し、フックは動く保証があるのが違いです。

No.38で書いた話に戻ります。CLAUDE.md は文脈であって強制ではありません。

「必ずこうしてほしい」があるなら、書いて頼むのではなく、仕組みとして走らせる。それがフックです。

いつフックを使うか

判断の分かれ目は1つです。

たぶん従う、では許されないものをフックにする。編集後の整形、コミット前のlint、機密ファイルへの書き込みの禁止。

公式ドキュメントもはっきり書いています。Claudeが決めるかどうかに関係なく実行されるので、確実性が要るならフックへ。

どのタイミングで走らせられるか

公式に挙げられているイベントです。

PreToolUse が止められるのが重要です。危険な操作を、実行される前に拒否できます。No.21で書いた「そもそもできないようにする」が、ここで実現します。

実例：出力を絞る

公式が挙げている例が分かりやすいので引きます。

テストの出力を、失敗した部分だけに絞るフック。Claudeが1万行のログを読む代わりに、フックが ERROR の行だけ返す。文脈が数万トークンから数百トークンに減ります。

これはNo.24の「詰め込まない」の実装でもあり、No.44のコスト削減でもあります。フックはコストの道具でもある、という視点は持っておくとよいと思います。

プラグイン

スキル・エージェント・フック・MCPサーバーをまとめて配る仕組みです。

公式の勧め方が現実的です。まず .claude/ で作って回し、共有したくなったらプラグインに変換する。先にプラグインにする必要はありません。

中身はディレクトリ構成で決まります。skills/ にスキル、agents/ にエージェント定義、hooks/hooks.json にフック、.mcp.json にMCPサーバー。マニフェストは .claude-plugin/plugin.json に置きます。

よくある間違いも明記されていて、skills/ や hooks/ を .claude-plugin/ の中に入れてしまうこと。plugin.json だけが .claude-plugin/ に入ります。

配布はマーケットプレイス経由です。Anthropicが公式のものとコミュニティのものを持っていて、社内向けにはprivate リポジトリでマーケットプレイスを立てられます。

安全の話

フックはシェルコマンドを実行します。当然ですが、危険もそこにあります。

• 他人が書いたフックを、読まずに有効にしない
• プラグインの配布元を確かめる（No.32で書いたのと同じ）
• 設定ファイルに入ったフックは、そのフォルダを信頼した時点で走る

第3章のNo.21の話が、ここでも当てはまります。接続を1つ増やすたびに、外から来るものの入口が1つ増えます。

やってみよう：必ず走らせたい処理を見つける（3分）

プロンプト
“`
私のプロジェクトで、Claudeの判断に任せず必ず走らせたい処理を
挙げてください。CLAUDE.md に書いても守られない可能性がある種類の
ものだけに絞ってください。

それぞれについて、どのフックのイベントで実装すべきかも教えてください。
実装はまだしないでください。
“`

期待される結果：候補とイベント名が返る。編集後の整形が PostToolUse、危険な操作の禁止が PreToolUse に割り当たる。

うまくいかないとき：候補が出ないなら、まだフックは要りません。同じことを2回言った時点で戻ってきてください。

つまずきポイント

最初からフックを作ろうとする。順番は CLAUDE.md → スキル → フックです。守られなかった実績ができてから作ってください。

フックを増やしすぎる。毎回走るので、遅くなります。本当に必要なものだけ。

他人のフックを読まずに使う。シェルコマンドが走ります。中身を読んでください。

まとめ

• フックは判断に関係なく必ず走る。確実性が要るならここ
• PreToolUse は操作を止められる。「そもそもできないようにする」が実現できる
• 出力を絞るフックは、文脈もコストも減らせる
• プラグインはまとめて配る仕組み。まず .claude/ で作ってから変換する

次に読む

Git・プルリクエスト・コードレビュー

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。