タスク

すべてのエージェント実行の作業単位であり、明確なステートマシン、タイムアウト、リトライルールを備えています。

タスクはすべてのエージェント実行の単位です — エージェントへのイシューの割り当て、コメントでのエージェントの @-メンション、チャットでのメッセージ送信、またはオートパイロットが予定時刻に発火することは、いずれもタスクを生成します。Multica はそれをキューに入れ、デーモンが取得して対応する AI コーディングツールに引き渡し、完了するとその結果をサーバーに書き戻します。

タスクとイシューは異なる 2 つのオブジェクトです。1 つのイシューは何度も割り当てられたり、@-メンションされたり、手動で再実行されたりでき — そのたびに新しいタスクが生成されます。

タスクが経るステート

Rendering diagram…

Queued（キュー待ち） — タスクが作成されたばかりで、デーモンが取得するのを待っている状態
Dispatched（ディスパッチ済み） — デーモンがタスクを占有し、AI コーディングツールを起動中
Running（実行中） — AI コーディングツールが実際に作業を実行中
Completed（完了） — 正常に終了し、成果物（コメント、コードコミット、ステータス変更）がサーバーに書き戻されます
Failed（失敗） — エラーまたはタイムアウトで中断。失敗理由がリトライ可能な場合、タスクは自動的に queued 状態に戻り、再試行されます
Cancelled（キャンセル済み） — ユーザーがキャンセルした場合

タスクがタイムアウトしたときに起きること

Multica サーバーは 30 秒ごとにスキャンします。2 種類のタイムアウトが失敗を引き起こします。

状況	タイムアウト
ディスパッチされたが開始されない（デーモンが取得したが AI ツールを起動しなかった）	5 分
実行が長すぎる	2.5 時間

どちらのタイムアウトも失敗理由として timeout を使用し、自動的にリトライされます（次のセクション）。関連するランタイム欠落チェックについては、デーモンとランタイム → ランタイムがオフラインとマークされるタイミングを参照してください。

どの失敗が自動的にリトライされ、どの失敗がされないか

失敗は 2 つのカテゴリに分かれます: リトライ可能とリトライ不可です。

リトライ可能（Multica が自動的に再キューイング）:

runtime_offline — タスクがディスパッチされた後にデーモンがいなくなった
runtime_recovery — デーモンがクラッシュして再起動し、終わらせなかったタスクを回収した
timeout — ランタイムまたはディスパッチのタイムアウト

リトライ不可（タスクは失敗状態のまま）:

agent_error — AI コーディングツール自体がエラーを報告した（API エラー、クォータ超過、内部バグ）。根本的な問題はリトライされません — 無限ループになってしまうためです。

自動リトライにはさらに 2 つの追加条件もあります。

最大 2 回の試行 — オリジナル 1 回 + リトライ 1 回。リトライも失敗した場合は、理由がリトライ可能であってもそれ以上リトライしません。
イシューおよびチャットでトリガーされたタスクのみ — オートパイロットでトリガーされたタスクは自動的にリトライされません。

オートパイロットのタスクは自動的にリトライされません — 意図された設計です。オートパイロットは独自の発火サイクル（例: 毎日）を持っており、失敗時に自動リトライが起きると次の予定実行と重なってしまいます。失敗後すぐに再実行が必要なら、手動の再実行を使用してください（次のセクション）。

オートパイロットのタスクが失敗したことを知る方法: インボックスに通知が届き、関連するイシューのステータスが in_progress から todo に戻ります。オートパイロットページでも、オートパイロットごとの最新の実行結果を確認できます。

手動の再実行 vs. 自動リトライ

手動の再実行は、CLI または API（POST /api/issues/{id}/rerun）から自分でトリガーするものです。

multica issue rerun <issue-id>

動作:

デフォルトでは、イシューの現在のエージェント担当者を対象とします — 以前のタスクを誰が実行したかに関わらず、再実行が現在の割り当てに従うようにしたいときに便利です。
実行ログの特定の行にあるリトライボタンは、その行のタスク ID も一緒に送信するため、再実行は現在の担当者ではなく、まさにそのタスクを実行したエージェントを対象とします。これにより、スクワッドワーカー、並列の @-メンションエージェント、または再割り当てによってエージェントが入れ替わった行に対しても、行単位のリトライが意味を持つようになります。
このイシューに対する対象エージェントのキュー待ちまたは実行中のタスクをキャンセルします（ある場合）。同じイシューで他のエージェントが所有するタスク（例: 並列の @-メンション実行）はそのまま残します。
まったく新しいタスクを作成します — オリジナルのタスクが試行回数の上限に達していても、試行回数は 1 にリセットされます。
新しいエージェントセッションを開始します — 以前のセッション ID は継承されません。手動の再実行は、以前の成果物が悪かったと判断したことを意味するため、同じ会話を続けると汚染された状態をそのまま再生してしまいます。（一方、自動リトライはセッションを継承します — そのパスは悪い成果物ではなくインフラ障害のためのものです。）

比較:

項目	自動リトライ	手動の再実行
トリガー	システム、失敗理由に基づく	ユーザー、手動
上限	2 回の試行	制限なし
適用できるソース	イシュー、チャット	エージェント担当者があるイシュー
選択されるエージェント	失敗したタスクと同じエージェント	ソースタスクのエージェント（UI 行単位リトライ）またはイシューの現在の担当者（CLI / task_id なし）
セッション継承	あり（以前のセッションを再開）	なし（新しいセッション）

失敗したタスクがイシューのステータスに与える影響

イシューがエージェントに割り当てられていてトリガーされたタスクが失敗すると（そして自動リトライが成功しないと）、イシューのステータスが in_progress から todo に自動的に戻ります — そのため、ボードを開くと「これはもう一度見る必要がある」とすぐに分かります。イシューとプロジェクトを参照してください。

タスクが以前のコンテキストから続行できるか

できます — AI コーディングツールがセッション再開をサポートしている限りは。

Multica はタスク中にセッション ID を2 回固定します: 開始時に 1 回（AI ツールが最初のシステムメッセージを返したとき）、終了時に 1 回（完了または失敗時）。1 回目はデーモンが実行の途中でクラッシュしても復旧できるようにし、2 回目は次の自動リトライのために予約され、その ID を渡し返すことでエージェントが以前の会話とファイル状態を引き継げるようにします。手動の再実行は意図的にこのステップをスキップし、新しいセッションを開始します — 手動の再実行 vs. 自動リトライを参照してください。

ただし、実際にどの AI コーディングツールがこれをサポートするかは大きく異なります。

✅ 実際にサポート — Antigravity, Claude Code, Copilot, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Pi
⚠️ コードはあるが使用不可 — Codex, Cursor
❌ サポートなし — Gemini

プロバイダー対応表 → セッション再開を参照してください。

プロバイダー対応表 — 12 個の AI コーディングツール間の機能差（正確なセッション再開の状態を含む）
エージェントへのイシューの割り当て / コメントでのエージェントの @-メンション / チャット / オートパイロット — タスクをトリガーする 4 つの方法