AIエージェントの自動化は4層｜着手する順番と稼働の数え方

「毎朝のレポートを出したくて、フックに書いたんです。でも、時間になっても何も動きませんでした」。

自動化でつまずく話は、たいていこの形をしています。書いた中身が間違っていたのではありません。置いた場所が違った、という話です。

自動化と一口に言っても、動き出すきっかけは同じではありません。イベントで1回だけ動くもの、時刻で起きて終わるもの、生き続けるもの、途切れを検知して再開するもの。同じ処理でも、どの層に置くかで頻度も寿命も変わります。

この記事は、その4層の役割分担と、着手する順番を整理します。根拠は公式ドキュメントと、運営元WEBMARKSが自社のlaunchdを実測した記録です。

本記事の検証環境：Claude Code / macOS（launchd）/ 2026-07-28実測。公式ドキュメントは2026-07-29に確認しています。

進行役は3人です。若葉さん（Web担当2年目）が用語のそもそもを聞き、高梨課長（自分の手で動かす立場）が実装側の疑問を出し、鈴木さん（本誌監修）が答えます。ご自身に近いほうの質問から読んでいただいて構いません。

01AIエージェントの自動化を、なぜ4つの層に分けて設計するんですか？

若葉さん

若葉さんの発言

自動化って、ぜんぶ「勝手に動いてくれる仕組み」だと思っていました。4つに分ける意味が、まだ飲み込めていません。

鈴木さん

鈴木さんの発言

分ける物差しは1つだけです。何がきっかけで動き出すか、ですね。ここが違うと、いつ終わるかも、止まったときに気づけるかも変わってきます。

きっかけで並べると、層は4つになります。イベントに反応するhooks、時刻や間隔で外から起こされる定期実行、起動したあと生き続ける常駐プロセス、そして途切れを見つけて作業をやり直す自動復旧です。

やっかいなのは、この4つが「自動で動く」という一言でまとめられてしまう点です。まとめた瞬間、どこに置いても同じように動く気がしてきます。実際には、呼ばれる条件がそれぞれ違います。

たとえの右側を、そのまま実務の言葉に置き直したものが次の表です。いちばん右の列は、運営元WEBMARKSで各層がどうなっているかの実測です。

02hooksは、AIエージェントの自動化でどこまでを担う層なんですか？

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

代表的なものは、SessionStart・PreToolUse・PostToolUse・Stop・SessionEndです。名前のとおり、セッションの入口から出口までに並んでいます。

並び順が分かると、どこに何を差し込めるかも見えてきます。

03自動化のhooksは、どうやって判定を返して、AI活用の実行を止めるんですか？

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

このスクリプトは、イベントが来るたびに新しいプロセスとして起動し、判定を返して終わります。裏で待ち受け続けるデーモンではありません。

04自動化のうち、時刻で動かしたい処理はエージェントのhooksでは扱えないんですか？

高梨課長

高梨課長の発言

毎晩0時にレポートを送る処理を、フックに書いたんです。構文は通っているのに、いくら待っても動きません。

鈴木さん

鈴木さんの発言

書き方の問題ではないと思います。hooksは、イベントが来たときだけ呼ばれる仕組みなので、時刻という合図では誰も呼びに来ないんです。玄関のセンサーライトに、朝7時に点いてほしいと頼んでいる状態に近いですね。

冒頭の「時間になっても動かない」は、ここで説明がつきます。イベントが発生しない限り、hookのスクリプトはそもそも起動しません。時刻は、Claude Codeのセッション内で起きる出来事ではないからです。

つまり、hooksに時刻起点の処理を書いても待ち続けることになります。この制約こそが、次に説明する定期実行という別の層が要る理由です。

危険なコマンドを遮断する実装の詳細は『Claude CodeのPreToolUseで危険コマンドを遮断する4つの判定』にまとめています。ここでは「hooksは時刻では動かない」の一点だけ押さえてください。

05自動化の定期実行は、AI活用のなかでどんな処理を任せる層なんですか？

定期実行は、hooksが反応できない時刻や一定間隔をきっかけに、外側からプロセスを新しく起こす層です。macOSではlaunchdが標準の仕組みになります。

Appleはcronを旧来の方式として扱い、共有のcrontabファイルをプログラムから直接書き換えることを避けるよう案内しています（出典: Apple公式ドキュメント）。新しく組むなら、個別のplistファイルで管理できるlaunchdを土台にしてください。

launchdの起動条件は、大きく2つに分かれます。StartIntervalは秒単位の間隔で、StartCalendarIntervalは曜日・時・分などの指定時刻です。どちらも「起きて、動いて、終わる」形は同じです。

運営元WEBMARKSは、launchdジョブを8本定義しています。名前を見ると、chatwork-morning-fetch・downloads-auto-import・offsite-backupのように、時刻起点の処理を思わせるものが並びます。定期実行に向いた業務は、たいてい「毎回人が同じ時間に手で起動している作業」です。

ただし、定期実行の失敗は静かです。予定が飛んでも、エラー画面は出ません。だから、この層を足したあとは確認の手順もセットで足すことになります。

06スリープ中に来た予定は、AI導入した自動化でどう扱われるんですか？

