ネットショップの受注処理をAIで効率化する：氏名と住所を渡さずに速くする手順

受注処理でAIが速くするのは、確認メール文面の生成・例外注文の仕分け・住所表記の揺れ検出の3つだけだ。氏名や住所を貼る必要はない。注文番号とSKUと金額に絞って渡せば、速度を落とさずに、外へ出る情報量を減らせる。

• 受注処理を7工程に割ると、AIで速くなるのは「仕分け」と「文面生成」の2工程。注文取込・在庫引当・伝票番号登録は連携設定とマスタの仕事で、AIを足しても速くならない
• 事故るのは氏名・住所・電話・自由記入欄の4つ。列を落として注文番号に置き換えれば大半の用途は成立する。ただし社内に対応表がある限り、そのデータは法律上まだ個人情報のままだ
• 「学習に使わない設定」は、入力事故そのものを消さない。サービス設定・モール規約・社内ルールは別々に決める必要がある

受注処理の効率化を調べると、出てくるのは「テンプレ化」「自動化」「AIで文面生成」といった打ち手の一覧だ。検索上位の動画（業務効率化のAI活用法を扱った動画・2026-08-09時点で約56万回再生）でも、この手の打ち手は並んでいる。だが実際に手を動かすと、打ち手より手前で止まる。受注CSVを開いた瞬間、同じ1行に氏名・住所・電話が並んでいて、そのままAIに貼れないからだ。上長や情シスからは「顧客情報を外部に入れるな」とだけ返ってくることが多い。どの列がだめなのかは誰も定義していない。

この記事は打ち手を増やす話ではない。どのデータなら渡してよいかを決める話だ。商品ページや問い合わせなら「この作業はAIに任せる／任せない」というタスク側の線引きで進められる（その考え方は商品ページ制作でAIに任せていい範囲で整理した）。受注処理はそれが効かない。扱うデータの大半が個人情報なので、作業側で線を引いても、貼るデータを決めない限り一歩も動かない。以下、工程の分解から、列の落とし方、対応表の持ち方までを順に書く。なお後払い決済の与信情報は取扱いの性質が違うため、この記事では扱わない。

受注処理を7工程に割ると、AIが効く場所は2つしかない

「受注処理が遅い」は、工程名まで割らないと手が付かない。通販の受注処理は、おおむね次の7つに割れる。

1. 注文取込（各モール管理画面からの受注データ出力／一元管理ツールの自動取込）
2. 内容確認と例外の仕分け（同梱・熨斗・後払い・住所不備・キャンセル依頼）
3. 在庫引当
4. 確認メール・お礼メールの送信
5. 出荷指示（納品書・出荷指示書・配送情報＝送り状データの出力）
6. 伝票番号の登録と発送通知
7. 入金確認／キャンセル・返品処理

この7つのうち、生成AIを足して速くなるのは2と4である。1・3・5・6は連携設定とマスタの精度で決まる。注文取込が遅いのはAIがいないからではなく、モールと一元管理ツールの取込間隔や、商品管理番号とモール別商品番号の紐付けが埋まっていないからだ。在庫引当が詰まるのは、SKUの粒度が実物と合っていないか、複数モールをまたぐ引当の優先順位が決まっていないからで、ここに文章生成モデルを差し込む余地はない。伝票番号登録も同じで、出荷実績CSVのフォーマットが合っているかどうかの問題である。

逆に2と4は、判断と文章の工程なので、AIの得意な形に落ちる。工程2は「この注文は通常フローか、人が見る例外か」の仕分けであり、工程4は「この状況を説明する日本語を書く」作業だ。工程2の一部である住所表記の揺れ検出（丁目・番地の全角半角、ビル名の欠落、都道府県の重複記載）も、単純なパターン照合では拾いきれず文脈判断が要るので、ここに入る。工程7のうち返品理由の分類や返信文の起草も、性質としては2と4と同じ側だ。以降で扱うデータの線引きは、そのまま7にも当てはまる。

