継続タスク、実行中の指示、タスクの停止

継続タスク（設定とコードでは responsibility）は、1 人の AI従業員が決められた期間、スケジュールまたは特定のイベントをきっかけに何度も起きて、同じ上限付きの仕事をする仕組みです。起きるたびに新しい goal タスクが 1 件作られます。ここではこれを「1 回の実行」（コードでは occurrence）と呼びます。1 回の実行には専用の期限、ラウンド上限、費用上限があり、通常の goal タスクと同じ流れで検収されます。実行と実行の間にはタスクが 1 件も存在しないので、待っている間は実行枠を使わず、モデルも呼び出しません。

同じ変更で、すべての goal タスクに使える操作が 2 つ加わりました。実行中のタスクに AI従業員への補足指示を渡すこと（ステアリング）と、タスクをサブタスクごと止めることです。

このリリースで使える画面と操作：

やりたいこと	場所
継続タスクの作成、変更、一時停止、再開、無効化、再有効化	コマンドライン `duduclaw responsibility …`。どの変更も管理者（Admin）がダッシュボードで承認する必要があります
継続タスク、実行記録、起床記録の確認	ダッシュボードの `/responsibilities` ページ、またはコマンドライン（確認系のコマンドは承認不要）
ダッシュボードでの作成、一時停止、再開、無効化、再有効化、連続失敗のリセット	`/responsibilities` ページ（その AI従業員への紐づけで使えるボタンが決まります）
実行中の goal タスクに指示を渡す	ダッシュボードのタスク詳細ページ
タスクとサブタスクを止める	タスク詳細ページ（即時に有効）、またはコマンドライン（承認が必要）

ダッシュボードの /responsibilities ページは下の「継続タスクページ」を参照してください。

スイッチと設定

2 つのスイッチはどちらも既定でオフです。~/.duduclaw/config.toml に書き、使うたびに読み直されるので、変更後にゲートウェイを再起動する必要はありません。

[responsibilities]
enabled = false                    # 継続タスクの全体スイッチ
max_stop_at_days = 30              # 終了日時を何日先まで設定できるか（1–90。90 を超える値は 90 として扱う）
event_poll_batch = 500             # 1 回の巡回で読むイベント数の上限（1–2000）
max_notifications_per_period = 10  # 予算期間ごとのプッシュ通知の上限。0 は通知しない
max_event_wakes_per_period = 12    # 予算期間ごとにイベントで起きられる回数の上限
operator_approval_minutes = 30     # コマンドラインの変更が承認後に適用できる時間（分、1–1440）

[goal_loop]
steering_enabled = false           # 実行中の指示のスイッチ

継続タスクはディスパッチエンジン（[dispatch] enabled、v1.59 から既定でオン）の上で動きます。エンジンがオフのときは作成が拒否され、既存の継続タスクも起きません。エンジンがオフの間はイベントの読み取り位置が進みません。そのため再びオンにしたとき、その期間のイベント（events.db が保持する最大 7 日分）は新しいイベントとして読まれ、継続タスクを起こすことがあります。
[responsibilities] セクションの形式が壊れていると、機能全体がオフとして扱われます。operator_approval_minutes が範囲外または読めないときは 30 を使います。
enabled を false に戻すと：新規作成も起床もしなくなり、AI従業員の 3 つのツールがツール一覧から消え、権限や費用を広げるコマンドライン操作は拒否されます。保存済みの記録は残ります。実行中の 1 回は通常の goal タスクとして最後まで進み、機能を再びオンにした後の巡回で精算されます。
steering_enabled がオフのときは新しい指示を送れません。すでに送って次のラウンドを待っている指示はそのまま渡されます。

1 回の実行はどこから来るか

起床のきっかけは 3 種類です。どれも「起きる時が来た」という記録を残すだけで、記録をタスクに変えるのはディスパッチエンジンの 30 秒ごとの巡回だけです。

スケジュール：cron 式とタイムゾーン。例：平日の朝 9 時。ゲートウェイ停止中に過ぎた時刻は、起動後に最大 1 回だけ補います（直近 24 時間で最も新しい時刻だけ）。まとめて何回も走ることはありません。
イベント：task.created と task.updated だけで、しかもこの AI従業員に属するイベント（内容の assigned_to が一致するもの）に限ります。これらのイベントは MCP のタスクツール（AI従業員のもの、または担当者の MCP キー）が書き込みます。ダッシュボードでの変更はイベントを書きません。activity.new を含む他のイベントを指定した契約は拒否されます。条件を付けられ、書き方は自動化ルールの条件と同じです。
判断：実行中の AI従業員が responsibility_ask で担当者に質問し、その回答が次の実行を起こします。

同時に開いている実行は 1 件だけです。前の実行が終わっていない間（人の対応待ちを含む）、新しい起床記録は待機し、終わった後に 1 回にまとめられます。2 回の実行の間は少なくとも min_wake_interval_secs 秒空き、ほかの goal タスクで実行枠が埋まっている間は作成しません。キューで待つ間に期限を消費しないためです。

