Antigravity /teamworkとは？使い方・料金・/swarm・/boostとの違いを解説【2026年11月】

Antigravityの /teamwork は、複数のAIエージェントがチームを組み、数時間〜数日かかる大きな開発や調査を進めるスラッシュコマンドです。最初に面談で「何を作るか」と「どうなれば合格か」を決め、承認したあとはエージェント同士で実装・レビュー・検証を繰り返します。

この記事では、/teamwork の仕組み、使えるプランと日本円の料金、使い方の手順、/swarm・/boost との使い分け、長時間動かすときの安全な設定を、2026年11月15日時点の公式情報をもとに整理します。Google Antigravityをすでに使っている開発者と、大きな移行や書き換えをAIに任せられるか検討しているエンジニア・開発責任者に向けた内容です。

使うかどうかを決めるときの判断材料は、次のとおりです。

• /teamwork は、リポジトリ全体の移行や長期の調査など「1回のエージェント作業では終わらない仕事」向けの機能です
• 公式では有料プラン限定です。日本では Google AI Pro（月額2,900円）以上なら使えます。Google AI Plus で使えるかは公式に明記がありません
• 数分〜数時間の作業なら /swarm、難しいバグ1つなら /boost のほうが合います。日常の小さな作業には向きません
• 長時間の自律実行になるため、権限プリセットは Default のままにし、AIクレジットの自動購入は止めておくのが安全です

Antigravity そのものをまだ知らない方は、先にGoogle Antigravityとはで全体像をつかんでおくと読みやすくなります。

Antigravity /teamworkとは

出典: Google Antigravity 公式ドキュメント

/teamwork は、Google Antigravity で複数のAIエージェントのチームを起動するコマンドです。公式ドキュメントは「大規模なソフトウェアプロジェクト、複雑なシミュレーション、深い調査のための協調型マルチエージェントチーム」と説明しています。

スラッシュコマンド一覧では「Reasoning」の区分に入り、例として「リポジトリ全体の移行や調査など、数日かかる大きな仕事」が挙げられています。公式が出している具体例は「RESTバックエンドを Express から Fastify へ、テストの結果を変えずに移行する」です。

基本情報

「/teamwork-preview」から「/teamwork」へ

Teamwork は Google I/O で最初に発表され、2026年8月27日の Antigravity 公式ブログで「全有料プランで /teamwork-preview として提供開始」と案内されました。現在の公式ドキュメントでは、コマンド名は /teamwork です。

名前が変わった日は、公式の更新履歴では確認できません。ただ、11月10日の CLI v1.5.5 の修正内容にはすでに /teamwork と書かれています。11月13日には Google Research が「/teamwork の外部公開」として Gemini 4 世代のモデルとあわせて紹介しました。古い記事で /teamwork-preview と書かれていても、今は /teamwork と入力すれば動きます。

なお、Zenn や Qiita で見かける /team などは、利用者が自分で作ったワークフローです。公式の /teamwork とは別のものです。

複数のエージェントが分担して動く考え方そのものは、マルチエージェントAIとはで詳しく解説しています。

/teamworkでできること

出典: Google 公式ブログ

/teamwork が得意なのは、ゴールがはっきりしていて、途中で何度も確認が要る長い仕事です。公式ドキュメントと公式ブログに出てくる用途を、開発の現場に置き換えると次のようになります。

毎回指示を出し直さなくても、承認した仕様に沿って最後まで進むのが特徴です。反対に、ゴールがあいまいなまま「とりあえず改善して」と頼む使い方には向きません。

/teamworkの仕組み

出典: Google Antigravity 公式ブログ

/teamwork は「面談で仕様を固める段階」と「チームが自律で進める段階」の2段階で動きます。人が決めるのは最初の仕様と最後の確認で、その間の実装とレビューはエージェントが受け持ちます。

段階1：スコーピング面談で仕様を決める

最初に「Sentinel」というエージェントがユーザーに質問します。決めるのは次の5つです。

• 作業の範囲と目的
• 要件
• 各要件を客観的に確かめる方法
• 受け入れ基準（どうなれば完了か）
• 作業ディレクトリ