工程の名前は、自社の画面の語彙に置き換えて数えたほうがいい。Shopifyなら「Orders」ページの「Export」から受注データを出力する（Shopifyヘルプ・2026-08-09確認）。ネクストエンジンのような一元管理ツールなら「受注伝票」「受注データの出力」「配送情報(送り状データ)の出力」「納品書/出荷指示書」といった語で並んでいる。楽天RMSは店舗ログインが必要で公開マニュアルを外から参照できないため、画面名とCSVの列名は自店のRMSを実際に開いて確認する。ここを他店のブログの表記で代用すると、後で作る判定表がそのまま使えなくなる。

AIの前に潰せる手段がある：自動連携・マスタ整備・外注との住み分け

工程を割ると、AIを持ち出す前に片付く遅さが相当量あることが分かる。順番を間違えると、本来一度の設定で終わる作業を、毎日プロンプトで補い続けることになる。

まず自動連携だ。1・3・5・6の遅さは、ほぼここに帰着する。モールと一元管理ツールの受注取込、在庫の自動反映、送り状データの出力と伝票番号の戻し込み。この経路が繋がっていれば、担当者は画面を3面開いて同じ注文を3回見なくて済む。楽天RMS・セラーセントラル・Shopify Adminを行き来しながら目視で突き合わせている時間は、AIでは1秒も短くならない。受発注と在庫の全体像は受発注・在庫管理の自動化にまとめてあるので、工程1・3・5・6が重い状態ならそちらが先になる。

次にマスタ整備。例外注文の多くは、注文が特殊なのではなく、マスタが足りないせいで例外に見えているだけだ。熨斗の表書きパターン、同梱可否、配送不可地域、リードタイムの違うSKU。これらが商品マスタや配送マスタに定義されていれば、仕分けの対象そのものが減る。AIに毎日「これは例外か」と聞く前に、例外の定義を一度書いて固定するほうが速い。

三つ目にテンプレートの整理。確認メールの文面は、実のところ大半が定型である。定型部分はテンプレに固定し、AIに書かせるのは残りの部分、つまり「在庫欠品でこの1点だけ後日発送になる」「住所のビル名が不明で確認したい」といった個別事情の説明だけに絞る。全文をAIに書かせると毎回トーンが揺れて、結局人が読み直す時間が増える。

四つ目に外注・人員配置。繁忙期だけ跳ねる負荷は、お買い物マラソンやスーパーSALEの期間に集中する。年に数回の山を平すために恒常的な仕組みを作ると費用が合わないことがあり、スポットで人を入れたほうが安く収まる場合もある。自社の件数と単価で計算する話だ。

この4つを潰した後に残るのが、判断と文章、つまり工程2と4だ。AIの守備範囲はそこにしかない。連携で消せるものを消し、マスタで減らせるものを減らし、残った揺らぎにAIを当てる。この順で進めると、AIに渡すデータの量も自然に減っていく。渡す必要のある情報が「例外かどうかを判断するのに要る最小限」まで落ちるからだ。

貼ると事故る4項目：氏名・住所・電話・自由記入欄

受注CSVの列は、扱いの難しさで4段階に分かれる。危ないのは常に同じ4項目で、しかも4つ目だけ性質が違う。

1. 氏名。Shopifyの受注CSVでいえば Shipping Name Billing Name にあたる列だ（先頭の Name 列は氏名ではなく注文番号なので混同しない）。厄介なのは、氏名がこの列だけに存在しないことである。ギフト注文では依頼主とお届け先で2人分出る。熨斗の表書きは氏名そのものだし、領収書の宛名も同じだ。「氏名の列を消した」と思っていても、熨斗指示の文字列に残っている、という形で漏れる。

2. 住所。Shipping Street Shipping Address1 Shipping Address2 Shipping City Shipping Zip Shipping Province Shipping Company と、Billing側の同名構成。ここで見落とされやすいのが郵便番号だ。Shipping Zip は数字の並びなので識別子に見えにくいが、実質は住所そのものである。地域別の傾向を見たいという用途なら、郵便番号を落として都道府県の列だけ残すのが折衷案になる。集計の粒度としてはたいていそれで足りる。

