結論から言うと、Antigravityの/teamworkは、1回のプロンプトで答えを出すAIではなく、複数のエージェントが候補を出し、別のエージェントが反証し、検証できた案だけを前に進める長期タスク向けの仕組みです。Google Researchは、Gemini 4系モデルと/teamworkを組み合わせ、数学、形式検証、分子構造、カーネル最適化などで成果を出したと説明しています。企業で見るべきポイントは、性能そのものより「誰が目的を決め、どの検証器で合格にするか」です。
この記事では、AI開発責任者、研究開発チーム、CopilotやClaude Codeを社内導入している管理者向けに、/teamworkを導入候補として見るときの5項目を整理します。単なる最新ニュースではなく、30日PoCで事故なく評価するための実務チェックに落とします。
Antigravity /teamworkとは？長期タスクを分解・反証・検証する仕組み
Googleの説明では、TeamworkはAntigravity内のマルチエージェント・オーケストレーションフレームワークです。特徴は、エージェントが互いの作業を提案、批判、改善し、数時間から数日かかる問題にも取り組める点です。単独のAIが長文コンテキストを抱え続けるのではなく、役割ごとに文脈を分け、コーディネーター、批評役、検証役を組み合わせます。
重要なのは、/teamworkが万能の自動化ボタンではないことです。Googleは、候補生成、ストレステスト、強い案の統合というループを明示しています。つまり、社内導入では「AIに任せる範囲」よりも「失敗案をどう検出するか」「人間がどの時点で承認するか」を先に決める必要があります。
何が変わる？5つの管理チェック
- 目的の定義: 研究、コード最適化、文書レビューのように、探索と検証を繰り返す課題に限定する。日次の定型作業を無理に/teamworkへ寄せない。
- 検証器の準備: テストスイート、Lean 4、シミュレーター、ベンチマーク、レビュー基準など、合否を機械的に見られる材料を用意する。
- 権限の分離: 生成役と批評役に同じ前提を渡しすぎない。Googleの説明どおり、クリーンな文脈で監査する設計が重要。
- コストと時間の上限: 数時間から数日動く前提なので、1キャンペーンあたりの予算、最大実行時間、停止条件を決める。
- 成果物の受け入れ: AIが出した証明、コード、レビューコメントを、そのまま本番に入れず、担当者が最終確認する運用にする。
Google Researchの発表で注目すべき数字
今回のGoogle Research記事では、/teamworkとGemini 4系モデルを組み合わせた研究・工学成果が複数紹介されています。たとえば、情報理論のCourtade-Kumar予想では、研究チームが問題を14変数の最適化に落とし、Gemini 4 Argonなどが解析的境界や区間演算証明書の作成を支援したと説明されています。最終的な証明はLean 4で形式化され、50 million lines of codeとされています。
形式検証の文脈では、/teamwork-LEAPがWeil予想の形式化を約1.8 million lines of Lean、28,800 subagent invocationsで生成したとも書かれています。さらにDeep Reviewでは、STOC 2027に向けた578件の投稿のうち3分の1超が利用し、調査回答者70名のうち90%がフィードバックを概ね事実に基づく、またはほぼすべて事実に基づくと評価したとされています。数字は派手ですが、企業導入では「長期AI実行には検証・監査の設計が必須」という示唆として読むのが安全です。
30日PoCの進め方：研究開発とソフトウェア開発で分ける
研究開発チームなら、PoCは未解決問題そのものではなく、既知の論文再現、計算パイプライン改善、技術文書レビューから始めるのが現実的です。既に答えや評価軸がある課題を使えば、/teamworkが本当に候補探索と反証に効くのかを測れます。指標は、再現率、レビューで発見した重大指摘数、人間の確認時間、誤指摘率の4つに絞ります。
ソフトウェア開発チームなら、分散コーディングや既存テストのある性能改善が候補です。たとえば、CIで落ちる変更を除外し、ベンチマークで10%以上改善した案だけを人間レビューに回す、といったゲートを置きます。/teamworkは長く動ける分、権限を広げすぎるとリポジトリ全体に影響するため、対象ディレクトリ、実行コマンド、外部アクセスを最初に制限します。
既存AIエージェント運用との違い
Claude Code、GitHub Copilot、通常のチャットAIは、依頼に対して単一の作業者として振る舞う場面が多いです。一方、/teamworkは複数案の競争、反証、統合を前提にしています。これは便利な半面、実行ログ、失敗案、批評ログ、最終成果物の関係を追えるようにしないと、あとからなぜその結論になったのかを説明しにくくなります。
管理者は、通常のAI利用規程に加えて、長期実行エージェント用の監査項目を持つべきです。最低限、入力データの機密区分、生成物のライセンス確認、外部検索の可否、検証コマンドの再現性、失敗時の停止条件を記録します。これらがないと、成果が出たときほど社内展開の判断が難しくなります。
FAQ
Q. Antigravity /teamworkはすぐ本番導入すべきですか？ A. まずは30日PoCで十分です。公式発表の成果は研究・形式検証・最適化のような検証可能な課題が中心なので、自社でも合否を測れる課題から始めるのが安全です。
Q. どの部門に向いていますか？ A. 研究開発、AI基盤、セキュリティレビュー、性能改善チームに向いています。営業資料作成や日次レポートのような短時間タスクは、通常のAIワークフローで十分な場合があります。
Q. 一番のリスクは何ですか？ A. 長く動くエージェントに広い権限を渡し、検証なしで成果物を採用することです。/teamworkの価値は自律性だけでなく、反証と検証の設計にあります。
