Grok Build Workflows は、xAI が 2026 年 7 月 23 日に Grok Build へ追加した機能で、1 回の指示を最大 1,024 エージェントに分担し、検証役まで計画に組み込めます。
📖 この記事で分かること
- Grok Buildに追加されたWorkflowsの中身
- 128/1,024というエージェント予算の意味
- 検証役を計画段階で固定できる仕組み
- 保存したワークフローの再利用方法
💡 知っておきたい用語
- オーケストレーション: 複数の作業役に仕事を割り振り、順番と集約方法まで決めて全体を回すこと。工場のライン編成に近い考え方です。
最終更新日: 2026年7月26日
▶ 公式ページ

Grok BuildのWorkflowsとは
この記事のポイント
- xAIが2026年7月23日、Grok BuildにWorkflowsを追加しました。
- 1回の実行に128エージェント、大きなジョブでは最大1,024エージェントの予算が付きます(2026年7月時点)。
- 進捗が保存されるため、一時停止・再開しても完了済みの作業をやり直しません。
- 保存したワークフローは引数を取るスラッシュコマンドになります。
xAIは7月23日、Grok BuildにWorkflowsを追加したと発表しました。ワークフローとは、タスクを並列のエージェントに扇状に分散し、結果を検証し、1回のバックグラウンド実行としてまとめて報告する「オーケストレーションスクリプト」です。
tech-noisyではGrok Build本体のソースコードがApache 2.0で公開された件を既報として扱いましたが、今回はそれとは別の機能追加にあたります。
使い方は、大きなタスクを自然言語で説明するだけです。Grokがそれを計画し、バックグラウンドで並列のエージェントに割り振り、全部終わった時点で報告します。実行中もセッションは占有されません。
エージェント予算と実行の仕組み
数値の骨格は明快です。1回の実行につき128エージェント、大きなジョブでは最大1,024エージェントの予算が与えられます(2026年7月時点)。
Grokはタスクを小さなスクリプトとして計画します。スクリプトが決めるのは、作業のフェーズ、各フェーズに置くエージェント、そして結果をどう集約するかの3点です。公式デモではPRレビューの例として、Context → Review → Verify → Synthesize というフェーズ構成が示されています。
各エージェントはクリーンで焦点を絞ったコンテキストから開始します。1つの会話に全部を積み上げるのではなく、担当分だけを持たせる設計です。
運用面では2点が実務に効きます。1つは、実行中に進捗が保存されるため、一時停止して再開しても完了済みの作業をやり直さないこと。もう1つは、/workflows コマンドでフェーズごとの進行状況をライブで確認でき、エージェント単位のトークン数まで見えることです。
検証を計画に組み込む
Workflowsの設計で目を引くのは、単一パスでは作れない検査を計画そのものに埋め込める点です。
公式が挙げる例は、独立した懐疑役(skeptics)を置き、すべての発見が最終レポートに載る前に検証させるという構成です。見つける役と、それを疑う役を分けて配置できます。
標準搭載の /deep-research も同じ考え方で作られています。リサーチ課題を並列の調査役に分散し、すべての主張をソースに照合して検証したうえで、出典つきレポートを返します。
なお、スクリプトを利用者が書く必要はありません。Grokがリクエストからワークフローを作成し、起動前にスモークチェックを通し、実行の合間に改善します。
保存と再利用
一度うまくいったワークフローは残せます。.grok/workflows/ に置いたものはチームで共有され、~/.grok/workflows/ に置いたものは環境を移っても付いてきます。
保存したワークフローは、引数を取る独自のスラッシュコマンドになります。PRレビューのワークフローを保存しておけば、次回は /pr-review 5137 と打つだけで済みます。なお Grok では、スケジュール実行に対応した Automations も別機能として提供されています。
公式が想定用途として挙げているのは、大規模PRの全機能レビュー、直近100件のIssueのトリアージ、あるクラスのバグについてのコードベース監査です。判断の目安は「独立した多数の断片に分割でき、1つの明確なレポートで終わるべき作業かどうか」とされています。
導入は次のコマンドで行えます。
curl -fsSL https://x.ai/cli/install.sh | bash
編集部の見方
編集部は、今回の更新で最も効くのは並列数の上限そのものではなく、検証役を計画段階で固定できる点だと見ます。
- 根拠1: 公式が示す構成は、独立した懐疑役が最終レポート到達前にすべての発見を検証するというものです。エージェントの出力を人手で毎回確認する運用に比べ、検査の位置が仕組み側に移ります。
- 根拠2: 進捗が保存され、一時停止・再開で完了済み作業をやり直さない設計です。長時間ジョブを試すときの再実行コストが読めることは、実運用に踏み込む条件になります。
- 根拠3: 保存したワークフローが引数付きスラッシュコマンドになるため、1回きりの実行ではなく反復可能な手順として固定できます。
この見方が変わる条件は料金です。128および1,024というエージェント予算がどのプラン・どの課金で提供されるかは、本稿執筆時点で公式が言及していません。1回の実行にかかる実コストが見えた時点で、どの規模の作業から任せるべきかの判断は動きます。
よくある質問
Q: ワークフローのスクリプトは自分で書く必要がありますか。
A: 必要ありません。Grokがリクエストからワークフローを作成し、起動前にスモークチェックを行い、実行の合間に改善します。
Q: 実行中は端末が占有されますか。
A: 占有されません。バックグラウンドで実行され、セッションは空いたままです。進行状況は /workflows コマンドで確認できます。
Q: 128エージェントと1,024エージェントはどう使い分けますか。
A: 公式の記述では、1回の実行に付く予算が128エージェント、大きなジョブでは最大1,024エージェントとされています(2026年7月時点)。どの条件で上限が引き上がるかの詳細は公式が明示していません。
まとめ
xAIは2026年7月23日、Grok BuildにWorkflowsを追加しました。1回の実行に128エージェント、大きなジョブでは最大1,024エージェントの予算が付き、Grok自身がフェーズ構成と集約方法を計画します。進捗保存による再開、独立した検証役の組み込み、保存したワークフローのスラッシュコマンド化が実務上の要点です。エージェント予算に対応する料金体系は本稿執筆時点で公式が言及していません。
【用語解説】
- ワークフロー: ここではGrokが作る実行計画そのものを指します。フェーズ、各フェーズのエージェント、結果の集約方法をまとめたスクリプトです。
- スモークチェック: 本格実行の前に、最低限動くかどうかだけを短時間で確かめる簡易テストです。
- トリアージ: 大量の案件に優先順位を付け、対応すべき順に仕分ける作業です。
引用元:
- [1] Workflows in Grok Build(xAI)
この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。
15 年以上の開発経験を持つソフトウェアエンジニア / テクノロジーライター。AI エージェントの実務活用を研究し、現場や経営者向けセミナーでその知見を発信。本メディア tech-noisy.com では、一次情報に基づく最新ニュース・解説記事を執筆。また、音楽生成 AI による DJ パフォーマンスを企業イベントで行うなど、テクノロジーと表現の融合も探求している。