Codex Record Replayを使ってみた：Playwrightと何が違うのか

こんにちは。もるふぉです。

Playwrightで書いた自動化コードが、相手のフロントエンド更新でいつの間にか壊れている。

あの体験を一度でもしたことがあれば、今回の機能は無視できません。

Codex Record Replayという機能が公開されました。

ひとことで言うと「Mac上で一度作業を見せれば、Codexがその手順を覚えて、次から自動で再現する」というものです。

「ただのマクロでは？」と思うかもしれません。

ただ、中身を覗いてみるとPlaywrightやRPAとはまったく違う発想で動いていて、エンジニアとしては無視できない作りでした。

機能の概要から内部技術、Playwrightや既存RPAとの違い、「プラグインとして配布できる」という見落とされがちな本質的な新しさまで一気に整理します。

Record & Replay – Codex | OpenAI Developers

Show Codex a workflow once and turn it into a reusable skill

developers.openai.com

Codex Record Replayとは何か（一度見せれば、あとはCodexがやる）

コンセプトは公式の言葉そのままで、Show Codex a workflow once and turn it into a reusable skillです。

Mac上で一度ワークフローを実演すると、Codexがその画面操作を観察して、再利用可能な「スキル」として保存します。

ここで言うスキルは単なる操作の録画ではありません。

録画停止後の解析でCodexが「いつ使うべきか」「どんな入力が必要か」「どんな手順を踏むか」「結果をどう検証するか」を組み立て、構造化されたスキルとして書き出します。

次回からは新しいスレッドで「このスキルを使って今月分の経費を提出して」と頼むだけで動きます。

似た機能にCodex Automationsがありますが、こちらは「決まった時刻に走らせる定期実行」が主役です。

Record Replayは「人間が普段やっているGUI操作そのものを、AIが代わりにやる」ことが主役で、棲み分けがはっきりしています。

毎月1回しか発生しないけれど自分にしかやり方が分からない、あの面倒な作業をAIに丸投げできる、という方向の機能です。

ここが面白いのですが、これを実現している内部の仕組みが、既存のRPAやマクロとは根本的に発想が違います。

中で動いているのはComputer Use（CUA）という画面操作モデル

なぜ「コードを書かなくていい」のかは、内部で動いているComputer Use（Computer-Using Agent、略してCUA）を見れば腹落ちします。

CUAの動作ループはこうです。

スクリーンショットを撮る、画像をマルチモーダルモデルに渡して「いま何が映っているか」を解釈させる、現在の目的に対して次のアクション（クリック、入力、スクロール）を推論させる、実行する、結果を確認する。

これを目的が達成されるまで繰り返します。

これ、何がすごいかっていうと、DOMのセレクターもUIエレメントの座標も使わずに、人間と同じ「画面を見て判断する」やり方で動く点なんです。

button#submit-btnがいつの間にかbutton.primary-actionになっていても、画面上で「送信」と書かれたボタンが視覚的に同じ位置にあれば、CUAは普通に押します。

デザインリニューアルによるセレクター崩れとは、そもそも無縁の設計です。

ちなみにOpenAIにはOperatorという別のComputer Use系プロダクトもありますが、こちらはクラウド側のブラウザを操作する役割が中心です。

Codex Record Replayはローカル（あなたのMac）のデスクトップアプリも含めて操作対象にできるので、Excelで開いた経費精算シートや、ローカルにしかない社内ツールにも届きます。

役割分担としてはOperatorが「Web担当」、Codex Computer Useが「あなたのデスクトップ担当」と整理すると分かりやすいです。

画面に映っていれば対象になる、というのがComputer Useの強みで、これがRecord Replayの土台になっています。

この「画面を見て判断する」という発想が、PlaywrightやRPAとどう違うのか。

次に整理します。

Playwright・RPA・Apple Shortcutsと何が違うのか

エンジニアにとって最も知りたいのはこの比較だと思います。

PlaywrightでCSSセレクターを直書きした自動化コードは、デザインリニューアルでクラス名が変わった瞬間に壊れます。

page.locator('button.submit-primary')と書いたコードが、CIで赤くなって、原因を調べたら相手のフロントエンドが更新されていただけ、というやつです。

現在はgetByRole等のロケーターAPIが整備されて多少改善されましたが、それでも「画面を視覚的に判断する」という発想ではなく、DOM構造への依存は残ります。

CUAはそもそもセレクターの概念を持たない点で、根本的に異なります。

RPAも構造は近くて、UiPathやAutomation AnywhereはUI要素のIDや座標を覚えさせるアプローチなので、画面レイアウトが変わると同じく壊れます。

ベンダーロックインが発生しやすく、社内導入のコストが見合うかどうかという別の悩みも乗ってきます。

Apple Shortcutsはローカル個人利用には強いものの、リアルタイムに画面を見てその場で判断するCUAのような柔軟性はまだ限定的です。

「画面に出てきたエラーメッセージを読んで適切に対処する」みたいな揺らぎのある操作は、現時点ではカバーしにくい構造です。

Record Replayは、この3つが抱えている「UIが変わると壊れる」「判断ができない」という問題を、画面を見て判断する方式で正面から殴っています。

