Antigravity Teamworkとは、複数のAIが提案・批判・改善を繰り返す機能
Antigravity Teamworkとは、複数のAIエージェントがチームを組み、互いの案を提案・批判・改善しながら難しい課題を進めるマルチエージェント機能です。マルチエージェントとは、1つのAIだけで完結させず、役割の異なる複数のAIを協調させる仕組みを指します。
2026年8月時点の提供条件
Googleは2026年8月27日、Teamworkの更新内容をAntigravity公式ブログで公開しました。2026年8月時点では、/teamwork-previewとしてAntigravity 2.0とAntigravity CLIの全有料プランで利用できます。
Teamworkが対象にするのは、数時間から数日かかり、途中で複数の仮説を比較し、反証し、成果物を検証する課題です。単にタスクを並列化するのではなく、他のエージェントの誤りを見つける役割と、検証結果を監査する役割まで含めてチームを構成します。
Antigravity全体の機能・料金・初期設定は、親記事のAntigravityとは？Googleのエージェント型開発ツールの機能・料金・使い方で解説しています。本記事では、その中でもTeamwork固有の仕組みに絞ります。
単なる並列実行ではなく、反証と統合まで自動化する
複数のAIに同じ問題を渡すだけでは、似た案が増えるだけです。さらに、最初の誤りへ全員が同調すると、人数を増やしても結果の確かさは上がりません。
Teamworkは候補を作るエージェントと、候補を壊そうとするエージェントを分けます。そのうえで、批判を踏まえて良い部分を統合し、テストや監査を通った成果物だけを次の工程へ送ります。この「候補生成、反証、統合、検証」の循環が、単純な並列実行との違いです。
Teamworkの仕組み｜役割分担と検証ゲート
Teamworkでは、全体を管理する役割、実際に作業する役割、品質を独立して確かめる役割が階層化されています。オーケストレーションとは、複数の処理や担当を適切な順序で動かし、全体を進行させることです。
SentinelとProject Orchestratorが全体を管理する
利用者が実行を承認すると、Sentinelが依頼内容を記録し、進捗を共有しながらProject Orchestratorへ管理を渡します。Project Orchestratorは課題をマイルストーンに分け、依存関係を見ながら並列作業を割り当てます。
長期タスクでは、同じ管理エージェントが情報を抱え続けません。マイルストーンの節目で構造化された成果物を次の担当へ渡し、会話履歴が増えすぎて判断が鈍ることを避けます。人は個々の作業指示を出すのではなく、目標と受入基準が維持されているかを確認します。
ExplorersとWorkersが調査・実装を分担する
Explorersはコードや資料を読み、変更せずに構造、依存関係、候補案を調べます。Workersは担当範囲を明確に分けたうえで、実装、リファクタリング、テスト作成を行います。
同じファイルを複数のWorkersへ同時に割り当てないことも、公式ドキュメントで示されている安全策の1つです。作業範囲を分離することで、並列化による衝突を抑えます。各エージェントの一時ファイルや記録も分け、主となるプロジェクトへ不要な作業物が混ざらないようにします。
Critic・Challenger・Auditorが別の角度から検証する
実装を担当したAIが自分の成果物を評価すると、前提の誤りを見落としやすくなります。Teamworkは検証を独立した役割へ分けます。
- Critic：正しさ、論理の抜け、堅牢性、インターフェース、既存の書き方との整合をレビューします
- Challenger：境界値、失敗経路、極端な入力、実行時間やメモリの負荷を想定して成果物を崩しにかかります
- Auditor：実行ログとテスト結果を照合し、実際には走っていない検証や見せかけの完了がないかを確かめます
- Success Auditor：最後に全体を通して検証し、依頼時の受入基準を満たしたかを確認します
この構造では、作るAIと評価するAIを分けるだけでなく、レビュー、攻撃的なテスト、証拠の監査も分離します。人が確認する際も「AIが完了と言ったか」ではなく、どの基準をどの実行結果で満たしたかを見られます。
AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。
Teamworkで課題に合わせて選ばれる5つの実行パターン
Teamworkは、固定人数のAIチームを毎回起動する機能ではありません。指示を解析し、課題に合う実行パターンとエージェント数を動的に選びます。途中で問題の構造が分かれば、人数や役割、反復回数も変わります。
| 実行パターン | 向いている課題 | 主な進め方 |
|---|---|---|
| Iterative Coding | 分割しにくい小さな実装 | 1つの案を実装・テスト・修正の短い周期で改善する |
| Distributed Coding | 複数ファイルにまたがる開発 | 作業を分解して並列実装し、Criticが統合前に確認する |
| Document Review | 論文・RFC・設計書の評価 | 複数の観点で批評し、論点と改善案を統合する |
| Long Proof | 未解決問題や長い数学的証明 | 複数戦略を競わせ、反証と統合を繰り返す |
| Self-Verification | 厳密な推論が必要な課題 | 生成・検証・修正を深く繰り返し、各段階を自己検証する |
たとえば、画面1か所の軽微な修正ならIterative Codingが候補です。一方、フレームワーク移行のように複数のモジュールを変更できる課題ではDistributed Codingが合います。利用者が人数や役割を細かく指定するより、課題の目的、制約、検証方法を具体的に伝えると、適切な実行経路が選ばれやすくなります。
パターンは設計図であり、固定されたプログラムではない
Teamworkのパターンは、参加する役割、作業を進める条件、検証ゲートを定めた設計図です。実行コードをパターンごとに作るのではなく、共通の基盤が設計図を読み、必要なエージェントを起動します。
この分離により、反証ループのような仕組みを、コード開発だけでなく文書レビューや数学的問題にも転用できます。ただし、同じ仕組みを使えることと、同じ受入基準を使えることは別です。コードならテスト、文書なら評価観点、研究なら再現や形式検証というように、課題ごとの客観的な確認方法を用意する必要があります。
Teamworkが向いている課題・向かない課題
Teamworkを選ぶ基準は、作業量の多さだけではありません。課題を分担できるか、複数案を比較する価値があるか、結果を独立に検証できるかの3点で判断します。次の表は、Teamworkを使う判断を4つの観点で整理したものです。
| 判断軸 | Teamworkが向いている | Teamworkを見送る |
|---|---|---|
| 課題の規模 | 複数日・複数ファイル・複数分野にまたがる | 1ファイルの小さな修正で終わる |
| 不確実性 | 正解への道筋が複数あり、反証が必要 | 手順と正解がほぼ決まっている |
| 分割可能性 | 調査・設計・実装・検証を分けられる | 作業の依存が強く、1本の短い工程で終わる |
| 検証可能性 | テスト、基準値、評価表で合否を確かめられる | 完成条件を言語化できず、好みだけで判断する |
たとえば、依存パッケージ1個の更新は通常のエージェントで十分です。一方、複数サービスのAPI変更、データ移行、回帰テストを同時に扱うなら、調査と実装と検証を分ける価値があります。Teamworkは「人数が多いほど良い」のではなく、独立した作業と検証を置ける課題で効果を発揮します。
人が先に決めるのはWhatと合格条件
公式ドキュメントは、Teamworkへの依頼を「What, Not How」で組み立てる考え方を示しています。何を達成したいか、誰が使うか、どの制約を守るか、何をもって完了とするかを伝え、手順の分解はAIチームへ任せます。
ただし、Howを任せることは、判断まで手放すことではありません。テストを通す、特定の応答時間を下回る、既存の画面操作を壊さないといった受入基準は人が決めます。Teamworkを使う前に合格条件を書けない課題は、AIを増やす前に要件を整理する段階です。
Antigravity Teamworkの使い方
Teamworkは/teamwork-previewコマンドから起動します。2026年8月時点では、Antigravity 2.0とAntigravity CLIの有料プランが対象です。利用条件や画面は変更される可能性があるため、実行前にGoogle Antigravity公式ドキュメントも確認してください。
1．達成したい結果を具体的に書く
最初に、作りたいものや解決したい問題を1文で書きます。「大規模な移行をして」だけではなく、対象、維持すべき挙動、移行後の状態まで含めます。
たとえば「既存のExpress APIをFastifyへ移行し、TypeScriptの型と現在のAPI互換性を維持し、全テストを通す」と書けば、対象と完了条件の入口ができます。この段階では、エージェントの人数や個別の担当を指定する必要はありません。
2．スコープ・制約・受入基準を対話で固める
コマンド実行直後に、Antigravityのメインエージェントがスコープを確認します。目的がデモか本番か、使ってよいライブラリ、変更してはいけない範囲、性能や安全性の条件を答えます。
さらに、各要件をどう独立検証するかを決めます。既存テスト、参照ベンチマーク、評価スクリプト、明示した採点基準など、第三者が見ても合否を判断できる方法が必要です。確認が終わると、実行用の依頼文が成果物として提示されます。
3．依頼文を確認して実行を承認する
提示された依頼文には、目標、要件、検証方法、受入基準、専用の作業ディレクトリが含まれます。意図と違う点があれば、実行前に直します。
承認後はSentinelとProject Orchestratorがマイルストーンを作り、作業を自律的に進めます。人は進捗報告と成果物を確認し、追加の判断が必要な場面だけ介入します。長時間の処理でも、作業方法を逐一指示する必要はありません。
4．進捗ではなく検証証拠を確認する
完了報告では、変更内容だけでなく、実行したテスト、失敗からの修正、受入基準との対応を確認します。AIが「成功した」と書いていても、実行ログや成果物が無ければ承認しません。
最初の利用では、影響範囲の狭い課題を選びます。既存テストがあり、失敗しても戻せる作業なら、Teamworkの分担と検証がどのように働くかを確認しやすくなります。
職種や業務ごとにAIへ任せる候補を広げたい場合は、職種別AI活用事例集に具体例をまとめています。
全国8,000人調査で、AIの活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
Teamworkの活用例｜研究・システム・開発
Googleは公式ブログで、Teamworkを数学・理論計算機科学、CPUシミュレーション、オープンソース開発へ適用した結果を紹介しています。以下はGoogleの報告であり、すべての利用環境で同じ結果が出ることを保証するものではありません。
長い数学的証明で候補と反証を競わせる
Long Proofパターンでは、複数の解法候補を並列に作り、それぞれに反証役を付けます。反証された案も捨てず、どこで失敗したかを次の候補へ引き継ぎます。選ばれた戦略は依存関係を持つ小問題へ分解され、独立部分は並列、依存部分は順序どおりに進みます。
Googleは、理論計算機科学の未解決問題など7件に取り組み、うち5件の論文をarXivで公開したと説明しています。Knuth’s Cyclesの結果はLeanによる形式検証を行い、それ以外は人間の専門家が確認したとしています。数値だけでなく、誰がどの方法で検証したかまで確認してください。
CPUシミュレーターを実装し、基準系と照合する
システム分野では、Gemini 3.7 Flashを使い、OSを起動できるRISC-V CPUシミュレーターを構築した事例が報告されています。機能が動くだけでなく、隔離した参照シミュレーターと継続的に照合し、サイクル単位のずれを検証しています。
この例が示すのは、複雑な実装をAIへ渡せることより、正解側となる基準系を用意した点です。Teamworkの品質はエージェント数だけで決まらず、比較対象、テスト、測定方法の質に左右されます。
オープンソースの性能改善を外部レビューまで通す
ソフトウェア開発では、EigenとParlayHashの性能改善が紹介されています。Teamworkが候補を作り、ベンチマークで検証し、最終的には外部メンテナーの通常のコードレビューを経て変更が取り込まれました。
AI内部のレビューだけで完了にせず、既存プロジェクトの評価手順を通した点が重要です。実際の利用でも、Teamworkの監査に加えて、組織のコードレビュー、CI、承認フローを残す必要があります。
開発支援を並列化するBefore・After例
たとえば、複数の処理が絡む機能改修を1人で順番に進めると、設計1日、実装2日、レビュー修正1日で計4日かかるケースがあります。Teamworkで調査、設計候補、実装、反証を分担し、人が目標と受入基準を確認すれば、初期案と検証材料を約2日で用意できる可能性があります。
GiftXでも、AIコーディングエージェントを使った機能追加で、平均2日だった作業が平均半日になった事例があります。ただし、これはTeamworkそのものの実測ではありません。複数のAIへ分担する前に、まず1つの開発工程をAIと人の協働で安定させる参考例です。
Teamworkと単一エージェント・サブエージェントの違い
3つの方法はいずれもAIへ作業を任せますが、管理と検証の深さが異なります。ここでは、作業規模、役割分担、品質確認、準備コストの4軸で整理します。短い作業は単一エージェント、独立した調査はサブエージェント、長期で反証が必要な課題はTeamworkという使い分けが基本です。
| 観点 | Antigravity Teamwork | 単一エージェント | 通常のサブエージェント |
|---|---|---|---|
| 主な対象 | 長期・複雑・検証可能な課題 | 短く一貫した作業 | 独立して切り出せる調査や実装 |
| 役割分担 | 管理・実装・批判・監査を階層化 | 1つのAIが一通り担当 | 親AIが個別の子AIへ委任 |
| 品質確認 | Critic・Challenger・Auditorが独立検証 | 自己確認か人のレビュー | 親AIまたは人が結果を統合・確認 |
| 準備 | 目標・制約・受入基準・検証方法が必要 | 通常の指示で開始しやすい | 分割可能な担当範囲を決める |
たとえば、既存コードの関数名を調べるだけならサブエージェントで十分です。複数の移行案を試作し、失敗経路のテストを作り、最終案を監査するならTeamworkの構造が合います。チーム化は高度な選択肢であり、すべての作業の既定にするものではありません。
AIエージェント導入で陥りがちな3つの落とし穴
Teamworkのようなマルチエージェント機能を導入しても、対象と確認方法が曖昧なら成果は安定しません。最初に避けたい3つの進め方を整理します。
いきなり全てをAIチームへ任せる
複数のプロジェクトを同時にTeamworkへ移すと、指示、権限、受入基準のどこに問題があるのか切り分けられません。最初は既存テストがある1つの課題へ絞り、作業の分解と検証ログを確認します。
成功条件を満たせなかったときに元へ戻せる範囲で試すことも重要です。AIチームが動くことではなく、同じ条件で再現性のある成果を出せることを合格とします。
壮大なAI戦略から考えて手が止まる
全体の役割体系や将来の自動化構想を先に作り込むと、最初の実行まで進みません。Teamworkは課題に応じて人数とパターンを変えるため、固定の組織図を設計する必要もありません。
まず、数日かかっている1つの作業を選び、目標、制約、検証方法を短い依頼文にします。実行結果を見てから、次の課題へ共通化できる要素をルールや評価基準として残します。
既製の設定だけで自社の流れに合うと考える
標準の実行パターンがあっても、自分のプロジェクトの合格条件までは自動で決まりません。既存テスト、禁止する変更、性能基準、承認者などを依頼へ組み込まなければ、動く成果物ができても採用できない場合があります。
ツールの設定だけで解決しようとせず、普段のレビューと承認をTeamworkの検証ゲートへ対応付けます。自分たちの作業のどこで品質を判断しているかを言語化する工程が必要です。
まず1業務を小さく任せ、検証手順を固める
AIエージェント導入では、スモールスタートで1業務を自動化・効率化することがポイントです。Teamworkでも、まず1つの課題で目標、受入基準、検証ログの見方を固めます。
1回の成功を再現できる形にしてから、似た作業へ対象を広げます。自社の業務フローに合うAIエージェントの設計から本番運用まで進めたい場合は、GiftX AIエージェント構築支援でご相談いただけます。
Antigravity Teamworkに関するよくある質問
利用前に確認されやすい提供条件と使い分けをまとめます。
Antigravity Teamworkは無料で使えますか
2026年8月時点では、/teamwork-previewはAntigravityの全有料プランで利用できます。無料プランは対象に含まれていません。プレビュー期間中は提供条件が変わる可能性があるため、実行前に公式ドキュメントを確認してください。
Teamworkを使うとエージェント数を指定できますか
通常は課題に応じてAntigravityが実行パターンと人数を動的に決めます。「非常に大きなチームを使う」のように規模を明示して大規模なMath・Proof経路を選ぶ方法はありますが、一般的な開発では人数より目標と検証方法を具体化するほうが重要です。
Teamworkはコーディング以外にも使えますか
使えます。公式ドキュメントにはDocument Review、Math・Proof、システムシミュレーションなどの経路が示されています。ただし、文書なら評価表、研究なら再現や形式検証というように、対象に合う受入基準が必要です。
TeamworkとAgent Teamsは同じ意味ですか
Antigravityの公式ドキュメントでは、Teamworkを「agent teams」と説明しています。一般名詞としてのAgent Teamsは他製品にも使われますが、Antigravityでは/teamwork-previewで起動する機能を指します。他製品の同名機能と役割や提供条件が同じとは限りません。
まとめ
Antigravity Teamworkは、複数のAIエージェントへ作業を分けるだけでなく、提案、反証、統合、監査を一連の流れとして動かす機能です。向いているのは、長期で複雑、複数案を比較でき、テストや評価表で完了を確かめられる課題です。
利用時は/teamwork-previewから目標を伝え、対話で制約と受入基準を固めます。最初から大きなプロジェクトを任せず、既存テストがある1つの課題で検証方法を型にしてから広げると、チーム化の調整コストを抑えられます。
複雑な業務へのAIエージェント導入をご検討の方へ
本記事で紹介したAntigravity Teamworkの考え方を、自社の業務でも具体的に進めたい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、PoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら
