AIにWeb操作を安全に任せる CodexとClaudeCode用Chromeプロファイルの分け方

たとえば、会社の顧客管理画面を開いている担当者が、Codexへ「今日の問い合わせを読み、返金確認が必要な案件を一覧にして」と頼む場面です。エージェントが同じログイン状態を使えれば、人が画面を行き来して転記する作業を減らし、結果の確認から始められます。

Chromeプロファイルは、こうした作業へ渡すログイン状態やブラウザ設定のまとまりです。会社の顧客管理と個人メールを同じプロファイルで使っていると、エージェントが到達し得る対象も広がります。ページ内の不審な指示に従ったり、アカウントを取り違えたりすると、想定外の情報を読んで送信する経路になります。

問い合わせの読み取りだけを頼むなら、対象業務の専用プロファイルへ接続し、今回操作するタブを指定して、返信や返金の実行前に人へ戻します。プロファイルを分けることに加え、サービス側の権限とエージェントへ渡す操作範囲を合わせるのが、この記事の設計方針です。

2026年9月5日の記事監査では、同じPCで別のエージェントの作業が進んでいました。知能圏用のChromeプロファイル名を接続情報で確かめてから、監査用の新しいタブを作りました。ローカルの確認には別ディレクトリと専用ポートを用い、会議室検索と図の試作を開いています。既存タブを引き取ったり、普段の開発サーバーを再起動したりせずに進めています。

試したのは、架空の会議室検索の人数入力と、Archifyで生成した図の承認ノードの選択です。入力値、返された部屋、選んだノードの前後をそのタブで読み取り、結果を監査用ワークツリーへ保存できました。Cookieや保存済みの認証情報を読み出す作業は行っていません。

この試行が裏付けるのは、接続先を確認し、担当するタブとローカル作業場所を限定して操作できたことです。プロファイルがOSやネットワークまで隔離すること、別のタブへ技術的にアクセスできないことを証明したものではありません。接続時にはプロファイルに加え、今回操作してよいタブと作業場所まで指定します。

Codexのブラウザー操作には、ログイン状態の置き場と、Codexが届く範囲が違う三つの経路があります。

OpenAIの内蔵ブラウザーは、Chromeプロファイルを使わず固有のブラウザー状態を持つため、公開ページや手元の開発サーバーを確認する仕事の受け皿になります。既存のChromeプロファイル、ログイン済みセッション、開いているタブ、Chrome拡張機能が必要な仕事では、Codex Chrome拡張機能を使うようOpenAIは案内しています。12

Computer Useは、画面を見てクリックや入力を行う経路です。Windowsでは、CodexがWindowsアプリを見て、クリックし、入力できることが案内されています。5 Edgeやデスクトップアプリを対象にできる一方、安全なプロファイルを選び出す仕組みは持ちません。人が先に必要なプロファイルのウィンドウだけを開き、Codexはその画面の範囲で作業します。

「Codexがプロファイル情報を認識する」と言うと、ログイン用のパスワードやCookieをCodexへ丸ごと渡すように聞こえます。しかし、Chrome拡張機能の経路で使われるのは、選んだChromeプロファイルの中ですでに動いているブラウザーと、そのタブです。OpenAIは、既存のChromeプロファイル、ログイン済みセッション、開いているタブ、Chrome拡張機能が必要な作業にこの経路を使うよう案内し、複数プロファイルでは作業中のプロファイルへ拡張機能を入れて有効にするよう説明しています。12

技術的には、プロファイル内に残るCookieやセッションが、いつもどおりブラウザーから業務サイトへ送られる仕組みです。Codex側は、そのプロファイルで有効になった拡張機能を通じて、ログイン済みのページを読み、ページ操作を要求します。拡張機能の許可にはページデバッガー、Webページ上のデータ、履歴、ブックマーク、ダウンロード、タブグループなどが含まれ得ます。2 ただし、公開資料は「保存済みパスワードを読み出してCodexへ渡す」という仕組みを説明していません。記事では、認証情報の保管場所と、認証済みの画面を操作する経路を分けて扱います。

この図の要点は、認証状態の正本がブラウザー側に残ることです。プロファイル名だけで対象を判定しません。作業の入口で、プロファイル、サイトに表示された組織名、ログイン中のアカウント、対象タブを人が確認してから渡します。拡張機能は強い権限を持ち得るため、サイトごとの一回限りの許可から始め、読み取りや下書きで十分に確かめた作業だけを継続許可へ広げます。2