公式の指針は「specify what, not how（どうやるかではなく、何をするかを指定する）」です。面談の結果は、拘束力のある仕様書としてプロンプトのアーティファクトにまとめられます。ユーザーがこれを承認するまで、実行は始まりません。

段階2：チームが自律で進める

承認後は、リクエスト・プロジェクト計画・進捗の3つのアーティファクトを更新しながら作業が進みます。チームの役割は、社内のプロジェクトチームにたとえるとわかりやすくなります。

各マイルストーンには、作った人とは別のレビュー役が関門として入ります。

Google Research の説明では、各エージェントにはそのステップに必要なファイルとツールだけを渡します。レビュー役と監査役は、まっさらなコンテキストから結果を確かめます。数日続く作業でAIの注意が散ったり、自分で書いたものに自分で合格を出したりするのを防ぐ作りです。

実行パス（進め方のパターン）

公式ドキュメントには5つの実行パスが載っています。どれを使うかは、Gemini がプロンプトの内容から自動で選びます。

8月の公式ブログでは、Iterative coding・Distributed coding・Long proof・Self-verification・Document review の5パターンとして紹介されていました。Google Research は、形式証明やリライト向けのパターンを今後追加するとしています。

整合性モード（どこまで厳しく確かめるか）

面談の中で、検証の厳しさを3段階から選びます。選んだモードはプロンプトのアーティファクトに記録されます。

作業場所と記録

作業は既定で ~/teamwork_projects/{PROJECT_NAME} という専用フォルダで行われます。普段使っているリポジトリに直接書き込まない設計です。同じファイルを2つの Worker が同時に編集しないよう担当が分けられ、エージェントごとに作業用ディレクトリが用意されます。状態の変化、実行したコマンド、レビュー、検証の結果はすべてアーティファクトに残ります。

/teamworkの強み

/teamwork の強みは、長い仕事を「仕様を決める人」と「確かめる仕組み」で挟み込んでいる点にあります。

1. 最初に合格条件を決める: 面談で受け入れ基準と確認方法を決めるので、途中でゴールがずれにくくなります
2. 作った人と確かめる人が別: Critic・Challenger・Auditor が独立して関門に立つため、「テストが通ったことにする」ような手抜きを見つけやすくなります
3. 数日単位でも続けられる: コンテキストを役割ごとに分けているので、長時間の作業でも前提を見失いにくい作りです
4. 普段のリポジトリを汚さない: 専用フォルダで作業し、記録がすべて残ります。結果を見てから取り込むかどうかを決められます

/teamworkの弱みと制約

一方で、手軽に試せる機能ではありません。

• 無料プランでは使えない: 公式に有料プラン限定と書かれています
• 使用量の目安が出ていない: 1回の /teamwork でどれだけクォータを消費するかは、公式ドキュメントにも公式ブログにも書かれていません。公式は「複雑なタスクほどクォータを多く使う」とだけ説明しています
• 小さな作業には大げさ: 面談から始まり、複数のエージェントが動くため、数行の修正や1ファイルの変更には向きません
• Iterative coding はタスクを分解しない: 1つのまとまった変更向けで、大きな仕事を分けて進めたいときは General を使う前提です
• 既定のモデルが明記されていない: /teamwork を実行したときにどのモデルが使われるかは、公式ドキュメントでは確認できません
• 人の確認は欠かせない: Google Research も「問題を設定するのは人で、出力は人が検証・簡略化・編集した」と書いています。Lean の証明でも、形式化した命題が元の問題と一致しているかは人が確かめています

/teamworkの料金と使えるプラン

/teamwork 単体の追加料金は、公式には書かれていません。契約しているプランのクォータを使い、足りない分はAIクレジットで補う仕組みです。

日本の料金（2026年11月15日時点）

料金は Google AI プランの公式ページの表示です。公式ドキュメントは対象を「Paid plans」とだけ書いており、Plus が含まれるかははっきりしません。確実に使いたいなら Pro 以上を選んでください。海外の解説記事には「Ultra限定」と書いたものもありますが、公式ドキュメントと公式ブログはどちらも「有料プラン」としています。