デザインが変わるたびにセレクターを更新する仕事、もう要らないかもしれません。

もちろん、業務クリティカルでミリ秒単位の精度が要求される場面ではPlaywrightのほうがまだ堅いです。

ただ、月次・週次の「人間がやってもいいけど面倒」な作業は、ほぼRecord Replayの守備範囲に入ってきました。

Codex Record Replayで録画してスキル化するまでの流れ

実際の手順は驚くほど短いです。

Codexのメニューを開いてPluginsに入り、「+」ボタンを押してRecord a skillを選びます。

すると、これから録画する作業について、Codexがプロンプトの叩き台を提案してくれます。

中身を確認して、必要なら細かい指示を足してから録画許可を出します。

あとはMac上で実際の作業を一度やるだけです。

終わったらメニューバーかオーバーレイから録画を止めます。

Codexが録画内容を解析し、いつ使うべきか、入力に何が必要か、ステップは何か、検証方法は何か、を含むスキル案を自動生成します。

精度を上げるための公式の推奨は4つあります。

• 短くて完結したワークフローを録ること（10分の作業を10分まるごと録らない）。長い手順のままだと「作業の本質」と「付随する操作」をCodexが区別しにくくなり、スキルの再現精度が落ちる
• 具体的な入力値を実際に使うこと（ダミーで埋めずに本物に近い値で実演する）。ダミー値だと「このフィールドに何を入れるべきか」をCodexが誤学習することがある
• 機密情報を画面に出さないこと（録画は保存されるので業務的に重要）
• 隠れた命名規則やデフォルト値を明示的にプロンプトに書くこと（例: 「経費の摘要は『MMDD_用途』形式」など）

特に最後の「隠れたルールを言語化する」は、人間同士の引き継ぎでも詰まる典型ポイントです。

AIに渡すときも同じです。

そして、スキルを作ったら終わりではありません。

ここからが今回いちばん面白いところです。

プラグインとして配布できる、という本質的な新しさ

従来、業務の自動化を他人に渡すときは、シェルスクリプトやPythonスクリプトを共有するか、RPAのフローを書き出すか、SOPの手順書を渡すかの3択でした。

スクリプトは実行環境のセットアップが必要、RPAはライセンスが必要、手順書は人間が読んで操作する必要がある、というそれぞれの壁がありました。

Record Replayで作ったスキルは、Codexのプラグインとして配布できる形に持っていけます。

受け取った相手は、自分のCodexでそのスキルを使って〇〇してと頼むだけです。

スクリプトを渡す時代から、スキルを渡す時代へ、というのは少し大げさですが、感覚としては近いものがあります。

いわばDockerイメージを渡すような感覚、と言えば近いかもしれません。

環境の差を吸収したうえで、動作するものがそのまま相手の手元に届く。

ある人の頭の中にしかなかった「あの作業のやり方」が、組織の資産になるということです。

誰かが辞めても、その人の作業ノウハウはスキルとして残り、新人が初日から再現できます。

ナレッジマネジメントの観点で見ると、重いインパクトを持っています。

より安定した形で配布したい場合はBuild pluginsという別の経路が用意されていて、こちらは個人デモではなくチーム配布や複数スキルのバンドル、アプリ統合、MCPサーバー管理に向いた作りです。

Record Replayは「最初の1本を試作する」用、Build pluginsは「本格的に配る」用と棲み分けるのが現実的です。

ただ、導入前に確認しておくべき制約があります。

Codex Record Replayを使う前に確認する制約とハマりどころ

現時点での制約をまとめます。

ここを誤ると「使えるはずなのに動かない」となるので、事前に確認してください。

• macOSのみ対応（WindowsとLinuxは未対応）
• EEA・UK・スイスは初期段階では除外
• Computer Useが有効になっている必要がある
• 組織が管理するCodexでrequirements.tomlの[features]セクションにcomputer_use = falseが書かれている場合は利用不可

特に最後の組織設定は、社内SaaS管理者がComputer Useを制限している企業だと、個人で有効化しようとしても弾かれます。

導入前に管理者へ確認しておくのが安全です。

ハマりどころとしては、録画中に余計なウィンドウやSlack通知が映り込むと、Codexがそれを「ワークフローの一部」と誤認することがあります。

録画前に通知をオフにしておくと、生成されるスキルの精度が上がります。

機密情報を出さないことも原則です。

録画データの扱いはOpenAIの規約に従いますが、業務上「そもそも画面に出すべきでない情報」は録らないようにしてください。

おわりに

Codex Record Replayは、派手な新機能というよりは「自動化のメンテコスト問題」と「ナレッジ属人化問題」を同時に殴りにきた、静かだけど重要な一手だと感じました。

Playwrightで書いたE2Eテストが壊れて夜中に直す、あの時間を取り戻す方向の技術です。

まずは月末のレポート出力や経費精算など、自分が月次・週次でこなしている繰り返し作業を1つ思い浮かべてみてください。

それをRecord Replayに録らせてみるだけで始まります。

Record a skillから動くものが手に入るまで、5分もかかりません。

今回触れていないBuild pluginsやAutomationsとの組み合わせは、別の記事で深掘りします。