ChatGPT WorkのData AgentでEC売上を読む｜BIを増やさない運用とプロンプト5本

齋藤竹紘2026年10月18日2026年10月18日ChatGPT

ChatGPT WorkのData Agentとは、社内データを会話で分析しダッシュボードまで作るAI機能のことです。

楽天RMSの受注CSV、Amazonのビジネスレポート、Shopifyの売上レポート、RPPやスポンサープロダクト広告の実績表。月末になると、この4〜5種類のファイルを手作業でスプレッドシートに貼り合わせ、「先月より売上が落ちた理由」を探すだけで半日が消えていく店舗は少なくありません。OpenAIが2026年9月にChatGPT Work向けに出したData Agent（データエージェント）は、この「数字を集めて、変化の理由を探して、見える形にする」作業を会話だけで進めるための機能です。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、Data Agentで何ができて何ができないのか、BIツールを新たに増やさずにEC売上を読む体制をどう組むかを、そのまま使えるプロンプト5本とあわせて整理します。

Data Agentは「数字を探す人」の仕事をどう変えるのか

Data Agentが変えるのは、ダッシュボードを作る作業そのものより「なぜ数字が動いたのかを探る時間」です。OpenAIは2026年9月10日にこの機能を公開し、OpenAIの発表では、社内データに接続して何が変わったかを調べ、共有できるダッシュボードを作り、クエリを書かずに1つの会話の中で分析を深められる機能として紹介されています。

使い方の起点は、ChatGPT Workの会話で「@Data」と呼び出すことです。OpenAIのヘルプセンターによると、ワークスペースでData用のプラグインが使える状態になっていること、さらに分析したいデータ源ごとのプラグインも有効になっていることが前提条件です。導入は管理者がワークスペース設定のプラグインディレクトリからインストールし、データ源を1つずつ接続していく流れだと、Lead with AIは伝えています。同記事はこの機能を「新機能が今後追加される初期版」と位置づけており、2026年10月時点でも仕様は動いている段階です。

接続先として報じられているのは、Amazon Redshift、Google BigQuery、ClickHouse、Databricks、MongoDB、Snowflakeといったデータウェアハウス群に加え、ファイル置き場としてのGoogle DriveとSharePointです（aicybr）。既存のBIツールとの連携先にはTableau、Power BI、Sigma、Omni、Oracle BI、ThoughtSpotが挙がっています。ただし利用できる接続先はワークスペースによって異なるとされ、自社の画面で確認するのが確実です。

権限まわりの設計も押さえておくべき点です。クエリは接続したアカウントが持つテーブル単位・行単位・列単位の権限をそのまま守るとされ、どのデータ接続を誰が使えるかは管理者がロールごとに決めます。店長には売上と広告のデータだけ、経理担当には原価まで、という切り分けを、データ源側の権限で表現できる設計です。

日本のEC事業者にとっての問題は、接続先の一覧に楽天RMSもAmazonセラーセントラルも入っていないことでした。BigQueryやSnowflakeに受注データを流し込んでいる中小ECはまだ少数派です。現場で繰り返し見るのは、モールの管理画面からCSVを落とし、Excelかスプレッドシートで加工して終わり、という運用です。この前提のまま使える入口は、Google DriveかSharePointに整えたファイルを置く方法と、GA4のBigQueryエクスポートのように既に無料で使えるデータ連携を足がかりにする方法の2つに絞られます。

もう1つ見落とされがちなのが、Data Agentが「指標の定義」を参照する設計になっている点です。報道では、dbtやDatabricks Genie Ontology、既存のBIダッシュボードを定義の参照元として使い、「アクティブ顧客」「月次売上」といった社内用語の計算式に答えを合わせるとされています。ECでいえば、売上を税込で見るのか税抜で見るのか、キャンセルや返品を引くのか、楽天スーパーポイントの原資負担を差し引くのか、といった定義です。ここが曖昧なままだと、AIがどれほど賢くても答えは社内の誰の数字とも合いません。

自社ECで使うときのデータの集め方と住み分け