クォータとAIクレジット

公式ドキュメント（Plans）によると、Pro は5時間ごとに回復する高いクォータ（週の上限あり）、Ultra は5時間ごとに回復する最大のクォータと最大の週の上限が付きます。上限は変わることがあると明記されています。

Pro と Ultra では、基本のクォータを超えた分をAIクレジットで払えます。単価は Gemini Enterprise の従量課金と同じです。設定の「AI Credit Overages」が「Always」になっていると、クォータを使い切ったあと自動でクレジットが使われます。数日動く /teamwork の前には、ここを「Never」にしておくと費用がふくらみません。CLI では /usage と /credits で残量を確かめられます。

企業で使う場合

Antigravity の App・CLI・IDE拡張は、Gemini Enterprise 経由でも使えます。ただし、/teamwork が Business・Enterprise のアカウントで使えるかは公式ドキュメントに書かれていません。社内導入を考えているなら、管理者が実際の画面か Google Cloud の窓口で確かめてから進めてください。

/teamworkの使い方

使い方は「入力する → 面談に答える → 仕様を承認する → 進捗を見る」の4ステップです。App でも CLI でも流れは変わりません。

手順

1. /teamwork <やりたいこと> と入力する

   例：/teamwork RESTバックエンドをExpressからFastifyへ移行する。既存のテスト結果は変えない

2. Sentinel の面談に答える

   範囲、要件、確認方法、受け入れ基準、作業ディレクトリ、整合性モードを聞かれます

3. 生成された仕様（プロンプトのアーティファクト）を読んで承認する

   承認するまで実行は始まりません。ここで受け入れ基準を必ず読み直します

4. 進捗のアーティファクトを見ながら待つ

   承認が必要な操作が出てきたら、メイン画面かサブエージェントのパネルに表示されます。CLI では Alt + J で承認待ちのサブエージェントへ移れます

CLI をまだ入れていない方は、Gemini CLIからAntigravity CLIへの移行で導入手順を確認できます。

面談でうまく答えるコツ

面談の出来が結果を左右します。公式の指針「何をするかを指定し、どうやるかは任せる」に沿って、次の3点を具体的に伝えます。

実装のやり方まで細かく指定すると、チームに任せられる部分が減ります。逆に「どうなれば完了か」があいまいだと、レビュー役が合否を判断しにくくなります。

/swarm・/boost・サブエージェントとの違い

出典: Google Antigravity 公式ドキュメント

Antigravity には、/teamwork 以外にも複数のエージェントを動かす機能があります。違いは仕事の大きさと始まり方です。公式ドキュメントの /swarm のページにある比較表と各機能のページをもとに整理しました。

/swarm はワーカーがそれぞれ別のエージェントとして動くため、クォータの減りが速いと公式に書かれています。全プランで使える /plan（計画を立て、承認後に実行）、/goal（目的を達成するまで止まらず進める）、/grill-me（設計を1問ずつ確認する）も、使い分けの候補になります。

どれを使うかの早見表

Claude Code のエージェントチームとの違い

Anthropic の Claude Code にも、複数のエージェントを協調させる機能があります。考え方は近いものの、/teamwork は「最初の面談で仕様を固め、独立したレビュー役の関門を必ず通す」形が決まっている点が特徴です。Claude Code 側の仕組みはClaude CodeのエージェントチームとClaude Codeのサブエージェント活用ガイドで解説しています。

/teamworkを安全に動かすための設定

長時間、人が見ていないところでエージェントが動くため、権限と費用の設定は最初に決めておきます。基本は「権限は Default のまま、危ない操作は禁止、クレジットの自動購入は止める」です。

権限プリセットの選び方（App）

ターミナルのサンドボックスは、既定でネットワークなし、触れるのはワークスペースと一時フォルダだけです。サブエージェントは親のコマンド許可・読み書きの範囲・サンドボックスの設定をそのまま引き継ぎます。CLI では --dangerously-skip-permissions（always-proceed）を付けると確認がすべて省かれるので、/teamwork では使わないほうが安全です。

