https://www.knightli.com/ja/tags/%E8%87%AA%E5%8B%95%E5%8C%96/ Recent content in 自動化 on KnightLiブログ Hugo -- gohugo.io ja Fri, 01 May 2026 03:11:27 +0800 https://www.knightli.com/ja/2026/05/01/claude-code-hooks-mastery-guide/ Fri, 01 May 2026 03:11:27 +0800 https://www.knightli.com/ja/2026/05/01/claude-code-hooks-mastery-guide/ <p><code>claude-code-hooks-mastery</code> は、<code>Claude Code Hooks</code> を学ぶためのプロジェクトです。</p> <p>単にいくつかのスクリプトを並べただけではありません。Claude Code の hooks ライフサイクル、設定方法、スクリプトの書き方、よくある自動化シナリオをまとめて説明しています。Claude Code をより制御しやすく、よりエンジニアリング向けの助手として使いたい人にとって、読む価値のある資料です。</p> <p>Claude Code は標準でもコードを読み、ファイルを編集し、コマンドを実行できます。しかし、特定のタイミングで権限を確認したり、危険な操作を止めたり、プロジェクト規約を注入したり、テストを実行したり、チームルールを思い出させたりしたい場合、チャット指示だけでは安定しません。Hooks の価値は、「毎回 AI に思い出させたいルール」を実行可能なワークフローに変えることです。</p> <h2 id="hooks-が解決する問題">Hooks が解決する問題 </h2><p>Claude Code をしばらく使うと、よく次のような課題が出てきます。</p> <ul> <li>新しい会話のたびに同じプロジェクトルールを説明する必要がある</li> <li>実行してはいけないコマンドを実行しないか不安</li> <li>ファイル変更の前後で自動チェックしたい</li> <li>コミット前にフォーマット、テスト、セキュリティスキャンを走らせたい</li> <li>チーム規約を口頭の注意ではなく固定フローにしたい</li> <li>ツール呼び出しの前後でコンテキストを取得し、ログやブロックに使いたい</li> <li>複雑なタスクでサブエージェントや専用スクリプトを起動したい</li> </ul> <p>Hooks は、こうした「決まったタイミングでの自動動作」のためにあります。</p> <p>Claude Code ワークフロー内のイベントフックとして考えるとわかりやすいです。セッション開始、ユーザーのプロンプト送信、モデルがツールを呼び出す直前、ツール呼び出し完了、エージェント終了直前などのタイミングで、設定したスクリプトを実行できます。</p> <h2 id="13-個の-hooks-ライフサイクル">13 個の Hooks ライフサイクル </h2><p>このプロジェクト README の重要な点の一つは、Claude Code の 13 個の hook イベントを体系的に整理していることです。</p> <p>これらのイベントは、セッション開始からツール呼び出し、ユーザー入力からエージェント終了まで、複数の段階をカバーします。用途別には、おおまかに次のように分けられます。</p> <ul> <li>セッション起動関連：環境初期化、プロジェクトコンテキスト注入</li> <li>ユーザー入力関連：プロンプト確認、ルール補足、監査</li> <li>ツール呼び出し前関連：権限判断、コマンドブロック、安全チェック</li> <li>ツール呼び出し後関連：結果記録、フォーマット起動、検証実行</li> <li>タスク終了関連：要約、クリーンアップ、通知、状態保存</li> </ul> <p>このライフサイクル設計により、すべてのルールを長いプロンプトに詰め込む必要がなくなります。</p> <p>たとえば、権限制御はツール呼び出し前に行うべきです。フォーマットチェックはファイル変更後の方が自然です。プロジェクト規約の注入は、セッション開始時やユーザー入力後が向いています。正しい hook ポイントにルールを置く方が、すべてを system prompt に詰めるより信頼しやすくなります。</p> <h2 id="設定ファイルの場所">設定ファイルの場所 </h2><p>Claude Code の hooks は通常、設定ファイルで構成します。</p> <p>よく使われる場所は次のとおりです。</p> <ul> <li>ユーザー単位の設定：<code>~/.claude/settings.json</code></li> <li>プロジェクト単位の設定：<code>.claude/settings.json</code></li> </ul> <p>ユーザー単位の設定は、一般的な安全ルール、コマンドブロック、ログパスなど、個人の好みに向いています。</p> <p>プロジェクト単位の設定は、そのリポジトリに関するルールに向いています。たとえば、必ず実行するテスト、編集禁止のディレクトリ、生成ファイルの扱い、コミット前のチェックなどです。</p> <p>チームで Claude Code を使うなら、プロジェクト単位の設定をリポジトリに置くのがおすすめです。そうすれば、各自が記憶で AI に注意するのではなく、全員が同じ AI 協作制約を持ってプロジェクトを開けます。</p> <h2 id="単一ファイルスクリプトが重要な理由">単一ファイルスクリプトが重要な理由 </h2><p>このプロジェクトでは <code>UV</code> の単一ファイルスクリプトが強調されています。</p> <p>利点はデプロイが簡単なことです。1 つの Python ファイルで依存関係を宣言して実行できるため、1 つの hook のために複雑な環境を維持する必要がありません。多くの hook は小さな処理を 1 つ行うだけなので、この形式は適しています。</p> <ul> <li>コマンドの実行可否を確認する</li> <li>ファイルパスが安全か判断する</li> <li>プロジェクト規約を読み、Claude に返す</li> <li>出力に機密情報が含まれていないか調べる</li> <li>変更後にフォーマットやテストを実行する</li> <li>イベントをログに書く</li> </ul> <p>Hook スクリプトは小さいほど保守しやすく、新しい複雑なシステムになりにくくなります。</p> <h2 id="どんな自動化ができるか">どんな自動化ができるか </h2><p><code>claude-code-hooks-mastery</code> は多くの方向性を示しています。実務でよく使うのは次のようなものです。</p> <h3 id="1-権限と安全制御">1. 権限と安全制御 </h3><p>これは hooks の最も直接的な用途です。</p> <p>Claude Code がコマンドを実行する前に、その内容をチェックできます。削除、リセット、クリア、上書きなどの高リスク操作が含まれている場合、実行を止めるか、人間の確認を求められます。</p> <p>同様のルールはファイルパスにも使えます。</p> <ul> <li>本番設定を変更しない</li> <li>秘密鍵ファイルに書き込まない</li> <li>マイグレーションスクリプトを削除しない</li> <li>指定ディレクトリに触れない</li> <li>未承認のネットワークコマンドを実行しない</li> </ul> <p>この保護をツール呼び出し前に置く方が、「危険な操作をしないで」とプロンプトに書くより確実です。</p> <h3 id="2-コンテキスト注入">2. コンテキスト注入 </h3><p>多くのプロジェクトには固定された背景があります。</p> <ul> <li>技術スタック</li> <li>コーディング規約</li> <li>テストコマンド</li> <li>ブランチ戦略</li> <li>ディレクトリ構造</li> <li>禁止事項</li> <li>生成ファイルの扱い</li> </ul> <p>これらを毎回手動で Claude Code に伝えるのは面倒で、漏れやすいです。Hooks を使えば、セッション開始時やユーザーのプロンプト送信後に必要なコンテキストを自動注入できます。</p> <p>これは Claude Code にプロジェクト単位の作業マニュアルを渡すようなものです。README や開発ドキュメントを置き換えるものではありませんが、AI がタスクを始める前に正しい状態へ入りやすくなります。</p> <h3 id="3-変更後の検証">3. 変更後の検証 </h3><p>Claude Code がファイルを変更した後、hook で自動チェックを起動できます。</p> <p>よくある処理は次のとおりです。</p> <ul> <li>フォーマットを実行する</li> <li>lint を実行する</li> <li>単体テストを実行する</li> <li>型エラーを確認する</li> <li>生成ファイルをスキャンする</li> <li>Markdown や JSON の形式を検証する</li> </ul> <p>これは低レベルなミスを減らすのに役立ちます。AI が複数ファイルを変更した場合、変更後に軽量な検証を走らせることで、問題を早めに見つけられます。</p> <p>ただし、hook に重い処理をデフォルトで入れるのは向きません。ファイル変更のたびに完全なテストスイートを走らせると、体験が遅くなります。より実用的なのは、ファイル種別、ディレクトリ、タスクのリスクに応じてチェック範囲を選ぶことです。</p> <h3 id="4-チームルールの検証">4. チームルールの検証 </h3><p>チームに明確な約束があるなら、その一部を hooks に入れられます。</p> <p>たとえば：</p> <ul> <li>コミットメッセージ形式</li> <li>コードスタイルルール</li> <li>特定の生成ファイルを直接変更しない</li> <li>ドキュメントを同時に更新する</li> <li>API 変更ではテストも更新する</li> <li>特定ディレクトリは指定ツールでのみ生成する</li> </ul> <p>これにより Claude Code は、制約のない外部アシスタントではなく、チームワークフローの一部に近づきます。</p> <p>もちろん、hooks は CI の代わりではありません。ローカルでの早めの注意や前置ブロックに向いています。最終検証は CI、review、テストシステムに任せるべきです。</p> <h3 id="5-サブエージェントと専用タスク">5. サブエージェントと専用タスク </h3><p>README ではサブエージェント関連の内容にも触れています。</p> <p>この使い方は、複雑なタスクをより専門的なフローに分ける場合に向いています。たとえばメイン会話が要求を理解し、hook や設定が専用のチェック、監査、要約、ドキュメント整理タスクを起動します。</p> <p>個人ユーザーにとって、最初にやる価値があるのは複雑なエージェント編成ではありません。まずは反復的で明確かつ低リスクな処理を hooks に任せることです。ルールが安定してから、より複雑な自動化を検討すれば十分です。</p> <h2 id="statusline-と出力スタイル">Statusline と出力スタイル </h2><p>プロジェクトは statusline と出力スタイルも扱っています。</p> <p>一見すると体験面の細部ですが、Claude Code を長期的に使う場合には重要です。Statusline は現在のコンテキスト、タスク状態、環境情報、ヒントを表示できます。出力スタイルは Claude Code の回答を自分の作業習慣に合わせやすくします。</p> <p>毎日同じターミナルで AI と協作するなら、こうした細部は効率に影響します。良い状態表示は誤操作を減らし、現在の会話が正しいプロジェクト、正しいブランチ、正しい環境にいるかを素早く判断できます。</p> <h2 id="hooks-を重くしすぎない">hooks を重くしすぎない </h2><p>Hooks は強力ですが、何でも詰め込む場所ではありません。</p> <p>良いルールは次のとおりです。</p> <ul> <li>高頻度の処理は速くする</li> <li>安全ブロックは明確にする</li> <li>出力は短くする</li> <li>失敗理由は読みやすくする</li> <li>スクリプトはできるだけ単一責務にする</li> <li>重いチェックは明示コマンドや CI に任せる</li> </ul> <p>毎回 10 秒以上かかる hook は、すぐに無効化したくなります。ブロックルールが曖昧な hook も、Claude Code とユーザーの両方にとって次に何をすべきか分かりにくくなります。</p> <p>Hooks は、境界が明確な処理に最も向いています。許可または拒否、コンテキスト追加、ログ記録、軽量チェック、次の手順提示などです。</p> <h2 id="向いているユーザー">向いているユーザー </h2><p>たまに Claude Code に小さなコード変更を頼むだけなら、hooks を深く学ぶ必要はまだないかもしれません。</p> <p>しかし、次のような場合はこのプロジェクトを調べる価値があります。</p> <ul> <li>Claude Code を頻繁に使う</li> <li>AI に実際のプロジェクトコードをよく変更させる</li> <li>AI が危険なコマンドを実行しないか不安</li> <li>チーム規約を AI ワークフローに自動注入したい</li> <li>変更後に自動チェックを走らせたい</li> <li>繰り返しの注意を設定に変えたい</li> <li>より安定した AI コーディングフローを作っている</li> </ul> <p>特に複数人で作業するプロジェクトでは、hooks の意味が大きくなります。チーム経験の一部をスクリプトとして残せるため、各メンバーがその場で AI に注意する必要が減ります。</p> <h2 id="利用時の注意">利用時の注意 </h2><p>第一に、安全系 hook から始めることです。</p> <p>複雑な自動化よりも、コマンドブロック、パス保護、機密ファイルチェックの方が実装しやすく、すぐにリスクを下げられます。</p> <p>第二に、プロジェクト単位のルールは慎重にコミットすることです。</p> <p><code>.claude/settings.json</code> は、そのリポジトリを使う全員に影響します。コミット前に、通常開発を過度に制限しないこと、自分のマシンにしかないパスに依存しないことを確認した方がよいです。</p> <p>第三に、hook の出力は簡潔にすることです。</p> <p>Claude Code はその出力を消費します。長すぎるとコンテキストを汚し、曖昧すぎると次の行動を導けません。必要な判断と次の提案だけを返すのがよいです。</p> <p>第四に、デバッグしやすく保つことです。</p> <p>Hooks が増えると、問題は設定、スクリプト、権限、パス、依存関係、Claude Code 本体のどこからでも起こり得ます。明確なログを残すと、後の調査がずっと楽になります。</p> <h2 id="参考">参考 </h2><ul> <li><a class="link" href="https://github.com/disler/claude-code-hooks-mastery" target="_blank" rel="noopener" >disler/claude-code-hooks-mastery</a></li> </ul> <h2 id="最後に">最後に </h2><p><code>Claude Code Hooks</code> の価値は、「AI に毎回覚えていてほしいルール」を、実際に実行されるフローへ変えることです。</p> <p>すでに Claude Code を実プロジェクトで使い始めているなら、hooks は「会話できるコーディング助手」から「制約を持つエンジニアリング協作者」へ進むための重要な一歩です。</p>