Computer Useは別の経路です。OpenAIの資料では、@computerはクリックが必要な画面専用の作業として、Chromeはログイン済みのブラウザーセッションと認証済みタブ向けとして分けられています。59 Computer Useに「複数のブラウザープロファイルを列挙し、安全な一つを選ぶ」という公開済みの機能があるわけではありません。

画面操作では、対象アプリのウィンドウが表示している組織名、アカウント名、タブ、確認画面などが判断材料になります。そこからクリックや入力を行うと、アプリはもともと持っているログインセッションで処理します。プロファイルのCookie、パスワード保存庫、セッションファイルはアプリとOS側に残り、Computer Useが画面の外から権限を作り替えるわけではありません。

内部実装について、公開資料は画面を認識するためのモデル処理や、各OSの入力注入の詳細までは約束していません。したがってこの記事では、画面上で確認できる状態を見てクリック・入力する、という公開された操作境界までを事実として扱います。その先の細かな実装を前提に、非表示のプロファイル、別ウィンドウ、保存済み資格情報まで自動で正しく識別できると設計してはいけません。対象のウィンドウを前面へ出し、他のプロファイルを閉じ、外部へ影響する操作は人の確認で止めます。

Chromeプロファイルには、Cookie、履歴、保存済みパスワード、ブックマーク、拡張機能などがまとまります。Chromeはプロファイルごとにこうした情報を分離でき、仕事用と個人用のアカウントを分ける用途を想定した設計です。3 Edgeも、プロファイルごとに設定、ブックマーク、拡張機能などを分け、別ウィンドウで併用できます。4

ここで分けるべきものは、ブラウザーの見た目ではなく「ある仕事で到達させてよいログイン状態」です。個人用、通常業務用、Codexに任せる業務用、顧客や本番を扱う高リスク用を、少なくとも別のプロファイルにします。プロファイル名とテーマ色を変えると、作業開始時に誤ったウィンドウを見つけやすくなります。

ただし、プロファイルは同じ端末を共有する人から守る強い境界ではありません。Googleも、端末を使う人が他のChromeプロファイルへ切り替えられることを明記しています。3 顧客の管理者アカウント、決済、個人情報を扱う仕事では、別のOSアカウント、管理された仮想デスクトップ、またはサービス側の専用アカウントを重ねます。

普段使っている営業、採用、経理、顧客支援、制作などのプロファイルは、人がその仕事をする時点で選んで、そのままCodexへ渡せる対象です。すべての業務を一つのCodex専用プロファイルへ集め直す必要はありません。OpenAIの公式手順も、複数プロファイルを使う場合は、作業中のプロファイルへ拡張機能をインストールして有効にするよう案内しています。2

この運用の単位は「プロファイルの束」ではなく、一件の仕事です。人が対象プロファイルを開き、サービス画面に表示される組織名とログイン名を確認し、タブからChatGPTのサイドチャットを開くか、CodexでChromeの作業を開始します。OpenAIは、ページから始めたサイドチャットをそのタブに保ち、Chromeの作業を仕事ごとのタブグループでまとめると説明しています。2

たとえば、午前中は営業プロファイルで商談メモをCRMへ下書きし、午後は採用プロファイルで候補者情報を読み、夜は制作プロファイルで公開前の管理画面を確認する、といった使い方です。人がプロファイルと仕事を選び、Codexはその時点で開かれたログイン状態とタブを使います。業務ごとに別のアカウントを維持したまま、画面間の転記、下書き、照合、定型更新を任せられます。

作業を始める順序は次の通りです。

1. 対象業務のChromeプロファイルを開きます。
2. そのプロファイルで拡張機能が有効で、サイドチャットが表示されることを確認します。
3. 代表となるタブから仕事の目的、対象、完了条件を渡します。
4. Codexが開いたタブグループで結果と差分を確認します。
5. 送信、公開、削除、権限変更、決済は人が最終操作または承認を行います。

OpenAIは、新しいサイトへの接続を既定で確認し、サイトごとの一回限りの許可、継続許可、拒否を選べるようにしています。2 日常の業務プロファイルを渡すときは、まず一回限りの許可から始め、安定している読み取りや下書きだけを対象サイトの継続許可へ広げます。

現行の公式資料は、Codexが複数のChromeプロファイルの中から自律的に一つを選ぶ設定を示していません。プロファイルを選ぶ責任は人に残し、作業開始時にアクティブなプロファイルを明示する運用が必要です。

