Claude Coworkのブラウザ内蔵とは？　任せられる4業務と安全設定

この記事のまとめ

Claude Coworkのブラウザ内蔵は、デスクトップアプリの中でブラウザが開き、Claudeがページを読み、押し、入力するところまで代わりに進める仕組みです。任せやすい仕事は、調査、請求書の回収、数値の取得、フォーム入力の4つに整理できます。安全に使うカギは、ログインさせるサイトの選び方と、承認のしかたを先に決めておくことです。

ウェブでの作業が必要なとき、サイドパネルにブラウザが開き、閲覧からクリック、入力までを任せられます。
普段使うブラウザとは別に動き、開いているタブや保存されたパスワードには自動でつながりません。
任せやすい4業務は、調査と情報収集、請求書と帳票の回収、ダッシュボードの数値取得、フォーム入力とポータル操作です。
行動前の許可確認や高リスクサイトのブロックはありますが、危険がなくなるわけではなく、承認と監督の設計が要ります。

ブラウザ内蔵の基本と仕組み

サイドパネルで動く操作の流れ

ブラウザ内蔵は、サイドパネルでウェブ操作を代わりに進めてくれる仕組みです。

Claude Coworkは、コードを書かなくても手順の多い仕事を任せられるエージェント機能です。書類や表計算といった日常の道具をまたいで、ファイルを読み、文章の下書きを作り、情報をまとめるところまで進めます（参照*1）。

ファイルや書類、ツールをまたぐ複雑な作業に向いた機能でもあります（参照*2）。私がこうした機能に注目するのは、「コネクタが用意されていないサービスへのアクセス」という現実的な壁を、ブラウザ操作の代行という形で突破しているからです。

そのCoworkのデスクトップアプリに、ブラウザが組み込まれました。ウェブサイトを使う必要がある仕事では、画面の横のサイドパネルにブラウザが開きます。

Claudeはそこでページを移動し、内容を読み取り、クリックし、入力まで行います。拡張機能を入れたり、設定を足したりする必要はありません（参照*3）。

動く場所はデスクトップアプリの中なので、ウェブ上の手作業を横で進めてもらいながら、自分は今の画面にとどまれます。サイトを開き直したり、画面を行き来したりする切り替えが減ります。依頼するかどうかは、その仕事がウェブ画面の操作を含むかどうかで見分けるのが一番シンプルな判断基準です。

自分のブラウザとの分離

内蔵ブラウザは、自分のブラウザとは完全に切り離されて動きます。

内蔵ブラウザは、毎日使っているブラウザとは別に動きます。Claudeは、開いているタブやブックマーク、保存されたパスワード、すでにログイン中のセッションへ自動ではつながりません。この境界があることで、余計な露出が減ります（参照*4）。

言い換えると、Claudeが触れるのは、内蔵ブラウザの中で渡した範囲だけです。普段のブラウザにためた情報が、そのまま作業へ持ち込まれる形にはなっていません。

ふだんの閲覧の環境と、作業用の環境が別々に保たれる形です。何をどこまで渡すかは、仕事のたびに自分で決められます。

ただし、分けて動くことと、安全であることは同じではありません。どのサイトにログインさせるかは利用者が選ぶため、渡した範囲の中では操作がそのまま進みます。危険が消えるのではなく、手が届く範囲が狭くなると考えるべきです。この点は、後述する運用ルールの話と直結します。

エージェント化という背景

ブラウザ内蔵が生まれた背景には、AIを「答えてもらう道具」から「仕事を代行させる道具」へと使い方を変えるという大きな流れがあります。

Claudeのエージェント機能をデスクトップへ持ち込むCoworkは、研究プレビューとして公開されました。AIを道具やデータにつなぐ規格であるモデルコンテキストプロトコル（MCP）は、月間1億回のダウンロードに達し、業界の標準になりました（参照*5）。

