AI活用レビュー

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

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

この記事の結論

Grok APIに「今日のAIニュース集めて」と1〜2週間投げ続けても、数日前のツイートが混ざって返ってきました。

私のプロンプトの書き方ではなく、APIとブラウザ版が別物という構造に原因があります。

browser-useでブラウザ版Grokを直接操作したら動きました。

ただし弱点も並んで出てきたので、速度・安定性・5回制限の話まで書きます。

この記事はGrok APIやブラウザ自動化で最新ニュース収集を組みたい開発者向け（API・ブラウザの違いがざっくり分かれば読めます）。

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

きっかけは単純です。

毎日のAIニュース収集を自動化したくて、Grok APIに投げ始めました。

X上の速報性はGrokが一番強い、という前提で動いたわけです。

「2026年4月の最新AIニュース、いいね1,000超を5件」みたいなプロンプトを叩く。

普通のリクエストですね。

ところが、返ってくるのは数日〜1週間前のツイートが平気で混ざった結果でした。

「24時間以内」と明示しても、「今日の」と書き直しても、構造は変わらず。

いいね数のしきい値を足しても変わらず。

期間指定を細かくしても変わらず。

これ正直きつい。

私の体感では、ここで1〜2週間で30時間くらい溶かしました。

1〜2週間、プロンプトの小細工で直そうとして粘りました。

結果、直りません。

中盤で「これは小手先の話じゃない」と腹を決めて、xAIの公式ドキュメントを上から下まで読みに行きました。

そこで見えてきたのが、この記事の主題です。

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

xAIの公式資料を読み込んで分かったのは、こういう構造でした。

ブラウザ版Grok（grok.com）で当たり前に動いている機能が、APIには載っていない。

料金や速度の話ではなく、機能そのものが渡されていません。

これは私もちょっと驚きました。

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

機能ブラウザ版GrokGrok API（2026年4月時点）
DeepSearch（検索を繰り返して統合）標準搭載Enterprise API限定。一般開発者は非公開（出典: x.ai/news/grok-3）
Think Mode（推論深掘り）主力モデルで利用可reasoning_effortパラメータでの対応は進行中。軽量系のgrok-3-miniはThink前提（出典: docs.x.ai/developers/models）
メモリ機能（会話記憶）2025年4月以降、Web/アプリで利用可API未提供。ブラウザ・アプリUIからのみ動作
システムプロンプト最適化xAI側で細かく調整（公式リポジトリで一部公開）素のモデル。開発者側で全部書く必要あり（出典: github.com/xai-org/grok-prompts）

特に効いたのは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はモデルの土台を渡す窓口です。

ブラウザ版は、その土台の上にxAIのUIチームが積み上げた最適化レイヤーが乗っかった完成形。

DeepSearchのループも、システムプロンプトの調整も、メモリ機能も、全部この上の層に属します。

xAIは公式リポジトリxai-org/grok-promptsで、ブラウザ版Grokのシステムプロンプトを継続公開しています。

具体的にはgrok4_system_turn_prompt_v8.j2（Grok 4本体のチャット用）、grok4p1_thinking_system_turn_prompt_v2.j2（Grok 4.1の思考モード版）、grok_analyze_button.j2（X上の「Grok Explain」ボタン用）、ask_grok_system_prompt.j2（XのGrokボット用）など、機能ごとに別ファイルで分かれていて、本数は10本以上。

中を見るとペルソナ・禁止事項・出力フォーマットの指示が細かく作り込まれていて、ブラウザ版の「賢さ」の一部はモデルそのものよりUIチームのチューニングだ、ということが読み取れます。

私はこれを見て、APIと体感が違う理由に納得しました。

これ、Grokだけの話じゃありません。

ChatGPTのBrowse、ClaudeのArtifactsやProjectsも、同じ構造でAPIには直接出ていない機能群です。

「APIがある」と「APIで同じことができる」は別問題という原則が、業界全体に横たわっている。

私はここに1〜2週間かけてようやく気づきました。

鈍かった。

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

grok-4.1-fastは出力が$0.50/M、コンテキストウィンドウは2Mトークン（出典: docs.x.ai/developers/models）。

テキスト生成・コード生成・長文処理の用途ではAPIの方が明らかに強いです。

私がやりたかった「最新ニュース収集」とミスマッチだっただけ。

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

ドキュメントを読み終わって私が決めたのは、「ブラウザ版Grokをスクリプトから直接叩きにいく」という方針でした。

ここで選んだのがbrowser-useです。

browser-useはPython製のオープンソースツールで、GitHubスター数は88,900超（2026年4月時点, github.com/browser-use/browser-use）。

現行はv0.12.6（2026年4月2日リリース）、累計123リリース。

開発の熱量は今もまだ強いです。

仕組みはざっくりこうです。

「AIが現在のページの状態を受け取る → 次の操作を決める → 実行する → ループする」という自律的なエージェントの動き方で、下回りにはPlaywrightというブラウザ自動化ライブラリを敷いています。

決まったセレクタを書いていくPlaywright単体と違って、「ざっくりした自然言語の指示」で動くのが差です。

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

  1. Step 1: Claude Codeに「今日のAIニュース集めて」と手動で投げる。期待結果は、Claude Codeがbrowser-useを起動する流れに入ること。詰まりどころは、ターミナルでPlaywrightの依存ブラウザがインストールされていないとここで止まる点。事前にuv run playwright install chromiumを1回叩いておく必要があります。
  2. Step 2: browser-useがgrok.com（私のXアカウントでログイン済み）を開く。期待結果は、ログイン状態が引き継がれて検索画面に入れること。詰まりどころは、Cookie/セッションが切れているとログイン画面に飛ばされる点。私は専用のユーザーデータディレクトリを--user-data-dirで指定して安定させました。
  3. Step 3: DeepSearchで検索を回させて、結果をClaude Codeに戻す。期待結果は、DeepSearchの深い検索結果がまとめて返ってくること。詰まりどころは、DeepSearchボタンが画面更新でセレクタ位置が変わると見失う点。自然言語で「DeepSearchのトグルをオンにしてから検索」と書いておくと安定しました。

