monitor-and-review-ai-employee-work

AI 従業員の作業を監視・確認する

タスクの状況を確認し、従業員が作成したものを人間が承認または却下できるようにし、組織の従業員が行っていた作業を読み取ります。Slack で承認することもできます。どちらの方法でも、同じ判断として処理されます。

前提条件：まず operate-ai-employees を読み込んでください。これにより、dozaldevs CLI とキーが設定され、エラーの読み方も確認できます。また、task_id（従業員を実行したときに取得したもの）も必要です。読み取りはどのキー権限レベルでも可能ですが、承認または却下には Member 以上の権限が必要です。

すべてのコマンドで使用できる引数とフィールド：dozaldevs <command> --help および ../operate-ai-employees/references/customer-api.md。以下では、仕様からは読み取れない動作のみ説明します。

状況を確認する：1 回の呼び出しで phase_category を確認

dozaldevs get-task "$TASK"

phase_category に基づいて分岐し、生の status は無視してください。

phase_category	意味	人間への伝え方
working	まだ実行中	「まだ処理中です。1、2 分ほど待ってから、もう一度聞いてください。」
awaiting_human	作業完了、承認待ち	出力（下記）を表示し、承認または却下を促します。
terminal	完了（Done）または停止（Failed、Cancelled）	Done：出力を表示し、配信されたことを伝えます。それ以外の場合は、その旨と理由を説明します。

すでに誰かが承認または却下したタスクは、生の status がまだ Reviewing でも working と表示されます。awaiting_human は、まだ誰も判断していないことを意味します。誰かが判断するまでは decision は null で、判断後は誰がどちらを選んだかが示されるため、設定されている場合は承認または却下を促さないでください。output.draft を表示し、ドラフトがない場合は output.summary を表示します。

待機する：人間が待つように伝えた場合のみ

デフォルトでは上記の呼び出しを 1 回だけ行って、そのまま進めてください。人間から結果を待つように求められた場合は、次を実行します。タスクが working の間は 10 秒ごとに再読み込みし、約 80 秒で停止して、最後の phase_category を出力します。

dozaldevs get-task "$TASK" --while phase_category=working --every 10 --timeout 80 --field phase_category

working と出力された場合は、もう一度実行してください。それ以外の場合は、表に戻ってください。呼び出しに失敗した場合は、エラーが出力されます。その next_step に従ってください。ストリームは開かないでください（stream-* コマンドはサーバーが閉じるまで開いたままになります）。

承認または却下する（awaiting_human の場合）

ドラフトを提示し、人間の判断に従って操作します。承認する場合：

dozaldevs decide-task "$TASK" --data action=approve

人間の理由を $REASON に指定して却下する場合：

dozaldevs decide-task "$TASK" --data action=reject --data reason="$REASON"

• 202：記録されました。承認すると配信されます（たとえば Slack に投稿されます）。「承認しました。今、送信しています。」
• 409 TASK_NOT_AWAITING_REVIEW：状況を再確認してください。まだ処理中か、すでに完了している可能性があります。
• 409 TASK_ALREADY_DECIDED：先に誰かが判断しています。message に誰がどちらを選んだかが示されるため、人間に伝えてください。同じ判断を 2 回送信すると、再び 202 が返されます。

却下するときは、必ず reason を指定してください。従業員がそのフィードバックから学習するためです。人間に代わって判断してはいけません。また、出力に問題がないように見えるからという理由で承認または却下してはいけません。

実行が失敗した理由：実行ログを確認する

まず、失敗したタスク自体を確認してください（get-task）。failure_reason は停止した理由についての実行自体の説明、failure_code はその短いコード、run_headline（null でない場合）は何が起きたかを簡潔に述べた一文です。既知のシークレット値は理由からマスキングされます。status_history には、終了時の状態が表示されます。詳しく確認するには、実行ログを確認してください。ログは顧客にも読める内容です。次の順で確認します。

1. まずイベントを確認します。 すべてのツール呼び出しとその入力、出力、エラーフラグ、タイミング、失敗して再試行された呼び出し、接続済みアプリの呼び出し、承認待ち、ステータスのタイムライン、実行への入力、実行開始時点の従業員の設定と、それ以降に行われた編集が一覧表示されます。

   dozaldevs get-task-events "$TASK"
   

2. 次にトランスクリプトを確認します。 試行ごとにエントリがあります。特定の試行をすべて読むには、その ID を --id とともに渡します。

   dozaldevs list-executions --task_id "$TASK"
   dozaldevs list-executions --id "$EXECUTION"
   

3. 最後にステータスログを確認します。 出来事の順序を確認できます。

   dozaldevs get-task-status-log "$TASK"
   

get-task-conversation は使用しないでください。これはアドホックな会話のみを返すため、従業員の実行では空になります。従業員への指示とその出力は、タスクの output、イベント、実行内容に記録されています。

ログに記録された内容を、平易な言葉で説明してください。ログだけでは失敗の理由が分からないこともあります。原因が記録されていない場合は、そのことを伝え、推測しないでください。プラットフォームの生のコンテナログはプラットフォームスタッフ専用のため、確認しないでください。

アクティビティとリアルタイムのステータス

• 最近の作業： list-tasks（--limit 10 を追加）、特定のタスクの出力を確認する list-deliverables --task_id "$TASK"、最近の決定者と決定内容を確認する list-recent-decisions、行動すべきだったのに行動しなかった従業員とその理由をそれぞれ確認する list-silent-dozals：

  dozaldevs list-tasks --limit 10
  dozaldevs list-deliverables --task_id "$TASK"
  dozaldevs list-recent-decisions
  dozaldevs list-silent-dozals
  

• 人の承認待ち： タスクが何の承認を待っているかを確認します。

  dozaldevs list-task-pending-approvals "$TASK"
  

• リアルタイムの進捗： 進捗を追跡するストリームはありません。上記の --while による待機を使い、各ラウンドの合間に phase_category の内容を人に伝えてください。実行が現在行っていることを確認するには、イベントを読んでください。