neko（m1k1o/neko・GitHubスター21,452）は、Dockerコンテナの中でブラウザを丸ごと動かし、その画面をWebRTCでストリーミングするセルフホスト型の仮想ブラウザです。視聴する側はプラグインもアプリも不要で、URLを開くだけ。同じ画面を複数人で同時に見て、同時に操作できます。もともとは友人同士の共同視聴（ウォッチパーティー）や、怪しいサイトを隔離環境で開く「安全なブラウジング」、リモートデスクトップのために作られたツールで、それ自体はAIツールではありません。

ではなぜ、AI系メディアである当サイトがnekoを取り上げるのか。理由は、ここ最近nekoが「computer-use / browser-use 系のAIエージェントに、隔離された・かつ人間が観察できるブラウザを与える基盤」として使われ始めているからです。エージェントにブラウザを触らせる話題は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証でも中心的なテーマの一つでした。本記事は、neko本来の姿を正直に押さえたうえで、この「エージェントの隔離ブラウザ」という切り口が本当に成立するのかを、編集部が実機でDocker起動して検証します。

まずは、nekoが実際にどう動くのか——公式デモ映像から。1つのブラウザ画面を、複数人が同時に見て操作している様子です。

neko公式のイントロ映像。1つの仮想ブラウザ画面をWebRTCで配信し、複数の参加者が同じ画面を共有・操作している（出典: neko.m1k1o.net）。
30秒でわかるポイント
  • ・課題：AIエージェントにブラウザを触らせたいが、ホストを汚したくない／途中経過が見えない／詰まっても人が割り込めない。共同視聴や安全なブラウジングでも「ブラウザを他人と共有する」手段が意外と無い。
  • ・解決：nekoはブラウザをDockerコンテナ内で動かし、画面だけをWebRTCで配信する。隔離（映像しか外に出ない）・可観測（操作をライブで見られる）・介入可能（人が操作を奪える）の3点が、共同視聴からエージェントのサンドボックスまで幅広く効く。
  • ・正直な線引き：neko自体にAI・LLM機能は無い。エージェント用途は「相性の良い基盤」であって、nekoが自動でブラウザを操作してくれるわけではない。
この記事のポイント（先に結論）
・nekoは「Dockerで動くWebRTC仮想ブラウザ」。共同視聴・安全ブラウジングが本来用途で、それ自体はAIツールではない
・当サイトが注目する角度は「AIエージェントに隔離された・観察できる・介入できるブラウザを与える器」としての使い道
・編集部が実機でDocker起動し、GStreamer→Pion WebRTCの配信パイプラインとライブ配信を実測した。誇張なしで「使える／使えない」を判定する

neko（m1k1o/neko）とは — 1つのDockerコマンドで動く仮想ブラウザ

nekoの一次情報を実測で押さえておきます（2026年7月19日時点）。GitHubスター21,452、フォーク1,526、ライセンスはApache-2.0、主要言語はサーバ側がGo、フロントエンドがVue。最初のコミットは2020年3月で、5年以上メンテナンスが続く息の長いプロジェクトです。公式の一言説明は「A self hosted virtual browser that runs in docker and uses WebRTC.（Dockerで動きWebRTCを使う、セルフホスト型の仮想ブラウザ）」。

ここで言う「仮想ブラウザ」は、あなたのPCのブラウザとは別物です。実体はサーバ（コンテナ）の中で動いているブラウザで、あなたはその画面を映像として受け取り、マウス・キーボード操作を送り返しているだけ。つまり「ブラウザのNetflixのようなストリーミングをWebRTCで実現したもの」と考えると近いです。ローカルには何もインストールされず、閲覧履歴もCookieもすべてコンテナ側に閉じ込められます。

