メインコンテンツまでスキップ

Grok Build の内側：オープンなエージェントハーネスを読む

上級

2026年7月14〜16日、xAI は自社 CLI の背後にあるコーディングエージェント Grok Build を、Apache 2.0 の公開リポジトリ xai-org/grok-build として公開しました。重みではありません。公開されたのはハーネスです。エージェントループ、ツールの実装、ターミナル UI、拡張システム。数時間のうちに Hacker News のトップページに載りました。

これは稀な資料です。本格的なコーディングエージェントのほとんど — Claude Code、Cursor、Codex — はバイナリかバンドルとして出荷されます。ここでは、およそ 80 万行の本番 Rust コードが、誰でも読めるリポジトリに置かれています。これは製品としてより教科書としての価値のほうが大きい。

このページはその実践的な読み方です。実際に何が入っているのか、その構造がエージェント構築について何を教えるのか、そしてこのリリースについて多くの報道が取り違えている2つの点。

What you'll learn
  • 何が公開され、何が公開されなかったのかを理解する — ハーネスは Yes、重みは No、開発履歴も No
  • クレート構成を、本番のコーディングエージェントに実際に必要なもののチェックリストとして読む
  • ここでの Apache 2.0 がなぜ open-development ではなく source-available を意味するのか、そしてなぜその区別が決定的に重要なのかを学ぶ
  • 公開ツリーに今も残るデータコレクターのコードと、その定数が7月の流出インシデントについて裏づけることを確認する
  • このリポジトリから本当に再利用できるものと、行き止まりであるものを見極める

実際に公開されたもの​

リポジトリは 99% 以上が Rust、ライセンスは Apache 2.0、自らをコーディングエージェントのハーネスおよび TUI — フルスクリーン、マウス操作対応、拡張可能 — と説明しています。ピン留めされた Rust ツールチェーンで macOS と Linux 上でビルドできます。

これがそうではない3つのこと：

  • モデルではない。 Grok 4.5 の重みはここにはなく、オープンでもありません。ハーネスはホストされたエンドポイントと通信します。エージェントがあなたのコードベースをどう捉えるかを一行残らず読めても、xAI の API なしには動かせません。
  • 開発履歴ではない。 リポジトリのコミットは2つだけです。Publish harness and TUI open-source、そして Synced from monorepo。ルートには内部リビジョンのハッシュ1つを含む SOURCE_REV ファイルがあります。これはプライベートなモノレポからのエクスポートを定期的に再同期したものであり、公開の場で開発されたリポジトリでも、設計判断を発掘できるリポジトリでもありません。
  • あなたに開かれてはいない。 CONTRIBUTING.md は、このリポジトリは外部からのプルリクエストや依頼されていないパッチを受け付けないこと、xAI が社内でソフトウェアを開発していること、そしてツリーは「ソースの透明性とローカルビルドのために」公開されていることを明言しています。GitHub の issue はリポジトリレベルで無効化されています。

★ 重要な区別： Apache 2.0 はライセンスであり、実際の権利を与えます — 読む、フォークする、改変する、派生物を出荷する。しかしガバナンスについては何も述べていません。Grok Build はクローズドな開発モデルを持つ、オープンソースライセンス下の source-availableです。フォークはできますが、影響を与えることはできません。見出しの「オープンソース」は「ソースを読める」と読み替えてください。提供されているのは、まさにそれだけです。

クレート構成こそが本当の学び​

マーケティングは無視しましょう。crates/codegen/ 以下のディレクトリ一覧は、このリポジトリで最も有用なものです。なぜならそれは、出荷されるコーディングエージェントに必要なものの正直な棚卸しだからです。抜粋：

クレート何を教えてくれるか
xai-grok-agent, xai-grok-shellエージェントのランタイムとそのエントリポイント — インタラクティブ、stdio、ヘッドレス
xai-grok-tools, xai-grok-tools-apiツールの実装を、ツールのインターフェースから分離 — 本物の境界
xai-grok-workspace, xai-fast-worktreeファイルシステム、バージョン管理、実行、チェックポイント — そして高速な git worktree
xai-codebase-graphgrep ではなく、リポジトリの構造的な理解
xai-grok-memoryメモリはプロンプトの小技ではなくサブシステム
xai-grok-mcpMCP は第一級の統合面
xai-grok-hooks, xai-hooks-plugins-typesフックとプラグインは独自の型レイヤーを持つ
xai-grok-subagent-resolutionどのサブエージェントが何を担当するかの解決は、独立したクレートを要するほど難しい
xai-token-estimation消費する前にトークンを数える
xai-hunk-tracker編集セッションをまたいで差分ハンクを追跡する
xai-grok-pager, xai-ratatui-inlineTUI — スクロールバック、プロンプト、モーダル、インラインレンダリング
xai-acp-libAgent Client Protocol — エディタがエージェントを組み込む
xai-grok-telemetry, xai-mixpanelテレメトリとプロダクト分析を、第一級のクレートとして
ptyctl, xai-tty-utils, xai-grok-crash-handlerターミナルは過酷であり、プロセスはクラッシュする

このリストを、ビルド計画としてもう一度読んでみてください。コーディングエージェントの素朴なメンタルモデルは「モデルを呼びツールを実行するループ」です。実際の分解には、コードベースグラフ、メモリサブシステム、チェックポイント、worktree 管理、ハンク追跡、サブエージェント解決、トークン推定、クラッシュ処理、PTY 制御層が含まれます — プロンプトを一行書く前に、です。

★ 規模の確認。 Simon Willison はツリー内の Rust を 844,530 行と数え、そのうちベンダー依存は約3%にすぎないこと、そして OpenAI の Codex がおよそ 950,933 行であることを指摘しました。2つの独立したチームが、「LLM を包むループ」のために、100万行近くへ収束したのです。あなたのエージェントプロジェクトが膨れ上がっているように感じるなら、これが較正値です。あなたのせいではないし、難しい部分は最初からループではなかったのです。

