Workboard Plugin

Workboard Plugin は、 Control UI にオプションのカンバン形式のボードを追加します。エージェント向けサイズの作業カード、エージェントへの割り当て、 およびカードのタスク、実行、ダッシュボードセッションへのリンクを提供します。

Workboard は意図的に小規模に設計されています。1 つの OpenClaw Gateway のローカル運用作業を追跡します。GitHub Issues、Linear、Jira、その他の チーム向けプロジェクト管理システムの代替ではありません。

有効化

Workboard は同梱されていますが、デフォルトでは無効です。

1. Control UI で Plugins を開くか、設定済みの Control UI ベースパスを基準とした /settings/plugins を使用します。 たとえば、ベースパスが /openclaw の場合は /openclaw/settings/plugins を使用します。
2. Workboard を見つけて Enable を選択します。Workboard は OpenClaw に同梱されているため、Install 操作は必要ありません。
3. UI に再起動が必要と表示された場合は、Gateway を再起動します。

Plugin ランタイムの読み込み後、ダッシュボードのナビゲーションに Workboard タブが表示されます。 無効な間は、このタブはナビゲーションに表示されません。Plugin が無効であるか、 plugins.allow/plugins.deny によってブロックされている状態で /workboard ルートを直接開くと、カードデータの代わりに Plugin を利用できない状態が表示されます。

同等の CLI ワークフローは次のとおりです。

openclaw plugins enable workboardopenclaw gateway restartopenclaw dashboard

設定

Workboard に Plugin 固有の設定はありません。標準の Plugin エントリを使用して有効化または無効化します。

{  plugins: {    entries: {      workboard: {        enabled: true,        config: {},      },    },  },}

openclaw plugins disable workboardopenclaw gateway restart

カードのフィールド

カードにはさらに、試行、コメント、リンク、証明、 成果物、自動化設定、添付ファイル、ワーカーログ、ワーカープロトコルの 状態、クレーム、診断、通知、テンプレート ID、アーカイブ状態、 古いセッションの検出に関するコンパクトなメタデータと、最近のイベント一覧（created、edited、 moved、linked、specified、decomposed、claimed、heartbeat、 execution_updated、attempt_started、attempt_updated、comment_added、 link_added、proof_added、artifact_added、attachment_added、 diagnostic、notification、dispatch、orchestration、 protocol_violation、archived、unarchived、stale）も含まれます。このメタデータにより、 オペレーターはリンクされたセッションを開かなくても、カードがボード内をどのように移動したかを確認できます。 これはローカルの運用コンテキストであり、セッションの トランスクリプトや GitHub Issue の履歴に代わるものではありません。

Plugin と Control UI は、単一の Workboard カードコントラクトを使用します。そのため、ダッシュボードを更新しても、 カードを UI 専用の小さなコピーに射影することなく、ワークスペースの出所と権限、 クレーム状態、診断アクション、通知シーケンス番号が維持されます。 未知の診断種別、診断の重大度、通知種別は、両方のサーフェスが対応するまで無視されます。 別の有効な状態へ書き換えられることはありません。

開いているダッシュボードは、plugin.workboard.changed の無効化イベントによって更新されます。各 イベントにはストアのエポックとリビジョンだけが含まれ、UI は通常の operator.read RPC を介して正規のカードを再読み込みします。複数のリビジョンは 後続の 1 回の読み込みにまとめられます。Workboard は、カードのドラッグ中、 編集中、または書き込み中はその読み込みを延期し、ローカル操作の完了後に再開します。 再接続時には、必ず正規データを再読み込みします。通常のカード全体の ポーリングは行われず、手動復旧手段として Refresh を引き続き利用できます。

複数のボードが存在する場合、ツールバーには、現在表示されているカードだけでなく 永続化されたボードメタデータに基づく Board フィルターが表示されます。そのため、空の ボードやアーカイブされたボードも引き続き選択できます。明示的な ボード ID がないカードは、正規の default ボードに属します。各ボードには、ブックマーク、共有、または サイドバーへの固定が可能な正規の /workboard/<boardId> ページがあります。以前にリリースされた /workboard?board=<boardId> 形式は 互換性エイリアスとして残り、ほかのクエリパラメーターを保持したままそのページへリダイレクトします。 All boards を選択すると /workboard に戻ります。

