2026年7月23日、xAIが開発ツール「Grok Build」にWorkflowsという機能を追加しました[1]。ひとことで言うと、大きな依頼を1体のAIに丸ごと投げるのをやめて、何百体もの小さなAIに分けて走らせ、別のAIに検証させてから1本のレポートにまとめる仕組みです。
使えるエージェントは既定で128体、大きな仕事では最大1,024体。数字だけ見ると物量で殴る話に聞こえますが、公式発表を読むと力点は別のところにあります。独立した「懐疑役」のエージェントが、報告に載る前にすべての指摘を検証する——この構造のほうが本体です。
この記事で分かること——①何が発表されたのか ②なぜ「1体の賢いAIに全部やらせる」だと詰まるのか ③肝は並列数ではなく検証役だという話 ④保存して使い回す方法 ⑤同じ型の仕組みを毎日使っている私たちの実感 ⑥使う前に知っておくこと。数値は公式発表と、xAIがApache-2.0で公開している実装ソースから確認したもので、CAG自身のベンチマーク検証ではありません（出典は脚注）。
01 何が発表されたのか
Grok Buildは、ターミナルで動くxAIのコーディングエージェントです。コーディングエージェントとは、開発者の代わりにコードを読んで修正まで進めるAIツールのことで、指示を出すと自分でファイルを開き、書き換え、テストを走らせます。今回そこに載ったWorkflowsを、公式はこう説明しています[1]。
大きな作業を普通の言葉で説明すると、Grokがそれを計画し、バックグラウンドで何百体もの並列エージェントに分配し、全部終わったら報告してくる。その間、あなたのセッションは空いたまま。
要点は3つです。まず仕事を「フェーズ」に分けること。公式デモのコードレビューでは、前提を集める → 担当を分けて見る → 検証する → 束ねる、の4段構成になっています。次に各エージェントが「まっさらな、狭い視界」で始まること。1つの会話に全部を詰め込まないので、途中で前半を忘れる事故が起きにくくなります。そして人間はスクリプトを書かないこと。依頼文からGrokが組み立て、起動前に軽く動作確認し、実行のたびに直します。
公式が想定用途として挙げているのは、「大きな変更の全機能をレビューする」「直近100件の課題を仕分けする」「ある種類のバグについてコードベース全体を監査する」。共通しているのは、独立した細かい仕事に割れて、最後は1本の報告になるべき仕事という条件です。
02 なぜ「1体に全部やらせる」だと詰まるのか
AIに大きな仕事を任せたことがある人は、だいたい同じ壊れ方を見ています。最初は快調で、途中から前半の指示を忘れ、終盤は何をしていたのか分からなくなる。原因は能力ではなく、コンテキスト（AIが一度に覚えていられる作業スペース）の総量にあります。100件の課題を1つの会話に流し込めば、80件目のころには最初の判断基準が薄れている。
Workflowsの答えは「もっと賢いモデルを使う」ではなく、1つの会話に収まる大きさまで仕事を割ることでした。割った先の128体は、それぞれ独立した短い会話として走ります。だから総量が増えても、1体あたりの視界は狭いままに保たれます。
実装側の数字も公開されています。xAIはGrok Buildの実装をApache-2.0で公開しており[2]、上限や既定値はソースから直接確認できます。
| 項目 | 値 | 意味 |
|---|---|---|
| エージェント予算（既定） | 128 | 1回の実行で使える子エージェント数の初期値 |
| エージェント予算（上限） | 1,024 | 大きな仕事のときの天井。1〜1,024の範囲で指定できる |
| 1回の並列呼び出し | 最大1,024件 | 一度に並べられる仕事の数 |
| 総呼び出し上限 | 10,000 | 暴走したスクリプトを止めるための総量ストッパー |
| スクリプトの実体 | Rhaiスクリプト | .grok/workflows/<名前>.rhai に保存される |
注目したいのは、上限の側にきちんと壁が用意されていることです。予算を超える計画は「走らせてから止まる」のではなく、子エージェントを1体も起動する前に拒否される[2]。AIエージェントの事故はたいてい「気づいたら大量に動いていた」という形で起きるので、ここは実務を分かっている設計です。
関連記事 ｜ 「分けて任せる」とコストはどう変わるかAgent Swarmとは何か ──同じ品質でコストが8分の1になった、AIエージェント「分業」の実験を解説
→
03 肝は並列数ではなく「懐疑役」
Workflowsで一番効いているのは、1,024という数字ではありません。公式が書いているこの一文のほうです[1]。
1回のパスではできないチェックを、計画に組み込める。たとえば、独立した懐疑役が、最終レポートに載る前にすべての指摘を検証する。
なぜこれが要るのか。複数のAIを協調させると、互いの間違いを補強し合うという厄介な現象が起きます。1体目が「ここにバグがある」と言い、2体目がその前提を受け取って「たしかに、だから連鎖してこちらも危ない」と積み増す。誰も元の前提を疑っていないので、もっともらしい嘘が3段組みで完成します。人数を増やしただけの体制は、間違いも同じ速度で増やします。
対策は、検証役に「賛成するな、否定を試みろ」という別の役割を与えて、独立した視界で走らせること。同じ会話の続きでチェックさせても、前提を共有しているので素通りします。だからフェーズを分け、まっさらな文脈で懐疑役を起動する。
これは「AIをたくさん並べれば賢くなる」という直感とは逆の設計思想です。並列は答えの数を増やすだけで、正しさは増やしません。正しさを増やすのは、疑う役をどこに何体置くかという設計のほうにあります。
04 一度きりで終わらせない──保存して使い回す
Workflowsのもう一つの現実的なところは、うまくいった手順を"部品"として残せる点です。公式が挙げている使い方はこうなっています[1]。
- 保存場所が2つある。プロジェクト直下の
.grok/workflows/に置くとチームで共有され、~/.grok/workflows/に置くと自分がどの案件で作業しても付いてくる - 保存すると、そのままスラッシュコマンドになる。公式の例では、一度作ったレビュー手順は次から
/pr-review 5137と打つだけで走る。引数も取れる - 調査用の
/deep-researchは最初から入っている。問いを並列の調査役に分け、すべての主張を出典と突き合わせてから、引用付きのレポートを返す - 途中経過が保存される。一時停止して再開しても、終わった分をやり直さない。
/workflowsを開けば、フェーズごと・エージェントごとのトークン消費までライブで見られる
7月24日のリリース（0.2.112）では、失敗した実行の再開と、進捗表示が実行中のフェーズを自動で追う改善が入りました[3]。ただし再開には条件があり、同じプロセスの中で一時停止したものに限られます（アプリを再起動すると、その実行はそこで終わり）。予算を使い切った実行を再開するときは、より大きい予算を渡す必要があります[2]。
05 同じ型の仕組みを毎日使っている側の実感
私たち電脳技巧集団（AI職人ギルド）は、開発の主戦場としてClaude Codeを使っています。そちらにも同型のワークフロー機構があり、日々の作業で回しています。仕様の細部は違いますが設計思想はほぼ同じなので、使って分かったことを3つだけ書いておきます（以下の数値は自社環境の話で、Grok Buildのものではありません）。
① 体数は「多いほどいい」ではない。 私たちの環境では、生涯の上限こそ1,000体ありますが、同時に走るのは16体前後に抑えられているうえ、既定の推奨サイズは「1つのワークフローで15体未満」です。上限と推奨がこれだけ離れているのは、実務では数を増やすほど良くなるわけではないから。効くのは体数ではなく、仕事の割り方のほうにあります。
② 段階の区切りで全員を待たせると、時間が溶ける。 「全員のレビューが終わってから、まとめて検証に入る」という組み方は分かりやすいのですが、いちばん遅い1体に全体が引きずられます。1件ずつ独立して最後まで流す組み方にすると、早く終わった案件から検証に進める。同じ体数でも体感速度がまるで違います。
③ 懐疑役は「1体」だと機能しにくい。 検証を1体に任せると、その1体が納得した時点で通ってしまいます。私たちは重い判断のときだけ、視点の違う検証を複数走らせて多数決を取ります（正しさを見る役、危ないところを見る役、本当に再現するかを見る役、というように役割を変える）。同じ検証を3回やるより、違う目で3回見るほうが引っかかります。
売り込みたいわけではないので手短にしますが、この手の仕組みは「導入すれば速くなる」ものではなく、「何をどう割るか」を人が決められるかどうかで結果が変わる、というのが正直な実感です。
06 使う前に知っておくこと
| 気になること | 実際のところ |
|---|---|
| コストは？ | エージェントの数だけ会話が増える。128体は「128回分のやりとり」に近い。小さな仕事に大きな予算を割り当てない |
| どんな仕事に向く？ | 独立に割れて、最後に1本の報告になる仕事（大量レビュー・仕分け・横断監査）。順番に依存する仕事や、途中で人の判断が要る仕事には向かない |
| 結果はそのまま信じていい？ | 懐疑役の検証は通ったものの質を上げる仕組みで、正しさの保証ではない。重い判断は人が最終確認する前提は変わらない |
| 中断からの再開は？ | 同じプロセス内で一時停止したものだけ。アプリを再起動した実行は再開できない |
| スクリプトは書ける必要がある？ | ない。Grokが書く。ただし保存された実体は編集でき、直して別の実行として走らせられる |
持ち帰り
- Workflowsは、大きな依頼を分割 → 並列実行 → 検証 → 統合の4段に組み替える機能（2026年7月23日発表）
- 使えるエージェントは既定128体・最大1,024体。上限を超える計画は、1体も起動する前に弾かれる
- 一番の勘所は数ではなく、独立した懐疑役に検証させてから報告に載せるという構造
- うまくいった手順は保存でき、引数付きのスラッシュコマンドとして使い回せる
- AIに大きな仕事を任せて壊れた経験があるなら、原因はモデルの賢さではなく仕事の割り方だった可能性が高い
出典・注記
- xAI「Workflows in Grok Build」2026年7月23日 — https://x.ai/news/workflows（フェーズ構成、エージェント予算128／最大1,024、懐疑役による検証、保存先とスラッシュコマンド化、
/deep-research、一時停止と再開、/workflowsのライブ表示。引用は原文からの日本語訳） - xai-org/grok-build（Apache-2.0） — https://github.com/xai-org/grok-build（既定予算128／上限1,024／1回の並列呼び出し上限1,024／総呼び出し上限10,000、ワークフローの実体がRhaiスクリプトである点、予算超過の計画が子エージェントの起動前に拒否される点、再開の制約）
- Grok Build CHANGELOG 0.2.112（2026年7月24日） — 失敗した実行の再開、進捗表示が実行中のフェーズを自動追従
- Grok Build ドキュメント（docs.x.ai/build/overview・2026年7月6日更新） — Grok Build 自体の位置づけ（TUI／ヘッドレス実行／grok-4.5）
- 05章の数値（同時16体前後・推奨15体未満・生涯上限1,000体）は、CAGが実務で使用しているClaude Codeのワークフロー機構の仕様に基づく自社環境の記述であり、Grok Build の数値ではありません。本記事全体を通じて、性能比較はCAG自身が計測したものではありません。
大きな仕事をAIに任せて、途中で壊れた経験がありますか
原因はたいてい、モデルの選定ではなく仕事の割り方にあります。電脳技巧集団（AI職人ギルド）では、こうした仕組みを実際の受託開発で日常的に回しています。相談は お問い合わせ からどうぞ。