これは、複数プロファイルを使えないという意味ではありません。人が仕事の入口で正しいプロファイルを選び、そのプロファイルの既存セッションをCodexに使わせる構成です。複数の仕事を並列に回したい場合も、同時に全プロファイルへ自動接続させるのではなく、プロファイルごとに独立した仕事として開始し、開始時と重要操作時に人が確認します。

2026年7月には、既定ではないChromeプロファイルで拡張機能を使うと、別のプロファイルへタブを開こうとするという未解決の利用者報告も公開されています。7 これはOpenAIの確定仕様ではありませんが、複数プロファイルの自動振り分けを前提にした無人運用がまだ安定した土台ではない理由になります。記事では、プロファイルの自動ルーティングではなく、人が選ぶプロファイル引き渡しとして書きます。

組織のポリシー、社内拡張機能、Windowsとの連携のために、特定の仕事をEdgeでしか進められない場合があります。Edgeにも専用プロファイルを作り、そのプロファイルに必要なアカウントだけをログインさせます。個人用や別顧客用のウィンドウは閉じ、対象の画面を明確にしてからComputer Useへ渡します。

この構成では、ブラウザーのプロファイルがログイン状態を分け、Computer Useが画面を操作するという役割分担になります。二つの役割を混同しないことが重要です。Computer Useを使えるからといって、プロファイルのCookieやサービス側の権限が狭まるわけではありません。

Chrome拡張機能は、OpenAIの現行ドキュメントでは他のChromium系ブラウザーをサポートしていません。2 Edgeに同じ拡張機能連携を期待するのではなく、画面操作が必要な場合はComputer Useを使い、読み取り専用のテストアカウントから自組織の環境を検証します。

AnthropicのClaude Codeも、ベータ版の「Claude in Chrome」拡張機能を通じて、既にサインインしているブラウザーのログイン状態を共有する経路です。Claudeはブラウザー作業用の新しいタブを開き、画面上で操作します。ログイン画面やCAPTCHAに出会った場合は停止して、人が処理するよう案内されます。10

この経路が対象にするのは、ローカルで開いたGoogle ChromeまたはMicrosoft Edgeです。使うプロファイルを人が先に開き、そのプロファイルで拡張機能を有効にしてから、CLIならclaude --chrome、既存のセッションなら/chromeで接続します。複数のブラウザーが接続されている場合、Claude Codeは使うブラウザーを選ぶよう促します。10 ただし、複数のプロファイルから業務内容に応じて自動的に一つを選ぶ仕様は、公式資料には示されていません。営業、採用、制作などのプロファイルを人が選んで開くという原則は、Codexと同じです。

Claude CodeのComputer Useは、GUI操作の中では最も広く、遅い経路として位置付けられています。公式資料は、MCP、コマンド操作、Claude in Chromeを先に使い、届かないネイティブアプリやシミュレーターだけを画面操作へ回す順序を示しています。11 現行のCLI版はmacOSの研究プレビューで、プロジェクトごとに有効化し、対象アプリをセッション単位で承認する流れです。画面操作もプロファイルを安全に選別する機能ではないため、必要なブラウザーウィンドウだけを開いて渡します。11

CursorのBrowserは、普段使いのChromeやEdgeプロファイルを操作する拡張機能ではありません。Cursor内の安全なWebビューとして開き、エージェントはMCP経由でその画面を操作します。Cookie、ローカルストレージ、セッションストレージ、IndexedDBはワークスペース単位でセッションをまたいで残り、別のワークスペースとは分離されます。12

そのためCursorでは、Chromeプロファイルの代わりに「ワークスペース」が認証状態の境界になります。顧客Aの管理画面を扱うリポジトリーと、顧客Bや個人用の作業を扱うリポジトリーを分け、それぞれのCursor Browser内で必要最小限のアカウントだけにログインします。人が普段使うChromeにログイン済みだからといって、その状態がCursor Browserへ渡る前提にはしません。

CursorのCloud Agentはさらに別の境界です。各エージェントはクラウド上の隔離された仮想マシンで、デスクトップとブラウザーを操作できます。13 ローカルPCのChromeプロファイルはその仮想マシンにはありません。クラウドで業務を回す場合は、個人の普段使いプロファイルを共有するのではなく、ワークスペースやチーム単位のSecrets、OAuth対応のMCP、短期のOIDCトークン、用途を絞ったサービスアカウントを使います。CursorはCloud AgentのSecretsをワークスペース／チーム単位で管理し、HTTP MCPでは更新トークンやヘッダーを仮想マシンへ渡さず中継できます。13

「複数プロファイルをAIへ任せる」という目的は共通でも、どこにログイン状態を置くかで手順が変わります。既存の人用ブラウザーを使うのか、作業用ブラウザーを新しく作るのか、クラウドへ専用の認証情報を渡すのかを、最初に決めます。