nekoが面白いのは、対象がブラウザに限らない点です。公式が配布するイメージだけでも、Firefox / Google Chrome / Chromium / Brave / Vivaldi / Opera / Microsoft Edge / Tor Browser / Waterfox / Ungoogled Chromium といった主要ブラウザに加え、XFCE や KDE のフルデスクトップ、VLC、Remmina なども動かせます（追加イメージは m1k1o/neko-apps に集約）。README自身も「X server で表示できて定期的に画像として取得できるものなら何でも配信できる」と説明しており、ブラウザは「たまたま一番人気のユースケース」に過ぎません。

編集部が実機で起動したneko v3のログイン画面。n.ekoの猫ロゴ、表示名とパスワードの入力欄、接続ボタンが表示されている
編集部が Docker で起動した neko の実際のログイン画面（日本語UIに自動対応）。この画面自体はふつうのHTMLで、WebRTC接続は「接続」後に始まる。

主な特徴を整理すると次の通りです。マルチユーザーで同じ画面を複数人が同時共有でき、誰が操作権を持つかを制御できる。音声も配信されるため動画視聴やプレゼンにも使える。低遅延のWebRTC配信で、画面共有ツールより滑らかに動く。そして完全セルフホストなので、データが外部SaaSに出ていかない。この「自分のサーバの中で完結する共有ブラウザ」という素性が、後述するエージェント用途にもそのまま効いてきます。

なぜnekoがAIエージェントの「隔離ブラウザ」になるのか

ここが本記事の主軸です。ただし最初に正直に線を引きます。nekoはAIエージェントではありません。 LLMも、自律的にWebを操作する機能も内蔵していません。neko公式がエージェント文脈で唯一明記しているのは、READMEの「Automated browser（自動ブラウザ）」という一節——「Playwright や Puppeteer をインストールしてタスクを自動化でき、しかもそれを実行中に能動的に介入（intercept）できる」という説明です。つまりnekoが提供するのは器であって、中身の自動操作は Playwright なり browser-use なりのエージェント側が担います。

その前提のうえで、なぜこの器がエージェントに向くのか。鍵は3つの性質です。

・隔離（Isolation）：ブラウザはコンテナ内のChromiumで動き、外に出るのは映像とデータチャネルだけ。エージェントが踏んだ不審なサイトのCookie・トークン・ダウンロードファイルは、ホストに触れずコンテナごと破棄できる
・可観測（Observability）：WebRTC配信のおかげで、エージェントが自動操作している「まさにその瞬間」を人間が同じURLを開いてライブで見られる。ヘッドレス実行では失われがちな「いま何をしているか」が、そのまま画面に出る
・介入可能（Intervention）：詰まったとき（ログイン・CAPTCHA・想定外のダイアログ）に、人間が操作権を取ってマウス・キーボードで割り込める。完全自動と完全手動の間を、シームレスに行き来できる

この「隔離された、観察できる、いつでも止められるブラウザ」という組み合わせは、まさにcomputer-use系エージェントの運用で欲しくなるものです。エージェントに実ブラウザを操作させるアプローチ（browser-use のようなツール）で常に問題になるのが「ホストを汚さないか」「途中で暴走しても人が止められるか」でした。nekoはこの2点——ホスト汚染の防止と、暴走時の人間による停止——に対する、素朴だが強力な回答になります。特別なエージェント連携機能を持たないのに、器としての性質だけでこの要求を満たしてしまう点が面白いところです。

エージェント→nekoコンテナ→人間が監視、の流れ。コンテナから外に出るのは映像だけでCookieやトークンはホストに残らないことを示した図
nekoをエージェントの隔離ブラウザとして使う構図。自動操作はPlaywrightやAIエージェントが担い、nekoは「隔離＋可視化＋介入」の器を提供する。