アクセンチュアは、2024年10月から12月に行った四半期調査で、AIから企業レベルの価値を得ている企業のうち、優れた財務実績と業務効率を示す企業は、エージェント型のアーキテクチャに投資している可能性が4.5倍高いとまとめました。この調査には、22業種20か国で収益5億ドル超の組織に所属する経営幹部3,450人と、経営幹部以外の従業員3,000人が参加しました（参照*6）。

平均的な企業では、全タスクの30%をAIが支えており、この割合は2年後に48%へ増えるという見通しです（参照*7）。

AIに渡す仕事は、答えをもらう使い方から、手順のある作業そのものへ移っています。ただし、業務で使うサービスのすべてに専用のコネクタが用意されているわけではありません。ブラウザ内蔵は、人がブラウザを開いて操作するしかなかった部分を引き受ける役割です。私の見方では、ここが最もリアルな活用の入り口になります。

任せられる4業務

業務1：調査と情報収集

1つ目は、公開されている情報を集めて、まとめるところまでの仕事です。

ここで挙げる4業務は、使いやすさの面から整理した代表例であり、公式に4種類と決まっているわけではありません。内蔵ブラウザなら、複数のサイトを順番に開いて、価格や条件、公開資料の要点を集められます。

集めた内容は、報告書のたたき台の形までまとめて受け取れます。開くサイトと集めたい項目を先に伝えておくと、戻ってきた内容を見比べる作業が短くなります。

グーグル Cloudは、企業向けのディープリサーチエージェントを、調べる力と分析する力を組み合わせた自律型のエージェントだと説明しました（参照*8）。

調査を任せるときも、出典の確認は人が行う前提です。私自身、Deep Research系の機能を使って調査レポートを出力させると、見た目は整っているのに根拠の弱い記述が混ざっていることを何度も経験しています。数字と引用元が合っているかを確かめてから、たたき台として使う。この手順は省けません。抜けている観点を足す余地も、この段階で残ります。

業務2：請求書と帳票の回収

2つ目は、毎月くり返す請求書や領収書の回収です。

企業にとって現実的な使い道は、地味な繰り返し作業にあります。ダッシュボードから数値を写す、毎月の請求書をダウンロードする、記録が一致するか確かめる、同じ形のフォームに記入する、といった仕事です（参照*4）。

取引先ごとのポータルに入り、当月分の請求書や領収書を集める流れは、この形に当てはまります。ファイル名の付け方や保存先まで決めておけば、毎月同じ手順で回せます。

対象の取引先と期間をあらかじめ伝えておけば、翌月からの依頼は短い言葉で済みます。集めた書類を、締めの日程に合わせて並べ直す形でも受け取れます。

一方で、支払いの実行のように取り消せない操作は、同じ扱いにはできません。回収までを任せ、支払いは人が決める。この線引きを最初に決めておくことが、安全に運用するための最低条件です。

業務3：ダッシュボードの数値取得

3つ目は、管理画面に並ぶ数値を読み取って、別の表へ写す仕事です。

Claudeは、フォームへの入力、ダッシュボードからの数値の取得、コネクタのないポータルでの作業を行えます。拡張機能も追加の設定も要らず、自分で選ばない限り、手元のブラウザから何も共有されません（参照*3）。

売上や広告費のように毎週見る数字を決めておくと、取得と転記の指示は短く済みます。前の期間との突き合わせまで頼めば、差の確認も同じ流れで進みます。転記先の表の形をそろえておけば、月ごとの並びも崩れません。

ただし、画面の読み取りには取り違えが起こり得ます。合計や単位が合っているかを、元の画面と照らして確かめる前提で使うべきです。桁や通貨の表示が変わる画面では、確認の手間を見込んで依頼を組んでください。

業務4：フォーム入力とポータル操作

4つ目は、コネクタが用意されていない社内外のポータルでの入力作業です。

申請フォームや取引先の管理画面には、外部からつなぐ口が用意されていないものがあります。こうした画面は、人が開いて入力するしかありませんでした。

内蔵ブラウザは、この入力や申請の手順を引き受けます。入力する項目と値の決め方を先に渡しておけば、同じ形の作業を続けて頼めます。

