Claude CodeとGrok Buildの比較 — 権限・hooks・設定の読み込みの違い

Grok Buildは、xAIが出しているターミナル向けのコーディングエージェントです。起動コマンドはgrokで、TUI、grok -pによるヘッドレス実行、Agent Client Protocol(ACP)経由の組み込みの3通りで使えます。Claude Codeを使っている人にとって最大の特徴は、Claude Codeの設定資産をほぼそのまま読み込む点です。

比べると、骨格はよく似ています。違いが出るのは、権限モードの数、サンドボックスの既定、hooksの種類、AGENTS.mdの読み方です。

同じ設定ファイルが両方で動く

Grok Buildのドキュメントは、Claude Codeとの互換性を「設定不要」と書いています。Claude Codeのマーケットプレイス・プラグイン・スキル・MCP・エージェント・hooks・指示ファイルを、.grok/と並べて自動で読みます。

読み込み対象は次のとおりです。

MCPは[compat.claude] mcps = falseで互換読み込みを止められます。何が読まれたかはgrok inspectで確かめます。

cd your-project
grok inspect

grok inspectは、設定の出どころ、指示ファイル、スキル、プラグイン、hooks、MCPサーバーを現在のディレクトリ基準で一覧します。Claude Codeのリポジトリを渡したときに、何が拾われるかを最初に見る手段になります。

逆向きは非対称です。次の節で扱うとおり、Claude CodeがAGENTS.mdを読む条件は限られます。

AGENTS.mdとCLAUDE.mdの読み分け

指示ファイルの扱いは、両者でいちばん結果が変わる箇所です。

Grok Buildは、リポジトリルートから作業ディレクトリまでの各階層でAGENTS.md・Agents.md・AGENT.md・CLAUDE.md・Claude.md・CLAUDE.local.mdのどれでも読みます。.grok/rules/配下の*.mdも対象です。深い階層のファイルが競合時に優先されます。

Claude Codeの既定は違います。AGENTS.mdだけがあり、作業ディレクトリかその上にCLAUDE.mdもCLAUDE.local.mdもないときだけ、AGENTS.mdを読みます。両方あればCLAUDE.mdだけです。読み込みには、AGENTS.mdの直接読み込みに対応するClaude Code v2.1.277以降が必要です。

両方のツールを同じリポジトリで使うなら、CLAUDE.mdからAGENTS.mdを取り込む形が安全です。Claude Codeのドキュメントも、CLAUDE.mdにインポートを書く方法を案内しています。

# CLAUDE.md
@AGENTS.md
 
## Claude Code固有の指示
- テストは変更したファイルの範囲だけ回す

こうしておけば、Claude CodeはAGENTS.mdをインポート経由で読み、Grok BuildはAGENTS.mdとCLAUDE.mdの両方を読みます。同じ規約が二重に載る点は、Grok側の読み込み量として見ておく必要があります。Grok Buildは指示ファイルを上限なしで全文読み込むと書いているためです。

権限モードとサンドボックス

承認の仕組みは、モードの数と切り替え方が違います。

Grok BuildのAutoは、分類器が安全なツール呼び出しを自動承認する方式で、有効化された機能のときだけ使えます。Always-approveでもdenyルールとPreToolUse hooksは効きます。ここはClaude Codeのautoと同じ考え方です。

Plan modeの挙動は近いものの、Grok Buildには注意書きがあります。計画ファイル以外の編集ツールは止まる一方で、bashは止まりません。リダイレクトでファイルに書けてしまいます。Claude Codeでもplanモードは編集を止めますが、シェル経由の書き込みまで塞ぐかは、サンドボックスの設定と合わせて考える点です。権限モデルを4製品で並べた違いは、AIコーディングエージェント 権限モデル比較にあります。

サンドボックスは、どちらも既定でオフです。

• Grok Build: macOSはSeatbelt、LinuxはLandlock。off・workspace・devbox・read-only・strictの5プロファイルを--sandboxで選ぶ。子プロセスのネットワーク遮断はLinuxだけで有効で、macOSではread-onlyとstrictでも効かない
• Claude Code: macOS・Linux・WSL2で動く。ネイティブWindowsではサンドボックスなしで実行される。対象はシェルコマンドで、ファイルツール・MCPサーバー・hooksは枠の外

どちらも、サンドボックスは「承認された呼び出しが何をできるか」を絞る別の層という位置づけです。実装の差はAIコーディングエージェントのサンドボックス実装比較で、Codex・Cursor・Devinとも並べています。

hooksで見落としやすい失敗時の挙動

