はじめに

2026年8月、xAIのターミナル型コーディングエージェント「Grok Build」がV1.0に到達しました。

ターミナルで動くAIエージェントといえば、AnthropicのClaude CodeとOpenAIのCodex CLIが先行しています。そこに後発で飛び込んできたのがGrok Buildです。正直なところ「また似たようなCLIが増えたのかな」と思った方もいるのではないでしょうか。うさぎも最初はそう思っていました。

ところが調べていくと、Grok Buildには他の2つとはっきり違う設計思想がありました。しかも既存のClaude Code資産をほぼそのまま引き継げるという、なかなか大胆な作りになっています。

本記事は2026年8月時点の公開情報をもとにしています。xAIの公式発表を軸に、国内外のレビュー記事も参照しながら、Grok Buildの正体、Claude CodeやCodex CLIとの違い、MCPやスキルへの対応、そして性能までを整理していきます。

記事の後半では、実際にGrok BuildとChatGPTへ同じお題を投げて、Fusion 360で3Dモデルを作らせてみた実践パートも用意しました。コード以外の領域にエージェントの手が届く感覚を、ぜひ味わってみてください🐰

この記事でわかること

• Grok BuildはxAIのターミナル型コーディングエージェント。2026年5月25日に早期ベータ、同年8月7日にV1.0.0へ
• AGENTS.md、プラグイン、フック、スキル、MCPサーバーが標準で動作。Claude Code向けの設定資産をそのまま流用できます
• ベンチマーク性能は既定モデルのGrok 4.6で見ると上位勢にわずかな差まで迫っています

それでは、ひとつずつ見ていきましょう。

生成AIの社内利用をお考えの企業様へ 
ナレフルチャットは初心者でも使いやすい設計で、組織全体への生成AI浸透を支援するツールです。プロンプト自動生成機能や社内共有機能により、AIリテラシーに差があっても全員が活用できます。企業のAI導入を検討している方は、こちらをご覧ください。

Grok Build とは何なのか

まずは正体を押さえます。ターミナルから起動して、コードを読んで書いて実行してくれるAIエージェント、という位置づけのツールです。

Grok Buildは、xAIが提供するコーディングエージェントのCLIです。公式の説明では「ターミナルから直接動く新しいコーディングエージェント」と紹介されています。

新しいセッションは既定でGrok 4.6モデルで起動します。単なるコード補完ではなく、計画を立てて手順を実行し、失敗したらデバッグして、開発ツールと連携するところまでを担当します。

V1.0までの歩み

リリースの流れを時系列で見ると、動きの速さがよくわかります。

出典 xAI「Introducing Grok Build」、xAI Grok Build Changelog

ベータ公開からV1.0.0まで、およそ2か月半という速さです。その後もアップデートが続いており、2026年8月12日時点でv1.0.3まで出ています。

V1.0は「新機能」より「磨き込み」

V1.0と聞くと派手な新機能を期待したくなりますが、実際の中身は少し違います。報じられている変更点は次のような内容です。

• インターフェースの刷新。ナビゲーションの整理、マークダウン表示の改善、キーボード操作の統一
• 権限まわりの改善。スクリプトを実行する前に内容を表示するようになり、中断もしやすくなりました
• 信頼性の向上。ログイン失敗の修正、大きなディレクトリでの起動最適化、MCPツールが画像を返す場合への対応

つまりV1.0は、機能を増やすというより「毎日使える状態に仕上げる」ためのリリースだったと理解するのが自然です。エージェントに実際のファイルを触らせるツールですから、権限表示や中断のしやすさが整うのは地味に効いてきます。

公式チェンジログで確認できるV1.0.0の変更点は次のとおりです。

出典 xAI Grok Build Changelog

インストール

macOS / Linux はインストールスクリプト一行で完了します。

curl -fsSL https://x.ai/cli/install.sh | bash

Windowsの場合はPowerShellで次を実行します。

irm https://x.ai/cli/install.ps1 | iex

インストール後、認証を済ませてプロジェクトのディレクトリに移動し、やりたいことを伝えれば動き出します。

cd your-project
grok

