AI Search Hub を採用する前に読む: ブラウザ駆動で多平台 AI 検索を束ねる Skill の輪郭

AI Search Hub が埋めようとしている穴は何か

検索を Agent に組み込むとき、多くのチームは 2 つの道のどちらかを選ぶ。1 つは API を叩く方法で、再現性は高いが、平台ごとに料金体系とレート制限が異なり、X や抖音のような SNS の生データにはそもそも手が届きにくい。もう 1 つは自前のスクレイパーで、公众号や微博の本文を取れる代わりに、DOM 変更、ログイン、CAPTCHA、IP 制限への対応を恒久的に負担することになる。AI Search Hub はこの 2 つの間に位置する。平台がすでに持っている検索エンジンとページ理解を、ブラウザ経由で借りるという発想である。README は「一堆脆弱爬虫和网页解析规则」を保守し続けたくない開発者を想定読者として挙げている。対象は、複数の平台の検索結果を 1 つのパイプラインに流し込みたいが、各平台の自動化コードを自分で書き続ける気はない個人開発者や小規模チームだ。

ブラウザを借りるという設計と、その帰結

README のバッジは mode を browser-driven と明示している。つまり AI Search Hub は各平台の HTTP API を叩くのではなく、ブラウザセッションを通じて平台の UI を操作し、その検索結果を回収する。この設計からいくつかの性質が導かれる。第一に、認証は API キーではなくブラウザのログイン状態に依存する。第二に、結果の形式は平台の画面に依存するため、プラットフォーム側が UI を変えれば Skill 側の抽出ロジックが壊れうる。第三に、平台の利用規約とレート制限の範囲内で動かす必要がある。README は「尽量沿用平台已有入口」「减少重复对抗」と述べており、CAPTCHA や風控を突破する類のツールではないことを示唆している。質問を投げる経路と URL を渡す経路の 2 つがあり、後者では平台のページ理解と要約をそのまま借りる。データフローとしては、ユーザーの入力が各平台の検索 UI に分配され、返ってきた内容が Agent やワークフローに戻る、という単方向の集約である。

対応平台と、それぞれに期待されている役割

README が「当前已接入」として挙げるのは Gemini、Grok、豆包、元宝、LongCat、通义千问、MiniMax、Kimi の 8 つである。README の表は平台ごとに得意方向と典型覆盖を並べている。Gemini は Google 検索と公開网页、Grok は X / Twitter のリアルタイム動向、豆包は抖音を含む中国語コンテンツ、元宝は微信公众号と中国語网页の補完、LongCat は中国語知識と行業報告、通义千问は中国語网页の拡張、MiniMax と Kimi は汎用中国語アシスタントとして位置づけられている。重要なのは、これらが「附属补充」ではなく「核心搜索入口」だと README が明言している点だ。同じ質問を複数平台に投げれば、英語圏の Google 由来の結果と、中国語圏の SNS 由来の結果が 1 つの出力に混ざる。ただし、各平台の状態バッジはすべて Good と表示されているだけで、その判定基準は README からは読み取れない。

導入手順で確認できること、できないこと

この記事の執筆時点で参照できた README には、インストールコマンド、設定ファイルのキー名、環境変数の一覧が含まれていない。したがって「pip install して config.yaml に API キーを書く」といった具体的な手順をここで示すことはできない。README から確実に言えるのは、これが Claude Code、OpenAI Codex CLI、Cursor、Kiro、OpenClaw、Google Antigravity、OpenCode の各環境に対応する Skill として配布されているという点である。Skill 形式の配布物なので、導入は各ホストの Skill ディレクトリに配置する操作になる可能性が高いが、これは推測であり、README に明記された事実ではない。実際に試す前に、リポジトリの docs ディレクトリと README.en.md を確認し、設定キーと依存パッケージの実名を把握しておくべきだ。README の画像は docs/images/ 配下に grok-result.png、doubao-result.png、minimax.png として置かれていることが分かる。

このツールが向かない場面

最も明確な限界は、ブラウザセッションへの依存である。ヘッドレス環境や CI で定期実行したい場合、各平台のログイン状態をどう維持するかが問題になる。README はログインや検証碼の処理を「自分でやらなくてよい」とは書いておらず、「反复处理风控与验证码」という従来の負担に対して「尽量沿用平台已有入口」と対置しているだけだ。つまり風控が完全に消えるわけではなく、平台側の入口を使うことで対抗の頻度を下げるという主張である。次に、出力の再現性が保証されない。同じ質問でも平台の検索結果は時間と地域で変わるし、UI の変更で抽出が失敗する可能性がある。規制産業や監査が必要な用途、あるいは「同じ入力に対して同じ構造化出力」を要求するバッチ処理には不向きだ。また、API 経由の従量課金でコストを予測したいチームにとっては、ブラウザ駆動という性質自体が管理対象を増やす。

代替となるアプローチとの違い

比較対象として分かりやすいのは、Perplexity API や Bing Search API のような検索 API を直接叩く構成である。違いはデータの出所にある。検索 API は自社のインデックスとクローラを持ち、返すのは自前の検索結果と要約だ。一方 AI Search Hub は、Gemini や Grok が既に持っている検索機能と、豆包や元宝が持つ中国語圏のデータ到達性をそのまま借りる。特に X や抖音、微信公众号のような、独立系の検索 API ではカバーしにくい入口を、その平台自身の検索 UI 経由で利用できる点が構成的な差になる。もう 1 つの代替は自前スクレイパーだが、これは README が明確に対置している通り、保守コストを自分で負うか平台に寄せるかの選択である。AI Search Hub を選ぶということは、平台の UI 変更リスクを受け入れる代わりに、DOM 解析ルールを書かなくて済むという取引をすることに等しい。

ライセンスと保守コストの読み方

README のバッジは MIT License と表示している。ただし、リポジトリのライセンスファイル自体は今回の材料に含まれておらず、GitHub のメタデータでも License は unknown とされている。MIT であれば改変と再配布は可能だが、これは法的助言ではなく、確認すべき事項の指摘である。実際に業務利用するなら LICENSE ファイルの本文を直接読む必要がある。保守コストについては、リリースが取得できておらず、最終 push が 2026-04-27 であること以外に更新頻度の手がかりがない。ブラウザ駆動型のツールは平台側の UI 変更に追随し続ける必要があるため、メンテナンスが止まれば壊れる速度は API ラッパーより速い。採用判断では、この点をリスクとして明示的に扱うべきだ。

編集部の結論

採用を検討すべきなのは、複数の AI 平台の検索結果を 1 つの Agent やワークフローに集約したいが、各平台ごとにブラウザ自動化とログイン処理を自前で書き続けたくないチームである。逆に、API キーによる従量課金で再現性と監査可能性を確保したい場合、あるいはブラウザセッションの維持を許容できない本番環境には向かない。導入前に確認すべきは、README に記載のないライセンス条項(バッジは MIT と表示しているが、リポジトリのライセンスファイルは未確認)、各平台のログインセッションがどの程度の頻度で切れるか、そして返却される結果が構造化データなのかテキストなのかという出力形式の 3 点である。

公式情報源

1. Issues
2. minsight-ai-info/AI-Search-Hub on GitHub
3. README