Claude Codeの内蔵ブラウザは、機能一覧で見るかぎり地味な追加に見えます。
ブラウザが1枚増えただけではないか、と私も最初は思っていました。

実際に触ってみて、印象が変わりました。
消えたのは画面ではなく、「ドキュメントを開いてコピーしてClaudeに貼る」という一連の手作業のほうでした。

ただし、そのまま素直に動いてくれたわけでもありません。
会員ページを開かせようとして、ログインしていない画面が返ってきて手が止まる。
外部サイトを触らせようとすると、許可を求めるダイアログが出て作業が止まる。
どちらも仕様どおりの挙動なのですが、知らずに触ると「壊れた」と勘違いします。

実際に作業が止まったのは、この2箇所だけでした。
逆に言えば、この2箇所さえ先に知っていれば、あとは素直に動きます。

Claude Codeの内蔵ブラウザ（Browserペイン）とは何か

「Claude Codeにブラウザが付いた」は正確ではない

まず、いちばん誤解されやすい点から片付けます。

内蔵ブラウザは、デスクトップアプリであるClaude DesktopのCodeタブに付いた機能です。
ターミナル（黒い画面にコマンドを打つ、あの操作環境）で動かすCLI版のClaude Codeに、同じペインが付いたわけではありません。

公式の週次ダイジェスト（code.claude.com/docs/en/whats-new/2026-w28）は、デスクトップのClaude Codeでドキュメント、デザイン、任意のサイトを開き、読む、クリックする、操作できると説明しています。
主語は「デスクトップの」Claude Codeです。

導入判断でいちばん混乱するのがここでした。
「Claude Codeに入った機能」という情報だけを見て、ターミナル版を探しに行くと見つかりません。

従来のプレビュー機能から何が変わったのか

もうひとつ、ゼロからの新機能ではない点も押さえておきます。

ローカル開発サーバー（自分のパソコンの中だけで動かしている、公開前のWebサイト）のプレビューは、以前からできていました。
今回の差分は、その対象が外部のWebサイトまで広がったことです。

つまり「見られる場所が自分のパソコンの中だけだったのが、インターネット全体になった」という変化です。
新機能の追加というより、既存機能の射程が伸びた、と捉えるほうが実態に近いと思います。

いつ入った機能か（Week 28 / v2.1.202〜206）

リリースはWeek 28、2026年7月6日から10日の週です。
対応するのはデスクトップ版のv2.1.202からv2.1.206。
日本語メディアでは、窓の杜が2026年7月10日（現地時間）発表分として報じています。

バージョン番号は2系統あるので注意が必要です。
内蔵ブラウザはv2.1.202〜206系、ペインのレイアウト機能そのものはClaude Desktop v1.2581.0以降という別の番号系列です。
「v1.2581.0で内蔵ブラウザが追加された」と書く二次情報も見かけますが、これは混同です。

使い始める前に確認する前提（プラン・バージョン・OS）

対応プランと課金の前提

claude.com/download によれば、チャットはFreeを含む全プランで使えますが、Claude CodeとClaude CoworkはPro / Max / Team / Enterprise が対象です。
まず無料で試してから判断する、という進め方はできません。
円建ての価格は為替と改定があるため、公式のpricingページで再確認してください。

必要なアプリバージョン

日本語の公式Docs（code.claude.com/docs/ja/desktop）は、ペインレイアウトにClaude Desktop v1.2581.0以降が必要と明記しています。
更新はmacOSがClaudeメニュー、WindowsがHelpメニューのCheck for Updatesからです。
ペインが出てこないという相談は、たいていここで解決します。

OS別の対応状況

対応OSはmacOS、Windows、Linux（ベータ）です。
ただしLinux版でBrowserペインがどう動くかについて、公式の明示的な記述は確認できていません。
Linuxで運用する予定なら、実機での確認が必要です。

項目	必要な条件	満たさない場合に起きること
プラン	Pro / Max / Team / Enterprise	Codeタブ自体が使えない。チャットのみ
アプリバージョン	Claude Desktop v1.2581.0以降	ペインレイアウトが表示されず、Browserペインを開けない
OS	macOS / Windows / Linux（ベータ）	Linuxはベータ扱い。Browserペインの挙動は公式記述を確認できず、要実機確認
ネットワーク	外部サイトへの接続	localhostのプレビューは可能だが、外部ドキュメントの参照ができない

Browserペインの開き方と基本操作

開き方は4経路あります。
macOSは Cmd + Shift + B、Windowsは Ctrl + Shift + B、Viewsメニューから選ぶ方法、そしてツールバー右端に追加された地球アイコンです（アイコンについては窓の杜 2026年7月10日報）。

ショートカットは覚えなくても困りません。
UIやショートカットの位置はバージョンで変わるため、覚えるならViewsメニューの経路のほうが壊れにくいと思います。

チャットの中に出てきた外部リンクをクリックすると、「アプリで開く（Browserペイン）」か「既定のブラウザ」かを選ぶダイアログが出ます。
毎回選ぶのが煩わしいときは、macOSはCmd+クリック、WindowsはCtrl+クリックで、システムのブラウザが直接開きます。

