AI活用レビュー

Grok APIで最新AIニュースが取れず1〜2週間溶かした話｜browser-useに乗り換えて見えた構造差

Grok APIで最新AIニュースが取れず1〜2週間溶かした話｜browser-useに乗り換えて見えた構造差

この記事の結論（3行）

Grok APIで「今日のAIニュース集めて」を1〜2週間やり倒しても、
数日前のツイートが混ざって帰ってくる。

悪いのは私のプロンプトじゃなく、APIとブラウザ版が「別物」という構造の方。

browser-useでブラウザ版Grokを殴りにいったら動いた。
ただし弱点も同じ重さで、
速度・安定性・5回制限の謎まで並べます。

Grok APIで「今日のAIニュース」を取ろうとしたら、何が起きたか

きっかけは単純で、
毎日のAIニュース収集をGrok APIで自動化しようとしたところからです。

X上の速報性はGrokが一番強いはず、
という前提でAPIに投げ始めました。
「2026年4月の最新AIニュース、
いいね1,000超を5件」みたいなプロンプトです。
まあ普通のリクエストですね。

ところが、
返ってくるのは数日〜1週間前のツイートが平気で混ざった結果でした。
「24時間以内」と明示しても、
「今日の」と書いても、
構造は変わらず。
いいね数フィルタを足しても変わらず。
期間指定を細かくしても変わらず。
これ、
正直きつい。

1〜2週間、
プロンプトの小細工で直せないかと粘りました。
結論、
直りません。
中盤で「これ小手先の問題じゃない」と腹を決めて、
xAI公式ドキュメントに潜りました。

そこで見つけたのが、この記事の主題です。

なぜAPIでは「最新情報」が弱いのか｜ブラウザ版との機能差

xAIの公式資料を読み込んで見えてきたのは、こういう構造でした。

ブラウザ版Grok（grok.com）で当たり前に動いている機能が、
APIには未到達。
しかも料金や速度の話じゃなく、
機能そのものが載っていない。
これは正直驚きました。

4機能で並べるとこうなります。

機能ブラウザ版GrokGrok API（2026年4月時点）
DeepSearch
（検索を繰り返して統合）		標準搭載Enterprise API限定。一般API開発者は非公開
（出典: x.ai/news/grok-3）
Think Mode
（推論深掘り）		主力モデルで利用可`reasoning_effort`パラメータでの対応は進むが、2026年4月時点で主力モデル全対応の公式リストは未確認。軽量系grok-3-miniはThink前提
（出典: Oracle Generative AI docs）
メモリ機能
（会話記憶）		2025年4月16日追加で利用可API未提供。「app/web UIからのみ利用可」と明記
（出典: TechCrunch）
システムプロンプト最適化xAI UIチームが細かく調整
（2025年8月に流出事件で詳細判明）		素のモデル。開発者側で全部書く必要あり
（出典: TechCrunch 2025-08-18）

特に刺さったのはDeepSearchの扱いで、
xAI公式ブログ「Grok 3 Beta — The Age of Reasoning Agents」にはこう書かれています。

DeepSearch will be released to Enterprise partners via the API.

（出典: xAI公式ブログ, x.ai/news/grok-3）

つまり、
私のような一般のAPI開発者には初めから渡されていなかったわけです。
「AIニュース収集」みたいに検索を何度も繰り返して統合するタスクは、
DeepSearchがないと質が根本から変わります。
私が1〜2週間溶かしていた原因は、
ここです。

APIとブラウザ版は、なぜ構造的にズレるのか

ドキュメントを読み終えてから、私の中で整理できました。

APIはモデルの基盤を提供する窓口です。
一方ブラウザ版は、
その基盤の上にUIチームが積み上げた最適化レイヤーがのっています。
DeepSearchのエージェントループも、
システムプロンプトの調整も、
メモリ機能も、
全部この上層に属します。

2025年8月にgrok.comのシステムプロンプトが誤公開された事件（TechCrunch）は、
偶然にもこの構造を裏付けました。
漏れたのは「クレイジーな陰謀論者」「無分別なコメディアン」などペルソナの詳細な設定で、
xAI側が相当作り込んでいたことが分かる内容でした。
ブラウザ版の"賢さ"の一部は、
モデルの賢さというよりUIチームのチューニングだったということです。