カードは Plugin 固有の Gateway 状態に保存され、その Gateway のほかの OpenClaw 状態とともに移動します（ストレージを参照）。

カードから作業を開始する

リンクされていないカードから直接作業を開始できます。

• Run Codex / Run Claude は、明示的なエンジンを指定してタスク追跡対象のエージェント実行を開始し、 カードのプロンプトを送信して、カードを running としてマークします。Codex の 実行では openai/gpt-5.6-sol、Claude の実行では anthropic/claude-sonnet-4-6 を使用します。
• Open Codex / Open Claude は、カードのプロンプトを送信せず、 カードを移動することもなく、リンクされたダッシュボードセッションを作成します。ボードに関連付けたまま 手動で作業する場合に使用します。

自律的な開始では、Gateway のタスク追跡対象エージェント実行パスを使用します（Codex/Claude を明示的に選択しない限り、 デフォルトのエージェントとモデルを使用します）。その後 Workboard は、生成された タスク、実行 ID、セッションキーをカードにリンクします。リンクされた各 実行では試行の概要（エンジン、モード、モデル、実行 ID、 タイムスタンプ、ステータス、連続失敗回数）も記録されるため、繰り返し発生する失敗を確認できます。

ダッシュボードは Gateway のタスク台帳からタスクのステータスを更新し、 タスク ID、実行 ID、またはリンクされたセッションキーによってタスクとカードを照合します。キュー待ちまたは実行中の タスクがある間、カードのライフサイクルはアクティブに保たれます。完了、失敗、タイムアウト、または キャンセルされたタスクは、リンクされたセッションと同じ同期 ルールに従ってカードを review または blocked に移行します（セッションライフサイクルの同期を参照）。

エージェントツール

証明ステータスはワーカーが報告した結果であり、独立した検証ではありません。passed エントリは、コマンドまたはチェックが成功したとワーカーが報告したことを意味します。独立した品質ゲートを 必要とする利用側は、添付されたコマンド、URL、または成果物を調査し、 独自の検証ツールを実行する必要があります。workboard_proof は新しいレコードの proofId を返します。 workboard_complete が同じ証明の最終ステータスを報告する場合は、proofId を渡すことで、 保留中のレコードが識別情報やタイムスタンプを失わずにその場で解決されます。すでに同じ 最終ステータスを持つ証明は、変更されずに再利用されます。proofId のない完了証明は 追記専用のままなので、後の再試行でコマンドやメモが同一であるというだけで古い履歴を 書き換えることはできません。

要求済みカードは、呼び出し元が workboard_claim から返された要求トークンを 保持していない限り、他のエージェントによるエージェントツールの変更を拒否します。 エージェントツールまたは Gateway RPC 呼び出しから返されるすべてのカードでは、 metadata.claim.token が [redacted] に秘匿化されます （トークン自体が返されるのは workboard_claim のトップレベルから一度だけです）。 これにより、ダッシュボード運用者や他のエージェントは、使用可能なトークンを見ることなく 要求状態を調査できます。復旧は workboard_promote/workboard_reassign/workboard_reclaim を介して行われ、 トークンは必要ありません。

ディスパッチ

ディスパッチは Gateway 内でローカルに行われ、任意の OS プロセスを生成することはありません。 実行は引き続き通常の OpenClaw サブエージェントセッションが担当します。1 回のディスパッチ処理では次を行います。

1. 依存関係の準備が整ったカードを昇格します。
2. 準備完了カードにディスパッチメタデータを記録します。
3. 期限切れの要求またはタイムアウトした実行をブロックします。
4. ボードで設定されたトリアージカードをオーケストレーション候補としてマークします。
5. 準備完了カードの小さなバッチを要求し、Gateway サブエージェントランタイムを通じて ワーカーの実行を開始します。

ワーカーには、範囲を制限したカードコンテキストと、Workboard ツールを通じて カードの Heartbeat、完了、またはブロックを行うために必要な要求トークンが渡されます。

