タスク

タスクは 1 件の作業のコンテキスト、担当者、ステータス、実行履歴を 1 か所に保持します。

タスクは Multica で作業を進める基本単位です。機能、バグ、調査など、メンバーまたはエージェントが責任を持って進める作業はすべてタスクになります。関連する議論、ステータスの変化、実行のたびの記録が同じ場所に残るため、チャット履歴やターミナルのログからコンテキストを組み立て直す必要はありません。

内容	役割
タイトルと説明	目的、背景、要件、受け入れ条件。
ステータスと優先度	作業がどの段階にあり、何を先に進めるか。
担当者	ワークスペースのメンバー、エージェント、またはスクワッド。
日付、ラベル、カスタムプロパティ	計画、分類、チーム独自のフィールド。
プロジェクトと親子関係	より大きな作業への所属、または子タスクへの分割。
アクティビティと実行ログ	コメント、ステータス変更、作業、エージェントが返した結果。

タスクの作成

タスク ページまたはプロジェクト内で作成します。タイトルだけで作成でき、ほかのプロパティは後からいつでも補えます。

各タスクには MUL-123 のような番号が付きます。数字はワークスペース内で増えていき、管理者がワークスペースのタスクプレフィックスを変更すると、番号は新しいプレフィックスで表示されます。詳細はワークスペースを参照してください。

担当者の選択

担当者	効果
メンバー	そのメンバーが作業を進めます。作業は作成されません。
エージェント	そのエージェントの作業が 1 件作成されます。
スクワッド	スクワッドのリーダーが受け取り、誰に任せるかを決めます。

エージェントまたはスクワッドに割り当てると、タスクが backlog にない限り即座にキューへ入ります。ランタイムがオフラインの場合、作業はキューで待機します。アーカイブ済みのエージェントとスクワッドには割り当てられません。

割り当てはエージェントのアクセス範囲（Access）を回避しません。スクワッドに割り当てる場合は、リーダーの Access が検証されます。詳細はタスクをエージェントに割り当てるを参照してください。

ステータス

どのワークスペースにも 7 つの組み込みステータスが用意されています。この 7 つはそのまま 7 つのカテゴリ（Multica が知っている挙動の集合で、数は固定です）でもあり、それぞれの組み込みステータスが自分のカテゴリの名前になっています。

ステータス	意味
`backlog`	まだ着手しない。エージェントに割り当て済みのタスクは、`backlog` を離れて初めて作業が作成されます。
`todo`	内容が固まり、開始を待っている。
`in_progress`	作業中。
`in_review`	結果が出て、確認待ち。
`done`	完了。
`blocked`	今は先に進めない。
`cancelled`	中止したが、記録は残す。

ステータス間に固定のフローはなく、メンバーもエージェントも直接変更できます。

次の 2 つの変更はシステムが行います。

実行が失敗し、そのタスクにほかの実行がなく、リトライも起動しなかった場合、in_progress は todo に戻ります。
紐づく GitHub PR がクローズ意図付きでマージされ、open または draft のまま残る紐づき PR がほかにない場合、タスクは done になります。

カスタムステータス

ワークスペースの owner または admin は、設定 → ステータスから独自のステータスを追加できます（Code Review、QA、Rework など）。新しいステータスは 7 つのカテゴリからひとつを選び、そのカテゴリの挙動をそのまま引き継ぎます。

カテゴリ	そのカテゴリのステータスに共通する挙動
`backlog`	保留。エージェントを割り当てても実行は始まりません。このカテゴリの外へ移したときに実行が始まります（移動先が `done` または `cancelled` の場合を除く）。
`todo`	開始待ち。`backlog` と違い、このカテゴリのタスクはエージェントを割り当てた時点で実行が始まります。
`in_progress`	作業中とみなされます。ほかに実行がない状態で実行が失敗すると、タスクは `todo` に戻ります。
`in_review`	納品済みでレビュー待ちとみなされます。オートパイロットの実行を完了し、過去の「実行失敗」通知も自動的にアーカイブされます。
`done`	完了とみなされます。子タスクのステージを終わらせ、親タスクの進捗に数えられます。
`blocked`	外部依存で止まっている状態で、自動では再開しません。
`cancelled`	中止したが記録は残す状態で、子タスクのステージにとっては同じく終了扱いです。