xai-grok-mermaid というクレートもあります — Unicode の罫線素片で Mermaid 図を描くターミナルレンダラーです。重要ではありません。ただ、仕上げの磨き込みが実際のエージェントの大きな部分を占めることを、心地よく思い出させてくれます。

データコレクターのコードは今もツリーに残っている​

ここからこのリポジトリは教科書であることをやめ、証拠になります。

2026年7月、ある研究者のワイヤーキャプチャは、Grok Build がリポジトリ全体 — git 履歴のすべて、一度も読まれていないファイル、.env の中身 — を、モデルが読んだ内容とは無関係なチャネルを通じて Google Cloud Storage のバケットへアップロードしていることを示しました。AILmanac はこのインシデントと一般的な失敗モードを エージェントがアップロードするもの で扱っています。xAI はこの挙動をサーバー側で無効化し、保持されたデータは削除すると述べました。

公開されたソースには、その仕組みが含まれています。リポジトリから直接検証できます：

  • crates/codegen/xai-grok-shell/src/upload/gcs.rs が存在する。
  • crates/codegen/xai-file-utils/src/upload_config.rs が DEDUP_GCS_PREFIX = "repo_changes_dedup" を定義している。

興味深いのはこの定数です。研究者が傍受したアップロードは gs://grok-code-session-traces/repo_changes_dedup/v2/… という形式のオブジェクトパスに送られていました。ワイヤー上で捕捉されたパスのプレフィックスは、xAI 自身が公開したソースの中で名前付き定数になっているのです。 同じファイルは ARCHIVE_SCHEMA_VERSION（v2）と ARCHIVE_SCHEMA_VERSION_V3 の両方を定義しています — つまりアーカイブ形式は3世代目まで反復されていたということです。これは迷い込んだデバッグ用のパスではなく、保守されていたインフラでした。

gcs.rs のモジュールドキュメントは、どんなプレスリリースよりも率直です。そこではアップロードのヘルパーを 「the data-collector helpers」 と呼んでおり、このファイルが存在する理由はまるごと1つのエンジニアリング上の修正 — 期限切れのトークンが POST /v1/storage で 401 を起こさないよう、リフレッシュ対応の認証情報を通すこと — です。誰かがリポジトリのアップロード経路の信頼性を、本番の業務としてデバッグしていたのです。

Simon Willison は、公開ツリーではアップロード経路が現在は無効化されており、ハードコードされたエラーを返すと報告しています。これは xAI の表明した立場と整合しますが、その具体的な仕組みをコード検索によって独立に確認することはできませんでした — ここでは検証済みではなく報告として扱ってください。

★ ここから得るべきもの。 「xAI が特別にひどい」ではありません — セキュリティのページからのより広い教訓が当てはまります。この種のチャネルは多くのエージェントに何らかの形で存在し、それを知る唯一の方法はソースを読むことです。代わりにメタな論点を持ち帰ってください。これこそがソースの透明性の本当の用途です。 バイナリのデータフローを午後のうちに監査することはできません。公開されたツリーを bucket_url で grep するのは10秒ほどで済みます。このリリースが本当に価値あるものなのは、まさに居心地の悪い部分まで grep 可能にしているからです。

Check yourself

0/4
  1. xai-org/grok-build は Apache 2.0 ライセンスです。これは修正を上流に貢献することについて何を教えますか？
  2. リポジトリにはコミットが2つと、ハッシュ1つを含むルートの SOURCE_REV ファイルがあります。これは何を意味しますか？
  3. Grok Build のハーネスはおおよそどれくらいの規模で、OpenAI の Codex の対応する数値はどれくらいですか？
  4. upload_config.rs の DEDUP_GCS_PREFIX 定数は何を裏づけますか？

本当に再利用できるもの​

フォークする前に、制約について正直になりましょう：

Guided walkthrough1 of 4
  1. クレートの境界は、実ユーザーに出荷している資金力のあるチームの産物です。その分解 — tools を tools-api から分離し、workspace を agent から分離し、サブエージェント解決を独立した関心事として扱う — こそが転用できる資産です。そこから Rust をコピーしても、形をコピーするより得られるものははるかに少ない。

ビルドせずにツリーを探索したい場合：

クローンしてクレート構造を把握する

git clone --depth 1 https://github.com/xai-org/grok-build
cd grok-build

# The inventory of what a production coding agent needs
ls crates/codegen/

# Where does data leave the machine? Start here, not with the README.
grep -rn "bucket_url\|/v1/storage\|upload_bytes" crates/ --include=*.rs | head -30

# Which internal revision was this cut from?
cat SOURCE_REV

既知のものとの位置関係​

Claude Code を使っているなら、Grok Build は内臓をさらけ出した同じカテゴリのツールです — すでに抱えている問題へのセカンドオピニオンとして読みましょう。コーディングエージェント CLI の比較 はこれを競合の中に位置づけ、Claude ユーザーのための Grok は周辺の xAI エコシステムを扱います。

クレート構成が示唆するアーキテクチャのアイデアについては、長時間動作するエージェントハーネス と エージェントのメモリアーキテクチャ を参照してください — xai-grok-memory と xai-grok-subagent-resolution は、まさにそれらの問題に対するあるチームの答えです。

そしてこのページと合わせて エージェントがアップロードするもの を読んでください。あちらは mitmproxy とカナリアリポジトリを使って、この種のチャネルをワイヤー上で捕まえる方法を示します。こちらはそれがソースの中でどう見えるかを示します。2つの手法を合わせたものが監査の全体です。

出典と参考文献​