Google は開発環境 Antigravity に /boost という新しいコマンドを追加しました。これを呼び出すと、単一のコーディングアシスタントではなく、マルチエージェントの推論パイプラインが起動します。オーケストレーターが問題を読み取ってタスクに分割し、隔離されたスコープで作業する専門エージェントにそれらを割り振り、その結果を独立した検証ラウンドにかけます。検証ラウンドは、何かがあなたの手元に届く前に実際にテストを実行します。本当のニュースは、AI がより速くコードを書くことではありません。コーディングツールが検証をツールそのものに組み込み始めたことです。

Google が実際に発表した内容

Antigravity の公式ドキュメントによると、/boost は特に難易度の高いソフトウェアエンジニアリングのために設計されています。並行処理のバグや競合状態、アルゴリズムの最適化、現れては消える微妙な回帰、複数ファイルにまたがる複雑なリファクタリングなどです。これらはまさに従来の単一ターン型アシスタントが失敗する問題です。解決には直接的な生成ではなく、試行錯誤と後戻りが必要だからです。

このコマンドは三つの明確なフェーズで実行されます。

  • 計画：メインのオーケストレーターがプロンプトを受け取り、ワークスペースのコンテキストを調べ、実行戦略を立て、課題を個別に検証可能なサブタスクに分解します。
  • 分散実行：オーケストレーターはそれらのサブタスクを専門エージェントに割り振ります。実装ワークストリームはコードとユニットテストを書きます。調査ワークストリームはファイルを一切変更せずに根本原因のデバッグを行い、コールグラフを追跡します。ローカル検証エージェントはビルドターゲットとテストスイートを実行し、報告する前に仮説を検証します。
  • 納品前の検証：オーケストレーターは結果を集約し、完全なテストスイートとエッジケースに対して回帰チェックを実行します。アサーションが失敗すると、エラー診断が次のイテレーションに渡されて自動修正が行われ、すべてが合格して初めて、検証済みの変更の概要があなたに届きます。

これらはすべて一時的で隔離された worktree の中で実行されるため、エージェントがあなたのプロジェクトの作業コピー上で実験することはありません。

モードは一つではなく三つ

Google は三つの異なる実行モードを文書化しており、その違いこそが実務的に役立つ部分です。

  • デフォルトエージェント：対話型のコーディング、コードベースのナビゲーション、一般的なリファクタリング。タスクの時間軸は数秒から数分、単一エージェントのループ、一回きりの検証。すべてのプランで利用可能です。
  • /boost：深い推論としつこいバグ。タスクの時間軸は数秒から数時間、三フェーズの階層構造、複数ラウンドの独立した検証。有料プランで利用可能です。
  • /teamwork-preview：大規模な移行やサブシステム全体の構築に何日もかけて取り組むエージェントチーム。Explorer、Worker、Critic、Auditor といった名前付きの役割があり、マイルストーンが承認される前に意図的にコードを壊そうとする検証ゲートも備えています。

この段階的な違いに注目してください。タスクが大きくなるほど、投資はスピードではなくレビューに向かいます。これはソフトウェアプロジェクトを運営するすべての人が注意を払うべきシグナルです。

なぜ開発者だけでなく経営者にとっても重要なのか

この二年間、プログラミングにおける AI の議論はスピードの議論でした。一分間に何行生成されるか、という話です。問題は、実際のプロジェクトではスピードがボトルネックではないことです。ボトルネックは信頼です。このコードは、誰も試していないケースでも本当に動くのか。

/boost のアーキテクチャが暗に示しているのは、業界も同じ結論に達したということです。より速く届くコードでも、納品後に二週間のデバッグが必要になるなら価値はありません。そのため、このツールは AI の有無にかかわらず、あらゆる技術チームに当てはまる三つのルールを軸に作られています。

  • 作者は自分の仕事を採点しない：検証する側は実装した側から分離されています。これは何十年にもわたってコードレビューの根底にある原則であり、今やツールの内部で強制されています。
  • 証拠とは主張ではなく実行である：テストに合格したという申告を受け入れるのではなく、テストを実際に実行し、その実際の出力を確認します。
  • 隔離がオリジナルを守る：実験は別のコピーで行われるため、失敗した試みがプロジェクトに漏れ出すことはありません。

ソフトウェア開発を発注しているなら、ベンダーに尋ねるべきなのはまさにこの三つの質問です。誰がレビューするのか、テストに合格した証拠は何か、そして実験はどこで行われるのか。

変わらないこと

このようなニュースを、もうエンジニアは不要になったという発表として読むのは簡単です。しかしドキュメントははっきりと逆のことを述べています。エージェントはワークスペースに設定されたファイルアクセスルールとコマンド権限ポリシーを継承し、保護されたコマンドや信頼済みスコープ外での編集はすべて、ユーザーへの承認プロンプトを発生させます。チェーンの最後には責任を負う人間がいるのです。

しかも権限は問題の小さい方の半分にすぎません。エージェントはあなたが説明した問題を解決します。説明そのものが間違っていたことは知り得ません。あなたの請求サイクルが 30 日ではなく 25 日に締まること、このフィールドを営業担当者に決して見せてはならないこと、顧客が「注文」と言うときにあなたとは違う意味で使っていることを、エージェントは知りません。要件を定義し、業務領域を理解し、意思決定に責任を持つことは、完全に人間の仕事であり続けます。

Origami はこれをどう見ているか

私たちはマルチエージェントツールを、他の生産性ツールと同じように扱っています。実行を加速しますが、責任を移すものではありません。私たちのプロジェクトは、コードを人が書いたかエージェントが生成したかにかかわらず、本番環境に出る前に、書面による仕様、人間によるレビュー、テストスイート、ステージング環境を引き続き通過します。自分でテストを実行するツールはこのチェーンへの歓迎すべき追加ですが、チェーンの一つの環であって、その代わりではありません。

経営者にとっての実践的な教訓はこうです。特に複雑な作業では納期が短縮されると期待してよいでしょう。しかし、テストもドキュメントも人間の責任者もない納品は受け入れないでください。自己レビューするツールは達成可能な品質の上限を引き上げます。しかし、作られたものがあなたの依頼どおりであることを保証する人の必要性をなくすわけではありません。

出典