投稿者 投稿日: カテゴリー ChatGPT
GPT-5.3-Codexとは、コード生成と汎用推論を1つに統合したOpenAIのモデルです。
エンジニアに依頼すると2週間、社内で抱える受発注のデータ整形をその日のうちに自動化する。2026年2月にOpenAIが公開したGPT-5.3-Codexは、この距離を一気に縮めました。コードを書くCodexと、知識・推論を担うGPT-5の学習スタックを初めて1つにまとめたモデルで、前世代比で約25%高速とされています。EC事業者にとっての意味は明快です。在庫アラート、レビュー集計、受注ステータス通知といった「外注するほどではないが手作業だと地味に重い」業務を、店長やバックヤード担当が自分の手で内製できる時代になりました。この記事では、楽天RMS・Amazon Seller Central・Shopify Adminのデータを題材に、内製の具体手順とそのまま使えるプロンプトを7本掲載します。
GPT-5.3-Codexで何が変わり、なぜ「内製」が現実的になったのか
GPT-5.3-Codexの一番の変化点は、モデルが「コードを書く力」と「業務文脈を読む力」を分離せずに持つようになったことです。従来は、コード生成に強いモデルと、業務指示を自然言語で理解するモデルの間に壁があり、EC事業者が「先月の楽天の注文CSVを商品別に集計して、在庫が10個を切ったものだけ赤字で出して」と頼んでも、意図の解釈とコード生成のどちらかが甘くなりがちでした。GPT-5.3-Codexは推論と実装を同じスタックで処理するため、業務の曖昧な日本語からそのまま動くスクリプトに落ちる確率が上がっています。OpenAIはSWE-Bench ProとTerminal-Benchで業界最高水準のスコアを示したと公表しており、これは「指示どおりにコードを書き、ターミナル上で動かしきる」能力の指標です。EC実務に置き換えると、CSVを読み込んで集計して結果を吐くまでの一連の作業を、人間がコードを直さずに完走させやすくなった、ということになります。
リリースの流れも押さえておきます。本体のGPT-5.3-Codexが2026年2月5日に登場し、その1週間後の2月12日には小型でリアルタイム性を重視したGPT-5.3-Codex-Sparkが追加されました。Sparkは応答が速い分、軽い整形や即時のチェックに向きます。重い集計ロジックや複数ファイルをまたぐ処理は本体側、入力中の補完や短いスクリプトの叩き台はSpark側、という棲み分けが現場感覚では自然です。さらに2026年5月17日には、GitHub CopilotのBusiness/Enterpriseの基盤モデルにGPT-5.3-Codexが採用されました。普段VS Codeなどでコードを触る担当者がいる店舗なら、Copilot経由でも同じモデルの恩恵を受けられます。
EC事業者にとって重要なのは、このCodexがChatGPTの各プランに同梱されている点です。専用の開発環境を新規契約しなくても、すでに使っているChatGPTからCodexを呼び出せます。2026年5月下旬時点で週間400万人を超える開発者が利用しているとされますが（目安）、ここで言う「開発者」には、本職のエンジニアだけでなく、業務を自動化したい非エンジニアも含まれ始めています。直近の支援案件で観測したのは、これまでExcelのマクロで止まっていた店舗が、Codexに「このCSVをこう変換するPythonを書いて」と頼むだけで日次の処理を回し始めたケースです。コードの読み書きができなくても、入力と出力の形さえ言葉で説明できれば道具として成立する。これが2026年に内製が現実的になった核心です。
「内製」と聞くと自社開発の大掛かりな話に思えますが、ここで扱うのはもっと小さい単位です。受注CSVを毎朝整形する、レビューをカテゴリ別に仕分ける、在庫が閾値を切ったらSlackに通知する。一つひとつは数十行のスクリプトで済みます。エンジニアに頼むほどの規模ではないのに、手でやると毎日15分、月に5時間溶ける。その隙間をCodexで埋めるのが、もっとも費用対効果の高い使い方です。
なぜ今まで内製が進まなかったのかも整理しておきます。理由は技術の難しさそのものより、「コードを書ける人が社内にいない」「いても通常業務で手が空かない」という人的なボトルネックでした。EC事業者の多くは、商品企画・撮影・受注・CS・広告運用に人手を割いており、社内ツールの自動化は常に後回しになります。外注すれば数万円から十数万円かかり、しかも仕様変更のたびに追加費用が発生する。この構造が「手作業のままでいいか」という諦めを生んでいました。GPT-5.3-Codexは、このボトルネックの正体である「書ける人がいない」を、業務を一番分かっている当人が書ける状態に置き換えます。コードを書くスキルではなく、業務を言語化するスキルが鍵になる、という逆転が起きているのです。
楽天・Amazon・Shopifyのデータで内製する7つの業務ツール
ここからが実装パートです。題材は実際のEC業務で頻出する7つで、それぞれにそのまま使えるプロンプトを1本ずつ用意しました。プロンプトはChatGPT上のCodex、またはCopilot経由のGPT-5.3-Codexのどちらでも動きます。コードの実行環境がない場合は、ChatGPTの画面でファイルをアップロードしてCodexに処理させる形でも構いません。変数は中括弧で囲んであるので、自店の値に置き換えて使ってください。
注意点を先に1つ。楽天・Amazon・ShopifyのCSVは文字コードや列名が独特です。楽天RMSの売上ダウンロードはShift-JISで出力されることが多く、Amazon Seller Centralのレポートはタブ区切りのテキスト、Shopify Adminの注文エクスポートはUTF-8のCSVです。プロンプトでこの違いを明示しないと、文字化けや列ズレで止まります。各プロンプトに該当箇所を入れてあります。
最初は在庫アラートです。楽天RMSの在庫データをもとに、閾値を下回った商品だけを抽出するスクリプトを作ります。手作業だと在庫数の列を目視で追うことになり、商品数が数百を超えると現実的ではありません。
プロンプト1：楽天在庫アラートツールの内製（Shift-JIS CSV対応）
あなたは在庫管理を自動化するPythonエンジニアです。
楽天RMSからダウンロードした在庫CSVを読み込み、在庫数が閾値を下回った商品だけを抽出するスクリプトを書いてください。
入力ファイルの前提：
- 文字コード：Shift-JIS（cp932）
- 列：商品管理番号、商品名、在庫数（列名は実ファイルに合わせて指定可能にする）
要件：
1. 在庫数が {閾値} 個未満の行だけを残す
2. 在庫数の少ない順に並べる
3. 結果を「商品管理番号 / 商品名 / 在庫数」の3列で、UTF-8のCSVとして出力
4. 在庫数が空欄や数値以外の行はスキップし、最後に件数を表示
5. コードには日本語コメントを各処理に付ける
入力ファイル名：{ファイル名}
閾値：{在庫アラートの基準個数}
抽出ロジックができたら、次は通知です。在庫アラートの結果を毎朝確認するのは結局手作業なので、Slackや指定メールに自動で飛ばすところまで内製すると一気に楽になります。
プロンプト2：在庫アラートのSlack通知化
あなたは業務通知を自動化するエンジニアです。
プロンプト1で作った在庫抽出スクリプトの結果を、Slackの指定チャンネルに自動投稿する処理を追記してください。
要件：
1. Slack Incoming Webhook URLを環境変数から読む（コードに直書きしない）
2. 在庫が閾値を切った商品が0件なら「本日の在庫アラートなし」と投稿
3. 1件以上なら、商品名と在庫数を箇条書きで投稿（先頭に件数を明記）
4. 投稿件数が20件を超える場合は上位20件＋「ほか○件」とまとめる
5. Webhookの送信失敗時はエラー内容をログに出して終了
通知先チャンネル名：{チャンネル名}
3つ目はレビュー集計です。楽天やAmazonのレビューをExcelに貼り付けて目で読むのは、件数が増えると限界があります。Codexにテキスト分類をさせれば、不満が集中している論点を機械的に拾えます。
プロンプト3：レビューの論点別自動集計
あなたはEC店舗のCS分析担当です。
以下のレビューテキスト群を読み、論点別に自動で仕分ける処理をしてください。コードではなく、分類結果を直接出力してください。
分類カテゴリ：
1. 商品品質（不良・破損・期待外れ）
2. 配送（遅延・梱包）
3. 価格・コスパ
4. 接客・対応
5. リピート・満足
6. その他
要件：
- 各カテゴリの件数と構成比（%）を提示
- ネガティブ評価が最も多いカテゴリを冒頭で指摘
- 改善優先度の高い具体的な指摘を3つ、原文の要約付きで抜き出す
- 誇張表現や断定は避け、件数の事実ベースで書く
商品ジャンル：{ジャンル}
レビュー本文：{レビューを貼り付け}
4つ目はAmazonのビジネスレポート整形です。Amazon Seller Centralのレポートはタブ区切りで列も多く、必要な指標だけ抜くのに手間がかかります。
プロンプト4：Amazonビジネスレポートの指標抽出（タブ区切り対応）
あなたはAmazon運用のデータ整形を担うエンジニアです。
Amazon Seller Centralからダウンロードしたビジネスレポート（タブ区切りテキスト）を読み込み、商品別の主要指標だけを抜き出すスクリプトを書いてください。
入力ファイルの前提：
- 区切り：タブ
- 文字コード：UTF-8
- 列：商品名(またはASIN)、セッション、ページビュー、ユニットセッション率、注文商品売上 など
要件：
1. 商品ごとに「セッション / ユニットセッション率（CVR） / 注文商品売上」を抽出
2. ユニットセッション率の低い順に並べる（改善余地の大きい商品が上）
3. セッションが {最低セッション数} 未満の商品は除外（母数が小さく判断できないため）
4. 結果をUTF-8のCSVで出力
5. 列名がレポートのバージョンで変わる場合に備え、対象列名を冒頭で指定できるようにする
入力ファイル名：{ファイル名}
最低セッション数：{値}
5つ目は受注ステータス通知です。Shopify Adminの注文データを読み、未発送のまま一定日数が経った注文を洗い出します。発送漏れはクレームに直結するので、内製で日次チェックする価値が高い業務です。
プロンプト5：Shopify未発送注文の自動検出（UTF-8 CSV対応）
あなたは受注処理を自動化するエンジニアです。
Shopify Adminからエクスポートした注文CSV（UTF-8）を読み込み、未発送のまま一定日数が経過した注文を抽出するスクリプトを書いてください。
入力ファイルの前提：
- 文字コード：UTF-8
- 列：注文番号、注文日、発送状況（Fulfillment Status）、顧客名 など
要件：
1. 発送状況が「未発送（unfulfilled）」の注文だけを残す
2. 注文日から {経過日数} 日以上経過したものを抽出
3. 経過日数の長い順に並べる
4. 「注文番号 / 注文日 / 経過日数 / 顧客名」の形でCSV出力
5. 注文日が空欄や不正な形式の行はスキップし、最後に件数を表示
入力ファイル名：{ファイル名}
経過日数の基準：{値}
6つ目は商品説明文の一括整形です。CSVに入った素の商品情報から、媒体ごとの文字数制限に収まる説明文を生成・整形させます。楽天市場のスマートフォン用商品説明文は半角2,560文字（全角換算1,280文字）以内、Amazonの商品説明は半角2,000文字以内と上限が異なるため、媒体を引数で切り替えられるようにします。
プロンプト6：商品説明文のCSV一括整形（媒体別文字数制限対応）
あなたはECの商品ページ最適化に詳しいエンジニア兼コピーライターです。
商品情報のCSVを読み込み、各行の商品について媒体別の説明文を生成するスクリプトの設計と、生成ロジックの方針を提示してください。
媒体別の文字数上限（全角換算）：
- 楽天スマートフォン用商品説明：1,280文字以内
- Amazon商品説明：1,000文字以内（半角2,000文字相当）
- Shopify商品説明：上限なし（推奨1,000〜1,500文字）
要件：
1. 入力CSVの列（商品名、特徴、素材、サイズ、価格帯）を読み込む
2. 媒体を引数 {媒体} で受け取り、その媒体の文字数制限内で説明文を生成
3. 薬機法・景表法に触れる断定表現（治す、最高、No.1 など）を含めない
4. 生成後に文字数をカウントし、上限超過があれば警告を出す
5. 結果を「商品名 / 媒体 / 説明文 / 文字数」でCSV出力
商品ジャンル：{ジャンル}
対象媒体：{楽天 or Amazon or Shopify}
最後はマスタの突合です。楽天とAmazonの両方に出している店舗では、価格や在庫が媒体間でズレているのを定期的に直す必要があります。2つのCSVを商品コードで突き合わせ、差分だけを出します。
プロンプト7：楽天・Amazon商品マスタの差分検出
あなたは複数媒体の商品マスタを管理するエンジニアです。
楽天とAmazonからそれぞれダウンロードした商品CSVを読み込み、共通の商品について価格と在庫の差分を検出するスクリプトを書いてください。
入力ファイルの前提：
- 楽天：Shift-JIS、列に 商品管理番号、価格、在庫数
- Amazon：UTF-8、列に 出品者SKU、価格、在庫数
- 両者は {対応表の指定方法}（共通の商品コード or 対応表CSV）で紐づける
要件：
1. 両媒体に存在する商品だけを対象に、価格差と在庫差を計算
2. 価格差が {許容額} 円以上、または在庫差が {許容数} 個以上の商品だけ抽出
3. 「商品名 / 楽天価格 / Amazon価格 / 価格差 / 楽天在庫 / Amazon在庫 / 在庫差」で出力
4. 片方にしか存在しない商品は別リストとして出力
5. 文字コードの違いを吸収して読み込む
価格差の許容額：{値}
在庫差の許容数：{値}
これら7本は単体でも効きますが、内製の真価は組み合わせにあります。プロンプト1の在庫抽出とプロンプト2のSlack通知をつなげば日次の在庫監視が完成し、プロンプト5の未発送検出を加えれば朝のバックヤード確認が自動化されます。Codexによる業務自動化を時間軸で設計する考え方は、別記事のCodex超時間EC自動化でも整理しているので、日次・週次の流れに組み込む際に参照してください。
内製で必ずつまずく3つの落とし穴と回避策
最初の落とし穴は文字コードです。楽天RMSのCSVをそのままPythonで開くと、ほぼ確実に文字化けします。原因はShift-JIS（cp932）で書き出されているのにUTF-8で読もうとするためで、これを知らないと「Codexが書いたコードが動かない」と誤解しがちです。回避策はプロンプトの段階で「楽天はShift-JIS、Shopifyはタブ区切りでない素のUTF-8 CSV」と明示すること。媒体ごとの仕様をCodexに伝えれば、読み込み部分を正しく書き分けてくれます。エラーが出たら、化けている1行をそのままCodexに貼って「この文字コードを判定して読み込みを直して」と頼むのが最短です。
2つ目は、列名の前提ズレです。楽天もAmazonもレポートのフォーマットを更新することがあり、「在庫数」が「在庫数量」に変わるだけでスクリプトが止まります。直近の支援案件で観測したのは、半年前に作ったスクリプトが列名変更で動かなくなり、原因が分からず手作業に逆戻りしていた店舗でした。回避策は、プロンプト4やプロンプト7のように対象列名を冒頭で指定できる作りにしておくこと。列名をコードの奥に埋め込まず、引数や設定として外に出しておけば、フォーマットが変わっても1行直すだけで済みます。
3つ目は、生成テキストの薬機法・景表法リスクです。プロンプト6で商品説明文を一括生成させると、商品数が多いほど「最高」「No.1」「効く」といった表現が紛れ込む確率が上がります。Codexは指示すれば避けますが、指示しなければ平気で書きます。回避策は、生成プロンプトに禁止語リストを毎回入れること、そして生成後に禁止語が混入していないかをチェックするスクリプトを別に走らせることです。AIに書かせた文章を無検品で公開するのは、媒体規約違反と行政指導の両方を招きます。生成と検品は必ず分けてください。
内製の費用・工数とKPIの置き方
費用面はシンプルです。GPT-5.3-CodexはChatGPTの各プランに同梱されるため、ChatGPT Plus（月額20米ドル）やTeamプランを契約していれば追加費用なしでCodexを使えます。Copilot経由で使う場合はGitHub Copilot Business（1ユーザー月額19米ドル、2026年6月時点の目安・要確認）が必要ですが、すでに開発環境を持つ店舗ならこちらでも構いません。エンジニアに同じ自動化を外注すると、簡単なスクリプト1本でも数万円から、複数媒体をまたぐ処理なら十数万円かかることが多く、内製ならその費用がそのまま浮きます。
工数のKPIは「削減できた手作業時間」で測るのが分かりやすいです。在庫チェックを毎朝15分やっていた店舗なら、プロンプト1と2の自動化で月に約5時間が浮く計算になります。レビュー集計を週1回30分やっていたなら、プロンプト3で月に約2時間。これらは派手な数字ではありませんが、店長やバックヤード担当の時間は店舗の利益に直結する希少資源です。現場感覚では、内製の最初の1か月で「自動化できた業務の数」を3〜5本に積み上げられれば、体感の負荷は明確に下がります。
注意したいのは、内製のKPIをCVRや売上に直結させようとしないことです。在庫アラートや受注通知は、ミスを防ぎクレームを減らす守りの自動化であり、効果は「事故が起きなかった」という形で表れます。発送漏れによる低評価レビューが月に数件減れば、長期的には店舗評価とCVRに効きますが、それは副次的な結果です。導入初期は時間削減と事故防止を主KPIに置き、売上系の指標は後追いで観測するのが堅実な置き方です。
工数の見積もりも、最初は甘く見ない方が無難です。プロンプトを投げて一発で完璧なスクリプトが出ることはまれで、文字コードや列名のズレを2〜3往復で直すのが実態です。1本のツールを業務で使える状態にするまでに、慣れないうちは1〜2時間かかると見ておくのが現実的です。それでも外注の納期と費用に比べれば桁違いに速く、一度作れば毎日効き続けます。投資対効果を測るときは、作るのにかかった一度きりの時間と、毎月浮く時間を分けて計算してください。前者は初月だけ、後者は翌月以降ずっと積み上がります。
エンジニア依存からの脱却と、内製の次に来るもの
GPT-5.3-Codexがもたらす本質的な変化は、EC事業者と「コードを書ける人材」の間にあった依存関係が薄くなることです。これまで小さな自動化のたびにエンジニアの空き時間を待ち、仕様を伝え、納品を待っていた往復が、店長自身の言葉で完結する場面が増えます。ただし、完全にエンジニアが不要になるわけではありません。複数のスクリプトをサーバーで定時実行させる、APIキーを安全に管理する、障害時に切り分けるといった運用面は、依然として技術的な知見が要ります。現実的な姿は、日々の小さな自動化はCodexで店舗側が内製し、基盤の整備だけを専門家に任せる分業です。
次に来るのは、スクリプトを書く段階すら飛ばす流れです。GPT-5.3-Codexのようなモデルがブラウザやアプリを直接操作するエージェントと結びつけば、「楽天RMSにログインして在庫を更新する」といった操作そのものを任せられるようになります。すでにその初期形は登場しており、CSVをダウンロードして整形する手順を人間が指示しなくても、エージェントが画面を見て自分で進める方向に向かっています。ただし媒体の管理画面を自動操作させることには規約上のリスクもあり、楽天RMSやAmazon Seller Centralの利用規約に照らして許容される範囲を確認する必要があります（要確認）。当面は、データの抽出・整形・通知という「読み取りと加工」の領域を内製で固め、画面操作の自動化は慎重に様子を見るのが安全です。
モデル選びの観点も補足します。コード生成に特化したいならGPT-5.3-Codexが筆頭ですが、業務によってはClaude系のコーディング支援も選択肢になります。両者の使い分けはCodexとClaude CodeのEC比較で詳しく扱っており、AIコーディングツール全般の比較はAIコーディングツール比較にまとめています。自店の体制に合うツールから始めるのが、内製を続けるコツです。
よくある質問
プログラミングの知識が全くなくても内製できますか
入力と出力の形を日本語で説明できれば、最初のスクリプトは作れます。「このCSVを読んで、在庫が10個未満の商品だけ別ファイルに出して」と頼めば、Codexがコードを書きます。ただし、エラーが出たときに化けている行をCodexに貼って直してもらう、といった往復はできた方が安定します。最初の数本は時間をかけて慣れる前提で取り組むのが現実的です。
GPT-5.3-Codexを使うには何を契約すればいいですか
CodexはChatGPTの各プランに同梱されているため、ChatGPT Plus（月額20米ドル）などを契約していれば追加費用なしで使えます。すでにGitHub Copilot Business/Enterpriseを利用している場合は、2026年5月17日からその基盤モデルがGPT-5.3-Codexに切り替わっているので、Copilot経由でも同じモデルを使えます。
GPT-5.3-CodexとSparkはどう使い分けますか
重い集計や複数ファイルをまたぐ処理は本体のGPT-5.3-Codexが向きます。Sparkは小型でリアルタイム性が高いため、短いスクリプトの叩き台や即時のチェックに適しています。内製の本番ロジックは本体、入力中の補完や軽い整形はSpark、という棲み分けが現場感覚では自然です。
楽天やAmazonのCSVが文字化けして動きません
楽天RMSのCSVはShift-JIS（cp932）で書き出されることが多く、UTF-8で読もうとすると化けます。プロンプトに「文字コードはShift-JIS」と明示すれば、Codexが正しい読み込みコードを書きます。化けた行をそのままCodexに貼って「この文字コードで読み込み直して」と頼むのが最短の解決策です。
内製したツールでミスが起きたら誰が責任を持ちますか
自動化はあくまで人間の確認を補助する位置づけで運用してください。在庫通知や未発送検出は「気づく」ための道具であり、最終判断は担当者が行います。導入初期は自動化の結果を1〜2週間は手作業と並走させ、出力が正しいことを確認してから完全移行するのが安全です。
AIに商品説明文を書かせると規約違反になりませんか
無検品で公開すると、薬機法・景表法に触れる表現や媒体規約違反のリスクがあります。生成プロンプトに禁止語リストを必ず入れ、生成後に禁止語が混入していないかを別スクリプトで検品してください。生成と検品を分けることが、AI生成テキストを安全に運用する前提条件です。
どの業務から内製を始めるのがおすすめですか
毎日繰り返していて、入力と出力が明確な業務から始めるのが定石です。在庫アラート、受注の未発送検出、レビュー集計の3つは、効果が見えやすく失敗しても被害が小さいため、最初の題材に適しています。慣れたら複数媒体をまたぐマスタ突合など、難度の高いものに広げてください。
著者：齋藤竹紘（株式会社オルセル 編集長／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実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
