CodexのChrome拡張機能の使い方｜Web画面をAIで検証する手順

本記事を読めば、CodexのChrome拡張機能でログイン済みWeb画面を検証できるようになり、管理画面やSaaS連携の確認工数を削減できます。

ログイン後の管理画面は、通常のブラウザ検証だけでは確認が手作業になりがちです。AIzen株式会社は、Webアプリ開発と検証自動化支援の現場で、AIに任せる操作範囲と人が承認する範囲の分離を重視しています。

本記事では、Chrome拡張機能の使い方、権限管理、社内ツール検証時の注意点を整理します。

CodexのChrome拡張機能でできること

CodexのChrome拡張機能は、CodexがユーザーのChromeプロファイルを使って、ログイン状態が必要なWebサイトを扱うための仕組みです。公式情報では、LinkedIn、Salesforce、Gmail、社内ツールのようなサインイン済み状態が必要なブラウザタスクに使うと説明されています。

一方で、ローカル開発サーバーや公開ページ、サインイン不要の確認では、まずin-app browserを使うのが基本です。Chrome拡張は強い権限を持つため、必要な場面に絞って使います。

ログイン状態が必要なWeb操作

Chrome拡張機能が役立つのは、通常のブラウザでは再現しづらいログイン済み画面の確認です。たとえばSaaS管理画面、社内ポータル、CRM、予約管理、決済管理、Google Workspace関連画面など、認証後の表示や操作を確認したい場面です。

Codexは、画面上の情報を読み取り、操作手順を進め、結果を説明できます。ただし、入力や更新を伴う操作では、人が内容を確認する前提にします。特に顧客情報、請求情報、権限設定を扱う画面では、Codexに任せる操作を限定します。

in-app browserとの使い分け

in-app browserは、Codex内でWebページを確認するためのブラウザです。ローカル開発サーバー、ファイルベースのプレビュー、公開ページなど、Chromeのログイン状態を使う必要がない確認に向いています。

Chrome拡張は、Chromeプロファイルのログイン状態が必要なときに使います。使い分けは次のように整理できます。

目的	使う機能	理由
localhostのUI確認	in-app browser	Codex内で完結し、Chromeプロファイルを使わない
公開LPの表示確認	in-app browser	ログイン状態が不要
SaaS管理画面の確認	Chrome拡張	サインイン済み状態が必要
社内ツールの更新操作	Chrome拡張＋人の承認	操作影響があるため確認が必要

「どちらでもよい」と考えるのではなく、ログイン状態や権限を使う必要があるかで選びます。不要な場面でChrome拡張を使わないことが、安全な運用につながります。

管理画面検証で使える範囲

管理画面検証では、表示確認、入力フォームの確認、検索条件の確認、権限別表示の確認、エラー表示の確認などに使えます。たとえば「管理者でログインした状態で、ユーザー一覧にフィルターが表示されるか確認する」といった依頼が可能です。

ただし、削除、送信、公開、権限変更、請求処理のような操作は慎重に扱います。Codexに画面確認や手順説明を任せ、実際の更新前には人が確認する運用にします。検証用環境やテストアカウントを用意できる場合は、本番画面より先にそちらで確認します。

Chrome拡張機能の設定方法

Chrome拡張機能は、CodexのPluginsからChromeプラグインを追加し、Chrome Web Storeの拡張機能をインストールして接続します。2026年6月時点の公式情報では、セットアップ後にChrome拡張がConnectedと表示されることを確認します。

実際の画面表示や導線は更新される場合があります。導入時はCodex内のPlugins画面とChrome側の拡張機能画面を確認し、同じChromeプロファイルで有効化されているかを見ます。

Pluginsからの追加手順

公式情報では、CodexでPluginsを開き、Chromeプラグインを追加し、セットアップフローに従ってChrome拡張機能をインストールする流れが示されています。Chrome側では、拡張機能の権限プロンプトを確認して承認します。

社内導入では、個人任せでインストールさせるのではなく、利用目的、対象サイト、利用してよいChromeプロファイルを事前に決めます。拡張機能の権限は広いため、利用者へ「どの画面で使うか」「何をしてはいけないか」を共有します。

