ログイン済みのChromeをAIエージェントに操作させる「Kimi WebBridge」を触る前に読んでおきたい話

※本記事は、下記の当方ブログ記事の要約です。詳細はブログまでお越しください。
https://shinichi.noguchi.jp.net/blog/2026-08-06-kimi-webbridge.html

E2Eテストを書いていると、遅かれ早かれMFAの壁にぶつかります。ID／パスワードだけならストレージ状態を使い回せますが、認証アプリの承認やワンタイムコードが挟まると途端に厳しくなる。

Kimi WebBridge は、そこを突破するのではなく順番を変えることで回避します。認証は人間がChrome上で済ませ、ログイン済みのタブだけをAIエージェントへ渡す。Chrome拡張とローカルのWebSocketで繋ぐ仕組みです。

公開リポジトリとnpmパッケージを読んだので、触る前に知っておくと事故らない点をまとめます。

まず「3つのKimi WebBridge」を区別する

検索すると同じ名前のものが複数出てきます。ここが最初の関門でした。

名前	実体
Chrome拡張	Chrome ウェブストアで配布中
npm kimi-webbridge	CLIとMCPサーバーを兼ねるラッパー。0.1.3
efrg123/kimi-webbridge	v2.0の設計文書リポジトリ

注意したいのが3つ目。READMEに get_page_state() submit_form() request_user_approval() といったAPI一覧が並ぶので実装に見えますが、冒頭に「Status: Planning Complete」とあります。設計であって、npx で降ってくるものではありません。

動かすのはnpmの kimi-webbridge（Node.js 18以上、依存は ws とMCP SDKのみ）と拡張のほうです。

使い方

インストール不要で npx から叩けます。

npx kimi-webbridge navigate '{"url":"https://example.com"}'
npx kimi-webbridge snapshot
npx kimi-webbridge fill '{"selector":"input[name=q]","value":"test"}'
npx kimi-webbridge screenshot '{"format":"jpeg"}'

MCPサーバーとして起動する場合はこれだけ。

npx kimi-webbridge mcp

Claude Code / Claude Desktop 側の設定はこうなります。

{
  "mcpServers": {
    "webbridge": {
      "command": "npx",
      "args": ["kimi-webbridge", "mcp"]
    }
  }
}

ハマりどころ1：WebSocketの向きがモードで逆になる

ここがいちばん引っかかると思います。ソースを読むと、こうなっていました。

• MCPモード（src/mcp.js）は new WebSocketServer({ port: 10086 }) → Node側が待ち受ける
• CLIモード（src/cli.js）は new WebSocket(WS_URL) → Node側はクライアント

つまりMCPモードでは拡張がNodeへ繋ぎに来ますが、CLIを単体で叩いても、別に待ち受け役がいなければ繋がりません。「ECONNREFUSED が出るけど拡張は入れたのに」というときは、まずここを疑ってください。

環境変数は WS_URL（既定 ws://127.0.0.1:10086/ws）と WS_TIMEOUT（既定 60000ミリ秒）ですが、効くのはCLIモードだけです。MCPモードのポートを変えたいなら src/mcp.js の CONFIG.WS_PORT を書き換える必要があり、npx 運用だと編集先が消えるのでローカルにクローンしたほうが早いです。

拡張側の接続先は、ポップアップのアイコンを5回クリックすると出る開発者モードから変更できます。知らないと探し回ります。

ハマりどころ2：クリックが3種類ある

click（CSSセレクター）、snapshot_click（@e ref）、mouse_click（物理）が別々にあります。アイコンだけのボタンなど、セレクターで掴めない要素があるためです。snapshot 由来の @e ref を基本にし、ref が失敗したら再試行せず snapshot を取り直してください。

ハマりどころ3：成功したように見えて何も起きていない

設計文書に v1 の課題として明記されているのですが、アクションが実際にページを変えたか確認せずに「clicked」を返します。コマンドの終了コードを成功条件にしてはいけません。URL、見出し、成功メッセージ、ブラウザエラーといった事後状態で判定する。ここは呼び出し側の責任です。

セキュリティは自分で足す

設計文書にはっきり書かれています。

No security boundary: any localhost process can connect to port 10086

認証がありません。さらに実装側も WebSocketServer に host を渡していないので、既定では全インターフェースで待ち受けます。共有端末や他の人と同じネットワークにいる状態では、確認してから使ってください。

読み取り専用から始める・対象URLをallowlistで絞る・送信や削除は人の承認を挟む、あたりは自分で組む前提です。evaluate で任意のJavaScriptが実行できる以上、渡した権限＝そのブラウザの全権だと考えたほうが安全側です。

Playwrightの代わりにはならない

ただし、ここで見落としてはいけない決定的な違いがあります。PlaywrightのようなヘッドレスブラウザによるE2Eは、基本的に画面の外、メモリ上のブラウザで実行されます。テストコードはDOMを操作して成功を返しますが、その瞬間に人間の目の前で画面が動いているわけではありません。表示や操作の実態は、後からスクリーンショットやtraceを確認することになります。

Kimi WebBridgeは、目の前にあるブラウザをAIが自動操作し、その画面を人間がリアルタイムに見ながらテストできる。 必要なら操作を止めて介入し、結果をその場で検証できます。これは単なるブラウザ自動化の違いではありません。AIの成果物に人間が介入し検証するhuman in the loopを、確実に実現できるかどうかの違いです。

AIに画面操作を任せるWeb開発の現場では、この差は非常に大きい。画面が見え、途中で判断でき、結果をその場で確かめられることが、安全性と品質を左右します。決定性が必要なCI回帰テストはPlaywrightのままでいい。一方でWebBridgeは、CIが落ちたときに「テストコードの問題か、ログイン済みセッションでしか起きない問題か」を、人間の監督下で実ブラウザを動かして切り分ける場面で効きます。

まずは navigate / snapshot / screenshot の3つだけで疎通させてみてください。詰まったら、原因はたいていWebSocketの向きかポートです。