大きなニュースではないが、記事にする価値があると思った。
OpenAIはCodexの内蔵ブラウザを追加した。 device toolbarこれはデバイスサイズツールバーとしても知られています。これからは、Codexでウェブページを作ったり、UIを変更したり、レスポンシブ・レイアウトを調整したりするときに、デフォルトのウィンドウを見つめなくても効果がわかります。
Codexは、モバイル、タブレット、デスクトップなど、さまざまなサイズでアプリをテストすることができます。Codexは単独でページを見て、ズレ、オーバーフロー、小さすぎるボタン、間違ったスペーシング、モバイルで崩れるナビゲーションを見つけ、コードを変更し続けます。
入力も非常に簡単で、コーデックス内蔵ブラウザのURLバーの右側にある3つの点をクリックすればOKだ。
図1：Codexアプリのコード・レビュー・インターフェース
Codexアプリは、コードを書くこと、変更点を見ること、レビューをすることを同じワークベンチで行うことができる。
出典：OpenAI Developers Codex アプリページ
この全体は、表向きは小さなボタンだが、実際には大きな意味がある。
過去にAIを使ってフロントエンドを書いたとき、最も一般的な問題は「コードは実行でき、ページも開けるが、デバイスを変えた瞬間にバレてしまう」というものだった。
デスクトップは問題なく見えるが、携帯電話の見出しは3行に押し込められ、カードの幅は死ぬほど狭く、横スクロールバーが飛び出し、ボタンは画面の端に張り付き、小さな画面ではポップアップがカバーしきれず、ナビゲーションバーはそのまま災害サイトになる。
モデルがコードの書き方を知らないのではなく、過去に安定した「見る」「検証する」リンクが欠けていたのだ。
フロントエンドの本当の問題点は、単に React 構成要素は書き出してある。問題は、それを何度も何度も見て、微調整し、サイズを試すことだ。特にレスポンシブ・ページの場合、デザインでは通常1つか2つの状態しか与えられないのに、実際のデバイスでは奇妙なサイズがたくさんある。
この欠点を補うのがデバイスツールバーなのだ。
図2：コーデックス・アプリの新しいスレッド・インターフェース
フロントエンドのタスクは、自然言語から始まり、コードの実装、ページのチェック、修正の閉じたループにコーデックスすることができる。
画像出典：OpenAI Developers Codexページ
Codexは、単なる “コード・ライターのアシスタント ”ではなく、“フロントエンドの結果を自らチェックする開発エージェント ”に近づいている。
それよりも私は、この機能がフロントエンドのタスクの提供方法を変えてしまうのではないかと心配している。
以前は、AIに与えるタスクはたいていこうだった：
レスポンシブ・ページを作るのを手伝ってください。
今ならこう言うだろう：
このページの実現に協力し、それぞれ390px、768px、1440pxでのレイアウトをチェックしてくれ。問題を見つけたときに自分で修正し、最終的に各サイズで何が変更されたかを教えてくれました。
それは違う。
前者はAIにコードを書かせることであり、後者はAIにフロントエンドのタスクを完了させることである。
さらに一歩進んで、Codexは非常に便利なクローズドループを形成することができる：
まずページを生成し、次にローカルアプリを開き、異なるデバイスサイズを切り替え、ページの問題を観察し、CSSとコンポーネント構造を修正し、再度実行し、最後に差分を提出する。
AIフロントエンドの生産性が本当に難しくなるのはここからだ。
デバイスツールバーの追加により、Codexはデスクトップを見るだけでなく、さまざまな画面サイズでページをチェックすることができる。
ブラウザは約30%高速化し、マウスカーソルのアニメーションはよりタイトになり、フルスクリーンモードでコンポーザーを非表示にする新しい方法が追加されました。
これらは不格好に聞こえるが、道具の感触にとって重要なものだ。
AIコーディングツールの最大の恐怖とは？
クールな機能がひとつ減ったということではなく、使うときに引っかかったり、遅くなったり、見えなくなったり、思考が中断されたりするのだ。効果を確認するために頻繁にブラウザを凝視しなければならなくなれば、こうした些細なことが無限に拡大される。より高速なブラウザ、より安定したカーソル、そしてフルスクリーンでのブロックが減れば、人々はより積極的に実際の作業をブラウザに委ねるようになるだろう。
図3：Codex Web / クラウド入力インターフェース
Codex Webは、クラウド環境でのタスクを処理したり、複数の開発タスクを並行して実行することができる。
画像引用：OpenAI Developers Codex Cloud ドキュメント
だからこそ、最近のコーデックスの方向性は明確だと思う。
それは、ただ中に入っているだけではない。 Claude Codeは、誰がコードを書くのがうまいかよりも、「ソフトウェア開発現場」の汚れた部分、壊れた部分、現実の部分を補うことにある。
コードを書くことは最初のステップに過ぎない。実際の開発では、ページのプレビュー、異常、サイズの切り替え、テストのフィードバック、PRの変更、レビューの証拠などもある。以前はこれらすべてに目を配る必要があったが、今はCodexが少しずつ引き継いでいる。
特にフロントエンド開発は、この機能によって書き換えられる可能性が最も高い。
フロントエンドは正しいロジックを持つだけでなく、正しいビジュアル、正しいインタラクション、正しいデバイスを持つことも重要だからだ。
ボタンがクリックできるかどうか、ポップアップ・ウィンドウがブロックされるかどうか、モバイルでオーバーフローするかどうか、ダーク・モードで十分なコントラストがあるかどうか。今は、Codexがブラウザを開き、サイズを切り替え、ページを観察しさえすれば、自分で問題を見つけるチャンスがある。
もちろん、完全に手放すことを勧めるわけではない。
特にブランドページや商品サイト、複雑なバックエンドシステムでは、AIはまだ「そっくりさん」のミスを犯しやすい。明らかなバグは修正できるが、美観、情報階層、インタラクションの意図などは、やはり人間がチェックする必要がある。
Codexに最初の実装と低レベルの問題の後始末を任せ、人間が最終的な判断を下す方が理にかなっている。
例えば、ページが完成したら、コーデックスに一巡させればいい：
- - デスクトップ 1440px 一度チェックする
- - フラットベッド768px チェック1回
- - モバイル 390px 一度チェック
- - ヘッダーの改行、ボタンのブロック、水平スクロール、フォームのオーバーフロー、ナビゲーションのクラッシュのチェックに重点を置く。
- - 修正後、各サイズで何が変更されたかを説明して差分を提出する。
この種の仕事は、AIに引き継ぐのに最適だ。
なぜなら、それは反復的で些細なことであり、目が疲れることであるにもかかわらず、配達の質に影響を与えるからだ。
レスポンシブの問題は、大きなバグではなく、見出しの改行、ボタンのステッカー、カードのオーバーフロー、ナビゲーションのズレといった小さな問題になりがちだ。
この観点からすると、デバイスツールバーの価値は「電話画面のシミュレーション」そのものにあるのではない。
ブラウザー開発ツールは長い間、これを可能にしてきた。
この能力はコーデックスの実行チェーンに組み込まれている。
かつては人間の開発者がアクションを起こさなければならなかった：
ページを開き、それを見て、ずれを見つけ、エディターに戻ってコードを変更し、もう一度更新してサイズを変更し、もう一度見て、また変更する。
これで、リンクはコーデックス自身によって運営されるようになる。
それが変化だ。
図4：コーデックスPR／テスト・フィードバック・インターフェース
Codexの成果物はコードだけでなく、差分、テスト結果、変更ノートなど、レビュー可能なものでなければならない。
画像出典：OpenAI Developers Codexページ
だから、私はこのアップデートをサインと捉えたい。
AIがコードを書くことは、「生成できるか」から「検証できるか」になった。
かつて私たちは、AIが実際にページを書き出すことができることに驚いていた。
次に本当に価値があるのは、AIが自分でページを見て、自分で問題を見つけ、自分で修正し、その結果を人間のレビューに渡せるかどうかだ。
フロントエンドはおそらく、仕事の習慣が変わる最初の場所になるだろう。
将来的には、フロントエンド・タスクの標準的な納品は「ページが書かれた」ではなくなるかもしれない：
デスクトップ側はそれを見ている。
タブレットの端が見えてきた。
モバイルで見た。
そのやりとりは終わった。
明らかなレイアウトの問題が修正された。
diffの見直しが可能になった。
それが、このコーデックスの小さなアップデートの背景にあるポイントだ。
追加のボタンではない。
フロントエンドの受け入れに本格的に参入し始めているのはAIだ。