避けたい設定と入れておきたい禁止ルール

公式ドキュメント（Permissions）の注意書きから、長時間の実行で特に気をつけたい点を整理しました。

• command(*)・read_file(*)・mcp(*) のようなワイルドカードの許可は範囲が広すぎます
• command(git) を許可すると git push も含まれます
• 承認カードで範囲を広げると、もとの依頼より広い許可になることがあります
• 中身を確かめていない MCP ツールは、レビューなしで動いてしまいます
• rm -rf・sudo・.git/ への書き込み・~/.ssh への書き込みは Deny（禁止）にしておきます

ルールは Deny が最優先で、次に Ask、最後に Allow の順に適用されます。

バージョンを最新にする

11月10日の CLI v1.5.5 で、「/teamwork が作業ディレクトリに .agents/teamwork/ の実行状態を書き込む」不具合が直りました。古いバージョンのままだと、普段のリポジトリに状態ファイルが残るおそれがあります。App と CLI は最新にしてから使ってください。

企業のデータの扱い

Gemini Enterprise 経由で使う場合、テレメトリとモデルとのやり取りは自社の Google Cloud プロジェクトに記録されます。Claude などほかのモデルを選んでいても、裏でコンテキスト管理に Gemini が使われ、その分の課金が発生することがあります。学習への利用の扱いは Enterprise のページに書かれていないため、社内規程で確認が必要な会社は事前に問い合わせておくと安心です。

AIエージェント全般のリスクと対策は、AIエージェントとはでもまとめています。

Googleが発表した/teamworkの成果

出典: Google Research 公式ブログ

Google は /teamwork を使った研究・開発の成果を相次いで公表しています。数字は大きいですが、どれも Google 自身の発表で、査読前の論文や社内の評価を含みます。

2026年11月13日の Google Research の発表

成果の大半は Gemini 4 Argon で出したと書かれています。

• 2013年に出された Courtade–Kumar 予想を一般の場合で証明（Lean 4 による形式化は約5,000万行）
• NMR データからの分子構造の推定で、30エージェントが top-1 完全一致95%、top-3 で100%（単独のエージェントのほぼ2倍）
• 29エージェントが11.5時間で、公開されている13個の表から因果推論のベンチマーク50タスクを作成
• Zircon 約80万行を Rust に書き換え。libgav1 は約17万行の Rust にビット単位で一致させ、最適化後は元の C++／アセンブリより20〜30%速くなった（最初は約4倍遅かった）
• 社内のスケジューラ Borg の変更で、一部のハードウェアで TPU ジョブの中断を24%減らした

2026年8月27日の公式ブログの発表

Gemini 3.7 Flash と Gemini 3.1 Pro を使い、理論計算機科学などの未解決問題7件を解いた（6件は専門家が確認、Knuth の Cycles 予想は Lean で検証）と発表しました。ほかに、社内評価 TCSBench で71%、xv6 を起動できるサイクル精度の RISC-V CPU シミュレータ（実機との誤差は平均0.71%）、Eigen・ParlayHash への最適化の取り込みが挙げられています。

成果の読み方

数字をそのまま自分の仕事に当てはめるのは早計です。8月の成果の一部は「既定より高い並列度」で出したものと書かれています。10月26日のブログで紹介された事例でも、設計と受け入れ基準は人が決め、数値は特定の社内環境で測ったものでした。どの事例も、問題の設定と最後の確認には人が関わっています。

「AIのチームに任せれば数日の仕事が終わる」と読むより、「合格条件を人が決めて、独立した検証器で確かめられる仕事なら、ここまで進められる」と読むのが実態に近いでしょう。Gemini 4 の各モデルはGemini 4とは、Gemini 4 Carbon、Gemini 4 Hydrogenで解説しています。

業務で/teamworkを使うときの考え方

業務で使うなら、最初の題材は「合格条件をテストで書ける仕事」にするのが現実的です。テストが揃ったリポジトリの移行や、入出力が決まっているモジュールの書き換えなら、レビュー役と監査役の仕組みがそのまま機能します。

