AIエージェントの自動化｜hooks・定期実行・常駐の役割分担

AIエージェントの自動化と一口に言っても、hooks・定期実行・常駐プロセス・自動復旧では発火条件も寿命も別物です。本記事は4層の役割分担と着手順序を、公式ドキュメントと自社launchdの実測（2026-07-28）から整理します。

01結論：AIエージェントの自動化は4層に役割分担して設計する

結論は3点です。

1. 4層は「何がきっかけで動くか」で分かれます。同じ処理を違う層に置くと、想定した頻度や寿命で動きません。
2. hooksは1回のイベントで完結し、定期実行は時刻で起動して終了し、常駐プロセスは生き続け、自動復旧は中断を検知して人間ゲート手前まで進めます。
3. 着手順は取り消せない操作を止めるhooksが最優先です。常駐と自動復旧は後回しにしても即座には壊れません。

設定ファイルを書いた事実と、いま動いている事実は別に数えます。WEBMARKSは常駐ジョブの稼働をlaunchctl listで毎回実測しています。2026-07-28時点で、定義しているlaunchdジョブ8本のうち稼働中は1本だと把握しています。設計した層の数と、実際に動いている層の数は、書いた設定を信じず毎回数え直してください。

AIエージェントそのものの定義は『AIエージェントとは｜そう呼べる3条件と、呼べない境界』で扱っています。本記事は、任せると決めた後の自動化の組み方だけに絞ります。

02hooksが担う自動化｜イベント駆動で1回だけ動く層

hooksは、Claude Codeのセッション内で起きる出来事に反応して1回だけ動く層です。Claude Code公式ドキュメントはhookイベントを30種類定義しています。出典はClaude Code公式ドキュメントのHook lifecycle表で、2026-07-29に確認しました。代表例はSessionStart・PreToolUse・PostToolUse・Stop・SessionEndです。

hooksの本質は、常に動いているプロセスではないという点です。標準入力でJSONを受け取り、標準出力に判定結果を返した時点で役目を終えます。判定は終了コードでも表現でき、コード0はJSON出力を解釈、コード2はその場でブロックという扱いです（出典: Claude Code公式ドキュメント）。

#!/bin/bash
# PreToolUseフックの最小構成
DECISION=$(judge_command "$1")
if [ "$DECISION" = "deny" ]; then
  echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny"}}'
  exit 0
fi
exit 0

このスクリプトはイベントが来るたびに新規プロセスとして起動し、判定を返して終了します。裏で待ち受け続けるデーモンではありません。だからこそ、hooksに「毎晩0時にレポートを送る」ような時刻起点の処理を書いても動きません。イベントが来ない限り、そもそも呼ばれないためです。

危険なコマンドを遮断する実装の詳細は『Claude CodeのPreToolUseフック｜危険コマンド遮断のコード例』にまとめています。ここでは「hooksは時刻では動かない」という一点だけ押さえてください。この制約が、次に説明する定期実行という別の層が要る理由です。

03定期実行が担う自動化｜時刻と間隔で起動し、動き終えたら閉じる層

定期実行は、hooksが反応できない「時刻」や「一定間隔」をきっかけに、外側からプロセスを新規に起動する層です。macOSではlaunchdが標準の仕組みです。Appleはcronを旧来の方式として扱い、共有のcrontabファイルをプログラムから直接書き換えることを避けるよう案内しています（出典: Apple公式ドキュメント）。

launchdの起動条件は、StartInterval（秒単位の間隔）とStartCalendarInterval（曜日・時・分などの指定時刻）の2種類に分かれます。スリープ中に予定が来た場合の扱いが異なる点は、実装前に確認しておく価値があります。

StartCalendarIntervalで組んだジョブだけが、スリープからの復帰時に取りこぼした1回を追いかけて実行します（出典: Apple公式ドキュメント）。StartIntervalとcronはどちらも、スリープ・電源オフ中の予定をそのまま切り捨てます。

WEBMARKSはlaunchdジョブを8本定義しています。名称にはchatwork-morning-fetch・downloads-auto-import・offsite-backupなど、時刻起点の処理を想起させるものが含まれます。書いた設定を信じずlaunchctl listで毎回確認しています。2026-07-28の実測では、このうち7本がplistとして存在するだけでロードされていないと把握しています。

定期実行の失敗は静かです。予定が飛んでも、エラー画面は出ません。次のセクションで扱う「落ちても復帰するか」「監視できているか」という論点は、定期実行にもそのまま関わります。

04常駐プロセスという自動化レイヤーは、なぜ落ちたら復帰するのか

常駐プロセスは、起動後にプロセスとして生き続けることを前提にした層です。launchdではKeepAliveキーで表現し、値をtrueにするとジョブが終了するたびにlaunchdが再起動します（出典: Apple公式ドキュメント）。

<key>Label</key>
<string>com.example.watcher</string>
<key>ProgramArguments</key>
<array>
  <string>/usr/bin/python3</string>
  <string>/path/to/watcher.py</string>
</array>
<key>KeepAlive</key>
<true/>

上の構成はあくまで典型的な形で、WEBMARKSの実ファイルそのものではありません。ここで押さえたいのは1点です。KeepAliveと定期実行の起動キー（StartInterval・StartCalendarInterval）は、launchd内で別物として扱われます。

