この機能は具体的にどんな問題を解決するのか？
これまで、Connector のないサイトを使う必要のある作業では、ユーザー自身がブラウザを開き、手作業で情報を調べ、コピー＆ペーストで Claude に貼り戻すしかなかった。この手作業部分は、ワークフローの中で最も自動化しにくい箇所であり続けた。内蔵ブラウザはこの隙間を埋める：Claude 自身がブラウザを開き、ページを読み、クリックしてフォームに入力する。ユーザーはもはやコピー＆ペーストの仲介役をする必要がない。
これが解決するのは「Claude がページを理解できるか」ではない（それはすでに Claude in Chrome でできていた）。「ユーザーが自分のブラウザを一切開かなくても、Claude が一連のブラウジング作業を単独で完了できるか」という問題だ。
Claude in Chrome と同時に存在すると、どちらを使うべきか分かりにくくならないか？
判断基準は実質1つしかない：そのタスクが「今開いているタブ」を必要とするかどうかだ。必要なら（例えば今見ている CRM ページ、まだ返信していないメール）Claude in Chrome を、必要なければ（Claude が自分でどこかのサイトへ行って調べればよい）内蔵ブラウザを使う。
公式もデフォルトの設計で選択の負担を減らしている：すでに Claude in Chrome を使っているユーザーはそれがデフォルトのまま維持され、使っていないユーザーは自動的に内蔵ブラウザに切り替わる。ユーザーが手動で切り替える必要がある場面はそれほど多くない。
「タブ・ブックマーク・パスワードは見えない」とは具体的にどういう意味か？
ここで重要なのはアーキテクチャレベルの分離であり、約束や運用上の自制ではない。内蔵ブラウザはユーザーの日常ブラウザとは完全に分離された独立環境であり、両者の間にデフォルトのデータ経路は存在しない——Claude には Chrome や Edge で開いているタブの内容を読み取る経路がなく、これは環境が分離されている結果であって、「Claude が見ないことを選んでいる」わけではない。
ログイン情報の移行はこれとは完全に独立した、ユーザーが能動的に行う操作だ。どのサイトのログイン情報を内蔵ブラウザに持ち込むかはユーザーが選択でき、銀行・メール・SSO の3種類はデフォルトで移行対象から除外されており、ユーザー自身が能動的に追加しない限り含まれない。つまり、よく使うサイトの大半のログイン情報を移行したとしても、最も機微なアカウント区分には「能動的に選ばない限り発生しない」という一段階余分な閾値が残る。
Anthropic 自身がプロンプトインジェクションを完全には排除できないと認めている以上、一般ユーザーはどうすればよいのか？
この一文は単なる免責事項として読み流すべきではなく、「AI エージェントがウェブを操作する」というリスクに関する業界全体の現在の技術的到達点を反映している。検知の仕組みは成功率を下げるが、リスクゼロを保証するものではない——この点は Claude in Chrome の公開時にすでに明確に認められており、内蔵ブラウザも同じ防護策を引き継ぎ、リスクの輪郭も同じだ。
一般ユーザーが実際にできる判断は、主に「Claude をどのサイトへ行かせるか」に集約される。構造が安定しており出所が信頼できるサイト（社内システムや日常的に使っているサービスのダッシュボードなど）は相対的にリスクが管理しやすい。出所が不明瞭で、不特定多数の第三者が自由に編集できるページ（公開フォーラムやユーザー生成コンテンツが中心のサイトなど）は、プロンプトインジェクションが潜みやすい場所だ。こうしたタスクでは、自分が実際に見ているタブ上で Claude in Chrome を使うか、少なくとも警戒を怠らず、Claude の操作が意図通りか段階的に確認することを優先したい。
Anthropic は2026年8月27日、Claude Cowork のデスクトップ版に内蔵ブラウザ機能を追加したと発表した。ウェブサイトの操作が必要なタスクでは、このブラウザが Cowork のサイドパネルに直接開き、Claude 自身がページの閲覧、内容の読み取り、ボタンのクリック、フォームへの入力を行える。拡張機能のインストールは不要だ。
公式が挙げる利用例には、レポートに必要なウェブデータの収集、サイトのダッシュボードから数値を整理すること、Connector がまだ提供されていない企業向けポータルでの作業などが含まれる。これまでユーザー自身がブラウザを開いてデータをコピーし、Claude に貼り戻す必要があった作業を、一括で任せられるようになる。
まず整理しておくべきは、これは Claude in Chrome の機能アップグレードではなく、まったく独立した新機能だという点だ。Claude in Chrome はユーザーがすでに開いてログイン済みのタブを操作するもので、目の前の CRM ページの更新、未返信のメール処理、編集中のドキュメントといった用途に向いている。一方 Cowork の内蔵ブラウザは、Claude に独立したブラウジング環境を与えるもので、ユーザー自身が普段使うブラウザとは完全に分離して動作する。
この違いがそのままどちらを使うべきかの判断基準になる：目の前のページを操作させたいなら Claude in Chrome、今開いているタブとは関係なく Claude 自身がどこかへ行ってデータ収集や操作を行うだけなら Cowork の内蔵ブラウザを使う。すでに Claude in Chrome を使っている場合はそのまま動作を継続しデフォルトであり続け、それ以外の場合は Claude が内蔵ブラウザを使用する。両者は Settings → Cowork → Preferred browser で切り替え可能だ。
独立した環境であるため、Anthropic は Claude がユーザー自身のブラウザのタブ、ブックマーク、パスワードを直接見ることはないと説明している。Claude にサイトへログインさせたい場合、ユーザーはログイン情報を個別に移行する選択ができる——現在 macOS では Chrome、Edge、Firefox からの移行、Windows と Linux では Firefox からの移行に対応している。銀行、メール、シングルサインオン（SSO）サイトはデフォルトで移行対象から除外されており、ユーザーが自ら選択しない限り含まれない。最も機微なアカウント区分がデフォルトで保護されている形だ。
Claude にブラウザ操作能力を持たせることは、ウェブを操作する AI エージェントに共通するリスク——プロンプトインジェクション——にも直面することを意味する。ページ内のコンテンツに隠された指示が、Claude をユーザーが本来依頼したタスクから逸脱させようとする可能性がある。Anthropic によれば、Cowork 内蔵ブラウザは Claude in Chrome と同じ防護策を採用しており、Claude の現在の操作がユーザーの当初の依頼と一致しているかをリアルタイムで確認する仕組みを含む。同社はこうした対策がリスクを低減するものであって完全に排除するものではないことも明言しており、ユーザーには信頼できるサイトを優先して Claude に操作させることを推奨している。
内蔵ブラウザは Claude デスクトップ版の Pro、Max、Team プランに段階的に展開されており、macOS、Windows、Linux に対応する（Linux 版は現在ベータ）。Enterprise プランはすでに利用可能で、管理者は Organization settings → Cowork → Built-in browser でこの機能を一元管理できる。
ブラウザ自体は Claude デスクトップアプリ内で動作する。デスクトップアプリが起動・接続された状態であれば、ウェブ版やモバイルからの指示でも Claude がこのブラウザを駆動できる。デスクトップアプリが起動していない場合、ウェブ版は引き続き Claude in Chrome でブラウザ機能を利用する。
「この社内システムには Connector がなく、手動でページを開いて調べては貼り戻すしかない」という壁に日常的にぶつかっているなら、内蔵ブラウザが埋めるのはまさにその隙間だ。Connector を置き換えるものではなく（Connector がある場合はそちらの方が依然として安定した選択肢だ）、公式連携が今後も提供されなさそうだが、時折手作業で確認せざるを得ないサイトをカバーするものと捉えるとよい。導入前に、Claude に実際に訪問させてよいサイトを棚卸ししておき、信頼できて構造が安定しているサイトから始めるのが現実的だ。銀行、メール、SSO はデフォルトで移行対象外のため、追加設定なしですでに一段階の保護がかかっている。それ以外のサイトのログイン情報を移行するかどうかは、手作業の時間削減とAIエージェントにどこまでアカウントアクセスを渡すかのトレードオフであり、一律の正解はない。