Claude Code HooksとカスタムコマンドでCLIを設定する手順｜個人開発の定型作業を自動化

結論：Hooksとカスタムコマンドは「毎回思い出す作業」をなくす仕組みだ

個人開発では、コミット前のチェックやデプロイ前の確認など、同じ作業を毎回自分で思い出して指示する場面が多い。

Claude Codeには、これを仕組み化する機能が2つある。

Hooks: ツール実行の前後に自動でコマンドを走らせる
カスタムスラッシュコマンド: よく使うプロンプトをテンプレート化して呼び出す

どちらも settings.json や .claude/commands/ に定義を置くだけで動く。本記事では実際の設定ファイルの書き方と、個人開発での活用例を示す。

Hooksとカスタムコマンドの役割分担

両者は似ているが目的が異なる。まず違いを整理する。

項目	Hooks	カスタムスラッシュコマンド
発動方法	自動（イベント駆動）	手動（`/コマンド名`で呼ぶ）
定義場所	`settings.json`	`.claude/commands/*.md`
主な用途	保存後のlint・型チェック・通知	定型プロンプトのテンプレ化
対象イベント	PreToolUse / PostToolUse / Stop 等	なし（呼び出し時のみ）

Hooksは「気づかないうちに品質チェックが走る」仕組み、カスタムコマンドは「毎回書くプロンプトを1コマンドに圧縮する」仕組みと考えるとよい。

手順1：Hooksを設定する

設定は .claude/settings.json（プロジェクト単位）または ~/.claude/settings.json（グローバル）に書く。

以下は、ファイル編集後に自動でTypeScriptの型チェックを走らせる例だ。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx tsc --noEmit"
          }
        ]
      }
    ]
  }
}

ポイントは3つ。

matcher で対象ツールを絞る（絞らないと全ツール実行のたびに走り重くなる）
コマンドの終了コードで成否が判定される。失敗時はClaude側に結果が返る
PreToolUse を使えば、危険なコマンド（rm -rf など）の実行前にブロックすることもできる

設定変更はエディタで直接書いてもよいが、/update-config のようなスキルやコマンドで生成すると構文ミスを防ぎやすい。

手順2：カスタムスラッシュコマンドを作る

.claude/commands/ 配下にMarkdownファイルを置くと、ファイル名がそのままコマンド名になる。

例：.claude/commands/release-check.md

---
description: リリース前チェックリストを実行する
---

以下を順番に確認してください。

1. `npm run build` が通るか
2. `npm test` が全て通るか
3. package.json のバージョンが更新されているか
4. CHANGELOG.md に今回の変更が追記されているか

問題があれば具体的な修正案を提示してください。

呼び出しは /release-check の一言で済む。引数を受け取りたい場合は $ARGUMENTS をテンプレート内に埋め込める。

個人開発での実践例

実際に効果が出やすいのは次のような定型作業だ。

コミット前チェック: PreToolUse で git commit の前に lint を強制する
記事・レポートの定型生成: 「このフォーマットで書いて」という指示をコマンド化する
デプロイ前の確認: 環境変数・ビルド成果物・料金プランの上限を毎回同じ手順でチェックする

こうした定型作業は Claude Codeのサブエージェント活用術と組み合わせると、チェックそのものを別セッションに任せて並列化することもできる。Claude Codeの基本操作にまだ慣れていない場合は、先にClaude Codeの使い方を確認しておくとよい。

注意点・デメリット

良い面ばかりではない。導入前に把握しておきたい点を挙げる。

Hooksは書き方を誤ると逆に遅くなる。matcher を広げすぎると、全ツール呼び出しのたびに重い処理が走ってしまう
失敗時の挙動を確認しておく。コマンドが異常終了したときにClaude側の動作がどう変わるか、小さい変更で試してから本番運用に入るべきだ
属人化しやすい。カスタムコマンドは個人の作業フローに最適化されがちなので、チーム開発に持ち込む場合は命名や説明文を丁寧に書く必要がある
仕様は変わりやすい。Hooksのイベント種類やカスタムコマンドの記法は今後変更される可能性があるため、導入時は公式の最新情報を確認してほしい

まとめ

Hooksは「自動で走る品質ゲート」、カスタムコマンドは「手動で呼ぶ定型テンプレート」だ。

個人開発では、コミット前チェックやリリース前確認といった「忘れがちだが毎回必要な作業」から仕組み化すると効果を実感しやすい。まずは1つの定型作業を選び、小さく試してから範囲を広げていくのがおすすめだ。