なお、名前の似たMicrosoft Copilot Coworkは、別の会社の別の製品です。マイクロソフトの資料によると、この製品は利用者がすでにサインインしているサイトを使い、端末上のマイクロソフト Edgeでウェブの作業を進めます。ブラウザのタブは利用者の端末で動き、資格情報とCookieも端末に残ります（参照*9）。

設計が違えば、任せ方の前提も変わります。送信の前に人が内容を確認し、確定の操作だけ自分で押す形にするのが、私がすすめる基本の構えです。

2つのブラウザの使い分け

選び方の判断基準

内蔵ブラウザ、Claude in Chrome、コネクタ連携の3つは、ログイン状態や作業方法に応じて選び分けられます。

自然言語の指示で実際のブラウザ操作を進め、途中で人が入らずに自動化する仕組みを、ブラウザ自動化ツールと呼びます（参照*10）。

内蔵ブラウザは、自分が作業を続けている間に、ウェブ上の仕事をClaudeへ任せるためのものです。例えば、報告書のための調査を集めたり、取引先のポータルから今月の請求書を集めたりできます。

Claude in Chromeは、すでに開いているページを、すでにログインしているアカウントで操作するためのものです（参照*3）。

コネクタが用意されている業務では、権限の設定で手綱を握れます。HubSpotの案内は、更新の前に必ず承認を求める設定を勧めており、コネクタのツール設定で書き込みツールを承認が必要に変えます（参照*11）。

選び方の要点は3つに整理できます。

自分のログイン状態が要るならClaude in Chrome
手を止めずに任せたいなら内蔵ブラウザ
専用のつなぎ役があるならコネクタ

設定切り替えとログイン移行

既定のブラウザと移せるログイン情報は、利用状況やOSによって変わります。

すでにClaude in Chromeを使っている人には、そのまま引き続きそれが既定になります。それ以外の人には、展開が届いた時点で内蔵ブラウザが既定として提供されます（参照*4）。

つまり、いま使っている状態によって、同じ依頼でも動く場所が変わります。使い分けたい場面では、設定で優先するブラウザを選び直せます。

サイトへのログイン状態を保つために、ログイン情報はサイトごとに移せます。macOSではChrome、Edge、Firefoxから、WindowsとLinuxではFirefoxから移行できます（参照*3）。

移せる範囲は、使っているOSと元のブラウザで変わります。まとめて全部を渡すのではなく、必要なサイトだけを選ぶ形になります。仕事で使うサイトが手元のブラウザとそろっているかは、移行の前に見比べられます。

安全設定と運用ルール

プロンプトインジェクション対策

ブラウザで動くエージェントでは、プロンプトインジェクションへの注意が欠かせません。

プロンプトインジェクションは、ページの中に紛れ込ませた指示で、エージェントを別の操作へ誘い出すやり方です。読ませるだけで成り立つため、閲覧そのものが入り口になります。

内蔵ブラウザは、Claude in Chromeと同じ安全策を使います。Claudeは、初めてそのウェブサイトで行動する前に許可を求めます。仕組みとして特定の高リスクサイトをブロックし、これから行う操作が利用者の元の指示と合っているかを照らし合わせます（参照*4）。

AI Now Instituteは、AnthropicのClaude Code CLIとOpenAIのCodex CLIで、遠隔からコードを実行できる概念実証を明らかにしました。攻撃に必要だったのは、Claude Codeのauto-mode、またはCodexのauto-reviewという設定だけでした（参照*12）。

この検証はコマンドラインの開発ツールが対象であり、Coworkの内蔵ブラウザで同じ被害が確認されたという報告ではありません。ただ、「閲覧するだけで指示が差し込まれる」というプロンプトインジェクションの性質は、ブラウザを操作するエージェント全般に共通するリスクです。許可の確認、ブロック、指示との照合を重ねればリスクは下がりますが、ゼロにはなりません。

ログイン情報とサイト選び

ログインさせるサイトは、扱う情報に応じて線引きできます。

銀行、メール、シングルサインオンのサイトは、利用者が選んで含めない限り、ログイン情報の移行の対象になりません（参照*3）。お金や本人確認に近い場所を、はじめから外している形です。