初回はモデルの認証やプロジェクトの読み込みが走るため、少し待ち時間が発生することがあります。数十秒ほど反応がなくても、慌てずに待ってみてください。

Grok Build の主要機能

ここからは中身の話です。Grok Buildが何を売りにしているのか、機能ごとに見ていきます。

Plan Mode 計画を見せてから動く仕組み

実装に入る前に計画フェーズを設け、アプローチを確認してからコードを書く仕組みです。

Plan Modeへの入り方は2つあります。エージェントが「このタスクには曖昧さがある」と判断したとき自動で提案する場合と、Shift+Tabでユーザーが手動で切り替える場合です。既定の起動状態はノーマルモードです。

Plan Mode中は、計画ファイル（plan.md）以外のファイル編集が一切ブロックされます。つまり承認するまでコードは変わりません。

流れはこうなります。

1. やりたいことを自然言語で伝えます
2. エージェントがコードベースを読んで実装方針を設計し、plan.mdに書き出します
3. あなたは計画を承認するか、コメントするか、まるごと書き換えるかを選べます
4. 承認後に実行が始まり、変更はすべて差分として表示されます

公式でも「計画と実装を分離することで、コードが書かれる前にアプローチを確認・修正できる」と説明されています。

出典 公式ユーザーガイド Plan Mode

計画段階で軌道修正できる作りは、「気づいたら意図しないファイルまで書き換わっていた」という手戻りをかなり減らしてくれます。特に影響範囲が広いリファクタリングや、アーキテクチャの選択肢が複数あるタスクで効果が大きいです。

並列サブエージェント 作業を分けて同時に走らせる

大きなタスクを小さく分割し、複数のエージェントに同時進行させる機能です。

Grok Buildは、大きめのタスクになるとメインのエージェントが作業を分解し、専門化されたサブエージェントへ割り振ります。各サブエージェントは独立したコンテキストウィンドウを持ち、調査・実装・テスト・コードレビューを並列でこなします。完了するとサマリーを親エージェントへ返す仕組みです。

サブエージェントは既定で有効です。使いたくない場合は環境変数 GROK_SUBAGENTS=0 か設定ファイルで無効化できます。

worktreeによる隔離（オプトイン）

サブエージェントはデフォルトで親と同じ作業ツリーを共有します。ファイル編集を伴うタスクで衝突を避けたい場合は、isolation: worktreeを明示することで隔離された環境で動かせます。

なお、ネストの深さは最大1段までです。サブエージェントがさらにサブエージェントを生成しようとすると失敗します。エージェントツリーをフラットに保つ設計です。

出典 公式ユーザーガイド Subagents

MCP対応 手持ちのツールをそのままつなげる

MCPとはModel Context Protocolの略で、AIアプリケーションを外部のツールやデータへつなぐための共通規格です。

Grok BuildはこのMCPにネイティブ対応しています。公式の表現では、AGENTS.md、プラグイン、フック、スキル、MCPサーバーが「すべて最初から動く」とされています。

ここが実用面でとても大きなポイントです。GitHub、Linear、Slack、社内データベース、CIといった、すでにMCPサーバーとして用意してあるものは、設定を書き直さずにそのまま持ち込めます。社内の知識ベースや独自APIを接続する使いかたも想定されています。

MCPそのものの仕様を確認したい方は、公式サイトが参考になります。

出典 Model Context Protocol 公式サイト

スキルとプラグイン 得意分野を持たせる

スキルは、繰り返し使う指示をパッケージにしたものです。プラグインは、そのスキルにMCPサーバーやフックなどを束ねた、より大きな配布単位です。

整理すると次のようになります。

スキルの置き場所は./.grok/skills/または~/.grok/skills/です。そして注目すべきは互換性で、.claude/skillsのようなClaude Code向けのディレクトリも自動的に認識されるとされています。

プラグインの導入はコマンド一発です。

grok plugin install <name> --trust

MCPサーバーの追加も同様にシンプルです。

grok mcp add --transport http composio https://connect.composio.dev/mcp