hooksの設定の形は、意図的に互換です。matcherでツール名を正規表現で絞り、PreToolUseでdenyを返すか終了コード2で止める、というJSONはそのまま通ります。Bash・Read・EditといったClaude Codeのツール名は、Grok側のツールに自動で対応づけられます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "bin/safety-check.sh", "timeout": 10 }]
      }
    ]
  }
}

差が出るのは次の3点です。

• イベントの数: Grok Buildの表はSessionStart・PreToolUse・Stop・PreCompactなど、ひとまとまりに収まる数のイベントです。Claude CodeにはPermissionRequest、WorktreeCreate、FileChanged、Elicitationなども別途あります。Claude固有のイベントを使うhooksは、Grokでは発火しないと見ておく必要があります
• ハンドラの種類: Grok Buildはcommandとhttpの2種類です。Claude Codeはcommand・http・mcp_tool・prompt・agentの5種類を持ちます
• ブロックの条件: Grok BuildでブロックできるのはPreToolUseだけで、タイムアウト・クラッシュ・不正な出力はすべてフェイルオープンです。ツール呼び出しはそのまま進みます。Claude Codeも終了コード2以外はブロックしませんが、onFailure: "block"を設定すれば、hookの失敗でも止められます

hooksの全イベントと設定の書き方はClaude Code Hooks完全ガイドにまとめています。

スキル・MCP・サブエージェント

ここは対応が素直です。

出力形式のフラグ値は綴りが違います。Grok Buildはstreaming-json、Claude Codeはstream-jsonです。CIのスクリプトを両対応にするなら、ここは分岐が必要です。

スキルのSKILL.mdは、どちらもYAMLのフロントマターで始まり、name・descriptionなどを持ちます。Grok Buildはmodel・effort・license・compatibilityを受け取っても適用しません。Claude Code向けに書いたスキルをそのまま渡すと、モデルの指定が効かない場合があります。スキルの書き方はClaude Code Skillsのfrontmatter全フィールドにあります。

MCPは両方とも標準のプロトコルなので、接続先の定義さえ共有できれば同じサーバーに繋がります。Grok Buildは.mcp.jsonをClaude Codeと同じ位置から読み、config.tomlの定義より低い優先で重ねます。5ツールのMCP対応を比べた記事はAIコーディングエージェントのMCP対応状況です。

Grok Buildのコマンド表で目立つ独自機能

Claude Codeの使い方と見比べると、次の4つがGrok Buildに特有です。

• /goal <目的>: 目的を渡すと、毎ラウンドの後に進捗を判定して続行する。完了に見えると、レビュー役のサブエージェント群が証拠を確かめ、過半数が同意したときだけ完了にする。--budget <トークン数>で上限を付けられる
• /create-workflowと/workflow: サブエージェントを束ねる手順を.grok/workflows/<名前>.rhaiとして保存し、再実行する
• /imagine・/imagine-video: テキストから画像や動画を生成する
• /import-claude: Claudeの設定をインポートするモーダルを開く

/goalの使いどころは、完了条件を検証できる作業です。ドキュメントも「認証モジュールを新APIに移行する」より、「認証テストが通ること、公開エンドポイントを変えないこと」まで書く形を推奨しています。条件を書く習慣は、Claude CodeでStop hookに完了条件を持たせる運用と近い発想です。

逆に、Claude Code側にあってGrok Buildのコマンド表に載っていないものもあります。ただし、表に載っていないことと機能がないことは別なので、移行前にgrok inspectと/helpで実環境を確かめるのが確実です。

どこで差がつくか

使い分けの判断は、既存資産とセキュリティの置き方で決まります。

• Claude Codeの設定資産が厚いチーム: CLAUDE.md・hooks・MCP・スキルが、Grok Buildにそのまま通ります。試す手間は小さく、grok inspectで拾われた内容を確認すれば足ります
• AGENTS.mdで他ツールと共有しているリポジトリ: Claude Code側の読み込み条件を確認します。CLAUDE.mdが一つでもあるとAGENTS.mdは読まれません
• hooksで安全確認を組んでいるCI: フェイルオープンの違いと、プロジェクトhooksの信頼設定を先に確認します
• 長時間の自走で完了条件を検証したい作業: /goalはGrok Build固有の仕組みで、Claude Code側は別の組み方になります

Grok Buildのドキュメントには料金表がなく、/usageでクレジットの使用量を見られると書かれているだけです。チャット製品としてのClaudeとGrokの料金・モデル・安全性方針はClaude Grok比較にあります。同じ軸でほかのエージェントと並べた記事には、Kilo Codeとの比較もあります。