ワークスペースパスは、呼び出し元が既に持つファイルシステム権限に従います。 operator.write を持つ Gateway クライアントは設定済みのエージェントワークスペースを使用でき、 operator.admin クライアントはホスト上の他のチェックアウトを使用できます。サンドボックス化されたエージェントツールは サンドボックスのワークスペースアクセスを使用し、サンドボックス化されていないワークスペース専用ツールは 設定済みのワークスペースルートを使用します。Workboard はワークスペースが割り当てられたときに その権限を記録し、ディスパッチ時に現在の呼び出し元の権限との積集合を再度取るため、 永続化されたカードによって後の呼び出し元のアクセス権が拡大することはありません。 明示的なホストワークスペースを持つものの権限が記録されていない古いカードでは、 フルホストディスパッチの前にそのワークスペースを再保存する必要があります。ホストパスを持たないカードは、 最初のディスパッチ時に現在の呼び出し元の権限を採用します。

ワークスペースに紐付けられたディスパッチがディレクトリまたは Git チェックアウトを受け入れるのは、 そのリポジトリルートが対象エージェントのワークスペースと完全に一致する場合だけです。 worktree の要求はそのディレクトリに限定され、ディレクトリワークスペースとして永続化されるため、 ホストがチェックアウトを実体化したり、リポジトリのセットアップコードを実行したりすることはありません。 対象ワーカーは、その正確なワークスペースに対して、書き込み可能で共有されていない Docker サンドボックスを 使用する必要があります。昇格された実行、永続化されたホスト／Node 実行オーバーライド、または 未分類の Plugin および MCP ツールは使用できません。Workboard は workboard_* プレフィックスを 信頼するのではなく、登録済みツールを列挙します。また、稼働中の Docker コンテナの ライブマウント／設定ハッシュが古い場合、ディスパッチを拒否します。ディスパッチは、 制約の弱いワーカーを起動する代わりに、互換性のない対象ポリシーを報告します。 フルホストディスパッチでは他のローカルチェックアウトを対象にでき、 通常の管理対象 worktree セットアップを維持します。

ワークスペース権限によって、カードのライフサイクルに関する第 2 の権限モデルが作られるわけではありません。 Workboard カードを変更できる呼び出し元は、すべてのサーフェスで同じステータス間を 手動で移動できます。読み取り専用のワークスペースアクセスが防ぐのは、 書き込みを必要とするワーカーディスパッチだけです。

ワーカーの選択

各パスでは、デフォルトで 最大 3 ワーカーが起動します。準備完了のカードは、 優先度、位置、作成時刻の順に並べられます。1 回のパスで起動されるカードは 所有者/エージェントごとに 1 件のみで、ボード上ですでに実行中またはレビュー中の 作業がある所有者はスキップされます。アーカイブ済みのカード、アクティブなクレームがあるカード、 および ready ステータスではないカードがワーカーの起動対象として選択されることはありません （ただし、ディスパッチのデータ処理側では、期限切れクレームのクリーンアップ、依存関係の昇格、 タイムアウトのクリーンアップによる影響を受ける場合があります）。

セッションキーはボード/カードごとに決定論的に生成されるため、ディスパッチを繰り返しても、 無関係なセッションを作成するのではなく、同じワーカーレーンにルーティングされます。

• 割り当て済みカード: agent:<agentId>:subagent:workboard-<boardId>-<cardId>
• 未割り当てカード: subagent:workboard-<boardId>-<cardId>（Gateway が 設定済みのデフォルトエージェントを解決）

カードがクレームされた後にワーカーを起動できない場合、Workboard はその カードをブロックし、クレームを解除し、実行開始の失敗を記録して、ワーカーの ログ行を追加します。このログはダッシュボード、CLI JSON、エージェントツール、 カード診断に表示されます。

エントリーポイント

• ダッシュボードのディスパッチアクション
• openclaw workboard dispatch
• コマンド対応チャネル上の /workboard dispatch

3 つすべてで、Gateway が利用可能な場合は Gateway のサブエージェントランタイムが使用されます。 CLI にはオペレーター向けのフォールバックが 1 つあります。Gateway 呼び出しが 接続/利用不可エラー（または古い Gateway では unknown method エラー）で失敗し、 明示的な --url/--token ターゲットが指定されておらず、設定済みのリモート Gateway（OPENCLAW_GATEWAY_URL または gateway.mode: remote）も適用されない場合、CLI は ローカルの SQLite 状態に対してデータのみのディスパッチを実行します。依存関係の昇格、 期限切れクレームのクリーンアップ、タイムアウトした実行のブロックは可能ですが、 ワーカーは起動できません。到達可能な Gateway から返された認証、権限、検証の失敗は 利用不可とは見なされず、コマンドエラーとして表示されます。明示的な --url/--token ターゲットが指定されている場合も、Gateway のあらゆる 失敗がコマンドエラーとして表示されます。