Data Agentを中小ECで生かす現実的な形は、「定例の数字は今のシートで見て、変化の理由探しをData Agentに任せる」という住み分けです。毎週同じ形で見る売上・アクセス・転換率の表は、既に回っているスプレッドシートやLooker Studioのレポートを無理に置き換える必要はありません。Data Agentの出番は、「先週火曜から楽天の転換率が0.4ポイント落ちた理由は何か」のように、毎回違う切り口で掘る問いです。

データの集め方は、Google Driveに専用フォルダを1つ作り、モールごとのエクスポートを決まった名前で置いていく方式が始めやすいでしょう。たとえば「受注_楽天_2026-10」「受注_Amazon_2026-10」「広告_RPP_2026-10」「在庫_全モール_2026-10-15」のように、データの種類・モール・期間がファイル名で分かる形にそろえます。ファイル形式としてCSVやスプレッドシートがどこまで正しく読めるかは公式に明記されておらず要確認ですが、ファイル名と列名の規則がそろっていれば、AIがファイルを取り違えるリスクは大きく下がります。

列名の統一も効きます。楽天の受注CSVとAmazonの注文レポートでは、注文日、商品管理番号とSKU、数量、金額の列名がそれぞれ違います。Data Agentに毎回「楽天の『注文日時』とAmazonの『purchase-date』は同じ意味です」と説明させるより、Driveに置く前に共通の列名へ寄せた整形版を1枚作っておくほうが、質問のたびの手戻りが減ります。整形の考え方は、うるチカラのEC月次経営レポートを自動化するスキルの解説が参考になります。

個人情報の扱いは最初に決めておくべきです。楽天やAmazonの受注データには、購入者の氏名、住所、電話番号、メールアドレスが含まれます。売上分析にこれらの列は不要なので、Driveへ置く段階で削除するか、会員番号のような識別子だけ残す形にします。ある食品ギフトの中規模店舗の事例では、分析用フォルダに住所入りの受注CSVをそのまま置いてしまい、共有範囲の見直しに1週間かかりました。分析の便利さより先に、置いてよいデータの線引きを社内ルールにしておくのが定石です。

GA4のデータを使っている店舗なら、GA4からBigQueryへのエクスポート機能を有効にしておくと、Data AgentのBigQuery接続からアクセス解析のデータを直接読める道が開けます。自社EC（Shopifyなど）の流入経路と売上の関係を掘りたい場合は、この経路が最も手堅い選択肢です。Shopifyの検索データとGA4をつなぐ考え方は、ShopifyのGA4とSearch Consoleのレポートを作るスキルの記事でも扱っています。

ChatGPT Work自体の業務自動化の全体像を先に押さえたい方は、ChatGPT WorkでEC業務を自動化するガイドから読むと位置づけがつかみやすくなります。

Data AgentでEC売上を読むための5つの手順とプロンプト

ここからは、BIツールを増やさずにData AgentでEC売上を読む体制を作る手順を、5本のプロンプトとあわせて示します。プロンプトはChatGPT WorkのData Agent向けに書いていますが、「@Data」の部分を外し、CSVを添付する形にすれば、ClaudeやGeminiでも同じ考え方で使えます。

手順1は、指標の定義書づくりです。AIに分析させる前に、自社の「売上」「粗利」「転換率」が何を指すのかを文書にしておきます。社内で定義が割れているときは、その割れ方自体を洗い出すところからAIに手伝わせます。

プロンプト1：EC指標の定義書を作る

あなたはEC事業の管理会計に詳しいアナリストです。
以下の条件で、当社のEC指標定義書の下書きを作ってください。

運営チャネル：{楽天市場、Amazon、自社EC（Shopify）など}
売上の計上タイミング：{注文日 or 発送日}
扱う指標：売上、粗利、注文件数、客単価、転換率、広告費、ROAS、返品率

条件：
1. 各指標について「定義」「計算式」「含めるもの」「除くもの」を書く
2. 税込・税抜、キャンセル、返品、クーポン値引き、ポイント原資負担の扱いを必ず明記する
3. モールごとに元データの列名が違う場合は、対応表を文章で示す
4. 定義が社内で決まっていない項目は「要決定」と書き、決めるための論点を1行添える

