「終わるまで自分で直す」AIコーディング — Grok Build /goalが検証まで自動化する

Claude Codeの動的ワークフロー、Cursorの/automateコマンド、CodexのGoal Mode。ターミナルAIコーディングは今、「目標を渡して放置する」方向に一斉に動いている。

6月22日、xAIがその競争に加わった。Grok Buildに追加された/goalは、高レベルの目標を渡すと計画・実装・検証までを自律的に回すモードだ。

渡すのは「ゴール」だけ

/goalの使い方はシンプル。ターミナルで/goalコマンドを打ち、やりたいことを自然言語で伝える。「このAPIにレート制限を追加して、テストも書いて」のような粒度でいい。

すると、まずアプローチを計画し、進捗チェックリストを生成する。そのまま実装に入り、コードを書き、テストを走らせ、問題があれば修正する。ユーザーはその間ロックアウトされない。作業中に「やっぱりこっちの方針で」と追加指示を差し込むこともできる。

ここまでなら他のツールでもできる。/goalが面白いのは、完了の定義に検証が組み込まれている点だ。

「できた」と「正しい」を分けない

従来のAIコーディングツールは、コードを書いて「できました」と返す。テストが通ったかどうか、Webページが正しく表示されるかは、ユーザーが確認する必要があった。

/goalはそこを変えた。タスクが「完了」と判定されるには、コードの生成だけでなく、レビュー・スクリプト実行・Webページの目視確認（ブラウザ操作を含む）のいずれかで検証まで終える必要がある。検証で問題が見つかれば、自動で修正ループに入る。

xAIはこのアプローチを「実行と検証の分離」ではなく「実行に検証を埋め込む」と説明している。開発者の自然なワークフロー——書いて、動かして、直して——をAIがまるごとシミュレートする設計だ。

マルチモデルで動く

内部アーキテクチャも独特だ。/goalは単一モデルではなく、Composer 2.5とGrok Build 0.1の2モデルを使い分ける。計画・判断にはComposer 2.5、コード生成・ツール操作にはGrok Build 0.1が担当するマルチモデルパイプラインになっている。

複数のモデルを段階ごとに切り替えるアプローチは、Cursor 3のComposerモデル切り替えやDevinのSWE-1.6にも共通する潮流だ。1つの万能モデルよりも、特化モデルの組み合わせのほうが結果がいい——という実験結果が業界全体で共有され始めている。

Claude Codeとの距離

正直なところ、Claude Codeの動的ワークフロー（/goalコマンド + サブエージェント）とやっていることは似ている。どちらも「目標を渡して自律実行」という同じコンセプトだ。

違いがあるとすれば、検証のアプローチ。Claude Codeはサブエージェントの階層で作業を分割し、メインエージェントが全体を監督する。一方、Grok Buildはパイプラインとして計画→実装→検証を直列に流す。どちらが優れているかはタスクの性質による。並列で複数ファイルを触る大規模リファクタリングならClaude Code、単一機能の追加+検証ならGrok Buildのほうが向いているだろう。

もう一つの差はエコシステムだ。Grok BuildはSpaceXのColossusクラスタ上で動いており、レート制限の緩さが特徴。一方で、MCP対応やプラグインの数ではClaude CodeやCursorに及ばない。

今すぐ使える、ただし

/goalはGrok Buildユーザーなら今日から使える。SuperGrokプラン（月$30 / 約4,500円）に含まれ、追加料金はない。

期待値は調整しておいたほうがいい。自律実行系の機能は、プロンプトの書き方でパフォーマンスが大きく変わる。「レート制限を追加して」と書くのと「Express.jsのAPIルートにIPベースのレート制限を追加し、429を返すテストを書いて」と書くのでは結果が違う。ゴールは高レベルでいいが、具体的であるほど成功率が上がるはずだ。

ターミナルAIコーディングの「自律化」は、もう特定のツールの専売特許ではなくなった。競争のフェーズが「モデルの賢さ」から「ワークフロー設計」に移りつつある。