AIコーディングエージェントをブログ運用や個人開発に入れると、作業はかなり速くなります。調査メモを読む、記事構成を作る、コードを修正する、テストを回す、WordPress下書き用のHTMLを整える。これまで人間が順番に見ていた作業を、Claude CodeやCodexに任せられる場面は増えています。
ただし、便利になるほど怖くなる部分もあります。特に怖いのは、AIが「うまく動いたように見える」まま、公開、削除、送信、認証情報の出力、顧客データの扱いといった一線を越えてしまうことです。人間が毎回注意していればよい、という考え方だけでは長く続きません。疲れている日もありますし、定期実行やバックグラウンド実行では、そもそも人間が画面を見ていないこともあります。
そこで今回の記事では、Claude CodeのHooksを「AIに作業を任せる前の安全弁」として深掘りします。Claude Code公式ドキュメントでは、HooksはClaude Codeのライフサイクル上の特定タイミングで自動実行されるユーザー定義のシェルコマンド、HTTPエンドポイント、またはLLMプロンプトとして説明されています。つまり、AIが何かをする前後に、人間側が決めたチェックを差し込める仕組みです。
この記事の結論はシンプルです。Claude Code Hooksは、AIを「何でも実行してくれる存在」にするための機能ではありません。むしろ逆で、AIに任せてよい作業と、必ず人間確認に戻す作業を分けるための境界線として使うと強いです。個人ブログ運用、フリーランスSEの小さな自動化、社内向けの補助ツール開発では、この境界線を先に決めておくことが、安心してAIを使い続けるための土台になります。
Claude Code Hooksとは何か
Claude Codeは、コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携できるエージェント型のコーディングツールです。公式概要でも、ターミナル、IDE、デスクトップアプリ、ブラウザなど複数の場所から使えることが示されています。単なるチャットではなく、プロジェクトの中で実際に作業する相手として設計されている点が特徴です。
Hooksは、そのClaude Codeの動きに対して、あらかじめ決めた処理を差し込むための仕組みです。たとえば、ファイル編集後にフォーマッタを走らせる、コミット前にlintを実行する、特定のツール実行前に入力内容を検査する、危険な操作が含まれていれば止める、といった使い方が考えられます。
Claude Codeの公式概要では、Claude Codeはテスト作成、lintエラー修正、依存関係更新、リリースノート作成などの面倒な作業を扱えると説明されています。また、MCPで外部データソースにつなげたり、CLAUDE.mdでプロジェクトの指示を読ませたり、Hooksでアクション前後にコマンドを動かしたりできます。つまり、Hooksは「AIが作業する環境そのものを、プロジェクトに合わせて制御する部品」と見たほうが分かりやすいです。
CodexにもAGENTS.md、sandbox、permissions、automationsなど、作業範囲を縛る考え方があります。半農エンジニアラボの運用でも、WordPressは必ずdraft、X投稿はしない、Threads投稿は初期状態で自動実行しない、というルールをAGENTS.mdとruntime-rules.mdに書いています。Claude Code Hooksは、これに近い考え方をClaude Code側の実行タイミングに組み込むための機能として使えます。
AI運用で本当に怖いのは「悪意」より「勢い」
AIエージェントのリスクというと、つい大きなセキュリティ事故や攻撃を想像しがちです。もちろんそれも大事です。ただ、個人開発やブログ運用で先に起きやすいのは、もっと地味な事故です。
- 下書きのつもりが公開扱いになってしまう
- 検証用の記事URLをSNS文案に入れてしまう
- APIキーやApplication Passwordをログに出してしまう
- 一度失敗したWordPress保存処理を再実行して重複下書きを作る
- 人間確認が必要な健康、農薬、税金、法律の話を断定してしまう
- エラー後に残ったプロセスや中途半端なファイルを見落とす
これらは、AIが悪意を持って起こすというより、作業の勢いで起きます。人間でも急いでいるとやります。だからこそ、精神論ではなく仕組みで止める必要があります。
Claude Code Hooksのよいところは、こうした「勢いで進むと危ない地点」にチェックを入れられることです。AIがコードを書いた後にテストを走らせるだけでなく、AIが外部送信や公開に近い作業をしようとしたときに、警告、停止、ログ記録、人間確認への切り戻しを設計できます。
ブログ運用でHooksを使うならどこに差し込むか
半農エンジニアラボのようなWordPressブログ運用に当てはめるなら、Hooksを差し込みたい場所は大きく5つあります。
1. ファイル編集後の本文チェック
記事本文をHTMLで作る場合、保存前に最低限のチェックをしたいです。文字数、参考URLの有無、禁止表現、先頭H1の重複、公開ステータスの混入、X投稿文案の有無などです。現在このリポジトリでは、記事保存前にcheck-article.ps1で最低文字数や参考URL、禁止ステータスなどを確認する流れがあります。
Claude Code Hooksを使うなら、記事ファイルを編集した後にこのチェックを自動実行する設計が考えられます。人間が毎回「チェックして」と言わなくても、記事ファイルが更新されたタイミングで品質チェックを走らせる。失敗したら、AIにそのままWordPress保存へ進ませない。これだけでも事故はかなり減ります。
2. WordPress保存前のステータス検査
このプロジェクトでは、WordPressへの保存は下書きまでです。投稿ステータスはdraft固定で、publish、future、private、trashは使いません。これは記事本文の品質以前に、運用上の絶対ルールです。
Hooksを使う場合、WordPress保存スクリプトや外部API呼び出しの直前に、引数や本文ファイルの中身を検査できます。たとえば、コマンドやファイル内にpublishという投稿ステータスが含まれていたら止める。futureがあれば止める。SNS投稿に進みそうな文言があれば、人間確認へ戻す。こうしたルールは、チャットの指示だけでなく実行前チェックにも置くと強くなります。
3. 認証情報とログの扱い
AIに作業を任せるとき、認証情報の扱いは特に注意が必要です。WordPressのApplication Password、X APIキー、OpenAI APIキー、Threadsアクセストークンなどは、チャットやリポジトリへ直書きしない。半農エンジニアラボでも、秘密情報は.envまたは環境変数で扱うルールにしています。
Hooksでは、ログ出力やファイル編集後に、秘密情報らしき文字列が混入していないかを確認する使い方が考えられます。完璧な検知は難しいですが、少なくとも「WP_APP_PASSWORD」「OPENAI_API_KEY」「THREADS_ACCESS_TOKEN」などの環境変数名や、長いトークンらしい文字列を検出して警告するだけでも、うっかり事故の予防になります。
4. 外部送信前の人間確認
AIエージェントが便利になるほど、メール、Slack、GitHub、WordPress、SNSなど、外部へ何かを送る操作が増えます。Claude Code公式ドキュメントでも、Git操作、PR作成、CI/CD、MCP連携、スケジュール実行など、外部ツールとの接続が前提になっています。
ここで大事なのは、外部送信をすべて禁止することではありません。下書き保存のように許可するもの、公開やSNS投稿のように人間確認へ戻すものを分けることです。Hooksを使うなら、外部送信系のコマンドやHTTPエンドポイントの前に「この操作は許可済みか」を見る設計が合います。
たとえば、WordPressのdraft保存は許可する。しかし、publishを含む保存、X APIの投稿、ThreadsのConfirmPost付き実行は止める。こうした線引きをプロジェクトルールとHooksの両方に持たせると、AIに任せられる範囲が明確になります。
5. 定期実行後の結果整理
Claude Codeの公式概要では、スケジュール実行やRoutines、Desktop scheduled tasks、CLIのloopなども紹介されています。OpenAI CodexのAutomationsでも、定期タスク、Triage、sandbox、worktree、skillsの活用が説明されています。つまり、AIエージェントは「人間が見ている一回のチャット」から「定期的に動く作業者」へ近づいています。
定期実行では、結果整理が重要です。何を調べたのか、どのURLを見たのか、記事案は何か、相談事項はあるか、WordPressやSNSに進んでいないか。これを毎回人間が思い出すのは大変です。Hooksや周辺スクリプトで、実行後にログやサマリーを必ず残す設計にしておくと、翌日の自分が助かります。
Hooksは「自動化を増やす機能」ではなく「止め方を決める機能」
Hooksという名前だけを見ると、何かを自動で追加実行する機能に見えます。実際、フォーマッタやlintを自動実行する用途も自然です。しかし、AIエージェント時代のHooksは、それ以上に「止め方」を決める機能として価値があります。
AIに任せる作業は、だいたい次の4段階に分けられます。
- 読んで整理するだけの作業
- ローカルファイルを作る作業
- 外部サービスに下書き保存する作業
- 外部に公開、送信、削除する作業
このうち、1と2は比較的AIに任せやすいです。3は条件付きで任せられます。4は原則として人間確認に戻したほうが安全です。Hooksは、この段階ごとの境界線を実行前後に置くのに向いています。
半農エンジニアラボの運用でいえば、調査メモ作成と記事下書きHTML作成はAIに任せやすい。WordPress保存はdraft固定なら任せられる。公開、予約投稿、X投稿、Threads投稿は人間確認が必要。この分類は、そのままHooks設計にも使えます。
Claude Code HooksとCodexルールを併用する
Claude Codeを使うならHooks、Codexを使うならAGENTS.mdやsandbox、permissions、automationsを使う。どちらか一方だけで考えるより、同じ運用思想を複数の場所に持たせるのが現実的です。
Codex Automationsの公式ドキュメントでは、standalone automationはスケジュールに従って独立した実行を開始し、結果をTriageに報告すること、Gitリポジトリではlocal projectまたは専用worktreeで実行できること、sandbox設定によってファイル変更やネットワークアクセスなどの扱いが変わることが説明されています。これは、Claude Code Hooksと同じく「便利な自動化には権限設計が必要」という話です。
実務では、次のように役割を分けると扱いやすいです。
- AGENTS.mdやCLAUDE.mdには、方針、禁止事項、判断基準を書く
- Hooksには、実行前後に機械的に確認できるチェックを書く
- 保存スクリプトには、draft固定など破ってはいけない制約を入れる
- ログには、何を実行したか、人間確認が必要かを残す
- 人間は、公開、送信、削除、契約、医療、法律、税金などの判断を担当する
AIへの指示文だけにルールを置くと、チャットが変わったとき、文脈が圧縮されたとき、別のツールに切り替えたときに抜け落ちることがあります。逆に、スクリプトやHooksだけにルールを置くと、なぜその制約があるのかが分かりにくくなります。方針と実行チェックの両方に置くのがちょうどよいです。
小さく始めるなら3つのHooksで十分
最初から複雑なHooksを作る必要はありません。個人ブログ運用や小さな副業ツール開発なら、まずは次の3つで十分だと思います。
1. 保存前チェックHook
記事本文やコードが更新された後に、最低限のチェックを走らせます。ブログなら、文字数、参考URL、禁止表現、カテゴリ、X文案の有無。コードなら、format、lint、test、型チェックなどです。失敗したらAIに修正させるか、人間確認に戻します。
2. 危険語検出Hook
公開、削除、送信、秘密情報、課金、権限変更などに関わる語を検出します。完全な安全策ではありませんが、うっかり進行を止めるには役立ちます。このブログなら、publish、future、private、trash、ConfirmPost、APIキー名などが対象になります。
3. 実行ログHook
AIが何を実行したか、どのファイルを作ったか、何に失敗したか、人間確認が必要かをログに残します。定期運用では、翌日の自分や別チャットのAIが状況を理解するための手がかりになります。AI活用は、実行そのものよりも、後から追えることが大事です。
注意点：Hooksを過信しない
Hooksは便利ですが、万能ではありません。チェックできるのは、あらかじめ想定した条件が中心です。新しい種類の事故、曖昧な文章品質、医療や法律の個別判断、顧客との契約上の判断までは、単純なHooksでは扱いきれません。
また、Hooks自体もコードや設定です。設定を間違えれば、必要な作業まで止めてしまうことがあります。逆に、緩すぎれば危険な操作を通してしまいます。最初は警告だけにする、dry runで動かす、ログを見ながら調整する、といった段階的な導入がよいです。
セキュリティや法務に関わる領域では、「Hooksを入れたから安全」とは書けません。あくまで、事故を減らすための補助線です。特に顧客データ、医療情報、税金、法律、農薬の安全性などを扱う場合は、人間の確認や専門家確認を前提にするべきです。
半農エンジニアラボで試したい実験
このブログで次に試すなら、Claude Code Hooksを直接本番運用へ入れる前に、まずローカル限定の実験から始めたいです。たとえば、次の流れです。
- 記事HTMLを作成する
- 保存前チェックを自動実行する
- draft以外のWordPressステータスが含まれていないか確認する
- 参考URLが複数あるか確認する
- X文案に公開後URLの差し込み位置があるか確認する
- 問題がなければWordPress下書き保存へ進む
- 公開やSNS投稿に進みそうなら停止する
この実験なら、実際の公開操作を含めずに、安全弁としてのHooksの効果を見られます。さらに、Codex側のAGENTS.md、runtime-rules.md、check-article.ps1、save-wp-draft.ps1と同じ思想で比較できます。Claude CodeとCodexを競わせるのではなく、どちらのツールでも同じ運用ルールを守れるかを見る実験です。
ブログ運用は、派手な自動化よりも、同じ品質を続けられる仕組みのほうが大事です。Hooksは、その地味だけれど効く部分を支える機能だと感じます。
まとめ
Claude Code Hooksは、AIコーディングエージェントに追加の自動処理を差し込める機能です。ただし、ブログ運用や個人開発で本当に価値が出るのは、作業をもっと速く進める場面だけではありません。公開、送信、削除、認証情報、外部API、顧客データといった危ない地点で、AIを止める仕組みとして使うことに価値があります。
AIエージェントを使うほど、作業は速くなります。そのぶん、人間が確認すべき場所も見えにくくなります。だから、プロジェクトルールに方針を書き、Hooksや保存スクリプトに機械的なチェックを置き、ログに結果を残す。これが、AIを怖がりすぎず、雑にも扱わないための現実的な設計です。
次に読むなら、Codex Automationsでブログ調査を定期化する話、またはAIエージェントに公開や送信を任せる前のチェックリストを読むと、今回の内容とつながります。
