Claude in Chromeとは｜設定手順と22ツール・拡張機能の権限を実機で確認

Claude in Chrome は、Claude Code からあなたの Chrome を操作させる公式連携です。2026年6月〜7月の Week 27（v2.1.198）で一般提供（GA）になりました。ログイン済みのブラウザをそのまま使えるので、API連携なしで Google Docs や社内アプリを触れます。本記事では --chrome での設定手順と、22個のブラウザツールが plan モードでどう切り分けられるか、そして拡張機能が manifest 上で何を要求しているかを、手元の Claude Code v2.1.241 と拡張機能 v1.0.85 で確認しながら整理します。

Claude Code 本体の設定はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事はそこにブラウザを繋ぐ話です。

Claude in Chromeとは — ログイン状態ごとAIに渡す連携

Claude in Chrome は、Claude Code が Chrome 拡張機能を通じてブラウザを直接操作する仕組みです。GA時のリリースノートはこう説明しています。

Claude Code drives your browser through the Claude in Chrome extension: it opens tabs, clicks through pages, fills forms, reads console logs, and shares your login state, so it can test the app it builds without you switching contexts.

“shares your login state” が肝です。API連携やOAuthを設定しなくても、あなたがすでにログインしている Google Docs・Gmail・Notion・社内管理画面をそのまま触れます。裏を返せば、ブラウザで見えるものはClaudeにも見えるということでもあります。

Claude Code を動かす「面」は増えていて、ブラウザはそのひとつです。クラウドVM側で走らせる話はClaude Code Webとは｜–cloudと–teleportの使い方・制約をCLI実測で解説にまとめてあり、あちらが「手元を離れて実行する」方向なのに対し、Chrome連携は「手元のログイン状態を使う」方向です。用途がはっきり分かれます。

公式が挙げるユースケースは8つです。

前提条件 — APIキー認証では動かない

必要なものは4つです。

・Chromium系ブラウザ（Chrome / Edge / Brave / Arc / Vivaldi / Opera）
・Claude 拡張機能 1.0.36 以降（Chrome ウェブストア）
・Claude Code
・Anthropic 直契約のプラン（Pro / Max / Team / Enterprise）

見落としやすいのが認証方式の制約です。公式ドキュメントは明確に書いています。

Chrome integration also requires signing in with /login. If you authenticate with an API key or a long-lived token from claude setup-token, Claude Code keeps Chrome integration off, even when you pass --chrome.

APIキー認証や claude setup-token の長期トークンでは、--chrome を渡してもオフのままです。しかも過去には挙動が違いました——v2.1.216 より前は、これらのセッションでもChrome連携を有効化でき、ただし接続のたびに403で失敗していた、と公式が明記しています。つまり「有効になっているのに繋がらない」という紛らわしい状態が存在した版があります。手元が古い場合はまずアップデートしてください。

Amazon Bedrock・Google Cloud・Microsoft Foundry 経由でのみ Claude を使っている場合も対象外で、別途 claude.ai アカウントが必要です。

設定手順 — --chrome と /chrome

手元の Claude Code v2.1.241 で --help を確認すると、専用のフラグが2つあります。

claude --version
# 2.1.241 (Claude Code)

claude --help | grep -i chrome
#   --chrome      Enable Claude in Chrome integration
#   --no-chrome   Disable Claude in Chrome integration

起動はこれだけです。

claude --chrome

初回は連携とサイト権限を説明する一度きりのダイアログが出ます。以降のセッションでフラグを省きたい場合は /chrome から「Enabled by default」を選びます。

接続状態の確認も /chrome です。「Status: Enabled」かつ「Extension: Installed」の両方が表示されていれば動いています。複数のブラウザが接続されている場合は /chrome の「Select browser…」で選べます（v2.1.154 以降が必要）。

【実機確認】「インストール済み」と「接続済み」は別物

ここが実際に触ってみて一番はっきりした点です。手元の環境を順に確認しました。

① 拡張機能はインストールされている。 Chromeのプロファイル配下に実体がありました。