現在の設定がどこから読み込まれているのか確認したいときは、inspectコマンドが便利です。設定の出どころ、指示、スキル、プラグイン、フック、MCPサーバーをまとめて表示してくれます。設定が効いていないときの切り分けが一気に楽になります。

出典 Composio「Top Grok Build CLI Skills and Plugins」

Claude Code、Codex CLIとの違い

3つとも「ターミナルで動いてコードを触るAIエージェント」という同じカテゴリの製品です。ただ、力を入れているポイントがそれぞれ違います。

スペック比較

出典 Codersera「Grok Build vs Claude Code vs Codex CLI」、公式ユーザーガイド Project Rules

三者三様の設計思想

数字よりも、それぞれが何を大事にしているかを掴むほうが選択には役立ちます。

Grok Buildが大事にしているのは、効率と乗り換えやすさです。同じタスクをこなすのに必要なターン数やトークン消費量が少なく、完了あたりのコストを抑えやすい傾向があるとされています。そこにPlan Modeの計画・確認フローと、サブエージェントの並列実行を組み合わせました。さらにClaude Code向けの設定やスキルをそのまま読み込めるため、乗り換えを迫るというより、今使っているツールと並行して気軽に試せる入り口になっています。

一方のClaude Codeが軸にしているのは、長いコンテキストを活かした大規模対応です。大きめのコードベースでも安定して力を発揮し、本番運用で実績のある経路として位置づけられています。派手さよりも手堅さを重視した設計と言えるでしょう。

Codex CLIが体現しているのは、「人間が操縦し、エージェントが実行する」という思想です。人間はタスクを見極めて指示を出すことに専念し、実際の作業はエージェントに委ねます。エンジニアの役割も、コードを書くことから環境設計へ変わったといいます。

出典
Codersera「Grok Build vs Claude Code vs Codex CLI」
OpenAI「ハーネスエンジニアリング エージェントファーストの世界におけるCodexの活用」

乗り換えコストの低さは効きます

比較のなかで、実務上いちばん見逃せないのがここです。

Grok BuildはAGENTS.mdに対応し、加えてClaude Code向けのスキルディレクトリも認識します。すでにClaude Codeでプロジェクトのルールを整備しているチームなら、設定を書き直さずに試せるということです。

うさぎとしては、設定を作り直さずに並行して走らせて比べられるのは、思っていたよりずっと大きな利点だと感じています。どちらか一方に決める前に、同じタスクを両方に投げて比べる、という進めかたが取りやすいうさよ🐰

性能と価格をどう見るか

ベンチマークの数字を見ると、Grok Buildの既定モデルGrok 4.6は上位勢にわずかな差まで迫っています。

ベンチマーク

SWE-bench Verifiedは、実際のバグ修正課題をどれだけ解けるかを測る、エージェント型コーディングの代表的な指標です。

第三者ベンチマークサイトVals AIが2026年8月時点で公開しているSWE-bench Verifiedの結果（同一のスキャフォールドMini-SWE-agentで統一評価）は次のとおりです。

Grok Buildの既定モデルであるGrok 4.6は、最上位のClaude Opus 5との差がわずか1.4ポイントまで縮まっています。

ただし、この表が測っているのはあくまで「モデル単体」の性能です。Grok Build・Claude Code・Codex CLIという「CLIツールとしての強さ」を直接比較したものではない点には注意してください。ツールとしての実力は、Plan Modeやサブエージェントをどう使いこなすかによっても変わってきます。

出典 Vals AI「SWE-bench Verified」

価格

Grok Buildは既定でGrok 4.6モデルを使います。2026年8月時点のGrok 4.6の公式API価格は次のとおりです。

200,000トークンを超えるリクエストには別料金が適用されるとされているため、大きめのコンテキストを使う場合は事前に公式ページで確認しておくと安心です。

出典 xAI Docs「Grok 4.6」

CLIはSuperGrokやX Premium Plusといったサブスクリプションに紐づく形で提供されています。APIキー経由でも利用できます。

今のGrok Buildをどう位置づけるか

まとめると、次のような温度感が現実的です。

