Google Antigravityの「Dynamic Workflows」とは？/run-workflowでサブエージェントを編成

Google Antigravityの「Dynamic Workflows」は、Googleが開発者向けAIエージェント環境Google Antigravityに追加した機能で、/run-workflowとタスクを入力するとエージェントが短いPythonスクリプトを書き、そのスクリプトが複数のサブエージェントを並列・逐次に編成して処理を実行するものです。

室谷代表取締役

Google AntigravityのDynamic Workflows、これ地味に見えて構造がかなり変わったんですよね。プロンプトで長い会話を回すんじゃなくて、エージェントがPythonスクリプトを書いて、そのスクリプトがサブエージェントを束ねる。

制御の主体が会話からコードに移った、というのがポイントなんですよ。

テキトー教師DotAI 認定講師

まさにそこなんですよ。単に「またエージェント機能が増えた」という話じゃないんです。

Antigravityの公式ドキュメントを読むと、/run-workflowはタスクが「多数の独立した要素」や「段階的な手順」「レビューと修正のループ」に分かれる場面で使う、と整理されている。つまり、1本の長い会話では制御が曖昧になりやすい仕事を、スクリプトで予測可能にするための仕組みなんです。

Google AntigravityのDynamic Workflowsとは？何が発表されたか

室谷代表取締役

まず発表そのものですが、GoogleがAntigravityでDynamic Workflowsのロールアウトを案内しました。/run-workflowを使うと、エージェントがPythonスクリプトを書いて、並列・逐次にサブエージェントを編成し、構造化された受け渡しでつなぐ。

プロンプトドリフトの代わりに決定論的な制御フローを渡す、という言い方でしたね。

テキトー教師DotAI 認定講師

公式のドキュメントでも同じことが書かれていて、/run-workflow <タスク>を実行すると、まずエージェントが組み込みのrun-workflowスキルを読んで、そのタスク用のPythonスクリプトを書く。次にAntigravityがスクリプトを表示して承認を求める。

承認するとワークフローがバックグラウンドで走り、フェーズやログ、エージェントが進行に合わせて表示される。終わるとメインのエージェントがログと出力を受け取って結果を要約する、という流れです。

室谷代表取締役

ここで大事なのは、ワークフローが起動するエージェントはそれぞれ独立した会話を持つ「完全なエージェント」で、スクリプトも互いも見えないということなんですよね。だからスクリプト側が、プロンプトに必要な情報を全部入れて、短く明確に定義された結果だけを返させる設計になっている。

テキトー教師DotAI 認定講師

そこが講座でも強調している「コンテキストの分離」なんですよ。ファイル読み込みや検索、テストログがメイン会話のコンテキストを圧迫しない。

各エージェントはJSON Schemaに合った構造化結果を返すので、スクリプトは解析済みの値を受け取れます。

室谷代表取締役

ちなみにAntigravityには従来、Markdownファイルに手順を書いて/workflow-nameで呼ぶ「Workflows」機能があったんですが、これは非推奨とされ、新しい仕組みへの移行が案内されています。既存のワークフローは今のところ動くけど、Agent skillsへの移行手順が示されている、という状態ですね。

Dynamic Workflowsでできること――並列・逐次サブエージェントと構造化された受け渡し

室谷代表取締役

できることを整理すると、まず並列と逐次のフェーズがあります。スクリプトはparallel()でエージェントを同時に走らせ、pipeline()で1つずつ順番に走らせる。

どちらも名前付きのフェーズにまとめられて、実行中に追えるわけです。

テキトー教師DotAI 認定講師

公式ドキュメントの例だと、phase("Discover")で変更ファイルを列挙して、phase("Review")でparallel()を使ってファイルごとに1エージェントを同時に走らせる。結果はアイテムの順序で返ってくる。

もし1つが失敗したら、他はキャンセルされる。ここは挙動として覚えておきたいところです。

室谷代表取締役

あと面白いのが、単発のエージェントとマルチターンのエージェントを両方扱えることなんですよね。ファイルごとに1人のレビュアーを立てるような単発の使い方もできるし、1人のエージェントをターンをまたいで保持して、バグを見つけた同じレビュアーに修正の確認までさせる、ということもできる。

テキトー教師DotAI 認定講師

スクリプトの部品も整理しておくとこうです。

