AIエージェントの完了を待たない — 通知・非同期・イベント駆動
この章の目次開く
エージェントを使い始めた人が最初に感じる違和感が、待ち時間です。指示を出したあと、数十秒から数分、画面を見ている時間が生まれます。しかもその間に別の作業を始めると、完了に気づくのが遅れます。
前の章で並列実行を扱いましたが、並べただけで全部に張り付いていては、負荷が増えるだけです。この章では、待つのをやめるための3つの方向を整理します。
学習者終わったか気になって、結局ずっと画面を見ちゃうんだよね…
待たないための3方向
やり方は大きく3つに分かれます。
| 方向 | やること | 効くもの |
|---|---|---|
| 知らせる | 完了や確認待ちを通知する | 見張らなくてよくなる |
| 手を離す | PCを閉じても走り続ける環境で動かす | 場所と時間の制約が外れる |
| 起動しない | イベントに反応して勝手に始まる | そもそも指示を出す手間が消える |
上から順に導入が簡単です。1つ目だけでも体感は大きく変わります。
知らせる — フックで通知する
最も費用対効果が高いのがこれです。エージェントのライフサイクル上のイベントでスクリプトを走らせるフックを使うと、完了時に通知を出せます。
公式ドキュメントには多数のイベントが定義されていますが、通知の用途で使うのは主に次の3つです。
| イベント | 発火するタイミング | 使いどころ |
|---|---|---|
Notification | エージェントが通知を送るとき | 確認待ち・入力待ち・完了など、種類で絞れる |
Stop | 応答が終わったとき（ターンごとに1回） | 作業完了の通知 |
SubagentStop | サブエージェントが終わったとき | 分担した調査の完了 |
Notification はさらに種類で絞り込めます。公式が挙げているものには、権限の確認待ち、アイドル状態、エージェントが入力を必要としている状態、エージェントが完了した状態などがあります。つまり「止まって待っているとき」と「終わったとき」を分けて扱えます。
通知の出し方は環境によって変わりますが、公式にはフックの出力でデスクトップ通知を出す・ウィンドウタイトルを変える・ベルを鳴らすといった手段が用意されています。OSの通知コマンドを直接呼ぶ方法もあります。
先生「完了」だけじゃなく「確認待ち」も通知するのが大事だよ。止まって待っているのに気づかないのが、いちばんもったいない待ち時間だからね。
手を離す — 走り続ける環境で動かす
通知を入れても、PCを閉じたら止まる環境では「席を外す」ができません。実行環境の章で扱ったクラウド実行は、ここに効きます。
公式によれば、クラウドのセッションはブラウザを閉じても継続し、モバイルアプリから状況を確認できます。CLIからは進行中のタスク一覧を確認でき、完了後に手元へ引き寄せることもできます。
これが成立すると、作業の形が変わります。指示を出す → 離れる → 通知で戻る → 結果をレビューするという流れになり、待ち時間という概念自体が薄くなります。
起動しない — イベント駆動
3つ目が、こちらから指示を出すのをやめる形です。
公式が提供している例が分かりやすく、プルリクエストを監視して、CIの失敗やレビューコメントに自動で反応する仕組みがあります。挙動は次のように整理されています。
| 状況 | エージェントの動き |
|---|---|
| 明確な修正で、過去の指示と矛盾しない | 修正してpushし、何をしたかを説明する |
| 曖昧、または設計上の判断を伴う | 実行前に人間に確認する |
| 重複、または対応不要 | 記録して次へ進む |
「曖昧なら聞く」が入っているのが実務的です。全部を自動で押し切る設計ではありません。
もう1つ、公式が挙げている限界があります。ベースブランチが進んでコンフリクトが発生しても、GitHubはwebhookを出さないため、自動では反応できません。コンフリクトの解消は人間から声をかける必要があります。
イベント駆動には、決まった時刻に走らせる形もあります。定期実行の仕組みを使えば、夜間にリファクタリングを走らせて朝に結果を見る、といった運用が組めます。
権限設計とセットで入れる
ここで権限設計の章に戻ります。待たないということは、見ていないということです。見ていない時間に何を許すかは、事前に決めておく必要があります。
| 待たない度合い | 前提として要るもの |
|---|---|
| 通知を受けて戻る | 確認待ちで止まる設定（従来どおり） |
| 席を外している間に進める | 許可リストの整備、隔離環境 |
| イベントで勝手に始まる | 禁止ルールの固定、記録、副作用の確認 |
よくあるハマりどころ
通知を設定しないまま並列にする。 並列度が上がるほど、見張るコストが線形に増えます。通知のほうが先です。
すべてに通知を付ける。 通知が多すぎると全部無視するようになります。確認待ちと完了に絞るのが現実的です。
イベント駆動を権限設計なしで入れる。 見ていない時間に何が起きるかを決めずに自動起動させると、事故が起きたときに止められません。
自動応答の副作用を確認しない。 前述のとおり、コメントで動く自動化を誘発することがあります。
コンフリクトも自動で直ると思う。 webhookが出ないので反応できません。
通知の設定自体が処理を遅くする。 待つ必要のない通知は非同期で走らせます。
ちゃんと使うためのポイント
- 待たないための方向は3つ。知らせる・手を離す・起動しない
- まず通知。
Notification/Stop/SubagentStopで、確認待ちと完了を拾う - 「止まって待っている」ことに気づけない時間が、いちばんもったいない
- 席を外すなら、PCを閉じても走り続ける環境が要る
- イベント駆動は「曖昧なら聞く」設計になっているものを選ぶ
- 自動応答は自分のアカウントで投稿される。コメント起動の自動化を誘発しうる
- 自動化の度合いを上げる前に、境界（禁止ルール・記録）を先に固める
ここまでで実行環境の話は終わりです。次の部では、エージェントに何を渡すか——コンテキストの設計に入ります。環境を整えても、渡す情報を間違えれば結果は安定しません。
参考リンク
- Hooks reference（Claude Code 公式） — イベント一覧、
Notificationの種類、非同期フックの指定 - Use Claude Code on the web（公式） — セッションの継続、モバイルからの確認、PRの自動修正とその副作用
- Routines（Claude Code 公式） — スケジュール実行やイベントを起点にした自動実行