Codexに業務手順を一度見せれば終わり？｜Record & Replayでも残る例外処理

一度操作を見せる。

Codexが覚える。

次から自動でやってくれる。

ここまで聞くと、業務自動化が急に簡単になったように見えます。

実際、2026年6月にOpenAIが追加したRecord & Replayは、Mac上で操作を記録し、繰り返し使えるスキルへ変換できる機能です。文章で長い手順を書くより、実際の操作を見せたほうが早い業務は多いんですよね。

ただし、一度見せたら運用まで完成するわけではありません。

見せるだけのスキル化

たとえば、毎朝次の作業をしているとします。

・管理画面へログイン

・前日のCSVをダウンロード

・Excelで不要な行を削除

・別のシステムへ登録

・完了メールを送信

この操作をCodexへ見せて再利用できるなら、手順書を一から書く負担は減ります。

クリックする場所、入力する内容、ファイルを保存する場所など、言葉にすると長くなる部分を操作から覚えさせられるからです。

社内業務では、「説明するより一回見たほうが早い」が本当に多いです。

私もシステム開発の相談で、文章だけでは分からないときは、現在のExcelや画面、実際の操作順を見せてもらいます。

担当者にとって当たり前すぎて、手順書へ書かれていない処理が出てくるからです。

正常系という一本道

一度見せられるのは、基本的にそのとき成功した操作です。

CSVが正しく出力され、画面もいつも通りで、ログインにも成功し、登録対象にも問題がない。

これは正常系と呼ばれる一本道です。

実務でクッッッソ厄介なのは、その道から外れたときです。

・CSVが出力されていない

・列の順番が変わっている

・空欄のデータが入っている

・同じデータが昨日も登録されている

・ログイン画面へ追加認証が出る

・保存ボタンの位置が変わる

・処理途中で通信が切れる

人なら画面を見て「今日はいつもと違う」と止まれます。

自動処理は、止まる条件を教えていなければ、そのまま進もうとします。

未定義メソッドの朝

以前、工程管理画面で自動保存を軽量化した後、画面に次のエラーが出ました。

scheduleLocalDraftSave is not defined

構文チェック自体は通っていました。

でも、実際の画面では必要なメソッドが足りず、自動保存が動いていませんでした。

はい。

構文が正しいことと、業務が動くことは別です。

CodexやClaude Codeがコードを書き、ブラウザ操作まで再現できても、呼び出される関数、保存先、権限、通信状態まで正常とは限りません。

自動化では、「クリックできた」「エラー表示がなかった」だけを成功条件にしないほうがいいです。

保存後のデータを読み直し、期待した内容になっているかまで確認する必要があります。

二回目のID消失

別のExcel閲覧ツールでは、IDをクリックして明細を開き、計算結果を親画面へ反映する機能を作っていました。

一度目の反映は動きました。

ところが、その後にExcelを読み直すと、二行目以降のIDが画面上で「IDなし」になりました。

原因の一つは、IDを数値として扱う場所と、文字列として扱う場所が混在していたことです。

最初の一回だけなら気づきにくいです。

二回目の操作、再読込、再反映まで試して初めて見える不具合があります。

Record & Replayで同じ操作を再現できても、データの型や保存状態が壊れていたら、同じ失敗をきれいに繰り返します。

自動化が忠実すぎるんですよね（そこは空気を読まなくていい）。

二重登録を止める鍵

業務自動化で必ず考えたいのが、同じ処理を二回実行した場合です。

メール送信なら、同じ相手へ二通届くかもしれません。

請求データなら、同じ金額が二回登録されるかもしれません。

投稿ツールなら、同じ内容が連続で公開されるかもしれません。

そのため、私は処理対象に識別子を持たせます。

・元データのID

・ファイル名と更新日時

・注文番号

・メールのメッセージID

・処理済みの状態

・登録先で発行されたID

同じ識別子がすでに処理済みなら止める。

途中で失敗しているなら、その地点から再開する。

この考え方がないまま操作だけ自動化すると、止まった後の復旧が人力になります。

承認を残す境界線

OpenAIのRecord & ReplayやCodexのブラウザ操作、Claudeのコネクターが広がるほど、「どこまで自動で実行させるか」が重要になります。

私は、次の処理には人の承認を残すことが多いです。

・メールやチャットの外部送信

・金額の確定

・顧客情報の更新

・公開投稿

・ファイル削除

・大量データの一括変更

自分で設計したX投稿支援ツールでも、自動大量返信ではなく、人が承認した内容だけを送信する構成にしました。

最初から完全自動にすると、問題が出たときに「どの判断を直せばいいか」が分かりにくくなるからです。

まずは候補を作る。

次に人が確認する。

修正内容を記録する。

問題が少ない処理だけ自動実行へ移す。

この順番が現実的です。

操作から運用への変換

一度操作を見せて自動化を始める場合でも、最低限次の項目を決めておきます。

・開始条件

・成功と判断する条件

・止める条件

・入力データの形式

・同じデータの判定方法

・失敗時の通知先

・再実行の方法

・人が確認する場所

ここまで決まって、操作の記録が業務システムになります。

Record & Replayは強い入口です。

ただ、入口が一気に広くなったぶん、奥にある例外処理が見えにくくなりました。

自動化前の一回

毎日繰り返している操作があるなら、一度録画して終わりではなく、次の三日分を見てみてください。

一日目は通常業務。

二日目はデータが少ない日。

三日目は入力漏れや例外があった日。

この三パターンを見るだけでも、必要な停止条件や確認項目がかなり出てきます。

私は、Excel、GAS、Python、Webアプリ、Codex、Claude Codeを使った業務自動化の相談を受けています。

操作は決まっているけど、どこまで自動化していいか分からない。

そんな段階からでも、正常系と例外処理を分けて整理します。