• phase(name): 名前付きフェーズを開始し、以降のログやツール呼び出し、エージェントカードをまとめる
• log(*args): 現在のフェーズに1行追加し、メインエージェントが受け取る結果にも含める
• agent(prompt, schema, role, type_name, workspace, model): エージェントを定義。await agent(prompt, schema)で1回実行、a = agent(...)の後にawait a(prompt, schema)で会話をまたいで1ターン実行
• parallel(items, fn): 全アイテムに対して同時に実行し、アイテム順で結果を返す。1つ失敗すると他はキャンセル
• pipeline(items, fn): 1アイテムずつ順番に実行し、アイテム順で結果を返す
• await trajectory(...): ワークフロー開始前の会話の過去ステップを返す（ステップ種別、ツール名、インデックス範囲、直近N件で絞り込み可能）
• args: エージェントがスクリプトに渡す任意引数の辞書（無ければ空）
• CONVERSATION_ID、STEP_INDEX、WORKSPACES: 会話ID、ワークフローステップのインデックス、ワークスペースフォルダ（プライマリが先頭）。スクリプトはプライマリのワークスペースフォルダで動く

室谷代表取締役

エージェントのschemaは結果用のJSON Schemaで、エージェントはfinishツール経由でスキーマに照らして結果を返し、スクリプトは解析済みの値を受け取る。自由回答なら{"type": "string"}でいい。

テキトー教師DotAI 認定講師

実行の仕方もプロンプトで指定できるんですよ。modelは既定で会話のモデルを継承（inherit）だけど、多数ファイルを高速に大量チェックするならflash_liteやflash、深い推論が要るならproを頼める。

type_nameは既定のselfが現在のエージェントの設定とツールを使い、読み取り専用のコードベース調査なら組み込みのresearchエージェント、あるいは自作のカスタムサブエージェント名も使える。workspaceは既定のinheritが現在のワークスペース、branchがエージェントごとに独立したGit worktree、shareがリポジトリのストレージを共有する新しい作業コピーです。

室谷代表取締役

並行してコードを編集するならbranchで分離する、というのは実務だと効きますよね。MYUUUでも複数エージェントに同時に触らせる場面はあるので、worktree分離は素直にありがたいです。

/run-workflowの使い方・始め方――スクリプトの確認から保存・再実行まで

室谷代表取締役

使い方はシンプルで、任意の会話で/run-workflowに続けてタスクを書く。入力中にメニューが候補を出すので、/run-workまで打ってTabを押すとコマンドが挿入される。

あとはタスクを続けて書くだけです。

テキトー教師DotAI 認定講師

自分の言葉で「各パッケージを並列で監査するワークフローを実行して」と頼んでもいい。開始前に「Allow running this workflow script?」というプロンプトでスクリプトが表示されるので、「Yes, allow this time」で今回だけ許可するか、「No」を選んでエージェントに修正点を伝える。

計画を変えたいときは拒否して指示する、という流れです。

室谷代表取締役

走り出したら、ワークフローは会話の中で1つのステップとして表示される。タイトルに説明、現在のフェーズ、終わったエージェント数が出る。

例えば「workflow · Review · 3/4 agents」みたいに。他のツール呼び出しと同じように折りたたみの要約の下に入ることもある。

テキトー教師DotAI 認定講師

ステップを展開すると、実行中のPythonスクリプト、名前付きフェーズごとのセクション、そのフェーズで出力されたログ、フェーズが起動したエージェントごとのカード、スクリプトがprintした出力が見られる。エージェントカードをクリックするとサイドパネルでそのエージェントの会話が開いて、プロンプトを読んだり、ツール呼び出しを見たり、保留中のリクエストを承認したり、メッセージを送ったりできる。

ワークフローのエージェントはメインの会話一覧には出ないので、カードから開く形ですね。

室谷代表取締役

途中で止めたいときは会話を停止する。親の会話を止めると、走っているワークフローのエージェントも全部止まる。

ここは挙動として知っておかないと、止めたつもりで残る、という事故になりかねない。

テキトー教師DotAI 認定講師

保存と再実行もポイントです。同じ種類のワークフローを定期的に回すなら、スクリプトをワークスペース内の.pyファイルに保存するようエージェントに頼んで、次回は/run-workflow Run scripts/review-changes.pyのように実行する。

毎回生成し直さずに済むわけです。ただし実行のたびに、常に許可する設定にしていない限り承認を求められます。

室谷代表取締役

承認の範囲も細かいんですよね。スクリプトの承認は「今回だけ」「この会話の残り」「常に」から選べるけど、承認はそのスクリプトそのものを対象にするので、コマンドのプレフィックスルールではPythonスクリプトをカバーできない。

あとワークフローが起動した各エージェントは、それぞれの会話で許可プリセットに従って承認を求めてくる。エージェントは答えが返るまで待ちます。

テキトー教師DotAI 認定講師

受講生さんがよく「承認が多くて止まって見える」と言うんですが、これは仕様どおりで、エージェントごとに独立した会話で承認を求めているからなんですよ。

料金と提供範囲――Google AI Pro／Ultraで使えるのか、Python環境はどうなる？

室谷代表取締役

提供範囲は公式に明記されていて、Dynamic WorkflowsはGoogle AI ProとGoogle AI Ultraのプランで、Antigravity AppとAntigravity CLIの両方で使えます。