出力：Googleドキュメントに貼れる見出し付きの文章

手順2は、売上変動の要因分解です。Data Agentの得意分野で、「何が変わったか」を数字の根拠つきで返させます。根拠を必ず出させる指示を入れておくと、後の検証が楽になります。

プロンプト2：先週の売上変動の理由を探す

@Data
Google Driveの「EC分析」フォルダにある受注データと広告データを使って、
{期間A}と{期間B}の売上の差を要因分解してください。

条件：
1. 指標の定義は同じフォルダの「指標定義書」に従う
2. 売上の差を「チャネル別」「商品カテゴリ別」「アクセス数×転換率×客単価」の3つの切り口で分解する
3. 差への寄与が大きい順に上位5つの要因を挙げる
4. 各要因について、根拠にしたファイル名・列名・集計値を必ず示す
5. データから断定できないことは「推測」と明記する

最後に、追加で確認すべきデータがあれば3つまで挙げてください。

手順3は、広告費の週次チェックです。RPPやスポンサープロダクト広告は、気づいたときには予算を使い切っていることがよくあります。毎週同じ問いを投げ、ROASが急に崩れた商品だけを拾います。

プロンプト3：広告のROAS崩れを週次で拾う

@Data
「EC分析」フォルダの広告実績データ（{楽天RPP、Amazonスポンサープロダクト広告}）を使って、
直近7日間と、その前の28日間の平均を比べてください。

条件：
1. 商品単位でROASを計算する（ROAS＝広告経由売上÷広告費）
2. 直近7日間のROASが前28日平均の{70}%未満に落ちた商品を一覧にする
3. 各商品について、クリック数・CPC・転換率のどれが主因かを1行で書く
4. 広告費が{5,000}円未満の商品は判断材料が少ないため対象外にする
5. 対応案は「入札を下げる」「キーワードを除外する」「商品ページを直す」の3択から選び、理由を添える

手順4は、在庫と販売速度の突き合わせです。売上分析と在庫データを同じ会話で扱えるのがData Agentの利点で、欠品による機会損失と、売れない在庫の積み上がりを同時に見られます。

プロンプト4：欠品リスクと滞留在庫を同時に洗い出す

@Data
「EC分析」フォルダの在庫データと直近{60}日分の受注データを使って、
SKUごとの販売速度（1日あたり販売数）と在庫日数を計算してください。

条件：
1. 在庫日数＝現在庫÷1日あたり販売数
2. 在庫日数が{14}日未満で、仕入れリードタイム{21}日より短いSKUを「欠品リスク」として一覧にする
3. 在庫日数が{180}日を超えるSKUを「滞留在庫」として一覧にする
4. 季節商品（{ギフト、夏物など}）は別枠にして、通常品と混ぜない
5. 各SKUに、根拠にしたファイル名と集計期間を添える

手順5は、ダッシュボードの設計と検証です。Data Agentは対話の結果を、編集・更新・共有できるダッシュボードにまとめられます。ただし、作る前に「誰が、何を判断するための画面か」を決めておかないと、指標を詰め込んだだけの画面になります。作ったあとに数字の検算をさせる指示まで、1本のプロンプトにまとめておきます。

プロンプト5：店長会議用ダッシュボードを作って検算する

@Data
店長会議（毎週{月曜}）で使うダッシュボードを作ってください。

目的：先週の売上の良し悪しを10分で判断し、今週の打ち手を1つ決めること
表示する指標：売上、注文件数、客単価、転換率、広告費、ROAS（チャネル別と全体）
比較対象：前週、前年同週

条件：
1. 指標の定義は「指標定義書」に従う
2. 1画面に収め、グラフは6つまでにする
3. 作成後、全体売上の数値を元データから再集計し、ダッシュボードの値と一致するか検算した結果を報告する
4. 一致しない場合は、差の原因（期間のずれ、キャンセルの扱いなど）を説明する
5. 個人を特定できる列（氏名、住所、電話番号、メールアドレス）は使わない