これ、
Grokだけの話じゃありません。
ChatGPTのBrowse with Bing、
ClaudeのArtifactsやProjectsも、
同じ構造でAPIに直接出ていない機能群です。
つまり「APIがある」と「APIで同じことができる」は別問題という原則が、
この業界全体に横たわっている。
私はこれに1〜2週間かけてようやく気づきました。
鈍かった。

ただ、誤解しないでほしいのは、Grok APIが悪いという話ではない点です。

grok-4.1-fastは出力で$0.50/M、
2Mトークンのコンテキストウィンドウを持っています。
GitHub Issue（openclaw #6872）では開発者の@ivelinが「It is practically free ($0.2/1M output tokens + input caching) with a massive 2M context」と評価していて、
コスト面は確かに強い（出典: github.com/openclaw/openclaw/issues/6872）。
テキスト生成・コード生成・長文処理の用途ではAPIの方が明確に良いです。
私がやりたかった「最新ニュース収集」とミスマッチだっただけ。

browser-useに乗り換えたらどう動いたか

ドキュメントを読み終わって腹を決めたのは、
「ブラウザ版Grokを私のスクリプトから殴りにいく」という方針でした。
ここで選んだのがbrowser-useです。

browser-useはPython製のOSSで、
GitHubスター数は88,900超（2026年4月時点, github.com/browser-use/browser-use）。
awesomeagents.aiでは「GitHubで最も多くスターが付いたブラウザ自動化エージェント」と紹介されています。
現行の最新版はv0.12.6（2026年4月2日）、
合計123リリース。
開発の熱量はまだ強い印象です。

仕組みはざっくりこう。
「LLMが現在のページ状態を受け取る→次のアクションを決定する→実行する→ループバックする」の自律エージェントループで、
下回りにPlaywrightを敷いています。
決定論的にセレクタを書いていくPlaywright単体と違って、
「ざっくりした自然言語指示」で動くのが差です（出典: nxcode.io）。

私の運用構成はこうです。

  • Claude Code に「今日のニュース集めて」と手動で投げる
  • Claude Codeがbrowser-useを起動する
  • browser-useがgrok.com（私のXアカウントでログイン済み）を開く
  • DeepSearchで検索を回させる
  • 結果をClaude Codeに戻してもらう

動きました。
Grok APIで1〜2週間苦しんだのが嘘みたいに、
ブラウザ版Grokが本来の深さで検索してくれる。
一次情報にアクセスできた瞬間の安堵感、
ちょっと忘れられないです。

browser-useの弱点｜これも同じ重さで書く

ここからが大事な章で、
browser-useを神ツール扱いするつもりはありません。
実運用で見えた弱点を並べます。

速度：APIと桁が違う

Grok APIは1リクエスト100ms以下で返ってきます。
browser-useは1アクションあたり2〜5秒。
ページ遷移・クリック・スクロールを積むと、
体感で数十秒〜1分かかるタスクが普通です。
リアルタイム用途には正直向きません。

安定性：体感70〜85%

これが一番悩ましいところで、
私の体感成功率は70〜85%です。
ブラウザ側のUI変化やポップアップで迷子になる。
nxcode.ioの比較でも、
browser-use（Claude Opus 4.6）のWebVoyagerベンチマーク成功率は約78%で、
Playwright手書きの約98%には届いていません。
GitHub Issue #2808にもタイムアウト（30秒超）・DOMツリー構築失敗・3回連続失敗でエージェント停止といった報告が積まれています（出典: browser-use Issues #2808）。

DeepSearch「5回制限」の謎

ここは私の環境での観測で、公式仕様とは切り分けたい話です。

私のケースでは、
browser-use経由のDeepSearchが1日5回ほどで打ち切られます。
Xアカウントにログインさせているはずで、
私自身は有料プランに入っています。
それなのに5回で止まる。
原因はまだ特定できていません。
ログイン状態が本当に引き継げていないのか、
browser-use経由だと別扱いされるのか、
あるいは何らかの動的制限に引っかかっているのか。

ちなみにxAI側の公式仕様は次の数字です。

  • 無料版: DeepSearch 1日2〜10回（出典: grokaimodel.com）
  • SuperGrok（$30/月）: Think/DeepSearch 各2時間あたり30回
  • X Premium+: 含まれるが上限の記載が曖昧