隔離という観点では、別アプローチとの比較も有益です。TencentのCubeSandbox（60ms起動のMicroVMでAIエージェントを安全実行）は、軽量VMで実行そのものを隔離する設計でした。nekoはVMではなくコンテナで、しかも「隔離」に「人間がライブで見られる」という可観測性を足しているのが違いです。速度と密度ならMicroVM、可視化と手軽さならneko、と役割が分かれます。逆に、検出回避しながらスクレイピングさせたい用途ではcamofox-browser（AIエージェントの検出を回避するREST APIブラウザ）のような専用ブラウザの方が目的に合う場面もあります。nekoは「万能の隔離ブラウザ」であって「特化型の最適解」ではない、という位置づけを持っておくと選定を誤りません。

具体的な組み込みイメージも描いておきます。最小構成は「neko（chromiumイメージ）のコンテナを1つ立て、その中にPlaywrightを同居させる」だけです。エージェント（LLM側のロジック）はPlaywright経由でコンテナ内のChromiumに指示を出し、ページ遷移やクリックを自動化します。運用者は同じ http://localhost:8080 を開いて、その自動操作を別ウィンドウでライブ観戦する。ログインやCAPTCHAでエージェントが止まったら、neko上で操作権を取って人間が手で突破し、そのままエージェントに制御を戻す——この「人間 in the loop」を、コードを書かずにブラウザ操作レベルで実現できるのがnekoの旨味です。実際、コミュニティでもneko内でPlaywrightを走らせてエージェントに使わせる構成は繰り返し議論されており、公式リポジトリのIssuesにも自動化・ヘッドレス連携に関するやり取りが蓄積しています。

このとき効いてくるのがAIエージェント サンドボックスとしての隔離性です。エージェントが誤って認証情報を入力しても、怪しいファイルをダウンロードしても、被害はコンテナ内に閉じます。セッションが終わればコンテナを捨てるだけ。ホスト側には映像の記憶しか残りません。セルフホスト ブラウザである以上、これらのデータが外部サービスに送られないことも、機微情報を扱う社内エージェントでは重要な条件になります。

念のため繰り返すと、これは当サイトのAIフォーカスに引き寄せた切り口であり、neko公式が掲げる第一の用途（共同視聴・安全ブラウジング・リモートデスクトップ）ではありません。エージェント基盤として神格化するのではなく、「たまたまエージェント運用に都合の良い性質を備えた汎用ツール」として捉えるのが正確です。WebRTC 仮想ブラウザという素性が、結果的にエージェントの可観測性という現代的な要求に噛み合った、という順序で理解するのが健全です。

編集部がnekoを実機で立てた — Docker導入と実測ログ

「使える感」は動かして初めてわかります。編集部は Apple Silicon の Docker（27.4.0）で、公式Chromiumイメージを実際に起動しました。手順は文字どおり数コマンドです。

まずイメージを取得して起動します（編集部が実際に走らせた構成そのままです）。

# 公式Chromiumイメージ（約1.48GB）を取得
docker pull ghcr.io/m1k1o/neko/chromium:latest

# 1コマンドで起動。8080=Web UI、52000-52100/udp=WebRTCメディア
docker run -d --name neko \
  -p 8080:8080 \
  -p 52000-52100:52000-52100/udp \
  --shm-size=2gb \
  -e NEKO_DESKTOP_SCREEN=1280x720@30 \
  -e "NEKO_MEMBER_MULTIUSER_USER_PASSWORD=neko" \
  -e "NEKO_MEMBER_MULTIUSER_ADMIN_PASSWORD=admin" \
  -e NEKO_WEBRTC_EPR=52000-52100 \
  -e NEKO_WEBRTC_NAT1TO1=127.0.0.1 \
  ghcr.io/m1k1o/neko/chromium:latest

ポイントは2種類のポートです。8080 はログイン画面とシグナリング（WebSocket）用のHTTP。52000-52100/udp が実際の映像・音声・入力を運ぶWebRTCメディア用。ローカル検証では NEKO_WEBRTC_NAT1TO1=127.0.0.1 を指定しておくのが接続成功の勘所で、ここを外すとブラウザは繋がってもICE（経路探索）が通らず画面が真っ黒、という典型的なハマりに陥ります（後述の「使えるか判定」でも触れます）。--shm-size=2gb はChromiumのクラッシュ防止に効きます。

