Claude Code や Cursor などのAIコーディングエージェント（自然言語の指示でコード変更を自律的に行うツール）を複数同時に動かす場面が増えています。1つのチャットで1エージェントに任せるうちは問題にならなくても、2つ3つと並走させ始めると「あのエージェントは何をしていたか」「今どこがブロックされているか」が見えなくなります。
この記事は、複数のコーディングエージェントを運用し始めたエンジニア、またはこれから並列化を検討しているチームリーダーに向けた内容です。エージェント同士の作業管理をどう設計するか、その判断材料を整理しました。
なぜエージェントが増えると管理が破綻するのか
エージェントは会話（セッション）が終わると、そのセッションで積み上げた文脈をほぼ失います。
次のセッションで同じ作業を再開しようとすると、エージェントに毎回「今の状況」を説明させ直すか、人間が記憶を頼りに状況を再構築するしかありません。
これは1人でエージェントを使っているときはそれほど問題になりません。
ですが複数エージェントが同時に別タスクを進めると、誰が何を終えて何がブロックされているかという「進捗の地図」を誰も持っていない状態になりやすくなります。
よくある対処は、エージェントに都度ステータス報告を求めることです。
これは機能しますが、報告のたびにプロジェクト全体の状況を再構築させる処理が走るため、時間とトークン（APIの課金単位であり処理するテキスト量の目安）を消費します。
また「計画を立てて」とエージェント任せにすると、「2〜3週間かかります」といった見積もりだけ出して、そのまま一気通貫（one-shot）で作業を進めてしまい、途中経過やドキュメント更新が抜け落ちることもあります。
判断軸1: 永続化されたタスク管理が必要か
ソフトウェア開発チームはこの種の問題を、イシュートラッカー（Jira や GitHub Issues のようなタスク管理ツール）で解決してきました。
Beads はこの考え方をコーディングエージェント向けに作り直したコマンドラインツールです。
コマンド名は bd で、チャットやMarkdownのTODOリストのような「消えてしまうメモ」ではなく、説明・優先度・ステータス・依存関係を持つイシューとして作業を記録します。
このイシューはエージェントの会話が終わっても残るため、新しいセッションが前のセッションの記憶に頼らず作業を再開できます。
永続化が必要かどうかを見極める基準は単純です。
「このエージェントのセッションが終わったら、今の作業状況を誰がどう引き継ぐか」を自分で即答できない場合、永続化の仕組みを検討する価値があります。
判断軸2: 依存関係の管理が必要な規模か
単発のバグ修正を1エージェントに頼む程度であれば、依存関係の管理は不要です。
ですが「データベース変更が終わらないとAPI更新に着手できない」のような、タスク間に前後関係があるプロジェクトでは話が変わります。
Beads はこの関係を記録でき、bd ready というコマンドでブロッカーのないタスクだけを一覧表示します。
実際の出力は次のようなイメージです。
$ bd ready
○ Racing_event_tracker-lj6m P1 [epic] Feeder series: correct calendars + session times
○ Racing_event_tracker-fwke P2 Waza follow-up: contain copilot-sdk executor
○ Racing_event_tracker-xdx8 P2 [bug] Stale past events linger in gold/upcoming.jsonIDと優先度、種別（epicやbugなど）、タイトルが一覧になっており、エージェントはここから着手可能なタスクを選んで bd update <id> --claim で取得し、終わったら bd close <id> で閉じます。
閉じたタスクが別タスクのブロッカーだった場合、そのタスクが自動的に bd ready に現れるようになります。
依存関係の可視化が必要かを判断する基準は、「タスクの順序を間違えると手戻りが発生するか」です。
順序を間違えても大きな影響がない小規模な修正の積み重ねなら、わざわざ依存グラフを組む必要はありません。
判断軸3: 並列実行する余力があるか
Beads は1エージェントでも導入できますが、真価が出るのは並列実行です。
独立して進められるタスクが複数あり、それを担当する複数のエージェント（サブエージェント）を用意できる場合、オーケストレーター役のエージェントが bd ready を見て独立タスクを各サブエージェントに割り振れます。
逆に言えば、トークンやAPIのリクエスト上限に余裕がない、あるいは並行して進められるタスクがそもそも少ないプロジェクトでは、導入のメリットが薄くなります。
並列化の余力があるかは、トークン予算とタスクの独立性の両方で確認する必要があります。
判断軸4: 導入・運用コストをどこまで許容できるか
セットアップ自体は軽量です。
brew install beads
cd your-project
bd initbd init を実行すると AGENTS.md（エージェント向けの作業指示ファイル）が作成または更新され、エージェントがリポジトリに入った際にワークフローを認識できるようになります。
ここで生成された内容をそのまま使うのではなく、自分のチームの運用に合わせて書き換える作業は発生します。
導入後はエージェントが自律的に bd ready → bd show <id> → bd update <id> --claim → bd close <id> というループを回すため、人間側の運用負荷はさほど大きくありません。
ただしイシュー管理のルール（優先度の付け方、epicの切り方など）をチームで合意しておかないと、エージェントが作るイシューが雑多になり、結局人間が整理し直す羽目になります。
選択肢の比較
| 運用スタイル | 向いているケース | 導入コスト |
|---|---|---|
| チャット内TODO管理 | 単発タスク・1エージェント運用 | ほぼゼロ |
| Markdownの進捗ファイル | 小規模プロジェクト・履歴重視 | 低いが更新漏れが起きやすい |
| Beads等の専用トラッカー | 複数エージェント並走・依存関係が複雑 | 中程度、運用ルール整備が必要 |
ケース別の推奨
- 1エージェントで単発のバグ修正や小さな機能追加をこなすだけなら、チャット内のやり取りで十分です
- 複数のエージェントを日常的に使い、タスクの引き継ぎで毎回状況説明をさせているなら、Beadsのような永続イシュー管理の導入を検討する価値があります
- タスク間に明確な依存関係があり、順序を誤ると手戻りが発生するプロジェクトなら、
bd readyによる依存グラフ管理が効いてきます - オーケストレーター役のエージェントが複数のサブエージェントにタスクを割り振る構成を組みたいなら、Beadsの並列運用がそのまま活用できます
あえて見送るべき条件
- プロジェクトが小規模で、タスクの並列度が低く、1エージェントで事足りているなら、ツール導入は過剰投資です
- トークン予算やAPIリクエスト上限が厳しく、エージェントを複数同時に動かす余地がないなら、並列運用のメリットは発生しません
- チーム内でイシューの優先度や粒度のルールを決める余裕がなく、運用ルール整備に時間を割けないなら、イシューが乱立して逆に混乱が増える可能性があります
- 既存のJiraやGitHub Issuesなど人間向けのトラッカーとエージェントの作業を厳密に同期させたい場合、Beads単体では完結せず別途連携の仕組みが必要になる点は確認しておく必要があります
まとめ
複数のAIコーディングエージェントを運用する際の管理負荷は、エージェントの数と作業の複雑さに比例して増えていきます。
判断軸としては、永続化の必要性・依存関係の複雑さ・並列実行の余力・運用コストの許容度の4点を自分のプロジェクトに当てはめてみてください。
まずは brew install beads と bd init を1つの小さなプロジェクトで試し、bd ready の出力がチームの状況把握にどれだけ役立つかを確認するところから始められます。
導入するかどうかは、エージェントの会話が途切れるたびに発生している「状況説明コスト」が、実際にどれだけ積み重なっているかで判断するのが現実的です。