反対に、要件が固まっていない新規開発や、社内の暗黙のルールが多い業務システムでは、面談で決めた仕様と実際の業務がずれやすくなります。専用フォルダで作られた成果物を本番のリポジトリに取り込むかどうか、取り込む前に誰がどこまで確かめるかも、事前に決めておく必要があります。

AIが作った試作やツールを社内の実データや既存システムにつないで業務で使うには、認証、権限、データの扱い、運用時の監視といった本番向けの作業が別に必要です。このとき何が必要になるかはバイブコーディング・Lovableで作ったアプリを本番運用するにはで整理しています。

/teamworkはこんな人におすすめ

おすすめな人

• テストが揃ったリポジトリで、フレームワークの移行や言語の書き換えを予定している開発者
• 数日かかる調査や文書レビューを、根拠付きでまとめさせたい研究者・技術者
• Google AI Pro 以上をすでに契約していて、クォータに余裕がある人
• 受け入れ基準を自分で言葉にでき、最後の確認に時間を取れる人

おすすめしない人

• 無料プランで試したい人（使えません）
• 数行の修正やちょっとした機能追加をしたい人（/plan やサブエージェントで十分です）
• 「何を作るか」がまだ決まっていない人（面談で答えられず、仕様がぶれます）
• 費用の上限を気にせず長時間動かしてしまいそうな人（AIクレジットの自動購入を止めてから使ってください）
• 会社のアカウントで今すぐ使いたい人（Business・Enterprise で使えるかは公式に明記がありません）

よくある質問

Q. /teamwork と /teamwork-preview は別の機能ですか？

同じ機能です。2026年8月の提供開始時は /teamwork-preview という名前で、現在の公式ドキュメントでは /teamwork になっています。いまは /teamwork と入力してください。

Q. 実行中にパソコンを閉じても作業は続きますか？

公式ドキュメントには、ローカルの App や CLI を閉じたときの挙動が書かれていません。数時間〜数日の作業になるので、実行中は App か CLI を開いたままにし、進捗のアーティファクトで状況を確かめるのが無難です。

Q. 途中で方針を変えたくなったら？

/teamwork は承認した仕様を「拘束力のある仕様書」として進むため、途中で大きく方針を変える使い方は想定されていません。範囲や受け入れ基準が変わるなら、仕様を作り直して新しく始めるほうが結果は安定します。

Q. どのモデルで動きますか？

/teamwork の既定モデルは公式ドキュメントに書かれていません。Antigravity では Gemini 4 Argon（10月13日）、Gemini 4 Carbon（11月10日）、Gemini 4 Hydrogen（11月12日）が順に使えるようになっており、Google Research は成果の大半を Gemini 4 Argon で出したとしています。

Q. 作ったコードは自動で自分のリポジトリに入りますか？

入りません。作業は既定で ~/teamwork_projects/{PROJECT_NAME} の専用フォルダで行われます。結果を確かめてから、自分で取り込むかどうかを決めます。

Q. 研究者向けに無料で使える制度はありますか？

Google Research は11月13日、学術研究者1万人に最上位の使用量プランを6か月無料で提供すると発表しました。申請制です。日本の研究者が対象に入るかは、公式の案内で確かめてください。

まとめ

/teamwork は、Antigravity で複数のAIエージェントに役割を分けさせ、数時間〜数日かかる移行・書き換え・調査を進めるコマンドです。最初の面談で「何を作り、どうなれば合格か」を決め、承認後はレビュー役と監査役の関門を通しながら自律で進みます。

• 使えるのは有料プラン。日本では Google AI Pro（月額2,900円）以上が確実で、Plus は公式に明記なし
• 長期・多段階の仕事は /teamwork、数分〜数時間なら /swarm、難しい1問なら /boost
• 権限は Default のまま、危ない操作は Deny、AIクレジットの自動購入は「Never」
• 発表された成果は Google の自己申告で、人が問題を決めて最後に確かめている

まずはテストが揃った小さめのリポジトリで、受け入れ基準をはっきり書いて試すのがおすすめです。Antigravity のほかの機能や基本の使い方はGoogle Antigravityとはをあわせてご覧ください。