イベントによる起床のルール

購読が有効になった後に起きたイベントだけを数えます。新しい購読、無効化してからの再有効化、機能のオフからオンへの切り替えのいずれでも、それ以前のイベントを新しいものとして扱うことはありません。
AI従業員が自分で起こしたイベントは自分の継続タスクを起こしません。自分のタスクツールで作成・更新したタスクと、自分の実行タスクの更新です。これらはデバッグ用に「見送った起床記録」として残ります。使い捨てヘルパー（spawn_agent）や同僚が作って AI従業員に割り当てたタスクは本人のイベントではなく、起床のきっかけになりえます。次の項目の予算期間ごとのイベント上限がその数を抑えます。
予算期間ごとにイベントで始まる実行は最大 max_event_wakes_per_period 回です。上限を超えた分はその期間内で破棄され、次の期間には持ち越しません。
イベントの内容はデータとしてだけ使われます。実行の説明に引用ブロックとして入り、プロンプトインジェクションの検査を受けます。担当者、期限、タグ、検収基準、予算、ツール権限はすべて継続タスク側から来ており、イベントでは変えられません。
イベントは events.db に 7 日間保存されます。ゲートウェイがそれより長く止まっていた場合、その間のイベントは失われ、アクティビティフィードに欠落の記録が残ります。
既知の制限：ゲートウェイの停止中に機能をオフにしてからオンに戻した場合、ゲートウェイはその切り替えを認識できず、購読の起点もリセットされません。

費用と回数の上限

継続タスクごとに次の上限を設定します。金額の単位は米セント（cents、monthly_budget_cents と同じ）です。

項目	意味
`occurrence_cost_cap_cents`	1 回の実行で使える上限。各ラウンドの前に確認し、超えたら人の対応に回します。費用はラウンド終了後に記録されるため、厳密な上限ではありません（下記参照）
`period_cost_limit_cents`	1 予算期間の上限（`budget_period`：`day`／`week`／`month`。`budget_timezone` の暦で区切る）
`period_occurrence_limit`	1 予算期間の実行回数の上限（1–96）
`occurrence_hours`	1 回の実行の最長時間（1–72 時間）。超えたら人の対応に回します
`max_consecutive_failures`	何回連続で失敗したら自動で一時停止するか（1–10、既定 3）
`stop_at`	継続タスク全体の終了日時。必須

数え方：

1 回の実行の費用には、その配下に記録されたタスク（サブタスクとその下のサブタスク）を含みます。AI従業員がその実行のいずれかのラウンド中に作ったタスクは、そのラウンドが扱っているタスクの配下にシステムが置きます。基準はシステムが把握しているラウンドで、モデルの要求は見ません。従業員が親を指定する場合は、そのタスクかそのサブタスクでなければ作成が拒否されます。システムが渡すラウンド情報が存在するのに空または不正な形式である場合、「ラウンドなし」とは扱わず、作成が拒否されます。1 つのタスクは最大 200 個の未完了のサブタスクを持て（完了したものは数えません。スケジュールとリマインダーはサブタスクではありません）、階層は最大 64 段です。
既定の親が当てはまるのは継続タスクのラウンド（その実行のタスク、またはその配下のタスクで、タスクボードから起床したサブタスクを含む）だけです。通常の goal タスクのラウンドや、どの実行にも属さないタスクのタスクボード起床には、既定の親はありません。このリリースでは、すべての呼び出し元に 2 つのルールが加わります。従業員が指定する親にはそのタスクとの関係が必要で（v1.69 は検査せずに書き込んでいました）、kind="goal" は親を受け付けます（v1.69 は無視していました）。
この配置は、従業員が自分の MCP サーバーの起動方法を変えられないことを前提にしています。従業員の .mcp.json の duduclaw エントリ（コマンド、引数、環境変数）を固定し、起動のたびにその環境を正規化することは別のプラットフォーム修正で、この機能より先にマージされる必要があります。それが出るまでは、そのエントリを書き換えた従業員は実行の外にタスクを作れます。
サブタスク自身のタスクボードからの起床（ハートビート）の費用はそのサブタスクに計上されるため、ぶら下がっている実行の費用に含まれます。
すべてがツリーに入るわけではありません。ラウンドを知らない MCP サーバー経由で作られたタスク（Bash から起動したもの、または MCP 設定が保存ファイルである Grok ランタイム）は、AI従業員がその実行を親として指定した場合だけ配下に入ります。他の AI従業員に任せた作業と使い捨てヘルパーもツリーに入りません（「費用に含まれないもの」を参照）。
上限は各ラウンドの前に、直前のラウンドの費用が記録された後で確認します。そのため進行中のラウンドや同時に動くサブタスクが、次の確認の前に実行を上限超過させることがあり、超過の幅はこの設定では制限されません。AI従業員自身の月予算（agent.toml [budget]）も各ラウンドの前に確認され、使い切っていれば実行は人の対応に回ります。
システムは、実行のラウンドを AI ランタイムに渡す直前に、そのラウンドが始まったことを記録します。この記録がないラウンドは費用がかかりません。ディスパッチゲートが取り消したもの、始まる前に拒否されたもの（たとえば委任チェックによる拒否）、キューで待っているもの（ゲートウェイの再起動をまたぐ場合も）です。そのため実行の一時停止と再開で上限を使い切ることはありません。この記録があるラウンドは、その後ランタイムが失敗した場合も、従業員がタスクを取得する前に失敗した場合も、ラウンドの途中でゲートウェイがクラッシュしてメッセージがキューに戻った場合も、実行されたものとして数えます。
実行されたが費用を測れなかったラウンドは、1 回あたりの上限をまるごと使ったものとして数えます。0 にはしません。トークン数がまったくない使用記録（報告しないランタイムがあります。下記）は測れなかったものとして扱います。費用データ自体が読めないときは起床せず、アクティビティフィードに記録します。
費用はすべてのランタイム（Claude、Codex、Antigravity、Grok、OpenAI 互換）で実行ごとに記録されます。Grok はトークン使用量を報告しないため、数値は送受信したテキストの長さからの推定です。使用量を報告しない Antigravity の実行、使用量イベントのない Codex の実行、および別のランタイムからのフェイルオーバーで到達した Claude のラウンド（0 を報告する）は、測れなかったものとして数えます。このようなランタイムが従業員のものであっても検収ジャッジ（[dispatch] judge_provider）のものであっても、測れなかった 1 ラウンドで 1 回あたりの上限をすべて使い切るため、実行は通常 1 ラウンドだけになり、そのラウンドが差し戻されると人の対応に回ります。継続タスクの作成時（コマンドラインと RPC）はこれが警告として表示され、duduclaw doctor はこのような継続タスクを一覧にします。
期間の予算を使い切ると「予算による一時停止」になり、次の期間に自動で再開します。その間にたまった起床記録は 1 回にまとめられます。
期限、ラウンド数、費用は再試行や再起動でリセットされません。1 日眠っても 1 日分の予算が増えることはありません。

