Automation

常設指示

継続指示は、定義されたプログラムについてエージェントに恒久的な実行権限を付与します。タスクごとにエージェントへ指示する代わりに、明確な範囲、トリガー、エスカレーションルールを持つプログラムを定義すると、エージェントはその境界内で自律的に実行します。「週次レポートはあなたの担当です。毎週金曜日に作成して送信し、何か問題がありそうな場合にのみエスカレーションしてください。」

継続指示が必要な理由

継続指示がない場合: タスクごとにエージェントへ指示する必要があり、定型作業が忘れられたり遅延したりして、あなた自身がボトルネックになります。

継続指示がある場合: エージェントは定義された境界内で自律的に実行し、定型作業はスケジュールどおりに行われ、例外や承認が必要な場合にのみあなたが関与します。

仕組み

継続指示はエージェントワークスペースのファイルで定義します。推奨される方法は、エージェントが常にコンテキストとして参照できるよう、セッションごとに自動挿入される AGENTS.md に直接記載することです。大規模な設定では、standing-orders.md のような専用ファイルに配置し、AGENTS.md から参照することもできます。

各プログラムでは、以下を指定します。

  1. 範囲 - エージェントに許可される操作
  2. トリガー - 実行するタイミング(スケジュール、イベント、条件)
  3. 承認ゲート - 実行前に人間の承認が必要な操作
  4. エスカレーションルール - 処理を停止して支援を求めるタイミング

エージェントは、ワークスペースのブートストラップファイルを介してセッションごとにこれらの指示を読み込み(自動挿入されるファイルの完全な一覧はエージェントワークスペースを参照)、時間ベースの実行を強制するCronジョブと組み合わせて実行します。

継続指示の構成

markdown
## プログラム:週次ステータスレポート **権限:** データを集計し、レポートを生成して、関係者に配信する**トリガー:** 毎週金曜日の午後4時(Cronジョブで強制)**承認ゲート:** 標準レポートには不要。異常は人間によるレビュー対象として報告する。**エスカレーション:** データソースが利用できない場合、または指標が通常と比べて異常に見える場合(平均との差が2σ超) ### 実行手順 1. 設定済みのソースから指標を取得する2. 前週および目標値と比較する3. Reports/weekly/YYYY-MM-DD.md にレポートを生成する4. 設定済みのチャネルで概要を配信する5. Agent/Logs/ に完了を記録する ### 実行してはいけないこと - 外部関係者にレポートを送信しない- ソースデータを変更しない- 指標が悪く見えても配信を省略せず、正確に報告する

継続指示とCronジョブの組み合わせ

継続指示は、エージェントに何を実行する権限があるかを定義します。Cronジョブは、それをいつ実行するかを定義します。両者は次のように連携します。

text
継続指示:「日次の受信トレイ整理はあなたの担当です」Cronジョブ(毎日午前8時):「継続指示に従って受信トレイを整理する」エージェント:継続指示を読む → 手順を実行する → 結果を報告する

Cronジョブのプロンプトでは、継続指示の内容を重複して記載するのではなく、それを参照してください。

bash
openclaw cron add \  --name daily-inbox-triage \  --cron "0 8 * * 1-5" \  --tz America/New_York \  --timeout-seconds 300 \  --announce \  --channel imessage \  --to "+1XXXXXXXXXX" \  --message "継続指示に従って日次の受信トレイ整理を実行してください。新しいアラートがないかメールを確認してください。各項目を解析、分類し、永続化してください。概要を所有者に報告してください。不明なものはエスカレーションしてください。"

例1:コンテンツとソーシャルメディア(週次サイクル)

markdown
## プログラム:コンテンツとソーシャルメディア **権限:** コンテンツの下書き、投稿のスケジュール設定、エンゲージメントレポートの作成**承認ゲート:** 最初の30日間はすべての投稿に所有者のレビューが必要で、その後は継続承認とする**トリガー:** 週次サイクル(月曜日にレビュー → 週半ばに下書き → 金曜日に概要報告) ### 週次サイクル - **月曜日:** プラットフォームの指標とオーディエンスのエンゲージメントを確認する- **火曜日~木曜日:** ソーシャル投稿の下書きを作成し、ブログコンテンツを制作する- **金曜日:** 週次マーケティング概要を作成する → 所有者に配信する ### コンテンツルール - 文体はブランドに合わせる必要がある(SOUL.md またはブランド文体ガイドを参照)- 公開コンテンツで自身をAIと明かさない- 利用可能な場合は指標を含める- 自己宣伝ではなく、オーディエンスへの価値に重点を置く

例2:財務業務(イベントトリガー型)

