Codex Record & Replay とは：ソフト操作を再利用できる AI Skill に変える仕組み
OpenAI Codex Record & Replay は、繰り返しの操作を一度見せて再利用可能な AI Skill に変える。
Codex Record & Replay は、一見すると小さな機能に見える。
ワークフローを録画して、あとで再実行する。
しかし本質は、会社の中にある操作知識を残す仕組みだ。
OpenAI の公式 Record & Replay ドキュメント は、この機能を「Codex にワークフローを一度見せ、再利用できる skill に変える」と説明している。例も日常的だ。経費申請、駐車スペースの予約、正しく設定された issue の作成、動画公開、定期レポートのダウンロード。
この日常性が重要だ。
会社には、ソフトウェアの操作に詳しい人がいる。どの項目に何を入れるか。どの命名規則を使うか。どのレポートを落とすか。どのチェックボックスに触らないか。最後にどう確認するか。
その知識の多くは、ソフトウェアにならない。
Record & Replay は別の道を示している。人が一度やって見せる。Codex がそれを、確認でき、編集でき、再利用できる Skill として下書きする。その後は Computer Use、browser actions、plugins、または複数のツールを組み合わせて再利用できる。
Record & Replay がすること
Record & Replay は macOS 上の Codex で利用できる。OpenAI は、初期提供地域から European Economic Area、United Kingdom、Switzerland が除外されることも明記している。また Computer Use が利用可能で、有効になっている必要がある。
流れはシンプルだ。
Codex アプリで Plugins を開き、skill の録画を選び、Codex に背景情報を渡し、録画を許可する。その後、Mac 上で普段どおりに作業を行い、完了したら録画を止める。
録画中、Codex はワークフローを学ぶために必要な操作とウィンドウ内容を観察する。停止後、捕捉した手順を確認し、skill を下書きする。
その skill には次の内容が含まれる。
- いつ使うべきワークフローか;
- 必要な入力は何か;
- どの手順で進めるか;
- 結果をどう検証するか。
録画後に skill をさらに調整することもできる。特に、命名規則、デフォルト値、承認条件、判断ポイントのような暗黙の好みは明示した方がよい。
なぜ単なるマクロではないのか
最初に思い浮かぶ比較は、マクロレコーダーだ。
ただし、それだけでは足りない。
マクロはクリックを記録する。Skill は意図、入力、条件、手順、検証方法を記述する。座標を再生するだけではない。現在の環境にある Computer Use、browser actions、インストール済み plugins、その他のツールを使う Agent のための再利用可能な文脈になる。
これは実務では大きい。
仕入先請求書を提出できる人は、ただボタンを押しているわけではない。どの仕入先名が正しいか、いつ契約書を添付するか、発注書がない場合にどうするか、提出が成功したかどう確認するかを知っている。
定期レポートを出す人も、ただファイルをダウンロードしているわけではない。日付範囲、フィルター、フォルダ規則、受け手、事前に見るべき異常値を知っている。
Record & Replay は、この暗黙の操作経験を、動く手順書に近いものへ変える。
人が読める。
人が直せる。
Agent が再利用できる。
新しい単位は Skill
AI 作業は長い間、prompt を中心に設計されてきた。
Prompt は便利だ。しかし実際の画面、個人の好み、繰り返しの検証に依存する作業では壊れやすい。
繰り返し作業には Skill の方が向いている。
Skill は単発の依頼ではなく、操作パターンを持てる。毎回変わる入力と、変えてはいけない手順を分けられる。Agent が完了をどう判断するかも書ける。
これにより、自動化に参加できる人が変わる。
経理担当者は経費申請を示せる。マーケティング担当者は動画公開を示せる。サポート責任者は ticket の作り方を示せる。運用マネージャーは毎週のレポート取得を示せる。
彼らがソフトウェアエンジニアになる必要はない。
その作業を十分に理解し、一度示し、生成された Skill をレビューできればよい。
リスク：録画された作業にもガバナンスが必要
Record & Replay は、安全面の課題も見えやすくする。
OpenAI は、録画を短く集中させること、現実的な入力を使いながら secrets や sensitive data を避けること、ワークフローが終わったら録画を止めることを推奨している。
これは実務的な助言だ。録画は明示的な手順だけでなく、ウィンドウ内容、アカウント状況、ファイル名、顧客データ、暗黙の運用習慣まで含む可能性がある。
チームは生成された Skills を運用資産として扱うべきだ。
広く再利用する前に、少なくとも次を確認したい。
-
録画は何を見たか 作業範囲を狭くし、無関係な画面や機密情報を避ける。
-
Skill は何ができるか browser actions、Computer Use、plugins、システムアクセスが必要かを見る。
-
誰が使えるべきか 経費申請の Skill と請求設定を変える Skill は同じ権限でよいとは限らない。
-
成功をどう確認するか 繰り返しワークフローには明確な done state が必要だ。
-
いつ人間の承認が必要か 送信、削除、支払い、公開のような高影響アクションでは review を挟むべきだ。
Skill が有用になるほど、所有者とガバナンスが必要になる。
Skills のためのワークスペースが必要になる理由
Record & Replay は、より大きな製品変化を示している。
AI Agent は質問に答えるだけではない。手順を蓄積し始めている。
チームに数十の再利用可能な Skills があると、問題は運用になる。
- Skills はどこに置くのか。
- 誰が review するのか。
- どのバージョンが最新か。
- それぞれの Skill はどのデータにアクセスできるのか。
- どの実行が成功し、どれが失敗したのか。
- ワークスペースを出る前に、どの成果物を確認すべきか。
ここで Buda の方向性が効いてくる。
Buda は、人間が主導する AI Agent Workspace だ。sessions、Drive の文脈、ツール、browser と terminal、channels、logs、skills、人間の review を一つの場所に置く。
再利用できる Skill は、チームが管理できて初めて役に立つ。人間は Agent の作業を確認し、文脈を調整し、重要なステップを承認し、次回のために手順を保存できるべきだ。
これからの自動化は、スクリプトを書ける人だけが作るものではない。
仕事をよく知る人が、作業を明確に示し、それを繰り返す Agent を管理する。
それが Record & Replay の本当の意味だ。
あなたの会社には、すでに Skills がある。
ただ、ソフトウェアを操作できる人の頭の中に閉じ込められているだけだ。
Buda dashboard で人間主導の Agent ワークフローを試すか、Buda Agent Workspace ドキュメント を読む。