navigera について
navigeraは、エージェントとユーザー向けのネイティブなブラウザー自動化コマンドラインツールです。要素参照付きの簡潔なアクセシビリティツリーでページを読み、コマンド間でブラウザーセッションを維持します。MCPサーバーも備えています。
主な機能
- 01要素参照付きアクセシビリティツリー
- 02マウスとキーボードによる操作
- 03名前付きブラウザーセッションの維持
- 04タブ、iframe、ダイアログへの対応
- 05Cookieとストレージ状態の保存・読み込み
- 06コマンドラインとMCPのインターフェース
活用シーン
- 01フォーム入力とページ遷移の自動化
- 02アクセシビリティ出力でページ要素を確認
- 03セッション間でブラウザーのログイン状態を再利用
- 04MCPクライアントからブラウザーを操作
MCP 対応
`navigera mcp`コマンドでMCPサーバーを起動し、CLIと同じアクセシビリティツリー、参照、待機機能を使ったブラウザー操作を提供します。判定エンドポイントを設定すると、`browser_find`と`browser_check`も利用できます。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
23掲載時のツール一覧 · 1 日前に更新
| パラメーター | 型 | 必須 | 説明 |
|---|---|---|---|
| url | string | はい | |
| wait | enum | いいえ | デフォルトの読み込みload | domcontentloaded | commit |
| snapshot | boolean | いいえ | 操作後にページのスナップショットも返します |
詳細
navigera
navigera は、シェルから各ステップで1つのコマンドを実行する、AI エージェント向けの超高速なブラウザー自動化ツールです。
Chrome DevTools Protocol を直接使用する、単一のネイティブバイナリ(Rust 製、Node 不要)です。
- ページを
[ref=N]ハンドル付きのコンパクトなアクセシビリティツリーとして読み取ります。 - 実際のマウスイベントとキーボードイベントで操作します。
- 名前付きセッションの背後で起動したブラウザーは、シェルの呼び出しをまたいで起動したままになります。
- 新しいタブ、iframe、シャドウ DOM、
alert/confirmダイアログは自動的に処理されます。
より良い地球のために、より高速なソフトウェアを。エネルギーと計算資源を減らし、人生に使える時間を増やしましょう。
インストール
curl -fsSL https://raw.githubusercontent.com/andrey-usa/navigera/master/install.sh | sh
Windows(PowerShell):
irm https://raw.githubusercontent.com/andrey-usa/navigera/master/install.ps1 | iex
またはパッケージマネージャーを使用できます。どの方法でも同じビルド済みバイナリがインストールされます。
| 配布元 | コマンド |
|---|---|
| npm | npm install -g navigera(または npx navigera …) |
| pip / uv | pip install navigera · uv tool install navigera |
| Cargo | cargo install --locked navigera |
| Homebrew | brew install andrey-usa/tap/navigera |
| Scoop | scoop bucket add andrey-usa https://github.com/andrey-usa/scoop-bucket の後に scoop install navigera |
次に、エージェントに使用ガイドを渡します。
navigera install-skill # -> ./.agents/skills (Gemini CLI, Codex, Cline, Kilo, …)
# --claude -> ./.claude/skills, --continue -> ./.continue/skills
Linux、macOS、Windows に対応しています。Windows では、セッションソケットはループバック TCP ポートで、temp ディレクトリ内のセッションファイルにあるランダムなトークンを提示したクライアントのみが接続できます。CDP は DevTools WebSocket 経由で動作し、Chrome は終了時に強制終了されるジョブオブジェクト内で実行されるため、navigera が終了すると Chrome も終了します。
navigera は Chrome を自動的に見つけます。$CHROME_BIN、システムの Chrome、Chromium、Edge、または navigera 自身がインストールしたブラウザーが対象です。コールドスタートを最速にするには、navigera install-browser を実行すると、Google の Chrome for Testing から chrome-headless-shell が navigera 専用のキャッシュにダウンロードされます。これはブラウザー UI 層のない、同じ Chrome です。ベンチマークでは、コールドスタートが 0.32 秒から 0.11 秒に、スクリプトによるセッションが 0.66 秒から 0.32 秒に短縮されました。インストール後は、ヘッドレスセッションではこちらが使われ、画面表示ありのセッションではシステムの Chrome が使われます(Chrome がインストールされていないマシンでは、navigera install-browser chrome を実行するとフル版の Chrome もインストールできます)。明示的に選択するには $CHROME_BIN を設定します。
使用方法(エージェントと人)
navigera -s work start # warm headless browser behind a local socket
navigera -s work goto example.com
navigera -s work --raw ax # page as an indented tree, [ref=N] on actionable nodes
navigera -s work click 12 # act on a ref
navigera -s work fill 31 "hello" && navigera -s work press Enter
navigera -s work wait --text "Saved"
navigera -s work quit
page "Checkout — Acme" http://shop.test/checkout
- main:
- heading "Checkout" [level=1]
- textbox "Full name" [ref=21]
- combobox "Country" [ref=22] value="Select…" options: "Canada", "Mexico", …
- radio "Express (1–2 days)" [checked, ref=25]
- Iframe "Card payment":
- document "Card details":
- textbox "Card number" [ref=41]
- button "Place order" [ref=30]
コマンドは goto、ax、click、fill、type、press、select、
hover、drag、scroll、upload、wait、eval、back/forward/reload、
screenshot、pdf、tab-* コマンド、dialog、quit です。1 つの値を取得するには get
と is、ページのログと取得内容を確認するには console と network、
サインインには cookies、storage、state save|load(cookies と localStorage を 1 つの
JSON ファイルに保存)、ビューポート、デバイス、メディア、位置情報
などの設定には set、リクエストを失敗させたり応答したりするには route を使います。
- 対象の指定: 要素は ref、
--selector <css>、--text "<visible text>"、--role/--name、--label、--placeholder、または--testidで指定できます。 - 出力: 各コマンドは JSON の 1 行を出力します。
--rawを指定すると結果だけを出力します。 - ヘルプ:
navigera help <command>。 - エージェントガイド: バージョンに対応したガイドは
skills/navigera/SKILL.mdにあります。navigera skillでも表示できます。 - リファレンス: docs/navigera.md に完全なリファレンスがあり、 llms.txt は LLM 向けのインデックスです。
エージェントにブラウザーを使わせる方法。 最も直接的な方法から最も汎用的な方法まで、3 つあります。
| 方法 | エージェントが利用できるもの | 必要なもの |
|---|---|---|
start --attach | 実行中の Chrome 自体を専用ウィンドウで利用できます。ログイン情報、設定、拡張機能をそのまま使えます | Chrome 144 以降。一度 chrome://inspect/#remote-debugging でリモートデバッグを有効にし、Allow をクリックする必要があります |
start --profile agent --from chrome | Chrome プロファイルのサインイン情報(cookies、サイトストレージ、保存済みのログイン情報)のコピーを引き継いだ専用ブラウザーを利用できます。作業を続けながら --headless で実行できます | 任意の Chrome。同じマシンとユーザーが必要です。Windows ではコピー中に cookies がロックされるため、Chrome を終了してください |
state save / state load | セッションの cookies とサイトストレージをファイルとして保存し、別のマシンや CI ジョブで利用できます | 不要です。cookies とサイトストレージを含む JSON ファイルが 1 つ必要です |
逆に、show はヘッドレスセッションを同じタブとサインイン情報のままユーザーの画面に表示し、本人しか実行できない手順(ログイン、2FA プロンプト、CAPTCHA)を完了できるようにします。hide で再び非表示にできます。MCP クライアントでは、同じ機能を browser_handoff として利用できます。
navigera profiles を実行すると、引き継ぎ可能なプロファイルの一覧が表示されます。各インストール済みブラウザーのプロファイル(名前、サインイン済みのメールアドレス)、現時点で --attach が接続できるかどうか、および navigera 独自の --profile ブラウザーが表示されます。--from を指定しない --profile work は、自分でサインインする永続ブラウザーです。どちらの場合も navigera は専用ウィンドウで動作します。quit は接続を切断するだけで、quit --close-browser はプロファイルが解放されるまで待機します。
ナチュラルモード。 --natural を指定すると、ヘッドレスブラウザーを通常のブラウザーのように見せられます。ユーザーエージェント(ページ、ワーカー、リクエストヘッダー)に HeadlessChrome を含めず、実際の画面サイズを使用します。どのモードでも navigator.webdriver は false であり、navigera は --enable-automation を渡しません。CAPTCHA を解く機能ではなく、フィンガープリントを偽装することもありません。通常の Chrome をユーザーの代わりに実行します。
詳細は docs/navigera.md をご覧ください。
プログラムでは、代わりにパイプ経由で 1 つのブラウザーを使い続けることもできます。navigera serve は標準入力の各行から JSON コマンドを 1 つずつ読み込みます。例:
{"id":1,"op":"goto","url":"https://example.com"}。セッションソケットも
同じプロトコルを使用します。
IDE エージェント(MCP)
navigera mcp は、Cline、Roo Code、Kilo
Code、Continue、VS Code、Claude Desktop、Cursor 向けの Model Context Protocol サーバーです。CLI と同じツリー、ref、待機機能を備え、他のブラウザー MCP サーバーよりもツール一覧が小さくなっています
(約 14 KB。数値は以下のベンチマークをご覧ください)。{"command": "navigera", "args": ["mcp"]} として追加するか、何もインストールせずに
{"command": "npx", "args": ["-y", "navigera", "mcp"]} として追加できます。クライアントごとの設定例は
docs/navigera.md にあります。
シェルコマンドを実行するエージェント(Kilo、Cline CLI、Gemini CLI、Codex)は、CLI と
スキルを直接利用できます。navigera install-skill を実行すると、エージェントが参照する .agents/skills にスキルが書き込まれます。
高速モデルによる判定(任意)
エージェントがページツリーの確認と LLM への問い合わせに費やす、どの要素か、うまくいったかという 2 つの小さな判定は、System One モデルに任せることができます。
TYPESAFE_API_KEY が設定されている場合は TypeSafe の Jev、または NAVIGERA_DECIDER_URL で指定する、同じ API を利用できる任意のエンドポイントを使えます。
navigera -s work click --find "accept the cookies" # acts on the element the model picks
navigera -s work check "Is an error message shown?" # {"yes":0.02,"answer":false}
find は参照情報、その確率、次点の候補を返します。確率が 0.5 未満の場合、--find は操作を拒否し、実行する代わりに候補を一覧表示します。判定器が設定されている場合、start は "decider" と報告し、MCP クライアントにはそのときだけ browser_find と browser_check が提供されます。それ以外の場合、マシンの外にデータが送られることはありません。入力された値は (filled) として送信されます。
測定結果(2026-10-14)。 正解が分かっている 39 件の判定で、Jev は要素を 25/25 件選び、はい/いいえの質問に 14/14 件回答しました(中央値 151 ms、39 件すべてで $0.0086)。同じツリーを読み込んだ Gemini 3.5 Flash-Lite は 23/25 件、14/14 件で、中央値は 724 ms でした。また一度、ページ内に仕込まれたテキストが指すボタンを選びました。エージェント評価では、2 つの大規模な参照ページ(ツリーが 56~95 KB)で --find を優先するよう指示された Gemini CLI は、ツリーを読み込んだ実行の約半分の Gemini トークンを使用しました(中央値 250K に対して 114~119K。サンプル数は少数です)。指示がない場合はツリーを読み込み、判定器を一度も使いませんでした。詳細と注意事項については、docs/multi-model.md を参照してください。
再測定結果(2026-10-21、実行 39530836547)。 78 件の判定(要素 50 件、はい/いいえの質問 28 件、公開ページを含む)で、Jev は中央値 80 ms で 50/50 件、28 件中 27 件に正解し、全件で $0.017 でした。同じツリーを読み込んだ DeepSeek-V4.1-Flash も、中央値 2.0 s で同じく 50/50 件、28 件中 27 件に正解しました。どちらもページ内に仕込まれたテキストには従いませんでした。start と長いツリーで判定器の使い方をエージェントに伝えた結果、Gemini CLI は指示なしの 15 回中 3 回、プロンプトで指示した場合は 15 回中 14 回、判定器を使用しました(実行 39561380436。各条件で 5 タスクを 3 回実行)。実行あたりのトークン数の中央値は、判定器なしで 199K、判定器ありで 172K、使用するよう指示した場合で 190K でした。このサンプル数では、実行ごとのばらつきの範囲内です。
対応ブラウザー
CI では、次の環境でエンドツーエンドテストスイートを実行します。
- 現行の Chrome Stable とその直前の 3 つのマイルストーン (約 4 か月分のリリース。Extended Stable を含みます)。いずれも Chrome for Testing を使用します。
- chrome-headless-shell
- Chrome Beta(ブロックしない早期警告用)
- Linux および Windows 上での、ランナー自体の Chrome
テストスイートは毎週実行され、プッシュのたびにも実行されるため、新しい Chrome のリリースによる問題をエージェントが遭遇する前に検出できます。最初の実行では、このマトリックスによって、ランナーの Chrome だけでは見逃していた実際のバグを 2 件検出しました。Chrome 151 では自動化フラグの 1 つ(--disable-features=OptimizationHints。chrome-bisect.yml で原因を特定)によりセグメンテーション違反が発生し、Chrome 153 では Enter キーで送信したフォームがリダイレクトの完了前に返っていました。どちらも修正済みです。
各実行では CDP プロトコルの正確性もチェックします。navigera は送信するすべてのコマンドを記録し(NAVIGERA_CDP_TRACE)、tools/cdp_check.py は、そのブラウザーが提供する /json/protocol に照らして、すべてのメソッド、パラメーター、列挙値を検証します。非推奨または未知の使用方法があると、ビルドは失敗します。Edge と Brave はベンチマークで対象にしています。
Lightpanda 1.0(--engine lightpanda)では、CI で同じエンドツーエンドテストスイートを 1.0.1 と nightly で実行します。これは異なるエンジン(タブ 1 つ、レイアウトなし)のため、CDP で不足する部分を navigera が補います。具体的には、ax におけるシャドウルートとパスワードフィールド、confirm()/prompt() の応答、クリックによって開始されるナビゲーションです。残る違いについては、docs/navigera.md に記載しています。
ベンチマーク
各ドライバーで同じヘッドレスブラウザーを操作し、同一のスクリプト化されたセッション(起動 → 一覧へ移動 → タイトル/件数/抽出の評価 →
フィルターに入力してクリック → 表示件数の評価 → スクリーンショット → 新しいタブ → 詳細へ移動 →
タイトル/行数の評価 → 閉じる)を実行しました。フィクスチャは決定的でローカルにあります(500 件のカード一覧、
1000 行の詳細)。CI では .github/workflows/bench.yml を使って実行します。
| 比較対象 | セッション所要時間(3 回中の最速) | ウォーム評価の平均(200 回) | コールドスタート(5 回中の最速) | ドライバー CPU(自身) | ドライバーのピーク RSS(自身) | ブラウザーのメモリ(PSS) |
|---|---|---|---|---|---|---|
nv-shell(このリポジトリ、chrome-headless-shell 上) | 0.34s | 0.39 ms | 0.09s | <10 ms | 7 MB | 234 MB |
nv-brave(このリポジトリ、Brave 上) | 0.65s | 0.50 ms | 0.34s | <10 ms | 7 MB | 666 MB |
nv-ws(このリポジトリ、Chrome 上、WebSocket) | 0.67s | 0.61 ms | 0.29s | 10 ms | 7 MB | 374 MB |
nv-serve(このリポジトリ、Chrome 上) | 0.67s | 0.62 ms | 0.31s | <10 ms | 7 MB | 341 MB |
gorod(go-rod 0.116.2、Go) | 0.73s | 0.52 ms | 0.30s | 40 ms | 20 MB | 370 MB |
nv-edge(このリポジトリ、Edge 上) | 0.74s | 0.45 ms | 0.39s | <10 ms | 7 MB | 774 MB |
chromiumoxide 0.7(Rust) | 0.83s | 0.87 ms | 0.39s | 20 ms | 9 MB | 424 MB |
chromedp 0.19.1(Go) | 1.02s | 0.69 ms | 0.48s | 30 ms | 8 MB | 475 MB |
chromey 2.x(Rust、メンテナンスされている chromiumoxide のフォーク) | 1.03s | 0.99 ms | 0.35s | 50 ms | 22 MB | 465 MB |
puppeteer-core(Node) | 1.05s | 0.85 ms | 0.64s | 0.38 s | 80 MB | 408 MB |
playwright-core(Node) | 1.26s | 1.43 ms | 0.78s | 0.68 s | 150 MB | 423 MB |
nv-lightpanda(このリポジトリ、Lightpanda 上、1 タブ) | 0.18s | 0.33 ms | 0.11s | <10 ms | 7 MB | 14 MB |
2026-10-26 に GitHub ホストの ubuntu-latest で測定(AMD EPYC 7763 64-Core Processor — 4 vCPU · Chrome 155.0.8059.39)。
すべてのドライバーで、抽出されたデータと件数がバイト単位で一致しました(正確性の確認条件)。所要時間は N 回中の最速値です。
ベンチマーク一覧は毎週、最新リリースの比較対象を使って再実行します(bench.yml)。
GitHub のランナーは実行ごとに異なるため、同じ実行内の行同士を比較してください。
ドライバーの CPU/RSS の測定方法。 各ドライバー自身の utime+stime を、ゾンビプロセスの /proc/<pid>/stat から回収前に読み取ります(WNOWAIT を指定した waitid を使用)。また、ドライバー自身の VmHWM も測定します。カーネルは CPU を 10 ms 単位で計上するため、約 50 ms 未満の値は同等とみなせます。wait4 は使用しません。rusage が RUSAGE_BOTH であり、ドライバーが回収したすべての子プロセスの値も加算されるためです。navigera、chromedp、puppeteer、playwright は Chrome に対して wait() を呼び出すため、wait4 では Chrome の CPU と RSS も加算されていました。一方、go-rod(leakless ヘルパーが Chrome を回収)と chromiumoxide では、Chrome の値が加算されることはありませんでした。この表の以前のバージョンでは、まさにこの誤った値を報告していました(「0.82s vs 0.03s」)。ブラウザーのメモリは、ブラウザープロセスツリー全体(すべてのレンダラー/GPU/ユーティリティプロセス)の PSS を 250 ms ごとに合算してサンプリングした値です(共有ページは 1 回だけ計上)。
表の見方。 セッション所要時間の順:nv-shell 0.34s、nv-brave 0.65s、nv-ws 0.67s、nv-serve 0.67s、gorod 0.73s、nv-edge 0.74s、chromiumoxide 0.83s、chromedp 1.02s、chromey 1.03s、puppeteer 1.05s、playwright 1.26s。navigera の最速構成(nv-shell)は 11 個中 1 位です。通常の Chrome では、nv-serve(0.67s)が最速の他のドライバーである gorod(0.73s)を上回っています。すべてのネイティブドライバー(navigera、 go-rod、chromiumoxide、chromedp)が使用する自身の CPU は数十ミリ秒以下ですが、Node のドライバーは数百ミリ秒を使用し、自身の RSS も 80~150 MB に達します。
実環境(公開インターネット、3回中のベスト)
example.com への移動 → title/h1:12件中12件合格;nv-lightpanda 0.19s、nv-shell 0.22s、gorod 0.41s、nv-serve 0.48s、chromey 0.48s、chromiumoxide 0.49s、nv-ws 0.49s、nv-brave 0.52s、nv-edge 0.56s、chromedp 0.61s、puppeteer 0.74s、playwright 0.86s。
GitHub の閲覧(awesome-list のスクロール+トレンドのクリック移動):12件中12件合格;gorod 3.57s、nv-shell 3.85s、chromiumoxide 3.93s、chromey 3.97s、nv-ws 4.09s、nv-lightpanda 4.09s、puppeteer 4.19s、nv-brave 4.20s、nv-serve 4.30s、chromedp 4.42s、playwright 4.48s、nv-edge 4.74s。
ライブページは実行ごとに変化するため、これらは参考情報であり、正確性の判定基準には含まれません。(スクロールのチェックは、以前はどのドライバーでもランダムに失敗していました。GitHub は CSS scroll-behavior: smooth を設定するため、アニメーションの途中で scrollY が読み取られていました。現在、各候補は behavior: 'instant' でスクロールします。)
chrome-headless-shell(ブラウザー UI レイヤーを除いた同じ Chrome ビルド):コールドスタート 0.28s → 0.08s、セッション 0.60s → 0.34s、ブラウザーのメモリ使用量 370 MB → 225 MB。
CDP トランスポートのA/B比較(同じビルド、同じ実行):--remote-debugging-pipe(Linux/macOS でのデフォルト)と DevTools の WebSocket ポート:コールドスタート 0.28s 対 0.30s、セッション 0.60s 対 0.63s。速度差はありません。WebSocket のハンドシェイク自体は約10 msです。パイプをデフォルトにしている理由は、ほかに2つあります。別のローカルプロセスが接続できる TCP ポートを開かないこと、そして navigera が終了すると Chrome も終了すること(コマンド用パイプの EOF)。そのため、エージェントが強制終了されてもブラウザーが残りません(tests/edge_cases.rs:WebSocket ポートでは、ドライバーが終了してもブラウザーは動作し続けます)。
Windows にはこのパイプトランスポートがなく、WebSocket を使用します。クローズ時に強制終了するジョブオブジェクトにより、同じ保証が得られます(killed_session_server_takes_its_browser_down もそこで実行されます)。
このビルドと前のビルドの比較、同じマシン、同じ実行(nv-baseline。ラダーの baseline_ref A/B により、前の master からビルド):セッション 0.62s → 0.60s(-3%)、コールドスタート 0.30s → 0.28s(-5%)、セッションあたりのブラウザー CPU 時間 1.14s → 1.16s。セッションで、ページがログに記録した内容と取得した内容(console、network)も記録するようになりました。
navigera のコールドスタートの内訳(NAVIGERA_TIMINGS、ベスト実行):ブラウザー起動 159 ms、最初のページ 110 ms、終了 2 ms。
エージェントのツール(スクリプト実行、ウォームセッション、3回中のベスト)
エージェントのツール呼び出しがブラウザーをどのように操作するか:CLI ツールでは各ステップにつき1つのプロセス(シェルツール)が実行され、MCP サーバーでは永続的な接続を介して各ステップにつき1つの tools/call が実行されます。同じ標準セッションに、ページスナップショットを1つ追加しています。
| ツール | 種別 | 合計実時間 | ステップあたりの平均 | スナップショット | スナップショットのサイズ | 判定 |
|---|---|---|---|---|---|---|
navigera(このリポジトリ) | CLI | 0.85s | 44 ms | 180 ms | 36 KB | ✓ |
chrome-headless-shell 上の navigera | CLI | 0.49s | 33 ms | 150 ms | 36 KB | ✓ |
agent-browser(Vercel Labs、Rust) | CLI | 1.29s | 94 ms | 198 ms | 73 KB | ✓ |
playwright-cli(Microsoft) | CLI | 10.08s | 804 ms | 422 ms | 50 KB | ✓ |
| Playwright MCP(Microsoft) | MCP | 5.32s | 403 ms | 76 ms | 50 KB | ✓ |
| Chrome DevTools MCP(Google) | MCP | 3.25s | 201 ms | 105 ms | 34 KB | ✓ |
ステップごとの時間には、プロセスの起動(CLI)または JSON-RPC(MCP)、デーモンへの接続、CDP の処理が含まれます。playwright-cli と Playwright MCP は Playwright のツールバックエンドを共有しており、各アクションの後に固定で500 ms待機します(timeouts.settle)。また、playwright-cli はステップごとに Node プロセスを起動します。
Lightpanda(実験的)は、同じ正確性の判定に0.18sで合格し、ブラウザーのメモリ使用量は約14 MBです。レンダリングエンジンがなく、タブは1つのみです(セッションは2つ目のページを同じタブで開きます)。そのため、Chrome 系のランキングとは分けて掲載しています。
エージェントの評価:汎用エージェントは各ツールにどのように対処するか
ベンチマークでは、スクリプト化された手順の所要時間を測定します。エージェント評価では、エージェントにとって重要な問いを検証します。汎用コーディングエージェントは、ツールとそのドキュメントだけを与えられたとき、実際のタスクを完了できるでしょうか?agent-eval.yml では、無料枠の API キーを使って、ローカルの Acme Supply サイト上で Gemini CLI をヘッドレスで実行し、navigera、playwright-cli、agent-browser を順番に評価します。
- skilled: ツールがインストールされており、ベンダー提供の Agent Skill がワークスペース(
.agents/skills/)にあります。 - onboard: エージェントにはツール名とリポジトリ URL だけが与えられ、ドキュメントを参照してインストールした後、短いタスクを実行します。
6 つのタスクは、価格の照会、クーポンと iframe の決済フォームを使った購入、ログインとページ分けされた注文テーブル、折りたたまれた FAQ がある新しいタブでのドキュメント閲覧、iframe 内のサポートフォーム、そして 170 行の設定フォームでほかのすべての項目はそのままに、指定された 4 つの変更を行うことです。成功は、サイトに記録された状態と最終回答から判定し、エージェントの自己申告は判断材料にしません。各実行では、モデルへのリクエスト、トークン、シェルコマンド、ツールを使わない回避策(curl、即席のスクリプト)も記録します。モデル、プロンプトテンプレート、Chrome、サイトは、すべてのツールで同一です。os: windows(または both)を指定すると、同じジョブが Windows ランナーでも実行されます。その場合、エージェントのシェルは PowerShell です。
3 つのツールは並列ジョブとして実行されます。キーは main 環境にツールごとに 1 枠ずつ設定します。Gemini の無料枠は Google Cloud プロジェクトごとに割り当てられるためです。キーは GEMINI_API_KEY(navigera)、GEMINI_API_KEY_2(agent-browser)、GEMINI_API_KEY_3(playwright-cli)です。枠が空の場合は GEMINI_API_KEY にフォールバックします。キーがない場合はスクリプトによるベースラインのみが実行され、既知の正常な navigera コマンドプランを使ってサイト、成功判定、ハーネスを確認します。モデルのクォータ超過や障害で停止した実行は、ツールの失敗として数えず、⚠ インフラとして報告されます。
agent: openai を指定すると、Gemini CLI の代わりに、OpenAI 互換モデルを使って同じタスク、プロンプト、ターン数上限、タイムアウトで実行されます(デフォルトでは SiliconFlow 経由の DeepSeek-V4.1-Flash。OPENAI_BASE_URL、SILICONFLOW_API_KEY)。これにより、別のモデルファミリーでも結果を照合できます。
navigera+jev は、decider を設定して navigera を実行します。navigera+jev-told では、さらにプロンプトで --find / check の使用を求めます。TypeSafe キー(main の TYPESAFE_API_KEY)はローカルリレー内にとどまり、エージェントのシェルからは見えません。各実行では decider の呼び出し回数とトークン数も記録されます。decisions: true を指定すると、上記の Jev と Gemini の意思決定比較が追加されます(bench/decide/compare.py)。
0.5.0 (2026-10-22)、skilled、6 つのタスクをツールごとに 2 回実行:
- DeepSeek-V4.1-Flash(run 39699303497):navigera は中央値 50K トークン、9 モデルターンで 12/12 に合格し、Lightpanda でも 12/12(121K)でした。playwright-cli は 11/12(96K)、agent-browser は 12/12(153K)でした。decider を有効にすると、navigera は 43K で 12/12 に合格し、エージェントはプロンプトで指示されなくても 12 回中 3 回使用しました。使用するよう指示した場合は 12 回中 11 回(12/12、62K)でした。
- Gemini 3.5 Flash-Lite(run 39691538974):navigera は 127K で 12/12 に合格し、Lightpanda でも 12/12(167K)でした。
0.4.1 (2026-10-14)、Gemini 3.5 Flash-Lite、skilled:5 つのタスクをそれぞれ 2 回実行した計 10 回すべてで navigera が合格し、モデルターン数の中央値は 7、トークン数の中央値は 103K でした。
0.3.0 と 0.2.1 の比較。同じモデルで同時に実行(購入とアカウント、各 2 回、すべて合格):ax が、ページでまだ取得中のデータを待つようになり、スキルでは確実な手順を 1 回のシェル呼び出しで連続して実行する方法を説明するようになりました。モデルターン数の中央値は 18 から 10 に、トークン数の中央値は 288K から 167K に減りました。同じタスクでは、0.3.0 のすべての実行で、0.2.1 のすべての実行よりトークン数が少なくなりました。
スクリプト化されたセッションは遅くなっていません。所要時間は 0.51 秒から 0.49 秒、コールドスタートはどちらも 0.23 秒でした。
自然言語によるチェック(agent-check.yml、
master へのプッシュごと、PR ごと、および夜間実行):Gemini に、navigera とそのスキルを使って
何かを購入するよう、平易な言葉で指示します。ローカルショップでは、Linux で一度、
PowerShell を使った Windows で一度(記録された注文をもとに判定する実際のチェック)、
さらに Sauce Labs の公開デモショップ
saucedemo.com でも一度実行します。このショップは自動化の練習用で、
実際の支払いは発生しません(確認画面と注文合計をもとに判定します)。
コントリビューション
ビルド、テストスイート、CI の結果の読み方、A/B ベンチマーク、リリースについては CONTRIBUTING.md を参照してください。
ディレクトリ構成
src/protocol.rs:CLI の解析、JSON Lines プロトコル、Driver(OPSテーブルは--help)src/browser.rs:BrowserSession:ブラウザーの検出(chrome-headless-shell を含む)、起動フラグ、タブsrc/cdp/:一から実装した CDP エンジン:パイプ/WebSocket トランスポート、JSON-RPC クライアント(NAVIGERA_CDP_TRACE)、ページ操作、ax.rs(スナップショットツリー)、events.rs(ダイアログ、ポップアップ、ナビゲーション)、procjob.rs(Windows ジョブオブジェクト)src/session.rs:名前付きセッション:ソケットサーバー(Unix ソケット、Windows ではループバック TCP +トークン)、クライアント、分離実行のstartsrc/cdp/attach.rs:--attach(実行中のブラウザー)と--profile(永続化された navigera ブラウザー)src/mcp.rs:navigera mcp、標準入出力で動作する Model Context Protocol サーバーsrc/decide.rs:find/check:意思決定モデルのクライアントと、ページ要素を選択肢に変換する方法src/install.rs:install-browser(Chrome for Testing のインデックス、curl によるダウンロード、zip の展開と検証)src/timing.rs:NAVIGERA_TIMINGS=1で起動/終了フェーズの所要時間を標準エラー出力に表示tests/:ブラウザーの E2E:プロトコル、セッション、Acme Supply のシナリオを実行bench/site/server.py:Acme Supply、決定論的なローカルショップ(SPA、iframe、Shadow DOM、ダイアログ、ポップアップ、ログイン、アップロード)bench/ladder/:ドライバーの比較とエージェントツールのベンチマーク(実行ごとのpublish.json、gen_readme.py)bench/agent-eval/:navigera、playwright-cli、agent-browser を対象にした Gemini CLI エージェント評価bench/decide/:意思決定ベンチマーク(compare.py)、TypeSafe リレー(relay.py)、キーなしでの実行用の代替実装(mock_jev.py)tools/:cdp_check.py(プロトコルの正確性)、protocol_dump.sh、cft_matrix.py(Chrome バージョンマトリックス)skills/navigera/SKILL.md:エージェントガイド(バイナリにコンパイル済み:navigera skill).github/workflows/:ci.yml(テスト、Chrome マトリックス、プロトコルチェック)、bench.yml、agent-eval.yml、release.yml、chrome-bisect.yml、vendor.yml
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。