起動後、docker logs を覗くと、内部で何が動いているかが手に取るように分かりました。要点だけ抜粋します。

・spawned: 'chromium' — コンテナ内でChromiumが起動
・setting initial screen size screen_size=1280x720@30 — 仮想ディスプレイ（Xorg :99）を1280x720@30で用意
・syntax check for video stream pipeline passed pipeline="ximagesrc ... ! vp8enc ... ! appsink" — GStreamer が画面をキャプチャしVP8にエンコードするパイプライン
・webrtc starting epr=52000-52100 ... iceservers=[stun:stun.l.google.com:19302] — Pion（Go製WebRTC）が起動
・http listening on :8080 → neko ready — 準備完了

この一連が、nekoの正体そのものです。「Xorgの仮想画面をGStreamerで動画にエンコードし、Pion WebRTCでブラウザへ配信する」——たったこれだけの単純さで、フルブラウザのリモート操作を実現しています。図にすると4層です。

nekoの配信パイプラインを4層で示した図。上からWebRTC(Pion)配信、GStreamer符号化(ximagesrc→VP8)、Xorg:99+Chromium描画、Dockerコンテナ基盤
編集部が実機ログから確認したnekoの配信パイプライン。クライアント側に必要なのはブラウザだけで、プラグインもアプリのインストールも不要。

ブラウザから http://localhost:8080 を開くと、先ほどのログイン画面が出ます。管理者パスワードで「接続」すると、docker logs 側では ICE connection state changed: connected → set webrtc connected=true が流れ、コンテナ内のChromiumデスクトップがそのままブラウザにストリーミングされました。これが編集部の環境で実際に配信された画面です。

nekoがコンテナ内のChromiumデスクトップをWebRTCでストリーミングしている実際の画面。SponsorBlock拡張のページが表示され、下部に操作バーと参加メンバーのアバターが並ぶ
編集部の環境で実際にストリーミングされたneko（chromiumイメージ）。コンテナ内のChromium（デフォルトでSponsorBlock等の拡張入り）がライブ配信され、画面下の操作バーからマウス・キーボード・音量を制御できる。

体感は「ローカルのChromeとは思えないが、リモートデスクトップよりは軽い」という位置。ここに Playwright を同居させれば、エージェントが自動でページを開き、その様子を人間が同じ画面でライブ監視する、という冒頭の構図が現実になります。導入の手軽さ（pull して1コマンド）と、中身の透明さ（ログで全部見える）は、実測しても評価できるポイントでした。

なお本番運用では、docker run を毎回叩く代わりに公式の docker-compose.yaml を使うのが定番です。

# 公式のcompose定義を取得して起動（本番向け）
wget https://raw.githubusercontent.com/m1k1o/neko/master/docker-compose.yaml
docker compose up -d

LAN内の別マシンから繋ぐ場合は NEKO_WEBRTC_NAT1TO1 をそのホストのローカルIPに、インターネット公開時はグローバルIPとTURNサーバの用意が必要です。この「WebRTCのNAT越え」がneko運用で最も学習コストの高い部分なので、まずは同一マシンの 127.0.0.1 で動作を掴んでから広げるのが安全です。

画面が真っ黒なときの確認ポイント

nekoで最も多いつまずきは「ログインはできるのに、接続後の画面が真っ黒（映像が来ない）」です。原因はほぼWebRTCのメディア経路にあります。編集部が実機で確認した勘所を挙げます。