Chrome側の接続確認

セットアップ後は、Chromeのツールバーや拡張機能メニューからCodex拡張を開き、Connectedと表示されるか確認します。表示が切れている場合は、ChromeプラグインがCodex側で有効か、同じChromeプロファイルで拡張機能を有効にしているかを確認します。

複数のChromeプロファイルを使っている場合、拡張機能を入れたプロファイルと実際にログインしているプロファイルが違うことがあります。業務アカウントと個人アカウントを分けている会社では、この確認が特に重要です。

対象サイトでの動作確認

対象サイトでの動作確認は、読み取り中心のタスクから始めます。たとえば「この管理画面の現在の表示項目を要約して」「ユーザー一覧の検索条件を確認して」のように、更新を伴わない依頼で接続状態を確認します。

動作確認時は、Codexがどのサイトを使おうとしているか、許可プロンプトが表示されるか、想定外のページを読んでいないかを見ます。最初の数回は担当者が画面を見ながら実行し、操作範囲が適切かを確認します。

Webサイト権限の管理

Chrome拡張機能を安全に使うには、Webサイトごとの権限管理が欠かせません。公式情報では、Codexは新しいWebサイトを使う前に確認を求め、現在のチャットで許可、常に許可、拒否を選べると説明されています。

権限管理では、利便性だけでなく、機密情報や履歴へのアクセス可能性も考慮します。社内ツールで使う場合は、allowlistとblocklistを運用ルールとして管理します。

サイトごとの許可設定

Codexが新しいサイトを使うときは、ホスト単位で許可を確認します。現在のチャットだけ許可するのか、今後も許可するのか、拒否するのかを選びます。初回検証では、現在のチャットだけ許可する形が安全です。

常に許可する設定は、利用頻度が高く、操作範囲が明確なサイトに限定します。顧客情報や請求情報を扱うサイトは、常時許可ではなく、必要なタスクごとに確認する運用が向いています。

allowlistとblocklistの管理

Computer Use settingsでは、allowlistとblocklistを管理できます。allowlistはCodexが再確認なしで使えるドメイン、blocklistはCodexに使わせないドメインとして扱います。

社内では、allowlistに入れる基準を決めます。たとえば検証用環境、社内のデモ環境、読み取り専用のレポート画面などは候補になります。一方で、本番決済画面、個人メール、管理者権限画面などは、blocklistや都度確認の対象にします。

ファイルURL許可の確認

Chromeタスクでローカルファイルのアップロードが必要な場合、Chromeの拡張機能詳細画面で「Allow access to file URLs」を有効にする必要があります。公式情報でも、ファイルアップロードが必要な場合の確認項目として説明されています。

ただし、ファイルURL許可は必要なタスクに限定して扱います。アップロード対象ファイルの保存場所、ファイル名、内容、送信先を事前に確認し、機密ファイルを誤って扱わないようにします。利用後に設定を戻す運用も検討します。

社内ツール検証の注意点

社内ツールでChrome拡張機能を使う場合、個人利用よりも権限管理が重要です。Chromeプロファイル、入力操作、更新操作、機密画面の扱いを決めておかないと、便利さより確認リスクが大きくなります。

AIzenの検証自動化支援では、まずテスト環境、検証アカウント、操作許可範囲を整理します。本番画面で直接試すのではなく、影響範囲を限定した状態でAI検証を導入します。

個人プロファイルと業務プロファイル

Chrome拡張機能は、インストールしたChromeプロファイルのログイン状態を使います。個人プロファイルに拡張を入れたまま業務画面を扱うと、不要な履歴や個人アカウントの情報が混ざる可能性があります。

業務利用では、業務用Chromeプロファイルを分け、対象サイトに必要なアカウントだけでログインします。複数会社や複数顧客を扱う場合は、プロファイルやアカウントの切り替えルールを明文化します。

入力・更新操作の承認ルール

