Codex に UI 修正を任せたあと、「画面も見て直して」と頼みたくなる場面は多いです。ところが、ブラウザ操作を雑に渡すと、どの URL を見たのか、どの viewport で再現したのか、通常の Chrome profile を使ったのか、画面上のコメントをどこまで差分に反映したのかが曖昧になります。
この記事では、2026年8月15日時点の OpenAI 公式ドキュメントを前提に、Codex browser use を built-in browser 中心の UI 検証レーンとして使う方法を整理します。既存 Chrome profile を使う作業は Codex Chrome extension ガイド、外部サイトを読む通信境界は Codex internet access 安全運用ガイド、作業ごとの sandbox / approval は Codex config profile 設計ガイド、最後の差分受け入れは Codex レビュー完了ゲート設計ガイド に分けています。Codex を Claude Code とどう使い分けるかから決めたい場合は Claude Code vs Codex CLI 比較 を先に読むと入口が揃い、browser use を自社クライアントへ埋め込む設計は Codex App Server ガイド が隣接レーンです。
今回扱うのは、built-in browser、localhost / public page の確認、画面コメント、Developer mode、site permission、検証ログです。
先に結論: built-in browser は閉じた UI 検証レーンにする
OpenAI の Browser docs では、ChatGPT desktop app の built-in browser は通常の browser profile とは別状態で動き、既存 tab や既存 session を自動共有しないと説明されています。一方、Chrome extension は既存 Chrome profile やログイン済み tab が必要なときに使うものです。
実務では、最初に次のように分けます。
| 使うもの | 向いている作業 | 避ける使い方 |
|---|---|---|
| built-in browser | localhost、公開ページ、ログインなしで再現できる UI 確認 | 既存 Chrome のログイン状態が必要な管理画面 |
| built-in browser + 画面コメント | overflow、余白、tooltip、empty state などの狭い UI 修正 | 10画面以上をまとめて直す依頼 |
| Developer mode | console error、network failure、DOM / style の切り分け | 単なる見た目確認の常時利用 |
| Chrome extension | 既存 Chrome profile、ログイン済み session、開いている tab が必要な作業 | built-in browser で足りる localhost 確認 |
判断基準は単純です。
built-in browser で足りる:
- localhost や公開ページを見れば再現できる
- 新しい browser state で問題ない
- 既存 Chrome tab / cookie / extension に依存しない
- UIコメントと差分レビューを同じ task で閉じたい
Chrome extension に回す:
- 既存 Chrome profile のログイン状態が必要
- 対象 tab や Chrome extension が必要
- 社内SaaSや管理画面の active account を人間が確認する必要があるbuilt-in browser は、普段使いの Chrome を渡さない点が強みです。localhost の画面崩れ、公開ページの見た目確認、ログインを新しく作ってよい staging UI は、まず built-in browser で閉じる方が差分も権限も小さくなります。
依頼文は URL、状態、確認観点、停止条件まで書く
悪い依頼はこうです。
@Browser で画面を見て直してこれでは、どの route、どの viewport、どの state を見ればよいのか分かりません。Codex がトップページだけを開いて「問題なし」と判断しても、人間が見てほしかったのは mobile の error state かもしれません。
私は browser use を使わせるとき、依頼文を次の粒度にします。
Use @Browser for this local route only:
http://localhost:4321/settings/billing
State:
- viewport: mobile width around 390px
- account: demo tenant
- tab: Usage
- data state: over quota warning is visible
Check:
- the plan selector does not overflow
- the warning text wraps without covering the CTA
- no horizontal scroll appears
Stop:
- do not change billing logic
- do not submit forms
- after editing, reopen the same route and report what changedポイントは、画面を見る前に「どの状態を正解として見るか」を固定することです。UI の崩れは URL だけでは再現できません。viewport、account、loading / empty / error / success、feature flag、seed data まで含めて渡す方が、修正もレビューも速くなります。
画面コメントは「どこが悪いか」ではなく「どう収めるか」を書く
Browser docs では、rendered page を見ながら要素や領域へコメントを残し、そのコメントをもとに修正を依頼できると説明されています。これは UI 修正ではかなり効きますが、コメントが曖昧だと結局プロンプトと同じ問題になります。
弱いコメント:
ここが変強いコメント:
Mobile 390px で、このラベルが2行目の値に重なっています。
カードの高さは固定し、label を1行で入らない場合だけ折り返してください。Hover tooltip が chart の右端からはみ出しています。
cursor の右側に出せない場合は左側へ反転し、plot area の内側に収めてください。画面コメントは感想ではなく、修正後の制約を書く場所です。特に次の4つは入れます。
- どの viewport / state で起きているか
- 何が期待状態と違うか
- 変えてよい範囲はどこか
- 変えてはいけない構造は何か
私は1回の browser use で扱うコメントを2個から5個に絞ります。10個以上まとめると、ほぼ別タスクです。「この route の mobile overflow だけ」「この table の empty state だけ」のように切った方が、差分が小さくなります。
Developer mode は console / network / DOM が必要なときだけ上げる
Configuration Reference では、requirements.toml で features.browser_use_full_cdp_access を false にすると、Browser Developer mode を含む full Chrome DevTools Protocol access を無効化できると説明されています。これは、Developer mode が単なる画面確認ではなく、browser の内部状態へ深く入る権限であることを示しています。
私は Developer mode を常時オンの万能確認として扱いません。
| 目的 | Developer mode を使うか | 理由 |
|---|---|---|
| button の余白や文言崩れを見る | 使わないことが多い | screenshot と画面コメントで足りる |
| console error を特定する | 使う | stack trace と runtime error が必要 |
| API 失敗を切り分ける | 使う | network status / response timing が必要 |
| hydration mismatch を見る | 使う | DOM と console の両方を見る |
| 本番管理画面を広く調査する | 原則避ける | sensitive state を巻き込みやすい |
依頼文はこうします。
Use @Browser Developer mode only on http://localhost:4321/dashboard.
Inspect console errors and failed network requests after opening the Reports tab.
Do not inspect cookies, storage, or other tabs.
Summarize the failing request URL, status, and the code file you changed.Developer mode を使う価値は、画面を眺めることではなく、再現した症状を証拠に落とすことです。console error、network status、DOM の applied style、performance trace のどれを見たいのかを先に指定します。
local dev server は branch と port まで固定する
UI 修正でよくある失敗は、dev server が古いまま、別 port、別 branch、別 cache の画面を見てしまうことです。built-in browser を使うなら、ブラウザ操作の前に実行環境を固定します。
Before opening @Browser:
1. run the existing dev server command if it is not already running
2. report the local URL and port
3. confirm the branch name
4. open only that local URLAstro や Next.js のようなローカルサイトでは、port がずれるだけで別の作業ツリーを見ていることがあります。特に Codex で worktree を分けている場合、localhost:3000 に root repo の dev server が残っていると、今の branch の修正を見ていないのに「確認済み」になります。
私は UI 確認後のログを次の形で残します。
browser_verification:
branch: agent/fix-settings-overflow
server: pnpm run dev
url: http://localhost:4321/settings/billing
viewport: 390x844
state: over quota warning
checked:
- no horizontal scroll
- console has no new error
- CTA remains visible
not_checked:
- production billing submitここまで残すと、Codex の browser use は「見たと言っている」ではなく、「この状態を確認した」に変わります。
site permission は作業用 host に寄せる
built-in browser でも、Web サイトの内容は未信頼入力です。Browser docs では、ページ上の指示は misleading or malicious になり得るため、サイトと action を確認する前提になっています。website permission はその site と対話できる許可であって、ページ内容を信頼済みにするものではありません。
私は site permission を次のように分けます。
browser_access_policy:
allowed_for_ui_debug:
- localhost
- 127.0.0.1
- staging.example.com
ask_each_time:
- app.example.com
- docs.example.com
blocked:
- admin.example.com
- billing.example.com
- accounts.example.comlocalhost と staging は継続許可しやすい一方、本番 admin、billing、account settings は毎回止めます。built-in browser は Chrome profile と分かれていても、サインインすればその browser state 側に権限ができます。分離されているから安全、ではなく、分離された作業用 browser として狭く使うのが正しいです。
組織導入では、必要に応じて requirements.toml 側でも機能の上限を決めます。
[features]
in_app_browser = true
browser_use = true
browser_use_external = false
browser_use_full_cdp_access = falseこの例では built-in browser の利用は残しつつ、外部 browser と full CDP access を閉じています。すべての組織でこの設定が正解ではありませんが、「UI 確認は許すが、既存 Chrome profile と深い DevTools 操作は別承認にする」という方針を configuration として表現できます。
Chrome extension と internet access と混ぜない読み順を作る
Codex browser use を調べる人は、built-in browser、Chrome extension、agent internet access、Computer Use、plugin を混同しやすいです。実務では、次の順に読むと迷いにくいです。
- 画面確認だけなら、この記事の built-in browser で閉じる
- 既存 Chrome profile が必要なら、Codex Chrome extension ガイド に進む
- 外部 docs や issue を読む通信を広げるなら、Codex internet access 安全運用ガイド を読む
- 作業ごとの sandbox / approval を変えるなら、Codex config profile 設計ガイド を読む
- 最後に diff を受け入れる前に、Codex レビュー完了ゲート設計ガイド で確認する
この順番にすると、「画面を見せたいだけなのに Chrome profile を渡す」「docs を読ませたいだけなのに browser permission を広げる」「UI 確認が終わっていないのに PR を受け入れる」といったズレを減らせます。
まとめ: browser use は確認作業を小さく切るほど強い
Codex browser use は、UI 確認、再現、画面コメント、Developer mode を同じ作業の中に入れられる便利な機能です。ただし、便利だからといって「ブラウザで全部見て」にすると、対象ページ、状態、権限、確認結果がぼやけます。
私なら、built-in browser はまず localhost と公開ページの UI reproduction 用に使います。Chrome profile が必要な作業は Chrome extension に分け、console / network / DOM が必要なときだけ Developer mode を承認します。
依頼文には URL、viewport、state、確認観点、停止条件を書いてください。最後に、どの branch のどの local URL を見て、何を確認し、何を確認していないかを残す。これだけで、Codex の browser use は「雰囲気の目視」ではなく、レビュー可能な検証工程になります。