Grok Buildとは｜xAI公式grok CLIの使い方と「★23K OSS」の正体を実測で解説

grok CLI（Grok Build）は、xai-orgが2026年7月に公開したターミナル常駐のAIコーディングエージェントです。Rust製のフルスクリーンTUIとして動き、公開からわずか15日でGitHubスター23,234を集めました。ただしそのリポジトリを実際に開くと、コミットは14本しかなく、しかも全部がbotによる同期です。この記事では、grok コマンドのインストールと使い方を押さえたうえで、この「★23KのOSS」が実際にはどういう形で公開されているのかまで、公式資料と実測値で確認していきます。

AIコーディングツール全体の地図から見たい方は、まずVibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026を読むと、本記事のGrok Buildがどの位置に来るかが掴めます。

Grok Buildとは——xAI公式のターミナル常駐コーディングエージェント

Grok Build は、GitHub の xai-org 組織が2026年7月14日に作成したリポジトリ xai-org/grok-build で公開されている、ターミナルベースのAIコーディングエージェントです。公式READMEはこれを「フルスクリーンのTUIとして動作し、コードベースを理解し、ファイルを編集し、シェルコマンドを実行し、Webを検索し、長時間タスクを管理する」と説明しています。

まず名称について、観測される事実をそのまま整理しておきます。リポジトリのオーナーは xai-org ですが、README と CONTRIBUTING.md の中で開発元は「SpaceXAI」と自称しており、ロゴ素材のファイル名も spacexai-symbol-* です。配布とドキュメントは x.ai ドメイン（x.ai/cli、docs.x.ai/build/overview）で提供されています。本記事では、リポジトリ名に合わせて xai-org 公式のプロダクトとして扱います。

技術的な骨格は次のとおりです。実装言語は Rustで、rust-toolchain.toml はツールチェインを channel = "1.92.0" に固定しています。同ファイルには「最新の安定版を使うが、バンプは手動で行う」「不要な変更を避け回帰検出を単純にするため、1ポイントバージョンずつ上げる」「リリースから最低でも数週間待ってから上げる」というコメントが添えられており、依存の更新を保守的に運用していることが読み取れます。

利用形態は3通り用意されています。

・対話TUI：grok と打つとフルスクリーンのUIが起動する。マウス操作にも対応
・headless：grok -p "プロンプト" で非対話実行。スクリプトやCI/CDに組み込む
・ACP連携：Agent Client Protocol 経由でエディタに埋め込む

配布されるバイナリ名にも注意点があります。ソースからビルドすると成果物は xai-grok-pager という名前になりますが、公式インストーラーが配置するときは grok という名前になります。READMEはこの差を明示しており、リポジトリ内のクレート構成も xai-grok-pager（TUI本体）、xai-grok-shell（エージェントランタイムと各エントリポイント）、xai-grok-tools（ツール実装）、xai-grok-workspace（ファイルシステム・VCS・実行・チェックポイント）という分割になっています。

インストールと初回起動——grok CLI の始め方

公式が案内する導入手順はワンライナーです。macOS・Linux、そしてWindowsでもGit Bash経由なら次のコマンドが使えます。

# macOS / Linux / Git Bash
curl -fsSL https://x.ai/cli/install.sh | bash

# バージョンを固定して入れる場合
curl -fsSL https://x.ai/cli/install.sh | bash -s 0.1.42

# 導入確認
grok --version

Windows のPowerShellにはネイティブのインストーラーが用意されています。こちらは %USERPROFILE%\.grok\bin をユーザーPATHへ自動追加します。WSLを使っている場合は自動的にLinux版バイナリが入ります。

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

# バージョン指定
$env:GROK_VERSION="0.1.42"; irm https://x.ai/cli/install.ps1 | iex

導入後、プロジェクトディレクトリで grok と打つと初回認証が走ります。ブラウザが開いて grok.com でのサインインを求められ、成功すると資格情報が ~/.grok/auth.json に保存されます。以降のセッションでは自動的に読み込まれ、更新もGrok側が自動で行い、更新不能になった時点で再サインインを促す設計です。

ブラウザを開けない環境——CI/CDランナーやリモートのコンテナなど——では、APIキー方式に切り替えられます。

export XAI_API_KEY="xai-..."
grok

公式ドキュメントの認証章には、このほかOIDC・外部認証プロバイダー・デバイスコードフローも用意されていると記載があります。更新は grok update で行い、セッション単位で更新チェックを止めたい場合は --no-auto-update を付けます。