・UDPポートが開いているか：-p 52000-52100:52000-52100/udp（＝NEKO_WEBRTC_EPR と一致）が正しくマッピングされているか。TCPだけ開けても映像は来ない
・NAT1TO1のIPが正しいか：同一マシンなら 127.0.0.1、LANならホストのローカルIP、公開ならグローバルIP。ここが実際の到達先とズレるとICEが通らない
・ブラウザのログでICE状態を見る：docker logs 側で ICE connection state changed: connected が出ていれば経路はOK。checking のまま進まない場合はポート/IPの問題
・TURNが要るケース：対称型NATやモバイル回線越しでは、STUNだけでは繋がらずTURNサーバが必要になる

編集部の環境では、NAT1TO1=127.0.0.1 とUDPレンジを揃えた時点で一発で connected になり、上のスクリーンショットの通り映像が届きました。逆に言えば、この2点さえ押さえれば大半の「真っ黒」は解消します。Docker ブラウザをローカルで検証する分にはハマりどころは限定的で、難所は公開時のTURN運用に集約される、というのが実測を通じた率直な感想です。

nekoでできること・できないこと（対応ブラウザ・制限）

期待値を正しく持つために、できること／できないことを分けて整理します。まずできること。複数人での同一ブラウザ共有（ウォッチパーティー・共同ブラウジング）、音声つきのプレゼン配信、使い捨ての隔離ブラウザ（怪しいリンクをホストから隔離して開く）、社内の踏み台ブラウザ、遠隔サポートやデモ、録画・配信、そしてAIエージェントの観察可能なサンドボックス。ブラウザだけでなくフルデスクトップ（XFCE/KDE）も配信できるので、「特定のLinux GUIアプリを皆で共有」といった応用も効きます。

一方でできない・不得意なことも明確です。nekoは自動でブラウザを操作しません（それはエージェント側の仕事）。大量の並列ヘッドレス自動化を最小コストで回す用途には重い（1セッション＝1コンテナで実画面つき、CPU・メモリを食う）。大規模SaaSとしての多人数配信・課金・監査のような機能は持たない（それはKasmのような専用基盤の領分）。そしてインターネット公開時のNAT越え・TURN設定は自前で面倒を見る必要があります。

用途に迷ったら、次の判断フローが目安になります。

