Codex Sitesで、EC運用の「ちょっと見える化したい」が早くなる

はじめに

AIリサーチ担当のMia Sato（佐藤ミア）です。

今回は、OpenAIのCodexに追加された「Sites」について紹介します。

最初に見たとき、私はかなり素直に「これは、現場で欲しかったやつかもしれない」と思いました。

というのも、Codex Sitesの面白さは、単にWebサイトや画面を作れることだけではないからです。

最近は、AIに頼めばUI案やアプリのたたき台を作れるツールが増えています。画面を作る。レイアウトを直す。ボタンや表を追加する。ここまでは、他のAIツールでもかなりできるようになってきました。

では、Codex Sitesの違いはどこにあるのか。

ポイントは、Codexが作ったものを、チャット上のコードや画面案で終わらせず、チームで開けるWebページとして保存・公開・確認しやすくするところにあります。

非エンジニアの視点で言うと、ここが一番大きいです。

通常、AIがコードを書いてくれても、それを実際に開けるWebページにするには、置き場所や公開設定が必要です。エンジニアであれば対応できるかもしれませんが、EC運用やCS、販促担当にとっては、そこで止まりがちです。

商品情報はスプレッドシートにある。販促進捗はSlackに流れている。画像素材はDriveにある。確認事項はNotionにある。CSの注意点は別の管理画面にある。

情報はあります。AIで画面案も作れるかもしれません。

でも、会議で全員が同じURLを開き、「今日はこのページを見ながら確認しましょう」と言える状態まで持っていくのは、意外と手間がかかります。

Codex Sitesは、この部分を短くする機能として見ると分かりやすいです。

今回は、Codex Sitesで何ができるのか。そして、EC運用ではどこから試せそうかを整理します。

Codex Sitesの新機能でできること

Codex Sitesは、Codexアプリ内のSites機能を使って、WebサイトやWebアプリを作成し、OpenAIがホストする形で公開できる機能です。

ここで大事なのは、「作る」だけではないことです。

作って、保存して、公開して、あとから確認して直せる。
この一連の流れがCodexの中に入ってきた点が面白いです。

1. 文章で依頼して、Webページや簡単なアプリを作れる

たとえば、次のような依頼ができます。

「新商品の公開準備を確認するためのチェック画面を作ってください」

「問い合わせカテゴリごとの件数を見られる簡単なダッシュボードを作ってください」

これまでなら、まず要件をまとめて、画面イメージを作って、開発者に相談する流れになりがちでした。

Codex Sitesでは、まずたたき台を作るところから始められます。

もちろん、一発で完成品になるという話ではありません。
でも、何もない状態から会話するより、画面を見ながら話すほうが圧倒的に早いです。

2. 作ったものをURLで共有できる

Sitesで作ったものは、URLで共有できます。

これも実務ではかなり効きます。

EC運用では、「最新版はどれですか」がよく起きます。
資料が複数あり、ファイル名が似ていて、会議中に違うバージョンを見てしまうこともあります。

Sitesで共有用のページを作れれば、「このURLを見ながら話しましょう」にできます。

特に、会議前の前提共有には向いていそうです。

資料を読むだけではなく、状況を確認する場所として使える。
ここが普通のドキュメントやスライドと少し違います。

3. 社内向けの軽いツールとして使える

OpenAIの説明では、Sitesは軽量なフルスタックのJavaScriptまたはTypeScriptのWebアプリを作れる機能として案内されています。

ここは少し技術的に聞こえますが、現場目線で言うと、「ちょっとした社内ツールの試作品を作りやすい」ということです。

たとえば、商品公開前の確認リスト。
返品理由の分類メモ。
キャンペーン準備の進捗ボード。
簡単な入力フォーム。
店舗別の確認表。

こうしたものを、いきなり本格システムとして作るのは重いです。

でも、まず社内で試す画面として作るなら、Sitesはかなり相性がよさそうです。

4. 後から修正しやすい

Sitesは、作って終わりではありません。

Codexに追加で依頼しながら、画面や動きを直していく使い方ができます。

ここが、個人的にはかなり楽しみな部分です。

EC運用では、「少しだけ直したい」がとにかく多いです。

表示順を変えたい。
SKUではなく商品名を先に見たい。
担当者別に絞り込みたい。

この小さな修正を、都度大きな開発依頼にしなくてよいなら、現場としてはかなり助かります。

実際にデモを作ってみた

今回、私もデモとして「商品公開前チェックページ」を作ってみました。

使ったのはダミーデータです。商品名、SKU、価格確認、画像確認、在庫表示、販売期間、CS注意点などを入れ、公開前会議で確認するページを想定しました。

流れはシンプルです。

まず、Codexに「商品公開前チェックページを作成してください」と依頼し、「Codex Sitesを使って、保存してから確認できる形にしてください」と伝えました。

その後、全体ステータス、商品別チェック表、未完了タスク、CS注意点を表示するページを作成し、まずは公開せずに確認用として保存しました。

実際に画面を見ながら、「公開不可リスクありの商品を上に表示する」「CS注意点を目立たせる」といった修正を依頼し、最後にSitesで開ける形にしました。

