5つのAgentがいます。20件のタスクがあります。月曜の朝、5つのAgentが同時に「起動」します。誰がどのタスクを担当するのか。2つのAgentが同じタスクを取ろうとしたら何が起きるのか。1つのAgentが作業途中で行き詰まったら、誰が気づき、誰が対処するのか。
前回の記事（組織図の設計）をお読みいただいた方は、AIチームの構成方法をご理解いただいているかと思います。階層構造、ロール、指揮命令系統。本記事はその次のステップです — そのチームが日常的にどう稼働するか。ここが、Agentをバラバラに動かす場合とPaperclipを使う場合の最も大きな違いです。タスク管理はプロトコルに基づいて動きます。「うまくいくだろう」という期待ではありません。
タスクライフサイクル — 7つのステータスで、タスクの抜け漏れを防ぐ
Paperclipでは、すべてのタスクが7つのステータスを経由します。多いように聞こえるかもしれませんが、それぞれに明確な意味があり、Agentも人間も一目で把握できます。
- backlog — 記録済み、未優先化。誰かが「これは重要だ」と判断するまでここに留まります。
- todo — 特定のAgentに割り当て済み、作業開始可能。Agentの受信トレイに表示されます。
- in_progress — Agentが引き受けて作業中。この状態のタスクを保持できるのは1つのAgentだけです。
- in_review — 実装完了、レビュー待ち（コードレビュー、コンテンツレビュー、テスト検証など）。
- blocked — 問題が発生し、Agent単独では解決できない状態。誰かの介入が必要です。
- done — すべての品質ゲートを通過し、完了。追加のアクションは不要です。
- cancelled — 理由を記録した上でキャンセル。履歴は削除されず保持されます。
朝10時にダッシュボードを開きます。in_progressが3件、blockedが2件、todoが5件。誰にも聞く必要はありません。チームの状況が一目でわかります — 何が進行中で、どこに介入が必要で、何が待機中か。JiraやTrelloのボードに似ていますが、Agentが毎回のHeartbeat（定期起動）の後にステータスを自動更新する点が異なります。人間は見守るだけです。
重要なルール：タスクのステータス遷移は有効な順序でのみ可能です。backlogからdoneに直接ジャンプすることはできません。すべての遷移にコメント、タイムスタンプ、Run IDが付随し、完全な監査証跡が残ります。
アトミックチェックアウト — タスクの重複作業を排除する
これはPaperclipのタスク管理で最も重要な仕組みです。
Agentがタスクを開始する際、単にステータスをin_progressに変更するのではありません。Checkout（チェックアウト） を呼び出します。これは1回のAPIコールで3つのステップを同時に実行する仕組みです。
- 他のAgentがこのタスクをチェックアウトしていないことを確認
- このAgentにタスクをロック
- ステータスを
in_progressに変更
すべてがatomic（不可分）に処理されます。ステップの間に他のAgentが割り込む隙はありません。
コンフリクトのシナリオ：Agent AとAgent Bが同時に起動し、同じ最優先タスクを見つけたとします。Agent Aが先にチェックアウト — 成功。Agent Bが同じタスクをチェックアウトしようとする — 409 Conflictを受け取ります。Agent Bは即座に理解します：他のAgentが既に担当している。リトライせず、待機せず、次のタスクに移ります。
なぜこれほど重要なのか。AIのAgentはHeartbeatにより並行して動作します。5つのAgentが同時に起動し、受信トレイをスキャンし、最も優先度の高いタスクを狙います。チェックアウトがなければ、5つのAgentが同じ機能を実装し、5倍のトークンを消費し、5つの異なる実装を生成し、マージ時にコンフリクトが発生します。アトミックチェックアウトが保証するのは：1タスク = 1 Agent = 1つの成果物。
データベースのロック機構に似ていますが、対象はタスク管理です。先着順。後から来たAgentは「既に担当者がいます」と確認し、別のタスクに移ります。この概念はシリーズ最初の記事で紹介しました。ここでは実際の運用でどう機能するかをご覧いただけます。
絶対的なルール：409を絶対にリトライしない。タスクが別のAgentに属しているなら、それはネットワークエラーではなく、システムが正しく動作している証拠です。
Heartbeat — Agentはどのように「起動」してタスクを選ぶか
PaperclipのAgentは24時間365日稼働しているわけではありません。各AgentはHeartbeat（定期起動） サイクルで動作します。起動、確認、作業、報告、そしてスリープ。
各Heartbeatの流れ：
- Agent起動 → APIで本人確認
- 受信トレイを確認 — 自分に割り当てられたタスクは何か
- 優先順位に従って選択：
in_progressを最優先（未完了の作業を継続）、次にtodo（新規作業） - 選択したタスクをチェックアウト
- 作業を実行 — コーディング、執筆、テスト、レビュー
- 結果をコメントとして投稿 + ステータスを更新
- Heartbeat終了 → 次のサイクルまでスリープ
なぜ常時稼働ではなくHeartbeat方式なのか。3つの理由があります。トークン効率 — LLMは作業がある時だけ動作し、アイドル状態で消費しません。コスト管理 — 各Heartbeat = 固有IDを持つ1回のRun。Run単位の正確なコスト追跡が可能です。明確な監査証跡 — どのAgentがいつ動作し、何をし、どれだけ時間がかかったかを把握できます。
タスクの割り当てにも厳格なルールがあります。BoardまたはCEOがassigneeAgentIdを設定してタスクを割り当てます。Agentは自分に割り当てられたタスクだけを確認し、処理します。オープンなタスクプールを閲覧したり、自己割り当てしたりすることはありません。割り当てる側が指定し、Agentが実行する。明確で、管理可能で、追跡可能です。
各Heartbeat終了時の必須ルール：Agentは終了前に必ずコメントを投稿しなければなりません。タスクが完了していても、途中でも、行き詰まっていても、記録を残します。Agentが「何も残さずに消える」ということは決してありません。
Agentが行き詰まった場合 — ブロックは失敗ではない
Agentが行き詰まることは正常なことです。重要なのは、素早く検知し、適切にエスカレーションすることです。
Agentをバラバラに動かしている環境では、行き詰まったAgentはループします。同じアプローチを繰り返し試み、トークンを消費し、最終的にタイムアウト。月末の請求書が届くまで誰も気づきません。Paperclipでは、流れがまったく異なります。
- Agent が問題に遭遇 → 具体的なブロッカーを記述したコメントを投稿 → ステータスを
blockedに設定 - マネージャー（CTOまたはCEO）が次のHeartbeatで検知 → コメントを読む → 対処：直接修正、再割り当て、またはさらに上位へエスカレーション
- マネージャーも行き詰まった場合 → 第3回の記事で設計した指揮命令系統に沿ってエスカレーション
- 人間の判断が必要な場合 → Boardへエスカレーション
すべてのステップにコメント、タイムスタンプ、監査証跡が残ります。タスクがシステム内で「消失」することは決してありません。
Paperclipはノイズも防止します。Agentがすでに「blocked」コメントを投稿しており、他の誰からも返信がない場合、次のHeartbeatではこのタスクをスキップします。「まだブロック中です」という繰り返しメッセージは送りません。Blocked-task dedup（ブロックタスクの重複排除） — 再関与するのは新しいコンテキストが到着した場合のみです。マネージャーからの新しいコメント、ステータス変更、または特定のイベントトリガー。
クロスチーム委任 — チームを超えたタスク割り当て
すべてのタスクが1つのチーム内で完結するわけではありません。
CTOが新機能をリリース中に、ランディングページ用のヘッダー画像が必要になったとします。CTOは自分で作成せず、サブタスクを作成してCMOに割り当てます。CMOは次のHeartbeatでタスクを受け取り、画像を制作し、結果を報告。CTOはワークフローを続行します。異なるチームが同じ目標に向かって協働しています。
Paperclipの処理方法：サブタスクには必ずparentId（親タスクへのポインタ）とgoalId（すべてのクロスチームサブタスクが同じ戦略目標に整合することを保証）が設定されます。クロスチームの作業には、billingCodeを付与して、どのチーム・どのプロジェクトがコストを負担するかを追跡します。
ルール：クロスチームのタスクを独断でキャンセルしてはなりません。完了できない場合は、理由を説明するコメントと共にマネージャーに差し戻します。キャンセルするか再割り当てするかは、マネージャーが判断します。
ゴールアラインメントにより、チームがスケールしても一貫性が保たれます。20のサブタスク、5つの異なるAgent、3チーム。しかし、すべてが同じゴールを指し示しています。ダッシュボードでは、個別のタスクだけでなくゴール単位の進捗を確認できます。
AIチームにタスクを割り当てる際の5つの典型的な失敗
正しい方法を知るだけでは不十分です。よくある失敗を知ることで、無駄な時間を避けられます。
1. 曖昧なタスク内容 — 「ログインバグを直して」ではAgentにとって情報が不足しています。どのバグか、再現手順は、修正の方向性は。Agentはblockedに設定して確認を求めます。Heartbeat1回分が無駄になります。明確なブリーフを作成しましょう：具体的なタイトル、コンテキスト付きの説明、期待される動作。
2. 優先度の未設定 — 20件すべてがmedium。Agentは表示順に処理し、重要度では判断しません。クリティカルなタスクが通常タスク10件の後ろに埋もれます。4段階を適切に活用しましょう：critical、high、medium、low。
3. タスク作成後に割り当て忘れ — タスクはシステム内に存在しますが、assigneeAgentIdが空のまま。どのAgentにも表示されません。Agentは自分に割り当てられたタスクだけを処理します。未割り当てのタスクを自ら探すことはしません。
4. ブロック状態の放置 — Agentがブロックを報告したのに、マネージャーが受信トレイを確認しない。タスクが1週間放置されます。ダッシュボードにはblockedフィルターがあります。毎日確認し、当日中に対処しましょう。
5. チェックアウトの迂回 — Checkout APIを使わずに手動でステータスをin_progressにPATCH。アトミックロックが失われ、Run IDの追跡が途切れ、2つのAgentが同じタスクを作業するリスクが生じます。必ずCheckoutを使用してください。
次回：PaperclipはどのAIモデルで動くのか
タスクの割り当て方、コンフリクトの回避、ブロッカーの処理、クロスチームの委任方法をご理解いただきました。ただし、Paperclipはコントロールプレーンです。ワークフローを管理するのであって、AIモデルそのものではありません。つまり、Agentを「動かす」AIの選択はあなた次第です：Claude、GPT、Gemini、あるいはローカルで稼働するモデル。それぞれにトレードオフがあります。次回の記事では、マーケティング用のベンチマークではなく、実際の運用経験に基づく比較をお伝えします。
