Codex CLIの5月更新では、自動レビュアーエージェントと並んで「in-app browser」が追加された。Codex自身がローカル開発サーバーやファイル直結ページを操作できるブラウザで、UIをポチポチして再現する種類のバグ——「ボタン押したあと表示が崩れる」「特定の入力でフォームが固まる」といったやつ——を、Codexが自走で踏みに行けるようになった。同時にリリースされた自動レビュアーと組み合わせると、攻めと守りが噛み合った設計になっている点も興味深い。
in-app browserは「Codexがバグを再現する手段」を一段増やす
これまでCodexにフロントエンドのバグを直させようとすると、人間がブラウザを開いて手順を記録し、それをスクリーンショットなりテキストなりでCodexに渡す必要があった。再現条件の伝達がボトルネックで、結局「人間が見ないと直らないバグ」が一定割合で残っていた。
in-app browser搭載後は、Codexがブラウザを直接操作してバグを起こせる。クリック、フォーム入力、スクロール、DOMの状態確認まで、ブラウザの中の振る舞いを自分で確かめながら修正に入れる。再現条件をCodexに正確に言語化して伝える手間が消えるのが、運用上は大きい。
自動レビュアーとの設計的な噛み合い
in-app browserは、副作用の出方が一段強い操作だ。ローカル開発サーバーだけを触らせているつもりが、ブックマーク経由で本番ドメインに遷移してしまう、外部APIを直接叩く管理画面に入ってしまう、といったリスクがある。本番URLを誤って操作したら事故になる。
ここで、同時にリリースされた自動レビュアーが効いてくる。レビュアーがあれば、Codexが「本番ドメインを操作しようとしている」状況を検知して止めることができる。in-app browserの「攻める」と、自動レビュアーの「守る」が同時に出てきたのは、設計として整っている。片方だけ入れて運用するより、両方セットで導入することを前提に組まれた更新と読むのが妥当だ。
手元での検証：フォームバリデーション修正タスク
筆者はNext.jsフロント+FastAPIバックエンドの社内ツールで、in-app browser経由のバグ修正フローを試した。指示は「ローカルサーバーを立てて、フォームのバリデーションを修正してテストまで通す」というシンプルなものだ。
従来フローでは、Codexがコードを書き換えた後、人間がブラウザでフォームを操作して挙動を確認し、そのフィードバックを返す必要があった。in-app browser利用後は、Codexがコードを書き換え、そのまま自分でブラウザを開いてフォームを操作し、バリデーションメッセージを確認してから修正のループを回した。
所要22分のうち、筆者が手を動かしたのは約3分。多くは自動レビュアーが「リスク高」と判定した本番URLアクセスと.env削除の承認だった。in-app browserと自動レビュアーが噛み合うと、Codexのフロントエンド修正タスクの「人間待ち」が、想像以上に短くなる体感がある。
副作用の境界をどう設計するか
in-app browserをチーム導入する場合に最初に詰めるべきは、「どのドメインへのアクセスを許すか」の線引きだ。localhostと社内ステージング環境までで止めるのか、本番モニタリングダッシュボードまで触らせるのか、によって設計が変わる。
筆者の運用では、自動レビュアーポリシー側で本番ドメインへのアクセスを「常に人間に上げる」分類に固定し、in-app browser自体は基本的に自由に動かす方針を取っている。ブラウザ操作そのものは安全性が高いが、遷移先のドメインで一気にリスクが変わる、という設計判断だ。
逆に、ブラウザ操作の全プロンプトを「都度確認」にしてしまうと、in-app browserの利点が大きく削がれる。ブラウザの中の操作は1セッションで数十回発生するため、毎回承認していたら従来フローと所要時間がほぼ変わらない。ここはポリシー設計でメリハリをつける必要がある。
推奨アクション
- Codex CLIを最新版に更新し、in-app browserと自動レビュアーをセットで有効化する
- 自動レビュアーポリシーで「許可ドメインのホワイトリスト」を明示する
- フロントエンドのバグ修正タスクをCodexに任せる際、再現条件のテキスト化を省略して、ブラウザ操作を任せるフローへ切り替える
- 本番ダッシュボードや決済画面に到達できるブックマークは、Codexから隔離したプロファイルで動かす
フロントエンド作業の任せ方が変わる
in-app browserの登場で、Codexに任せられるタスクの境界が広がった印象がある。これまで「人間が見ないと直らない」と諦めていたUIバグの一部が、Codex単独で完結する候補に入った。自動レビュアーとセットで運用すれば、安全性を確保しつつ「ブラウザの中で起こることはCodexに任せる」フローが現実的に組める。
フロントエンドの作業を一気に外注エンジニアへ投げるような感覚に近い。チーム導入時はレビュアーポリシーの整備とドメイン制御の設計が前提条件になるが、整備さえできれば、Codexのフロントエンド領域での価値は段違いに上がる。