5本を回す順番は、定義書を1回作り、要因分解と広告チェックを毎週、在庫の突き合わせを隔週、ダッシュボードは最初に1回作って毎週更新、というリズムが無理のない形です。

導入でつまずく3つのパターンと回避策

1つ目は、指標の定義がずれたまま分析を始めてしまうパターンです。楽天の売上を「クーポン値引き前」で見ている店長と、「値引き後の入金ベース」で見ている経理担当では、同じ月の売上が数%ずれます。Data Agentに両方のデータを渡して「売上は？」と聞くと、どちらの定義に寄せたかによって答えが変わり、会議で「AIの数字が合わない」という話になります。回避策は単純で、プロンプト1の定義書を先に作り、すべての質問で「定義書に従う」と書き添えることです。

2つ目は、CSVの文字化けと列ずれです。楽天RMSからダウンロードするCSVはShift_JISで出力されるものが多く、そのまま別のツールに読ませると日本語の列名や商品名が化けることがあります。化けた状態でAIに集計させると、商品名の照合がずれて「売れていない商品」が誤って出てきます。Driveに置く前にUTF-8で保存し直し、先頭の数行を目で確認する工程を1つ挟むだけで防げます。

3つ目は、共有範囲の甘さです。OpenAIのヘルプセンターでは、ダッシュボードを社内向けサイトとして公開する場合、分析に使ったデータが公開先にコピーされる点に注意を促しています。楽天やAmazonの受注データには個人情報が含まれるため、公開前に使っている列を確認し、閲覧できる人の範囲を絞ることが欠かせません。ALSELが支援する店舗群では、分析用と共有用でフォルダを分け、共有用には集計済みの数字しか置かない運用に落ち着くケースが多くなっています。

運用KPIと費用・工数の目安

効果の測り方は、売上が伸びたかどうかより先に「数字の理由探しにかかる時間」で見ます。月末の振り返りで、複数モールのデータを集めて要因を特定するまでに4時間かかっていた店舗なら、データ置き場と定義書が整ったあとは、質問と検証で1時間前後まで縮むのが現場感覚での目安です。週次の広告チェックも、30分ほどかけていた目視確認が、プロンプト3の結果を読む10分程度に置き換わります。

KPIとしては、要因分解の初回回答から結論が出るまでの往復回数、AIの集計値と元データの検算一致率、会議で「その数字はどこから」と聞かれた回数の3つを月次で記録しておくと、改善が見えやすくなります。検算一致率が9割を切る月は、定義書かデータ整形のどちらかが崩れているサインです。

費用面では、Data AgentはChatGPT Work向けの機能で、管理者によるプラグインの導入が前提です。対象プランについては、Business・Enterprise向けとする報道と、ChatGPT Workの顧客全般とする報道があり、2026年10月時点で料金体系とあわせて要確認です。新しいBIツールを契約する前に、まず既存の契約範囲でData Agentが使えるかを管理画面で確認するのが、余計な固定費を増やさない順番です。

工数の初期投資は、定義書づくりに半日、データ置き場の整理とファイル名ルールの決定に半日、権限設計に2〜3時間ほどを見込んでおくと、最初の1か月で運用が回り始めます。CSV整形を毎月手で行う場合は、その作業自体が月1〜2時間残る点も織り込んでおきます。

今後の展望：モールのデータがAIに直接つながる日まで

今後の焦点は、接続先の拡大と、モール側のデータの出し方です。現状の接続先はデータウェアハウスとファイル置き場が中心で、楽天RMSやAmazonセラーセントラルとの直接連携は報じられていません。当面は、CSVを整えてDriveに置く運用が日本の中小ECにとっての標準ルートになると判断します。

一方で、ChatGPTのプラグインの仕組み上、データ源ごとのプラグインが増えれば接続先は広がっていきます。Shopifyのように外部連携の文化が強いプラットフォームから先に対応が進み、モール系は公式APIの提供範囲に左右される、という順番が現実的な見立てです。社内ツールの内製と組み合わせる考え方は、ChatGPT Workで社内ツールを内製する記事でも触れています。

