これにより、例えば次のようなタスクがAIに任せられるようになります。
従来のAIのように「やり方を説明する」だけではなく、AIが実際に操作を実行する点が大きな違いです。
従来のAIブラウザ自動化は、多くが クラウド上の仮想ブラウザ を使っていました。ユーザーはその環境にログインし、AIサービス側がブラウザを操作します。
Kimi WebBridgeはこれとは逆のアプローチを採用しています。
この仕組みでは
の2つが連携します。
AIエージェントからの命令はローカルサービスに送られ、そこから Chrome DevTools Protocol を通じてブラウザを操作します。ページ読み取り、ナビゲーション、スクリーンショット取得などもこの仕組みで行われます。
すべての処理がローカルで行われるため、次の利点があります。
Moonshotのドキュメントでも、ログイン状態やページデータはユーザーのマシンから外に出ないと説明されています。
この設計により、認証が必要なサイトの自動化で発生していた設定の複雑さやセキュリティ上の懸念が大きく減ります。
WebBridgeのもう一つの特徴は、特定のAIアプリに縛られない エージェント非依存(agent‑agnostic)設計 です。
公式ページでは、次のような開発ツールやエージェント環境での利用が挙げられています。
つまりWebBridgeは、単一AIの機能というより AIエージェントがブラウザを操作するための共通インターフェース として設計されています。
実際の役割分担は次のようになります。
ブラウザ操作そのものはWebBridgeが担当しますが、複雑なタスクの計画や推論を担うのが Kimi K2.6 モデルです。
Kimi K2.6はMoonshot AIが公開したエージェント向けモデルで、
といった特徴を持っています。
このモデルは特に次の用途を想定しています。
Moonshotのプラットフォームでも、長期的なコード生成や自律的なエージェント実行能力を強化したモデルとして説明されています。
WebBridgeと組み合わせると、役割は次のようになります。
例えばAIが複数のECサイトを調査し、価格を比較し、結果をまとめるといった一連の流れも、この組み合わせで実行できます。
AIの進化は、単なるモデル性能競争から エージェント基盤(agent infrastructure)競争 に移りつつあります。
AIエージェントが現実の作業を行うためには、実際のソフトウェアやWebサービスに接続する仕組みが必要です。
しかしクラウドブラウザ型の自動化にはいくつかの問題があります。
WebBridgeのように ユーザーのブラウザを直接操作する方式 は、これらの問題を大きく減らします。
その結果、AIエージェントは次のような作業により実用的に使える可能性があります。
Moonshot AIの動きは、AI企業が モデルだけでなくエージェント用インフラ全体を構築し始めている ことを示しています。
現在のAIエージェントの構成は大きく次の3層で考えられます。
この中でWebBridgeは「ブラウザ実行レイヤー」を担い、Kimi K2.6は推論エンジンとして動作します。
AIが質問回答から 実際のタスク実行 へと進むにつれ、ブラウザを含む実行レイヤーの重要性はさらに高まると見られています。