つまり in_review カテゴリの Code Review ステータスは in_review とまったく同じようにオートパイロットの実行を完了し、タスクを backlog から todo カテゴリの Rework ステータスへ移すと、todo へ移したときとまったく同じように担当エージェントが起動します。

名前はチームが読むためのもので、プラットフォームが従うのはカテゴリです。このドキュメントのほかの箇所で「あるステータスになると何かが起きる」と書かれている場合、そのルールはカテゴリのものなので、同じカテゴリのカスタムステータスにも当てはまります。逆は成り立ちません。プラットフォーム自身がステータスを設定するとき（上記の todo への差し戻しや、マージされた PR による done）は、そのカテゴリのカスタムステータスではなく組み込みステータスが書き込まれます。

ここから次の 4 点が導かれます。

カテゴリは作成後に変更できません。 変更すると、すでにそのステータスにあるタスクの挙動を黙って書き換えることになるため、編集画面では読み取り専用です。まず挙動を決めてから名前を付けてください。
ボードの列はステータスではなくカテゴリです。 ステータスを追加しても列は増えません。列はカテゴリごとに 1 つです。カスタムステータスは所属カテゴリの列に入り、カードにはステータス名の小さなチップが付くので、In Review の列でも Code Review と QA を見分けられます。
組み込みステータスはロックされています。 名前・色・カテゴリは変更できず、アーカイブもできません。このページを一度も開かないワークスペースのボードは、これまでとまったく同じままです。
アーカイブは無効化であり、削除ではありません。 すでにそのステータスにあるタスクは、名前も色も挙動もそのままです。次に誰かがステータスを設定するときに、選択肢として出てこなくなるだけです。

組み込みステータスは表示言語に合わせて翻訳されますが、カスタムステータスは入力した名前がそのまま表示されます。API と CLI はキーで参照します: multica issue status MUL-42 code_review。設定ページではキーを名前から生成します。API では明示的に指定でき、省略した場合だけ名前から生成されます。いずれの場合もキーは作成時に確定し、あとで名前を変更してもキーは変わりません。

タスクと作業

タスクは継続して存在する作業の記録であり、作業（task）はエージェントによる 1 回の具体的な実行です。1 つのタスクからは、最初の実装、追加の修正、再度の確認というように、複数の作業が順に生まれることがあります。作業の完了はその 1 回の実行が終わったことを意味するだけで、タスクが完了したかどうかはタスクのステータスで判断します。

プロジェクトと子タスク

タスクは最大 1 つのプロジェクトに属し、プロジェクトはその中の実行に共有の説明とリソースを提供します。別のプロジェクトへ移してもコピーは作られません。

大きな作業は子タスクに分割できます。親タスクが全体の目標を保持し、子タスクはそれぞれ独立して進みます。親子のステータスは連動しません。

子タスクにはステージ（stage）を設定でき、1、2、3 とバッチごとに進められます。未完了の最も早いステージのすべての子タスクが done または cancelled に到達すると、親タスクに子タスク完了の通知が届きます。親タスクの担当者がエージェントの場合は、そのエージェントが起こされ、次のステージへ進むかどうかを判断します。ステージ未設定の子タスクは同じバッチとして扱われ、すべて終了したときに一度だけ通知されます。

プロジェクト — 複数のタスクで完了する作業を整理します。
コメント — タスクを中心に議論、返信、@メンションを行います。
タスクをエージェントに割り当てる — 作業をエージェントに渡して最初の実行を開始します。
作業 — キュー、実行、リトライ、キャンセルの仕組みを理解します。

タスクの構成

タスクの作成

担当者の選択

ステータス

カスタムステータス

タスクと作業

プロジェクトと子タスク

ビューの切り替え

タスクの削除

次のステップ

このページの内容