Grok Buildのリポジトリ送信問題から考える、本当の「local-first」

確認できたこと

2026年7月、Redditのr/LocalLLaMAに、Grok Build CLI v0.2.93の通信を調査したという報告が投稿されました。 報告者は、モデルが実際に読んだファイルだけでなく、Gitリポジトリ全体を履歴付きのbundleとして送信する通信を観測したとしています。 調査方法、再現用リポジトリ、ハッシュ値、確認コマンドもGitHubで公開されています。

これはコミュニティ研究者による報告であり、現時点でSpaceXAIによる詳細なインシデント報告ではありません。 影響した利用者数、対象バージョンの全範囲、保存期間は公開情報だけでは確定できません。 一方、報告後の再テストでは、同じクライアントでもサーバー側の設定が変わり、送信が観測されなくなったという報告があります。 この点も「問題が存在しなかった」という意味ではなく、挙動の変更がクライアント更新なしで行われ得ることを示しています。

7月15日、SpaceXAIはGrok BuildのソースコードをApache 2.0で公開しました。 公式発表では、エージェントループ、ツール、TUI、拡張機構を確認でき、独自のローカル推論先へ接続してlocal-firstで実行できると説明しています。 ただし、この発表自体はRedditで指摘された送信挙動の公式な事後検証ではありません。

Redditで目立った利用者報告

議論で繰り返し出ていた懸念は、「タスクに必要なファイルをモデルへ送ること」と 「読んでいないファイルや履歴を含むリポジトリ全体を送ること」は別だ、という点です。 学習利用を止める設定と、処理のためのデータ送信を止める設定が同じとは限らないことも注目されました。

反応は事業者への批判だけではありません。 AIコーディングエージェントには最初から広いファイル権限を渡さず、秘密情報をリポジトリに置かず、 コンテナや専用ユーザー、送信先制限を使うべきだったという運用側への指摘も複数ありました。

オープンソース化については前向きな反応がある一方、「公開されたから自動的に安全になるわけではない」という慎重な意見も見られます。 ソースが読めること、実際にビルドしたバイナリがそのソースと一致すること、サーバー側の挙動を確認できることは、それぞれ別の問題です。

NSFW・ローカルLLM運用への示唆

NSFW創作では、APIキーだけが秘密情報ではありません。 未公開のキャラクター設定、プロット、会話ログ、LoRA用データ、個人的な嗜好を含むプロンプトも、外部へ出したくないデータです。

今回の議論から得られる最も重要な教訓は、ローカルモデルを選んだだけでは処理全体がローカルにならないことです。 モデル本体が手元にあっても、UI、エージェント、拡張機能、ログ収集、クラッシュ報告のどこかが外部通信すれば、創作データは端末の外へ出ます。

実運用では、少なくとも次を分けて確認した方が安全です。

1. モデル推論はどこで実行されるか
2. ハーネスやUIがどのファイルを読めるか
3. 読み込んだ内容、ログ、履歴がどこへ送られるか
4. 設定変更が送信停止なのか、保存・学習停止だけなのか
5. 実行ファイルを再現可能なソースからビルドできるか

機密性の高い創作では、専用の作業コピーを作り、不要な履歴や秘密情報を含めず、 可能なら外向き通信を制限した環境で実行する方が堅実です。 「local-first」は製品名や宣伝文句ではなく、モデル、ハーネス、保存先、ネットワークを含む構成全体で判断する必要があります。