私の体感「5回」は、
無料版の下限値に近い数字です。
ログインが引き継げていない可能性が一番高いと睨んでいますが、
まだ詰められていません。
5回使い切った日はブラウザを直接開いて手動検索に切り替えています。
ここ、
完全自動化の手前で止まっている状態です。

セキュリティ面：2026年3月のlitellm事件

2026年3月24日、
browser-useも依存していたlitellm（compromised: 1.82.7/1.82.8）にサプライチェーン攻撃が入りました。
browser-useはv0.12.5でlitellmをコア依存から外す対応済みですが、
OSSを回す以上、
この手のリスクは無料ではないという記憶は残しておいた方がいい（出典: browser-use Releases）。

結局、Grok APIとbrowser-useはどう使い分けるか

1〜2週間の失敗と乗り換えを経て、私の中での使い分けはこうなりました。

やりたいこと向いてる方理由
テキスト生成・要約・コード生成・長文処理Grok API（grok-4.1-fast等）100ms以下の速さ、2Mコンテキスト、$0.50/M出力のコスト感
最新ニュース・速報収集（DeepSearch必須系）browser-use＋grok.comAPI側にDeepSearch未到達。ブラウザ版の上層機能を殴りにいく
安定・高頻度・リアルタイム処理Grok API安定性99%以上、速度が桁違い
APIに機能が無い迂回ルートbrowser-use（力技として）安定性70〜85%、速度2〜5秒/アクションを許容できるなら

大原則はこう整理しました。
「自動化したいならまずAPIを試す。
APIにない機能がブラウザ版にだけあるなら、
browser-useのような力技も選択肢に入れる」。
順番が逆になると、
私みたいに1〜2週間溶かします。

あとこれはGrokに限らず、
ChatGPTのBrowse with Bing、
ClaudeのArtifactsやProjectsでも同じ構造です。
「APIがあるからAPIで全部いける」と思った瞬間、
同じ落とし穴にハマる。
ここを先に知っておくと、
溶かす時間はだいぶ節約できます。

FAQ｜Grok APIとbrowser-useでよく聞かれること

Q. Grok APIは「最新情報」に弱いんですか？

A. 弱いというより、
DeepSearchのような検索を繰り返すエージェント機能がAPIに載っていないのが主因です。
単発の`web_search`や`x_search`はAgent Tools API経由で使えますが、
ブラウザ版のDeepSearchは「Enterprise partners via the API」扱いで一般開発者には非公開（出典: x.ai/news/grok-3）。
「今日のニュース5件」のように検索の深さが質を決めるタスクでは、
ここの差が致命的に効きます。

Q. Grok APIのLive Search APIで直接Xを検索できるのでは？

A. 旧Live Search APIは2026年1月12日に廃止（HTTP 410 Gone）されています（出典: docs.x.ai）。
現行はAgent Tools APIの`web_search`/`x_search`で、
Responses API経由での提供です。
単発検索は使えますが、
DeepSearchのエージェントループとは別物という整理になります。

Q. browser-useはGrok公式対応ですか？

A. browser-useの対応LLMプロバイダはREADME上でOpenAI・Anthropic・Google・ローカルOllamaの4系統で、
Grok/xAIの明示的な公式記述は確認できていません（出典: github.com/browser-use/browser-use）。
私の運用はbrowser-useで「grok.comをブラウザ操作する」形で、
LLMプロバイダとしてGrokを指定しているわけではありません。

Q. DeepSearchが1日5回で止まるのは仕様ですか？

A. 私の環境での観測値で、
公式仕様ではありません。
xAI公式は無料版「1日2〜10回」、
SuperGrok（$30/月）「2時間あたり30回」という数字を示しています（出典: grokaimodel.com）。
私は有料プラン契約者ですが5回で止まる現象に当たっていて、
ログイン引き継ぎの失敗が一番疑わしい線だと見ています。
原因特定中です。

Q. 自動化するならPlaywright自前実装の方が速くて安定では？

A. 速度・安定性だけならその通りで、
Playwrightの単純クリックは100ms以下、
WebVoyager成功率は約98%に届きます（出典: nxcode.io）。
ただしセレクタのメンテ負担が30日あたり15〜25%とされるのに対し、
browser-useは5%以下のプロンプト調整で追従する構造。
メンテ工数とコード量を「時間」に換算してどちらを取るかという判断です。
私はメンテに時間を取られたくなかったのでbrowser-useを選びました。

関連リンク

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。

-AI活用レビュー
-, ,

← 戻る