3. 電話番号。Phone Shipping Phone。配送業者への連絡先として必須の項目だが、AIに判断させる材料としてはまず使わない。電話番号は他システムの検索キーとして機能するので、外に出たときの追跡可能性が氏名より高い場合すらある。用途を問わず落として構わない列だ。

4. 自由記入欄。Shopifyなら Notes と Note Attributes、モールなら備考欄・要望欄にあたる。これだけは性質が違う。列ごと落とすのは簡単だが、そうすると今度は仕事にならない。例外注文の仕分けをAIに任せたい理由の大半が、この欄にあるからだ。「不在が多いので◯◯様方へ」「同居の家族に渡してほしい」「前回の注文と同梱で」といった文章には、氏名も、家族構成も、過去の購買履歴も混ざる。

だからといって「備考欄は全部人が読む」運用にすると、いちばん時間の掛かる工程がそのまま残る。現実的なのは二段構えだ。頻出の言い回し（熨斗希望、置き配、領収書の宛名指定、同梱希望）は表記ゆれごと辞書にして機械的に振り分け、そこから外れた文だけを、氏名と番地を伏せた状態でAIに渡して分類させる。この欄は列の設計では処理できず、渡す前に一段加工する対象になる。

この構造は、問い合わせメールの本文をAIに扱わせるときの詰まり方とほぼ同じだ。文章の中に個人情報が溶けている領域をどう切り分けるかは、問い合わせ対応でAIに任せられる範囲でも同じ論点になる。

逆に、残してよい列は明確だ。Shopifyの受注CSVでいえば Id Created at Financial Status Fulfillment Status Paid at Fulfilled at Subtotal Total Discount Code Shipping Method Lineitem name Lineitem SKU Lineitem quantity Lineitem price Payment Method Refunded Amount Tags Risk Level Location といった列である（列名は2026-08-09時点のShopifyヘルプで確認）。例外注文の分類という仕事は、実のところこの範囲でほぼ成立する。

氏名と住所を渡さない手順：列落とし、注文番号への置換、対応表の持ち方

手順は4ステップだ。順番に意味がある。

ステップ1：用途を1文で書く。「例外注文を仕分けたい」「欠品連絡の文面を作りたい」「住所の表記揺れを見つけたい」。用途が決まれば、必要な列は驚くほど少なくなる。例外の仕分けなら、支払いステータスと配送ステータス、金額、SKU、数量があれば足りる。Shopifyの場合、支払いステータスは Pending / Authorized / Paid / Refunded / Partially refunded / Voided など、配送ステータスは Unfulfilled / In progress / On hold / Scheduled / Partially fulfilled / Fulfilled などの値を取る（2026-08-09時点のShopifyヘルプで確認）。この2列の組み合わせだけでも、人が見るべき注文はかなり絞れる。

ステップ2：列を落とす。用途に要らない列は、加工する前に消す。マスクするのではなく消す。伏せ字の文字列を残すと、桁数や記号のパターンから元が推測できる余地が残るうえ、消し忘れの判定も面倒になる。CSVを表計算ソフトで開いて、残す列だけを別シートにコピーするのが一番速い。

ステップ3：注文番号に置き換える。行を識別する必要がある場合だけ、氏名の代わりに注文番号（または連番）を入れる。Shopifyなら Name 列がこの注文番号にあたる。ここで必ず理解しておくべき点がある。個人情報保護法のガイドライン通則編2-1は、個人情報を「他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む」と定義している（2026-08-09時点の個人情報保護委員会ガイドラインで確認）。つまり、自社の手元に注文番号と顧客を突き合わせられる状態がある限り、注文番号だけのデータも個人情報のままである。自社の受注管理画面に注文番号を入れれば氏名と住所が出てくるのだから、これは「容易に照合できる」典型に当たる。

「注文番号に置換したから匿名化された」「個人情報ではなくなったので自由に使える」という理解は、この点で誤っている。置換の効能は法的性質を変えることではない。外部に出る文字列から直接の識別子を落とし、万一そのデータが漏れたときの被害を小さくすること、この一点に限られる。似た概念として仮名加工情報（法2条5項）や匿名加工情報があるが、これらは法令で定められた加工基準を満たしたうえで、安全管理措置や利用・提供の制約とセットで成立する枠組みだ。単に列を置き換えた社内データがそれに当たるかどうかを自己判断で決めず、必要なら顧問弁護士や専門家に確認するのが安全である。

