AIエージェントスウォーム徹底解説：プランナー、ワーカー、ベリファイア

TL;DR

AIエージェントスウォーム（群れ）は、1つのゴールを3つの役割に分割して実行します。作業をタスクに分解する「プランナー」、隔離されたワークスペース内でそれらのタスクを並行して実装する「ワーカー」、そしてすべての変更をマージ前にテスト・検証する「ベリファイア（検証役）」です。プランナーとベリファイアには最も強力なモデルを割り当て、ワーカーには安価で高速なモデルを使います。このパターンが破綻するのは、ワーカー間でファイルを共有してしまったとき、ベリファイアが形式的な承認（形骸化）に陥ったとき、あるいはコスト上限を設定していないときです。

なぜ今、AIエージェントスウォームが再び注目されているのか

GoogleがGemini 4 Carbonを一般提供（GA）し、Google Antigravityで単一のプロンプトからエージェントの協調チームを編成する/swarmのプレビューを公開しました。Googleの言葉を借りれば、Carbonは「アーキテクチャ設計、連携、監査」を担当し、「並行して動作する隔離されたワークスペース上のより高速で軽量なモデルと、あらゆる変更をテストする敵対的（アドバーサリアル）なベリファイア」と組み合わされます。

この説明が示しているのは、手持ちのモデルでもすでに実践できるパターンです。本ガイドでは、3つの役割、プランニングと検証にコストをかけるべき理由、スウォームが破綻しやすいポイント、そして共有ボード上でスウォームを運用する方法について解説します。すでに複数のコーディングエージェントを運用している場合、Sharklyを使えば各エージェントにTask、実行ログ、レビュー手順を割り当てることができ、スウォームに必要な要素の大部分をカバーできます。

AIエージェントスウォームとは何か

AIエージェントスウォームとは、1つのゴールを複数の独立したタスクに分割し、同時に処理を進めるAIエージェントのグループのことです。1つのエージェントが作業を計画して割り当て、複数のエージェントが並行して実行し、1つ以上のエージェントがマージ前に各成果物をチェックします。それぞれの役割には明確に限定された責任と、明確な引き継ぎフローが存在します。

Anthropicは2024年に同様の構成をオーケストレーター・ワーカー（orchestrator-workers）パターンとして提唱しました。中央のモデルがタスクを分解して個々の作業を委譲し、最終的な結果を統合する仕組みです。ベリファイアはそこに新しく加わった要素であり、多くのチームが見落としがちな役割でもあります。

スウォームとは「多数のエージェントが同じ作業をする」ことではありません。同一のリポジトリに対して同じプロンプトを与えた5つのエージェントを走らせても、それはチームではなくレースコンディション（競合状態）を生むだけです。明確な役割分担があってこそスウォームとして成立します。エージェントをどのように連携させるかという全体像については、AIエージェントオーケストレーションとは何かを参照してください。

3つの役割：プランナー、ワーカー、ベリファイア

それぞれの役割は異なる問いに答え、それぞれ異なるコンテキストを必要とします。

プランナーの役割とは？

プランナーは、曖昧なゴールを互いに重複しないタスクへと分解します。優れた計画では、各タスクが変更してよいファイル、完了を証明するテスト、そしてタスク間に依存関係がある場合の実行順序が明確に指定されます。2つのタスクが同じファイルを必要とする場合、プランナーはそれらを1つのタスクに統合するか、順次実行するようにスケジュールします。

ワーカーの役割とは？

ワーカーは、並行して割り当てられた1つのタスクだけを実装します。各ワーカーには専用のワークスペースが与えられます。通常はgit worktree（同一リポジトリを個別のブランチにチェックアウトしたもの）が用いられます。この隔離環境があるからこそ、3つのワーカーが互いの変更を上書きすることなく、同時にコードを編集できるのです。詳細については、隔離されたworktreeでの並行エージェント運用をご覧ください。

ベリファイアの役割とは？

ベリファイアは、変更に不備や誤りがないかを徹底的に暴こうとします。Googleは「敵対的（アドバーサリアル）」という表現を使っていますが、まさにその通りです。ベリファイアはテストを実行し、タスク要件に照らしてdiffを精読し、ワーカーが手抜きをしていないかを探ります。単に「テストが通ったか？」と確認するだけのベリファイアでは、テストを無理やりパスするように書き換えてしまったワーカーを見逃してしまいます。

なぜ高価なモデルを計画と監査に使うのか

計画と検証は、読み込む情報量は少ないものの失敗したときの影響が非常に大きい工程です。一方で実装作業は、出力トークン数は多いものの1行あたりのリスクは比較的小さく済みます。この非対称性によって、どのモデルをどこに配置すべきかが決まります。

プランナーが書くのはせいぜい数百行のタスク記述です。ベリファイアが書くのも判定結果だけです。どちらも出力トークン数は多くないため、トークン単価が高いプレミアムモデルを使っても総コストはそれほど膨らみません。トークンの大半を消費するのはワーカーであるため、そこに安価なモデルを充てることで最大のコスト削減効果が得られます。