なお、ソースからビルドする場合は少し準備が要ります。RustツールチェインはrustupがREADMEの固定バージョンを自動導入しますが、それとは別に DotSlash が必須です。リポジトリの bin/ 配下に置かれたハーメティックなツール（特に bin/protoc）がDotSlash経由でダウンロード・実行されるためで、ビルド前に cargo install dotslash などで導入し、dotslash にPATHを通しておく必要があります。ビルドホストとしてサポートされるのはmacOSとLinuxで、Windowsビルドはベストエフォートかつこのツリーからは現在テストされていない、とREADMEは明記しています。

★23,234の「OSS」の正体——コミット14本、すべてbot

ここからが、他のコーディングエージェントCLIとGrok Buildを最も強く分ける部分です。

2026年7月29日時点でGitHub APIから取得した実測値は、スター 23,234、フォーク 4,402、Watch 180、ライセンス Apache-2.0、主要言語 Rust です。リポジトリの作成日は2026年7月14日なので、公開からおよそ15日での到達になります。単純平均すると1日あたり約1,550スターですが、これはあくまで期間全体をならした平均値で、日々の増加曲線を示すものではありません。

一方、開発の実態を示す数値は対照的です。

・総コミット数は14本。最初のコミットは2026年7月16日の Publish harness and TUI open-source（c68e39f6）
・コントリビューターは1人だけで、その正体は grokkybara[bot] というボットアカウント
・2本目以降のコミットメッセージはすべて Synced from monorepo（同期は概ね1日1回のペース）
・ReleaseもTagも0件。バージョン配布はGitHub Releasesではなく x.ai/cli のインストーラーと x.ai/build/changelog で行われる
・Issueは無効化され、プルリクエストの作成は共同作業者のみに制限されている

この構造の理由は、リポジトリ自身が説明しています。READMEには「このリポジトリは grok CLI/TUI とそのエージェントランタイムのRustソースを含む。SpaceXAIのモノレポから定期的に同期されている」とあり、ルートには SOURCE_REV というファイルが置かれ、このツリーに存在するコードがモノレポのどのコミットに対応するかをフルSHAで記録しています（2026年7月29日時点の値は 2a818575225183d8ca915f5632a09b8067b5156a）。

そしてCONTRIBUTING.mdは、方針をさらに明確に述べています。「このリポジトリは外部のプルリクエストや未依頼のパッチを受け付けない」「SpaceXAIはこのソフトウェアを社内で開発している」「公開ツリーはソースの透明性とローカルビルドのためにApache-2.0の条件で公開されている」。外部貢献を受け付けないため、CLA（コントリビューターライセンス契約）も提供されていない、と続きます。脆弱性については公開Issueではなく SECURITY.md の手順で報告するよう案内されています。

つまり Grok Build は、コードが読めて手元でビルドできるという意味では紛れもなくオープンソースですが、開発プロセスへ外部が参加する経路は開いていません。ライセンス上はApache-2.0が保証する自由（利用・改変・再配布・フォーク）がそのまま効くため、フォーク4,402件に対しWatchが180件という比率も、この構造を踏まえて眺めると理解しやすくなります。実際に手を入れたい人は、アップストリームへPRを送るのではなくフォークするしかありません。

中身はどう作られているか——codex と opencode からの移植12本

もう一つ、公開ツリーを読まないと分からない事実があります。エージェントのツール実装の一部が、他のオープンソースのコーディングエージェントから移植されていることです。

crates/codegen/xai-grok-tools/THIRD_PARTY_NOTICES.md は、次のように記載しています。

・src/implementations/codex/ 配下の apply_patch / grep_files / list_dir / read_file は、openai/codex の codex-rs/core/src/tools/handlers/ から移植（Apache-2.0、Copyright 2025 OpenAI）
・src/implementations/opencode/ 配下の bash / edit / glob / grep / read / skill / todowrite / write は、sst/opencode の packages/opencode/src/tool/ から移植（MIT、Copyright (c) 2025 opencode）

同ファイルは、移植したファイルが原典から変更されている（言語間で翻訳し、このクレートの Tool トレイトとランタイムに適合させ、拡張した）ことを明示し、これが Apache License 2.0 §4(b) が要求する変更の明示的告知にあたると述べています。

この記載は実態と一致します。GitHub API でディレクトリを引くと、crates/codegen/xai-grok-tools/src/implementations/ の下に実際に codex/ と opencode/ が存在し、通知に書かれたファイル名がそのまま並んでいます。移植元の側も確認したところ、openai/codex のライセンスはApache-2.0、sst/opencode はMITで、通知が指すパス（codex-rs/core/src/tools/handlers/、packages/opencode/src/tool/）はいずれも現存しています。