では、個人情報のままのデータを外部サービスに渡してよいのか。ここが上長や情シスに説明する本番になる。必要なのは「個人情報ではない」と言い張ることではなく、利用目的の範囲内であることの確認と、委託として整理し監督することの2つだ。次の2章で順に見る。

ステップ4：対応表の置き場所を決める。注文番号と顧客を突き合わせる表は、作った瞬間から受注データ本体と同じ機密度になる。ところが実務では、これがいちばん雑に扱われがちだ。個人PCのデスクトップに 置換表_0809.xlsx が残り、チャットに添付され、そのまま数か月放置される。決めるべきは3つ。①どこに置くか（既存の顧客データと同じ権限が掛かる場所に置く）②誰が見られるか ③いつ消すか。そもそも対応表を作らずに済むならそのほうがよく、AIに聞きたいのが「どの注文を人が見るべきか」なら、返ってきた行番号を手元のCSVと突き合わせれば足りることが多い。

「学習に使わない設定」で消えるリスクと、消えないリスク

「学習に使われない設定にしてあるから大丈夫」という説明をよく聞く。だが「学習に使わない」「人が見ない」「保存されない」は別々の項目であり、この3つが同時にゼロになるサービスは、公開情報を読む限り単純には見つからない。各社の公開ドキュメントを2026-08-09時点で確認した範囲では、次のように書き分けられている。

サービス	公開ドキュメントに記載されていること（2026-08-09時点）
OpenAI（ビジネス向け・API）	ビジネス向け製品およびAPIの入出力を既定でモデル学習に使わないと記載。個人向けChatGPTは設定でオプトアウトしない限り学習の対象になりうる
Anthropic（商用製品）	商用製品の入出力を既定でモデル学習に使わないと記載。ただしフィードバックを送信した会話は例外で、最大5年保存されると記載（当該記事の更新日2026-03-16）
Google（Gemini Apps）	一部のデータを人間のレビュアーが確認すると明記。ヘルプ上で機密情報を入力しないよう案内。レビュー済みの会話は最大3年保持と記載
Azure（同基盤で提供されるモデル）	プロンプトと応答を基盤モデルの学習に使わないと記載。一方で不正利用監視の一環として人がサンプルを確認する仕組みがあり、申請・承認により監視を制限できる旨が記載

読み取るべきは各社の優劣ではない。どのサービスでも、設定で消せるのは主に「学習利用」で、保存期間と人による確認は別の条件として残るという構造のほうだ。契約形態（個人向けか、業務向けか、API経由か）によっても条件は変わる。そして最も重要な点として、学習オフの設定は入力事故そのものを一切消さない。宛先を間違えて別の画面に貼った、共有中の画面に映した、私物アカウントで作業した——これらは設定では防げない。事故の多くは、モデルの内部ではなく貼る側の操作で起きる。

個人情報保護委員会は令和5年6月2日付の「生成AIサービスの利用に関する注意喚起等について」で、個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合、その取扱いが特定した利用目的の達成に必要な範囲内であることを十分に確認するよう求めている。加えて、本人の同意なく個人データを含むプロンプトを入力し、応答結果の出力以外の目的で取り扱われる場合には法違反となる可能性があるとして、当該個人データが機械学習に利用されないこと等を十分に確認することを挙げている（2026-08-09時点で個人情報保護委員会サイトにて確認）。

ここで求められているのは「学習オフのボタンを押すこと」ではなく確認である。設定を押した事実ではなく、利用目的の範囲内か、応答の出力以外に使われないか、その2点を確かめ、確かめた日付とページを残しておくこと。この違いは社内で説明を求められたときに効く。「オフにしました」だけでは、何をどう確認したのかが誰にも分からないからだ。

外部AIに渡すと「委託」になる：社内で実際に直す箇所