失敗による影響の広がり方も異なります。不適切な計画はすべてのワーカーを迷走させ、甘いベリファイアはあらゆる欠陥のある変更を素通りさせてしまいます。一方、能力の劣るワーカーが質の悪いdiffを作ったとしても、ベリファイアがそれを検知してくれます。ミスが何倍にも増幅される箇所にこそ、最高峰の判断力（強いモデル）を投入すべきです。

Google自身のポジショニングもこの役割分担を裏付けています。Gemini 4 Argonは「大半のソフトウェアエンジニアリングやナレッジワークにおいて依然として理想的な選択肢」であるとする一方、Carbonは「徹底的に探索し、深く推論し、長期的な検証ループを実行する」ためにより多くのトークンを使用します。Carbonの価格は2026年11月30日まで入力100万トークンあたり2ドル、出力100万トークンあたり10ドルで、それ以降は4ドルと20ドルになります。モデルの詳細については、コーディングエージェント向けGemini 4 Carbonおよびコーディングエージェント向けGemini 4 Argonをお読みください。同じ論理はあらゆるモデルの組み合わせにも当てはまります。安価なワーカーと高価なレビュアーによるハイブリッドモデル構成のCrewも参照してください。

AIエージェントスウォームが破綻する原因

スウォームの失敗の多くは、3つの落とし穴から生じます。状態の共有、チェックの甘さ、そして予算・リトライ上限の欠如です。

なぜエージェント同士が互いのコードを上書きしてしまうのか？

計画で禁止されていなかったために、2つのワーカーが同じファイルに手をつけてしまうことがあります。隔離されたワークスペースがなければ、後から書き込んだ方の内容が優先され、最初のワーカーの変更は消え去ってしまいます。ワークスペースを隔離していても、マージの段階で両方の変更が衝突（コンフリクト）します。この問題の解決策は計画段階にあります。タスクごとにファイルの所有権を明確に割り当て、同じファイルを共有するタスクは直列化（順次実行）することです。

なぜベリファイアは形骸的な承認をしてしまうのか？

diffではなくワーカーによる要約（サマリー）を読むベリファイアは、実際の成果物ではなく単なる「主張」を評価しているに過ぎません。「すべてのテストに合格しました」という記述を見て、そのまま鵜呑みにしてしまうのです。ベリファイアにはワーカーの自己報告ではなく、生のdiffとテスト出力を直接渡してください。また、ワーカーと同じ盲点を共有しないよう、ワーカーとは異なるモデルでベリファイアを動かすことも重要です。レビュー用エージェントが確認できること・できないことについては、AIコードレビューエージェントで解説しています。

スウォームのコストはなぜ跳ね上がるのか？

リジェクトされるたびに再実装と再レビューが発生するため、3回失敗したタスクは実装とレビューがそれぞれ4回分発生します。10体のワーカーが一晩中リジェクトループに陥れば、1週間分の予算が一瞬で吹き飛ぶことになります。タスクごとのリトライ回数に上限を設け（デフォルトとしては2回が妥当です）、同時実行ワーカー数を制限し、最後のリトライが失敗したタスクは人間にエスカレーションするようにしましょう。

さらにこれらの下には、4つ目の失敗要因が隠れています。計画、実行履歴、判定結果がすべて単一のコンテキストウィンドウ内に混在していると、誰もその結果を監査できなくなります。スウォームの外部にいる何者かが、常にその動向を監視していなければなりません。

共有ボード上でAIエージェントスウォームを運用する方法

スウォームを運用するのに、専用のスウォームツールは必須ではありません。必要なのは、タスク、隔離されたワークスペース、そしてゲート（承認の関所）です。共有ボードを使えばこの3つがすべて揃い、人間がいつでも確認できる形で記録を残すことができます。

1. ゴールに対して1つの親タスクを作成する。 プランナーがそれを読み取り、対象ファイルと受け入れテストを明記したサブタスクとして計画を作成します。
2. 各ワーカーに厳密に1つのタスクを割り当てる。 1つのタスク、1つのエージェント、1つのブランチ。2つのサブタスクが同じファイルを共有している場合は、作業を開始する前に統合します。
3. 各タスクを専用のディレクトリで実行する。 実行ごとにworktreeを用意することで、並行したコード編集が干渉するのを防ぎます。
4. 「Done（完了）」の前に「Review（レビュー中）」ステータスを設ける。 ワーカーの自己申告だけでタスクを完了にしてはなりません。
5. より強力なモデルのベリファイアエージェントにレビューを割り当てる。 diffとテスト出力を読み込み、タスクを承認するか、理由を添えて差し戻します。
6. 最後のステップに人間を配置する。 ベリファイアが対象を絞り込み、人間が最終的な成果物を承認します。

