![]()
Claude Code hooksとは?設定と自動化の実例を全部見せる
Claude Codeを使っていると、「コードを直したあと、毎回この整形コマンドを手で打つのが地味に面倒」と感じる瞬間があります。そこを埋めるのがhooksです。
この記事のポイント
- hooksは、Claude Codeの決まったタイミングで自作のコマンドを自動で走らせる仕組みです
settings.jsonに数行書くだけで、整形・テスト・通知・危険コマンドの停止まで自動化できます- AIに指示を出さなくても必ず実行される「確実性」が最大の価値です
- まずはファイル編集後の自動整形から始めるのが一番わかりやすい入り口です
Claude Code hooksとは、Claude Codeが動く途中の特定のタイミングで、あなたが決めたコマンドを自動で実行する機能です。たとえば「ファイルを書き換えた直後に必ずコード整形を走らせる」といった動きを、AIへのお願いではなく確実なルールとして固定できます。
ここが普通のお願いとの決定的な違い。AIに「整形しておいてね」と頼むと、やる時とやらない時が出ます。hooksは設定した以上、100%走ります。
Claude Code hooksとは何が便利なの?

一言でいうと、AIの気まぐれをなくして、開発の後始末を自動化できるのが便利なところです。
Claude Codeは、リポジトリ全体を読んでコードを直したりGitを操作したりする、いわゆるエージェント型のAIコーディング支援ツールです。ターミナルやIDEから使えて、Claude Opusなどのモデルが背後で動いています。ここまでは多くの人が知っています。
見落とされがちなのが、その動作の「隙間」に自分の処理を差し込めること。
hooksが埋めるのは、たとえばこんな隙間です。
- ファイルを直したあとの自動整形(コードの見た目をそろえる作業)
- 変更後のテスト自動実行
- 作業が終わったときのデスクトップ通知やSlackへの連絡
rm -rfのような危険なコマンドが走る前の停止
AIに毎回お願いする必要がありません。設定した瞬間から、裏で勝手に面倒を見てくれます。
この「勝手に」が効くのは、人間がうっかり忘れる作業ほど価値が出るからです。整形やテストは、忘れても動くけれど後で痛い目を見る類の作業。だからこそ自動化と相性が良い。
では、その設定はどこに書くのか。
hooksの設定はどこに書く?

hooksはsettings.jsonというファイルに書きます。置き場所によって適用範囲が変わります。
設定ファイルは3か所あります。それぞれの役割を表にまとめました。
| ファイルの場所 | 適用範囲 | 向いている用途 |
|---|---|---|
~/.claude/settings.json | 自分の全プロジェクト | 個人の通知設定など |
.claude/settings.json | そのプロジェクト全員 | チーム共通の整形ルール |
.claude/settings.local.json | 自分+そのプロジェクト | 個人的な検証用の設定 |
つまり、チーム全員に効かせたいルールはプロジェクト直下の.claude/settings.json、自分だけの好みは.local.jsonという使い分けになります。
基本の書き方はこんな形です。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npx prettier --write $CLAUDE_FILE_PATHS"
}
]
}
]
}
}
この例は「ファイルを編集(Edit)または新規作成(Write)したあとに、prettierという整形ツールを走らせる」という意味です。matcherが「どのツールに反応するか」、commandが「何を実行するか」を決めています。
JSONの書き間違いは動かない原因の第一位です。カンマの位置とカッコの対応だけは、保存前に一度目で追ってください。
書く場所がわかったら、次は「いつ走るか」の種類を押さえます。
hooksが走るタイミングにはどんな種類がある?