Browserペインはタブ付きです。
動かしているアプリの隣に、ドキュメントやIssueトラッカーを並べておけます。
HTML、PDF、画像、動画のパスは、ファイルペインではなくBrowserペインで開く点も覚えておくと戸惑いません。

なお、表示中のページの要素を選択する Cmd + Shift + S については、クラスメソッドのDevelopersIOなど二次ソースでの紹介にとどまり、公式Docs上の記載は確認できていません。
使う場合は、自分の環境で動くことを確かめてから運用に載せてください。

「ドキュメント往復がなくなる」を実作業フローに落とす

従来フローとBrowserペイン後のフローの違い

従来のフローは5ステップでした。

1. ドキュメントを読む
2. ブラウザに切り替える
3. 必要な箇所をコピーする
4. Claudeに貼り付ける
5. 作業に戻る

Browserペインが効くのは、3と4のコピーと貼り付けが丸ごと消えるところです。
Claude自身がページを開いて読み、そのままコードに反映します。

推測：1回あたりの節約は数十秒程度だと思います。計測はしていません。
測るなら秒数より、回数のほうが素直です。
仕様確認から実装、動作確認、記録までの1周に、アプリの切り替えが何回入っているか。
従来は「調べる」たびに1往復が発生していたものが、URLを渡す1回に置き換わります。
効いているのは1回の秒数ではなく、この往復の本数のほうです。

パターン1：API仕様を参照しながら実装する

APIとは、外部サービスの機能を自分のプログラムから呼び出すための窓口です。
使い方は提供元のドキュメントページに書かれています。
ここではURLを渡すこと自体が、参照すべき情報の受け渡しになります。
どのページのどの節か、と口頭で説明する手間がなくなります。

パターン2：localhostで動作確認して直す

localhostとは、自分のパソコンの中だけで動いている開発中のサイトのことです。

ここが実務でいちばん軽く回ります。
ローカルの開発サーバーとプロジェクトファイルへのアクセスは承認不要なので、動作確認は許可のダイアログに止められずに走り続けます（公式Docs desktop）。

「localhostの該当ページを開いて、表示崩れがないか確認して」と伝えると、開いて見て直す、までが続けて進みます。

パターン3：GitHub Issueや外部情報を読ませる

GitHubのIssueは、開発中の課題やバグ報告を記録しておく掲示板のような場所です。
外部ページを読ませる場合は、後述するドメイン許可リストと安全分類器の対象になります。
初回は許可を求めるダイアログが挟まる前提で、作業の段取りを組んでおくほうが安全です。

小規模事業者の実務で効くのは、「仕様確認→実装→ブラウザで動作確認→結果をメモに記録」の1周が1画面で終わることです。
画面を行き来しないと、途中で何を調べていたのかを見失う回数が減ります。

つまずきどころ①：許可プロンプトが出る条件を理解する

安全分類器とドメイン許可リストの二層構造

ここが仕様のいちばんややこしいところです。

公式Docsによれば、外部ページでの書き込み操作、つまりクリックや入力は、どの権限モードでも安全分類器がレビューします。
危険と判断されれば、モードに関係なく許可を求めるダイアログが出ます。

一方、ドメイン許可リスト（アクセスしてよいサイトのリスト）のチェックは、AutoとBypass permissions以外のモードでのみ、新しいサイトへ遷移する前に入ります。

つまり片方は全モードで効き、もう片方はモードによって省かれます。
この非対称が「モードを緩めたのにプロンプトが出る」という混乱の正体です。

権限モードごとの効き方の違い

権限モード	安全分類器	ドメイン許可リスト	実務での使いどころ
Manual	適用される	適用される	外部サイトを初めて触るとき。挙動を目で確認したい段階
Auto	適用される	適用されない	参照先が固まった後の反復作業。localhost中心の検証
Bypass permissions	適用される	適用されない	影響範囲を把握している検証環境に限る

表のとおり、安全分類器の列はすべて「適用される」です。
モードを緩めても、外部ページへの書き込みは止まりうると考えてください。

Claudeがやらないこと（購入・アカウント作成・CAPTCHA）

承認済みのサイトであっても、Claudeはユーザーの入力なしに購入、アカウント作成、CAPTCHA（画像の文字や信号機を選ばせる、人間かどうかの判定）の回避を行いません（公式Docs desktop）。

運用の整理としては、こう覚えると組みやすいと思います。
自分のコードを触る作業は止まらず、外部サイトを触る作業だけが止まる。

つまずきどころ②：ログインできない・セッションが消える

普段のChromeとは別のクリーンなプロファイルで動く

私が最初に手を止めたのがここでした。

会員ページを開かせたら、ログイン画面が返ってきました。
普段のChromeではログイン済みのサイトです。

公式Docsは、Browserペインが普段のブラウザとは別のクリーンなプロファイルで動作し、保存済みのログインや履歴を引き継がないと明記しています。
普段のブラウザのログイン状態は、Browserペインには一切引き継がれません。
不具合ではなく、そういう設計です。

ペイン内でサインインする

ペインの中でサインインすること自体はできます。
Google OAuth（Googleアカウントで他サービスにログインする仕組み）のような、別窓が開くタイプのログインにも対応しています。