KeepAliveには、Apple公式ドキュメントが明記する落とし穴があります。起動から10秒未満で終了する状態が続くと、launchdは常駐プロセスを「クラッシュしている」と判定します。以後は再起動しなくなると明記されています（出典: Apple公式ドキュメント）。常駐のつもりで設定しても、実装のバグで即終了を繰り返せば、静かに動かなくなります。

WEBMARKSは常駐プロセスの稼働も2026-07-28にlaunchctl listで実測し、把握しています。launchdジョブ8本のうち、ロードされていたのはcom.webmarks.computer-use-input-guardの1本だけでした。残る7本はplistとして存在しますが、ロードされていない状態です。ロードされていない状態と、ロード後に再起動を繰り返してスローされた状態は、原因も対処もまったく別の障害です。

05自動復旧という自動化レイヤーは、中断を人間ゲート手前まで進める

自動復旧は、作業がクラッシュ・再起動・レート制限などで途中停止したことを検知し、送信・公開・削除のような取り消せない操作の手前まで、人手を介さずに作業を進め直す層です。

Anthropicは、エージェントが処理の途中で立ち止まり、チェックポイントで人からのフィードバックを待つ設計を紹介しています（出典: Anthropic公式）。自動復旧は、この「立ち止まる場所」を再起動後にも保つための仕組みです。作業状態を記録した台帳がなければ、どこまで進んでいたかをAI自身も思い出せません。

自動復旧は、他の3層より「壊れていることに気づきにくい」という性質を持ちます。正常に動いているときは何も表示せず、止まっているときも同じく何も表示しないためです。

WEBMARKSは自動再開パトロールという仕組みを、レート制限解除後にタスク台帳の未完了項目を自動で再開する目的で運用してきました。実行記録ファイルの最終更新日を毎回実測しています。2026-07-28時点では最終更新が2026-07-13で止まっており、記事執筆時点から15日が経過していると把握しています。

監視の指標を誤ると、動いていないことにさえ気づけません。WEBMARKSは過去に、ファイルの更新時刻だけを根拠に「動いている・壊れていない」と判定し、3日間で233回の誤爆を起こした事例を持っています。原因の切り分け手順は『AI運用の障害切り分け｜更新時刻を犯人にしない4段の手順』にまとめています。自動復旧を組むときは、動いた証拠を推測ではなく記録として残す設計が要ります。

06AIエージェントの自動化をどこから始めるか｜4層を導入する順序

4層を同時に整える必要はありません。取り消せない操作のリスクが高い層から着手し、後の層は前の層の土台の上に積みます。

1. 対象操作を洗い出し、hooksでdenyする：入力は禁止したい操作の一覧、確認方法は該当コマンドを実際に打ってdenyされるかどうかです。
2. 手作業で回している定型処理を定期実行へ移す：入力は毎回人が起動している作業、確認方法はlaunchctl listでジョブがロードされているかです。
3. 止まると業務が止まる処理だけを常駐プロセス化する：入力は落ちて困る処理の一覧、確認方法はプロセスを強制終了して自動的に復帰するかです。
4. 作業状態を残す台帳が定着してから自動復旧を組む：入力は案件ごとの進捗記録、確認方法はセッションを強制終了し、次回起動時に自動で再開されるかです。
5. 月次で「定義した本数」と「ロードされている本数」を数える：入力はlaunchctl listの出力です。確認方法は、数が一致しているか、一致しなければどの層で止まっているかです。

止める場所を先に決めてから自動化を足す順序は『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』の設計思想と同じです。自動復旧が取り消せない操作を無人のまま押し進める設計になっていないか、着手前に確認してください。

07自動化でつまずきやすい点｜設計と稼働がずれる3つの落とし穴

落とし穴1：plistを書いただけでロードしていない。 設定ファイルを作成しても、launchctl load（またはbootstrap）を実行しなければ何も起動しません。WEBMARKSの実測（2026-07-28）では、定義した8本のうち7本がこの状態でした。

落とし穴2：KeepAliveと定期実行を混同する。 秒単位で動かしたいだけなのにKeepAliveを選ぶと、処理が終わるたびに即再起動を繰り返します。10秒未満での終了が続くと、launchdに再起動を止められます（出典: Apple公式ドキュメント）。「常に生きていてほしいか」「時刻で動けば十分か」を先に切り分けてください。

落とし穴3：自動復旧の監視自体が止まっていることに気づかない。 自動再開パトロールの最終実行が2026-07-13で止まっていたケースは、まさにこの落とし穴です。監視対象が正常でも異常でも画面に何も出ない設計は、定期的に人が実測しない限り気づけません。

3つに共通するのは、「設定を書いた」と「実際に動いている」を同一視した点です。層を1つ導入するたびに、実際の稼働を数値で確認する手順を差し込んでください。

08自動化を整えるチェックリスト

• 送信・公開・削除・決済に関わる操作を、hooksのdeny対象として先に洗い出したか
• 定期実行に回す処理と、常駐プロセス化する処理を、寿命の必要性で区別したか
• KeepAliveとStartInterval／StartCalendarIntervalのどちらを使うべきか、処理の性質で選んだか
• スリープ中・電源オフ中に予定が飛んでよい処理かどうかを確認したか
• 自動復旧を組む前に、作業状態を記録する台帳がすでに運用されているか確認したか
• launchctl list等で、定義した本数と実際にロードされている本数を数えたか
• 自動復旧の監視そのものが止まっていないかを、定期的に実測しているか
• 自動化した処理が、人間ゲートの手前で止まる設計になっているか確認したか

09FAQ