Automation
常設指示
常設指示は、定義されたプログラムについてエージェントに恒久的な実行権限を付与します。タスクごとにエージェントへ指示する代わりに、明確なスコープ、トリガー、エスカレーションルールを持つプログラムを定義すると、エージェントはその境界内で自律的に実行します。「週次レポートはあなたの担当です。毎週金曜日に作成して送信し、何か問題がありそうな場合にのみエスカレーションしてください。」
常設指示が必要な理由
常設指示がない場合: タスクごとにエージェントへ指示する必要があり、定型作業が忘れられたり遅れたりして、あなた自身がボトルネックになります。
常設指示がある場合: エージェントは定義された境界内で自律的に実行し、定型作業は予定どおりに行われ、あなたが関与するのは例外や承認が必要な場合だけになります。
仕組み
常設指示は、エージェントワークスペースのファイルで定義します。推奨される方法は、常設指示を AGENTS.md（セッションごとに自動挿入されます）へ直接記述し、エージェントが常にコンテキスト内で参照できるようにすることです。大規模な設定では、standing-orders.md のような専用ファイルに配置し、AGENTS.md から参照することもできます。
各プログラムでは、以下を指定します。
- スコープ - エージェントに許可する操作
- トリガー - 実行するタイミング（スケジュール、イベント、条件）
- 承認ゲート - 操作前に人間の承認が必要な事項
- エスカレーションルール - 処理を停止して支援を求めるタイミング
エージェントはワークスペースのブートストラップファイルを介してセッションごとにこれらの指示を読み込み（自動挿入されるファイルの完全な一覧についてはエージェントワークスペースを参照）、時間ベースの実行を強制するCron ジョブと組み合わせて実行します。
常設指示の構成
## プログラム: 週次ステータスレポート **権限:** データを集計し、レポートを生成して、関係者へ配信する**トリガー:** 毎週金曜日の午後4時（Cron ジョブで強制）**承認ゲート:** 標準レポートには不要。異常は人間によるレビュー対象として報告する。**エスカレーション:** データソースが利用できない場合、または指標が異常に見える場合（標準値から >2σ） ### 実行手順 1. 設定済みのソースから指標を取得する2. 前週および目標と比較する3. Reports/weekly/YYYY-MM-DD.md にレポートを生成する4. 設定済みのチャネルで要約を配信する5. Agent/Logs/ に完了を記録する ### 実行してはならないこと - 外部関係者へレポートを送信しない- ソースデータを変更しない- 指標が悪く見えても配信を省略せず、正確に報告する常設指示と Cron ジョブの併用
常設指示は、エージェントに許可する操作の内容を定義します。Cron ジョブは、それを実行するタイミングを定義します。両者は次のように連携します。
常設指示: 「毎日の受信トレイ整理はあなたの担当です」 ↓Cron ジョブ（毎日午前8時）: 「常設指示に従って受信トレイ整理を実行する」 ↓エージェント: 常設指示を読む → 手順を実行する → 結果を報告するCron ジョブのプロンプトでは、内容を重複させずに常設指示を参照してください。
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: コンテンツとソーシャルメディア（週次サイクル）
## プログラム: コンテンツとソーシャルメディア **権限:** コンテンツの下書き、投稿の予約、エンゲージメントレポートの作成**承認ゲート:** 最初の30日間はすべての投稿に所有者のレビューが必要。その後は常設承認とする**トリガー:** 週次サイクル（月曜日のレビュー → 週半ばの下書き → 金曜日の概要） ### 週次サイクル - **月曜日:** プラットフォームの指標とオーディエンスのエンゲージメントを確認する- **火曜日～木曜日:** ソーシャル投稿の下書きとブログコンテンツを作成する- **金曜日:** 週次マーケティング概要を作成する → 所有者へ配信する ### コンテンツルール - 文体はブランドに合わせる必要がある（SOUL.md またはブランドの文体ガイドを参照）- 公開コンテンツで自らを AI として示さない- 利用可能な場合は指標を含める- 自己宣伝ではなく、オーディエンスにとっての価値を重視する例2: 財務処理（イベントトリガー型）
## プログラム: 財務処理 **権限:** 取引データを処理し、レポートを生成して、要約を送信する**承認ゲート:** 分析には不要。提案には所有者の承認が必要。**トリガー:** 新しいデータファイルの検出、または予定された月次サイクル ### 新しいデータを受信した場合 1. 指定された入力ディレクトリで新しいファイルを検出する2. すべての取引を解析して分類する3. 予算目標と比較する4. 異常な項目、しきい値超過、新しい定期請求を報告する5. 指定された出力ディレクトリにレポートを生成する6. 設定済みのチャネルで所有者へ要約を配信する ### エスカレーションルール - 単一項目が > $500: 即時に警告する- カテゴリが予算を 20% 超過: レポートで報告する- 識別できない取引: 所有者に分類を確認する- 2回再試行しても処理に失敗: 失敗を報告し、推測しない例3: 監視とアラート（継続実行）
## プログラム: システム監視 **権限:** システムの正常性を確認し、サービスを再起動して、アラートを送信する**承認ゲート:** サービスは自動的に再起動する。再起動が2回失敗した場合はエスカレーションする。**トリガー:** Heartbeat サイクルごと ### 確認項目 - サービスのヘルスエンドポイントが応答している- ディスク空き容量がしきい値を上回っている- 保留中のタスクが古くなっていない（>24時間）- 配信チャネルが稼働している ### 対応マトリクス | 状態 | 操作 | エスカレーションするか || ---------------- | ------------------------ | ------------------------ || サービス停止 | 自動的に再起動 | 再起動が2回失敗した場合のみ || ディスク空き容量 < 10% | 所有者へ警告する | はい || 古いタスク > 24h | 所有者へ通知する | いいえ || チャネルがオフライン | 記録し、次のサイクルで再試行する | オフライン状態が > 2時間の場合 |実行・検証・報告パターン
常設指示は、厳格な実行規律と組み合わせると最も効果的です。常設指示内のすべてのタスクは、次のループに従う必要があります。
- 実行 - 実際の作業を行う（指示を確認するだけでは不十分）
- 検証 - 結果が正しいことを確認する（ファイルが存在する、メッセージが配信された、データが解析された）
- 報告 - 実行した内容と検証した内容を所有者へ伝える
### 実行ルール - すべてのタスクは実行・検証・報告に従う。例外は認めない。- 「対応します」は実行ではない。実行してから報告する。- 検証を伴わない「完了」は認められない。証明する。- 実行に失敗した場合: 方法を調整して1回再試行する。- それでも失敗する場合: 診断結果とともに失敗を報告する。暗黙のまま失敗させない。- 無期限に再試行しない。最大3回試行した後、エスカレーションする。このパターンにより、タスクを完了せずに確認応答だけを返すという、エージェントで最も一般的な失敗を防止できます。
複数プログラムのアーキテクチャ
複数の領域を管理するエージェントでは、常設指示を明確な境界を持つ個別のプログラムとして整理します。
## プログラム1: [領域A]（毎週） ... ## プログラム2: [領域B]（毎月 + オンデマンド） ... ## プログラム3: [領域C]（必要時） ... ## エスカレーションルール（すべてのプログラム） - [共通のエスカレーション基準]- [複数のプログラムに適用される承認ゲート]各プログラムには、以下が必要です。
- 固有のトリガー頻度（毎週、毎月、イベント駆動、継続実行）
- 固有の承認ゲート（プログラムによって必要な監督の度合いは異なります）
- 明確な境界（エージェントは、あるプログラムがどこで終了し、別のプログラムがどこから始まるかを把握する必要があります）
ベストプラクティス
推奨事項
- 限定的な権限から開始し、信頼の構築に応じて拡大する
- リスクの高い操作には明示的な承認ゲートを定義する
- 「実行してはならないこと」セクションを含める。境界は権限と同じくらい重要です
- 時間ベースの確実な実行のために Cron ジョブと組み合わせる
- 常設指示が遵守されていることを確認するため、エージェントのログを毎週確認する
- ニーズの変化に応じて常設指示を更新する。常設指示は継続的に更新される文書です
避けること
- 初日から広範な権限を付与する（「最善だと思うことを何でも実行する」）
- エスカレーションルールを省略する。すべてのプログラムに「いつ停止して確認を求めるか」という条項が必要です
- エージェントが口頭の指示を記憶していると想定する。すべてファイルに記述してください
- 複数の領域を1つのプログラムに混在させる。領域ごとに個別のプログラムを使用してください
- Cron ジョブによる強制を忘れる。トリガーのない常設指示は単なる提案になります
関連項目
- 自動化: すべての自動化メカニズムの概要。
- Cron ジョブ: 常設指示のスケジュールを強制します。
- フック: エージェントのライフサイクルイベントに対応するイベント駆動型スクリプト。
- Webhook: 受信 HTTP イベントのトリガー。
- エージェントワークスペース: 常設指示の配置場所と、自動挿入されるブートストラップファイル（
AGENTS.md、SOUL.mdなど）の完全な一覧。