テキトー教師DotAI 認定講師

プラン全体の整理もしておくと、Antigravityは全プラン共通でGeminiモデル（Gemini 4 Hydrogen、Gemini 3.8 Flashなど）をコアのエージェントモデルとして使えて、Tab補完は無制限、スケジュールタスクやCLIといった製品機能にもアクセスできる。Google AI Ultraは最も多いクォータが5時間ごとに更新され、週次のレート制限も最も高く、サードパーティのモデルにもアクセスできる。

Google AI Proは5時間ごとのクォータが週次上限まで更新され、週次レート制限も高め。ProでもUltraでもない場合は、週次で更新される相応のクォータと週次レート制限になる、という違いです。

室谷代表取締役

クォータはエージェントの作業量に相関するので、単純なタスクなら多く、複雑なタスクは多く消費する。ProやUltraなら、ベースラインのクォータを超えた分を購入済みのAIクレジットで賄える。

AIクレジットの超過利用は設定で「Never」か「Always」を選べる、という話ですね。

テキトー教師DotAI 認定講師

料金の細かい数字はAntigravity Proの料金と制限まとめ。無料・Ultraとの違いを比較で整理しているので、そちらと合わせて読むと分かりやすいです。

無料枠の限界についてはGoogle Antigravity無料枠の実力と限界も参考になります。

室谷代表取締役

Python環境の話も重要なんですよね。ワークフローのスクリプトは別のPythonプロセスで動くけど、Antigravityがワークフロー用のPythonを同梱しているので、自分でPythonをインストールする必要はない。

最初に実行したときに展開されるので、少しだけ時間がかかります。

テキトー教師DotAI 認定講師

独自のパッケージが入ったPythonを使いたい場合は、ANTIGRAVITY_PYTHON環境変数に、PATH上のインタプリタ名かフルパスを設定する。インタプリタはPython 3.8以降が必須で、動かないとその変数名を示すエラーでワークフローが止まる。

macOSではDockからAntigravity Appを開くとシェルの環境変数が見えない、という注意もあります。

室谷代表取締役

もしAntigravity同梱のPythonが起動できない場合、例えばセキュリティソフトにブロックされた場合は、PATH上や一般的なインストール場所（macOSのHomebrewやpython.orgのインストール、Windowsのpyランチャーなど）にあるPython 3.8以降にフォールバックする。それでも見つからなければ、何を試したかとOSごとのPythonの入れ方を示すメッセージで止まる。

なぜ「プロンプトドリフト」を置き換えるのか――従来のWorkflowsや/swarmとの違い

室谷代表取締役

ここが一番面白いところで、なぜプロンプトドリフトを置き換えるのか。長い会話の中で指示の意図がぶれて挙動が不安定になるのがプロンプトドリフトで、これをスクリプトの決定論的な制御で置き換える、という主張なんですよね。

テキトー教師DotAI 認定講師

従来のWorkflowsはMarkdownファイルに手順を書いて/workflow-nameで呼ぶもので、ワークフローの中から別のワークフローを呼ぶこともできた。ただこれは非推奨になって、新しい仕組みへの移行が案内されている。

Dynamic Workflowsは、その「手順をなぞる」段階から「スクリプトで編成する」段階への移行なんですよ。

室谷代表取締役

公式ドキュメントでは、Orchestrator、Subagents、Dynamic Workflows、/swarmの使い分けが整理されています。Orchestratorは1つの会話の中で、フロンティアなプランナーモデル（Gemini 4 CarbonまたはGemini 4 Argon）が計画とレビューを担い、定型のツール実行をGemini 4 Hydrogenに振る。

Subagentsは調査やビルドのような1つのタスクを委任して、自分は作業を続ける。Dynamic Workflowsは予測可能でスクリプト化された制御フローで、ファイルやパッケージのリストに同じチェックを回したり、段階的な手順を順に実行したり、エージェント同士が対話するのではなく構造化結果をスクリプトに返すレビュアー＆フィクサーのループを回したりする。

/swarmはピア同士が協調する、という位置づけです。

テキトー教師DotAI 認定講師

単一の長い会話やエージェント同士の対話に依存すると、同じチェックを多数ファイルへ一括適用するような反復作業では制御が曖昧になりやすい。そこをスクリプトで固定するのがDynamic Workflowsの狙い、というわけです。

室谷代表取締役

複数エージェントをコードで編成するという発想自体は、Devinの「Dynamic Workflows」とは？複数エージェントをコードで編成でも触れている流れですね。ただAntigravityの場合は、承認を挟んでスクリプトを確認できる点と、Antigravity AppとCLIの両方で使える点が特徴的です。

実務での使いどころと注意点――向くタスク・向かないタスク

室谷代表取締役

