ルーム内のエージェントに送信されたすべてのタスクは、R20260906-07のようなパブリックIDと、pending、approved、running、done、failed、cancelled、expiredのいずれかの状態を持つリクエストになります。このIDが存在することで、チャットスレッドにいる人、スマートフォンを使っている人、そして承認カードを見ているオーナーが、全員同じ対象について話せるようになります。再開（Resume）とは、中断が発生した後も同じIDのもとで、その同じリクエストを継続することを意味します。
これは地味な基盤作りに見えます。しかし、「エージェントが何かをしている」と「エージェントはSarahが依頼し、あなたが14:02に承認したR-07を実行中で、進捗は60%である」との決定的な違いを生み出すものでもあります。
ID
R + UTCの日付 + 日ごとのカウンター。スマートフォンから入力できるほど短く、リンクとして機能するのに十分な一意性を持っています。これはルーム内、監査ログ、チャットプラットフォームのスレッド、そして承認カードに表示されます。FeishuやSlackのコネクタを使用している場合、タスクのスレッドのタイトルにもこのIDが付けられます。Feishu向けの設計を参照してください。
状態
7つの状態と状態間の遷移。オレンジの破線は再開を表す。
オーナー自身のリクエストはpendingをスキップし、直接approvedになります。
Cancel、retry、resume
Cancelはdaemonがツール呼び出しの合間にチェックするフラグを設定します。実行中のリクエストは次の安全なポイントで停止し、キューに入っているものは削除されます。あるユーザーの権限またはマシンを取り消すと、それらにキューイングされていたすべてのリクエストがキャンセルされます。
Retryは、古いリクエストを参照する新しいIDを持った新規リクエストを作成します。ルームには両方が表示されるため、履歴の整合性が保たれます。
Resumeは異なります。実行中にマシンがスリープしたりdaemonが再起動したりしても、リクエストはそのIDとランタイムセッション参照を保持します。復帰時、daemonは最初からpromptを再実行するのではなく、同じセッションを継続します。タイムラインには重複ではなく中断期間が表示されます。これにより、夕方6時に閉じられるノートPCであっても、他のメンバーが頼りにするエージェントの実行環境として無理なく運用できるようになります。
エージェントごとのキューが直列である理由
各エージェントは1回に1つのリクエストを順番に処理します。2人が同じエージェントに同時にリクエストした場合、それぞれR-07とR-08が割り当てられ、R-08は待機します。同じマシン上の異なるエージェントは並行して実行されます。エージェント単位で直列処理を行うことで、作業ディレクトリの一貫性が保たれます。同じリポジトリに対して2つの編集が並行して走ると、誰も望んでいない状態に陥ってしまいます。
承認のTTL
誰も回答しなかった承認は（デフォルトでは24時間後に）期限切れとなり、誰も文脈を覚えていない1日後に突然実行されるのではなく、リクエストはexpiredになります。リクエスト送信者は再試行でき、オーナーは監査ログで期限切れを確認できます。監査ログに記録すべき内容を参照してください。
よくある質問
新しいリクエストから既存のリクエストを参照できますか？ はい。IDをメンションすると、エージェントはそのリクエストの結果をコンテキストとして取得します。メッセージや出力、リクエストを参照することで、フォローアップ時に前提条件を再度説明する手間を省くことができます。
実行中のリクエストがある状態でリクエスト送信者の権限を取り消すとどうなりますか？ 実行中のものは完了して履歴に残り、そのユーザーからキューに入っていたものはすべてキャンセルされます。実行途中で停止させると、完了させるよりもリポジトリが好ましくない状態に陥る可能性があるためです。
IDはグローバルですか、それともルームごとですか？
オーナーごと、日ごとです。2人のオーナーがそれぞれR20260906-01を持つことは可能ですが、ルーム内において曖昧さが生じることはありません。
再開はClaude CodeだけでなくCodexでも機能しますか？ どちらのランタイムもセッション参照を公開しており、daemonはそれをリクエストとともに保存して再開に使用します。
タスクに名前を付けることで、誰もが共通認識を持って話せるようになります。エージェントにルームを用意しましょう。
公開日