費用に含まれないもの（duduclaw responsibility get の cost_not_counted に表示）：

人の対応に回すときに付ける軌跡シミュレーション
開始承認のプッシュ文面
ディスパッチ方針による担当者の選択
MCP サーバープロセス内の「取り消せない操作か」を判定するジャッジ
他の AI従業員に委任した作業
spawn_agent で起動した使い捨てヘルパー
ラウンド情報なしで作られ、実行の配下に置かれなかったタスク（上記参照）
tasks_create と schedule で作成した cron ルーチンとリマインダー

通知のスコアリング（「通知」を参照）は補助モデルを 1 回呼び出し、その費用はその実行に計上されます。

1 回の実行の終わり方

タスクの結果	記録	失敗として数えるか
検収合格	done	数えない。連続失敗はリセット
失敗、キャンセル	failed／cancelled	数える
AI従業員が `tasks_block` で止めた	blocked	数える。通知も送る
Manager 以上のロールがダッシュボードで停止、または Admin の承認を経たコマンドラインの停止	stopped	数えない
Operator 権限しかないアカウントがダッシュボードで停止	stopped	数える

最後の行は、AI従業員の担当者が、失敗しつつある実行を止めることで連続失敗による一時停止を逃れられないようにするためです。

人の対応待ち（needs_human）で止まっている実行は精算されず、ダッシュボードで誰かが対応するまで次の起床を止めたままにします。

期限を過ぎた実行は、その継続タスクが一時停止中でも期限切れでも人の対応に回り、その時点で枠は解放されます（期限までは、一時停止中や期限切れの実行も枠を保持します）。一時停止で実行が宙に浮くことはありません。担当 AI従業員が月予算を使い切った実行も、予算を理由として人の対応に回ります。

実行タスクはシステムが管理します。AI従業員もダッシュボードの通常のタスク編集も、担当者を変えたり、タイトル、説明、検収基準、タグ、期限などの制御項目を変更したりできません。状態と進捗の更新はこれまでどおりできます。AI従業員の未完了タスクを他の人へ引き継ぐ操作（退職時の引き継ぎ）では、実行タスクはその従業員に残ります。止めるには、それらのタスクを停止するか継続タスクを無効化してください。

コマンドライン

duduclaw responsibility list [--agent <従業員>]
duduclaw responsibility get <id>
duduclaw responsibility occurrences <id>
duduclaw responsibility fires <id>