ボードのメタデータでは autoDecompose、autoDecomposePerDispatch、 defaultAssignee、orchestratorProfile を設定できます。OpenClaw はこの意図を記録し、 ワーカーコンテキストで公開します。実際の仕様策定/分解は引き続き 通常の Workboard ツールを通じて実行されます。

CLI とスラッシュコマンド

openclaw workboard list [--board <id>] [--status <status>] [--include-archived] [--json]openclaw workboard create "Fix stale card lifecycle" --priority high --labels bug,workboardopenclaw workboard show <card-id> [--json]openclaw workboard move <card-id> --status <status> [--json]openclaw workboard dispatch [--board <id>] [--json]

list のテキスト出力では、デフォルトでアーカイブ済みカードが非表示になります （--include-archived で上書き可能）。--json には常にアーカイブ済みカードが含まれ、 既存スクリプトが使用する全カード契約と一致します。show と move は、曖昧さのない ID プレフィックスを受け付けます。 list、create、show、move は、 常にローカルの Plugin 状態を直接読み書きします。実行中の Gateway を呼び出すのは dispatch のみで、前述のフォールバックが適用されます。

すべてのフラグ、JSON 出力、Gateway のフォールバック動作、ID プレフィックスの処理、 ディスパッチの選択ルール、トラブルシューティングについては、 Workboard CLI を参照してください。

/workboard list、/workboard show <card-id>、/workboard create <title>、 /workboard move <card-id> --status <status>、/workboard dispatch は CLI と同じ機能を提供します。リスト表示と詳細表示は、認可されたすべてのコマンド送信者が 実行できる読み取り操作です。作成、移動、ディスパッチには、チャットサーフェス上での 所有者ステータス、または operator.write/operator.admin を持つ Gateway クライアントが必要です。オペレーターによる手動移動には、ダッシュボードの ドラッグ＆ドロップと同じクレーム上書き動作が適用されます。ワークツリーへのアクセスも、 前述と同じワークスペース境界に従います。

セッションライフサイクルの同期

カードは、既存のダッシュボードセッション、またはカードから作業を開始したときに 作成されたセッションにリンクできます。リンクされたカードには、実行中、期限切れ、 リンク済みアイドル、完了、失敗、欠落というセッションライフサイクルがインライン表示されます。 Sessions タブで既存のセッションを選択し、Workboard に追加を使用して取り込むこともできます。 カードはそのセッションにリンクされ、セッションラベルまたは直近のユーザープロンプトを タイトルとして使用し、利用可能な場合は直近のユーザープロンプトと最新のアシスタント応答から メモを初期設定します。

リンクされたセッションが見つからなくなっても、カードはコンテキストのためにリンクを維持し、 新しいセッションで再開するための開始コントロールを引き続き表示します。アクティブな リンク済みセッションから最近のアクティビティが報告されなくなると、Workboard はカードを stale としてマークし、ライフサイクルによって解除されるまで、その状態を メタデータとして保存します。

カードがアクティブな作業状態にある間、Workboard はリンクされたセッションに追従します。

手動のレビューステータスが優先されます。 カードを review、 blocked、または done に移動すると、そのカードを todo または running に戻すまで自動同期が停止します。

カードの開始には通常の Gateway セッションが使用されます。Workboard が保存するのは カードのメタデータとリンクのみです。会話のトランスクリプト、モデル選択、実行ライフサイクルは、 通常のセッションシステムが引き続き所有します。ライブのリンク済みカードで 停止を使用すると、 アクティブな実行が中止されます。Workboard はそのカードを blocked として マークし、フォローアップのために表示を維持します。

新しいカードは Workboard テンプレート（bugfix、docs、 release、pr_review、plugin）から開始できます。 テンプレートによってタイトル、メモ、ラベル、優先度が事前入力され、 テンプレート ID はカードのメタデータとして保存されます。

ダッシュボードのワークフロー

