Grok Build Workflows、最大1,024エージェントでプログラミングタスクを分解——段階的な検証と再開可能な状態管理を追加

SpaceXAIは7月23日、ターミナル向けコーディングエージェントGrok BuildにWorkflowsを導入し、従来の単一の会話で進める作業方式を、プログラム可能なマルチエージェント実行グラフへと拡張した。ユーザーが目標を記述するだけで、システムは作業ステージ、各ステージで起動するエージェント、中間成果物の受け渡しと集約方法を定義するオーケストレーションスクリプトを生成する。公式デモでは、大規模なpull requestのレビューを、コンテキスト取得、専門レビュー、敵対的検証、結果のランキングという4段階に分割している。

各実行ではデフォルトで128エージェントを利用でき、大規模タスクでは最大1,024エージェントまで対応する。各エージェントはクリーンで対象を絞ったコンテキストから開始するため、大量のissueの分類、ルート単位の権限監査、モジュール横断レビューなどを、互いに独立したサブタスクへ分割する用途に適している。システムは完了済みのステージと各エージェントのtoken使用量を保存し、一時停止後も処理をやり直さずに再開できる。安定したフローはプロジェクトの`.grok/workflows/`に保存し、チームで共有できるパラメーター付きslash commandとして呼び出せる。組み込みの`/deep-research`も、最初に情報を並列収集し、その後にソースを検証する構造を採用している。

技術的な変化は、単に「エージェントを複数起動する」ことではない。コンテキスト分離、fan-out、集約、再検証をコーディングエージェントの第一級の抽象概念へ引き上げた点にある。これにより、単一の極端に長いコンテキストによる注意の希薄化を抑えられるほか、検証エージェントが元の解法に影響されていない状態で結論を再確認できる。Grok BuildのRust製エージェント実行環境とTUIは、GitHubでApache 2.0ライセンスの下に公開されている。ただし、公開リポジトリは社内monorepoから定期的に同期されるもので、ホスト型ワークフローバックエンドの実装がすべて含まれている保証はない。

一方、エンジニアリングチームは、エージェント数の増加が独立した証拠の増加を意味するわけではない点に注意すべきだ。共通のモデル、prompt、または誤ったコンテキストにより、数百のエージェントが強く相関した誤判定を生み出す可能性がある。公式は、単一エージェントとの比較における合格率、レイテンシー、tokenコスト、リトライ戦略、sandbox分離に関するデータも公表していない。今後の注目点は、ワークフロー定義に安定したフォーマットが用意されるか、オフラインで実行できるか、そして検証ステージを別のモデルによる判断だけに頼らず、決定論的なテストやセキュリティスキャナーと統合できるかどうかだ。