duduclaw responsibility create --file contract.json [--confirm]
duduclaw responsibility update-contract <id> --file contract.json [--confirm]
duduclaw responsibility pause <id> [--reason <テキスト>] [--confirm]
duduclaw responsibility resume <id> [--confirm]
duduclaw responsibility disable <id> [--reason <テキスト>] [--confirm]
duduclaw responsibility enable <id> [--confirm]
duduclaw responsibility clear-failures <id> [--confirm]
duduclaw responsibility stop <task_id> [--confirm]

確認系を含むすべてのサブコマンドは、AI従業員のセッション内では拒否されます。

契約ファイルの例

{
  "owner_agent_id": "support-lead",
  "objective": "昨日から未返信のサポートチケットを確認し、私が対応すべき 3 件を挙げる。",
  "acceptance_template": "最大 3 件。各件にチケット番号と理由を 1 文。",
  "schedule": { "cron": "0 9 * * 1-5", "timezone": "Asia/Tokyo" },
  "event_subscriptions": [],
  "occurrence_hours": 2,
  "occurrence_cost_cap_cents": 50,
  "budget_period": "week",
  "budget_timezone": "Asia/Tokyo",
  "period_cost_limit_cents": 300,
  "period_occurrence_limit": 7,
  "min_wake_interval_secs": 3600,
  "max_consecutive_failures": 3,
  "stop_at": "2026-11-01T00:00:00Z",
  "notification_policy": { "enabled": true, "on": ["result", "needs_decision", "paused"] }
}

ルール：スケジュールとイベント購読の少なくとも一方が必要です。min_wake_interval_secs は 300 以上。period_cost_limit_cents は occurrence_cost_cap_cents 以上。stop_at は未来の日時で、max_stop_at_days 以内。イベント購読の timeout_at（任意）は現在から stop_at までの間で、その時刻までに該当イベントがなければ「起きなかった」ことを扱うために 1 回起きます。AI従業員が存在している必要があります。

イベント購読の書き方：

"event_subscriptions": [
  {
    "event_name": "task.updated",
    "filter": { "all": [ { "field": "status", "op": "eq", "value": "blocked" } ] },
    "timeout_at": "2026-10-20T00:00:00Z"
  }
]

filter を省くと、この AI従業員に属するその種類のイベントがすべて対象になります。

承認の流れ

コマンドラインでは、誰がコマンドを打ったかを証明できません。Bash を使える AI従業員は、あなたと同じ OS ユーザーで動いているからです。そのため、stop、pause、disable を含め、状態を変えるすべての操作は、管理者がダッシュボードで承認して初めて有効になります。

--confirm なしで実行：変更内容を表示するだけで、何も変えません。create と update-contract では、この段階で契約も検査されます（上限、スケジュール、AI従業員の存在）。不正な契約は、リクエストが作られる前に拒否されます。
--confirm 付きで実行：ダッシュボードの受信箱に承認リクエストを作ります。この種類のリクエストはダッシュボード上で管理者だけが判断でき、チャネルのボタンや返信は効きません。24 時間判断されなければ自動的に却下されます。
管理者が承認した後、operator_approval_minutes（既定 30 分）以内に、まったく同じコマンドを（--confirm 付きで）もう一度実行します。変更は 1 回だけ適用されます。

承認は、操作、対象、変更内容、対象の現在の状態に結び付けられます。状態が変わると古い承認は使えません。たとえば一時停止を承認した後、誰かが再開してまた一時停止した場合、最初の承認はもう効きません。その承認は監査記録とともに取り下げられます。同じ操作・同じ対象・同じ内容のリクエストは 1 件にまとめられます。1 つの対象への 1 つの操作で、未決の内容違いのリクエストは最大 3 件までで、4 件目はどれかが判断されるか期限切れになるまで拒否されます。1 つの対象へのプッシュ通知は 1 時間に最大 2 回で、それを超えたリクエストはダッシュボードの受信箱にだけ残り、監査記録が書かれます。これらのリクエストについてリマインドのプッシュは送られません。

v1.70.0 の次のリリースから、すでに変わった状態に対して出された待機中のリクエストは、同じコマンドをもう一度実行したときに取り下げられ（state_changed）、新しいリクエストが作られます。それ以降は 3 件の枠を使いませんが、再実行するまでは 24 時間後に期限切れになるまで枠に数えられます。状態が変わった承認済みリクエストも、再実行のときに同じく取り下げられます。2 つのターミナルが同じ承認済みコマンドを同時に再実行すると、適用するのは 1 つだけで、もう 1 つは承認がほかの実行で使われたか無効にされたと表示して何もしません。gateway が従業員プロセスに設定する環境変数が 1 つでもあれば（空でも）、このコマンドは拒否します。これらの規則はほかの運用者コマンドと共通です。コマンドラインからの運用者操作は 1 つの承認ゲートを共有するを参照してください。

stop もタスクの現在の状態に結び付けられます。実行中の goal タスクは状態がよく変わるため、承認済みのコマンドライン停止は、再実行するときには一致しなくなっていて、改めてリクエストが必要になることがよくあります。停止にはダッシュボードのボタンを使ってください。