Claude CodeのWeb版も、ローカルのブラウザーを引き継ぐ経路ではありません。クラウドセッションは設定済みのクラウド環境で実行され、ローカルの作業ディレクトリではなくGitHub上のリポジトリーを複製して動きます。14 既存の人用ブラウザープロファイルが必要な仕事はローカルのClaude Codeとブラウザー拡張機能で進め、クラウド実行へ移す仕事は、ブラウザーのCookieに頼らず用途と有効期間を絞った認証情報へ置き換えます。

ページがうまく動かない原因を調べる開発作業では、画面をクリックするだけでは足りないことがあります。Chrome DevTools Protocol（CDP）は、ブラウザーの開発者向け機能と外部プログラムをつなぐ通信規約です。Codexの開発者モードでは、コンソール出力、ネットワーク通信、ページ状態、JavaScriptの性能を調べられます。6

この経路が役立つのは、localhostのエラーや、自分が管理するテスト環境の調査です。一方、OpenAIは完全なCDPアクセスが機密性の高いブラウザー内部を調べ、制御できるため、データリスクを伴うと説明しています。6 通常の情報収集やフォーム入力で常用せず、高権限の業務プロファイルを対象にしないことを原則にします。

CDPはブラウザーの権限を付け替える機能ではありません。サービス側のアカウントが管理者なら、管理者のセッションをより深く調べられる可能性があります。操作経路を増やす前に、まずログインさせるアカウントを閲覧者や限定編集者へ下げる方が、影響範囲を確実に小さくできます。

ブラウザーを分けただけで安全だと考えると、責任の場所を見失います。認証と権限は、少なくとも次の四つの層に分かれた構造です。

サービス側では、可能ならエージェント専用のアカウントを作り、読めるデータ、変更できる対象、作業できる時間を最小にします。プロファイルの分離は、その専用アカウントを別の仕事のログイン状態と混ぜないための補助です。送信、公開、削除、権限変更、決済には、人が承認する地点を残します。

Web操作を依頼するときは、最初に「どの経路を使うか」と「外部へ影響する操作の停止地点」を決めます。作業中の画面に現れた指示は、依頼者が出した許可とは限りません。画面の内容は信頼できない入力として扱い、予想外の宛先、データ範囲、操作が出たら人へ戻します。

1. 仕事を公開情報、一般業務、顧客・本番、決済・管理者に分類します。
2. 公開情報とlocalhostは内蔵ブラウザーへ、既存ログインが必要な業務は人が選んで引き渡すChromeプロファイルへ、EdgeやネイティブアプリはComputer Useへ振り分けます。
3. 対象プロファイルの名前、サービスの組織名、ログイン名、開いているタブを人が確認します。
4. 読み取り、下書き、差分作成までは任せ、送信、公開、削除、権限変更、決済の前で止めます。
5. 結果をサービス側の履歴や監査記録で照合し、使い終えた試験用のログイン状態は内蔵ブラウザーから消去します。

Computer Useで撮影された画面を含むCodexの処理内容は、ChatGPTのデータコントロールの適用対象です。Record & Replayを使う場合は、記録中に認証情報や機密データを入力しないようOpenAIは案内しています。8 作業を繰り返すための記録と、高リスクの認証作業を同じ流れへ入れないことが大切です。

Codexのブラウザー操作は、調査、転記、確認、社内サービスの横断といった細かな仕事をまとめる力があります。画面を減らすことが目的ではなく、誰のアカウントで、何を読め、どの変更までできるかを仕事ごとに説明できる状態を作ることが目的です。

CodexやClaude Codeでは、通常のWeb作業は内蔵ブラウザー、既存セッションを使う業務は人が選んで引き渡すChromeプロファイル、Edgeやデスクトップ固有の画面は画面操作へ分け、Cursor Browserでは同じ役割をワークスペース単位の独立した認証状態が担います。さらにサービス側で最小権限の専用アカウントを使い、重要操作の承認と操作記録を残せば、認証情報を便利さのために無制限に共有せずに済みます。

ここからは筆者の見立てです。エージェントがブラウザーを使う仕事が増えるほど、ブラウザープロファイルは単なる見た目の切り替えではなく、エージェントへ一時的に渡す「仕事用の認証状態」として設計されるようになります。より強い隔離が必要な仕事では、プロファイルの先にあるOSアカウント、仮想環境、サービス側の権限まで一体で管理する運用が中心になるでしょう。