Google Antigravityに「Dynamic Workflows」、エージェントの段取りをPythonスクリプトで先に検品する仕組み

まず初めに

AIエージェントに仕事を振ると、だいたい途中で「今どこまで進んだのか分からない」という顔になる。長い会話の中で複数の作業が絡み合い、失敗した部分だけやり直すのも一苦労だ。今回Googleが出した答えは、実にプログラマらしい。段取りそのものをPythonのスクリプトにしてしまえ、というのである。エージェントが書いた段取り表を、人間が先に読んで、納得したら実行ボタンを押す。言ってみれば、部下が勝手に走り出す前に、まず工程表を机に置かせる仕組みだ。AIに自由にやらせる時代から、AIの段取りを検品する時代へ。地味だが、現場ではこの地味さが効く。 ※個人の感想です

何が起きたのか

Googleは2026年11月13日、エージェント型の開発環境「Google Antigravity」のアプリ版のリリースに「Dynamic Workflows」を追加しました。公式の変更履歴によれば、この機能は、アプリに同梱されたPythonランタイムを使い、エージェントが並列のサブエージェントや複数ステップのタスクを段取りできるようにするものです。同じリリースには新しいテーマや、エージェントが操作するブラウザタブへの保護強化なども含まれています。

公式ドキュメントによれば、Dynamic Workflowsでは、エージェントが短いPythonスクリプトを書いて実行し、多数のエージェントを調整します。向いているのは、変更されたファイル1つにつきレビュー1件、パッケージ1つにつき監査1件のように、仕事が多数の独立した部品に分かれる場合や、失敗するテストを先に書いてからコードを直すような段階型の作業です。長い会話1本で粘る代わりに、予測可能なスクリプト制御に置き換える、という設計です。

使い方と仕組み

使い方は、プロンプトで /run-workflow に続けてタスクを書くだけです。CLI版では、生成されたPythonスクリプトが権限の確認画面に表示され、実行してよいかを尋ねられます（権限プリセットで許可済みの場合を除く）。スクリプトはバックグラウンドで動き続け、その間プロンプトは空いたままになります。進行状況は、現在のフェーズと完了したエージェントの数として表示されます。

スクリプトの構成要素は公式ドキュメントで公開されています。名前付きの区切りを作る phase()、結果を記録する log()、エージェントを定義する agent()、全アイテムを同時に処理する parallel()、1件ずつ順に処理する pipeline() などが中心です。各エージェントは独自の会話で作業し、結果はJSON Schemaに照らして検証された構造化データとして返ります。ファイルの読み込みや検索、テストのログはメインの会話の文脈（コンテキスト）に入らないため、本筋の会話が細切れの作業記録で埋まらない、とドキュメントは説明しています。

エージェントごとに、使用するモデル（軽量なflash系や、より深く考えるproなど）、作業場所も指定できます。作業場所は、現在のワークスペースを引き継ぐ方法のほか、各エージェントに分離したGitワークツリーを与える branch、リポジトリのストレージを共有する新しい作業コピーを渡す share が選べます。並列にコードを編集させる場合の競合を、最初から設計に入れているわけです。うまくいったスクリプトはプロジェクト内のファイルに保存し、後で再実行することもできます。

提供範囲と料金

公式ドキュメントによれば、Dynamic WorkflowsはGoogle AI ProとGoogle AI Ultraのプランで、Antigravity AppとAntigravity CLIの両方で利用できます。ワークフローのスクリプトは別のPythonプロセスで動き、Antigravityが自前のPythonを同梱しているため、利用者側でPythonをインストールする必要はありません。別のPython環境を使いたい場合は、環境変数 ANTIGRAVITY_PYTHON で差し替えられます。

料金については、AIニュースメディアのAlphaSignalが、追加料金はなく、プランに含まれる既存のモデルクレジットを消費する形だと伝えています。大量のファイルを並列にレビューさせるような使い方は、それだけ多くのエージェントセッションを同時に回すことになるため、クレジットの消費ペースには注意が必要です。

なおAntigravityでは、11月10日に複数のサブエージェントが掲示板を介して連携する /swarm が、11月12日にはGemini 4 Carbonと組み合わせたOrchestratorが追加されており（いずれも公式変更履歴）、今回のDynamic Workflowsは、それらとは別の「スクリプトで段取りを固定する」方式として位置づけられます。エージェント同士の連携方法そのものが、競合の主戦場になりつつあります。この流れは、アプリの道具一式をAPIに開放したDeepSeekの動き（DeepSeekのAPI開放）とも地続きです。

IT Postの見方

IT Postでは、今回の肝は「並列化」そのものではなく、「段取りが読める」ことだと考えます。複数のエージェントを同時に走らせる機能自体は、もはや珍しくありません。珍しいのは、エージェントが自分の段取りをPythonのコードとして先に提出し、人間がそれを読んで承認してから実行する、という順序を製品の標準にしたことです。コードなら差分も取れるし、保存して再実行もできるし、どこで何をするのか後から検証もできる。会話の流れに任せる方式の最大の弱点だった「再現性のなさ」への、正面からの回答です。もちろん、スクリプトを書くのもエージェントなので、段取り自体が間違っている可能性は残ります。だからこそ実行前の表示と承認がセットになっている。自由にやらせるか、細かく管理するかではなく、「工程表だけは先に出させる」という落としどころは、実務の知恵としてかなり堅い。AIエージェントの評価軸が、賢さから「段取りの透明さ」へ移り始めた転換点に見えます。

今後どうなりそうか

まずは、変更ファイルの一括レビューや監査のような、部品の多い定型作業から利用が広がるとみられます。試す場合は、いきなり大規模な並列実行にせず、対象を数ファイルに絞り、生成されたスクリプトを実際に読んでから承認する運用で始めるのが現実的です。スクリプトの保存と再実行が定着すれば、チーム内で「効いた段取り」が資産として共有されるようになる可能性もあります。本誌では、提供範囲の拡大や、スクリプト形式の仕様変更が公表された場合に続報として扱います。