承認カードはサーバーが作ります。AI従業員、操作、費用と回数の上限、スケジュールとイベントによる起床条件を表示します。継続タスクの作業内容は引用データとして表示し、80 文字に切り詰めます。他の人が書いた文章かもしれないからです。カードには「このリクエストはローカルのコマンドラインから作られ、誰が実行したかシステムでは確認できない」とも書かれます。誰が作ったか確信が持てなければ却下してください。

リクエスト、適用、拒否のたびにセキュリティ監査記録が 1 件書かれます：responsibility_cli_requested、responsibility_cli_applied、responsibility_cli_refused。

機能がオフのとき、権限や費用を広げる操作（create、update-contract、enable、resume、clear-failures）は即座に拒否されます。pause、disable、stop はリクエストできます。

3 つの操作の違い

操作	効果	影響しないもの
`pause` 一時停止	起床しなくなり、実行中の 1 回にも次のラウンドを出さない	すでに走っているラウンドは最後まで進み、提出済みの結果は通常どおり検収される。起床記録はたまり続け、`resume` 後に 1 回にまとめられる
`disable` 今後のスケジュールを無効化	すべての購読を取り消し、未処理の起床記録を破棄	実行中の 1 回（止めるにはそのタスクを別に停止）。`enable` は元の条件で購読し直し、無効化中に逃した分は補わない。`enable` は連続失敗の回数を保持します。失敗で一時停止された継続タスクは、有効化しても失敗による一時停止のままで、失敗をクリアしたときだけ回数がリセットされます（RPC は Manager 以上、コマンドラインは Admin の承認が必要）。承認済みの `update-contract` で、以後の実行に対する `max_consecutive_failures` を引き上げることはできます
`stop` タスクの停止	1 件のタスクとそのすべてのサブタスクを止める	継続タスク自体。時間が来ればまた起きる

すべて止めたいときは、先に disable、次に実行中の 1 回を停止します。

継続タスクページ

/responsibilities（ナビゲーション：仕事 → 継続タスク）は、あなたが紐づいている AI従業員の継続タスクを従業員ごとに一覧表示します。各行には状態、読み取り専用で実行するか、次回起動、今の予算期間の費用と上限、今期の回数と上限、連続失敗と上限、終了日が表示されます。データはすべて既存の RPC（responsibilities.list／.get／.occurrences）から取得し、サンプルデータは表示しません。

機能がオフのとき：responsibilities.status が 2 つのスイッチを返します。[responsibilities] enabled または [dispatch] enabled がオフなら、ページはそう明示して 2 つの設定キーを示します。既存の項目は一時停止と無効化だけできます（機能オフ中にサーバーが受け付けるのはこの 2 つの狭める操作だけです）。
操作：一時停止・再開・無効化・有効化には従業員に対する Operator が必要で、連続失敗のリセットには Manager 以上も必要です。呼び出しは画面に表示した control_epoch を送り、「その間に変更された」という応答なら再送せず一覧を更新します。詳細ダイアログには受け入れ基準、実行中の回（既存の停止ボタン付き）、直近 20 回の結果と費用が表示されます。
作成：テンプレートは 毎日のブリーフィング（読み取り専用）、毎週の振り返り（読み取り専用）、カスタム の 3 つ。読み取り専用テンプレートは常に lane = "explore" を付け、予算期間ごとに最大 1 回、1 回 1 時間、小さな上限（変更可）で動きます。カスタムは既定で読み取り専用で、チェックを外せます。値はすべてコマンドラインと同じ規則でサーバーが検証します。

読み取り専用の実行（`lane = "explore"`）

継続タスクの契約には "lane": "explore" を付けられます（RPC responsibilities.create／update_contract、コマンドラインの契約ファイル）。この値は契約の scope に保存されるので契約ハッシュに含まれます。付けていない継続タスクは以前とバイト単位で同じです。それ以外の値は拒否されます（invalid_lane）。

このような継続タスクの各実行の各ラウンドは、heartbeat の能動チェック用に作られた読み取り専用の explore lane で動きます。その実行のツリー内のタスクに対する後続の作業も同じです：サブ goal の各ラウンドと、実行の下にある任意のタスクへの heartbeat のタスクボード起床（ディスパッチャーは親タスクを最大 64 階層までたどり、そのタスクを含むいずれかの継続タスクの実行が読み取り専用なら explore lane を使います）。MCP Events の配信で起こされる作業も同じ lane を使います（MCP エコシステム）：ディスパッチャーは両方に同じ 1 つのフラグを立てるので、下の表はどちらにも同じく当てはまります。

