デザインのための Grok Build。

Grok Build とは実際に何か

Grok Build は xAI のターミナル向けコーディングエージェントで、Grok Build という名前で提供されています。リポジトリを読み取り、ファイルを編集し、シェルコマンドを実行し、行を補完するだけでなく、自然言語のタスクから複数ステップのエンジニアリング作業を計画します。xAI の Grok モデルを中心に構築され — xAI API 上では grok-build モデルファミリーとして公開されています — xAI アカウントを通じて認証するため、エージェントとモデルが同じベンダーから来ます。

デザイン作業では二つの特性が際立ちます。プランモードを備え、変更が反映される前に承認・コメント・書き換えができる構造化されたアプローチを下書きすること — UI を反復するときに役立つゲートです。そして Grok モデルが画像入力を受け付けるため、参照スクリーンショットを渡せば、文章による説明から推測するのではなく実際のレイアウトについて推論することです。

• コンテキストファイル: Grok Build は永続的なプロジェクトコンテキストとして AGENTS.md ファイルを読み取ります。ここがデザイン規約・トークン・レビューチェックリストをエンコードする自然な場所です。Codex や他のエージェントが使うのと同じオープンな AGENTS.md 規約に従います。
• ツール、MCP＋サブエージェント: ファイルを編集し、シェルコマンドを実行し、MCP サーバーをサポートして、ライブの Figma ファイルのような外部コンテキストを追加できます。より大きなタスクでは、調査・構築・レビューを同時に行う並列サブエージェントへ委譲できます。
• アカウントでサインイン: SuperGrok または X Premium+ サブスクリプションでブラウザからサインインして認証します。ヘッドレスや CI 用途のために xAI API キーを持ち込むこともできます。

• ベンダー：xAI
• 認証情報：xAI SuperGrok OAuth（`grok login`）、またはヘッドレス用途の xAI API キー（BYOK）
• モデル：xAI Grok モデル（xAI API 上の grok-build ファミリー）、画像入力対応

なぜプランモードと画像対応モデルがデザインに合うのか

Grok Build のデザイン上の強みは二つの特性から来ます。ただし、どのエージェントでも同じく、センスは人間が供給しなければなりません。

• 画像対応の推論: Grok モデルが画像入力を受け付けるため、エージェントは参照スクリーンショットを読み取り、文章による説明から推測するのではなく、描画した出力を画像と照らし合わせます。
• 変更が反映される前のプランモード: プランモードは、ファイルが変わる前にあなたが承認する構造化されたアプローチを下書きするので、デザインの意図が差分の後に発覚するのではなく、前もってレビューされます。
• AGENTS.md の規約: AGENTS.md（に加えて Figma MCP サーバー）がエージェントをあなたのトークン・コンポーネント・本物の仕様へ向けるので、既定の見た目ではなくブランドに沿って作業します。

教訓はどのエージェントも示すものと同じです。Grok Build は既定ではセンスを持ちません。制約 — デザインシステム、美的スキル、具体的な参照素材 — を与えたときに、良いデザインを生み出します。Open Design はまさにそれらの入力をパッケージ化しており、だからこそ両者は噛み合います（詳しくは後述）。

デザイン作業のために Grok Build をゼロからセットアップする

まっさらなマシンから、UI を構築・検証できる Grok Build までの全行程はこちらです。

# 1. Install Grok Build (Grok Build) on macOS/Linux
curl -fsSL https://x.ai/cli/install.sh | bash

# 2. Start it in your project and authenticate on first run
cd your-project
grok login   # opens your browser; sign in with SuperGrok / X Premium+
#   or, for headless / CI use, set an xAI API key:
#   export XAI_API_KEY=xai-...

# 3. Add project context
#    create an AGENTS.md at the repo root with your design conventions

# 4. Wire the Figma MCP server (optional, for design handoff)
#    add it to your MCP server configuration

• デザインルールをエンコードする: トークン・プリミティブ・規約を AGENTS.md に入れ、Grok をそこへ向けます。そうすれば出力が平凡な既定の見た目に落ちるのではなく、ブランドに合致します。
• ブラウザ検証を追加する: Playwright またはブラウザ MCP を接続し、Grok が本物のブラウザで描画してブレークポイント横断で出力を確認するようにします。ビルドが通ることを確認するだけで終わらせないために。