ただし、公式の案内はもう一歩踏み込んでいます。
自分としてログイン済みの状態で操作させたい用途は、Claude in Chrome拡張の役割だとされています。

セッション保持のオン／オフと消去

保存済みのセッションデータの消去と、Browser自体のオフは、Settings → Claude Code のトグルで行います。

セッションを保持するトグルについては、2026年5月時点の記事で「Persist Preview Sessions」として紹介されており、Cookie（サイトがブラウザに預けておくログイン状態などの小さなデータ）やログイン状態をプロジェクトフォルダ単位で保存する挙動が説明されています。
ただし正式なUI名称はバージョンで揺れている可能性があり、実機での確認が必要です。

検証段階では、業務アカウントでのログインは試さないほうが安全です。
公開ドキュメントとlocalhostだけで運用を組み、ログインが必要になった時点でClaude in Chromeとどちらを使うかを判断すれば十分だと思います。

Browserペイン・Claude in Chrome・computer useの使い分け

3つの機能は目的が違う

名前が似ているため混同されがちですが、動く場所が違います。
動く場所が違えば、任せられる作業も変わります。

Claude in ChromeはChrome拡張（v1.0.36以降）として、実際に自分のパソコンで動いているChromeを操作します。
CLIとVS Code拡張の両方から使え、ブラウザのログイン状態を共有します。

computer useはmacOSとWindowsのリサーチプレビューです。
ProまたはMaxが必要で、Team／Enterpriseでは利用できず、既定はオフです。
Browserペインとは別機能なので、比較検討のときに混ぜないでください。

機能	動く場所	ログイン状態	向く作業	必要プラン
Browserペイン	Claude Desktop内のクリーンなプロファイル	引き継がない	公開ドキュメント参照、localhost検証	Pro / Max / Team / Enterprise
Claude in Chrome	ローカルのChrome本体（拡張 v1.0.36以降）	共有する	ログイン必須の管理画面操作	Claude Codeの対象プラン
computer use	OS画面全体（リサーチプレビュー）	端末の状態に依存	画面操作の自動化の検証	Pro / Max（Team・Enterprise不可）

判断の順番と実務での線引き

公式Docsは、コネクタ、Bash、Claude in Chrome、iOS Simulatorペインの順に、より精密なツールを優先する考え方を示しています。
APIで直接取れるものはAPIで取る。
コマンドで済むものはコマンドで済ませる。
画面を見ないと判断できないものだけをブラウザに任せる。

小規模事業者の実務なら、公開情報の参照と自社サービスの動作確認はBrowserペイン、ログインが必須の管理画面操作はClaude in Chrome、の二分で足ります。

貼って使えるBrowserペイン運用チェックリスト

導入時に一度だけ確認する項目と、毎回の指示テンプレートをまとめました。

■ 導入時チェック（一度だけ）
□ プランが Pro / Max / Team / Enterprise のいずれかである
□ Claude Desktop を v1.2581.0 以降に更新した
   macOS : Claudeメニュー → Check for Updates
   Windows : Help → Check for Updates
□ 権限モードを決めた
   Manual : 安全分類器＋ドメイン許可リストの両方が効く（初期はこれ）
   Auto / Bypass permissions : ドメイン許可リストは省略、安全分類器は効く
□ セッション保持の方針を決めた（Settings → Claude Code のトグル）
□ ログイン必須の作業は Claude in Chrome に回す、と線引きした

■ 毎回の指示テンプレート
【仕様を参照して実装する】
このURLのページを開いて、認証部分の仕様を確認してから、
該当箇所を実装してください。参照した箇所は要約して残してください。

【動作確認して直す】
localhost の該当ページを開いて、表示崩れがないか確認してください。
崩れがあれば原因の見当をつけて修正し、もう一度開いて確認してください。

よくあるご質問

まとめ：一画面で完結する環境に一歩近づいた

内蔵ブラウザの本質は、新しい閲覧手段が増えたことではありません。
ドキュメントの内容をコピーしてClaudeに渡す、という受け渡しのコストが消えたことです。

私の元になった投稿は、この点だけを書いたものでした。

ブラウザペインが入ったことで、Claudeが自分でドキュメントページを開いて読んで、そのままコードに反映できるようになりました。
（筆者のX投稿より）

投稿では書ききれなかったのが、許可プロンプトの二層構造と、ログインが引き継がれない点です。
冒頭で「止まったのは2箇所」と書いたのは、この2つのことでした。

本記事は2026年7月時点の仕様に基づいています。
Cmd + Shift + S の要素選択と、Linux版でのBrowserペインの挙動は公式Docs上の記載を確認できていません。
運用に載せる前に、公式Docs（code.claude.com/docs/ja/desktop）と週次のwhats-newを確認してください。

Browserペインは、使い始めるだけなら10分もかかりません。
難しいのは、どの作業をClaudeに任せ、どこで人が判断するかの線引きのほうです。
自社の業務でどこから手を付けるか判断がつかない、という段階でしたら、現状の作業フローを一緒に整理するところからお手伝いしています。
気軽にご相談ください。