Sharklyではこれがどのように実現されるかを説明します。Crewは、1つのリーダーエージェントによって統括される、人間とエージェントの再利用可能なグループです。親TaskをCrewに割り当てると、まずリーダーが起動します。Taskを読み取ったリーダーは、個々の作業のためにメンバーエージェントをアサインし、それぞれの成果物を統合します。この「リーダーが先」という順序により、計画が整う前にワーカーが勝手に動き出すのを防ぎます。

一時的な作業ディレクトリモード（working-directory mode）にあるエージェントにはTaskごとに隔離されたディレクトリが割り当てられ、リポジトリベースの実行では新しいworktreeが準備されるため、並行して動くワーカー同士がファイルを共有することはありません。各エージェントは設定したランタイム上で動作するため、リーダーやレビュアーにはワーカーよりも強力なモデルを割り当てることができます。

レビューゲートは、Taskワークフロー内のステータスとして機能します。エージェントタスク実行のドキュメントで説明されているように、エージェントはTaskを人間のレビュー待ち状態にすることができ、その引き継ぎはメインサイドバーのTask Chatsモジュールに表示されます。失敗した実行やブロックされた実行もインボックスに届きます。エージェントは調査、実行、テスト、レポートを担当し、人間は方向性の設定、権限の付与、成果物の承認を担います。Sharklyは無料で使い始めることができます。1台のComputerを接続し、2つのAgentを作成して、Crewに小さめのタスクを割り当ててみてください。人間の役割についての詳細は、並行エージェントのためのレビュー設計をご覧ください。

AIエージェントスウォームが不要なケース

作業を分割できない場合は、スウォームを使う必要はありません。単一のバグ修正、1ファイルのみのリファクタリング、あるいは一連の長い思考プロセスを要するタスクであれば、1つの強力なエージェントと1人のレビュアーで進める方が早く済みます。独立したタスクが3つ未満の場合、調整にかかるコストが並行処理によって得られるメリットを上回るのが一般的です。

スウォームが真価を発揮するのは、異なるファイルに手を加える複数の作業にゴールを分解できる場合です。たとえば、複数パッケージにまたがるマイグレーション、モジュール横断のテスト追加、あるいは1つのAPI変更を10個のサービスに適用するようなケースです。Googleもマルチエージェント環境においてCarbonが得意とするタスクとして、「マルチパッケージマイグレーション」や「サブシステム横断の根本原因調査」を挙げています。

まとめ

AIエージェントスウォームとは、1つの巨大なプロンプトではなく、「計画」「実装」「検証」という3つの役割で構成される仕組みです。計画と判定には最良のモデルを投入し、実装には安価なモデルを使い、すべての成果物を人間が確認できる場所に残しましょう。まずは1つの親タスク、3つのワーカー、そして1つのベリファイアから始めてみてください。すでにお使いのエージェントでこの構成を試すには、SharklyにComputerを接続して、最初のCrewにタスクを割り当ててみましょう。

FAQ

エージェントスウォームとマルチエージェントオーケストレーションの違いは何ですか？

オーケストレーションとは、複数のエージェントを連携・調整する全般的な手法を指します。スウォームはそのオーケストレーションパターンの1つであり、プランナー、並行ワーカー、ベリファイアという固定された役割分担を持つのが特徴です。すべてのスウォームはオーケストレーションされていますが、すべてのオーケストレーションがスウォームというわけではありません。

AIエージェントスウォームは何体のエージェントで構成すべきですか？

まずはプランナー1体、ワーカー3体、ベリファイア1体から始めるのがおすすめです。タスクの独立性が保たれ、レビューキューの消化が追いついている場合にのみワーカーを増やしてください。レビュー可能な処理能力を超えてワーカーを増やしても、ボトルネックがベリファイアに移るだけです。

プランナーとベリファイアを同じエージェントにすることはできますか？

同じモデルを使用することは可能ですが、実行とコンテキストは必ず分けてください。自ら立てた計画の成果物をプランナー自身がレビューすると、甘い承認になりがちです。独立した新しいベリファイアであれば、プランナーの思い込みや前提にとらわれずにdiffを検証できます。

エージェントスウォームを実行するにはGoogle Antigravityが必要ですか？

いいえ、必要ありません。/swarmはAntigravity内のプレビュー機能ですが、このパターンに必要なのはタスクの分割、隔離されたワークスペース、そしてレビュー手順だけです。現在利用している任意のコーディングエージェントを使い、git worktreeとタスク管理ボードを組み合わせることで構築できます。

スウォームのワーカーが同じファイルを編集するのを防ぐにはどうすればよいですか？

計画の段階でファイルの所有権を割り当ててタスクの重複を防ぎ、隔離されたワークスペースによってマージ時まで各ワーカーの変更を個別のブランチに保持します。さらにCODEOWNERSのルールを設定すれば、レビュー時のチェックを追加できます。