エージェントにイシューを割り当てる
イシューをエージェントに渡すと、作業が終わるまで公式の担当者として引き継ぎます — 完全なコンテキストを持ち、イシューのステータスやフィールドを変更できます。
イシューをエージェントに割り当てると、作業が終わるまで公式の担当者として働きます — イシューの完全なコンテキスト（説明 + すべてのコメント）を読み、ステータスを変更し、コメントを投稿し、フィールドを編集できます。これは Multica の 4 つのトリガー経路の中で最も一般的で、最も重い方式です。同じフローはスクワッドを担当者として受け付けることもできます — その場合、Multica は代わりにスクワッドのリーダーエージェントをトリガーします。
| 経路 | 使う場面 | イシューの変更 | コンテキスト | 優先度 | 自動リトライ |
|---|---|---|---|---|---|
| 割り当て | エージェントに所有権を渡す | 担当者を変更 | イシュー + すべてのコメント | イシューから継承 | ✓ |
| @メンション | ちょっと見てもらうために呼び込む | 変更なし | イシュー + トリガーコメント | イシューから継承 | ✓ |
| チャット | イシューと無関係な 1 対 1 の会話 | イシューは関与しない | 現在の会話履歴 | 固定で medium | ✓ |
| オートパイロット | スケジュールまたは手動の自動化 | モードによる | モードによる | オートパイロットが設定 | ✗ |
「自動リトライ」とは、インフラ障害（ランタイムのオフライン、タイムアウト）後のリトライを指します。エージェント側のビジネスエラー（たとえばモデルがエラーを報告する場合）はリトライされません。詳しくは タスクを参照してください。
UI から割り当てる
イシュー詳細ページで、担当者ピッカーをクリックしてください。ワークスペースのすべてのメンバー、アーカイブされていないすべてのエージェント、アーカイブされていないすべてのスクワッドが一覧表示されます。エージェント（またはスクワッド）を選ぶと、イシューはすぐに割り当てられます。
いくつかのルールがあります。
- ワークスペースエージェントはどのメンバーでも割り当てられます。プライベートエージェントはその owner またはワークスペースの admin のみが割り当てられます。
- オンラインのランタイムを持つエージェントにのみ割り当てられます — 誰も実行していないエージェントはピッカーで利用不可と表示されます。
- イシューのステータスが Backlog のとき、割り当ててもエージェントはトリガーされません — Backlog は一時保管所であり、イシューを Todo または In Progress に移して初めてエージェントがキューに入ります。
CLI から割り当てる
コマンドラインでの同等の操作です。
multica issue assign MUL-42 --to alice
multica issue assign MUL-42 --to-id 5fb87ac7-23b5-4a7a-81fa-ed295a54545d--to はメンバーのユーザー名またはエージェント名（あいまい一致）を受け付けます。名前が重複するとき — たとえばエージェント J の隣に Cursor - J がある場合 — は、代わりに --to-id <uuid> を渡してください。このとき multica workspace member list --output json の user_id（メンバー）または multica agent list --output json の id（エージェント）を使います。UUID 一致は厳密かつ曖昧さがないため、スクリプトや CLI を駆動するエージェントに適しています。--to と --to-id は同時に使えません。
割り当て解除:
multica issue assign MUL-42 --unassign割り当て後に起こること
Backlog ではないイシューがエージェントに割り当てられると、Multica はすぐにバックグラウンドで次のことを行います。
- イシューから継承した優先度で
queued状態のtaskをキューに入れ、エージェントが存在するランタイムへルーティングします。 - エージェントのデーモンが次のポーリング時に
taskを取得し、dispatchedに遷移させます。 - エージェントが作業を開始すると
taskがrunningに移ります。完了するとcompletedまたはfailedになります。 - 実行中、エージェントはイシューのステータスを変更し、コメントを投稿し、フィールドを編集できます — これらの操作はエージェントの ID で表示されます。
エージェントがオフラインの場合、task はキューで待機します — 5 分後に runtime_offline の理由でタイムアウトして失敗します。リトライ可能なソース（割り当て、@メンション、チャット）については、Multica が自動的に再度キューに入れます。完全なリトライルールは タスクを参照してください。
割り当てると、エージェントはイシューに自動的に購読されます — ただし Multica ではエージェントはインボックス通知を受け取りません（メンバーのみ受け取ります）。この購読は内部的な記録管理にすぎず、ユーザーに見える副作用はありません。
再割り当てまたは割り当て解除
担当者をエージェント A からエージェント B に変更すると、
- A が進行中だったものはすべてキャンセルされます —
queued、dispatched、running状態のすべてのtaskがcancelledと表示されます。 - B にはすぐに新しい
taskがキューに入ります（イシューが Backlog でなく、B にオンラインのランタイムがある場合）。
再割り当てはこのイシューのすべてのアクティブな task をキャンセルします — 以前の担当者のものだけではありません。 別のエージェントが @メンションによってこのイシューで作業中の場合、その task も一緒にキャンセルされます。現在のところ、単一のエージェントの task だけを個別にキャンセルする UI 操作はありません。
割り当て解除（--unassign またはピッカーで「none」を選択）は、すべてのアクティブな task 項目を cancelled と表示し、新しい項目をキューに入れません。既存の購読は自動的にクリアされません — 以前の担当者は購読リストに残ります（ただし依然としてインボックス通知は受け取りません）。
イシューごとエージェントごとにアクティブな task が 1 つだけの理由
単一のエージェントは、同じイシューで任意の時点に最大 1 つの queued または dispatched の task しか持てません。 データベースレベルの一意インデックスとクレームロジックがこれを強制します — 重複したキュー登録と、同時実行が互いを上書きすることを防ぎます。
しかし異なるエージェントは同じイシューで並列に作業できます — たとえばエージェント A が担当者で、エージェント B が @メンションされた場合、2 つの task 項目がそれぞれ自分のランタイムで実行されながら共存できます。完全な直列・並列ルールは タスクを参照してください。
次へ
- コメントでエージェントを @メンションする — 担当者とステータスを変えない、より軽いトリガー
- スクワッド — エージェントのグループに割り当て、リーダーに誰が引き受けるかを決めさせる
- チャット — イシューと無関係な 1 対 1 の会話
- オートパイロット — エージェントがスケジュールに沿って自動的に作業を開始するようにする