hooksには複数の起動タイミングがあり、目的に合わせて選びます。
主要なタイミングを表にしました。この種類選びが、hooks設計のいちばん大事なところです。
| タイミング名 | 走る瞬間 | よく使う用途 |
|---|---|---|
| PreToolUse | ツールが動く直前 | 危険コマンドの停止、事前チェック |
| PostToolUse | ツールが動いた直後 | 自動整形、テスト実行 |
| UserPromptSubmit | 指示を送った直後 | 入力ログの記録 |
| Notification | Claudeが通知を出すとき | デスクトップ通知への転送 |
| Stop | 応答が一区切りしたとき | 作業完了の合図、まとめ処理 |
| SessionStart | セッション開始時 | 環境情報の読み込み |
つまり、「何かの前に止めたい」ならPreToolUse、「何かの後に処理したい」ならPostToolUse、という発想で選べば大きく外しません。
このうち、PreToolUseだけは特別です。実行を止められる力を持っているからです。
ここまでの整理: hooksは「settings.jsonに書く」「matcherで対象ツールを選ぶ」「タイミングを選んで処理を差し込む」の3点セットです。あとは実例を見れば具体像がつかめます。
実例1: ファイル編集後にコードを自動整形する

いちばん手応えを感じやすいのが、この自動整形です。
Claudeがコードを直すたびに、整形ツールが裏で走ります。あなたは何もしません。それでいてコードの見た目は常にそろいます。
先ほどのprettierの例がそのまま使えます。JavaScriptやTypeScriptならprettier、Pythonならblackやruffに置き換えるだけ。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "ruff format $CLAUDE_FILE_PATHS" }
]
}
]
}
}
$CLAUDE_FILE_PATHSには、Claudeが直したファイルのパスが自動で入ります。全ファイルを整形せず、触った分だけを整えるので速い。
地味ですが、これだけでコードレビューの指摘が一段減ります。整形の乱れを人が指摘する時間ほど、もったいないものはありません。
整形の次に効くのが、変更の正しさを守るテスト自動化です。
実例2: 変更後にテストを自動で走らせる
コードを直したら、壊れていないかをその場で確かめたい。これもhooksに任せられます。
PostToolUseで、対象のテストコマンドを走らせるだけです。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "npm test -- --silent" }
]
}
]
}
}
テストが落ちれば、その結果がClaudeに戻ります。Claudeは失敗を受け取って、自分で直そうとします。人間が「テスト落ちてるよ」と伝える手間が消えるわけです。
ただし、テストが重いプロジェクトだと毎回の実行は待ち時間になります。対策は2つ。
- 変更に関係する一部テストだけを走らせる
- テスト全実行はStopタイミングにまとめて1回だけにする
全部を毎回回すのは、正直やりすぎになりがちです。速度と安心のバランスで決めてください。
テストで品質を守ったら、今度は自分の安全を守る番です。
実例3: 危険なコマンドを実行前に止める
これはhooksの中でも、いちばん「入れておいてよかった」となる使い方です。
PreToolUseは、コマンドが走る前に割り込んで、実行そのものを止められます。rm -rfのような取り返しのつかないコマンドを、水際で防ぐ盾になります。
判定用のスクリプトを1本用意して、こう設定します。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "python3 .claude/guard.py" }
]
}
]
}
}
guard.pyの中で、これから走るコマンドの中身を受け取り、危険なパターンなら停止する終了コードを返します。停止させたいときは、判定スクリプトが決められた終了コード(2)を返す、という約束になっています。
Claudeは自律的にGit操作もコマンド実行もします。だからこそ、人間側に最後のブレーキが要ります。このブレーキを1つ挟むだけで、深夜の事故がぐっと減ります。
内部のリスク管理をどう自動化するかは、社内のAIツール棚卸しの考え方も参考になります。ツールに何を許すかを決める発想は、hooks設計とそのまま地続きです。
安全の次は、作業の終わりを見逃さない工夫です。
実例4: 作業完了を通知で受け取る
Claudeに長い作業を任せると、終わったかどうかを確認しに戻る往復が発生します。この往復こそ、通知hooksでなくせます。
macOSならこれだけで、作業が一区切りしたときに音や通知が出せます。
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "osascript -e 'display notification \"作業が完了しました\" with title \"Claude Code\"'"
}
]
}
]
}
}
別の作業をしながら待てるようになります。画面をちらちら見る必要がありません。
SlackやDiscordに飛ばしたいなら、commandをWebhookに投げるcurlに差し替えるだけ。仕組みは同じで、送り先が変わるだけです。
通知が届く安心感は、使ってみると想像以上に効きます。放置できる、という状態が生産性を静かに底上げします。
ここまで4つ見てきました。次は、なぜわざわざhooksを使うのかを整理します。
なぜAIへのお願いではなくhooksを使うの?
答えは「確実性」の一点です。
AIは賢いですが、毎回まったく同じ動きをするとは限りません。「整形して」「テストして」とプロンプト(AIへの指示文)に書いても、状況次第で飛ばすことがあります。
hooksは違います。設定した以上、条件に合えば必ず走ります。この差を表にしました。
| 観点 | プロンプトでお願い | hooksで固定 |
|---|---|---|
| 実行の確実さ | やる時とやらない時がある | 条件に合えば必ず走る |
| 設定の手間 | 毎回書く必要がある | 一度書けば効き続ける |
| 向いている処理 | その場限りの判断 | 毎回必ずやりたい後始末 |
つまり、「絶対に毎回やってほしいこと」はhooks、「その場の判断で変わること」はプロンプト、という住み分けになります。
Claude Codeを開発パイプライン全体の自動化基盤として設計するなら、この確実性が土台になります。MCPやSkillsと組み合わせると、コード修正だけでなく、その前後の処理まで一本の流れにできます。
自動化の思想そのものに興味があるなら、画像生成の裏側を自動化したComfyUIとStable Diffusionの比較の記事も、処理を部品としてつなぐ発想の参考になります。
自動化の全体像が見えたら、他のAIコーディングツールとの立ち位置も気になるところです。
他のAIコーディングツールとどう違う?
hooksという「決まったタイミングで確実に処理を差し込む」仕組みは、Claude Codeの設計思想をよく表しています。
AIコーディングツールは今、Claude CodeとCodexが二強と言われる状況です。設計はClaude、細かい修正ループはCodex、という使い分けをする人も増えています。
ツールの比較検討をするなら、Claude CodeとCursorの比較や、Claude CodeとCodexの比較を見ると、それぞれの得意分野がつかめます。Cursorに乗り換えを考えているならClaude Codeの代替候補も一覧できます。
ツール単体の使い方は、Claude Codeのツールページにまとめています。まずここで全体像を押さえてから、hooksに進むのが遠回りに見えて近道です。
比較の切り口をもっと知りたい人向けに、下のセクションに関連リンクをまとめました。その前に、費用の話を片付けておきます。
料金はかかる?
hooks機能そのものに、追加のお金はかかりません。
hooksが実行するのは、あなたのパソコンの上で動くコマンドです。整形もテストも通知も、ローカルで完結します。だからhooksを使うこと自体でAPI(他のソフトからAIを呼び出す窓口)の課金が増えることはありません。
かかるのは、あくまでClaude Code本体の利用料です。個人ならProプランとターミナル利用が最小コストの入り口、チーム開発ならIDE拡張とチーム向けプランが導入しやすいルートになります(2026年4月時点)。
なお、2026年6月15日からClaude Codeの料金体系が一部改定されました。ターミナルで対話しながら使う部分は従来どおりサブスク枠のままで、変わるのはAgent SDKやclaude -p、GitHub Actionsなどの自動化部分です。hooksが呼び出すのはローカルのコマンドなので、この改定の影響は基本的に受けません。
正確な最新料金は公式の料金ページで確認してください。ここでは金額を断定しません。
費用の心配がないなら、あとは始め方だけです。
初めてのhooks、どこから手をつける?
最初の1本は、迷わずファイル編集後の自動整形にしてください。
理由は3つ。効果が目に見える、失敗しても壊れない、設定が短い。この記事の実例1をそのままコピーして、整形ツールだけ自分の言語に合わせれば動きます。
おすすめの進め方はこの順番です。
- まず自動整形を1本入れて、確実に走る感覚をつかむ
- 慣れたらテスト自動実行を足す
- 最後に危険コマンドの停止と通知を入れる
いきなり全部を盛り込むと、動かないときの原因切り分けが難しくなります。1本ずつ、動作を確かめながら増やすのが結局いちばん速い。
設定を変えたあとは、必ずわざと小さな編集をClaudeにさせて、hookが走るか確認してください。「書いたつもり」で動いていない、が最初のつまずきどころです。
関連する比較・代替を見る
- Claude Code vs Cursor — エージェント型とエディタ統合型、開発スタイルの違いで選ぶ
- Claude Code vs Codex — 設計向きと修正ループ向き、二強の使い分け
- Claude Code vs GitHub Copilot — 補完中心か自律作業か
- Cursor vs GitHub Copilot — エディタ系2強の比較
- Claude Codeの代替ツール一覧 — 乗り換え候補をまとめて確認
よくある質問(FAQ)
Q. hooksを設定するとClaude Codeが遅くなりますか?
走らせるコマンド次第です。整形のような軽い処理はほぼ気になりません。ただし全テストを毎回走らせると待ち時間が出ます。重い処理はStopタイミングにまとめるか、対象を一部に絞ると快適です。
Q. プログラミング初心者でも設定できますか?
JSONを1か所書き換えられれば大丈夫です。この記事の実例をコピーして、コマンド部分だけ自分の環境に合わせれば動きます。最初は自動整形の1本から始めるのが安全です。
Q. hooksとMCPやSkillsは何が違いますか?
hooksは「決まったタイミングで確実にコマンドを走らせる」仕組みです。MCPは外部ツールとClaudeをつなぐ窓口、Skillsは繰り返す作業の手順を登録する機能です。役割が別なので、組み合わせると自動化の幅が広がります。
Q. チーム全員に同じhooksを効かせられますか?
できます。プロジェクト直下の.claude/settings.jsonに書いてGitで共有すれば、そのリポジトリを開いた全員に同じhooksが適用されます。個人だけの設定は.claude/settings.local.jsonに分けます。
Q. hooksで危険なコマンドを完全にブロックできますか?
PreToolUseで判定スクリプトを挟めば、危険なパターンを止められます。ただし、あらゆる危険を自動で見抜けるわけではありません。あくまで人間の最終確認を補助するブレーキとして考えるのが現実的です。
Q. 設定したのにhookが走りません。なぜですか?
多いのはJSONの書き間違いと、matcherの対象ツール名のズレです。カンマとカッコの対応を見直し、反応させたいツール名(EditやBashなど)が正しいか確認してください。保存後にわざと小さな編集をさせて動作を確かめると原因が切り分けやすくなります。
AI PICKS編集部の判定
Claude Code hooksは、Claude Codeを日常的に使う人なら入れて損はない機能です。とくにファイル編集後の自動整形は、設定5分で毎日効いてくる破格のコスパ。ここだけでも入れる価値があります。
強みは、AIの気まぐれを消して「必ず走る」確実性を手に入れられること。整形やテスト、危険コマンドの停止といった、忘れると後で痛い作業ほど自動化が効きます。人間の注意力に頼らない仕組みは、チーム開発になるほど重宝します。
一方で、最初のハードルはJSONを書くことへの心理的な抵抗と、動かないときの原因切り分けです。ここは1本ずつ増やせば十分越えられます。
結論、Claude Codeユーザーなら自動整形の1本から今日始めるのが一択です。慣れたらテストと安全ブロックを足していく。この順番で、開発の後始末が静かに自動化されていきます。
次に読むなら、AIツールの導入判断をどう進めるかをまとめた社内AIツールの棚卸しガイドがおすすめです。hooksで足元を固めたあと、どのツールに何を任せるかを考える土台になります。