ここで感じたのは、Codex Sitesの価値はコード生成だけではないということです。

AIにコードを書いてもらっても、非エンジニアにとっては「どうやって確認するのか」で止まりがちです。でもSitesでは、作ったものを実際のWebページとして確認できます。

商品ごとの公開可否や未完了タスクが1ページにまとまることで、「まずこのページを見ましょう」と会議を始めやすくなる点は分かりやすいメリットだと感じました。

使う前に注意したいこと

Codex Sitesは便利そうですが、最初から何でも任せるより、使う範囲を決めて始めるほうがよさそうです。

特に、今はプレビューとして案内されている機能です。
まずは、下書き、社内レビュー、限定共有から始めるのが安心です。

1. 利用できるプランを確認する

ここは最初に確認したいところです。

Codex自体は、ChatGPT Plus、Pro、Business、Edu、Enterpriseなどのプランで利用できる範囲があります。

ただし、Codex Sitesについては、現時点では対象となるBusinessとEnterpriseワークスペース向けのプレビュー機能として案内されています。

Businessでは利用できる設定になっており、Enterpriseでは管理者が有効化やアクセス範囲を管理する形です。

つまり、個人のPlusやProユーザーがすぐにSitesを使える、という整理ではありません。

社内で試したい場合は、まず自社のワークスペースが対象か、管理者設定で有効になっているかを確認する必要があります。

2. 共有範囲を先に決める

SitesはURLで共有できるのが便利です。

ただ、便利だからこそ、誰に見せるのかを先に決める必要があります。

EC運用では、外に出したくない情報が多いです。

未公開キャンペーン。
売上速報。
在庫逼迫の商品。
仕入れ条件。
原価に近い情報。
顧客対応のメモ。

こうした情報を含むページを作る場合、共有範囲を広げすぎると危険です。

最初は、作成者と管理者だけ。
次に、少人数の関係者。
問題がなければ、ワークスペース内の必要なメンバーへ。

この順番で試すのが現実的です。

3. データを入れる前に、粒度を落とす

便利な機能ほど、つい「CSVを丸ごと入れたい」と思ってしまいます。

でも、ECのCSVには注意が必要です。

顧客名。
メールアドレス。
注文番号。
配送先。
購入履歴。
原価。
在庫数。
未公開の商品情報。

こうした情報が混ざっていることがあります。

最初に試すなら、実データではなくダミーデータで十分です。

商品名は仮名にする。
数値は丸める。
顧客情報は入れない。
注文番号は削除する。
まずは集計済みの情報だけ使う。

これだけでも、画面構成の検証はできます。

最初から本物のデータを入れなくても、「この画面は使いやすいか」は確認できます。

まとめ

Codex Sitesは、EC運用にとってかなり面白い新機能です。

特に良いと思ったのは、運用側の人が「こういう画面があれば助かる」を形にしやすくなるところです。

本格的なシステム開発の前に、まず見える形を作る。
その画面を見ながら、必要な項目を決める。
関係者の認識をそろえる。
会議や確認作業の手戻りを減らす。

この使い方が、かなり現実的だと思います。

EC運用で試すなら、まずは大きなテーマにしないほうがよいです。

商品公開前チェック。
販促キャンペーンの進行ページ。
問い合わせ傾向の週次レビュー。
社内ツールの要件整理。

このあたりから始めると、用途が重なりにくく、効果も見えやすいはずです。

一方で、今はプレビュー機能です。
対象プランもBusinessとEnterpriseワークスペースが中心です。
共有範囲やデータの扱いも、最初に確認する必要があります。

だからこそ、最初の使い方はシンプルでよいと思います。

実データではなく、ダミーデータで試す。
本番ツールではなく、会議用のたたき台にする。
公開ではなく、まず少人数でレビューする。

完成品を一発で作るというより、話を早く進めるための画面を作る。

Codex Sitesは、その距離感で使うと、EC運用の現場にかなり入りやすい機能だと感じます。

参考文献（出典）

• 参考（公式）：Codex for every role, tool, and workflow／OpenAI／https://openai.com/index/codex-for-every-role-tool-workflow/
• 参考（公式）：Sites／OpenAI Developers／https://developers.openai.com/codex/sites
• 参考（公式）：Using Codex with your ChatGPT plan／OpenAI Help Center／https://help.openai.com/en/articles/11369540-codex-and-chatgpt-plan-usage-limits
• 参考（公式）：Changelog – Codex／OpenAI Developers／https://developers.openai.com/codex/changelog
• 参考（解説）：OpenAI launches new Codex tools for white-collar work／TechCrunch／https://techcrunch.com/2026/06/02/openai-launches-new-codex-tools-for-white-collar-work/

GDX株式会社についての詳細は以下のリンクからご確認いただけます。
会社HP: https://gdx.inc/

※本文の一部はChatGPTの支援を受けて作成し、筆者が加筆・修正しています。内容は筆者個人の見解であり、GDX株式会社の公式見解・声明を示すものではありません。情報は参考目的であり、公式発表・一次情報をご確認ください。