顧客データを外部のAIサービスに入れる行為は、社内的には「便利なツールを使う」だが、法的な整理では別の話になる。個人データの取扱いを外部に任せる形になるため、委託として整理される場面がある。ガイドライン通則編3-6-3は、委託に伴う個人データの提供は第三者提供に当たらないとしている（法27条5項1号）。第三者提供に当たらないということは本人同意の論点が外れるということだが、代わりに事業者側へ別の義務が掛かる。安全管理措置（3-4-2／法23条）と委託先の監督（3-4-4／法25条）である。委託先の監督として挙げられているのは、適切な委託先の選定、委託契約の締結、取扱状況の把握の3点だ（いずれも2026-08-09時点の同ガイドラインで確認）。

この整理を現場に落とすと、直す箇所は4つになる。

1. プライバシーポリシー。利用目的の記載と、委託に関する記載が現状の運用と一致しているか。何年も前に作ったまま、業務内容だけ増えている店舗は多い
2. 選定の根拠。そのAIサービスを選んだ理由を、公開ドキュメントの記述と確認日つきでメモしておく。前章の表のような形で十分だ
3. 契約。無料プランや個人アカウントは、契約主体が個人になっている場合がある。誰の名義でどの契約形態を使っているのかを確認する
4. 取扱状況の把握。誰が、どのアカウントで、どの範囲のデータを入れているか。ここが空白だと、事故が起きた日に「誰が何を入れたか」を再現できない

加えて、モール出店者にはもう1系統の縛りがある。モールから提供される購入者情報の利用範囲は、法令とは別に各モールとの契約・規約で定義される。店舗ごとに契約内容が異なりうるうえ、公開されていない条項も含むため、外部の記事の記述で判断してはいけない。楽天でもAmazonでも、自社が締結している規約の該当箇所を自分で開いて確認するのが唯一の方法だ。参考として、Amazonの開発者向け公開ドキュメントには購入者の個人情報へアクセスするための項目が独立して設けられており、購入者情報が通常のデータ取得とは別枠で扱われていることが読み取れる（2026-08-09時点で節見出しの存在を確認）。

貼ってよい／だめを判定する表を、1枚だけ作る

ここまでの話は、毎回考えていたら回らない。判断を1枚の表に落として、迷ったらそれを見る形にする。フローチャートではなく表にする理由は、受注CSVの列と1対1で対応させるためだ。

列は5つあれば足りる。

データ項目（CSVの列名そのまま）	直接の識別子か	この用途で必要か	渡し方	決めた人／日
Shipping Name	はい	いいえ	列ごと削除	受注担当A／2026-08-09
Shipping Zip	はい（住所そのもの）	地域集計のときだけ	削除。必要時は都道府県の列だけ残す	受注担当A／2026-08-09
Lineitem SKU	いいえ	はい	そのまま	受注担当A／2026-08-09
Notes（備考欄）	場合による	はい	辞書で振り分け、残りは氏名・番地を伏せて渡す	店長／2026-08-09

ポイントは3列目の「この用途で必要か」だ。列の危険度だけで表を作ると「危ないから全部だめ」になり、結局AIを使わない結論に落ち着く。用途とセットで判断するから、渡せる範囲が残る。だから表は用途ごとに行が増えてよい。同じ Notes 列でも、例外の仕分けなら加工して渡す、文面生成なら不要なので削除、と判断が変わる。

更新のきっかけも決めておく。①新しいモールやカートを追加したとき（列名が変わる）②CSVの出力項目を変えたとき ③判断に迷った行が出たとき。3つ目が実は一番大事で、迷った事例をその日のうちに1行足していくと、半年で自社固有の運用ルールが表の形で溜まる。逆にこれを口伝でやっていると、担当者が変わった瞬間に全部ゼロに戻る。

この表を作って更新できる人は、受注処理を処理している人ではなく、受注処理を設計している人だ。どのデータをどこまで外に出すかは、本来は情シスや管理側の判断とされてきた領域だが、CSVの列名と業務の用途を両方知らないと現実的な線は引けない。そして両方を知っているのは現場の担当者しかいない。この立ち位置がAIを入れる局面でどう効くかはEC担当者がこれから身につけるAIスキルで整理している。

