TITLE

Claude Code から X の情報収集を grok build にやらせてみた — 触れ込みと実際の差

投稿日：2026.06.27

何を試したか

きっかけは OSS「agmsg」(github.com/fujibee/agmsg)のバージョン 1.1.1 へのアップデートです。agmsg は bash と sqlite3 で実装された CLI エージェント間メッセージングの仕組みで、Claude Code・Codex・Gemini・Copilot・Grok Build といった異なる AI エージェント同士をメッセージングでつなぐことを目的としています。1.1.1 では grok-build エージェントタイプへの対応と、spawn 時のモデル選択機能が追加されました。

agmsg が面白い理由は、「Claude Code 側から指示を出し、grok build が X の情報収集を担当する」という分業構成を CLI だけで組めると紹介された点です。

xAI の Grok Build CLI(grok コマンド)は web_search と X Search ツールを持っており、xAI のモデルが X のデータに直結します。スクレイピングでも別途の高価な X API でもなく、モデル側が X データにアクセスする仕組みです。導入は公式インストーラ(x.ai/cli)からで、認証は2系統あります。

grok build の認証2系統。左: SuperGrok/X Premium+ のブラウザ OAuth ログイン経路。右: API キー従量課金経路。ヘッドレス環境では右側の API キー経路を明示的に設定する必要がある

ひとつは SuperGrok または X Premium+ サブスクのブラウザログイン経由、もうひとつは API キーの従量課金(pay-as-you-go)です。料金の目安は SuperGrok 約 $30/月・X Premium+ 約 $40/月で、従量課金は grok-build モデルが入力/出力で約 $1/$2 per 1M トークン、サーバーサイド検索ツールが約 $5/1,000 calls です(いずれも筆者確認の執筆時点の値。xAI の pricing ページで最新値を確認してください)。

動いたこと

grok を API キーでヘッドレス導入し、X 検索を実際に実行できました。「Claude Code 側のスクリプトから grok を呼び出す」形で、X の情報を作業環境のまま取得できます。構成としては単純で、シェルスクリプトから grok コマンドを呼んで結果をパイプで受け取るだけです。

ここは触れ込み通りでした。「API もブラウザも使わず」という表現は正確で、追加の X API 契約なしに X 検索が動きます。

つまずき① 認証の罠

最初にはまったのは、API キーだけでは X 検索が通らないことです。

grok の検索ツールは既定で OAuth ログイン経路に向いているため、API キーのみで起動すると、ベースのモデル呼び出し自体は通るのに、検索だけが 401 で失敗します。エラーを読むと「モデルは応答しているのに検索だけ落ちている」という不思議な状態になりました。

設定ファイルで検索を API キー経路に明示的に向け直すことで解決しましたが、このはまりポイントはドキュメントに目立つ形では書かれていなかったので、エラーログを見ながら自力で辿り着きました。ヘッドレス環境で grok を使う場合は、最初から API キー経路に設定を合わせておくほうが無難です。

つまずき② 出典が信用できない(最重要の教訓)

grok が …/status/206 something という壊れた URL を返してきました。確認しようとしたら X のログインウォールで弾かれました。どちらの問題が先でも、結論は変わりません——grok の引用は裏取り前提で使います。

具体的には2つの問題が重なっています。一つは grok がそもそも架空の URL を生成すること。X の引用を返す際にモデルが情報を補完してしまうようで、古い投稿 ID を最近のものとして参照してくるケースも経験しました。複数回の検索で疑わしい引用が混在していました。もう一つは、仮に正しい URL でも X の投稿ページは未ログイン状態だとアクセスできず、確認しようとしても 402 エラーが返るだけです。grok の引用が正確かどうかを独立して検証する手段がありません。

実際にあったケースを紹介します。grok が「ある大手企業が AI コーディングツールの社内利用を縮小した」という話題を引用 URL と一緒に提示してきました。URL は当てにならなかった(正確には確認できなかった)のですが、テーマ自体は一般的な報道から裏付けが取れました。トレンドのセンサーとしては機能したわけです。

一言で言うと、grok の X 検索結果は「話題の種(トピック発見)」としてのみ使い、事実の裏付けは別途ふつうの Web リサーチで取る。ツイートの引用は記事や報告書に載せない。この運用ルールを設けることで、実用的なトレンドセンサーとして機能します。

つまずき③ コスト

既定の構成で使い始めると、コストが想定より早く積み上がります。

grok は既定状態で、使っていない多数のスキル/ツール定義を毎回コンテキストに載せます。この結果、モデル呼び出しあたり入力トークンが約 30,000 になっていました。さらに既定プロファイルではサブエージェントが有効で、1回のユーザー操作あたり複数のモデル API 呼び出しが内部で発生します。これが積み重なって、10 回程度の試行で約 $0.7 を消費しました。

原因を調べると、ほとんどは不要なスキル定義とサブエージェントの設定が自動でロードされていることでした。検索専用の最小プロファイル——ツールを Web 検索のみに限定し、サブエージェントを停止する——に切り替えると、呼び出しあたりの入力トークンが約 8,000 に下がりました(30,000 → 8,000 でトークン単体は約 3.75 倍削減)。加えてサブエージェント停止によりユーザー操作あたりの API 呼び出し回数も減り、両方の効果が合わさって 1 検索あたり約 6 倍のコスト削減を実測で確認しました。

デフォルトプロファイルと最小プロファイルのコスト比較。入力トークン: 30,000 → 8,000(約3.75倍削減)。API 呼び出し回数削減も加わり1検索あたり約6倍のコスト削減を実測

設定ファイルを数行変えるだけで、出力の品質に影響を与えず達成できた削減です。grok をヘッドレスで使う場合は、最初に最小プロファイルを組んでから試行を始めるほうが無駄がありません。

agmsg は使う/使わないを用途で選んだ

私の用途は「依頼が来たら調査して記事化する」というバッチ的な自動処理でした。agmsg のアーキテクチャを確認すると、複数のエージェントがメッセージキューを介して継続的に協調する設計になっています。

cron で定期実行する一発完結のバッチに agmsg を組み込もうとした場合、各エージェントのプロセスを維持し続ける必要があり、メッセージング往復のオーバーヘッドも加わります。このバッチ処理の用途には過剰だと判断し、スクリプトから grok を直接ヘッドレス呼び出しする方式を採りました。

agmsg が本領を発揮するのは、複数の AI エージェントを常駐させて継続的に協調させる場面です。たとえば「Claude Code がコードを書きながら、grok が X のトレンドを監視して逐次フィードバックを送り続ける」ような対話的な協調なら、agmsg の仕組みが活きます。私はここで agmsg を採用しませんでした。バッチなら直呼びで十分でした。