ランタイム	動作
Claude CLI	起動時に `DUDUCLAW_LANE=explore`（継承した DuDuClaw MCP サーバーは `read`／`draft` ツールだけを一覧・実行）、`--tools` は `Read`、`Glob`、`Grep`、`WebFetch`、`WebSearch`（`denied_tools` を除く）だけ、`--allowedTools` は DuDuClaw MCP ツールとそれらの組み込みツールだけ（従業員自身の許可リストより広くならず、`.mcp.json` の他のサーバーのツールは自動承認されません）。`.mcp.json` の他の stdio サーバーは制御付きプロキシを通り、`read` ツールだけを一覧します
OpenAI 互換ランタイム	組み込みツールなし。DuDuClaw MCP 子プロセスに `DUDUCLAW_LANE=explore` が渡ります。lane 内では `agent.toml [mcp.external]` のサーバーをマウントしません（制御するものがないため）。2026-10-20 以降、従業員の `.mcp.json` にあるその他のサーバーは制御付きの proxy 経由で `DUDUCLAW_LANE=explore` 付きでマウントされ、`read` ツールだけが一覧に出ます
MoA モデル、`inference_mode = "local"`	拒否（`explore_lane_unsupported`）。lane 内ではハイブリッドのローカル振り分けを使いません
Codex	従業員自身の権限レベルにかかわらず `-s read-only` と `approval_policy=never` で実行（書き込みとネットワークを遮断し、設定ファイルの許可リストを無視する OS レベルのサンドボックス）。DuDuClaw MCP サーバーは `DUDUCLAW_LANE=explore` 付きで登録し、2026-10-19 以降は従業員のサードパーティサーバーも制御付きの proxy 経由で同じ変数付きで登録します。Codex 0.156.1 は `-s read-only` ではすべての MCP 呼び出しを拒否するため、呼び出せるツールはありません（2026-09-24 に 0.156.1 で確認、今回は再実行していません）
Antigravity、Grok、汎用 CLI	拒否：そのラウンドはディスパッチ前に失敗し（`explore_lane_unsupported`）、フェイルオーバーで到達した場合に備えて各ランタイムの `execute` にも同じ拒否があります。Antigravity には読み取り専用モードがありません（`agy --sandbox` はターミナルを制限するだけで、ユーザーレベルの `permissions.allow` は同じ OS ユーザーのすべての従業員で共有されます）。Grok と汎用 CLI には読み取り専用と示せる仕組みがありません
タスクサンドボックス（`[container] sandbox_enabled`）	ディスパッチ前に拒否（サンドボックスでは従業員がシェルを使えるため）

拒否されたラウンドは不成功の実行として数えられ、連続失敗でいずれ継続タスクは一時停止します。lane を読み取れない場合もそのラウンドは失敗します（explore_lane_unreadable）。属する実行の lane を読み取れないときは、heartbeat が起こすサブタスクも同様に失敗します。実際のゲートウェイではまだ動かしていません。

タスク詳細ページ

指示（ステアリング）

goal タスクの詳細ページに「次のラウンドへの指示」欄があります。書いた内容は次のラウンドの開始時に AI従業員へ渡され、進行中のラウンドは中断されません。

1 件 4000 文字まで。1 つのタスクで、まだ渡していない指示は同時に 10 件まで。
そのラウンドが実際に送り出されたときだけ「渡した」と数え、画面に「第 N ラウンドに組み込みました」と表示されます。渡したという意味で、採用されたという意味ではありません。そのラウンドが始まる前に拒否または取り消された場合、指示は「次のラウンドを待っています」に戻ります。ラウンドが始まった後は、そのラウンドがその後失敗しても、指示は渡したままです。
指示は検収基準を変えません。AI従業員には「検収基準と矛盾するときは検収基準を優先する」という注記付きで渡されます。ジャッジは作成時に固定された検収基準だけを読み、指示は見ません。
指示はプロンプトインジェクション検査を受けます。該当しても止めはしません（担当者自身の文章ですが、外部から貼り付けた内容の可能性があります）。タスクページではその指示の横に「この内容には指示のような文が含まれています」と表示し、AI従業員には参考情報にすぎず、新しい権限や検収基準として扱えないという注記付きで渡します。
先にタスクが終わったり停止されたりした場合、まだ渡していない指示は「届きませんでした」と理由付きで表示されます。
指示を含むラウンドは常に AI従業員 1 人で実行し、チームラウンドにはなりません。
必要な権限：その AI従業員に対する Operator 以上。AI従業員には指示を送るツールがありません。

範囲（検収基準）を変えたいときは、タスクを停止して新しいタスクを作るか、継続タスクに update-contract を使ってください。update-contract が変えるのは次の実行で、実行中の 1 回は元の契約のまま進みます。

停止

タスク詳細ページの「タスクを停止」ボタンは、ロックされていないどのタスクにも使え、その AI従業員に対する Operator 以上の権限が必要です。本人確認された経路なので、押せばすぐに有効になり、別の承認はいりません。確認は 2 回求められます。