マスキングしたつもりで漏れる箇所

最後に、列を落としたのに漏れる経路を挙げる。いずれも構造上ありうるという指摘で、発生頻度を測ったデータがあるわけではない。自社で該当するかを1つずつ確かめてほしい。

• 画面のスクリーンショット。CSVは丁寧に加工したのに、「この画面の意味を教えて」と受注一覧のスクショを貼る。画像でも文字は読み取られる。列を落とすのと同じ判断を、画像にも適用する必要がある
• 領収書・納品書のPDF。宛名は氏名そのもので、住所も刷り込まれている。「この書式を整えて」という用途でそのまま渡しやすい
• 熨斗とギフト。表書きの名入れは氏名であり、ギフトは依頼主とお届け先で2人分の情報が出る。同梱指示の文章にも紛れる
• 対応表そのもの。置換して安全にしたはずのデータと、対応表を、同じスレッドに貼ってしまう。これをやると加工した意味が完全に消える
• 会話の共有リンク。要約結果だけ共有するつもりでスレッド全体を共有すると、加工前に貼った内容まで一緒に出る
• 一部キャンセル・返品での崩れ。注文番号と行の対応を作った後に一部キャンセルが入ると、対応表と実データの整合が崩れる。番号を振り直すと今度は履歴が追えない。加工データは都度使い捨てにして長期保存しないほうが破綻しにくい

共通しているのは、加工の対象をCSVだけだと思っている点だ。判定表の対象を「受注CSVの列」ではなく「AIに渡すすべての素材」と定義し直すと、この6つはほぼ拾える。

よくある質問

注文番号に置き換えれば、そのデータは個人情報ではなくなりますか

なりません。個人情報保護法のガイドライン通則編2-1は、他の情報と容易に照合でき、それにより特定の個人を識別できるものを個人情報に含めています（2026-08-09時点で確認）。自社の受注管理画面に注文番号を入れれば顧客が特定できる状態なら、その注文番号入りのデータも個人情報として扱うのが前提です。置換の効果は、外部に出る情報量と、事故が起きたときの被害を小さくすることにあります。

無料版の生成AIに受注データを貼ってもよいですか

契約形態と設定によって条件が変わるため、一律には答えられません。個人向けのプランは、設定でオプトアウトしない限り入力内容が学習に使われうると案内している事業者があります（2026-08-09時点の各社ヘルプ）。業務で使う前に、①契約主体が会社になっているか ②学習利用と保持期間の記載 ③人によるレビューの有無、の3点を各サービスの公開ドキュメントで確認し、確認日を残しておくのが実務的です。

モールの規約上、購入者情報を外部AIに渡してよいですか

各モールとの契約・規約で定義される範囲の問題であり、外部の記事の記述では判断できません。自社が締結している規約の該当箇所を開いて、購入者情報の利用目的・第三者への提供・外部サービスの利用に関する条項を確認してください。判断に迷う場合は、モールの担当窓口や社内の法務に確認するのが確実です。

AIを入れると受注処理はどれくらい速くなりますか

取材や実測に基づく数値がないため、この記事では時間短縮率を出しません。自社で測るなら、工程2（例外の仕分け）と工程4（メール文面）だけを1週間分ストップウォッチで記録し、その2工程の合計時間の前後差を見るのが妥当です。ほかの工程は連携設定とマスタの精度で決まるので、AIの効果としては数えないほうが正確な数字になります。

あわせて読みたい：メール本文から受注データを取り出す具体的な手順は、受発注メールの本文から、受注データを取り出す手順で解説しています。

あわせて読みたい：自分の業務のどの工程がAIに置き換わりつつあるかを数える手順は、事務職はAIに奪われるのか——EC実務の「工程」で数え直すにまとめています。

あわせて読みたい: EC売上の分析に、AIはどこまで使えるのか

あわせて読みたい：ここで扱ったような日常業務のどれに値札が付いているかは、ネットショップ運営の求人、Indeed14件中8件が未経験可で求人票14件から確かめている。