markdown
## プログラム:財務処理 **権限:** 取引データを処理し、レポートを生成して、概要を送信する**承認ゲート:** 分析には不要。提案には所有者の承認が必要。**トリガー:** 新しいデータファイルの検出、またはスケジュールされた月次サイクル ### 新しいデータを受信した場合 1. 指定された入力ディレクトリで新しいファイルを検出する2. すべての取引を解析して分類する3. 予算目標と比較する4. 異常な項目、しきい値の超過、新しい定期請求を報告対象にする5. 指定された出力ディレクトリにレポートを生成する6. 設定済みのチャネルで所有者に概要を配信する ### エスカレーションルール - 単一項目が500ドル超:即時に警告する- カテゴリが予算を20%超過:レポートで報告する- 識別できない取引:分類について所有者に確認する- 2回再試行しても処理に失敗:失敗を報告し、推測しない

例3:監視とアラート(継続的)

markdown
## プログラム:システム監視 **権限:** システムの正常性を確認し、サービスを再起動して、アラートを送信する**承認ゲート:** サービスは自動的に再起動する。再起動に2回失敗した場合はエスカレーションする。**トリガー:** Heartbeatサイクルごと ### 確認項目 - サービスの正常性エンドポイントが応答している- ディスク空き容量がしきい値を上回っている- 保留中のタスクが古くなっていない(24時間超)- 配信チャネルが動作している ### 対応マトリクス | 状態                 | 操作                         | エスカレーションするか || -------------------- | ---------------------------- | ---------------------- || サービス停止         | 自動的に再起動する           | 再起動に2回失敗した場合のみ || ディスク空き容量10%未満 | 所有者に警告する           | はい                   || 24時間超の古いタスク | 所有者に通知する             | いいえ                 || チャネルがオフライン | 記録し、次のサイクルで再試行する | 2時間超オフラインの場合 |

実行・検証・報告パターン

継続指示は、厳格な実行規律と組み合わせることで最も効果を発揮します。継続指示内のすべてのタスクは、次のループに従う必要があります。

  1. 実行 - 実際の作業を行う(指示を確認するだけで済ませない)
  2. 検証 - 結果が正しいことを確認する(ファイルが存在する、メッセージが配信された、データが解析された)
  3. 報告 - 実行した内容と検証した内容を所有者に伝える
markdown
### 実行ルール - すべてのタスクは「実行・検証・報告」に従う。例外はない。- 「対応します」は実行ではない。実行してから報告する。- 検証なしの「完了」は認められない。証明する。- 実行に失敗した場合:方法を調整して1回再試行する。- それでも失敗する場合:診断結果とともに失敗を報告する。黙って失敗しない。- 無期限に再試行しない。最大3回試行し、その後エスカレーションする。

このパターンにより、タスクを完了せずに確認だけを返すという、最も一般的なエージェントの失敗を防ぎます。

複数プログラムの構成

複数の領域を管理するエージェントでは、明確な境界を持つ個別のプログラムとして継続指示を整理します。

markdown
## プログラム1:[領域A](週次) ... ## プログラム2:[領域B](月次+オンデマンド) ... ## プログラム3:[領域C](必要時) ... ## エスカレーションルール(全プログラム) - [共通のエスカレーション基準]- [プログラム全体に適用される承認ゲート]

各プログラムには以下が必要です。

  • 固有のトリガー頻度(週次、月次、イベント駆動、継続的)
  • 固有の承認ゲート(他のプログラムより多くの監督を必要とするものもある)
  • 明確な境界(エージェントが、あるプログラムの終了位置と別のプログラムの開始位置を把握できること)

ベストプラクティス

推奨事項

  • 限定的な権限から始め、信頼の構築に応じて拡大する
  • リスクの高い操作には明示的な承認ゲートを定義する
  • 「実行してはいけないこと」セクションを含める。境界は権限と同じくらい重要である
  • 確実な時間ベースの実行のためにCronジョブと組み合わせる
  • 継続指示が守られていることを確認するため、エージェントのログを毎週レビューする
  • ニーズの変化に応じて継続指示を更新する。継続指示は継続的に更新される文書である

避けること

  • 初日から広範な権限を付与する(「最善だと思うことを何でも実行する」)
  • エスカレーションルールを省略する。すべてのプログラムに「いつ停止して確認するか」という条項が必要である
  • エージェントが口頭の指示を覚えていると想定する。すべてファイルに記載する
  • 1つのプログラムに複数の領域を混在させる。領域ごとにプログラムを分ける
  • Cronジョブによる強制を忘れる。トリガーのない継続指示は単なる提案になる

関連項目

  • 自動化:すべての自動化メカニズムの概要。
  • Cronジョブ:継続指示のスケジュールを強制します。
  • フック:エージェントのライフサイクルイベントに対応するイベント駆動型スクリプト。
  • Webhook:受信HTTPイベントのトリガー。
  • エージェントワークスペース:継続指示を配置する場所と、自動挿入されるブートストラップファイル(AGENTS.mdSOUL.md など)の完全な一覧。
Was this useful?
On this page

On this page