入力や更新を伴う操作では、Codexにそのまま実行させるのではなく、承認ポイントを置きます。たとえばフォーム入力はCodexに下書きさせ、送信ボタンを押す前に人が内容を確認する運用にします。

更新操作の影響範囲は、画面ごとに違います。検索条件の変更、メモの追加、ステータス更新、メール送信、権限変更、削除ではリスクが異なります。操作ごとに「Codexが実行してよい」「人が確認してから実行」「実行不可」を分けます。送信・削除・権限変更は、原則として人の最終確認を挟む操作として扱います。

機密画面を扱う際の確認

機密画面では、Codexが読む情報がスレッドの文脈に含まれる可能性があります。公式情報でも、OpenAIが拡張機能からChrome操作の完全な別記録を保存するわけではない一方、Codexの文脈に入ったページ情報、スクリーンショット、ツール呼び出し、要約などは処理対象になると説明されています。

そのため、秘密情報、個人情報、顧客情報、認証情報を含む画面では、入力前に必要性を確認します。画面全体を読ませるのではなく、テスト環境やマスキング済みデータを使う、必要な項目だけを確認する、といった運用が現実的です。

弊社エンジニアからのコメント：

Chrome拡張を使った検証では、最初に「AIに触らせる画面リスト」と「触らせない画面リスト」を作るだけで運用が安定します。特に本番管理画面は、表示確認までは許可しても、送信・削除・権限変更は人が最後に確認するルールを置くと、開発速度と安全性を両立しやすくなります。

検証自動化の運用ルール

Chrome拡張機能を使った検証自動化は、対象画面、操作範囲、承認フロー、結果の残し方を決めてから始めます。単発の便利操作ではなく、開発フローの中に組み込むことで効果が出ます。

運用では、in-app browserで足りる確認はin-app browserへ、ログイン状態が必要な確認だけChrome拡張へ分けます。不要な権限利用を減らすことが、継続利用の前提になります。

テスト対象画面の選定

テスト対象画面は、利用頻度、変更頻度、業務影響で選びます。ログイン後のダッシュボード、顧客一覧、予約一覧、設定画面、レポート画面など、確認工数が多く、表示崩れや権限表示の影響が大きい画面から始めます。

最初は、読み取りと表示確認に限定したチェックリストを作ります。たとえば「ログイン後に一覧が表示される」「フィルターが使える」「権限のないメニューが表示されない」のように、判断基準を明確にします。

更新操作前の承認フロー

更新操作前には、Codexが行う操作内容を一度説明させます。「どの画面で、どの項目に、何を入力し、どのボタンを押すか」を出力させ、人が確認してから進めます。

承認フローは、テスト環境と本番環境で分けます。テスト環境では一部操作を許可し、本番環境では送信や削除を禁止するなど、環境ごとのルールを明確にします。AGENTS.mdや社内手順書にも反映しておくと、複数メンバーで運用しやすくなります。

検証自動化支援に相談する範囲

検証自動化で相談すべき範囲は、Chrome拡張の設定だけではありません。テスト対象画面、検証用アカウント、データ作成、操作許可、証跡の残し方、失敗時の対応まで含めて設計します。

AIzen株式会社では、Webアプリ開発、管理画面改善、Codexを使ったブラウザ検証、社内ツール検証フローの設計を支援できます。既存の手動確認を棚卸しし、AIに任せる確認と人が承認する操作を分けるところから相談できます。

まとめ

CodexのChrome拡張機能は、ログイン済みWeb画面をCodexが扱うための機能です。要点は次の3つです。

• ログイン状態が不要な検証はin-app browserを優先し、Chrome拡張は必要な場面に絞る
• サイトごとの許可、allowlist、blocklist、ファイルURL許可を管理する
• 社内ツールでは業務プロファイル、承認フロー、機密画面の扱いを明確にする

AIzen株式会社では、CodexのChrome拡張機能を使ったWeb画面検証、管理画面テスト、SaaS連携確認、社内ツール検証自動化を支援しています。手動検証の工数を減らしつつ安全に運用したい場合は、無料相談からご相談いただけます。