スクリーンショットから UI へのワークフロー

Grok Build で最もレバレッジの高いデザインループは、参照画像を動作するレスポンシブな UI に変え、一致するまで反復することです。プランモードに頼ってアプローチに合意し、画像対応モデルに出力を参照と照らし合わせさせます。

1. 手元にある最も明確なビジュアル参照から始めましょう。そして 1 枚のヒーロー画像だけでなく、複数の状態（デスクトップとモバイル、ホバー、空、ローディング）を含めます。
2. プロンプトでは具体的に。曖昧なプロンプトは、強力なモデルでも平凡な UI を生みます。
3. デザインシステムと規約を AGENTS.md に保持し、トークンと正規のプリミティブがどこにあるかを Grok に伝えます。
4. プランモードでアプローチをレビューし、その後開発サーバーを起動して、Grok に本物のブラウザで描画させ、ブレークポイントへリサイズして結果を確認させます。
5. Grok に実装をスクリーンショットと照らし合わせさせて反復します。単にビルドが通ることを確認するだけにしません。

参照画像を添付し、具体的な制約を与えます：

grok
# in the prompt (attach reference-desktop.png and reference-mobile.png):
> Implement this design in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens from AGENTS.md.
  Match spacing, layout, and hierarchy; make it responsive.
  Show me the plan first, then render it in the browser and iterate
  until it matches the references across breakpoints.

プロンプトは小さく焦点を絞り、良い反復はコミットし、悪い反復はリバートして（リバートした際は Grok に伝えて）、各パスがきれいなベースの上に積み上がるようにします。

AGENTS.md、MCP、サブエージェント

三つの拡張ポイントが Grok Build を継続的なデザイン作業に実用的にし、そのいずれもオープンなデザインワークフローへきれいに対応します。

• AGENTS.md のコンテキスト: プロジェクトのルールはリポジトリのルートにある AGENTS.md に存在します。これはあなたのデザイン規約の永続的な置き場であり、実行のたびに読まれます。そして他のエージェントも理解する同じオープンな形式なので、ルールがあなたと共に旅します。
• MCP サーバー: MCP サーバーを設定して、デザインコンテキストや外部ツール、最も関連が深いものとしては Figma MCP サーバーを持ち込みます。これは本物の仕様をコードへ供給するためのポータブルな手段で、Grok に限らず複数のエージェント間で機能します。
• サブエージェントと組み込みツール: Grok Build は調査・構築・レビューを同時に行う並列サブエージェントを起動でき、ファイル・シェル・検索のツールにより、ターミナルを離れずに参照素材を集め、検証ループを回せます。

これらはポータブルでマルチエージェント対応の機能であり、まさに Open Design がプロジェクトごとに作り直すのではなくオーケストレーションするために作られたものです。

デザインにおける Grok Build 対 Codex 対 Claude Code 対 Cursor 対 Gemini CLI

デザイン作業に唯一の勝者はいません。各エージェントには異なる強みがあり、経験豊富なチームはそれらを重ねて使います。公平にまとめると：

コミュニティで繰り返される結論は、センスは人間から来るというものです。スキル・参照素材・制約がなければ、どれも平凡な美的傾向に落ちます。それこそが解くべき本当の課題であり、それはモデルの形ではなくデザインツールの形をしています。

落とし穴と「AI スロップ」感を避ける方法

AI 生成デザインに対する最も一般的な不満は、平凡に見えるというものです。ぼんやりしたグラデーション、浮いたパネル、過大な角丸、大げさな影、「AI が作ったと叫ぶ」ような Inter とパープルの雰囲気。報告されている他の問題には、崩れたモバイルレイアウトや、指示文が UI コピーに漏れ出ることなどがあります。これらはどれも Grok Build 固有のものではなく、どのエージェントであれキュレーションされたデザインコンテキストなしで動かしたときに起こることです。

• 美的スキルを追加する: キュレーション済みのデザインスキルは、エージェントに既定の見た目ではなく本物の方向性へ踏み込ませます。
• 本物のブラウザで検証する: ブレークポイント横断で描画・自己チェックし、モバイルでレイアウトが静かに崩れないようにします。
• トークンと参照素材を供給する: 本物のデザイントークンと参照スクリーンショットは、出力品質に対する単一で最大のレバーです。
• AGENTS.md にルールをエンコードする: 「ヒーローカードは禁止、書体は最大 2 種、ブランド優先の階層」といった様式ルールを、エージェントが実行のたびに読む場所に入れます。