念のため補足すると、これはライセンス上の適正な手続きです。Apache-2.0もMITも、条件（著作権表示の保持、Apache-2.0では変更の告知など）を満たせば他プロジェクトへの取り込みを認めています。Grok Buildはその条件を満たす通知を、クレート単位とリポジトリルート（THIRD-PARTY-NOTICES）の二段で用意しています。読み取れるのは「ターミナル型コーディングエージェントのツール層は、すでにOSS間で実装が共有される段階に入っている」という事実です。

同じ implementations/ ディレクトリには、移植ではない自製の実装も並んでいます。grok_build / grok_build_concise / grok_build_hashline、lsp、memory、skills、web_search、task_output、use_tool、editor_infra、search_tool、そして後述する cursor_rules_on_read.rs などです。

既定で ~/.claude と ~/.cursor を読む「compat」層

Grok Build を入れて最初に知っておくべき挙動が、他社ツールの設定を読みにいく互換レイヤーです。

公式ドキュメントの「Harness compatibility」章は、Cursor・Claude・Codex の互換性を制御するとしたうえで、「すべてのセルの既定値は true」と明記しています。設定ファイル ~/.grok/config.toml での記述は次の形です。

[compat.cursor]
skills = true     # ~/.cursor/skills/ と <cwd>/.cursor/skills/ を走査
rules = true      # ~/.cursor/rules/ と <dir>/.cursor/rules/ を走査
agents = true     # ~/.cursor/ の名前付き指示ファイルを走査
mcps = true       # ~/.cursor/mcp.json と <cwd>/.cursor/mcp.json を走査
hooks = true      # ~/.cursor/hooks.json と <cwd>/.cursor/hooks.json を走査

[compat.claude]
skills = true     # ~/.claude/skills/ と <cwd>/.claude/skills/ を走査
rules = true      # ~/.claude/rules/ と <dir>/.claude/rules/ を走査
agents = true     # ~/.claude/ と <dir>/.claude/CLAUDE*.md を走査
mcps = true       # ~/.claude.json のMCPサーバー定義を走査
hooks = true      # ~/.claude/settings.json のフックを走査

つまり、すでに Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き で解説したような ~/.claude/ 環境を作り込んでいる開発者の場合、grok を起動した時点でそれらのスキル・ルール・MCP定義・フックが追加設定なしに探索対象になります。Codexについては [compat.codex] に sessions セルのみが staged として存在し、skills / rules / agents / mcps / hooks の各セルは「予約済みで現在は不活性」であり .codex の探索を有効にしない、と明記されています。

MCPサーバーの読み込み元と優先順位も文書化されています。

すべての読み込み元は config.toml > Claude > Cursor > .mcp.json の優先順でマージされ、名前が衝突した場合は優先度の高い側が勝ちます。

