https://knightli.com/ja/tags/hooks/ Recent content in Hooks on KnightLiブログ Hugo -- gohugo.io ja Fri, 01 May 2026 03:11:27 +0800 https://knightli.com/ja/2026/05/01/claude-code-hooks-mastery-guide/ Fri, 01 May 2026 03:11:27 +0800 https://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> https://knightli.com/ja/2026/04/23/claude-code-claude-md-rules-memory-hooks-guide/ Thu, 23 Apr 2026 10:43:40 +0800 https://knightli.com/ja/2026/04/23/claude-code-claude-md-rules-memory-hooks-guide/ <p><code>Claude Code</code> をしばらく使っていると、すぐに気づくことがあります。モデルそのものが重要なのは当然ですが、どんな環境を与えるか、どんな境界を置くか、どんなルールを持たせるかも同じくらい重要だということです。</p> <p>最初のうちは「今回の prompt をどう書くか」に意識が向きがちです。ですが、本当に <code>Claude Code</code> を使いこなすようになると、気になるのは別のことです。</p> <ul> <li>それは自分が誰かを分かっているか</li> <li>自分がどう働くかを分かっているか</li> <li>破ってはいけないルールを分かっているか</li> <li>先に確認すべきことを分かっているか</li> <li>そうした境界を長期的に覚えていられるか</li> </ul> <p><code>Claude Code</code> が成熟したツールになる理由は、単にモデルが強いからではありません。こうした働き方を仕組みとして定着させる一式があるからです。大きく分けると、その中核は次の4層です。</p> <ul> <li><code>CLAUDE.md</code></li> <li><code>Rules</code></li> <li><code>Memory</code></li> <li><code>Hooks</code></li> </ul> <p>この記事では、この4つをまとめて整理します。</p> <h2 id="なぜ単発のプロンプトより環境設定のほうが重要なのか">なぜ単発のプロンプトより環境設定のほうが重要なのか </h2><p><code>Claude Code</code> を、雇ったアシスタントだと考えてみてください。</p> <p>初日に「何か手伝って」と一言だけ伝えることはないはずです。普通は説明書を渡して、次のようなことを伝えます。</p> <ul> <li>自分はどんな立場なのか</li> <li>どんなコミュニケーションのトーンを好むのか</li> <li>どんな操作は必ず事前確認が必要か</li> <li>以前起きたどんなミスを今後は避けたいか</li> <li>重要な文書がどこにあるか</li> </ul> <p>だからこそ、長い目で見ると、環境設定は単発の prompt より重要になりやすいのです。</p> <p>prompt が解決するのは「今回は何をするか」です。環境設定が解決するのは「これから毎回どう働くか」です。</p> <h2 id="第1層claudemd">第1層：<code>CLAUDE.md</code> </h2><p>まず一番基本から始めます。<code>CLAUDE.md</code> は本質的にはただのテキストファイルです。</p> <p>そこには Claude への説明を書けます。たとえば：</p> <ul> <li>自分が誰か</li> <li>何に取り組んでいるか</li> <li>どんなコミュニケーションを好むか</li> <li>守るべきルール</li> <li>現在のプロジェクトの特殊事情</li> <li>重要な文書やディレクトリの場所</li> </ul> <p><code>Claude Code</code> が起動するたびに、この文書は自動的にコンテキストに入るので、モデルは必ず目を通します。</p> <p>私はこれを「共有された暗黙知のファイル」だと考えることが多いです。実際、それがあなたとモデルの長期協業における前提になるからです。</p> <h3 id="claudemd-に書くのに向いていること"><code>CLAUDE.md</code> に書くのに向いていること </h3><p><code>CLAUDE.md</code> に最も向いているのは、おおむね次のような内容です。</p> <ul> <li>身元や仕事上の背景</li> <li>話し方や出力の好み</li> <li>グローバルな行動ルール</li> <li>よく参照する重要なプロジェクト背景</li> <li>よくあるミスとその防ぎ方</li> </ul> <p>たとえば：</p> <ul> <li>自分のタイムゾーン</li> <li>モデルによるメールやメッセージの直接送信を許可するか</li> <li>どの操作が不可逆か</li> <li>文書やファイルの扱い方の癖</li> <li>セキュリティ方針や機密情報の境界</li> </ul> <h3 id="とても大事な原則できるだけ簡潔にする">とても大事な原則：できるだけ簡潔にする </h3><p><code>CLAUDE.md</code> には非常に大事な原則があります。それは、できるだけ簡潔に保つことです。</p> <p>理由は単純で、毎回コンテキストに強制的に入るからです。</p> <p>長くなりすぎると、大量のコンテキストを消費してしまい、本当に重要な情報が薄まります。モデルが読まないのではなく、注意が分散し、最も重要なルールを取りこぼしやすくなるのです。</p> <p>公式の目安としては、<code>400</code> 行を超えないほうがよいと言われることが多いです。</p> <p>私自身はもう少し保守的で、できるだけ <code>200</code> 行以内に収めるようにしています。</p> <h3 id="claudemd-のよくあるスコープ"><code>CLAUDE.md</code> のよくあるスコープ </h3><p><code>CLAUDE.md</code> には実際には複数の配置レベルがあり、そのレベルによって効く範囲が変わります。最もよく使うのは次の2つです。</p> <h4 id="1-user-level">1. User Level </h4><p>これはグローバルレベルです。</p> <p>ローカル環境に置かれ、そのマシン上で扱うすべてのプロジェクトに効きます。</p> <p>ここに向いているのは：</p> <ul> <li>自分の基本情報</li> <li>汎用的なコミュニケーションの好み</li> <li>プロジェクトをまたいで通用する作業習慣</li> <li>グローバルな安全ルール</li> </ul> <p>たとえば、あなたのタイムゾーンが一般的に想定されがちなものではなく、バンコク時間であるなら、それは <code>user level</code> に置くのが自然です。そうすれば、後で日時を扱うときのミスが減ります。</p> <h4 id="2-project-level">2. Project Level </h4><p>こちらはプロジェクトレベルです。</p> <p>特定のプロジェクトディレクトリの下に置かれ、そのプロジェクトにだけ効きます。</p> <p>ここに向いているのは：</p> <ul> <li>プロジェクト固有の背景</li> <li>そのプロジェクトでしか成立しないルール</li> <li>ディレクトリ構成の説明</li> <li>重要文書の入口</li> </ul> <p>たとえば、あるプロジェクトが財務を扱い、別のプロジェクトが人事を扱うなら、背景も制約も違うので、同じグローバル説明に混ぜるべきではありません。</p> <h3 id="どのレベルに置くかをどう判断するか">どのレベルに置くかをどう判断するか </h3><p>判断基準はシンプルです。</p> <p>別のプロジェクトに移っても成立するなら <code>user level</code> に置く。</p> <p>プロジェクトを変えた瞬間に成立しなくなるなら <code>project level</code> に置く。</p> <h3 id="最初の版をどう書き始めるか">最初の版をどう書き始めるか </h3><p>よくある始め方は2つあります。</p> <h4 id="1-init-を使う">1. <code>/init</code> を使う </h4><p>ターミナルで <code>/init</code> を実行して、Claude に現在のプロジェクトをスキャンさせ、基礎的な <code>CLAUDE.md</code> を自動生成してもらう方法です。</p> <h4 id="2-claude-に整理してもらう">2. Claude に整理してもらう </h4><p>他の人がどう <code>CLAUDE.md</code> を書いているかを Claude に調べてもらい、自分の状況に合わせて質問してもらった上で、最終的に自分向けの版に整理してもらうこともできます。</p> <p>多くの場合、ゼロから自分で書くよりずっと楽です。</p> <h3 id="とても実用的な習慣">とても実用的な習慣 </h3><p>長く協業していると、「これは今後も必ず覚えておくべきだ」「これは二度と繰り返してほしくない」と思うことが出てきます。そういう内容は、そのまま <code>CLAUDE.md</code> に書き足していくと便利です。</p> <p>ただし、その前に考えるべきことがあります。</p> <ul> <li>それはグローバルルールか</li> <li>それとも今のプロジェクト専用のルールか</li> </ul> <p>何でも1つのファイルに詰め込まないことが大切です。</p> <h2 id="第2層rules">第2層：<code>Rules</code> </h2><p>次が <code>Rules</code> です。</p> <p><code>CLAUDE.md</code> との最大の違いは、ファイル形式ではなくロードの仕方です。</p> <p><code>CLAUDE.md</code> は何をしていても常に読まれます。</p> <p>一方、<code>Rules</code> の強みは <strong>条件付きで読み込める</strong> ことです。</p> <p>つまり、特定のパス、ファイル、ツール、場面でだけ、そのルールを読ませることができます。</p> <h3 id="なぜ条件付きロードが重要なのか">なぜ条件付きロードが重要なのか </h3><p>コンテキスト空間は常に限られています。</p> <p>すべてのルールを無差別に毎回押し込むと、次の2つが起きます。</p> <ul> <li>モデルの負担が増える</li> <li>本当に重要なルールが埋もれる</li> </ul> <p>必要なときに必要な情報だけ読ませる。これが条件付きロードの価値です。</p> <h3 id="claudemd-から-rules-に移すべきタイミング"><code>CLAUDE.md</code> から <code>Rules</code> に移すべきタイミング </h3><p>典型的には2つあります。</p> <h4 id="1-claudemd-が長くなりすぎたとき">1. <code>CLAUDE.md</code> が長くなりすぎたとき </h4><p><code>CLAUDE.md</code> が <code>200</code> 行を超え始め、ルールが増えすぎて重要な内容が薄まってきたら、一部を切り出すタイミングです。</p> <h4 id="2-特定のルールが特定のパスにしか関係しないとき">2. 特定のルールが特定のパスにしか関係しないとき </h4><p>たとえば、あるルールが：</p> <ul> <li>Python スクリプトにだけ有効</li> <li>hooks ディレクトリにだけ有効</li> <li>特定のサブプロジェクトにだけ有効</li> </ul> <p>のように、適用対象が明確なら、それは <code>Rules</code> に移したほうが自然です。</p> <h3 id="rules-が最も向いている場面"><code>Rules</code> が最も向いている場面 </h3><p>典型的なのは「特定状況・特定パス・特定ファイル種別」です。</p> <p>たとえば：</p> <ul> <li>hook ファイルにだけ適用したい規約</li> <li>特定種類のスクリプトだけで守らせたいコーディング規則</li> <li>特定ディレクトリだけで有効な作業方針</li> </ul> <p>そうした内容を <code>CLAUDE.md</code> に入れ続けるのは、あまり効率的ではありません。</p> <h2 id="第3層memory">第3層：<code>Memory</code> </h2><p>3つ目の層が <code>Memory</code> です。</p> <p>これも <code>CLAUDE.md</code> や <code>Rules</code> と同じくコンテキストに入りますが、本質的な違いがあります。</p> <p><code>CLAUDE.md</code> はあなたが意図的に定義するものです。</p> <p><code>Memory</code> は、協業の中で Claude が自分用に残すメモに近いものです。</p> <h3 id="memory-に入るもの"><code>Memory</code> に入るもの </h3><p>Claude が「これは覚えておく価値がある」「しばらく保持したほうがよい」と判断した内容は <code>Memory</code> に入ります。</p> <p>たとえば：</p> <ul> <li>あなたが修正したやり方</li> <li>最近追加された好み</li> <li>現在のプロジェクトの一時的な状態</li> <li>今日終わらず、明日続きが必要なこと</li> <li>最近誰と協業しているか</li> <li>最近出てきた個人的な情報や文脈</li> </ul> <p>つまり、<code>Memory</code> は長期制度というより、動的な知識に近いのです。</p> <h3 id="最初の2層との違い">最初の2層との違い </h3><p>簡単に分けるなら：</p> <ul> <li><code>CLAUDE.md</code> / <code>Rules</code>：長期的、制度的、明示的なルール</li> <li><code>Memory</code>：一時的、動的、作業の中で新しく得た理解</li> </ul> <p>ここ数日しか有効でないことや、状態が継続的に変わることなら、長期ルールではなく <code>Memory</code> に向いています。</p> <h3 id="memory-は手動でも書ける"><code>Memory</code> は手動でも書ける </h3><p><code>Memory</code> は自動整理されることがありますが、こちらから明示的に指示して書かせることもできます。</p> <p>たとえば：</p> <ul> <li>明日やることを覚えておいて</li> <li>誰の状況を追う必要があるか覚えておいて</li> <li>今月のプロジェクトの重要な節目を覚えておいて</li> </ul> <p>といった内容です。</p> <p>また、<code>/memory</code> コマンドで現在の記憶を確認し、手動で編集・削除することもできます。</p> <p>ただ、私自身はあまり頻繁に手で管理しません。Claude 側でも古くなった記憶を定期的に整理できるからです。</p> <h2 id="第4層hooks">第4層：<code>Hooks</code> </h2><p>最後であり、最も重要かつ上級なのが <code>Hooks</code> です。</p> <p>ここまでの <code>CLAUDE.md</code>、<code>Rules</code>、<code>Memory</code> は、いずれも最終的には自然言語の指示です。</p> <p>ルールを書けば、モデルはたいてい従います。ですが、それでも「解釈してから実行する」ものです。</p> <p>自然言語にとどまる限り、いくつかの問題が残ります。</p> <ul> <li>ときどき見落とす</li> <li>ルールが増えると注意が分散する</li> <li>状況によっては、そのルールを重要でないと自己判断する</li> </ul> <p>これは書き方が悪いのではなく、自然言語ルールが <code>100%</code> 強制にはなりにくいという性質によるものです。</p> <h3 id="hooks-の本質"><code>Hooks</code> の本質 </h3><p><code>Hooks</code> は自然言語の説明ではありません。スクリプトです。</p> <p>イベントで発火する、プログラムレベルの強制ロジックです。</p> <p>あるイベントが起きれば、そのロジックは必ず実行されます。モデルの判断で飛ばされることはありません。</p> <p>これが <code>Hooks</code> の最大の価値です。</p> <p>「守るべき」から「必ず実行される」へ変えることです。</p> <h3 id="どんなときに-hooks-に上げるべきか">どんなときに <code>Hooks</code> に上げるべきか </h3><p>もし、あるルールをすでに <code>CLAUDE.md</code> や <code>Rules</code> に書いてあるのに、Claude がときどき守り損ねる。そして、その見落としのコストが高い。そういう場合は <code>Hooks</code> に上げるべきです。</p> <p>要するに：</p> <ul> <li>低リスクならルール</li> <li>高リスクなら <code>Hooks</code></li> </ul> <h3 id="典型的な-hooks-の場面">典型的な <code>Hooks</code> の場面 </h3><p>最も典型的なのは、絶対にミスしてほしくない操作です。たとえば：</p> <ul> <li>メール送信前の確認</li> <li>Slack、Outlook、Gmail 送信前の確認</li> <li>危険なファイル削除の遮断</li> <li>パスワードや API Key の外部送信のブロック</li> </ul> <p>こうした内容が自然言語ルールだけだと、いつか忙しいタイミングでミスが起きる可能性があります。</p> <p>でも <code>Hooks</code> にしておけば、イベント発生時に必ず止められます。</p> <p>これは本当の意味でのプログラム的な安全柵です。</p> <h3 id="hooks-のよくあるトリガー地点"><code>Hooks</code> のよくあるトリガー地点 </h3><p><code>Hooks</code> はさまざまな段階に設定できます。たとえば：</p> <ul> <li>会話開始時にリマインドを入れる</li> <li>ツール実行前に条件を確認する</li> <li>ツール実行後に結果を検証する</li> </ul> <p>専門用語を全部知っている必要はありません。</p> <p>多くの場合、「こういう要件がある」「これを hook にすべきか」と明確に説明できれば、Claude が一緒に設計してくれます。</p> <p>また、<code>/hook</code> コマンドで現在設定されている hooks を確認することもできます。</p> <h2 id="より実用的な導入順">より実用的な導入順 </h2><p>この4層をつなげて運用するなら、私なら次の順番を勧めます。</p> <h3 id="ステップ1まず-init-で基本版-claudemd-を作る">ステップ1：まず <code>/init</code> で基本版 <code>CLAUDE.md</code> を作る </h3><p>最初から完璧なルール文書を手書きしようとしないことです。</p> <p>まずは Claude にプロジェクトを見てもらい、たたき台を作ってもらって、そこから育てていくのが自然です。</p> <h3 id="ステップ2使いながら足していく">ステップ2：使いながら足していく </h3><p>協業の中で、</p> <ul> <li>今後も必ず覚えてほしい</li> <li>このミスは二度と起こしてほしくない</li> <li>この好みは毎回効いてほしい</li> </ul> <p>というものが見つかったら、<code>CLAUDE.md</code> に追加していきます。</p> <h3 id="ステップ3claudemd-が長くなったら-rules-に分ける">ステップ3：<code>CLAUDE.md</code> が長くなったら <code>Rules</code> に分ける </h3><p><code>CLAUDE.md</code> がどんどん長くなり、すべてのルールが安定して効かなくなってきたら分割します。</p> <ul> <li>何がグローバルルールか</li> <li>何が特定パス専用か</li> </ul> <p>後者を <code>Rules</code> に移し、条件付きロードにします。</p> <h3 id="ステップ4高リスクなものを-hooks-に上げる">ステップ4：高リスクなものを <code>Hooks</code> に上げる </h3><p>書いてあるのにまだ漏れる。そして漏れると危険。そういうものは自然言語のままにせず、<code>Hooks</code> に上げます。</p> <p>つまり「リマインド」を「強制実行」に変えるわけです。</p> <h3 id="ステップ5一時状態は-memory-に任せる">ステップ5：一時状態は <code>Memory</code> に任せる </h3><p>期限があるもの、変化するもの、長期制度ではないものは、何でも <code>CLAUDE.md</code> に入れないことです。</p> <p>たとえば：</p> <ul> <li>現在のプロジェクト進捗</li> <li>最近の協業相手</li> <li>最近増えた好み</li> <li>直近の計画や ToDo</li> </ul> <p>こうしたものは <code>Memory</code> に持たせたほうが、コンテキストもすっきりし、モデルの挙動も安定しやすくなります。</p> <h2 id="4層それぞれに何を入れるか">4層それぞれに何を入れるか </h2><p>手早く覚えるなら、次の整理で十分です。</p> <ul> <li><code>CLAUDE.md</code>：長期的な共通認識、グローバルな説明、プロジェクトの基礎背景</li> <li><code>Rules</code>：パスや場面ごとに読み込む専門ルール</li> <li><code>Memory</code>：動的な知識、一時状態、最近学んだこと</li> <li><code>Hooks</code>：高リスク操作をプログラム的に強制制御する層</li> </ul> <h2 id="まとめ">まとめ </h2><p><code>Claude Code</code> を「コードを書けるチャット画面」として使う人は多いですが、深く使うほど、それは長期協業のための知的な作業台に近いと分かってきます。</p> <p>重要なのは毎回の指示文だけではありません。安定していて、分かりやすく、積み重ねていける環境を与えられているかどうかです。</p> <p>この4層、</p> <ul> <li><code>CLAUDE.md</code></li> <li><code>Rules</code></li> <li><code>Memory</code></li> <li><code>Hooks</code></li> </ul> <p>をきちんと組めるようになると、あなたとモデルの協業品質はかなり大きく上がります。</p> <p>毎回ゼロから「自分が誰で、どう働いて、何をしてはいけないか」を説明し直す必要がなくなり、それらが環境の一部として定着するからです。</p> <p>それこそが、強いモデルを本当に成熟した道具として使うための重要な一歩です。</p>