Skip to main content
Task Flow は、バックグラウンドタスクの上位に位置するオーケストレーションレイヤーです。フローは、独自のステータス、JSON 状態、リビジョンカウンター、リンクされたタスクレコードを持つ、複数ステップの作業を永続的に記録するものです。フローは Gateway の再起動後も維持されます。個々のタスクは、引き続き切り離された作業の単位です。

​
Task Flow を使用する場合

​
同期モード

​
管理モード

管理対象フローにはコントローラーがあります。これは、目標と必須のコントローラー ID を指定して Plugin ランタイムの Task Flow API からフローを作成し、その後フローを明示的に駆動する Plugin コードです。
  • 各ステップはフロー配下に作成されたバックグラウンドタスクとして実行され、フローの所有者キーとリクエスターのオリジンが子タスクに引き継がれます。
  • コントローラーはフローを running、waiting、終了状態の間で進行させ、任意の JSON ステップ状態をフローレコードに保存します。
  • すべての変更操作で、フローの期待リビジョンを渡します。古い書き込みは新しい状態を上書きせず、リビジョン競合として拒否されます。
  • キャンセルが要求されると、新しい子タスクは拒否され、アクティブな子タスクがなくなった時点でフローは cancelled として終了します。
例：（1）データを収集し、（2）レポートを生成し、（3）配信する週次レポートフロー。各ステップにつき 1 つのバックグラウンドタスクを使用します。

​
ミラーモード

切り離された ACP またはサブエージェントの実行が開始されると（配信可能な完了結果を持つセッションスコープのタスク）、OpenClaw はミラー化された単一タスクのフローを自動的に作成します。フローレコードは、単一の基盤タスクのステータス、目標、タイミングを反映します。これにより、切り離された起動はコントローラーなしでも、ステータス確認や再試行のための安定したフローハンドルを取得できます。ミラーフローの同期モードは CLI で task_mirrored と表示されます。

​
フローのステータス

​
永続的な状態とリビジョン追跡

フローレコードはタスクレコードとともに共有 SQLite 状態データベース（~/.openclaw/state/openclaw.sqlite、flow_runs テーブル）に永続化されるため、Gateway の再起動後も進行状況が維持されます。書き込みのたびにフローの revision が増加します。古い期待リビジョンを渡した同時書き込み処理では競合が発生し、再読み込みが必要です。WAL の増加は SQLite の自動チェックポイントと定期的なパッシブチェックポイントによって制限され、シャットダウン時には truncate チェックポイントが実行されます。以前のインストールで使用されていた従来の flows/registry.sqlite サイドカーは、openclaw doctor によってインポートされます。

​
キャンセル時の動作

openclaw tasks flow cancel はフローに永続的なキャンセル意図を設定し、アクティブな子タスクをキャンセルして、新しい管理対象の子タスクを拒否します。アクティブな子タスクがなくなると、フローは cancelled として終了します。これは即時に行われるか、子タスクの完了に時間がかかる場合はメンテナンススイープによって行われます。この意図は永続化されるため、すべての子タスクが終了する前に Gateway が再起動しても、キャンセルされたフローはキャンセル状態のままです。

​
CLI コマンド

フローは openclaw tasks audit（古い、または破損したフローの検出）と openclaw tasks maintenance（停止したキャンセル処理を完了し、7 日後に終了済みフローを削除）の対象にもなります。

​
信頼性の高いスケジュール済みワークフローのパターン

市場情報ブリーフィングなどの定期的なワークフローでは、スケジュール、オーケストレーション、信頼性チェックを別々のレイヤーとして扱います。
  1. タイミングにはスケジュール済みタスクを使用します。
  2. ワークフローで以前のコンテキストを引き継ぐ必要がある場合は、永続的な Cron セッションを使用します。
  3. 決定論的なステップ、承認ゲート、再開トークンには Lobster を使用します。
  4. 子タスク、待機、再試行、Gateway の再起動にまたがる複数ステップの実行を追跡するには、Task Flow を使用します。
Cron の構成例：
定期的なワークフローで意図的な履歴、前回実行の概要、または継続的なコンテキストが必要な場合は、isolated ではなく --session session:<id> を使用します。実行ごとに新しく開始し、必要なすべての状態がワークフロー内で明示されている場合は、isolated を使用します。 ワークフロー内では、LLM の要約ステップより前に信頼性チェックを配置します。
推奨される事前チェック：
  • ブラウザの可用性とプロファイルの選択。たとえば、管理対象の状態には openclaw、サインイン済みの Chrome セッションが必要な場合は user を使用します。ブラウザを参照してください。
  • 各ソースの API 認証情報とクォータ。
  • 必要なエンドポイントへのネットワーク接続性。
  • lobster、browser、llm-task など、エージェントで必要なツールが有効になっていること。
  • 事前チェックの失敗が確認できるように、Cron の失敗通知先が設定されていること。スケジュール済みタスクを参照してください。
収集する各項目に推奨されるデータ来歴フィールド：
要約前に、ワークフローで古い項目を拒否するか、古いものとしてマークします。LLM ステップには構造化 JSON のみを渡し、出力内で sourceUrl、retrievedAt、asOf を保持するよう指示します。ワークフロー内でスキーマ検証済みのモデルステップが必要な場合は、LLM タスクを使用します。 再利用可能なチームまたはコミュニティ向けワークフローでは、CLI、.lobster ファイル、セットアップノートを Skills または Plugin としてパッケージ化し、ClawHubで公開します。Plugin API に必要な汎用機能が不足している場合を除き、ワークフロー固有のガードレールはそのパッケージ内に保持します。

​
フローとタスクの関係

フローはタスクを置き換えるのではなく、調整します。1 つのフローは、その存続期間中に複数のバックグラウンドタスクを駆動できます。個々のタスクレコードを調査するには openclaw tasks、オーケストレーションを行うフローを調査するには openclaw tasks flow を使用します。

​
関連項目