> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 常時指示

常設指示は、定義済みプログラムに対する**永続的な運用権限**をエージェントに付与します。タスクごとにエージェントへ指示する代わりに、明確なスコープ、トリガー、エスカレーションルールを持つプログラムを定義し、エージェントはその境界内で自律的に実行します。「週次レポートはあなたの担当です。毎週金曜日に作成して送信し、何か異常に見える場合だけエスカレーションしてください。」

## 常設指示が必要な理由

**常設指示がない場合:** すべてのタスクでエージェントに指示する必要があり、定型作業は忘れられたり遅れたりし、あなた自身がボトルネックになります。

**常設指示がある場合:** エージェントは定義された境界内で自律的に実行し、定型作業はスケジュール通りに行われ、あなたが関与するのは例外と承認だけになります。

## 仕組み

常設指示は、[エージェントワークスペース](/ja-JP/concepts/agent-workspace)ファイルで定義されます。推奨される方法は、エージェントが常にコンテキスト内に保持できるように、`AGENTS.md`（各セッションで自動注入されます）へ直接含めることです。より大規模な設定では、`standing-orders.md` のような専用ファイルに配置し、`AGENTS.md` から参照することもできます。

各プログラムは次を指定します。

1. **スコープ** - エージェントに許可されていること
2. **トリガー** - 実行するタイミング（スケジュール、イベント、または条件）
3. **承認ゲート** - 実行前に人間の承認が必要なもの
4. **エスカレーションルール** - 停止して助けを求めるタイミング

エージェントは、ワークスペースのブートストラップファイルを通じて各セッションでこれらの指示を読み込み（自動注入されるファイルの完全なリストは[エージェントワークスペース](/ja-JP/concepts/agent-workspace)を参照）、時間ベースの強制には[Cron ジョブ](/ja-JP/automation/cron-jobs)と組み合わせて実行します。

<Tip>
  各セッションで確実に読み込まれるように、常設指示は `AGENTS.md` に入れてください。ワークスペースのブートストラップは `AGENTS.md`、`SOUL.md`、`TOOLS.md`、`IDENTITY.md`、`USER.md`、`HEARTBEAT.md`、`BOOTSTRAP.md`、`MEMORY.md` を自動注入しますが、サブディレクトリ内の任意のファイルは対象外です。
</Tip>

## 常設指示の構成

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## Program: Weekly Status Report

**Authority:** Compile data, generate report, deliver to stakeholders
**Trigger:** Every Friday at 4 PM (enforced via cron job)
**Approval gate:** None for standard reports. Flag anomalies for human review.
**Escalation:** If data source is unavailable or metrics look unusual (>2σ from norm)

### Execution steps

1. Pull metrics from configured sources
2. Compare to prior week and targets
3. Generate report in Reports/weekly/YYYY-MM-DD.md
4. Deliver summary via configured channel
5. Log completion to Agent/Logs/

### What NOT to do

- Do not send reports to external parties
- Do not modify source data
- Do not skip delivery if metrics look bad - report accurately
```

## 常設指示と Cron ジョブ

常設指示は、エージェントに許可されている**内容**を定義します。[Cron ジョブ](/ja-JP/automation/cron-jobs)は、それが発生する**タイミング**を定義します。これらは連携して動作します。

```text theme={"theme":{"light":"min-light","dark":"min-dark"}}
Standing Order: "You own the daily inbox triage"
    ↓
Cron Job (8 AM daily): "Execute inbox triage per standing orders"
    ↓
Agent: Reads standing orders → executes steps → reports results
```

Cron ジョブのプロンプトは、内容を重複して書くのではなく、常設指示を参照する必要があります。

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
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 "Execute daily inbox triage per standing orders. Check mail for new alerts. Parse, categorize, and persist each item. Report summary to owner. Escalate unknowns."
```

## 例

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

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## Program: Content & Social Media

**Authority:** Draft content, schedule posts, compile engagement reports
**Approval gate:** All posts require owner review for first 30 days, then standing approval
**Trigger:** Weekly cycle (Monday review → mid-week drafts → Friday brief)

### Weekly cycle

- **Monday:** Review platform metrics and audience engagement
- **Tuesday-Thursday:** Draft social posts, create blog content
- **Friday:** Compile weekly marketing brief → deliver to owner

### Content rules

