Kimi WebBridge

概要

Kimi WebBridge は、ブラウザを単なる閲覧面ではなく、エージェントが実際に操作できる作業面に変えます。検索や静的取得で止まらず、Chrome DevTools Protocol 経由で Chrome や Edge をローカルエージェントが動かし、ログイン状態やページデータは手元の端末に残します。

今注目されている理由

2026 年 5 月 15 日に Product Hunt でローンチされ、今のエージェント基盤の弱い部分にかなりきれいに刺さっています。Web を読むだけのアシスタントは多い一方で、認証付きブラウザ操作までやりつつ、そのセッション全体をリモートのブラウザ事業者へ預けない構成はまだ少ないためです。

主な機能

• ブラウザ拡張とローカルサービスの組み合わせで、実サイト上のクリック、入力、スクリーンショット、抽出を行える。
• Kimi Work や他のローカルエージェント構成と組み合わせつつ、実ブラウザのセッションは端末内に残せる。
• クロスサイト検索、Google Sheets、繰り返し作業の skill 化など、用途が分かりやすいサンプルを備える。

実際の活用例

• 検索結果だけでは足りず、実ページをまたいで操作が必要な調査作業。
• スプレッドシート更新、フォーム入力、比較収集などの反復ブラウザ作業の自動化。
• ローカルのコーディングエージェントや調査エージェントに、ログイン済みブラウザ操作の手段を与えること。

コミュニティの反応

評価されているのは、ブラウザ自動化を別のロボティクス製品ではなく、普段のエージェント運用の延長として扱える点です。一方で懸念はやはり信頼性です。ブラウザエージェントはデモでは強く見えますが、実サイトの変更、対 bot 対策、拡張機能とデスクトップ連携の複雑さは現場で効いてきます。

制限とリスク

WebBridge はノーセットアップではありません。拡張機能、ローカルブリッジ、対応するエージェント面が必要です。さらに安定性は対象サイトの構造に大きく依存します。MFA が重いページや動的 UI、厳しい自動化対策のあるサイトでは詰まりやすいです。

代替候補

代替候補には Playwright ベースのエージェントフロー、ホスト型ブラウザ operator、TinyFish 系の受管理 Web レイヤー、OpenClaw のブラウザ skills などがあります。

よくある質問

• まず誰が試すべきですか？ すでにローカルエージェントを使っていて、そのエージェントに本物のブラウザ操作をさせたい人です。
• 最初に何を確認すべきですか？ 対象ワークフローがブラウザ自動化に向いているか、そしてローカル導入コストが受け入れ可能かです。