ls ~/Library/Application\ Support/Google/Chrome/*/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn
# 1.0.85_0

バージョンは 1.0.85。公式要件の 1.0.36 を大きく上回っています。

② Chrome も起動している。 プロセスを確認済みです。

③ native messaging のホスト設定も存在する。 公式トラブルシューティングが指す場所にファイルがありました。

{
  "name": "com.anthropic.claude_code_browser_extension",
  "description": "Claude Code Browser Extension Native Host",
  "path": "$HOME/.claude/chrome/chrome-native-host",
  "type": "stdio",
  "allowed_origins": ["chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/"]
}

④ それでも接続済みブラウザの一覧は空だった。 接続中のブラウザを問い合わせると [] が返りました。

つまり ①〜③がすべて揃っていても、接続が確立しているとは限りません。 「拡張機能を入れたのに動かない」という詰まり方の多くはここで、/chrome の「Reconnect extension」か、Claude Code と Chrome の両方の再起動が必要になります。とくに初回はChromeが起動時にしかホスト設定ファイルを読まないため、設定ファイルを置いた直後はChromeの再起動が効きます。

なお本記事の環境は非対話セッションで /login 済みの対話セッションを持たないため、この空の結果が「未接続」なのか「認証条件を満たしていない」のかまでは切り分けていません（未検証）。確認できたのは「①〜③が揃っていても自動的には繋がらない」という事実までです。

native host の正体は Claude Code 自身

設定ファイルが指す chrome-native-host を開くと、152バイトのシェルスクリプトでした。

#!/bin/sh
# Chrome native host wrapper script
# Generated by Claude Code - do not edit manually
exec $HOME/.local/bin/claude --chrome-native-host

claude --chrome-native-host という（--help には出てこない）モードで Claude Code 自身が起動するだけの薄いラッパーです。Chrome から見れば普通の native messaging ホスト、実体は Claude Code のプロセス、という構造になっています。

Claude Desktop とは別のホストが同居する

同じディレクトリを見ると、ホスト設定が2つありました。

そして同じ拡張機能ID fcoeoabgfenejglbffodgkkbkcdhcgfn が両方の allowed_origins に入っています。1つの拡張機能が、Claude Code と Claude デスクトップアプリという2つのクライアントから使われる設計です。片方を消しても、もう片方の設定ファイルは残ります。

【実機確認】ブラウザツールは22個、plan モードで承認が分かれる

実際のセッションで利用可能なブラウザツールを数えると 22個でした。

plan モードでの扱いが実務上重要です。公式は読み取り専用と状態変更を明確に分けています。

・承認プロンプトなしで動く：read_page / get_page_text / find / コンソール・ネットワークの読み取り / スクリーンショット
・承認を求める：クリック・入力・ナビゲーション・タブとウィンドウの操作・GIF録画

ここに例外があります。読み取り系のツールでも、状態を変えるフラグを立てると承認対象になります。

browser_batch は中に入っている操作が全部読み取り専用のときだけプロンプトなしで通ります。1つでも状態変更が混ざれば承認が要ります。「読み取り系ツールだから安全」ではなく、引数まで見て判定されているわけです。

拡張機能が持っている権限を manifest で確認する

ログイン済みのブラウザをAIに渡す機能なので、拡張機能が技術的に何をできるのかは把握しておく価値があります。インストール済みの manifest（v1.0.85 / Manifest V3）を実際に読みました。

注目すべきは debugger です。 これは Chrome DevTools Protocol（CDP）へのアクセスを意味します。コンソールログやネットワークリクエストを読めるのはこの権限があるからで、機能上は必要なものです。一方でCDPはページ操作の非常に強い口でもあります。

<all_urls> と組み合わせると、技術的にはすべてのサイトに対して読み書きができる構成です。これは「ログイン済みのブラウザをそのまま操作する」という価値提案とそのまま等価なので、権限が過剰というより機能の定義そのものと理解するのが正確です。

実務での絞り込み方は2つあります。1つはサイト単位の権限で、これは拡張機能側の設定で管理します（Claude Code 側ではなく Chrome の拡張機能設定が権限の出どころです）。もう1つは組織のポリシーで、deniedMcpServers の managed setting で claude-in-chrome MCPサーバーをブロックすると、そもそもインストールを促すプロンプトすら出なくなります。CIやGitHub側で権限をどう宣言するかという同種の設計はClaude Code Actionとは｜39入力とv1タグの実体、権限バイパス2つを実測解説でも扱っており、既定を絞って必要な分だけ開けるという考え方は共通です。

何を「読める」かはツール単位で違う

同じ「読み取り」でも、返ってくるものの粒度は違います。read_page はアクセシビリティツリーとして構造つきで返し、要素に参照IDが振られるのでクリック対象を指定できます。get_page_text は本文テキストだけを平たく返すので、記事や検索結果を読むときはこちらが軽く済みます。read_console_messages と read_network_requests はデバッグ用で、後者はリクエストIDを指定してレスポンスボディまで取れます。

「まずページを見せて」と頼むときにどれが呼ばれるかで、消費するコンテキスト量が変わります。 長いページの構造を丸ごと読ませると重いので、テキストだけで足りる作業なら get_page_text を明示的に指定するほうが効率的です。

つながらないときの切り分け

公式のトラブルシューティングを、実機で確認した構造に沿って並べ替えると次の順序になります。

1. chrome://extensions で拡張機能が有効かを確認する
   
2. claude --version を確認する（v2.1.216 未満だと、APIキー認証時に「有効なのに403で失敗」する）
   
3. Chrome が起動しているかを確認する
   
4. /chrome → 「Reconnect extension」を実行する
   
5. それでも駄目なら Claude Code と Chrome の両方を再起動する

5番目が効く理由は前述のとおりで、Chrome は native messaging のホスト設定を起動時にしか読まないためです。初回セットアップ直後に検出されない場合は、まずChromeを再起動してください。

ホスト設定ファイルの場所はブラウザごとに違います。macOS の場合、Chrome は ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/、Edge は ~/Library/Application Support/Microsoft Edge/NativeMessagingHosts/、Brave は ~/Library/Application Support/BraveSoftware/Brave-Browser/NativeMessagingHosts/ です。Windows はレジストリの HKCU\Software\<ベンダー>\<ブラウザ>\NativeMessagingHosts\ を見ます。

ブラウザが応答しなくなった場合は、まず JavaScript のモーダル（alert / confirm / prompt）がページを止めていないか確認します。ダイアログはブラウザイベントをブロックするため、Claude 側にコマンドが届きません。手動で閉じてから再開させます。

まとめ

・Claude in Chrome は Week 27（v2.1.198）でGA。ログイン状態を共有してブラウザを操作する
・claude --chrome で起動、/chrome で状態確認（v2.1.241 に --chrome / --no-chrome を確認）
・APIキー認証・setup-token・Bedrock/Vertex/Foundry 経由では使えない。/login が必須。v2.1.216 未満は「有効なのに403」という紛らわしい状態があった
・ブラウザツールは22個。plan モードでは読み取り／状態変更で承認が分かれ、createIfEmpty・clear・save_to_disk のようなフラグ1つで判定が変わる
・拡張機能（v1.0.85・MV3）は debugger と <all_urls> を要求。CDPアクセスを含む
・インストール済み ≠ 接続済み。実機では拡張機能・Chrome起動・ホスト設定の3つが揃っていても一覧は空だった
・native host の実体は claude --chrome-native-host を呼ぶ4行のシェルスクリプト。Claude Code 自身が動いている

「ブラウザをAIに渡す」のは強力ですが、権限の実体は manifest に全部書いてあります。入れる前に1回読んでおくのが、いちばん確実な判断材料です。

導入を判断するときの現実的な線引きとしては、個人の開発用プロファイルと、業務で機微な情報にログインしているプロファイルを分けるのが最も素直です。Chrome はプロファイル単位で拡張機能を管理するので、開発用プロファイルにだけ入れておけば、<all_urls> の範囲が実質的にそのプロファイルで見られるものに限定されます。実機で確認した限り、この拡張機能が入っていたのも1プロファイルだけでした。

参照ソース

• Use Claude Code with Chrome — 公式ドキュメント。前提条件・plan モードでの承認の切り分け・トラブルシューティング・ホスト設定ファイルの場所（2026-08-27 参照）
• Claude Code What’s New — Week 27 — v2.1.198 でのGA告知と “shares your login state” の記述（2026-08-27 参照）
• Claude 拡張機能（Chrome ウェブストア） — 配布ページ（2026-08-27 参照）
• インストール済み拡張機能 v1.0.85 の manifest.json、NativeMessagingHosts/*.json 2件、~/.claude/chrome/chrome-native-host、および Claude Code v2.1.241 の --help（2026-08-27 実測）