もう1つの変化は、「ダッシュボードを見る文化」から「AIに問いを投げる文化」への移行です。これまで中小ECでBIが定着しなかった理由の多くは、画面を作っても見に行く人がいなかったことでした。Data Agentは、結果をSlackやメールに送り、次に関わるべき人まで示す方向で設計されていると報じられています。数字を見に行くのではなく、数字の変化が人に届く運用に変わると、店長が毎朝確認すべき情報は今より絞り込まれていきます。

ただし、AIが出した結論をそのまま意思決定に使える段階にはまだありません。Lead with AIも、根拠を確認するステップがあってこそ業務で信頼できる、という趣旨で評価しています。根拠のファイル名と集計値を必ず出させ、人が検算する、という運用を外さないことが、Data Agentを長く使ううえでの前提になります。

よくある質問

ChatGPT WorkのData Agentとは何ですか

ChatGPT WorkのData Agentとは、社内のデータ源に接続し、会話で分析してダッシュボードまで作るAI機能のことです。2026年9月10日に公開され、ChatGPT Workの会話で「@Data」と呼び出して使います。クエリを書かずに「なぜ数字が変わったか」を掘り下げられるのが特徴です。

楽天RMSやAmazonセラーセントラルに直接つながりますか

いいえ、2026年10月時点では直接の接続先として報じられていないからです。報じられている接続先はBigQueryやSnowflakeなどのデータウェアハウスと、Google Drive、SharePointが中心です。モールのデータは、CSVを整形してDriveに置く方法が現実的な入口になります。

既存のBIツールやスプレッドシートは不要になりますか

いいえ、定例の数字を見る仕組みは残したほうがよいからです。毎週同じ形で見る売上表は既存のシートやレポートで続け、変化の理由探しのような毎回違う問いをData Agentに任せる住み分けが効率的です。TableauやPower BIを使っている場合は、Data Agentから既存ダッシュボードを更新する連携も報じられています。

個人情報を含む受注データを読ませても大丈夫ですか

いいえ、分析に不要な個人情報は渡さないのが原則だからです。氏名・住所・電話番号・メールアドレスの列は、Driveに置く前に削除するか、会員番号などの識別子だけ残します。ダッシュボードを社内公開すると分析データが公開先にコピーされる点にも注意が必要です。

どのプランで使えますか

対象プランは2026年10月時点で要確認です。Business・Enterprise向けとする報道と、ChatGPT Workの顧客全般とする報道があります。いずれも管理者がプラグインディレクトリからインストールする必要があるため、まず自社ワークスペースの管理画面で利用可否を確認してください。

ClaudeやGeminiでも同じことはできますか

はい、CSVを添付して分析させる使い方なら同じ考え方で応用できるからです。本記事のプロンプトは「@Data」の行を外し、データを添付する形に変えればClaudeやGeminiでも使えます。ただし、データ源への常時接続やダッシュボードの自動更新は、各サービスの機能と契約範囲によって異なります。

最初の一歩は何から始めればよいですか

最初の一歩は、指標の定義書を作ることです。売上を税込で見るか、キャンセルや返品を引くかといった定義が決まっていないと、AIの答えは誰の数字とも合いません。プロンプト1で下書きを作り、店長と経理の両方で合意してから、データ置き場の整備に進むのが近道です。

まとめ

ChatGPT WorkのData Agentは、EC事業者が月末に費やしてきた「数字を集めて理由を探す」時間を縮めるための機能です。楽天RMSやAmazonとの直接連携はまだありませんが、Google Driveに整えたCSVと指標の定義書があれば、BIツールを新たに増やさずに売上の変化を掘り下げられます。導入は、定義書づくり、データ置き場の整理、権限設計の3つを先に済ませ、プロンプト2の要因分解から試すのが無理のない順番です。根拠のファイル名と集計値を必ず出させて人が検算する運用を守れば、店長会議の議論は「数字が合わない」から「次に何をするか」へ移っていきます。

参考文献

著者：齋藤竹紘（株式会社オルセル編集長／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実装」を一次情報として発信しています。

投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。齋藤竹紘のすべての投稿を表示