結果、動きました。

Grok APIで1〜2週間苦しんだのが嘘みたいに、ブラウザ版Grokが本来の深さで検索してくれます。

一次情報にアクセスできた瞬間の安堵感、ちょっと忘れられないです。

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

ここからが大事な章で、browser-useを神ツール扱いするつもりはありません。

実運用で見えた弱点を並べます。

速度：APIと桁が違う

私の感覚で言うと、速度差はざっくり20〜50倍です。

Grok APIは1リクエスト100ms以下で返ってきます。

browser-useは1操作あたり2〜5秒。

ページ遷移・クリック・スクロールを積むと、体感で数十秒から1分くらいかかります。

リアルタイム用途には正直向きません。

私の判断としては、毎朝1回の自動収集みたいな非同期ジョブ向けです。

安定性：体感70〜85%

これが一番悩ましいところで、私の体感成功率は70〜85%でした。

ブラウザ側のUIが変わったり、ポップアップが急に出てきたりで迷子になります。

browser-useのGitHub Issue #2808には、タイムアウト（30秒超）・DOMツリー構築失敗・3回連続失敗でエージェントが止まる、といった報告が積まれています（出典: browser-use Issue #2808）。

私の見方では、本番運用なら必ずリトライ機構を上に被せて使うべきです。

DeepSearch「5回制限」の謎

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

私のケースでは、browser-use経由のDeepSearchが1日5回ほどで打ち切られます。

Xアカウントにログインさせているはずで、私自身は有料プランに入っています。

それなのに5回で止まります。

原因はまだ特定できていません。

ログイン状態が本当に引き継げていないのか、browser-use経由だと別扱いされるのか、何らかの動的制限に引っかかっているのか。

ちなみにxAI側の公式仕様は次の数字です（出典: help.x.com about-grok）。

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

私の体感「5回」は、無料版の下限値に近い数字です。

ログインが引き継げていない説が一番濃いですが、まだ詰められていません。

5回使い切った日はブラウザを直接開いて手動検索に切り替えています。

ここは完全自動化の手前で止まっている状態です。

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

2026年3月24日、browser-useも依存していたlitellm（影響バージョン: 1.82.7/1.82.8）にサプライチェーン攻撃が入りました。

browser-useはv0.12.5でlitellmをコア依存から外す対応済みです。

ただオープンソースを回す以上、この手のリスクは無料ではないという記憶は残しておいた方がいい（出典: browser-use Releases）。

私は依存ライブラリを毎週uv pip list --outdatedで確認するルーティンに変えました。

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

私なら、月100件以上のニュース収集なら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、ClaudeのArtifactsやProjectsでも同じ構造です。

「APIがあるからAPIで全部いける」と思った瞬間、同じ落とし穴に落ちる。

ここを先に知っておくと、私と同じ1〜2週間は節約できます。

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/docs/guides/live-search）。

現行は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回」という数字を出しています（出典: help.x.com about-grok）。

私は有料プラン契約者ですが5回で止まる現象に当たっていて、ログイン引き継ぎの失敗が一番疑わしいです。

原因特定中。

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

A. 速度・安定性ともAPIに近いのはPlaywrightで、browser-useはAI推論を挟む分だけ安定性が下がります（個別サイトのUI変化で動作差が出やすい）。

一方Playwrightは決まったセレクタを書く構造のため、対象サイトのUIが変わるたびにコードのメンテが要ります。

browser-useは自然言語の指示でそこを吸収させる思想。

UI変化のたびにコードを書き直す時間と、AI推論のぶれを許容する時間、どちらを取るかという判断です。

私はメンテに時間を取られたくなかったのでbrowser-useを選びました。

このページに出てきた言葉

Grok
xAIが作っている対話型AI。ブラウザ版（grok.com）とAPI版で機能が違う。
DeepSearch
ブラウザ版Grokに乗っている、検索を自動で何度も繰り返して結果を統合する機能。
API（エーピーアイ）
手元のプログラムから外部サービスを呼び出すための窓口。
Enterprise API
大企業向けに個別契約で渡されるAPI。月数千ドル以上の契約レンジ。
Think Mode
モデルが結論を出す前に内部で「考える時間」を伸ばすモード。
システムプロンプト
ユーザーが投げる依頼文の前に渡される、振る舞いを決めるベース設定文。
トークン
AIが文字をまとめて扱う単位。日本語で1〜2文字くらいに相当。
コンテキストウィンドウ
AIが一度に受け取れる入力の最大量。
browser-use
AIに自然言語でブラウザを操作させるPython製オープンソースツール。
Playwright
Microsoft製のブラウザ自動化ライブラリ。
セレクタ
Webページ内のボタンや入力欄を指し示すための識別子。
litellm
OpenAI/Anthropic/xAIなどを共通の書き方で呼び出せる中間ライブラリ。
サプライチェーン攻撃
手元のソフトではなく、その下で動く他人のライブラリに悪意あるコードを混ぜる攻撃。

関連リンク

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

-AI活用レビュー
-, , , ,

← 戻る