結論：併用は可能だが、managed設定で明示許可してから範囲を絞る
Claude Codeの排他的なmanaged MCP構成でChrome連携も使うには、組織管理者が公式changelogに追加されたallowClaudeInChromeWithManagedMcp managed settingを確認し、併用を許可する必要があります。設定を足すだけで全サイトを安全に操作できるわけではありません。Chromeのsite permission、Claudeのログイン方式、MCP toolの権限と送信データを別々に審査してください。
この検索意図の読者は、MCPを組織配布した後にclaude --chromeが使えず、管理設定を外して解決すべきか迷っています。答えは「管理設定を外す」ではなく、ブラウザ操作を業務で許可する必要性、直接Anthropic planの認証条件、許可サイト、停止担当を決めてから併用することです。
一次情報はClaude Code公式changelogとChrome連携の公式文書です。managed MCPの配布方式はMCP公式文書、設定のscopeと優先順位はsettings公式文書を正本にします。公式にない「安全になる」「自動でサイトを制限する」という保証は置きません。
managed MCPとChrome連携を比較する
| 対象 | 得られる操作 | 先に固定する境界 |
|---|---|---|
| managed MCP | 組織がHTTP・SSEのserverを利用者へ配布 | server、tool、認証、送信データ、停止担当 |
| Chrome連携 | ログイン済みブラウザで閲覧・入力・検証 | site permission、アカウント、可視操作、人間承認 |
| 併用 | コード変更とWebアプリ確認を一つのworkflowに接続 | MCPからの指示とブラウザ操作の因果、証跡 |
Chrome公式文書では、ChromeまたはEdgeなどのChromium系ブラウザ、Claude in Chrome拡張機能1.0.36以降、Claude Code、直接Anthropic plan、/loginが前提です。API keyやclaude setup-tokenだけの認証、Amazon Bedrockなど第三者provider経由ではChrome連携が利用できないと説明されています。MCPが使えることとChromeが使えることは同じ認証経路ではありません。
特に注意したいのは、MCPの説明文やtool結果がブラウザ操作の判断材料になることです。MCP serverが返したURLへ無条件に移動する、ページ上の指示をそのまま実行する、ログイン済みの別サービスへファイルを送る、といった連鎖を許可しないようにします。ブラウザを使う目的、MCPの出力を読む目的、実際に入力を送信する目的を分け、送信直前に人間が確認できる画面を残してください。
全社配布では、設定の正しさだけでなく変更の伝播も確認します。managed settingを更新した日時、利用者が受け取ったscope、Chrome拡張機能のversion、site permissionの変更者を記録し、退職・異動・業務終了で権限が消える経路を用意します。検証に使うstagingと本番を同じgroupに入れないことも、事故の影響を小さくする実務的な境界です。
判断に迷ったら、まず閲覧だけの小さなworkflowを一人の担当者で試し、MCP出力からChrome操作へ進む箇所を列挙します。入力や送信が不要なら、Chromeを許可しない構成のまま目的を満たせるかも比較します。
この比較結果も承認記録に残すと、機能を許可する理由が説明できます。
期限を過ぎたら設定を自動で再審査する担当も明記します。
少なくとも最初の承認は、閲覧と入力を同じ権限にしないことが原則です。
操作対象を増やす時は、先に目的と証跡を更新します。
導入前に確認する8手順
- 用途を一文で固定する。例えば「ステージング画面のフォーム検証だけ」と書き、Gmailや本番管理画面の操作を同じ許可に含めません。
- Claude Codeのversionを記録する。
claude --version、managed設定の配布日、変更承認者を台帳へ残します。 - 排他的MCPの範囲を確認する。
managed-mcp.jsonのserver、transport、tool、認証方式を読み、command型の扱いと全利用者への影響を確認します。 - 併用設定を審査する。
allowClaudeInChromeWithManagedMcpを誰のscopeで有効にするか、対象group、期限、ロールバック方法を決めます。 - 認証経路を分ける。Chromeを使う利用者は公式文書に合う
/login状態か確認し、API keyやBedrock経由で同じ機能が使えると説明しません。 - サイト許可を最小化する。Chrome拡張機能のsite-level permissionでstagingなど必要なhostだけを許可し、認証済みの個人情報サイトを対象から外します。
- 無害なfixtureで試す。テスト用アカウント、偽の注文番号、読み取り専用MCPを使い、ページ遷移、入力、送信前停止、MCP出力を記録します。
- 停止と見直しを実演する。
/chromeで接続状態を確認し、拡張機能権限とmanaged設定を戻して操作が止まること、監査担当が判断できることを確認します。
導入判定チェックリスト
- 対象業務と対象外業務が一文で書かれている。
- managed MCPのserver・tool・認証・送信先を棚卸しした。
allowClaudeInChromeWithManagedMcpのscope、承認者、期限、rollbackを記録した。- 直接Anthropic planと
/loginの条件を確認した。 - Chromeのsite permissionをstagingなどへ限定した。
- ログイン状態、ブラウザ操作、MCP tool結果の保存範囲を決めた。
- 送信前の人間確認、secret入力禁止、緊急停止をテストした。
よくある質問と次の行動
managed MCPを外せばChromeは動きますか？
動く可能性の検証だけを目的に管理設定を外すのは、組織の統制を弱めます。まず併用設定、認証、拡張機能、site permissionを順番に確認します。
Chromeの「allow all actions on that site」を選んでよいですか？
サイト単位の許可は、環境・アカウント・操作目的が限定されている時だけ検討します。本番や個人情報を含むサイトは、操作ごとの確認を残します。
MCPがread-onlyならChromeの入力も安全ですか？
別問題です。MCPのtoolが読み取り専用でも、Chrome側の入力・クリック権限は変わりません。二つの権限表を分けて承認します。
組織MCPの配布はmanagedMcpServersの運用ガイド、実行許可の設計はClaude Code権限設定ガイド、未知のrepositoryを調べる初期運用は制限モードのガイドも参照してください。Miraigentの無料診断では、MCP・ブラウザ・人間承認・停止条件を業務単位で整理します。