• 本番の主力をいきなり総入れ替えするフェーズではありません
• 一方で、設定資産を流用して並行運用しながら試す価値は十分にあります
• Plan Modeの安心感や並列実行の速さが刺さる作業では、今でも選ぶ理由になります
• モデル側の伸びが早い領域なので、数か月単位で状況が変わる前提で見ておくのが良さそうです

法人向け生成AIサービス「ナレフルチャット」では、最新のGrok4.6をはじめ、ChatGPT、Gemini、Claudeなど各種主要LLMの最新モデルを選んで利用可能！用途に応じて使い分けるなど最適なAI活用を可能にします。
また、料金プランは企業単位の定額制を採用しており、何人で利用しても追加のコストは発生しないため、コスト管理の手間がかからないスムーズな全社導入を実現できます。
初月無料で生成AIが利用できるトライアル期間も用意しておりますので、生成AIの利活用を検討している企業様は、是非一度導入をご検討ください。

実際に触ってみた Grok BuildとChatGPTでFusion 360を動かす

ここからは実践パートです。同じお題をGrok BuildとChatGPT（GPT-5.6 Sol）の両方に投げて、Fusion 360で3Dモデルを作らせてみました。以下は実際に手元で動かした結果です。

お題 マイクアームに付ける哺乳瓶ホルダー

実はこの記事を書いている今、我が家に新しい家族が増えました🐰 抱っこしながらの授乳や哺乳瓶の扱いに毎日格闘するなかで、ちょうど手元にあったマイクスタンド用のアームに瓶を固定できたら楽になるのでは、と思いついたのがきっかけです。せっかくなら検証のお題も、単なるサンプルコードではなく日常で本当に使えそうなものにしたいと考えました。

そこで今回のお題は、ピジョン製の哺乳瓶を、トングのような形状で挟んで固定するクリップにしました。持ち手の付け根には雌ネジを設け、YoPINのマイクスタンド／マイクアームへ直接ネジ込めるようにする、という指定にしました。両方のツールに、まったく同じ文面のプロンプトを渡しています。

ピジョン製の哺乳瓶を、はさみ（トング）のような形状で挟み込んで固定するクリップ／
ホルダーを設計してください。その器具の末端（持ち手の付け根部分）には雌ネジを設け、
YoPINのマイクスタンド／マイクアームに直接ネジ込んで取り付けられるようにしてください。
Fusion360で3Dモデルを作成し、哺乳瓶の外径やYoPINマイクアーム側のネジ規格など、
必要な仕様は事前に調査した上でモデルに反映してください。

単純な立方体ではなく、寸法の裏取り（哺乳瓶の外径、ネジ規格）とCAD操作の両方を一度に要求する、実務に近いお題です。

Grok Buildの結果

Grok Build（Grok 4.6、highモード、always-approve）にプロンプトを渡すと、まずタスクを5つのToDoに分解しました。

1. ピジョン哺乳瓶の外径・形状を調査
2. YoPINマイクアームのネジ規格を調査
3. Fusion 360 MCPツールと現在ドキュメントを確認
4. トング型ホルダーをFusion 360でモデリング
5. 寸法検証とスクリーンショット

出てきた設計は、可動する顎を開いて瓶を挟み、ロックノブで固定し、末端のハブをマイクアーム先端にネジ込むという方式です。ブームの角度を変えることで、授乳角度も調整できるようにしてありました。

Fusion 360のツリーを見ると、TongBase（土台）、TongArm（可動アーム）、PivotPin（可動部の軸）、VelcroStrap（面ファスナーの帯）、JawPads（挟む部分のパッド）、Ref_YoPIN_38Male（ネジ規格の参照コンポーネント）という6つの部品で構成されていました。

さらにGrok Buildは、3Dプリントを見越したファイルまで出力していました。

• Fusionプロジェクト Default Project / Pigeon_Bottle_Tong_Clip
• 再生成用スクリプト bottle_clip/build_pigeon_tong_clip.py
• 印刷用STL bottle_clip/TongBase.stl ほか

印刷素材はPETGかナイロン、周4壁・インフィル30%以上を推奨し、ネジ部は実体ねじのため初回は5/8と3/8のタップで軽く追うと確実、というところまで具体的なアドバイスが添えられていました。

