投稿者 投稿日: カテゴリー ChatGPT
OpenAI Operatorとは、AIが専用ブラウザでクリックや入力を代行し反復作業を自動化する仕組みのことです。
2025年7月17日、OpenAIは単体サービスだったOperatorを「ChatGPT agent」としてChatGPTに統合し、composerのドロップダウンから「agent mode」を選ぶだけでブラウザ操作・リサーチ・対話を1つのエージェントに任せられるようになりました。EC運営の現場では、競合の価格を毎朝モールで見て回る作業や、在庫が減った商品の発注画面を開いて数量を整える下準備に、いまも人の手が張り付いています。この記事は、その定型ブラウザ作業をどこまでOperatorに渡せるか、そしてどこからは渡してはいけないかを、楽天やAmazonの規約を踏まえて線引きするための実装ガイドです。
ChatGPT agent統合でEC業務の何が変わったのか
OpenAIが2025年1月に公開したOperatorは、自分専用のブラウザでWebページを見て、タイピング・クリック・スクロールして操作するAIエージェントです。フォーム入力やネット注文のような反復的なブラウザ作業を代行する点が、従来のチャット型AIと決定的に違います。テキストで回答を返すだけでなく、画面を実際に触って作業を前に進める。ここがEC運営にとっての転換点でした。
技術的な核はComputer-Using Agent（CUA）と呼ばれる仕組みです。画面のスクリーンショットで現在の状態を取得し、推論モデルが次のアクションを決定し、クリックやスクロールやタイピングを実行する。この取得・推論・実行のループを反復することで、人が画面を見ながら手を動かす作業を模倣します。APIで構造化データを受け渡すのではなく、人と同じように画面越しに操作するため、専用のAPIが用意されていないモール管理画面やニッチなツールでも動かせる余地があるわけです。
2026年に入ってからは、OperatorがDeep ResearchおよびChatGPTと統合され、単一のエージェント的システムになりました。ブラウザ操作・リサーチ・対話の3機能が1つにまとまったことで、たとえば「競合10店舗の価格を調べて、その結果を表形式で要約し、自店より安い商品だけ抜き出す」といった、操作と分析が連続する仕事を1回の指示で流せるようになっています。2026年6月時点のフラッグシップはOpenAIのGPT-5.5系で、同時期にAnthropicはClaude Opus 4.8、GoogleはGemini 3.5系を出しており、ブラウザ操作型エージェントは各社が競って強化している領域です。
EC運営の現場で繰り返し見るのは、店長やEC担当者の時間が「調べる」と「転記する」に溶けていく構図です。競合の価格を毎日チェックする、レビューを読んで傾向を拾う、在庫が減った商品の発注数を計算して発注画面に入れる。どれも判断は数秒で済むのに、画面を開いて目的の項目までたどり着く操作に時間を取られます。Operatorが効くのは、この「判断は軽いが操作が重い」領域です。生成AIをEC業務に入れる順番を整理したEC×AI導入の最初の90日でも、最初に手を付けるべきは判断の重い領域ではなく、操作が重く再現性の高い定型作業だと整理しています。
従来のRPA（パソコン操作を録画して再生する自動化ツール）との違いも押さえておきたいところです。RPAは画面のボタンの座標やHTMLの構造を手がかりに動くため、モール側が管理画面のデザインを少し変えただけで止まってしまう脆さがありました。Operatorはスクリーンショットを見て推論で次の操作を決めるため、画面が多少変わっても「目的の項目はおそらくここだ」と判断して進める柔軟さがあります。ただしこの柔軟さは諸刃の剣でもあって、指示が曖昧だと意図しない項目を触る余地も生まれます。だからこそ、後述するように禁止事項を具体的に書き込む設計が要になります。
導入を検討する際にまず分けて考えたいのが、API連携で解決すべき作業と、ブラウザ操作で解決すべき作業の境界です。受注データの取り込みや在庫数の同期のように、モールが公式APIを提供している領域は、本来そのAPIや既存の一元管理ツールで処理するのが安定します。Operatorの出番は、APIが用意されていない管理画面の確認作業や、複数のサイトを横断して人が目で見ていた調査のように、機械的な連携では拾いにくい隙間の仕事です。この棲み分けを最初に引いておくと、何でもエージェントに寄せて遠回りになる事態を避けられます。
EC現場でOperatorに任せられる5つの作業
Operatorに渡しやすいのは、入力の形が毎回ほぼ同じで、結果の正しさを人が一目で検証できる作業です。逆に、渡した結果が間違っていても気づきにくい作業は向きません。この観点で、EC運営の定型業務を5つに分けて見ていきます。
1つ目は競合価格の定点調査です。同じジャンルの競合店舗を10〜30店リスト化し、特定商品の価格・送料・ポイント還元を毎朝拾わせる。出力を一覧にして「自店より安い行だけ赤くして」と頼めば、目視すべき範囲が一気に絞れます。食品ギフトのように季節で相場が動くジャンルでは、この定点観測が値付け判断の土台になります。
2つ目はレビュー収集と傾向の要約です。自店および主要競合のレビューを読み込ませ、不満が集中している論点を3〜5個に束ねる。星の数だけでなく、文章のどこに不満が出ているかを拾えるのが、エージェント型の強みです。
3つ目が在庫補充発注の下準備です。ここは慎重に扱う必要があります。発注画面を開いて必要数量を入力するところまでは任せても、最終の発注確定ボタンは人が押す。この線引きを最初から崩さないことが安全運用の肝になります。
4つ目は各モール管理画面での定型確認作業です。受注ステータスの確認、未発送リストの抽出、問い合わせの一次仕分けなど、判断を伴わない確認系の操作はエージェント向きです。ただしモールの規約上の制約があるため、後述のチェックを必ず通します。
5つ目がフォーム入力やデータ転記です。展示会で集めた名刺情報のCRMへの入力、商品マスタの一部項目の流し込みなど、コピーと貼り付けの繰り返しはエージェントが得意とします。アパレル系の単一店舗で試したケースでは、サイズ展開ごとに同じ説明文を貼り直す作業を任せ、担当者は仕上がりの確認に回ることができました。
ここで決定的に重要なのが、安全機能の理解です。Operatorはログイン情報の入力やCAPTCHA応答など機微な操作の場面では、ユーザーに確認を求めます。重要な操作の前に許可を求め、ユーザーはいつでも割り込んで操作を引き継いだり停止したりできる設計です。つまり「全部お任せ」ではなく「人が要所で承認する」前提で組まれている。この承認ステップを邪魔に思って飛ばす設計にすると、安全装置を自分で外すことになります。生成AIモデルごとの得手不得手はChatGPT・Claude・Geminiの使い分けで整理していますが、ブラウザ操作の代行という用途では、まずChatGPTのagent modeから検証するのが現実的でした。
Operatorへ投げる指示の実装手順（プロンプト4本）
エージェントへの指示は、通常のチャットプロンプトとは設計思想が違います。「何を出力してほしいか」ではなく「どの画面で、何を見て、どう操作し、どこで止まるか」を順序立てて書く。とくに止まるべき地点を明示しないと、エージェントが勝手に確定操作まで進むリスクが残ります。ここでは用途別に4本のプロンプト例を用意しました。いずれもagent modeに貼って使う前提です。実際の運用では、自店のジャンルや管理画面の名称に合わせて中括弧の変数を置き換えてください。
最初は競合価格の定点調査です。調べる対象店舗と項目を固定し、出力形式まで指定することで、毎朝同じ粒度の結果が返ります。確定操作を含まない読み取り専用の作業なので、エージェントに渡しやすい入口になります。
（用途タイトル：競合価格の定点調査）
あなたはEC運営を支援するリサーチアシスタントです。
これから指定する競合店舗のページをブラウザで開き、対象商品の情報を読み取って一覧にしてください。
対象ジャンル：{ジャンル}
対象商品キーワード：{第1KW、第2KW}
調査する競合店舗URL：
- {店舗URL1}
- {店舗URL2}
- {店舗URL3}
各店舗で読み取る項目：
1. 商品名
2. 税込価格
3. 送料（無料/有料の別と金額）
4. ポイント還元率の記載があれば
5. 在庫状況（在庫あり/在庫切れ/予約）
ルール：
- 価格を変更したり、カートに入れたり、注文に進む操作は一切しない（読み取りのみ）
- ログインが必要なページに当たったら、操作を止めて私に確認を求める
- 読み取れなかった項目は「取得不可」と明記する
出力：店舗名・商品名・価格・送料・ポイント・在庫の一覧。最後に、最安値の店舗と自店想定価格{自店価格}を下回る店舗だけを抜き出して列挙する
次はレビューの傾向要約です。集めて終わりではなく、対応の優先度まで添えさせることで、読んだ後にすぐ施策へ移れます。
（用途タイトル：自店・競合レビューの傾向要約）
あなたはECの顧客満足度分析の担当者です。
指定するページのレビューを読み込み、不満と満足の論点を整理してください。
読み込み対象：
- 自店商品ページ：{自店商品URL}
- 競合商品ページ：{競合商品URL}
整理の手順：
1. 各ページのレビューを新しい順に最大50件まで読む
2. 不満が書かれているレビューを抽出し、論点を3〜5個に分類する（例：梱包、配送日数、サイズ感、説明との差異）
3. 満足の論点も同様に3〜5個にまとめる
4. 自店と競合で、不満の出方がどう違うかを比較する
ルール：
- レビューに返信したり、投稿者へ接触する操作はしない（読み取りのみ）
- 具体的な個人が特定できる記述は要約に含めない
出力：不満論点・件数の目安・代表的な記述の要旨・改善の優先度（高/中/低）を、論点ごとに文章でまとめる
3本目が在庫補充発注の下準備です。ここでは確定操作の直前で必ず止めるよう、二重に指示しています。数量を入れるところまでが自動、確定は人。この境界を守らせることが最重要です。
（用途タイトル：在庫補充発注の下準備・確定は人が行う）
あなたはEC運営のオペレーション担当です。
在庫が減った商品の補充発注の「下準備」だけを行ってください。発注の確定は絶対に行いません。
作業対象の管理画面：{発注管理画面URL}
補充ルール：
- 在庫数が{しきい値}個を下回った商品を対象にする
- 発注数量は「{標準在庫数}−現在庫数」を基本とする
- 1回の発注上限は{上限数}個とする
手順：
1. 管理画面で在庫数を確認し、しきい値を下回った商品をリスト化する
2. 各商品の発注数量を上のルールで計算する
3. 発注画面に商品と数量を入力するところまで進める
絶対に守るルール：
- 「発注を確定する」「注文を送信する」に相当するボタンは押さない
- 入力が終わったら必ず操作を止めて、私に内容の確認を求める
- 金額・数量に少しでも不明点があれば、入力せず私に質問する
出力：入力した商品・数量・想定発注金額の一覧。最後に「確定操作は行っていません。内容をご確認ください」と明記する
4本目は受注確認など、判断を伴わないモール内の定型確認です。何を見て、何を抜き出すかだけを依頼し、状態を変える操作は禁じます。
（用途タイトル：受注ステータスの確認と未発送リスト抽出）
あなたはEC運営の受注処理担当です。
指定する管理画面で、未発送の注文を確認してリスト化してください。状態を変更する操作はしません。
対象画面：{受注管理画面URL}
抽出条件：
- ステータスが「未発送」または「発送待ち」の注文
- 注文日が{対象期間}のもの
手順：
1. 該当条件で注文を絞り込む
2. 各注文の注文番号・注文日・商品名・数量・配送希望日を読み取る
3. 配送希望日が近い順に並べ替える
絶対に守るルール：
- 発送処理、ステータス変更、キャンセル、顧客への連絡など、状態を変える操作は一切しない（読み取りと並べ替え表示のみ）
- 個人情報（氏名・住所・電話番号）は出力に含めず、注文番号で識別する
出力：注文番号・注文日・商品名・数量・配送希望日の一覧を、配送希望日が近い順に
これら4本に共通するのは、確定・送信・状態変更を禁じる一文を必ず入れていることです。エージェントは指示の空白を自分で埋めようとするため、禁止事項を書かないと「親切心」で確定まで進むことがあります。もう一つの共通点が、出力形式を最後に具体的に指定していること。どの列を、どの順で、何を抜き出すかまで書いておくと、毎回同じ粒度の結果が返り、人の確認作業が軽くなります。逆に「いい感じにまとめて」とだけ頼むと、日によって出力の形がぶれて、結局そろえ直す手間が生まれます。
商品説明文そのものの生成は別領域なので、ChatGPTの商品説明プロンプト集を併用し、Operatorは生成物の貼り付けや反映の操作に限定するのが、役割分担として整理しやすい組み方でした。文章をつくるのは対話型のChatGPT、つくった文章を画面に流し込むのはエージェント、という分担です。この切り分けを意識すると、どちらのツールに何を頼むべきかが現場で迷わなくなります。
モール規約に抵触させない安全運用の線引き
ここが競合記事の大半が触れていない、最も重要な論点です。Operatorは便利ですが、各モールの規約では自動操作やスクレイピングが禁止または制限されている場合があります。便利さに引きずられて規約を踏み越えると、アカウント停止という最悪の結果を招きかねません。
楽天市場では、楽天RMSやモール上の運用に関して、ボットによる自動操作やスクレイピングが規約で制限される可能性があります。とくに楽天R-Mailや商品ページの運用では、楽天市場外への誘導が禁止されており、エージェントに「自社サイトへのリンクを商品ページに入れて」といった指示を出すこと自体が規約違反の運用設計になります。Operatorで楽天関連の作業を組むなら、楽天市場内で完結する操作（件名・本文の下書き、配信時間帯の整理、モール内の他商品ページへの遷移リンクの確認など）に限定し、外部URLを差し込む自動化は設計から外すべきです。自動操作の可否そのものについては、楽天RMSの規約を必ず一次情報で確認してください（要確認）。
Amazonでも同様の配慮が要ります。Amazon Seller Central上での自動操作が規約上どこまで許容されるかは、利用規約の確認が前提です（要確認）。さらにAmazonでは、商品ページの商品紹介コンテンツ（A+）内に外部URLを置くことが原則として認められておらず、レビュー誘導に特典を絡める運用も規約違反にあたります。Operatorに「レビューを書いた人へ割引クーポンの連絡をして」といった指示を出すのは、自動化以前に規約違反です。
現場で安全に運用するための線引きを整理すると、次のようになります。読み取り専用の調査・確認はリスクが低く、状態を変える操作（発注確定、ステータス変更、顧客への連絡、価格変更）はリスクが高い。後者はOperatorに任せず、人が承認・実行する。この境界をプロンプトに毎回明記し、Operatorの確認ステップを無効化しない。ログイン情報の扱いも要注意で、エージェントにIDとパスワードを直接書いて渡すのではなく、Operatorが機微な操作で確認を求める設計を活かして、人がその場でログインする運用にとどめるのが安全です。
楽天/Amazonの両方を回している店舗で観測されたのは、規約への配慮を業務マニュアルに落とし込んでいるかどうかで、新しいツールの入れやすさが変わるという点です。「このプロンプトでは外部URLを差し込まない」「確定ボタンは押させない」といった禁止事項を、エージェント任せにせず店舗側のルールとして明文化しておく。そうしておけば、担当者が交代してもプロンプトをそのまま引き継げますし、規約の境界線を踏み越えるリスクも下がります。Yahoo!ショッピングは楽天より規約が緩いとされますが、2024年以降ガイドラインが強化される流れにあり、店舗から外部へのメール内リンクは推奨されません。どのモールでも「外部誘導」と「自動操作」の2点は、エージェントを使う前に必ず一次情報で線引きを確認しておくべき論点です（要確認）。
直近の支援案件で観測したのは、自動化の範囲を「読み取りと下準備まで」に固定した店舗ほど、トラブルなく運用を続けられているという傾向でした。一方で、確定操作まで一気に自動化しようとした例では、想定外の画面遷移でエージェントが迷い、結局人が後追いで確認する二度手間が発生していました。最初から欲張らず、操作が重く判断の軽い読み取り系から入るのが定石です。範囲を広げるのは、修正がほぼ要らなくなってからで遅くありません。
KPI設計と費用・工数の目安
Operator（ChatGPT agent）はChatGPTの有料プランで利用でき、ChatGPT Plusは月額20米ドルが目安です（2026年6月時点の見込み、最新の提供条件と対象プランは公式の料金ページで要確認）。EC事業者にとっては、この月額で「調べる・転記する」工数がどれだけ減るかが投資判断の軸になります。
工数削減の見立てとしては、競合価格の定点調査に毎朝30〜45分かけていた店舗が、エージェントの出力を確認するだけの5〜10分に短縮できた、という現場感覚があります（業界平均の目安。店舗のジャンルや競合数で変動）。レビュー要約も、これまで週次で1〜2時間かけていた手作業が、出力のチェック中心になることで体感の負担は半分以下になりました。数字そのものより、担当者の時間が「操作」から「判断」へ移ることに価値があります。
KPIとして追うなら、対象業務にかけていた人時間の削減幅、確認に要した時間、そしてエージェントの出力にどれだけ修正が必要だったかの修正率を見るのが実務的です。修正率が高いうちはプロンプトの指示が曖昧な証拠なので、禁止事項と出力形式を具体化していく。修正率が下がってきたら、その業務はエージェントに安定して任せられる段階に入ったと判断できます。費用対効果は、削減できた人時間を時給換算した額が月額利用料を上回るかで素直に測れます。
工数の見える化には、導入前の2週間と導入後の2週間で、同じ業務にかけた時間を記録して比べる方法が手堅いです。たとえば競合価格調査なら、導入前は「店舗を開く・探す・転記する」までの一連で何分かかっていたか、導入後はエージェントの出力を確認して値付けを決めるまで何分かかったか。この前後比較を数字で残しておくと、社内で次の業務への展開を提案するときの説得材料になります。化粧品やサプリのように競合数が多く価格改定が頻繁なジャンルほど、調査の自動化は効きやすい一方、対象店舗が数店しかないニッチなジャンルでは、人が見たほうが速いこともあります。自店のジャンル特性に合わせて、効果の出やすい業務から優先順位を付けるのが現実的でした。
費用面では、ChatGPTのほかに比較対象としてClaude ProやGemini Advancedもそれぞれ月額20米ドル前後が目安です（2026年6月時点の見込み、各社の最新料金は要確認）。ただしブラウザ操作という用途では、まず1つのサービスで運用を固めてから他を比較するほうが、ノウハウが分散せずに済みます。複数を並行で契約して結局どれも中途半端、という状態は避けたいところです。
AIエージェント時代にEC運営はどう備えるか
ブラウザ操作型エージェントの進化は、EC運営の競争軸を少しずつずらしています。これまでは「定型作業をいかに速くこなすか」が現場力でしたが、その部分がエージェントに移れば、差がつくのは「何をエージェントに任せ、どこを人が握るか」の設計力に変わります。任せ方の巧拙が、そのまま運営の余力を生むわけです。
注目すべきは、各モールが自動操作をどう位置づけ直すかという論点です。現状は規約で制限される領域が多いものの、エージェント前提の業務が一般化すれば、モール側が公式に「許容される自動操作」のラインを示す動きが出てくる可能性があります。そのときに慌てないためにも、いまのうちから読み取り系・下準備系に範囲を絞って運用ノウハウを溜めておくことが、先行者の備えになります。
もう一つの独自論点が、AI Overviewやエージェント検索への対応です。OperatorやChatGPT agentのようにAIが情報を取りに来る世界では、自店の情報がエージェントに正しく読み取られる構造になっているかが効いてきます。商品説明が画像内テキストばかりで機械可読でない、価格や在庫の表示が崩れている、といった状態は、人にもエージェントにも不利になる。GPT-5.5系を含む最新モデルのEC活用の全体像はGPT-5.5のEC活用で扱っていますが、エージェントに読まれる前提でページを整えることが、これからのSEOと業務効率化の交差点になります。5,000社支援の中で何度も再現したパターンとして、情報が整理されている店舗ほど、新しいツールを入れたときの立ち上がりが速いという傾向があります。
よくある質問
OpenAI Operatorは無料で使えますか
Operatorは現在ChatGPTのagent modeとして提供されており、利用には有料プランが必要です。ChatGPT Plusは月額20米ドルが目安ですが、対象プランや提供条件は変わる可能性があるため、最新の料金ページで確認してください（2026年6月時点の見込み）。
楽天やAmazonの管理画面を自動操作させても規約違反になりませんか
なる可能性があります。楽天RMSやAmazon Seller Centralでは、ボットによる自動操作やスクレイピングが制限される場合があるため、各モールの規約を一次情報で必ず確認してください（要確認）。安全策としては、状態を変える操作は人が行い、Operatorは読み取りや下準備にとどめるのが現実的です。
Operatorにログイン情報を渡しても大丈夫ですか
Operatorはログイン情報の入力やCAPTCHA応答など機微な操作で、ユーザーに確認を求める設計です。IDやパスワードをプロンプトに直接書いて渡すのではなく、エージェントが確認を求めた場面で人がその場でログインする運用が安全です。重要な操作の前には許可を求める仕組みを無効化しないでください。
ChatGPT・Claude・Geminiのどれでブラウザ操作を試すべきですか
ブラウザ操作の代行という用途では、ChatGPTのagent modeから検証するのが現実的でした。各モデルの得手不得手は用途で変わるため、まず1つで運用ノウハウを溜め、必要に応じて比較するのがよいでしょう。詳しくは使い分けの記事を参照してください。
導入の最初の一歩は何をすればよいですか
読み取り専用で結果を一目で検証できる作業から始めるのが定石です。競合価格の定点調査や受注の未発送リスト抽出など、間違っても気づける作業を1つ選び、確定操作を禁じるプロンプトで小さく試してください。修正率が下がってから次の業務へ広げます。
発注や価格変更まで全部自動化できますか
技術的には操作可能でも、自動化はおすすめしません。発注確定・価格変更・ステータス変更・顧客連絡といった状態を変える操作は、間違いに気づきにくく影響も大きいためです。これらは人が承認・実行し、Operatorは入力や下準備までに範囲を固定するのが安全運用の基本になります。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
