自動化
自動化は、指定した指示をスケジュールに従って実行し、その結果を通常のチャットセッションとして届けます。日次のニュースダイジェスト、週次レビュー、月次レポートなど、各実行はサーバー上でヘッドレスに処理され、チャット一覧に追加されます。ほかの会話と同じように開いて続きを行えます。
構成
自動化には、名前、自由記述の指示、1 つ以上のトリガー、任意のモデル（空欄の場合は Auto、つまり実行時点の既定チャットモデル）、実行対象、通知設定（アプリ内またはオフ）があります。実行対象によって生成されるものが決まります。チャットセッション（既定値）では、指示を会話としてキューに登録します。Work タスクでは、指示を最初のメッセージとして隔離された Work サンドボックスを起動し、フォームで選択した名前付き Work ポリシーを任意で適用できます。通知をオンにすると、失敗した実行は通知受信箱にも届くため、自動化ページを閉じていても失敗を確認できます。名前と指示は保存時に暗号化されます。各自動化は作成したユーザーに属します。
トリガーはカレンダーと共通のモデル（once、hourly、daily、weekly、monthly、yearly）を再利用し、1 つの自動化に最大 5 個設定できます。次回実行時刻は、すべてのトリガーのうち最も早く到来する時刻で、サーバーのローカルタイムゾーンを基準に計算されます。
実行
スケジューラーのティックは、調整用リースの背後で毎分実行されるため、スケジュールを進めるレプリカは常に 1 つだけです。自動化の実行時刻になると、ティックは実行を記録し、永続的な automation.run.v1 ジョブをキューに入れ、compare-and-set で next_run_at を進めます。これにより、各発生分は最大 1 回だけ実行されます。ジョブは自動化と同じ名前のチャットセッションを作成し、すべての会話で使われるものと同じ永続的なチャット生成パイプラインに指示を登録します。プロバイダーのルーティング、ペルソナの既定値、永続化も含まれます。
発生時刻にサーバーが停止していた場合、次のティックはその発生分を 1 回実行し、それより古い未実行枠はスキップします。自動化を一時停止するとスケジュールが消去され、再開または編集すると現在時刻を基準に再計算されます。自動化を削除すると、外部キーのカスケードによって実行履歴も削除されます。
実行結果は永続ジョブ台帳から確定します。チャット生成が完了すれば成功、いずれかのジョブがデッドレター化すれば失敗となります。また、キューに入った実行が 30 分以内に開始されなければ stalled として失敗します。
Work 対象の実行も同様ですが、チャットジョブの代わりに Work のライフサイクルを使います。実行レコードには作成したタスクが記録され（「実行」タブから直接開けます）、エージェントが完了するか入力を求めて停止すると成功し、タスクが失敗またはキャンセルされると失敗します。スケジュール発火時に Work へのアクセス権が検証されるため、ユーザーの Work アクセスを取り消すと、そのユーザーの Work 対象自動化も停止します。この場合は黙ってスキップせず、work-access-denied として失敗します。選択したポリシーは自動化の保存時に検証され、そのネットワーク既定値とリソース制限が、自動化から起動されるすべてのタスクに適用されます。Work では直接接続するモデルプロバイダーだけが利用でき、モデルはツールをサポートしている必要があります。これは Work コンポーザーと同じルールです。
エージェントルーチン
Work 対象の自動化は、代わりに workTaskId を介して既存の Work タスクへ関連付けることもできます。これはエージェントの詳細パネルにある「ルーチン」セクションの内部形式です。関連付けたルーチンは発火ごとに新しいタスクを作成しません。各発生分は、そのタスク自身のワークスペースと会話内で、タスクのモデル、プロバイダー、ランタイムポリシーを使って実行を開始します。そのため、自動化レベルのモデルとポリシーのフィールドは適用されず、指定されたポリシーは保存時に破棄されます。関連付けは自動化の保存時に検証されます（タスクが存在し、呼び出し元の所有物である必要があります）。発火時にタスクが削除済みなら実行は work-task-missing として失敗します。タスクがすでに実行中、またはライブプレビューを保持している場合は、後ろにキューイングせず、その発生分は work-task-busy として明示的に失敗します。
Webhook トリガー
スケジュールに加えて、自動化は外部システム（CI パイプライン、cron サービス、ホームオートメーションなど）から発火させることもできます。自動化の編集ダイアログで Webhook トリガー → 有効化 を選ぶと、その自動化専用のシークレットが生成されます。保存されるのは SHA-256 だけなので、平文は一度しか表示されません。シークレットをローテーションすると以前のものは直ちに無効になり、Webhook を無効化するとエンドポイントは再び閉じられます。
外部システムは次のようにして自動化を発火させます。
curl -X POST https://your-host/api/automations/<automationId>/webhook \
-H "Authorization: Bearer lwh_..."
（代替のヘッダーとして X-Libre-Webhook-Secret: lwh_... も使えます。）応答はキューに入った実行 ID を伴う 202 です。今すぐ実行と同じ手動実行の経路を通るため、実行の確定、通知、履歴への表示はまったく同じように行われます。シークレットの比較は定数時間で行われ、存在しない自動化と誤ったシークレットは同一の応答を返し（自動化 ID のオラクルになりません）、一時停止中の自動化は 409 を返します。所有者の「今すぐ実行」とは異なり、外部の呼び出し元は一時停止を越えて発火させることはできません。
API
Webhook による発火を除き、すべてのエンドポイントで認証が必要であり、呼び出し元自身の自動化だけを操作します。Webhook による発火は、代わりに自動化ごとのシークレットで認証します。
| メソッド | パス | 用途 |
|---|---|---|
GET | /api/automations | 自動化の一覧取得 |
POST | /api/automations | 自動化の作成 |
GET | /api/automations/occurrences?from=&to= | 計算済みの今後の発生時刻 |
GET | /api/automations/runs | 実行履歴（絞り込み可能） |
GET | /api/automations/runs/summary | 未確認件数と 30 日分のバケット |
POST | /api/automations/runs/seen | 完了済み実行を確認済みにする |
GET | /api/automations/:automationId | 1 件の自動化を取得 |
PUT | /api/automations/:automationId | 自動化を更新 |
DELETE | /api/automations/:automationId | 自動化を削除 |
POST | /api/automations/:automationId/pause | スケジュールを一時停止 |
POST | /api/automations/:automationId/resume | スケジュールを再開 |
POST | /api/automations/:automationId/run | 今すぐ実行（実行 ID を伴う 202） |
POST | /api/automations/:automationId/webhook | シークレットで発火（202） |
POST | /api/automations/:automationId/webhook-secret | シークレットの生成・ローテーション |
DELETE | /api/automations/:automationId/webhook-secret | Webhook を無効化 |
ユーザーは最大 50 件の自動化を保持できます。名前は 200 文字、指示は 20,000 文字までです。