ChatGPT（GPT-5.6 Sol）の結果

まったく同じプロンプトを、ChatGPTのフルアクセスモード（モデルはGPT-5.6 Sol、reasoningはhigh）にも渡しました。

出てきたのは、ばね閉鎖式のトング形状です。仕様は次のようにかなり具体的な数値で提示されました。

見た目は、赤いキャップの瓶を黒いクランプ機構で挟み込み、グレーの円柱状マウントでマイクアームに接続する形です。Grok Buildのような可動式のピボット機構ではなく、ばねで閉じる固定式のクランプという方向性でした。なお、こちらは今回3Dプリントまでは試していません。

比較して見えたこと

同じお題・同じプロンプトでも、出てきた設計の方向性は次のようにはっきり分かれました。

うさぎとしては、Grok Buildが3Dプリント目線の後工程（印刷素材、インフィル率、タップ穴の下処理）まで踏み込んで提案してきた点が印象的でした。一方でChatGPTは、ネジ規格を主・代替の2系統用意するなど仕様面での抜かりのなさが光りました。どちらが優れているというより、同じ指示でも設計者としての癖がはっきり出るという発見が面白かったです。

触ってみた感想

コードを書くためのエージェントが、CADの画面を実際に動かして哺乳瓶ホルダーを設計する光景は、想像していた以上に新鮮でした。

同じプロンプトを渡しても、Grok BuildとChatGPTでは機構の選びかたも仕上げの丁寧さも違う結果になりました。エージェントごとに得意不得意があることは知っていましたが、CADのような形のある成果物で違いを見せられると、納得感がまるで違いますね🐰

せっかくGrok BuildがSTLまで出力してくれたので、実際に3Dプリンターで印刷もしてみました。

外形の再現度や曲面のなめらかさ、ピボット部分の作り込みは、写真で見てもかなり高いクオリティに仕上がっていました。ところが、いざ組み立てて可動部を動かそうとすると、ジョー（挟む部分）が物理的に開閉しないことがわかりました。Fusion 360上では干渉なく動くように見えていたのですが、実物では可動範囲のクリアランス（隙間）が足りず、固まって動かない状態になっていたのです。

ここで改めて実感したのは、コードを書くAIエージェントは実行やテストをPCの中だけで完結できますが、3Dモデルの検証はそう単純にはいかないということです。CAD上で干渉なしと判定されていても、実際に印刷して組み立ててみるまで、可動部が本当に動くかどうかは分かりません。3Dプリントの世界は、まだPCの中だけでは完結しないのだと、あらためて感じさせられました。とはいえ、可動部の設計さえ詰め直せれば、造形そのものは十分実用レベルに届くクオリティだったと思います。

3Dプリントまで見据えた提案がほしいのか、仕様の網羅性を重視したいのかで選ぶツールを変えつつも、最後は必ず実物で確かめる、というのが今のところの結論です🐰

まとめ

Grok BuildはxAIのターミナル型コーディングエージェントで、2026年5月のベータから8月のV1.0まで駆け抜けてきました。既定モデルはGrok 4.6で、ベンチマークも上位勢にわずかな差まで迫っています。

他ツールとの一番の違いは、Plan Modeとサブエージェントの並列実行が最初から前面に出ていること、そしてAGENTS.mdやスキル、MCPサーバーがClaude Code資産をそのまま流用できることです。すでにClaude Codeを使っているなら、試すコストはほとんどかかりません。

うさぎとしては、MCP経由でFusion 360まで動かせたのが今回いちばんの収穫でした。コードの外側までエージェントの手が届く感覚は、実際に触ってみないとわからないものがあります。ただし3Dプリントの検証で分かったとおり、PCの中だけでは完結しない領域もまだ残っています。

Grok Buildは今すぐ主力を置き換えるツールというより、気軽に比較できる新しい選択肢として面白い立ち位置です。あなたも自分の道具をひとつ、つないでみてはいかがでしょうか🐰

ここまでお読みいただき、ありがとうございました。