含めること自体はできますが、その判断は利用者がはっきり選んだときだけ働きます。「絶対に使えない」のではなく、「自分で選ばない限り渡らない」という違いです。機微な情報を扱うサイトは、本当に任せる必要があるかどうかをゼロベースで考えてください。

運用では、ログインさせるサイトを仕事に必要な範囲へ絞ると、手が届く先が小さくなります。移したログイン状態は保たれるため、作業が終わった後に何が残るかも含めて決められます。

取引先のポータルのように、扱う情報が限られたサイトから始める形も取れます。

承認と人による監督

重要な操作には、承認と人による監督が必要です。

マイクロソフトの資料によると、Copilot Coworkはメールの送信やTeamsへの投稿のような重要な操作の前に、承認を求める表示を出します。中リスクと高リスクの承認にはリスクの高さの表示が付き、影響の大きさを判断できます（参照*9）。

AIエージェントで広く使われる守り方は、重要とみなす行動の前に人の確認を求める仕組みです。この仕組みは有害な行動の可能性を下げますが、確認を求めすぎると使いやすさと自動化を損ないます。確認が続くと利用者は疲れ、よく見ないまま承認するようになり、本来の守りが弱まります（参照*13）。

人の確認があれば安全、とは言い切れません。どの操作を承認の対象にするかを絞り、途中で止められる状態にしておくことが監督の中身です。承認の回数が増えるほど、確認が形骸化するリスクも上がります。確認する回数と、確認する場面の重さは分けて設計すべきです。

組織導入時のガバナンス

組織で使うときは、有効化の判断と権限の管理をセットで考えます。

ウォートン校の案内は、提供開始の時点でClaude Coworkが最初から無効になっている点を挙げ、より広く有効にする方法を決める作業を進めているとしました（参照*14）。これは1つの教育機関の設定例であり、法人向け環境すべての既定を表すものではありません。

企業の状況に目を向けると、38%の企業にはエージェント型のワークフローに人が関わる仕組みがなく、37%にはエージェントの権限とアクセス制御がありません。エージェントの登録簿を持つ企業は44%にとどまります（参照*7）。私が生成AI導入支援をしていて感じるのも同じことで、プロンプトやモデル選定より先に、誰が何を承認するかという設計が決まっていないケースがほとんどです。

英国の情報コミッショナー事務局は、適切に実装されていないエージェント型のシステムがデータ保護上の被害のリスクを高めると指摘し、目的が明確でない、仕事に必要のないデータベースにつながっている、アクセスを守り活動を監視または停止し情報の共有を管理する手立てがない、といった例を挙げました（参照*15）。

ADPの社内分析は、生成AIのガバナンスについて、小規模企業の20%、中堅企業の半数、大企業の3分の2がプロセスを整えていると回答したとまとめました（参照*16）。

導入前に決める要点は、シンプルに3つです。

誰に使わせるか
どのデータへつなぐか
止める手段を誰が持つか

すでに整えたルールがある組織なら、ブラウザ内蔵の扱いをその中へ足す形で判断できます。逆に言えば、ルールがない状態で機能だけ有効にするのが最もリスクの高いやり方です。小さな業務から始めて、入力・出力・確認・修正・効果測定を一通り回し、ノウハウを貯めてから範囲を広げるのが現実的な進め方です。

おわりに

ブラウザ内蔵が加わったことで、ウェブ上の手作業を横で進めてもらいながら、自分は別の仕事を続けられます。調査、請求書の回収、数値の取得、フォーム入力といった繰り返しの作業は、依頼の形に置き換えられます。どこまで任せるかは、仕事の性質と取り消せるかどうかで分けるのが判断の基本です。

任せる範囲を先に決めることがポイントです。ログインさせるサイトを絞り、取り消せない操作は人が押す形にしておけば、便利さと安全の釣り合いを保てます。設定と運用のルールをそろえてから、任せる仕事を少しずつ広げる。この順番を守ることが、エージェント活用を「便利な実験」で終わらせないための条件です。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））