ドキュメント

タスク

タスク詳細ビュー — エージェントのワークフロー、受け入れ基準、実行履歴、および記録されるその他すべての情報。

タスクとは、1つのpull requestとして完了する作業単位です。実際に実行されるのはこれであり、プランやスプリント、レーンはタスクを整理するための手段です。

ヘッダー

チップの行には、タスクの概要が一目でまとめられています:そのプロジェクト、そのタイプ、 そのAIプロファイルがタスクを実行し、さらにQAチェックが適用されます。ポリシー名、その出所、バージョンなどが表示されます。Standard · From plan · Organisation policy · v6。

AIプロファイルに表示される鍵マークは、そのプロファイルが固定されて変更できないことを意味します。同様に、解決済みのQAポリシーも実行開始時に固定されるため、後から組織ポリシーを変更しても、すでに実行中の作業に遡って影響は及びません。

タスク詳細ビュー:左側にプラン構造、右側にチップ行、エージェントワークフロー、受入基準、実行履歴が表示されます。
プラン内のタスクとそのエージェントワークフロー、受入基準。

エージェントのワークフロー

4種類のデリバリーエージェントはそれぞれの状態(保留中、実行中、完了)を表示します。標準モードでは順番に実行されます:

アーキテクト → デベロッパー → QA → レビュアー

これが「このタスクは現在どの段階か」という疑問への最も明確な答えです。デベロッパーによる作業が完了し、QAが保留中の状態は、タスクが停滞しているのではなく検証を待っている状態です。

コーディネーターモードでは、次に実行するエージェントをコーディネーターが選択するため、開発者→QA→失敗時には再び開発者→再度QAという順序で処理が繰り返されることがあります。また、タスクの要求内容が既にコードで実現されている場合は、QAが変更されていないコードを検証し、開発者は実行されず、タスクはpull requestなしで完了します。エージェントの役割。

あるステージが保留中と表示されることは、タスクがすでに完了している場合でも正当なことです。プランから生成されたタスクにはすでに仕様と実装計画が含まれているため、アーキテクトのステージにはもはや実行すべき作業が残っていないのです。アーキテクトステージにはもはや実行すべき作業が残っていません。

「エージェントの役割」を参照してください。エージェントの役割各エージェントが実行できる作業とできない作業について説明しています。

受入基準

以下の基準は仕様書から得られるものです、各項目ごとのステータスが記載されたチェックリストとして表示されます —Verified OK基準が確認されると その旨が示されます。

ステータスは現在のパイプライン段階に準拠するため、基準はタスクの進行に合わせて逐次検証され、最後に一括で確認されるわけではありません。

完了したタスクを評価する際に参照すべきパネルです。ここには約束された内容と実際に確認された内容が記載されており、テストが通ったかどうかよりも重要な情報となります。

実行履歴

タスクに対して記録されたすべての実行内容です。各エントリには実行したエージェント、実行内容、結果、およびコストが記載されます:

DEV · Generating code · Completed
4m 41s / 608.9k tokens · 16.2 g Est. CO2e / deepseek-v4-flash-0731

実行ごとに所要時間、トークン使用量、推定CO2排出量、使用モデルがすべて記録されるため、タスクのコストが予想を上回った場合でも、どの段階でどのモデルが影響を与えたかを確認できます。

展開された実行履歴には各ステップが記載されており、読み込まれたファイル、実行されたコマンド、エージェントの応答、変更されたファイルと行数が確認できます。
ステップごとの展開された実行内容。

実行内容を展開すると、詳細な手順が表示されます:読み込まれたファイル、実行されたコマンド、エージェントの推論内容、変更されたファイルとその行数 (+25 / −0)。トークンエントリにはキャッシュ効率が示されます(9.1k used (90% cached))、これが高コストな実行と低コストな実行を分ける主な要因です。

何が行われたかを知りたい場合に開くべきビューです方法単に変更内容を知るだけでなく、処理の詳細を把握するためのものです。

残りのセクション

セクション表示内容
仕様書プランに基づく要件
実装計画実行手順とその完了状況
品質と発見事項検証ステータスとテスト件数
使用状況とタイムラインコスト、トークン使用量、試行回数
依存関係とコンテキストリンクされた依存関係とそれぞれのステータス

使用状況とタイムラインコストに加えて試行回数も報告します —1 attemptsの値が1であれば 初回で成功したことを意味します。数値が大きいほど再作業が発生したことを示し、これは仕様書の品質を判断する上で最も有用な指標です。

依存関係とコンテキストセクションにはプロジェクト情報と10件の関連依存関係がそれぞれのステータスと共に一覧表示されます。
依存関係とコンテキストの詳細表示。

依存関係とコンテキストプロジェクトおよび関連するすべての依存関係とそのステータスを一覧表示します。これにより、タスクが他のものを待機中なのか、それとも実際にブロックされているのかを判断できます。

優先度

タスクにはP0(最優先)からP3までの優先度が設定され、デフォルトではP2となります。処理待ちのタスク数が利用可能なスロット数を上回る場合に、優先度によってキューの順序が決定されます。

優先度を上げても処理能力は増えません。すべてのタスクがP0の場合、何も処理されません — 詳細は処理能力とエージェントスロット。

ステータス

各タスクのステータスと対応方法についてはタスクステータスここで特に把握しておくべきなのは以下の2つです:

  • PENDINGは作業が停滞しているわけではありません。これはキューに入れられ、処理スロットを待機している状態です。
  • NEEDS_HUMAN_REVIEWは処理失敗を意味するわけではありません。これは確認事項です。回答すればタスクは続行されます。

介入

タスクの実行中に、一時停止、キャンセル、またはコメント付きで再作業として送り返すことができます。どれを選択すべきかは をご覧ください。タスクが停滞または失敗した場合。