Skip X API Costs: Automate Data with Grok Build

Claude Code から X を自動で扱うのは、これまで微妙でした。ブラウザを操作させてスクレイプする手はあります。でも X の規約的にグレー。じゃあ公式の X API はというと、コストが高くて自動化の敷居になっていました。スクレイプはグレー、API は高い。X の自動化は、ずっとそこで止まっていました。

そこで Grok Build です。このモデルは「X Search」というツールコールを持っていて、X のデータに直接つながっています。xAI のモデルなので、グレーなスクレイプでも高い API でもなく、モデルがそのまま X を引ける。これなら X の自動化もいけるんじゃないか。そう思って agmsg 1.1.1 で Grok Build に対応しました。Claude Code のチームに入れれば、X まわりの仕事を、いつもの作業場所でそのまま回せます。

実際にやってみる

Claude Code から、Grok Build の相棒にこう頼みます。「ここ2週間くらいで、Claude Code や Codex、Cursor みたいなコーディングエージェントを何個も併用しているけど、エージェント同士が連携できない・共有の受信箱がない、と困っている開発者の投稿を探して。製品の宣伝と公式アナウンスは除いて、実際の開発者の生の声だけ。反応の多い順に3〜4件、アカウントとリンクと一言要約で」。

同じ agmsg のチームに入れた Grok Build が、これを X で実行して、そのまま返してきます。短くて、順位がついていて、ノイズのないリスト。ブラウザもコピペもなし、数手で終わり。作り込んだデモじゃなく、実際に一発で動かした結果です。

で、返ってきた中身が、そのまま「なんで agmsg が要るのか」になっていました。がんばって手動でつないでいる人がいます（@PawelHuryn）。Claude Code と Codex を道具じゃなく対等な相棒として動かすために、AGENTS.md を揃え、skills を同期し、MCP 設定を両方に読ませる。動くけど、全部手作業です。inbox でつないでみたものの「速く回すには、両方に『受信箱を見て』と手で言い続けないといけない」と書く人もいます（@chrisreedbates）。

反応がいちばん大きかったのは、これは面白いのですが、もう答えにたどり着いた人でした。前回も紹介しましたが、@izutorishima さんは、Opus で設計を固めて Codex に指示書を渡し、「終わったら agmsg で待機中の Claude に報告しろ」と書いて、自分が間に入らなくてもエージェント同士が連携するように組んでいます。痛みを探したつもりが、その痛みと、もう埋めている実例が、両方まとめて返ってきた。そういう結果でした。

なぜ Grok Build か

まず、アクセスの壁が消えます。さっきの「スクレイプはグレー、API は高い」が、X Search だと両方なくなる。xAI のモデルが X に直結しているからです。ここが一番大きい。

そしてここが肝心なのですが、agmsg で Grok Build を入れるのは、サーチ API を叩くのとは違います。相手はエージェント。だから、ただデータを取るだけじゃなく、検索して・読んで・条件で絞って・整えて、その先の判断まで一手でやれる。さっきのデモも、「宣伝は除く」「反応順」「一言要約」「日本語で」を一つずつ指示しなくても、エージェントが自分で組み立てて返してきました。ただの取得やサーチとは、できることの幅が違います。

実務的な速さ・クリーンさもあります。ブラウザ自動化がループに入らないので速い。返ってくるのは構造化された答えで、パースしてノイズを除く前の生テキストではありません。

どれだけ新しい投稿を取れるか、を競う話ではありません。狙いは、X を自動で・グレーにならず・いつもの作業場所で扱えることです。

1.1.1 で入ったもの

grok-build エージェントタイプ（#216）：agmsg が xAI の Grok Build CLI から使えるようになりました。Grok Build のエージェントが、ほかのメンバーと同じようにチームに参加して、メッセージをやり取りできます。
spawn --model（#135）：相棒を spawn するときにモデルを選べます。仕事に合ったエージェント（X まわりなら Grok Build）を、その都度立てられます。
信頼性の修正いくつか（watcher の後始末の範囲、セッション終了時のクリーンな終了、monitor 経路の引数クォート）。

テストで使ってみて罠を見つけました

Grok Build をちゃんと受信させるには修正が要って、それは実際に動かして初めて分かりました。最初の実装は、Claude の経路と同じ「受け身のフック」でメッセージを届ける作りでした。テストは通った。でも実際に使うと何も届かない。しかも悪いことに、メッセージが途中で既読扱いになっていて、届かないどころか消えていました。テストはグリーンなのに、配信はゼロ。

直し方は、フックと戦うのをやめて、そのエージェントが元から対応してる方式に切り替えること。毎ターン読むルールファイルです。受信箱を自分で確認して、待っているものを引く。切り替えたら、さっきの受け渡しが最後まで通りました。罠は、誰かに届く前に潰せました。

なぜこの形か

agmsg は連携をオープンに、自分の手の内に置きます。どのエージェントをチームに入れるかは自分で選ぶ。受け渡しは全部見える。外から来るものは、信頼してから読み込まれる。1.1.0 で入れたゲートです。いま、たくさんのモデルを一つの閉じた API の裏で束ねる流れに盛り上がりがあります。agmsg も「一つのモノリスより複数エージェントの連携」という同じ方向に賭けますが、やり方はオープンです。誰をチームに入れるかを自分で選んで、自分のマシンの上で、動いているところを見られる。