Claude CodeのHooksは、所定の出来事に応じて処理を動かす仕組みです。
今回は原稿を編集した後、題名・本文・出典欄があるかを自動で確かめます。
配布する読み取り専用の検査を新規フォルダへ登録し、正常な原稿と出典を欠く原稿で試します。
必要なのはNode.js、利用準備済みのClaude Code、macOSかLinuxのターミナルです。
この記事で学ぶこと
- 形式検査の対象と限界を決めます。
- /hooksと実際のツール記録で発動を確かめます。
- 検出後は人が結果を読み、修正と再検査を行います。
形式検査で分かることを決める
自動化するのは、draft.mdに題名、本文、出典の三つがあるかという形式検査です。
見出しだけで本文が空なら不備と判定します。
一方、出典が実在するか、数字を裏付けるか、文章を公開してよいかは判定しません。
機械が確認する範囲と、人が読む範囲を分けることで、合格表示への過信を防ぎます。
配布するcheck-draft.mjsはファイルを読み取るだけです。
原稿の修正、削除、外部への通信は行いません。
検査対象は新規プロジェクト直下のdraft.md一つに絞ります。
サイズの大きな原稿や別の場所へのリンクは検査不能にするため、最初は配布した小さな見本をそのまま使ってください。
期待する表示は、形式がそろうOK、不足があるINVALID、検査できないERRORの三つです。
ERRORは合格ではなく、設定やファイルの状態を調べる合図です。
対象外のファイルはSKIPとなります。
原稿の不備と検査自体の故障を区別できると、どちらを修正すればよいか判断できます。
この練習の成功は、コードを置くことだけではありません。
正常な見本が通り、出典を欠く見本を検出し、修正後に再び通る一巡を確認します。
時間のかかる総合検査を編集ごとに実行する前に、この小さな検査で発動時点と結果の読み方を理解しましょう。
例の店舗情報はすべて架空です。
配布ファイルで手動検査を試す
本番や共有フォルダの外に、新しい0ku-hooks-practiceフォルダを作ります。
ターミナルではmkdirで作成し、cdで移動し、pwdで場所を確かめます。
同名の場所が既にある場合は別名で作り直してください。
node --versionとclaude --versionの表示を確認し、どちらかが使えなければ導入を済ませてから続けます。
以下のリンクからcheck-draft.mjs、settings.example.json、draft.mdを同じ場所へ保存します。
HTMLページではなく、リンク先のテキストを指定した名前で保存してください。
詳しいコマンドは配布手順書にあります。
ファイル名へ.txtが追加されていると起動できないため、保存後の名前を確認します。
まず「node check-draft.mjs --check」を実行します。
正常な見本では0KU OKが出ます。
次にエディタで出典の見出しとその下の一文を取り除き、同じコマンドを実行してください。
0KU INVALIDと不足した項目が出れば、期待した不備を検出しています。
出典を戻し、OKへ戻ることまで試します。
手動で検査するときの終了値は、正常が0、原稿不備が1、検査不能が2です。
直後にecho $?を実行すると数値が分かります。
この段階でERRORになるなら、Hookへ登録しても直りません。
現在地、原稿名、保存内容を先に確認します。
形式検査が単独で動くことを確認してから、自動実行につなぎます。
新しいプロジェクトだけへ登録する
設定は、新規練習フォルダの.claude/settings.jsonへ保存します。
「mkdir .claude」を実行し、成功した場合だけ「cp -n settings.example.json .claude/settings.json」を実行します。
.claudeが既にあるというエラーなら先へ進まず、別の新規場所を使います。
既存設定を見本で上書きしてはいけません。
設定のPostToolUseはツールの処理が終わった後、matcherのEdit|Writeは二つの編集ツールを指定します。
実行するのはNode.jsと配布スクリプトです。
設定内のCLAUDE_PROJECT_DIRはClaude Codeが渡すプロジェクトの場所であり、手入力の本番パスに置き換える必要はありません。
空白を含む場所でも使えるよう引用符を付けています。
練習場所で「claude --debug-file hook-debug.log」を起動し、必要な確認画面に従います。
その後「/hooks」で一覧を開き、PostToolUse、Edit|Write、配布スクリプトの組合せを確かめます。
表示されなければJSONと保存先を見直して起動し直します。
一覧にない状態で、登録済みと思って課題を進めないでください。
このコマンド例はmacOSとLinux向けです。
WindowsではWSLで同じ手順を使うか、公式のWindows向け設定を確認します。
既存プロジェクトへ導入する場合は、他の設定やHooksを残して追加する作業が別に必要です。
今回の練習は、その移植を含めず、新規場所での認識と動作を完成条件にします。
EditとWriteで発動を確認する
正常なdraft.mdを用意し、「Editツールで10時を11時へ変更し、ほかの行は維持してください。Hookの結果を報告し、Bashは使わないでください」と依頼します。
ツールの記録でEditが使われたことを確認します。
会話に成功表示が出ない場合もあるため、AIの返答だけでなくデバッグログの0KU OKを確かめます。
次に「検出練習として、Editツールで出典の見出しと本文だけを取り除き、結果を報告して終了してください。自動修正はしないでください」と依頼します。
ログの0KU INVALIDに不足項目が出ることを見ます。
実際の原稿も開き、出典が消えた状態を確認してください。
すでに編集されたことと、不備を検出したことは別の出来事です。
最後は「Writeツールで正常な見本と同じ内容をdraft.mdへ保存してください」と頼みます。
Writeの記録とOKを確認し、手動検査でも合格することを確かめます。
これで登録、正常、異常、修正後の四段階がそろいます。
原稿を元へ戻す際も、設定ファイルや検査スクリプトまで変更させる必要はありません。
この設定はBashや別のエディタでの変更には反応しません。
Readも対象外です。
別のファイルをEditやWriteで更新した場合は、検査側がSKIPと返します。
意図した方法で編集したかを確認することが、未発動を調べる第一歩です。
ログには作業内容が含まれ得るため、練習では架空資料だけを使います。
検出と操作の禁止を区別する
PostToolUseは編集後に動くため、変更の取消機能ではありません。
配布スクリプトは不備をJSONのdecision: blockとreasonでClaudeへ伝えますが、既に終わった編集を元へ戻しません。
公開や次の操作を必ず止める保証もありません。
今回の課題では人が結果を読み、修正と再検査が済むまで成果物を採用しない運用にします。
Hookモードでは、JSONを正常に返すため終了値を0にしています。
手動検査と異なり、終了値0だけで原稿が合格したとは判断できません。
表示のOK、INVALID、ERRORを読み分けます。
異常を作ったのに何も出ない場合は、出典がまだ残っていないか、検査対象がdraft.mdかを先に確認してください。
検査不能なら、Node.jsがClaude Codeを起動した環境でも使えるか、スクリプトと原稿が指定した場所にあるかを調べます。
原稿の問題ではないのに文章を直し続けないことが大切です。
/hooksでは見えるのに動かない場合は実際のツール名とログを照合し、登録の問題と実行の問題を分けます。
自動検査を外す場合も、練習の設定全体を無条件に消しません。
登録したPostToolUseの項目だけを確認して外し、セッションを開始し直します。
他の検査がある場所へ移すときは、誰が管理し、何を合格とし、異常後に誰が判断するかを先に決めます。
形式が通ることと、内容が仕事で使えることを最後まで区別してください。
実践課題
実践課題：原稿編集後の検査を動かす
新規練習場所で配布ファイルを動かし、手動検査からHookの登録、EditとWriteでの発動まで確認します。
設定しただけで完了にはせず、ログと実際の原稿を対応させてください。
- 手動でOKと出典不足のINVALIDを確認し、見本を戻します。
- 新規.claude/settings.jsonへ保存し、/hooksで認識を確認します。
- Editで正常変更と出典削除を行い、それぞれのHook出力を読みます。
- Writeで見本を復元し、OKと原稿の内容を確認します。
完成例（架空）：営業時間の変更後はOK、出典削除後はINVALIDが記録されました。
原稿は自動では戻らず、Writeで正常な見本へ戻した後にOKを確認しました。
対象外のファイルはSKIPで、公開操作は行っていません。
自己確認
- 実際にEditとWriteが使われましたか。
- 原稿不備と検査不能を区別できますか。
- 不備検出が編集の取消や公開禁止を保証しないと説明できますか。
まとめ
Hooksは、機械的な確認を編集の出来事へ結び付けます。
新規の小さな場所で手動検査を確かめ、登録後は実際のEditとWriteで正常と異常を試してください。
検出結果と編集済みの状態を分けて読み、人が修正後の採用を判断します。
- 形式検査の対象と限界を決めます。
- /hooksと実際のツール記録で発動を確かめます。
- 検出後は人が結果を読み、修正と再検査を行います。