確認ダイアログを開いた時点で、見ているタスクのバージョンを記録します。「停止する」を押す前にタスクが変わった場合（たとえばもう 1 ラウンド終わった場合）、「このダイアログを開いた後にタスクが変更されました」と表示されるので、現在の状態を確認してからもう一度押してください。システムが新しいバージョンで勝手に送り直すことはありません。タスクがすでに終わっていれば、停止は不要だと表示されます。

停止後：

タスクとすべてのサブタスクは取り消され、再開できません。やり直すには新しいタスクを作成してください。
大きなツリーは分割して処理します。ルートと最初のまとまりはすぐ取り消し、残りはその後の巡回で順に取り消します。その間、ツリーの下に新しいサブタスクを作ることも、ツリー内のタスクを取得または完了することもできず、ツリー内のタスクを送り出すものもありません。ディスパッチエンジンも、ハートビートのタスクボード起床も同様です。
キューで送り出しを待っているラウンドは取り消され、キューで待っているメンバー向けのタスクボード起床も取り消され、これらのタスクに結び付いた未決の承認は無効になり、準備済みでまだ始まっていない外部操作は実行されません。
その実行がすでに送った委任は別のタスクなので、一緒には止まりません。

画面の表示：

状態	画面の文言	意味
`cancel_pending`	停止中：進行中の作業が終わり次第停止します。	まだ動いているものがある：すでに始まったラウンド、リース期限が切れていない取得、チームラウンド、実行中の外部操作。ラウンドを途中で中断する手段はないため、終わるのを待ちます。「再確認」で更新できます
`cancel_pending`（別の文言）	停止中：ここからは確認できないチーム作業がまだ動いている可能性があります。後で確認します。	このゲートウェイからはチームラウンドが動いているか分からないため、リースの上限まで待ってから判断します
`stopped`	停止しました	動いているものはもうありません
`stopped_uncertain`	停止しましたが、一部の作業や外部操作の結果を確認できません。ご自身で確認してください。	確認できないものがある：リースが切れたのに完了したラウンドの記録がない取得（実行前に取り消されたラウンドは完了に数えない）、結果不明の外部操作、スキャン上限を超える大きさのツリー

「停止中」も「停止しました」も、すでに送られた外部操作を取り消したという意味ではありません。外部操作の結果が不明なときは、相手のシステムで実際に完了したかを人が確認する必要があります。

AI従業員が使える 3 つのツール

機能がオンのとき、AI従業員のツール一覧に次の 3 つが現れます。詳しいルールは MCP ツールを参照してください。

responsibility_get：自分の継続タスクを確認する。
responsibility_followup：自分の実行中に、追加の起床を 1 回予約する。
responsibility_ask：自分の実行中に、担当者へ質問を 1 つする。回答は次の実行にデータとして渡され、権限は何も与えません。この質問の通知には継続タスクの名前とダッシュボードへのリンクだけが入り、ボタンはなく、リマインドも送られないため、実際にはダッシュボードの受信箱で回答します。別の経路で届いた回答（信頼済み送信者によるその依頼へのチャネル上の判断）も同じように扱われます。回答は 1 回の実行を起こすだけで、上限・状態・権限を変えず、ほかの保留中の承認も決めません。

AI従業員は継続タスクを作成、変更、再開、再有効化できず、上限を引き上げることもできません。

通知

結果が出たとき、判断が必要なとき、継続タスクが自動で一時停止または終了したとき、停止が「結果不明」で終わったときは、必ず先にアクティビティフィードへ記録します。プッシュ通知はさらに次の条件を順に満たす必要があり、1 つでも満たさなければ送りません。

継続タスクの notification_policy が有効で、その種類が on に含まれている（既定ではすべてオフ）。
AI従業員の agent.toml [proactive] enabled が true（既定でオフ）。
その予算期間のプッシュ回数が max_notifications_per_period 未満。この回数はゲートウェイが自分で記録し、AI従業員が投稿したアクティビティは数えません。
プロアクティブゲートのスコアリングを通過する。この手順は補助モデルを 1 回呼び出し、その実行の費用に計上されます。

プッシュの内容は継続タスクの名前、状態、ダッシュボードへのリンクだけで、結果の要約やイベントの内容は含みません。おやすみ時間帯は通知を遅らせますが、捨てはしません。

セキュリティモデルと既知の制限