スキルの探索についても同様で、~/.claude/skills/・~/.claude/commands/・~/.cursor/skills/ などが優先度つきで走査対象になります。ドキュメントには実務上の注意も書かれており、スキルとコマンドの探索は .gitignore を参照しないため、.claude/** をローカル専用としてignoreしているチームでも、ディスク上に存在すればロードされます。隠したい場合はリポジトリのignoreではなく、設定の [skills] ignore を使う必要があります。なおCursorが標準で同梱するスキル（shell、canvas、statusline など）は、設定にかかわらず常に除外されます。

自分の環境で何が読み込まれているか確認する

挙動を推測せず、手元で確かめるのが確実です。読み込まれたMCPサーバーとその由来（[cursor] / [claude]）は grok inspect で確認できます。走査そのものを止めたい場合は、環境変数か config.toml で個別に無効化します（解決順は「環境変数 > config.toml > 既定値(on)」）。

# 何がどこから読み込まれたかを確認する
grok inspect

# 他ベンダーの探索を止める（環境変数で一時的に）
export GROK_CLAUDE_SKILLS_ENABLED=false
export GROK_CURSOR_SKILLS_ENABLED=false
export GROK_CLAUDE_MCPS_ENABLED=false
export GROK_CURSOR_MCPS_ENABLED=false

# 走査対象になりうるパスが自分の環境にあるか棚卸しする
ls -la ~/.claude/skills/ ~/.cursor/skills/ 2>/dev/null
ls -la ~/.claude.json ~/.cursor/mcp.json 2>/dev/null

grok inspect はセッション開始時点で解決できていないセルを ? と表示し、該当する探索エントリはJSON出力で compatibilityStatus: "unresolved"、人間向け出力で [compat unresolved] と報告します。

grok CLIのheadlessモードとサンドボックス——CI組み込みと安全側の運用

対話TUIだけでなく、スクリプトやCIから使う経路が明確に用意されています。-p（--single）でプロンプトを渡すとheadlessモードになり、必要なツールを実行して結果を標準出力へ返し、応答完了とともにプロセスが終了します。

主要なフラグを整理すると次のとおりです。

ツール名は内部IDで指定する点が実務上の落とし穴です。ドキュメントは「シェルツールは bash ではなく run_terminal_cmd」と明示しています。また --disallowed-tools は Agent という特別なエントリを解し、Agent で全サブエージェントの起動を禁止、Agent(explore) で特定タイプのみ禁止、Agent(explore, plan) で複数指定、という制御ができます。

なお --tools / --disallowed-tools / --max-turns / --agents はheadless専用で、対話TUIで渡すと警告が出て無視されます。一方 --reasoning-effort（--effort）・--permission-mode・--allow・--deny は両モードで機能します。推論の強度は none / minimal / low / medium / high / xhigh / max が正準のレベルとして定義され、モデルが提示するメニューに載っているレベルのみ受け付ける仕様です。

サンドボックスは既定でoff

エージェントにシェルを渡す以上、権限の話は避けて通れません。Grok Buildにはサンドボックスがありますが、既定は off です。

有効化すると、LinuxではLandlock、macOSではSeatbeltというOSのカーネル機構でファイルシステムとネットワークのアクセスが制限され、プロセスの生存期間中カーネルが強制します。

# 通常の開発（読み取りはどこでも、書き込みはCWD＋一時ディレクトリ＋~/.grok/）
grok --sandbox workspace

# 読み取り専用（探索・コードレビュー向け）
grok --sandbox read-only

# 最も厳しい（未信頼コードを読むとき。読み取りもCWD＋システムパスに限定）
grok --sandbox strict

ここで必ず読み飛ばさないでほしい注意点があります。read-only と strict の「子プロセスのネットワーク遮断」は、公式ドキュメントによれば Linuxでのみ（seccompで）強制され、macOSではno-opです。macOSで --sandbox strict を指定しても、子プロセスの通信は止まりません。ファイルシステムの制限は効きますが、ネットワークについては期待とズレる可能性があるため、脅威モデルに通信遮断を含めるならLinuxで動かす必要があります。

.env や **/*.pem のような機微ファイルを個別に塞ぎたい場合は、~/.grok/sandbox.toml（全体）または .grok/sandbox.toml（プロジェクト単位）でカスタムプロファイルを定義し、deny リストを書きます。これはカーネルで強制され、読み取りと書き込み・リネームの双方に効き、globパターンを解します。

もう一点、堅牢化として興味深いのは「グローバルフックの直接書き込み保護」です。workspace / read-only / strict（およびこれらを継承したカスタムプロファイル）では、Grokの状態ディレクトリは書き込み可能なまま残る一方、ユーザーグローバルなフックのソースとして使われるパス（~/.grok/hooks/、~/.grok/hooks-paths、およびそこに列挙された絶対パス）はカーネルで書き込み拒否されます。読み取りは可能です。シンボリックリンクを張った $GROK_HOME や、hooks-paths の要素にシンボリックリンクが含まれる場合はサンドボックス起動時点で拒否され、リンクの張り替えによる乗っ取りを防ぎます。ただし devbox プロファイルは使い捨てVM向けのためこの保護を適用しません。

Claude Code・Codex CLI・Kimi Code との比較

同じ「ターミナルで動くコーディングエージェント」でも、公開のされ方には無視できない差があります。以下は各プロジェクトの公開情報から検証できる項目だけを並べたものです（2026年7月29日時点）。

※ スター・言語・ライセンス・コントリビューター数・Issue有無・PR作成ポリシー・Release有無は、2026年7月29日にGitHub APIで取得した実測値です。Nanocoderの LICENSE.md はMIT本文ですが、Markdown形式のためGitHubの自動判定は「Other」を返します。なお openai/codex もPR作成ポリシー自体は共同作業者限定ですが、Issueは有効で、コントリビューターは100人以上が記録されています——「Issueもトラッカーも閉じ、コミットがbot1つだけ」という組み合わせはGrok Buildに固有です。

