mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-06 14:00:09 +02:00
117 lines
10 KiB
Plaintext
117 lines
10 KiB
Plaintext
---
|
||
title: タスク
|
||
description: すべてのエージェント実行の作業単位であり、明確なステートマシン、タイムアウト、リトライルールを備えています。
|
||
---
|
||
|
||
import { Callout } from "fumadocs-ui/components/callout";
|
||
import { Mermaid } from "@/components/mermaid";
|
||
|
||
**タスク**はすべての[エージェント](/agents)実行の単位です — [エージェントへのイシューの割り当て](/assigning-issues)、[コメントでのエージェントの @-メンション](/mentioning-agents)、[チャット](/chat)でのメッセージ送信、または[オートパイロット](/autopilots)が予定時刻に発火することは、いずれもタスクを生成します。Multica はそれをキューに入れ、[デーモン](/daemon-runtimes)が取得して対応する [AI コーディングツール](/providers)に引き渡し、完了するとその結果をサーバーに書き戻します。
|
||
|
||
タスクと[イシュー](/issues)は異なる 2 つのオブジェクトです。1 つのイシューは何度も割り当てられたり、@-メンションされたり、手動で再実行されたりでき — そのたびに**新しい**タスクが生成されます。
|
||
|
||
## タスクが経るステート
|
||
|
||
<Mermaid chart={`
|
||
graph LR
|
||
Q["Queued<br/>queued"] -->|daemon picks up| D["Dispatched<br/>dispatched"]
|
||
D -->|agent starts| R["Running<br/>running"]
|
||
R -->|success| C["Completed<br/>completed"]
|
||
R -->|error or timeout| F["Failed<br/>failed"]
|
||
Q -->|user cancels| X["Cancelled<br/>cancelled"]
|
||
D -->|user cancels| X
|
||
R -->|user cancels| X
|
||
F -.retryable reason.-> Q
|
||
`} />
|
||
|
||
- **Queued（キュー待ち）** — タスクが作成されたばかりで、デーモンが取得するのを待っている状態
|
||
- **Dispatched（ディスパッチ済み）** — デーモンがタスクを占有し、AI コーディングツールを起動中
|
||
- **Running（実行中）** — AI コーディングツールが実際に作業を実行中
|
||
- **Completed（完了）** — 正常に終了し、成果物（コメント、コードコミット、ステータス変更）がサーバーに書き戻されます
|
||
- **Failed（失敗）** — エラーまたはタイムアウトで中断。失敗理由がリトライ可能な場合、タスクは自動的に `queued` 状態に戻り、再試行されます
|
||
- **Cancelled（キャンセル済み）** — ユーザーがキャンセルした場合
|
||
|
||
## タスクがタイムアウトしたときに起きること
|
||
|
||
Multica サーバーは 30 秒ごとにスキャンします。2 種類のタイムアウトが失敗を引き起こします。
|
||
|
||
| 状況 | タイムアウト |
|
||
|---|---|
|
||
| ディスパッチされたが開始されない（デーモンが取得したが AI ツールを起動しなかった） | **5 分** |
|
||
| 実行が長すぎる | **2.5 時間** |
|
||
|
||
どちらのタイムアウトも失敗理由として `timeout` を使用し、**自動的にリトライされます**（次のセクション）。関連するランタイム欠落チェックについては、[デーモンとランタイム → ランタイムがオフラインとマークされるタイミング](/daemon-runtimes#when-a-runtime-is-marked-offline)を参照してください。
|
||
|
||
## どの失敗が自動的にリトライされ、どの失敗がされないか
|
||
|
||
失敗は 2 つのカテゴリに分かれます: **リトライ可能**と**リトライ不可**です。
|
||
|
||
**リトライ可能**（Multica が自動的に再キューイング）:
|
||
|
||
- `runtime_offline` — タスクがディスパッチされた後にデーモンがいなくなった
|
||
- `runtime_recovery` — デーモンがクラッシュして再起動し、終わらせなかったタスクを回収した
|
||
- `timeout` — ランタイムまたはディスパッチのタイムアウト
|
||
|
||
**リトライ不可**（タスクは失敗状態のまま）:
|
||
|
||
- `agent_error` — AI コーディングツール自体がエラーを報告した（API エラー、クォータ超過、内部バグ）。根本的な問題はリトライされません — 無限ループになってしまうためです。
|
||
|
||
自動リトライにはさらに 2 つの追加条件もあります。
|
||
|
||
1. **最大 2 回の試行** — オリジナル 1 回 + リトライ 1 回。リトライも失敗した場合は、理由がリトライ可能であってもそれ以上リトライしません。
|
||
2. **イシューおよびチャットでトリガーされたタスクのみ** — オートパイロットでトリガーされたタスクは自動的にリトライ**されません**。
|
||
|
||
<Callout type="warning">
|
||
**オートパイロットのタスクは自動的にリトライされません** — 意図された設計です。オートパイロットは独自の発火サイクル（例: 毎日）を持っており、失敗時に自動リトライが起きると次の予定実行と重なってしまいます。失敗後すぐに再実行が必要なら、手動の再実行を使用してください（次のセクション）。
|
||
|
||
**オートパイロットのタスクが失敗したことを知る方法**: [インボックス](/inbox)に通知が届き、関連するイシューのステータスが `in_progress` から `todo` に戻ります。[オートパイロット](/autopilots)ページでも、オートパイロットごとの最新の実行結果を確認できます。
|
||
</Callout>
|
||
|
||
## 手動の再実行 vs. 自動リトライ
|
||
|
||
**手動の再実行**は、CLI または API（`POST /api/issues/{id}/rerun`）から自分でトリガーするものです。
|
||
|
||
```bash
|
||
multica issue rerun <issue-id>
|
||
```
|
||
|
||
動作:
|
||
|
||
- デフォルトでは、イシューの**現在のエージェント担当者**を対象とします — 以前のタスクを誰が実行したかに関わらず、再実行が現在の割り当てに従うようにしたいときに便利です。
|
||
- 実行ログの特定の行にあるリトライボタンは、その行のタスク ID も一緒に送信するため、再実行は**現在の担当者ではなく、まさにそのタスクを実行したエージェント**を対象とします。これにより、スクワッドワーカー、並列の @-メンションエージェント、または再割り当てによってエージェントが入れ替わった行に対しても、行単位のリトライが意味を持つようになります。
|
||
- このイシューに対する対象エージェントのキュー待ちまたは実行中のタスクを**キャンセルします**（ある場合）。同じイシューで他のエージェントが所有するタスク（例: 並列の @-メンション実行）はそのまま残します。
|
||
- **まったく新しい**タスクを作成します — オリジナルのタスクが試行回数の上限に達していても、試行回数は 1 にリセットされます。
|
||
- **新しいエージェントセッション**を開始します — 以前のセッション ID は**継承されません**。手動の再実行は、以前の成果物が悪かったと判断したことを意味するため、同じ会話を続けると汚染された状態をそのまま再生してしまいます。（一方、自動リトライはセッションを継承します — そのパスは悪い成果物ではなくインフラ障害のためのものです。）
|
||
|
||
比較:
|
||
|
||
| 項目 | 自動リトライ | 手動の再実行 |
|
||
|---|---|---|
|
||
| トリガー | システム、失敗理由に基づく | ユーザー、手動 |
|
||
| 上限 | 2 回の試行 | 制限なし |
|
||
| 適用できるソース | イシュー、チャット | エージェント担当者があるイシュー |
|
||
| 選択されるエージェント | 失敗したタスクと同じエージェント | ソースタスクのエージェント（UI 行単位リトライ）またはイシューの現在の担当者（CLI / task_id なし） |
|
||
| セッション継承 | あり（以前のセッションを再開） | なし（新しいセッション） |
|
||
|
||
## 失敗したタスクがイシューのステータスに与える影響
|
||
|
||
イシューがエージェントに割り当てられていてトリガーされたタスクが失敗すると（そして自動リトライが成功しないと）、**イシューのステータスが `in_progress` から `todo` に自動的に戻ります** — そのため、ボードを開くと「これはもう一度見る必要がある」とすぐに分かります。[イシューとプロジェクト](/issues)を参照してください。
|
||
|
||
## タスクが以前のコンテキストから続行できるか
|
||
|
||
できます — AI コーディングツールがセッション再開をサポートしている限りは。
|
||
|
||
Multica はタスク中にセッション ID を**2 回**固定します: 開始時に 1 回（AI ツールが最初のシステムメッセージを返したとき）、終了時に 1 回（完了または失敗時）。1 回目はデーモンが実行の途中でクラッシュしても復旧できるようにし、2 回目は次の**自動リトライ**のために予約され、その ID を渡し返すことでエージェントが以前の会話とファイル状態を引き継げるようにします。**手動の再実行は意図的にこのステップをスキップし**、新しいセッションを開始します — [手動の再実行 vs. 自動リトライ](#manual-rerun-vs-automatic-retry)を参照してください。
|
||
|
||
ただし、**実際にどの AI コーディングツールがこれをサポートするか**は大きく異なります。
|
||
|
||
- ✅ **実際にサポート** — Antigravity, Claude Code, Codex, Copilot, Cursor, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Pi
|
||
- ❌ **サポートなし** — Gemini
|
||
|
||
[プロバイダー対応表 → セッション再開](/providers#session-resumption-who-really-supports-it)を参照してください。
|
||
|
||
## 次へ
|
||
|
||
- [プロバイダー対応表](/providers) — 12 個の AI コーディングツール間の機能差（正確なセッション再開の状態を含む）
|
||
- [エージェントへのイシューの割り当て](/assigning-issues) / [コメントでのエージェントの @-メンション](/mentioning-agents) / [チャット](/chat) / [オートパイロット](/autopilots) — タスクをトリガーする 4 つの方法
|