向くタスクは公式の例が分かりやすいです。変更ファイルを並列でレビューする、レビューして並列で修正して検証する、隔離ワークスペースで編集する、1件ずつテストして直す、という4つが示されています。

テキトー教師DotAI 認定講師

具体的にはこうです。

• 変更ファイルの並列レビュー: 1つのフェーズで対象を洗い出し、次のフェーズで全部を同時に処理する
• レビュー・並列修正・検証: マルチターンのレビュアーがフェーズをまたいでメモを保持し、並列のフィクサーが指摘に対応し、同じレビュアーが全部直ったか確認する
• 隔離ワークスペースでの編集: 並列エージェントが同時にコードを編集してテストする場合、それぞれに独立したブランチワークスペースを与える
• 1件ずつテストして直す: 共有ファイルやテストスイートに触る場合は順番に処理する

室谷代表取締役

逆に向かないのは、単一の長い会話で十分なタスクや、エージェント同士の対話から創発させたいタスク。あとは共有ファイルを触る作業を並列で回すと衝突するので、pipeline()で逐次にするかbranchで分離する。

ここを間違えると、速くするつもりが壊れる結果になります。

テキトー教師DotAI 認定講師

注意点としては、parallel()は1つ失敗すると他がキャンセルされるので、失敗を許容して残りを続けたいタスクには向かない。あとワークフローが起動したエージェントはスクリプトも互いも見えないので、必要な情報はプロンプトに全部入れる必要がある。

逆に言えば、プロンプトが自己完結していないと結果が不安定になる、ということです。

室谷代表取締役

承認の設計も実務では効いてきます。スクリプトの承認はそのスクリプト単位で、コマンドのプレフィックスルールではカバーできない。

エージェントごとの承認はそれぞれの会話で求められる。チームで回すなら、どこを「常に許可」にするかを決めておかないと、承認待ちで止まりがちです。

テキトー教師DotAI 認定講師

あと地味な落とし穴として、macOSでDockから起動するとシェルの環境変数が見えないので、ANTIGRAVITY_PYTHONを設定したのに反映されない、ということが起こり得ます。CLIから起動するか、設定方法を確認しておくのが安全です。

室谷代表取締役

モバイルからの操作感を知りたい方はAntigravity スマホで使う方法まとめも参考になります。日本語化の話はAntigravity 2.0は日本語化できない？代わりにできる設定とOS別の始め方で解説しています。

テキトー教師DotAI 認定講師

講座では、まず小さなタスクでスクリプトを読むところから始めてもらっています。Pythonを書けなくても使えるように、Antigravityが実行前にスクリプトを見せてくれる。

だから部品を知っておくと、レビューで「ここは逐次にすべきでは」と具体的に頼めるようになるんですよ。

室谷代表取締役

まさにそこなんですよね。コードを書くためじゃなく、コードを読んで指示を出すために部品を知る。

制御の主体が会話からスクリプトに移ったというのは、そういうことなんだと思います。

よくある質問

室谷代表取締役

最後に、よく聞かれる点を整理しておきます。

テキトー教師DotAI 認定講師

まず「Dynamic Workflowsとは何か」ですが、エージェントが短いPythonスクリプトを書いて、複数のサブエージェントを並列・逐次に編成する機能です。スクリプトは実行前に確認・承認でき、保存すれば再実行できます。

室谷代表取締役

「誰が使えるか」は、Google AI ProとGoogle AI Ultraのプランで、Antigravity AppとAntigravity CLIにて利用可能です。

テキトー教師DotAI 認定講師

「Pythonのインストールは必要か」は不要です。Antigravityがワークフロー用のPythonを同梱していて、初回実行時に展開されます。

独自のPythonを使いたい場合はANTIGRAVITY_PYTHONでPython 3.8以降を指定できます。

室谷代表取締役

「従来のWorkflowsとは何が違うか」は、従来はMarkdownファイルに手順を書いて/workflow-nameで呼ぶもので、現在は非推奨とされ新しい仕組みへの移行が案内されています。Dynamic Workflowsはスクリプトで制御フローを組む点が違います。

テキトー教師DotAI 認定講師

「ワークフローを他のワークフローから呼べるか」については、現時点の公式ドキュメントにその記載は確認できません。従来のWorkflowsでは呼び出しが可能でしたが、Dynamic Workflowsについては明らかにされていません。

室谷代表取締役

「実行を止めるには」は、会話を停止します。親の会話を止めると、走っているワークフローのエージェントもすべて止まります。

テキトー教師DotAI 認定講師

「スクリプトの承認は毎回必要か」は、常に許可する設定にしていない限り、実行のたびに承認を求められます。承認はそのスクリプトそのものを対象にし、コマンドのプレフィックスルールではカバーできません。

室谷代表取締役

というわけで、Dynamic Workflowsは「速くする機能」というより「壊れにくくする機能」なんですよね。反復作業を回すチームほど、効いてくると思います。