Grok Build を選ぶ判断材料になるのは、Rust実装のフルスクリーンTUIであること、headlessとACPの両方が最初から揃っていること、そして既存の ~/.claude / ~/.cursor 資産をそのまま拾う互換層を持つことです。逆に、バグを見つけたときに公開Issueで報告したい、パッチを送って直したい、といった関わり方を重視するなら、この構造は合いません。どちらが優れているという話ではなく、開発への参加経路が開いているかどうかがプロジェクトごとに異なるという前提で選ぶ必要があります。

ターミナル常駐型エージェントの比較検討をしている場合は、同じ切り口で調べたKimi Code CLIとは｜Moonshot純正のAIコーディングエージェントをターミナルで動かすや、ローカルLLMで完全オフライン動作させる選択肢を扱ったNanocoder徹底解説｜Ollamaで完全オフライン動作するローカルコーディングエージェントを実測も合わせて読むと、選定軸が整理しやすくなります。

実際に使ううえで押さえておく設計

最後に、ドキュメントから読み取れる運用上のポイントをまとめます。

セッション管理：-c で直近セッションの継続、-r でIDまたはタイトルによる再開ができます。タイトル指定は大文字小文字を無視し、手動でリネームした一致が1件だけならそれが選ばれ、重複が残る場合はIDを添えてエラーになります。UUID形式の値は常にID扱いです。ドキュメント自身が「スクリプトではIDを使うのが望ましい」と勧めています。--fork-session を併用すると、元セッションに追記せず新しいIDへ分岐できます。

権限：--allow / --deny はglobパターンを解し、繰り返し指定できます。対話TUIとheadlessの両方で機能します。拒否をデフォルトにしたい場合は .claude/settings.json の defaultMode を使う、と headless の章に記載があります（ここでもClaude Code互換の設定ファイルが参照される点が現れます）。--permission-mode bypassPermissions は常時承認を有効にするもので、--yolo と同様に扱いに注意が必要です。

拡張性：MCPサーバー、スキル、プラグイン、フック、サブエージェント、カスタムモデル、プロジェクトルール、メモリ、プランモード、バックグラウンドタスクといった機能が、それぞれ独立したドキュメント章として crates/codegen/xai-grok-pager/docs/user-guide/ にリポジトリ同梱で提供されています。全24章あり、設定の章（05-configuration.md）だけで約42KBという分量です。ドキュメントがソースと同じツリーに入っているため、SOURCE_REV の同期時点における仕様がそのまま読めます。

確認しておきたい前提：本記事のコマンドやフラグは、すべて公開ツリーの公式ドキュメントとREADMEの記述に基づいています。実際の挙動はバージョンによって変わりうるため、導入後は grok --version と grok inspect で自分の環境の実際値を確認することをおすすめします。とくに互換層は既定で有効なので、チームで使う前に「何が読み込まれるか」を一度棚卸ししておくと安全です。

まとめ

Grok Build は、xai-org が公開するRust製のターミナル常駐AIコーディングエージェントです。フルスクリーンTUI・headless実行・ACP連携という3つの使い方を最初から備え、MCP・スキル・プラグイン・フック・サンドボックスまでドキュメント付きで揃っています。導入は curl -fsSL https://x.ai/cli/install.sh | bash の一行で済み、grok と打てば動き始めます。

同時に、公開のされ方は一般的なOSSプロジェクトとかなり異なります。Apache-2.0で全ソースが読め、フォークもローカルビルドも自由である一方、Issueは無効、外部PRは受け付けず、コミット履歴は非公開モノレポから同期するbotの14本だけです。CONTRIBUTING.md自身が「ソースの透明性とローカルビルドのため」と目的を述べており、コミュニティ開発型のプロジェクトではないことを隠していません。

そして実務で最も影響が大きいのは、既定で ~/.claude/ と ~/.cursor/ のスキル・ルール・MCP定義・フックを走査する互換層でしょう。既存資産をそのまま活かせる利点であると同時に、意図しない読み込みを避けたいなら grok inspect での確認と、[compat.*] セルまたは GROK_*_ENABLED 環境変数での明示的な無効化が必要になります。

参照ソース

・xai-org/grok-build（公式リポジトリ・README / CONTRIBUTING.md / THIRD_PARTY_NOTICES.md） — 本記事のライセンス・貢献方針・移植元・クレート構成の一次ソース
・Publish harness and TUI open-source（初回コミット c68e39f6） — 公開の起点となったコミット
・Grok Build 公式ドキュメント（docs.x.ai/build/overview） — インストール・認証・headless・サンドボックス・互換設定の公式解説
・openai/codex — 移植元のひとつ（Apache-2.0）
・sst/opencode — 移植元のひとつ（MIT）