コマンドラインの承認は減速帯です。Bash レーンの検査は、AI従業員と本人確認できない呼び出し元が duduclaw／duduclaw-pro の responsibility サブコマンド（確認系を含む）を実行するのを止めますが、見ているのはコマンドの文字列です。名前を変えた実行ファイルや変数で組み立てたコマンドは止められません。制限のない Bash を持つ AI従業員はコマンドラインの承認を回避でき、データベースを直接書き換えることさえできます。本当の分離は Bash を与えないこと、またはタスクサンドボックスです。
緊急時。ダッシュボードの「タスクを停止」ボタンは現在の実行をすぐ止めますが、継続タスクはスケジュールどおり起き続けます。ダッシュボードには継続タスクを一時停止または無効化するページがありません。起きないようにするには、duduclaw responsibility disable を実行して管理者の承認を待つか、config.toml で [responsibilities] enabled = false にします（ダッシュボードで扱えるのは生の設定エディタだけです）。スイッチをオフにしても、すでに進行中の実行は通常の goal タスクとして最後まで進むため、そちらもボタンで止めてください。コマンドラインの stop は承認を待ちます。
コマンドラインからの停止は、コマンドラインのプロセス内で検査されるため、ゲートウェイがちょうど始めたチームラウンドは見えません。通常の goal タスク（実行タスクは常に 1 人で動くので対象外）には狭い時間帯があり、コマンドラインが stopped と報告しても、そのチームラウンドが最後まで動き続けることがあります。
継続タスクの実行と、指示を含むラウンドは常に AI従業員 1 人で実行し、チームラウンドにはなりません。
「費用に含まれないもの」に挙げた補助モデル呼び出しは費用に含まれません。1 回あたりの上限はラウンドの間に確認されるため、実行は最後のラウンドと並行するサブタスクが使った分だけ上限を超えることがあります。
継続タスクで絞り込めるのはイベントの発生源と通知先だけで、ツール権限は絞れません。実行で使えるツールは、その AI従業員がもともと持っているツールです。
イベントによる起床で見えるのは、MCP のタスクツールが events.db に書く task.created と task.updated だけで、長い停止の後は 7 日より古いイベントが失われます。
子タスク 200 件の上限は AI従業員の tasks_create だけで検査され、書き込む前に数えるため、同時の呼び出しではわずかに超えることがあります。ゲートウェイと担当者はこの上限の対象外です。
使用量を報告しないおそれのあるランタイムについての費用の警告は、コマンドラインと duduclaw doctor にだけ表示されます。ダッシュボードは responsibilities.create が返す usage_warnings を表示せず、外部判定（[dispatch] judge = "external"）も検査の対象外です。
同じデータディレクトリで複数のゲートウェイを起動した場合、<home>/locks/gateway.lock を保持している 1 つだけが、継続タスクの起床、停止の突き合わせ、指示のスイープ、途中まで進んだ永続ラウンドの修復を実行します。ほかのゲートウェイも goal ラウンドはこれまでどおりディスパッチします（永続ラウンドの固定メッセージ ID により二重送信されません）。
ある従業員のタスクボードを 3 回続けて読めなかった場合、その従業員のタスクボード起床が止まったことをアクティビティフィードに 1 件表示します（ゲートウェイのプロセスごとに 1 回）。失敗は毎回、警告としてもログに記録されます。
/responsibilities ページでは一覧、作成、一時停止／再開／無効化／有効化／連続失敗のリセットができます。契約の変更は引き続きコマンドラインです。

開発者向け

コード：crates/duduclaw-gateway/src/responsibility/（wake.rs、events.rs、cost.rs、stop.rs、steering.rs、operator_gate.rs、notify.rs）。テーブルは tasks.db にあります。
ダッシュボード RPC（handlers/responsibilities_rpc.rs）：responsibilities.status／create／list／get／occurrences／fires／update_contract／pause／resume／disable／enable／clear_failures、および tasks.steer／tasks.steering／tasks.stop／tasks.stop_status。読み取りには Viewer、変更には担当 AI従業員に対する Operator が必要です。ただし clear_failures は Manager が必要で、書き込みのたびに監査記録が 1 件追加されます。responsibilities.create は usage_warnings（使用量を報告しないおそれのあるランタイム）も返します。system.update_config は responsibilities.enabled と goal_loop.steering_enabled を受け付けます。
コマンドライン：crates/duduclaw-cli/src/responsibility_cmd.rs。承認の種類は responsibility_operator_change で、ダッシュボード上の Admin だけが判断できます（decided_by が dashboard: で始まる）。
Bash レーンでの遮断：共通の担当者コマンド照合（duduclaw_core::bash_operator_command_decision、GuardDecision::BlockedOperatorCommand）で、一覧は responsibility_cmd::OPERATOR_COMMANDS にあり、agent-file-guard フックで LINE 受信箱コマンドの後に連結されます。
継続タスク、指示、停止の各 RPC は、呼び出し元をアカウントストアから毎回読み直します（handlers/task_privacy.rs::live_reader_context）。tasks.steer／tasks.steering／tasks.stop／tasks.stop_status はさらにタスク内容ゲート（authorize_private_task_read：従業員へのアクセス権とタスクの対象者）を通ります。
このラウンドが実行されるタスクは、すべてのランタイムで DUDUCLAW_TASK_ID として MCP サーバーに渡されます（runtime::round_task_env）。承認カードも同じ値を使います。