graph TD A["ブラウザを
どう使いたい?"] --> B{"人間が画面を
見る/操作する?"} B -->|"いいえ・完全自動でOK"| C["ヘッドレス自動化
Playwright / browserless"] B -->|"はい・観察や介入がしたい"| D{"隔離環境で
動かしたい?"} D -->|"はい"| E["neko
隔離+可視化+介入"] D -->|"いいえ・自分のPCで十分"| F["通常のブラウザ
拡張やDevTools"] E --> G{"エージェントに
操作させる?"} G -->|"はい"| H["neko内でPlaywright
+ browser-use等"] G -->|"いいえ"| I["共同視聴/安全ブラウジング
/踏み台として使う"]

対応ブラウザの広さもnekoの実用上の強みです。Chromium系（Chrome / Brave / Vivaldi / Edge / Ungoogled）だけでなく、Firefox系（Firefox / Waterfox / Tor Browser）も選べるため、「特定ブラウザでしか再現しない挙動」を隔離環境で共有・検証する、といった使い方もできます。エージェント用途なら実質Chromiumイメージ一択ですが、選択肢が広いこと自体が、共同デバッグやサポートの現場では効いてきます。

具体的なワークフローに落とすと、たとえば「怪しいリンクの調査」はnekoが最も分かりやすく効く場面です。フィッシングが疑われるURLを自分のブラウザで直接開くのは怖い——そんなとき、使い捨てのnekoコンテナを立ててその中で開けば、たとえ悪意あるスクリプトが動いても被害はコンテナ内に閉じ、終わったら docker rm で丸ごと消せます。複数人で同じ画面を見ながら「これは危ない」と判断できるので、セキュリティチームの共同トリアージにも向きます。同様に、録画・配信（セッションをそのまま録る）、遠隔サポート（相手に同じ画面を見せて操作を代行する）、踏み台ブラウザ（社内ネットワークへの入口を1つのコンテナに集約する）といった用途は、いずれも「ブラウザを他人やエージェントと安全に共有する」という同じ本質から派生しています。

リソース面の現実も押さえておきましょう。nekoは1セッションごとに実画面つきのブラウザ（＋X server＋GStreamer＋WebRTC）を動かすため、ヘッドレス実行に比べればCPU・メモリを着実に消費します。編集部の実測でもイメージは約1.48GB、--shm-size=2gb を推奨される程度にはメモリを使います。「1台のサーバで何百セッションも並列に」という規模には向かず、そこはKasmのような専用基盤や、ヘッドレスを大量に回すbrowserlessの領分です。nekoは「少数のセッションを、可視化しながら丁寧に扱う」使い方でこそ光ります。

neko vs 既存の仮想ブラウザ・エージェント基盤【比較表】

nekoの立ち位置は、単体で見るより競合と並べると分かりやすくなります。「ブラウザをリモートで／隔離して動かす」系のツールを、目的別に比較します。各ツールのライセンス・提供形態は編集部が公開情報で確認しました（2026年7月時点。Selenium Grid＝Apache-2.0、Steelの公開ブラウザ＝Apache-2.0、browserless＝SSPL-1.0または商用ライセンスのデュアル、Kasm＝Community Edition無料のフリーミアム、Browserbase＝クラウド商用）。一方「ストリーミング方式」「AIエージェント適性」の欄は、各ツールの設計に基づく編集部の整理であり、優劣の断定ではありません。

ツール 主目的 人間の同時視聴・操作 ストリーミング方式 セルフホスト ライセンス/提供形態 AIエージェント適性
neko (m1k1o) 共有・隔離ブラウザ/デスクトップ ◎ 複数人ライブ共有・介入 WebRTC（低遅延・音声つき） ◎ 完全 Apache-2.0（OSS） ○ 観察可能な隔離環境として好適
browserless ヘッドレスChrome as a Service △ 基本は非対話 なし（API/WebSocket） ○ 可 SSPL/商用 ○ 大量並列自動化に強い
Selenium Grid 並列ブラウザテスト △ VNC等で覗ける程度 主にVNC（任意） ◎ Apache-2.0（OSS） △ テスト向け、対話性は弱い
Kasm Workspaces ストリーミング型仮想デスクトップ基盤 ◎ 多人数・管理機能豊富 独自（Webネイティブ） ○ 可（Community/商用） フリーミアム/商用 ○ 大規模隔離運用向け
Browserbase / Steel AIエージェント向けクラウドブラウザ ○ セッション閲覧 独自（マネージド） × クラウド前提 商用（一部OSS） ◎ エージェント特化・API充実

読み解きのコツは「何を最優先にするか」です。とにかく軽く大量に自動化を回したいなら browserless や Selenium Grid。エージェント特化のマネージド体験が欲しく、運用を任せたいなら Browserbase / Steel。大規模に隔離デスクトップを配るなら Kasm。そのなかでnekoが唯一に近いのは、「OSS・完全セルフホスト・1コマンドの手軽さ・WebRTCでの可視化と介入」を全部そこそこの水準で満たす点です。尖った最強ではないが、自分のサーバで完結する「隔離＋可視化ブラウザ」を最短で手に入れたいときの第一候補になります。

エージェント運用の観点では、Vercelが公開したagent-browser（AIエージェント向けブラウザ自動化CLI）のような「操作する側」のツールと、nekoのような「動かす場所（器）」を組み合わせて考えるのが実践的です。前者がブラウザに指示を出し、後者がそれを隔離・可視化する、という役割分担です。

「使えるか」を正直に判定する — ライセンス・活性度・バス係数

最後に、採用判断のための健全性を実測ベースで正直に評価します（すべて2026年7月19日時点）。

ライセンスは明快です。Apache-2.0で、商用利用・改変・再配布・特許条項まで含めて扱いやすい部類。反AIベンダー条項のような追加制限もなく、社内利用でもプロダクト組み込みでも判断に迷いません。この点は安心材料です。

活性度は「息が長く、いまも動いている」。2020年3月開始で5年以上、最新のタグ付きリリースは v3.1.0（2026-04-02）。スター21,452・フォーク1,526は、この種のインフラ寄りOSSとしては十分な支持です。一方でopen issueは181件あり、その多くはWebRTCのNAT越え・UDPポート・特定環境での接続失敗といった「運用の難所」に集中します。裏を返せば、コア機能の欠陥というより設定の難しさが課題の中心で、ドキュメントと NAT1TO1/EPR の理解でかなり回避できる、とも読めます。

バス係数（属人性）は正直に言えば中程度です。contributorは約57名と裾野はありますが、コミットの多くは作者 m1k1o 氏（約1,753）に集中します。ただしdcgのような「実質1人」ではなく、nurdism 氏（約188）ら複数の実質貢献者が継続的に関わっており、極端な単一障害点ではありません。個人主導OSSであることは織り込みつつ、Apache-2.0でフォーク可能なため「上流が止まっても手元のコンテナは動き続ける」という安心感はあります。

本番投入を検討するなら、最低限このあたりを確認してから広げると安全です。

・接続経路：公開範囲（ローカル/LAN/インターネット）に応じて NAT1TO1 とUDPレンジ、必要ならTURNサーバを用意したか
・認証：MULTIUSER のパスワードをデフォルトのまま公開していないか。踏み台用途では認証を必ず固める
・リソース上限：同時セッション数の見積もりと、コンテナごとのCPU/メモリ制限を設定したか
・破棄運用：使い捨て前提なら、セッション終了時にコンテナをきちんと破棄する仕組み（--rm やオーケストレータ）を用意したか。残置コンテナはリソースも攻撃面も無駄に増やす
・上流追従：Apache-2.0でフォーク可能とはいえ、セキュリティ更新のためにイメージのタグ運用（latest 固定を避ける）を決めたか

これらは特別なものではなく、セルフホストのWebサービスを1つ増やすときの定石とほぼ同じです。nekoが個人主導OSSであることを踏まえても、運用の勘所が「WebサービスのDocker運用＋WebRTCのNAT設定」に収まるため、インフラ担当がいるチームなら導入のハードルは高くありません。

総合すると、nekoは「枯れて実績があり、ライセンスも明快な個人主導OSS。手軽さと可視化が武器で、難所はWebRTCの設定に集約される」という評価です。共同視聴や安全なブラウジングにはそのまま、AIエージェントの隔離ブラウザとしては「器」として、いずれもまず 127.0.0.1 で動かして感触を掴んでから用途を広げるのが、失敗しない使い方です。エージェント運用の全体像はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証と併せて読むと、nekoが担うレイヤーがより明確になります。

「neko 仮想ブラウザ」という言葉で情報を探していた方にとって、本記事が実測に基づく判断材料になれば幸いです。派手なAI機能を持つツールではありませんが、エージェントにも人間にも同じブラウザ画面を安全に共有できるという一点で、nekoは静かに効く道具です。まずは手元の 127.0.0.1 で1コンテナ立てて、その手触りから確かめてみてください。

参照ソース

・m1k1o/neko（公式リポジトリ） — スター・フォーク・ライセンス・contributorの実測元
・n.eko 公式ドキュメント — アーキテクチャ・クイックスタート・設定
・neko README.md — 対応ブラウザ・ユースケース・「Automated browser」の記述
・n.eko リリース一覧 — v3.1.0 等のバージョン情報
・m1k1o/neko-apps — 追加アプリ（デスクトップ環境・各種ソフト）のイメージ集
・Pion WebRTC — nekoが採用するGo製WebRTC実装