ここは実装前に確認しておく価値があります。同じ「定期実行」でも、選んだキーによって、眠っているあいだの予定の扱いが変わるためです。

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

ノートPCで運用するなら、この違いは毎日効いてきます。閉じて持ち歩く時間が長いほど、切り捨てられる予定は増えます。

07自動化の常駐プロセスは、AI社員を動かし続ける層としてどう設計するんですか？

高梨課長

高梨課長の発言

落ちてほしくない処理があります。とりあえずKeepAliveを付けておけば安心、という理解で合っていますか。

鈴木さん

鈴木さんの発言

そこは分けて考えたいところです。KeepAliveは「終わったら起こし直す」設定であって、「いつ起こすか」の設定ではありません。時刻で起きれば足りる処理に付けると、終わるそばから起こし直すことになります。

常駐プロセスは、起動したあともプロセスとして生き続けることを前提にした層です。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の中で別物として扱われます。

区画が決まれば、キーは自動的に決まります。逆に言えば、区画を決めないままキーを選ぶと、次の落とし穴に落ちます。

08常駐させた自動化が静かに止まるのは、AIエージェントのどこを見落としたときですか？

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

常駐のつもりで設定しても、実装のバグですぐ終わり続ければ、静かに動かなくなります。画面には何も出ません。

そして、そもそも読み込まれていない場合もあります。運営元WEBMARKSは常駐の状態を2026-07-28にlaunchctl listで実測しました。定義していた8本のうち、ロードされていたのはcom.webmarks.computer-use-input-guardの1本だけです。残る7本はplistとして存在しますが、ロードされていない状態でした。

ここで分けて数えたいのは、次の2つです。ロードされていない状態と、ロードされたあとに再起動を繰り返して止められた状態。見た目はどちらも「動いていない」ですが、原因も対処もまったく別の障害です。

09自動復旧が、AIエージェントの自動化でいちばん気づきにくいのはなぜですか？

若葉さん

若葉さんの発言

止まっていることに気づけない層がある、と表にありました。気づけないのに、どうやって直すんでしょうか。

鈴木さん

鈴木さんの発言

直す前に、見分けるほうが先ですね。この層は、順調なときと止まっているときで、画面の見た目が同じなんです。だから「何も起きていない」を、良い知らせとして読まないようにします。

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

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

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

監視の指標を誤ると、動いていないことにさえ気づけません。WEBMARKSは過去に、ファイルの更新時刻だけを根拠に「動いている・壊れていない」と判定し、3日間で233回の誤爆を起こした事例を持っています。切り分けの手順は『AI運用の障害の原因切り分け｜証跡で追う4段の順序』にまとめています。

10どこから着手すれば、生成AIの自動化は安全に広がるんですか？

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

いちばん下がhooksです。送信・公開・削除・決済のように取り消せない操作を洗い出し、denyの対象にします。確かめ方は、該当するコマンドを実際に打って止まるかどうかです。

その上が定期実行です。毎回人が起動している定型処理を移します。確かめ方は、launchctl listでジョブがロードされているかどうかです。

さらに上が常駐プロセスです。止まると業務が止まる処理だけを絞り込みます。確かめ方は、プロセスを強制終了して自動で復帰するかどうかです。

いちばん上が自動復旧です。作業状態を残す台帳が定着してから組みます。確かめ方は、セッションを強制終了し、次回の起動で再開されるかどうかです。台帳という土台が無い状態で先にこの層だけ組むと、再開の起点が決まりません。

止める場所を先に決めてから自動化を足す順序は、『AIエージェントの承認ゲート｜止める操作4種と3層の選び方』の設計思想と同じです。

11自動化を広げる前に、AIエージェントの何を数えておけばいいんですか？

高梨課長

高梨課長の発言

数えるのが大事なのは分かりました。ただ、うちで毎月それをやる余裕があるかというと、正直あやしいです。

鈴木さん

鈴木さんの発言

数えるのは2つの数字だけで足ります。定義した本数と、いま読み込まれている本数ですね。この2つがずれていたら、どこかの層で止まっている。それだけの話にしておくと、続けやすくなります。

ここまで見てきた落とし穴は、形を変えた同じ1つです。「設定を書いた」と「実際に動いている」を、同じものとして数えてしまうこと。

plistを作成しても、launchctl load（またはbootstrap）を実行しなければ何も起動しません。WEBMARKSの実測では、定義した8本のうち7本がこの状態でした。KeepAliveと定期実行を取り違えれば、処理が終わるたびに即再起動を繰り返します。自動復旧の監視そのものが止まっていても、画面には何も出ません。

だから、層を1つ導入するたびに、実際の稼働を数える手順を差し込んでください。

12エージェントに自動化を任せる前に、チェックリストで何を確かめますか？

ここまでの内容を、着手前に自分の環境へ当てはめるための項目にまとめます。「いいえ」が1つでもあれば、着手ではなく確認のほうを先に進めてください。

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

上から順に埋めていくと、止まっている層がどこかで引っかかります。埋まらなかった行が、次に手をつける場所です。

13よくある質問

14まとめ｜今日やる3つのこと

分け目は、何をきっかけに動くかの一点でした。層が決まれば寿命が決まり、寿命が決まれば見つけ方も決まります。自社の自動化に当てはめるところまで、この順で進めてください。