この記事でわかること
EC-CUBEの注文番号は、標準では1から始まる連番です。そのままお客様に表示すると、注文件数や事業規模を推測されてしまう可能性があります。かといって、注文番号を安易に変更すると、受注管理・帳票・CSV・外部連携といった運用全体に影響が及びます。本記事では、EC-CUBE内部の受注IDは一切変更せず、お客様向けの注文番号だけを差し替えるという設計の考え方と、フロントから管理画面・帳票・CSVまで一貫して整合させる実装範囲を解説します。
EC-CUBE標準の注文番号は「連番」
EC-CUBEでは、注文が入るとデータベース側で自動的に採番され、1、2、3……と順に増えていく連番が注文番号になります。この番号は、注文完了画面やマイページ、各種メールなどでお客様にも表示されます。
連番はシンプルで分かりやすく、管理する側にとっては扱いやすい仕組みです。しかし「そのままお客様に見せてよいか」は別の問題です。連番には、公開することで生じる副作用があります。
連番のまま公開すると何が問題か
注文番号を連番のまま表示すると、次のような問題が起こり得ます。
| 問題 | 内容 |
|---|---|
| 累計の注文件数が分かる | 注文番号がそのまま「これまでに何件注文があったか」を意味する。オープン直後や注文の少ない時期は、番号の小ささから事業規模を推測されてしまう |
| 期間あたりの注文数が推測される | 時期をずらして2回注文すれば、その差分から「その間に何件の注文があったか」が分かる。競合他社に売上規模の推測材料を与えることになる |
| 他の番号を推測できてしまう | 連番は次の番号・前の番号が自明。番号を手がかりにした不正なアクセスを試みられる余地を残す |
| 社内の管理番号をそのまま公開してしまう | 内部管理用の番号体系を、そのままお客様や取引先に見せることになる |
ご相談をいただくとき、その動機は「売上を隠したい」という後ろ向きなものではありません。注文番号は、取引先や競合に対して、事業規模や成長状況を推測させる材料になる——ここが問題の本質です。特にBtoBでは、「この会社は年間どれくらい受注しているのか」を取引先に推測されることを避けたい、という相談も少なくありません。連番をそのまま公開することは、意図せず経営情報を開示していることになります。注文番号の設計は、経営情報の保護の一環でもあるということです。
そこで、お客様に表示する注文番号を、連番から推測されにくい形式に変更する——これが注文番号カスタマイズの主な目的です。たとえば「注文日時をもとにした数字＋ランダムな数桁」といった形式にすれば、番号から件数を読み取ることはできなくなります。
設計の肝：内部の受注IDは変更しない
ここからが、この記事で最も重要な部分です。
注文番号を変えたいとき、安易に「EC-CUBE内部の受注ID（採番の仕組みそのもの）」を変更してしまうと、運用全体に影響が及びます。正しい設計は、内部の受注IDには一切手を触れず、「お客様向け注文番号」を別に持たせて、表示だけを差し替えることです。
| 内部IDごと変更する | お客様向け番号だけ差し替える（推奨） | |
|---|---|---|
| プラグインへの影響 | 受注IDを前提に作られたプラグインが動かなくなる恐れ | 影響なし |
| 外部システム連携 | 基幹システムや倉庫システムとの連携キーが変わり、連携が壊れる | 影響なし |
| 既存の受注データ | 過去データとの整合が崩れるリスク | 過去データはそのまま維持できる |
| EC-CUBEのバージョンアップ | 本体の中核に手を入れるほど、将来の更新が困難になる | 影響を最小限に抑えられる |
| 不具合時の切り分け | 原因の特定が難しくなる | 表示層の問題として切り分けやすい |
実際の案件でも、EC-CUBE内部の受注IDは変更せず、お客様向けの注文番号を新たに持たせる形で実装しました。これにより、既存のプラグインや外部連携、過去の受注データに影響を与えることなく、お客様に見える番号だけを変更できます。
注文番号のカスタマイズを検討中の方へ
「連番のまま公開したくない」「でも運用を壊したくない」——内部の受注IDに影響を与えない注文番号カスタマイズを、御社の運用に合わせてご相談いただけます。
実装範囲：変更した注文番号をどこまで反映させるか
注文番号のカスタマイズで、実務上いちばん手間がかかるのが「反映範囲」です。番号を作ること自体は難しくありませんが、注文番号はサイトのあらゆる場所に登場します。どこか一箇所でも古い番号のままだと、お客様も運営も混乱します。
実際の案件では、次の範囲すべてに一貫して反映させました。
反映先は、大きく「お客様が見る場所」「運営が使う場所」「出力されるデータ」の3つに分かれます。1つの注文番号が、この3方向すべてに同時に現れると考えてください。
| 区分 | 反映先 | なぜ必要か |
|---|---|---|
| お客様が 見る場所 | 注文完了画面 | お客様が最初に注文番号を目にする場所 |
| マイページの注文履歴 | お客様が後から注文を確認する場所。完了画面と番号が違うと混乱する | |
| 各種メール | 注文確認・発送通知など。メールの番号が画面と違えば問い合わせが増える | |
| 運営が 使う場所 | 管理画面の受注一覧・受注詳細 | お客様から番号で問い合わせが来たとき、運営側が同じ番号を見られる必要がある |
| 管理画面の受注検索 | お客様が伝えてきた番号で検索できなければ、問い合わせ対応が成立しない | |
| 出力される データ | 帳票PDF | 納品書や受注明細書に記載される番号。出荷作業や取引先とのやり取りで使われる |
| CSV出力 | 外部システムへの連携や、社内での集計に使われる |
このうち1箇所でも対応が漏れると、そこだけ古い番号が表示されます。お客様が見る番号と、運営が見る番号と、帳票に載る番号が食い違う——これが起きると、問い合わせ対応も出荷作業も混乱します。注文番号のカスタマイズは、番号を作る作業ではなく、この3方向すべてを漏れなく揃える作業だと考えた方が実態に近いです。
見落とされがちだが決定的に重要な「検索対応」
実装範囲の中で、最も見落とされやすく、それでいて最も重要なのが管理画面の検索対応です。
注文番号を変えるカスタマイズで「フロントの表示だけ変更して終わり」という実装を見かけることがありますが、それでは運用初日から問い合わせ対応が止まります。表示を変えたなら、その番号で必ず探せるようにする。これは機能追加ではなく、運用を成立させるための必須要件です。
注文番号は帳票にも記載されるため、帳票のカスタマイズと合わせて検討されることも少なくありません。帳票についてはEC-CUBEで受注明細書PDFを出力するメリットとは？で解説しています。
既存の注文をどう扱うか
すでに稼働しているECサイトで注文番号を変更する場合、「過去の注文をどうするか」という判断が必要になります。
| 方針 | 内容 | 考慮点 |
|---|---|---|
| 既存注文は従来の表示のまま | 新しい注文からのみ、新しい番号体系を適用する | 過去の注文について、お客様や社内が把握している番号が変わらない。混乱が起きにくい |
| 既存注文にも新番号を振り直す | 過去の注文もすべて新体系に統一する | お客様が把握している番号や、過去のメール・帳票との整合が取れなくなる恐れがある |
実際の案件では、既存の注文は従来どおりの表示を維持し、新規注文から新しい番号体系を適用する方針を採りました。過去の注文番号は、お客様の手元のメールや帳票、社内の記録にすでに残っています。それを後から書き換えると、かえって照合できなくなるためです。運用中のサイトでは、この方針が現実的です。
どんなECサイトに向くか
- 注文番号から注文件数や事業規模を推測されたくない
- サイトをオープンして間もなく、注文番号の小ささが気になる
- 競合に売上規模の推測材料を与えたくない
- 社内の管理番号をそのままお客様に見せたくない
- すでにプラグインや外部システム連携が入っており、運用を壊さずに変更したい
特に、すでに稼働中で外部連携やプラグインが組み込まれているサイトほど、「内部IDを変更しない」設計の価値が高くなります。運用を止めず、既存の仕組みに影響を与えずに、お客様に見える部分だけを変更できるためです。
あわせて読まれています
よくある質問
EC-CUBEの注文番号は標準で変更できますか？
標準の設定では変更できません。EC-CUBEの注文番号はデータベース側で自動採番される連番で、管理画面の設定から形式を変えることはできない仕様です。表示する注文番号を変更したい場合はカスタマイズが必要になります。EC-CUBEはオープンソースのため、こうした変更にも対応できます。
注文番号を変更すると、プラグインや外部システム連携に影響しますか？
設計次第です。EC-CUBE内部の受注IDそのものを変更すると、その受注IDを前提に動いているプラグインや、基幹システム・倉庫システムとの連携が壊れる恐れがあります。一方、内部の受注IDには手を触れず、お客様向けの注文番号を別に持たせて表示だけを差し替える設計であれば、既存のプラグインや外部連携に影響を与えずに変更できます。運用中のサイトでは、後者の設計が安全です。
変更した注文番号で、管理画面から注文を検索できますか？
検索できるように実装する必要があります。お客様は自分に表示された注文番号で問い合わせてくるため、その番号で管理画面から該当の注文を探せなければ、問い合わせ対応が成立しません。注文番号のカスタマイズでは、表示の変更だけでなく、管理画面の受注一覧・受注詳細・検索機能まで一貫して対応させることが重要です。あわせて、メール・帳票PDF・CSV出力への反映も必要になります。
すでに稼働中のサイトでも、注文番号を変更できますか？
可能です。稼働中のサイトでは「既存の注文は従来どおりの表示のまま、新規の注文からのみ新しい番号を適用する」という方式を採用するケースが一般的です。過去の注文番号は、お客様の手元のメールや帳票、社内の記録にすでに残っています。それを後から書き換えると、かえって照合できなくなるためです。この方式であれば、運用を止めることなく、これからの注文から新しい番号体系に切り替えられます。現状のサイト構成によって実装方法は変わりますので、まずはご相談ください。
EC-CUBEの注文番号カスタマイズ、ご相談を承ります
EC-CUBE公式パートナーとして、17年以上にわたりEC-CUBEのカスタマイズを手がけてきました。注文番号の変更は、フロント・メール・管理画面・検索・帳票・CSVまで一貫して対応させ、かつ内部の受注IDに影響を与えない設計が重要です。運用を壊さない実装をご提案します。
投稿者プロフィール
- サンクユーのEC-CUBE担当。15年以上にわたりEC-CUBE開発に従事し、2系・3系・4系すべてに精通。難易度の高いカスタマイズや、他社構築サイトの改修・再設計も多数対応しています。
Javaでの業務システム開発を起点に、PHP・Perl・フロントエンド・CMSまで横断的に対応。基幹システム連携や業務フローを踏まえた設計を得意とし、複雑な要件にも柔軟に対応可能です。
ChatGPT CODEXを活用し、開発スピードと品質の両立を実現しています。