- Voice must match the brand (see SOUL.md or brand voice guide)
- Never identify as AI in public-facing content
- Include metrics when available
- Focus on value to audience, not self-promotion
```

### 例 2: 財務オペレーション（イベントトリガー）

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## Program: Financial Processing

**Authority:** Process transaction data, generate reports, send summaries
**Approval gate:** None for analysis. Recommendations require owner approval.
**Trigger:** New data file detected OR scheduled monthly cycle

### When new data arrives

1. Detect new file in designated input directory
2. Parse and categorize all transactions
3. Compare against budget targets
4. Flag: unusual items, threshold breaches, new recurring charges
5. Generate report in designated output directory
6. Deliver summary to owner via configured channel

### Escalation rules

- Single item > $500: immediate alert
- Category > budget by 20%: flag in report
- Unrecognizable transaction: ask owner for categorization
- Failed processing after 2 retries: report failure, do not guess
```

### 例 3: 監視とアラート（継続）

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## Program: System Monitoring

**Authority:** Check system health, restart services, send alerts
**Approval gate:** Restart services automatically. Escalate if restart fails twice.
**Trigger:** Every heartbeat cycle

### Checks

- Service health endpoints responding
- Disk space above threshold
- Pending tasks not stale (>24 hours)
- Delivery channels operational

### Response matrix

| Condition        | Action                   | Escalate?                |
| ---------------- | ------------------------ | ------------------------ |
| Service down     | Restart automatically    | Only if restart fails 2x |
| Disk space < 10% | Alert owner              | Yes                      |
| Stale task > 24h | Remind owner             | No                       |
| Channel offline  | Log and retry next cycle | If offline > 2 hours     |
```

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

常設指示は、厳密な実行規律と組み合わせると最も効果的です。常設指示内のすべてのタスクは、このループに従う必要があります。

1. **実行** - 実際の作業を行う（指示を認識するだけではない）
2. **検証** - 結果が正しいことを確認する（ファイルが存在する、メッセージが配信された、データが解析された）
3. **報告** - 何を行い、何を検証したかをオーナーに伝える

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
### Execution rules

- Every task follows Execute-Verify-Report. No exceptions.
- "I'll do that" is not execution. Do it, then report.
- "Done" without verification is not acceptable. Prove it.
- If execution fails: retry once with adjusted approach.
- If still fails: report failure with diagnosis. Never silently fail.
- Never retry indefinitely - 3 attempts max, then escalate.
```

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

## 複数プログラムのアーキテクチャ

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

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## Program 1: [Domain A] (Weekly)

...

## Program 2: [Domain B] (Monthly + On-Demand)

...

## Program 3: [Domain C] (As-Needed)

...

## Escalation Rules (All Programs)

- [Common escalation criteria]
- [Approval gates that apply across programs]
```

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

* 独自の**トリガー頻度**（週次、月次、イベント駆動、継続）
* 独自の**承認ゲート**（より多くの監督を必要とするプログラムもあります）
* 明確な**境界**（エージェントは、あるプログラムがどこで終わり、別のプログラムがどこから始まるかを把握している必要があります）

## ベストプラクティス

### 推奨事項

* 狭い権限から始め、信頼が築かれるにつれて拡張する
* 高リスクなアクションには明示的な承認ゲートを定義する
* 「やってはいけないこと」セクションを含める - 権限と同じくらい境界も重要です
* 信頼性の高い時間ベースの実行には Cron ジョブと組み合わせる
* エージェントログを毎週確認し、常設指示が守られていることを検証する
* ニーズの変化に合わせて常設指示を更新する - それらは生きた文書です

### 避けること

* 初日に広範な権限を付与する（「最善だと思うことを何でもして」）
* エスカレーションルールを省略する - すべてのプログラムには「停止して尋ねるタイミング」の条項が必要です
* エージェントが口頭指示を覚えていると想定する - すべてをファイルに入れる
* 1つのプログラムに関心事を混在させる - 別々のドメインには別々のプログラムを用意する
* Cron ジョブで強制することを忘れる - トリガーのない常設指示は提案になります

## 関連

* [自動化](/ja-JP/automation): すべての自動化メカニズムの概要。
* [Cron ジョブ](/ja-JP/automation/cron-jobs): 常設指示のスケジュール強制。
* [フック](/ja-JP/automation/hooks): エージェントライフサイクルイベントのイベント駆動スクリプト。
* [Webhooks](/ja-JP/automation/cron-jobs#webhooks): 受信 HTTP イベントトリガー。
* [エージェントワークスペース](/ja-JP/concepts/agent-workspace): 常設指示が置かれる場所。自動注入されるブートストラップファイル（`AGENTS.md`、`SOUL.md` など）の完全なリストを含みます。