画面を見せればAIが仕事を覚える
2026年7月22日現在、AnthropicがClaude Coworkに追加した「Record a skill」は実在する。Anthropicの公式投稿によると、ユーザーが作業中の画面を録画し、何をしているかを話しながら実演すると、Claudeがその内容を再実行可能なスキルへ変換する。Claudeデスクトップアプリの「＋」メニューから利用でき、発表時点の対象はPro、Max、Teamプランである。
第一に、Anthropicが明記しているのは「画面を録画し、話しながら作業する」ということだ。画面上のクリックや入力操作は当然映るが、キーロガーのようにクリック座標や全キーストロークを生のイベントデータとして保存するのか、映像と音声を中心に解析するのかは、現時点の公式投稿だけでは分からない。「クリックやタイピングをClaudeに分析させる」という説明は利用者目線ではおおむね妥当だが、技術仕様として断定すべきではない。
第二に、「追加料金なし」は「対象の既存サブスクリプションに含まれる」という意味なら妥当だ。Claude CoworkはPro、Max、Teamの各プランに含まれている一方、AnthropicはCoworkが通常のChatより利用上限を速く消費することや、利用制限が適用されることも明記している。したがって「完全無料」「無制限」という意味ではない。
第三に、OpenAIとの競争は単なる将来予測ではない。OpenAIは2026年6月18日、CodexのmacOS向け機能として、ほぼ同じ発想の「Record & Replay」をすでに発表していた。ユーザーが一度ワークフローを実演し、それを再利用可能なスキルへ変換する機能で、こちらも実際のメニュー項目は「Record a skill」である。時系列では、OpenAIの一般公開発表がAnthropicより約1か月早い。
つまり今回のニュースを正確に表現するなら、次のようになる。
AnthropicはClaude Coworkに、画面操作と音声による実演から再利用可能なスキルを生成する「Record a skill」を追加した。OpenAIのChatGPT Work／Codexには、すでに類似機能「Record & Replay」があり、両社の競争は「プロンプトを書かずに、仕事を見せてAIへ教える」領域へ移っている。
1．これは「マクロ録画」ではなく、仕事の意味を学習させる仕組み
一見すると、Record a skillは昔からあるマクロレコーダーやRPAの録画機能に似ている。
従来型のマクロは、基本的に「この位置をクリックする」「このキーを入力する」「3秒待つ」といった操作列をそのまま再生する。画面レイアウトが変わったり、ボタンの位置がずれたり、データ件数が変化したりすると壊れやすい。
一方、ClaudeやCodexのスキルは、単なる操作列ではない。一般的には、次のような情報をまとめた「AIが仕事を遂行するための手順書兼能力パッケージ」になる。
- いつこのスキルを使うべきか
- どのような入力が必要か
- 何をどの順番で行うか
- 状況によってどう判断を変えるか
- 何をしてはいけないか
- 完了後に何を確認するか
- 必要に応じて利用するスクリプト、資料、テンプレート、ツール
OpenAIは、Record & Replay終了後にCodexが作成するスキルには、「いつ使うか」「必要な入力」「実行手順」「結果の検証方法」が含まれると説明している。再実行時には、アップロードするファイル、作成するチケット、レポートの対象期間など、今回変わる値だけを渡せばよい。Codexは利用可能なComputer Use、ブラウザ操作、プラグインを組み合わせてワークフローを実行する。
OpenAIのスキル自体は、中心となるSKILL.mdと、必要に応じたスクリプト、参考資料、テンプレートなどで構成される。明示的にスキルを指定することも、依頼内容とスキルの説明が合致したときにCodexが自動選択することもできる。
Anthropicの既存Skillsも同じく、SKILL.mdへ手順を書き、Claudeが必要な場面で読み込んで利用する仕組みだ。Claude Codeの公式資料では、繰り返し貼り付けている指示、チェックリスト、複数段階の手順をスキル化することが推奨されている。
Anthropicは今回、録画から生成される内部構造の詳細をまだ公式投稿で説明していない。しかし、Claudeの既存Skills基盤へ接続されると考えるのが自然だ。これは現時点では公式仕様ではなく、既存製品構造からの推論である。
重要なのは、録画そのものが最終成果物ではない点だ。
録画は教師データであり、最終成果物は編集・再利用・共有・評価できる「仕事のモデル」である。
2．ClaudeとCodexの違い
両機能は非常によく似ているが、現在公表されている範囲では違いもある。
観点Claude CoworkChatGPT Work／Codex機能名Record a skillRecord & Replayメニュー表示「＋」→ Record a skill「＋」→ Record a skill教え方画面を録画し、作業しながら口頭で説明Mac上の操作と必要なウィンドウ内容を観察音声説明公式投稿で明示公式ガイドでは必須機能として明示されていない出力再実行可能なClaude Skill利用条件、入力、手順、検証方法を含むSkill実行環境Coworkのファイル、ツール、画面操作Computer Use、ブラウザ、プラグイン発表時点の対象Pro、Max、TeammacOS上の対象ユーザー地域制限公式投稿では特記なし初期提供はEEA、英国、スイスを除外チーム展開既存Skillsには組織共有・プロビジョニング機能リポジトリ共有、Plugin化、管理者配布自動実行との接続Coworkのスケジュール実行と組み合わせ可能AutomationsとSkillを組み合わせ可能
OpenAIのRecord & Replayは、ChatGPTデスクトップアプリでWorkまたはCodexを選び、Pluginsを開いて「＋」から開始する。録画中、Codexは仕事を学ぶために必要な操作とウィンドウ内容を観察する。現時点ではmacOS限定で、Computer Useが有効である必要がある。
一方、Claude Coworkそのものは、ユーザーが許可したファイルやツールを横断し、調査、分析、文書作成などの非コーディング業務を完了するエージェントとして位置付けられている。AnthropicはCoworkとClaude Codeの違いについて、Claude Codeはソフトウェア開発向け、Coworkは調査・分析・文書作成などの知識労働向けと説明している。
ただしOpenAI側も現在は「Codexだけ」の話ではない。2026年7月9日に公開された新しいChatGPTデスクトップアプリは、会話用のChat、一般業務用のWork、ソフトウェア開発用のCodexを統合している。Record & ReplayはWorkモードからも開始できるため、「Claude Cowork対Codex」というより、正確には「Claude Cowork対ChatGPT Work／Codex」の競争と見るべきだ。
3．なぜ「プロンプトを書かなくてよい」ことが重要なのか
これまでAIで業務を自動化できたのは、仕事の手順を文章で分解できる人に偏っていた。
例えば営業担当者が行っている案件レビューをAIへ教えるには、従来なら次のような内容をプロンプトとして明文化する必要があった。
「CRMから商談を取得し、最終接触日が14日以上前で、次回アクションが未入力の案件を抽出する。過去の通話記録とメールを確認し、失注リスクを高・中・低に分類する。高リスク案件には理由と推奨アクションを付け、経営会議向けに表へまとめる」
この文章を書ける人なら、もともと業務設計やプロンプト作成が得意である。しかし現場の優秀な担当者ほど、実際には判断を直感的に行っていることが多い。
「この会社は決裁者が会議に出ていないから危ない」
「最終メールの言い回しを見ると、予算より優先順位が問題だ」
「この業種では年度末の定義が違う」
「このタイプの顧客には長いメールを送らない」
こうした暗黙知は、文章としてゼロから書き出すより、実際の案件を処理しながら「ここではこう考える」と話す方がはるかに容易だ。
実際、一部のXユーザーは、完璧なプロンプトを何分もかけて書く代わりに、音声で考えを話しながら教えられる点を評価している。また、営業担当者が通話分析や競合対策資料の作り方をスキル化し、社内へ共有する将来像を示す投稿もある。ただし、これらは世論調査ではなく、あくまで個々のユーザーによる期待や例示として扱うべきだ。
Record a skillが下げるのは、操作の自動化コストだけではない。
自分の仕事を言語化するコストを下げる。
ここに従来のRPAとの大きな違いがある。これまでは自動化担当者が現場へヒアリングし、業務フロー図を書き、例外処理を確認し、システムへ実装していた。これからは現場担当者自身が日常業務を一度実演し、AIが草案を作り、人間が修正・テストして公開する流れが可能になる。
業務手順書が「読んでもらう文書」から「AIが実行する能力」へ変わるのである。
4．最も効果が出やすい活用領域
すべての仕事が録画自動化に適しているわけではない。効果が出やすいのは、頻度が高く、ある程度手順が安定し、完了条件が明確な業務だ。
OpenAIも、Record & Replayは手順が安定し、成功条件が明確なワークフローで最も効果を発揮するとしている。公式例として、経費申請、駐車スペースの予約、適切な設定を含むIssueの作成、動画の公開、定期レポートのダウンロードなどを挙げている。
営業：調査からCRM更新までを一つのスキルにする
営業では、次のような一連の作業が候補になる。
- 対象企業のCRMレコードを開く
- 過去のメール、商談メモ、通話記録を確認する
- 企業の最新ニュースや採用情報を調べる
- 課題、決裁者、競合、次のアクションを整理する
- 商談前ブリーフを作る
- CRMの所定フィールドを更新する
- フォローアップメールの下書きを作る
このワークフローを教える際には、単に「どこをクリックするか」ではなく、判断基準を話すことが重要だ。
例えば、「決裁者不在なら赤信号」「次の会議日が決まっていても目的が不明なら未確定扱い」「競合名は顧客が明言した場合だけ記録する」といった判断ルールを音声で説明する。
完成したスキルは、担当者の代わりにメールを勝手に送信するのではなく、調査結果と下書きを作り、人間の承認を待つ設計にする。外部送信や商談ステージ変更など、顧客や売上予測に影響する処理には承認ゲートを置くべきだ。
営業マネジメント：トップ担当者のレビュー方法を共有する
営業部長が週次パイプラインレビューを実演し、案件ごとに何を見て、どの質問をし、どの状態を危険とみなすかを話せば、そのレビュー観点をスキル化できる。
これは単に報告資料を作る自動化ではない。優れたマネージャーの「見る順番」と「疑うポイント」をチームへ配布する仕組みになる。
新人はスキルに案件レビューを依頼し、なぜその案件が高リスクと判定されたかを確認できる。スキルを人材育成用のコーチとして使うことも可能だ。ただし、スキルの判断を評価制度へそのまま用いるのではなく、あくまで補助的なレビューとして位置付ける必要がある。
経理・財務：定期取得、照合、差異説明
経理・財務では、定期レポートのダウンロード、複数CSVの統合、勘定残高の照合、予算対実績の差異抽出、経費申請の入力補助などが向いている。
例えば月次照合の実演では、次の内容を説明する。
- どのシステムから、どの期間のデータを取るか
- 日付や通貨の形式をどうそろえるか
- 重複を何のキーで判定するか
- 数円の丸め差を許容するか
- 不一致をどの分類へ振り分けるか
- 合計件数と金額をどこで検算するか
ただし、支払実行、銀行振込、税務申告、会計仕訳の確定などは、録画した直後から無人化すべきではない。最初は「データ取得、照合、候補提示、下書き作成」までに限定し、人間が確定処理を行う構成が安全である。
マーケティング：制作物の公開手順を標準化する
マーケティングでは、記事や動画を公開するまでの細かなルールが属人化しやすい。
タイトルの長さ、サムネイルの命名、カテゴリ選択、UTMパラメータ、公開日時、OG画像、法務表記、社内承認、SNS投稿文など、担当者は多数の細部を暗黙に処理している。
この作業を録画しながら、「このキャンペーンではこの命名規則を使う」「日本語タイトルは全角何文字まで」「公開前に必ずプレビューする」「法務未承認なら下書き保存まで」と説明すれば、CMSが変わらない限り高い再利用価値がある。
さらに、画面操作だけを残すのではなく、ブランドガイド、禁止表現、過去の成功例、テンプレートをスキルへ添付すれば、単なる投稿代行ではなく品質管理スキルになる。
カスタマーサポート：分類、調査、返信案作成
サポート担当者が問い合わせを処理する様子を実演すれば、次のようなスキルを作れる。
- 問い合わせ内容を製品、請求、障害、要望へ分類する
- 契約プランや利用環境を確認する
- 過去の類似チケットを探す
- ナレッジベースから該当手順を取得する
- 優先度とエスカレーション先を判断する
- 顧客への返信案を作成する
- チケットへ内部メモを残す
ここでも「返信案の作成」と「実際の送信」は分離した方がよい。特に返金、契約解除、セキュリティ事故、法的主張が含まれる問い合わせは、人間の確認なしに処理しないという禁止条件をスキルへ書く。
人事・総務：オンボーディングを漏れなく進める
入社準備では、アカウント発行依頼、機器申請、研修予定、組織図更新、歓迎メール、必要書類など、複数のシステムを横断する。
Record a skillを使えば、人事担当者が実際のオンボーディングを進めながら、雇用形態、勤務地、職種、権限レベルによる違いを説明できる。
ただし、パスワード、本人確認情報、給与口座、マイナンバーなどを録画へ含めてはいけない。実演には架空社員や匿名化したデータを使い、スキルには「必要な情報の所在」と「安全な入力方法」だけを記述するべきだ。
データ分析：定期レポートを「取得」から「説明」まで自動化する
ダッシュボードから数値をダウンロードするだけでは、価値は限定的だ。より有効なのは、数値取得後の検算や解釈まで教えることである。
例えば、
- 前週比、前年同期比を計算する
- データ欠損や異常値を確認する
- 目標との差を示す
- 変化の大きいセグメントを特定する
- 原因候補と追加調査項目をまとめる
- 経営会議向けに1ページへ要約する
という一連の手順をスキルにする。
「数値が増えたら良い」といった単純ルールではなく、「売上増でも値引率上昇を伴う場合は注意」「コンバージョン低下が特定地域だけなら全体施策の問題と断定しない」といった判断を録画中に説明することが重要だ。
開発・QA：Codexが特に強い領域
Codexでは、リポジトリ、CLI、IDE、ブラウザ操作、スクリプトを組み合わせられるため、ソフトウェア開発との相性がよい。
候補には、次のようなものがある。
- バグ報告を再現してIssueを作成する
- ログとネットワーク通信を確認する
- デザインとの見た目の差分を調べる
- リリース前の手動確認を行う
- リリースノートを生成する
- 毎日のCI失敗を分類する
- 依存ライブラリ更新後の確認をする
OpenAIのSkillsはリポジトリ内へ保存してチームで共有でき、Automationsと組み合わせて定期実行し、結果をレビューキューへ送ることもできる。
5．良いスキルを作る録画方法
Record a skillは、ただ日常の画面を漫然と録画すればよい機能ではない。録画の品質が、そのままスキルの品質を左右する。
① 一つのスキルには一つの仕事を教える
「営業の仕事全部」のような大きすぎる録画は避ける。
代わりに、
- 商談前ブリーフを作る
- CRMの案件リスクを点検する
- 商談後メールの下書きを作る
- 週次パイプライン表を作る
という単位へ分ける。
OpenAIも、スキルは一つの仕事へ集中させ、入力と出力を明確にすることを推奨している。
② 録画前に目的、入力、禁止事項を話す
作業を始める前に、AIへ次の四点を伝える。
- この仕事の目的
- 毎回変わる入力
- 固定されたルール
- 絶対にしてはいけない行為
例えば次のように説明する。
このスキルの目的は、週次営業会議用の案件リスク一覧を作ることです。入力は対象期間と担当チームです。CRMの値は読み取りますが、案件ステージは変更しません。外部メールも送信しません。最後に対象案件数と一覧の行数が一致しているか確認してください。
これだけで、録画を単なる操作映像から「仕様を伴った実演」へ変えられる。
OpenAIも、録画前に目的と変動する入力を伝えること、現実的なデータを使いつつ機密情報を避けること、録画を短く完全なものにすることを推奨している。
③ 「何をしているか」より「なぜそうしたか」を話す
画面を見れば、AIはどのボタンを押したかを把握できる。しかし、なぜその選択をしたかまでは分からない。
悪い説明は、「次にここをクリックします」である。
良い説明は、次のようになる。
この欄は任意ですが、契約更新が90日以内の場合だけ入力します。更新日が不明なら推測せず、『要確認』として残します。
通常は最新の連絡を使います。ただし、自動配信メールは顧客の意思を表さないので、最新の人間同士のメールまでさかのぼります。
顧客が競合を明言していない場合は、Web情報だけから競合利用中と断定しません。
音声の最大の価値は、操作説明ではなく判断理由の外部化にある。
④ 例外が発生したら、隠さず説明する
録画中にエラーや例外が起きた場合、最初から撮り直したくなる。しかし、その例外が日常的に起きるものなら、むしろ重要な教材である。
「この画面が出たらログインが切れている」
「同じ名前が複数ある場合はメールアドレスで確認する」
「該当データがゼロ件でも空のレポートを作成する」
「合計が一致しない場合は処理を停止する」
と説明し、スキルへ例外処理として残す。
ただし、偶発的で無関係な通知対応や私用作業まで録画し続けてはいけない。OpenAIも、目的のワークフローが終わった時点で録画を止め、無関係な後片付けを含めないよう案内している。
⑤ 実データではなく、現実的なテストデータを使う
架空すぎるデータでは、実務上の例外が出ない。一方、実際の顧客情報やパスワードを使えば漏洩リスクがある。
理想は、構造と複雑さは現実的だが、個人情報や機密を含まないテスト環境である。
- 顧客名は架空名へ置換
- 金額は桁数を維持したダミー値
- メールアドレスはテスト用ドメイン
- 契約書は匿名化版
- APIキー、パスワード、認証コードは入力しない
- 他人のチャット通知を閉じる
- 録画対象外のウィンドウを閉じる
Codexは録画中に操作とウィンドウ内容を観察するため、OpenAIも秘密情報や機微データを入力しないよう注意している。スクリーンショットなどのデータにはChatGPTのデータコントロールが適用される。
⑥ 生成されたスキルを必ず編集する
録画終了後に生成されたスキルは、完成品ではなく初稿と考えるべきだ。
特に確認したいのは以下の点である。
- スキルが起動する条件は狭すぎないか、広すぎないか
- 入力項目に不足がないか
- 画面上の偶然の値が固定ルールになっていないか
- 判断理由が正しく言語化されているか
- 禁止事項が明記されているか
- エラー時に処理を止める条件があるか
- 完了確認が形式的になっていないか
- 外部送信や削除が自動承認になっていないか
「青いボタンを押す」「画面右上から3番目を選ぶ」といった脆い表現があれば、「保存ボタンを選ぶ」「ステータス欄で“レビュー待ち”を選ぶ」という意味ベースの表現へ修正する。
また、APIやコネクタで安定して取得できる処理を、すべて画面クリックに頼る必要はない。画面録画で業務を教えた後、データ取得部分だけスクリプトやコネクタへ置き換えると、速度、再現性、監査性が高まる。
⑦ 正常系だけでなく、失敗させるテストも行う
最低でも次のケースを試す。
- 標準的な正常ケース
- データがゼロ件のケース
- 必須項目が欠けたケース
- 同名データが複数あるケース
- 権限が足りないケース
- UIや列順が少し違うケース
- 禁止された操作を依頼されたケース
- スキルを使うべきでない依頼
Anthropicのスキル評価ガイドも、「スキルが呼び出されたか」と「期待した結果を出したか」を分けて測定し、スキル有効時と無効時を新しいセッションで比較することを推奨している。作成中の会話履歴が残ったままだと、不完全な指示を会話コンテキストが補ってしまうからだ。
⑧ 自動実行は最後に追加する
最初から毎朝自動実行させるのではなく、次の順番で成熟させる。
手動起動 → 人間が全件確認 → 例外時だけ確認 → 定期実行 → 低リスク部分のみ無人化
OpenAIではSkillをAutomationsと組み合わせられ、Claude Coworkにもスケジュール実行がある。しかし、動くことと安全に放置できることは別問題である。
6．録画開始時に使える説明テンプレート
スキルの品質を上げるには、録画開始直後に次のように話すとよい。
目的
この作業は、毎週月曜日に営業案件のリスク一覧を作成するためのものです。
起動条件
「今週の案件レビューを作って」と依頼された場合に使います。個別案件の調査だけを頼まれた場合には使いません。
入力
対象期間、対象チーム、レポートの保存先です。
固定ルール
最終接触から14日以上経過し、次回アクションがない案件を高リスク候補にします。ただし、契約手続き中の案件は除外します。
判断基準
顧客が返信していないだけでは失注と断定しません。過去の会話、決裁者の参加状況、予定されている次回会議も確認します。
禁止事項
CRMの案件ステージを変更しません。顧客へメールを送信しません。判断できない項目を推測で埋めません。
完了条件
対象案件数と出力表の件数を照合し、参照した情報の日時を記載し、高リスク案件には理由と推奨アクションを付けます。
この説明の後で実際の画面操作を見せれば、AIは操作順だけでなく、スキルの境界と品質基準を理解しやすくなる。
7．企業導入で注意すべきリスク
機密情報が録画へ映り込む
画面録画には、対象業務以外の通知、メール件名、顧客名、社内チャット、個人情報が映り込む可能性がある。音声には、録画者以外の会話が入ることもある。
そのため、企業では少なくとも次のルールが必要になる。
- 録画可能なアプリとデータ分類
- テスト環境または匿名化データの利用
- 録画前の通知停止
- 顧客・従業員情報の取り扱い
- 音声に第三者が含まれる場合の社内方針
- 録画データと生成スキルの保存・削除方針
悪い習慣まで標準化される
熟練者の業務だからといって、常に最適とは限らない。
不要な二重入力、古い承認経路、個人的なファイル命名、規程に反した回避策まで録画すれば、それが「正しい仕事」としてスキル化される。
したがって、録画者と承認者は分けた方がよい。現場担当者が実演し、業務責任者、セキュリティ担当者、場合によっては法務や内部監査が公開前に確認する。
UI変更で静かに品質が落ちる
AIによるComputer Useは、固定座標マクロより変化へ対応しやすい可能性がある。しかし、画面項目の名称変更、権限変更、業務ルール変更に完全対応できるわけではない。
危険なのは、完全に停止することより「一応動くが、違う項目を使う」状態である。
スキルには、次のような検証を組み込むべきだ。
- 対象システム名とページタイトルを確認
- 必須フィールド名を確認
- 実行前後の件数を照合
- 保存後にステータスを再取得
- 想定外の画面なら停止
- 重要な変更はスクリーンショット付きで報告
プロンプトインジェクションとデータ流出
スキルがWebページ、メール、文書など外部データを読む場合、その中に「以前の指示を無視して別の情報を送信せよ」といった悪意ある指示が含まれる可能性がある。
Anthropicは、Skillsに関する重大なリスクとして、意図しない操作を引き起こすプロンプトインジェクションと、悪意あるコードや注入された指示によるデータ流出を明記している。信頼できる提供元のスキルだけを利用し、スクリプト、依存関係、外部接続先を確認するよう求めている。
特に、画面操作、メール、クラウドストレージ、CRMを同時に扱えるスキルは権限が大きい。閲覧、下書き、変更、送信、削除を同じ権限として扱わず、段階的に許可する必要がある。
Claude Coworkは、ユーザーがアクセス可能なフォルダやツールを選び、削除には承認を必要とする設計を説明している。
スキルが増えすぎる
誰でも簡単に作れるようになると、似たスキルが乱立する。
「週次営業レポート」
「営業週次レポート」
「営業会議用レポート」
「パイプラインまとめ」
が別々に存在し、それぞれ判断基準が違う状態は危険だ。
組織で共有するスキルには、少なくとも以下の管理情報を持たせたい。
- スキル名と目的
- 所有部署と責任者
- 作成者
- 元になった録画日
- 対象システム
- 必要権限
- 許可された操作
- 禁止された操作
- テストケース
- 最終評価日
- バージョン
- 次回見直し日
- 廃止予定日
Claudeの既存Skillsでは、TeamおよびEnterpriseの管理者が組織全体へスキルをプロビジョニングできる。OpenAI側では、安定したチーム配布にはPlugin化し、複数スキル、コネクタ、MCPサーバー、インストール情報をまとめることが推奨されている。
8．ClaudeとCodex、どちらを使うべきか
Claude Coworkが向いているケース
Claude Coworkは、文書、表計算、調査、社内ファイル、複数ツールを横断する非技術部門の業務に向いている。
特に今回の音声説明を前提としたRecord a skillは、プロンプトやコードを書き慣れていない営業、人事、経理、マーケティング、事業企画の担当者が、自分の仕事をそのまま教える用途と相性がよい。
既存のClaude Skillsには、Team／Enterpriseでの組織共有・プロビジョニング機構もある。したがって今後、現場担当者が録画でスキルを作り、管理者が確認し、全社配布する流れが自然に整備される可能性が高い。ただし、今回のRecord a skill発表で明記された対象はPro、Max、Teamであり、Enterpriseへの提供状況は個別に確認する必要がある。一般のClaude SkillsやCowork自体がEnterpriseで利用できることと、新機能の提供範囲は区別すべきだ。
ChatGPT Work／Codexが向いているケース
OpenAI側は、開発業務との統合で優位性がある。
スキルをリポジトリへ保存し、CLIやIDEでも利用し、必要に応じてスクリプトやMCP、プラグインと組み合わせられる。録画で大枠を教えた後、壊れやすい画面操作をコードやAPIへ置き換える発展経路が明確だ。
一方でRecord & Replayそのものは、発表時点ではmacOS限定であり、Computer Useが有効な対象ユーザーに限られる。EEA、英国、スイスは初期対象外である。日本は明示的な除外地域には含まれていないが、「対象ユーザー」への段階的提供であるため、契約プランだけで必ずメニューが表示されるとは限らない。
さらに、Codex、ChatGPT Work、その他のエージェント機能は共通の利用量・クレジット枠を消費し、作業の規模や複雑さによって消費量が異なる。録画スキルを大量の定期処理へ展開する場合、実行コストも評価指標へ含めるべきだ。
結局、UI録画とAPI自動化は競合しない
理想的なのは、すべてを画面操作で実行することではない。
画面録画は、現場の暗黙知を収集し、業務の草案を作る手段として優れている。API、コネクタ、スクリプトは、それを高速かつ安定して実行する手段として優れている。
したがって実務では、
録画で教える → AIがスキルへ抽象化する → 人間が修正する → 安定部分をAPIやスクリプトへ置換する
という組み合わせが最も強い。
9．30日で導入するロードマップ
第1週：候補業務を洗い出す
各部署から反復業務を20件程度集め、次の式で優先順位を付ける。
**自動化候補スコア ＝ 頻度 × 1回当たり削減時間 × 利用人数 × 手順安定度 ÷ リスク ÷ 例外発生率**
最初に選ぶのは、高頻度、低リスク、手順安定、結果を検証しやすい業務である。
メール送信、支払い、削除、人事評価、契約確定などは最初のパイロットから外す。
第2週：三つのスキルを録画する
異なる性質の三業務を選ぶ。
- データ取得・整理型
- 文書作成型
- 複数アプリ操作型
録画者は業務の熟練者、レビュー担当は業務責任者とする。目的、入力、判断基準、禁止事項、完了条件を録画の冒頭で説明する。
第3週：テストと改善を行う
正常系だけでなく、欠損、重複、権限不足、ゼロ件、UI差分などを試す。
手作業とスキル利用を比較し、次を測定する。
- 所要時間
- 完了率
- 誤りの件数
- 人間による修正回数
- 再実行回数
- 使用量またはクレジット
- 承認待ち時間
- セキュリティ上の問題
時間短縮だけでなく、品質のばらつきが減ったかを確認する。
第4週：共有と限定自動化
品質基準を満たしたスキルだけを、部署またはチームへ共有する。
最初は明示的に起動させ、実行結果を人間が全件確認する。十分な実績が得られた後、低リスクな処理だけスケジュール実行へ移す。
月次または四半期ごとに、業務ルール、UI、権限、判断基準が変わっていないか再評価する。
10．競争の本質は「どちらのAIが賢いか」ではなくなる
OpenAIが約1か月先行していたからといって、AnthropicがOpenAIを模倣したと断定する根拠にはならない。画面上の実演から手順を抽出する「Programming by Demonstration」は以前から存在する考え方であり、コンピューター操作能力を持つAIエージェントが成熟すれば、両社が同じ地点へ到達するのは自然である。
今後の競争軸は、録画機能の有無だけではない。
- 実演からどれだけ正確に判断ルールを抽出できるか
- UI変更や例外へどこまで適応できるか
- 作られたスキルをどれだけ簡単に編集できるか
- チームで安全に共有・更新できるか
- API、ブラウザ、ローカルアプリをどう使い分けるか
- スキルが正しく起動したかを評価できるか
- 実行内容を監査できるか
- 危険な操作に承認を要求できるか
- 業務コストに見合う利用量で動くか
といった、運用基盤全体へ移る。
企業にとって本当に価値があるのは、録画ファイルではない。
「この会社では、どの状況で、どの情報を見て、どのように判断し、何を品質基準として仕事を完了するか」という組織固有の知識である。
これまで、その知識はベテラン社員の頭、個人メモ、画面共有、引き継ぎ会議、古くなった手順書へ分散していた。Record a skillやRecord & Replayは、それをAIが実行可能な形式へ変える入口になる。
ただし、何でも録画すればよいわけではない。
最も有効な導入サイクルは、次の形だ。
Record：仕事を実演する
Abstract：目的、判断、例外をスキルへ抽象化する
Review：人間が内容と権限を確認する
Evaluate：正常系と失敗系で評価する
Govern：所有者、版、禁止事項を管理する
Automate：安全な範囲だけ自動・定期実行する
ClaudeとChatGPT／Codexの競争によって、業務自動化は「AIへうまく指示を書ける人の道具」から、「自分の仕事を実演できる人の道具」へ広がろうとしている。
この変化の最大の受益者は、必ずしもエンジニアではない。仕事を深く理解しているが、コードやプロンプトを書くことには慣れていない現場担当者である。
そして企業にとっての最大の機会は、人をAIへ置き換えることではなく、優れた担当者の仕事の仕方を、検証可能で更新可能な組織能力へ変えることにある。