1. Control UI で Workboard タブを開きます。
2. タイトル、メモ、優先度、ラベル、任意のエージェント、任意のリンク済みセッションを 指定してカードを作成します。または Sessions を開き、既存のセッションで Workboard に追加を選択します。
3. カードを列間でドラッグするか、コンパクトなステータスコントロールにフォーカスして、 メニューまたは ArrowLeft/ArrowRight を使用します。ドラッグ中は元のカードが薄く表示され、 ドロップ可能な列に枠線が表示されます。
4. カードから作業を開始し、ダッシュボードセッションを作成または再利用します。
5. エージェントが作業している間、カードからリンク済みセッションを開きます。
6. ライフサイクル同期によって実行中の作業を review/blocked に移動させ、承認後にカードを手動で done に移動します。

セッションボードウィジェット

Workboard には、セッションダッシュボード用のネイティブウィジェットが 2 つ付属しています （ダッシュボードを参照）。エージェントは dashboard ツールで content: { kind: "plugin", pluginKind, props } を使用してこれらを固定します。これらはライブデータを使用する ファーストパーティ UI としてレンダリングされ、サンドボックスフレームやケイパビリティの 付与は不要です。

• props: { cardId } を指定した workboard:card は、 ステータスコントロール、優先度、割り当て済みエージェントを含む 1 件のカードを表示します。
• 任意の props: { boardId, limit } を指定した workboard:mini は、 ステータスごとの件数と、上位の準備完了/実行中カードを表示し、ボードの完全なページへ リンクします。boardId を指定しない場合はすべてのボードを集約し、 boardId を指定した場合はそのボードに限定します （明示的なボード ID なしで作成されたカードは default に属します）。

診断

診断はローカルのカードメタデータから算出されます。組み込みチェックでは次の状態が検出されます。

権限

Gateway RPC メソッドは workboard.* 配下にあります。

operator.admin を必要とする RPC メソッドはありません。読み取り専用の オペレーターアクセスで接続されたブラウザーはボードを確認できますが、 カードを変更することはできません。管理者スコープを使用すると受け入れ可能な Workboard ホストパスが拡張されますが、利用可能なメソッドは変わりません。

ストレージ

Workboard は、OpenClaw の状態ディレクトリ配下にある Plugin 所有のリレーショナル SQLite データベースに永続データを保存します。ボード、カード、ラベル、ライフサイクルイベント、 実行試行、コメント、依存関係リンク、証明、成果物参照、添付ファイルのメタデータと BLOB、 診断、通知、ワーカーログ、プロトコル状態、購読はすべて Workboard のテーブルに保存されます （Plugin のキー値エントリには保存されません）。カードのエクスポートでは、 添付ファイルの BLOB 内容をインライン化せずに、ボードの経緯が保持されます。

.28 リリースで Workboard を使用していたインストール環境では、 openclaw doctor --fix を実行して、出荷済みの旧 Plugin 状態名前空間 （workboard.cards、workboard.boards、workboard.notify、および存在する場合は workboard.attachments）をリレーショナルデータベースに移行できます。

トラブルシューティング

タブに Workboard を利用できないと表示される

openclaw plugins inspect workboard --runtime --json

plugins.allow が設定されている場合は、そこに workboard を追加します。 plugins.deny に workboard が含まれている場合は、Plugin を有効にする前に 削除してください。

カードを保存できない

ブラウザー接続に operator.write アクセスがあることを確認してください。 読み取り専用のオペレーターセッションではカードを一覧表示できますが、 作成、編集、移動、削除はできません。

カードを開始しても想定したセッションが開かない

カードのエージェント ID とリンク済みセッションを確認し、Sessions または Chat を開いて、 実際の実行状態を確認してください。

ディスパッチしてもワーカーが起動しない

アクティブなクレームがない ready カードが少なくとも 1 件あることを確認してください。

openclaw workboard list --status ready

CLI がデータのみのディスパッチを報告した場合は、Gateway を起動または再起動してから 再試行してください。データのみのディスパッチではローカルのボード状態は更新されますが、 サブエージェントのワーカー実行は開始できません。同じ所有者またはエージェントの別のカードが すでに実行中またはレビュー待ちの場合も、カードがスキップされることがあります。同じ 所有者に対してさらにディスパッチする前に、その進行中の作業を完了、ブロック、または解放してください。

関連項目

• コントロール UI
• ワークボード CLI
• Plugin
• Plugin の管理
• セッション