Gemini Nexus を採用する前に読む: Gemini Web 逆解析と MCP 制御を抱えた Chrome 拡張

Gemini Nexus が埋めようとしている穴は API キーとブラウザ文脈の断絶

ブラウザで調べ物をしながら LLM に聞くとき、多くの人はタブを切り替えてチャット画面にコピーし、結果をまた元のページに戻す。Gemini Nexus はこの往復をサイドパネルに畳み込む。対象は Chrome を使い、Gemini を日常的に使っているが、公式 API キーを用意するほどでもない、あるいは複数プロバイダを状況で使い分けたい層だ。README は「Give your browser a native AI layer」と表現し、サイドパネル単体ではなく注入型のフローティングツールバー、画像とスクリーンショット入力、Chrome DevTools Protocol ベースのブラウザ制御ツール、任意の外部 MCP ツールを同梱すると説明している。つまりチャット UI の提供ではなく、開いているページを文脈として渡し、必要ならページ操作まで踏み込むところが狙いだ。

Gemini Web 経路はトークン抽出で成立している

README の Data Flow Disclosure はかなり率直だ。Web Client プロバイダは gemini.google.com の内部 RPC エンドポイントを逆解析し、ページ HTML から atValue、blValue、f.sid を抽出してローカル保存する。これを使ってブラウザリクエストを模倣し、公式 API キーなしでアクセスする。リクエストは gemini.google.com と push.clients6.google.com にセッション資格情報付きで送られる。README 自身が「This approach likely violates Google's Terms of Service」と明記し、不正アクセスと見なされうるとも書いている。ここは機能の説明ではなく設計上のリスクそのものだ。内部 RPC は予告なく変わりうるので、この経路は Google 側の変更で壊れる前提で扱う必要がある。

プロバイダは services/providers のドライバで切り替わる

リポジトリには services/providers があり、README の表では web.js、official.js、openai_compatible.js、anthropic.js の 4 ドライバに 9 プロバイダが割り当てられている。Gemini Web、Gemini API、OpenAI 互換、OpenAI 公式、DeepSeek、OpenRouter、Qwen / DashScope、Anthropic、Zhipu だ。興味深いのは openai_compatible.js が OpenAI 互換、OpenAI 公式、DeepSeek、OpenRouter、Qwen、Zhipu の 6 つを兼ねる点で、差分は Base URL、API Key、Model IDs と各社固有のペイロードで吸収している。OpenRouter は /models を取得し provider routing JSON を送り、Qwen は enable_thinking と VL 画像入力、Anthropic は Messages API と extended-thinking ストリーム表示というように、共通ドライバでは足りない部分だけ別実装になっている。

動かすまでの手順と設定キー

README にはインストール手順の記載がなく、リポジトリ構成から読み取れるのは Vite と TypeScript、JavaScript を使う MV3 拡張で、ビルド成果物を Chrome の拡張機能ページから読み込む形になるという程度だ。具体的なコマンドは README に書かれていないので、package.json の scripts を自分で確認する必要がある。設定側で確実に押さえるキーは Base URL、API Key、Model IDs の 3 つで、プロバイダごとに個別指定する。Web プロバイダには一時チャットを有効にするオプションがあり、これをオンにすると Web 経由のリクエストが Gemini の Recent chats に残らない。API キーは Chrome 拡張のストレージにローカル保存され、選択したプロバイダ以外に送信されないと README は説明している。

MCP と CDP 制御はサイドパネルを操作端末に変える

ブラウザ制御タスクは Chrome のネイティブタブグループで印を付け、list_pages / select_page の対象を制御スコープに限定する。外部 MCP ツールは任意で接続でき、その場合データはユーザーが設定した MCP サーバーのエンドポイントへ流れる。API キーが第三者に渡らないという README の記述は、あくまで選択したプロバイダと自分で設定した MCP サーバーが送信先だという意味であり、MCP を足せば送信先も増える。制御対象をタブグループで絞る設計は、意図しないタブを操作する事故を減らす方向に働く。ただし CDP 経由の操作がどの権限を要求するかは README からは読み取れず、manifest.json の permissions を確認しないと判断できない。

watermark 除去は便利機能ではなく法的な分岐点

Gemini が生成した画像について、拡張は埋め込み watermark（メタデータマーカー）を除去して直接ダウンロードできるようにする。README はこれが帰属表示と署名を AI 生成コンテンツから剥がす行為だと認め、著作権上の含意と Google の生成コンテンツポリシーに注意を促している。業務で生成画像を扱う場合、この機能が既定で有効なのか、設定で切れるのかを先に確認したい。切れないなら、その時点で導入判断は変わる。個人が自分のメモ用に使うのと、成果物として配布するのとでは意味がまったく違う。

向かない場面と、代わりに検討するもの

規約遵守が調達条件に入る組織では Web プロバイダ経路は使えない。watermark 除去も同様だ。この場合の現実的な代替は、Gemini API キーを発行して official.js 経路だけを使う構成で、Google Search grounding と Thinking は API 側でも提供されると README は説明している。もう一つの代替はブラウザ拡張をやめ、MCP サーバーを別プロセスで立てて任意の MCP クライアントから操作する形だ。Gemini Nexus は MCP をクライアント側で取り込む立場だが、制御と UI を分離すれば拡張の更新に振り回されずに済む。逆に、Gemini Web のセッションをそのまま使いたい、サイドパネルからページを読ませたいという要求は代替では満たしにくい。

MIT ライセンスが及ぶ範囲と保守コスト

ライセンスは MIT で、コードの利用と改変は自由だ。ただし MIT が免除するのは著作権者からの責任追及であって、Google の規約違反や watermark 除去に伴う問題を免れるものではない。README も research/experimental purposes と位置づけ、誤用への責任を否認している。保守コストは Web プロバイダ経路に集中する。内部 RPC とトークン名に依存する以上、Google 側の変更で動かなくなる可能性が常にあり、v5.2.0 から v5.3.0 まで短期間に版が進んでいる事実は、追従が必要な変化が続いていることを示す。API プロバイダ側だけを使うなら、この種の破損リスクはかなり下がる。

編集部の結論

Gemini Web のセッションを再利用して API キーなしで試したい個人、複数プロバイダを 1 つのサイドパネルにまとめたい開発者には向く。企業や規約遵守が必須の環境、生成画像の帰属表示を外せない業務には向かない。導入前に services/providers 配下のドライバ構成と、Web プロバイダ利用時の Google アカウントの扱いを自分の目で確認し、watermark 除去機能を無効にできるかどうかを確かめておくべきだ。

公式情報源

1. Issues
2. License: MIT
3. README
4. Releases
5. yeahhe365/Gemini-Nexus on GitHub