どの緩和策も、エージェントにキュレーションされたデザインコンテキストを与えることに尽きる点に注目してください。そのコンテキストをプロジェクトごとに手作業で維持すること、それこそ Open Design が取り除く骨折り仕事です。

Open Design の中で Grok Build を使ってデザインする

Open Design は、上記のワークフローが繰り返し求めてくるオープンソースのデザイン層です。Grok Build をファーストパーティのアダプターとして扱い、キュレーション済みのスキルとデザインシステムのライブラリ、構造化されたレンダリングパイプライン、ローカルなデスクトップ UI でそれを包みます。だから Grok を良くするデザインコンテキストが、毎回手作業で組み立てるのではなく、最初の実行から揃っています。Open Design は独立しており、Apache-2.0 で、自分のマシン上で動くため、この組み合わせは自然です。

1. Open Design をインストールし、エージェントとして Grok Build を選びます。
2. あなたの SuperGrok アカウントまたは xAI API キー（BYOK）で認証します。認証情報はあなたのマシンに留まり、私たちを経由してプロキシされることはありません。
3. デザインシステムとスキルを選び、一貫したセンスでデッキ・プロトタイプ・ランディングページを生成します。
4. すべての成果物と DESIGN.md ファイルは、ホスト型クラウドではなくあなた自身のリポジトリに存在します。

同じ Grok Build エージェント、同じ認証情報。そこに本物でポータブルなオープンソースのデザインワークフローが加わります。ローカルファーストで Apache-2.0 なので、あなたの作業や認証情報に関する何も、マシンの外へ出ません。

よくある質問

1. 01 Grok Build は本当にデザイン作業をこなせますか？ +

   はい。美的スキル、デザインシステム、そして本物の参照画像をコンテキストに入れれば、Grok Build は本番品質のレスポンシブな UI を生み出し、その画像対応の Grok モデルが出力を参照に対して検証するのを助けます。そのコンテキストがないと平凡な見た目に落ちがちで、それこそ Open Design が埋めるギャップです。

2. 02 Grok Build の認証方法は？ +

   SuperGrok または X Premium+ サブスクリプションでブラウザからサインインします（`grok login`）。管理すべき API キーはありません。ヘッドレスや CI 用途では、代わりに xAI API キーを持ち込めます。いずれにせよ Open Design はあなたの認証情報を決してプロキシしません。

3. 03 Grok Build が特にデザインに向いている理由は？ +

   二つあります。プランモードにより、いかなる変更が反映される前にもアプローチをレビューできること。そして Grok モデルが画像入力を受け付けるため、参照スクリーンショットをよく読み取ること。どちらも役立ちますが、センスは依然としてあなたが供給するデザインシステム、スキル、参照素材から生まれます。

4. 04 フロントエンドのデザインには Grok Build と Claude Code のどちらが良いですか？ +

   どちらも強力です。Claude Code は具体的でコードベースを把握したデザイン判断で知られ、Grok Build の強みはプランモードによるレビューと画像対応の xAI モデルです。多くのチームは両方を使います。Open Design なら、デザインワークフローを変えずにエージェントを切り替えられます。

5. 05 Grok Build を Figma に接続するには？ +

   あなたの MCP 設定に Figma MCP サーバーを追加します。すると Grok は本物のデザインコンテキスト — コンポーネント、変数、レイアウトデータ — を取り込めるので、生成されるコードは近似ではなくソースに合致します。

6. 06 Open Design は xAI と提携していますか？ +

   いいえ。Grok Build は xAI の製品です。Open Design は独立したオープンソースプロジェクトで、それをファーストパーティのアダプターとしてサポートします。Grok は xAI の商標です。

7. 07 私のファイルと認証情報は安全ですか？ +

   はい。Open Design はローカルファーストで Apache-2.0 です。あなたのファイル、成果物、DESIGN.md はあなた自身のリポジトリに留まり、xAI の認証情報はあなたのエージェントが直接使い、Open Design のサーバーを経由してルーティングされることは決してありません。