CONTENT
ここから
第14章では、注文完了メール、店舗向け通知、発送案内など、決済後の連絡まわりを整理しました。
この章では、店舗側が注文を確認し、配送準備を進めるためのEC管理画面を作ります。
EC管理画面は、購入者には見えない裏側の画面です。
しかし、実務ではとても重要です。
なぜなら、管理画面が分かりにくいと、次のようなミスが起きるからです。
・注文に気づかない
・発送済みかどうか分からない
・同じ注文を二重に処理してしまう
・キャンセル注文を発送してしまう
・メールを送ったか分からなくなる
・手動確認が必要な注文を見落とす
つまり、管理画面は単なる一覧画面ではありません。
店舗が安全にECを運用するための司令室です。
攻略本風に言えば、第15章は**「注文をさばく拠点を作るステージ」**です。
15.1 管理画面で必要な機能
まず、EC管理画面に必要な機能を整理します。
最初から高機能な管理画面を作る必要はありません。
小規模ECで最初に必要なのは、次の機能です。
・注文一覧を見る
・注文詳細を見る
・注文ステータスを変更する
・手動確認が必要な注文を見る
・発送済みにする
・追跡番号を登録する
・注文を検索する
・CSVで出力する
最小構成であれば、まずは注文管理だけで十分です。
最初に作る：
注文一覧
注文詳細
ステータス変更
あとから作る：
商品管理
在庫管理
配送管理
CSV出力
管理画面で大切なのは、機能の多さではありません。
今日、店舗が何をすればよいか分かることです。
そのため、管理画面のトップでは、次のような情報を見せます。
・新規注文
・配送準備中
・手動確認が必要な注文
・メール送信失敗
・発送待ち
たとえば、管理画面の入口は次のような構成にします。
EC管理画面
↓
注文一覧
↓
注文詳細
↓
ステータス変更
↓
発送処理
最初の目標は、店舗の人が次の判断をすぐにできることです。
この注文は確認済みか
この注文は発送してよいか
この注文は手動確認が必要か
この注文はもう対応済みか
管理画面は、開発者のためではなく、店舗のために作ります。
15.2 認証の設計
管理画面には、注文情報や配送先情報が表示されます。
そのため、誰でも見られる状態にしてはいけません。
必ず認証を入れます。
公開ページ：
誰でも見られる
管理画面：
ログインした管理者だけが見られる
管理画面のURLは、たとえば次のようにします。
/admin
/admin/orders
/admin/orders/[orderId]
ただし、URLを知っているだけで入れる設計は危険です。
必ずログイン確認を行います。
/admin にアクセス
↓
ログイン済みか確認
↓
ログイン済みなら表示
↓
未ログインならログインページへ移動
Next.jsで考える場合、管理画面はサーバー側で認証状態を確認するのが基本です。
理由は、ブラウザ側だけで制御すると、画面を隠しているだけになりやすいからです。
よい設計：
サーバー側でログイン確認する
危険な設計：
Client Componentだけで表示・非表示を切り替える
認証方法には、いくつかの選択肢があります。
・Supabase Auth
・Auth.js
・独自ログイン
・Basic認証
・管理者だけの簡易パスワード
本格運用では、Supabase AuthやAuth.jsのような認証基盤を使う方が安全です。
ただし、最初の検証段階では簡易的な認証から始めることもあります。
重要なのは、次の3点です。
・管理画面を一般公開しない
・ログイン状態をサーバー側で確認する
・管理者以外に注文情報を見せない
環境変数にも注意します。
よい例：
ADMIN_EMAIL=
ADMIN_ALLOWED_DOMAIN=
悪い例：
NEXT_PUBLIC_ADMIN_SECRET=
NEXT_PUBLIC_が付いた環境変数はブラウザ側に公開される可能性があるため、秘密情報には使いません。
15.3 管理者ロールの考え方
管理画面を使う人が1人だけなら、最初は「ログインできる人は全員管理者」でも運用できます。
しかし、店舗スタッフ、発送担当、オーナーなど、複数人が使う場合は、権限を分けた方が安全です。
これをロール設計と呼びます。
ロールとは、役割のことです。
owner 全体を管理できる
manager 注文や商品を管理できる
staff 発送処理だけできる
viewer 閲覧だけできる
たとえば、次のように分けます。
オーナー：
売上確認、注文管理、商品管理、設定変更
店長：
注文管理、発送管理、在庫確認
スタッフ：
注文確認、発送ステータス変更
閲覧者：
注文を見るだけ
小規模ECでは、最初から細かく作りすぎる必要はありません。
まずは次の2種類で十分です。
admin:
すべて操作できる
staff:
注文確認と発送処理ができる
ロールを設計するときの考え方は、次の通りです。
必要な人に
必要な機能だけを
必要な範囲で見せる
たとえば、発送担当者に商品価格の変更機能は必要ありません。
発送担当者に必要：
注文一覧
注文詳細
配送先
追跡番号登録
発送済み変更
発送担当者に不要：
商品価格変更
管理者追加
決済設定
ロール設計をすると、誤操作や情報漏えいのリスクを減らせます。
特に個人情報を扱うECでは、誰が何を見られるかを決めておくことが重要です。
15.4 注文一覧ページを作る
注文一覧ページは、管理画面で最もよく使う画面です。
店舗の人は、ここを見て「今日何を処理するか」を判断します。
注文一覧に表示する基本項目は、次の通りです。
・注文番号
・注文日時
・購入者名
・合計金額
・注文ステータス
・配送ステータス
・メール送信状況
・手動確認フラグ
画面イメージです。
注文一覧
[手動確認] ORDER-0005 山田 太郎 5,400円 manual_review
[決済完了] ORDER-0004 佐藤 花子 3,200円 paid
[配送準備] ORDER-0003 鈴木 一郎 8,800円 preparing
[発送済み] ORDER-0002 田中 美咲 4,500円 shipped
重要なのは、すべての注文を同じ見た目にしないことです。
手動確認が必要な注文は、すぐに分かるようにします。
優先度が高い：
manual_review
メール送信失敗
決済完了だが未確認
発送期限が近い注文
逆に、発送済みの注文は目立たせすぎる必要はありません。
注文一覧では、次のような並び順が使いやすいです。
1. 手動確認が必要な注文
2. 決済完了した新規注文
3. 配送準備中の注文
4. 発送済みの注文
5. キャンセル注文
TypeScriptで注文一覧用の型を作ると、次のようになります。
type OrderListItem = {
id: string;
orderNumber: string;
customerName: string;
totalAmount: number;
orderStatus: OrderStatus;
emailStatus: EmailStatus;
createdAt: string;
};
注文一覧では、詳細すぎる情報は出しすぎない方が見やすいです。
一覧では要点だけを表示し、詳しい情報は注文詳細ページで確認します。
一覧ページ：
どの注文を見るべきか判断する
詳細ページ：
その注文をどう処理するか判断する
この役割分担が大切です。
15.5 注文詳細ページを作る
注文詳細ページでは、1つの注文に関する情報をすべて確認できるようにします。
注文一覧で気になる注文をクリックすると、詳細ページに移動します。
/admin/orders
↓
/admin/orders/ORDER-0001
注文詳細に表示する情報は、次の通りです。
・注文番号
・注文日時
・注文ステータス
・決済ステータス
・購入者情報
・配送先情報
・商品情報
・金額情報
・メール送信状況
・配送情報
・対応履歴
・管理メモ
画面構成は、次のように分けると分かりやすくなります。
注文詳細
1. 注文の状態
2. 購入者情報
3. 配送先
4. 商品内容
5. 金額
6. メール送信状況
7. 操作ボタン
8. 対応履歴
注文詳細で大切なのは、状態と操作を近くに置くことです。
たとえば、ステータスがpaidの場合、次の操作が必要になります。
現在の状態：
決済完了
次の操作：
配送準備へ進める
そのため、画面には次のように表示します。
注文ステータス：決済完了
操作：
[配送準備へ進める]
[手動確認にする]
[注文完了メールを再送]
発送準備中の場合は、次のようになります。
注文ステータス：配送準備中
操作：
[追跡番号を登録する]
[発送済みにする]
注文詳細ページには、操作履歴も残します。
2026-07-06 14:31 決済完了
2026-07-06 14:31 顧客メール送信
2026-07-06 14:32 管理者通知送信
2026-07-06 15:10 配送準備へ変更
履歴があると、あとから「誰が、いつ、何をしたか」が分かります。
小規模ECでも、対応履歴はとても重要です。
15.6 ステータス変更機能
管理画面では、注文ステータスを変更できるようにします。
ただし、どの状態からでも自由に変更できる設計は危険です。
たとえば、pendingの注文をいきなりshippedにできてしまうと、決済前の注文を発送してしまう可能性があります。
そのため、変更できる流れを決めます。
pending
↓
paid
↓
preparing
↓
shipped
キャンセルや手動確認も含めると、次のようになります。
pending
→ paid
→ failed
→ cancelled
paid
→ preparing
→ manual_review
→ cancelled
preparing
→ shipped
→ manual_review
manual_review
→ paid
→ cancelled
ステータス変更は、ボタンで行うと分かりやすいです。
[配送準備へ進める]
[発送済みにする]
[キャンセルにする]
[手動確認にする]
ただし、危険な操作には確認を入れます。
キャンセルにしますか？
この操作は注文対応に影響します。
ステータス変更用の型を作ると、次のようになります。
type ChangeOrderStatusInput = {
orderId: string;
nextStatus: OrderStatus;
reason?: string;
};
/**
* 役割: 注文ステータスを変更する
* 入力: 注文ID、変更後ステータス、変更理由
* 出力: 更新後の注文ステータス
*/
async function changeOrderStatus(
input: ChangeOrderStatusInput
): Promise<OrderStatus> {
// 実際の実装では、現在のステータスを確認してから更新する
// 許可されていない変更はエラーにする
return input.nextStatus;
}
ここで大切なのは、フロントエンドのボタンを非表示にするだけでなく、サーバー側でも変更可能か確認することです。
画面上でボタンを隠す
＋
サーバー側でも変更ルールを確認する
管理画面の操作は、必ずサーバー側で守ります。
15.7 注文検索・絞り込み
注文数が少ないうちは、一覧を見るだけでも問題ありません。
しかし、注文が増えると検索や絞り込みが必要になります。
検索できると便利な項目は、次の通りです。
・注文番号
・購入者名
・メールアドレス
・電話番号
・商品名
・ステータス
・注文日
最初に作るなら、次の3つで十分です。
・注文番号検索
・ステータス絞り込み
・注文日絞り込み
画面イメージです。
注文検索
注文番号：[ ORDER-0001 ]
ステータス：[ 決済完了 ▼ ]
注文日：[ 2026-07-01 ] 〜 [ 2026-07-31 ]
[検索する]
よく使う絞り込みは、ボタンにしておくと便利です。
[新規注文]
[配送準備中]
[手動確認]
[メール失敗]
[発送済み]
検索・絞り込みで注意したいのは、個人情報の扱いです。
電話番号やメールアドレスで検索できると便利ですが、表示や権限には注意します。
admin:
すべて検索できる
staff:
注文番号、商品名、ステータスで検索できる
viewer:
閲覧のみ
また、検索結果が多すぎる場合はページネーションを入れます。
1ページ目：50件
2ページ目：50件
3ページ目：50件
管理画面は、表示速度も大切です。
過去すべての注文を一度に読み込むのではなく、必要な件数だけ取得します。
15.8 CSV出力
CSV出力は、実務でよく使います。
たとえば、次のような場面です。
・配送会社の送り状作成
・売上集計
・会計ソフトへの取り込み
・注文データのバックアップ
・催事販売後の集計
CSVとは、表形式のデータをカンマ区切りで保存する形式です。
ExcelやGoogleスプレッドシートで開けます。
CSVに出力する項目は、目的によって変えます。
配送用CSVであれば、次の項目が必要です。
注文番号
購入者名
郵便番号
住所
電話番号
商品名
数量
配送方法
備考
売上集計用CSVであれば、次のようになります。
注文番号
注文日時
商品名
数量
小計
送料
合計金額
決済方法
注文ステータス
すべての情報を1つのCSVに入れると、使いにくくなることがあります。
そのため、出力目的ごとに分けると便利です。
・配送用CSV
・売上用CSV
・注文一覧CSV
CSV出力で注意したいのは、個人情報です。
配送用CSVには住所や電話番号が必要ですが、売上集計用CSVには不要な場合があります。
配送用：
住所、電話番号が必要
売上用：
住所、電話番号は不要なことが多い
必要な情報だけを出力する設計にします。
また、CSV出力は管理者だけに許可する方が安全です。
admin:
CSV出力可能
staff:
必要なCSVだけ出力可能
viewer:
CSV出力不可
CSVは便利ですが、ダウンロード後の管理はシステム外になります。
そのため、出力履歴を残しておくと安心です。
2026-07-06 15:20
配送用CSVを出力
実行者：admin@example.com
対象期間：2026-07-01〜2026-07-06
15.9 管理画面のUI設計
管理画面のUIは、かっこよさよりも分かりやすさが重要です。
店舗の人は、毎日短い時間で注文を確認します。
そのため、画面を見た瞬間に状態が分かる設計にします。
管理画面のUIで大切なことは、次の通りです。
・ステータスが分かりやすい
・重要な注文が目立つ
・操作ボタンが迷わない
・危険な操作が目立ちすぎない
・一覧と詳細の役割が分かれている
ステータス表示は、日本語ラベルにします。
pending 決済待ち
paid 決済完了
preparing 配送準備中
shipped 発送済み
cancelled キャンセル
failed 決済失敗
manual_review 手動確認
英語のまま表示すると、運用担当者が判断しにくくなることがあります。
悪い例：
manual_review
よい例：
手動確認が必要
一覧画面では、色やラベルで優先度を分かりやすくします。
ただし、色だけに頼らない方が安全です。
よい例：
[手動確認] 注文内容の確認が必要です
悪い例：
赤色だけで危険を表す
ボタンの文言も重要です。
分かりにくい：
更新する
変更する
実行する
分かりやすい：
配送準備へ進める
発送済みにする
注文完了メールを再送する
管理画面では、次の行動が分かる文言にします。
また、スマホ対応も検討します。
小規模店舗では、PCではなくスマホで注文確認することもあります。
スマホで見る可能性がある画面：
注文一覧
注文詳細
新規注文通知からの確認
すべての管理機能をスマホ最適化する必要はありません。
ただし、注文確認だけはスマホでも見やすくしておくと実務で便利です。
15.10 誤操作を防ぐ設計
管理画面では、誤操作を完全にゼロにすることはできません。
しかし、起きにくくすることはできます。
特に注意したい操作は、次の通りです。
・注文キャンセル
・発送済みへの変更
・メール再送
・在庫数の変更
・CSV出力
・個人情報の表示
誤操作を防ぐ基本は、確認画面を入れることです。
この注文をキャンセルしますか？
キャンセル理由を入力してください。
発送済みにする場合も、確認を入れます。
この注文を発送済みにしますか？
追跡番号が登録されているか確認してください。
メール再送では、同じメールが何度も送られないようにします。
この注文完了メールはすでに送信済みです。
再送しますか？
さらに安全にするなら、操作履歴を残します。
2026-07-06 15:30
注文ステータスを「配送準備中」に変更
実行者：admin@example.com
操作履歴があると、あとから原因を追えます。
誰が
いつ
何を
なぜ変更したか
これを残しておくと、店舗側の安心感も上がります。
危険な操作は、ボタンの配置にも注意します。
よい例：
[発送済みにする]
少し離して配置：
[キャンセルする]
よく使う操作と危険な操作を近くに置くと、押し間違いが起きやすくなります。
また、キャンセルや削除のような操作は、できるだけ元に戻せる設計にします。
完全削除
→ 基本的に避ける
キャンセルステータスに変更
→ 履歴が残る
ECでは、注文データを簡単に消さない方が安全です。
注文を削除するのではなく、ステータスで管理します。
注文を消す
→ 過去の対応履歴が分からなくなる
キャンセルにする
→ 記録が残る
管理画面は、便利さだけでなく、ミスを起こしにくいことが重要です。
第15章のまとめ
EC管理画面は、店舗が注文を安全に処理するための司令室です。
購入者には見えませんが、EC運用の品質を大きく左右します。
この章で覚えておきたいポイントは、次の通りです。
1. 管理画面は、店舗が今日やるべきことを分かるようにする
2. 注文一覧では、重要な注文を見つけやすくする
3. 注文詳細では、状態と次の操作を分かりやすくする
4. 管理画面には必ず認証を入れる
5. 管理者ロールを分けると誤操作を減らせる
6. ステータス変更は、許可された流れだけにする
7. 検索・絞り込みで注文を探しやすくする
8. CSV出力は目的別に分ける
9. UIは見た目よりも運用しやすさを優先する
10. 危険な操作には確認と履歴を残す
最初から完璧な管理画面を作る必要はありません。
まずは、次の3つを作れば十分です。
・注文一覧
・注文詳細
・ステータス変更
この3つがあるだけで、ECの運用は大きく安定します。
第16章では、注文管理の次に必要になる、商品登録・編集・在庫変更などの商品管理機能を作っていきます。