［ネットショップ］縄文おやき通販ショップをFutureShopでリニューアル（システム移転のリアルな記録）

縄文おやきの小川の庄様のネットショップを、FutureShop へ移転・リニューアルさせていただきました。

大規模ECのシステム移転は本当に大変で、細かな確認と調整の連続です。完成したときの達成感は大きいのですが、そこに至るまでの道のりは「想像以上」。ネットショップご担当のスタッフさんとはほぼ3か月、密着で伴走させていただきました。大変お世話になりました。ありがとうございました。

■ FutureShop移転の主目的：Googleショッピング広告（Merchant Center）との自動連携

これまで利用していた MakeShop（こちらも高機能カートです）から移行した最大の理由は、Googleショッピング広告（Google Merchant Center）との連携を強化したかったためです。

FutureShopでは、Google Merchant Centerの管理（親）アカウントとしての連携が可能で、商品を登録すると自動的に商品リストへ反映され、ショッピング広告用フィードにも自動出稿できます。

多くの方が見落としがちですが、これは非常に重要です。
もしこの機能がなければ、Googleショッピングへ1点ずつ出稿する必要があります。
CSVでの一括登録も可能とはいえ、日々商品が変わる店舗（とくに季節入替が激しいアパレルなど）では、手動運用では広告の反映スピードが落ち、機会損失が発生します。

さらに無料掲載枠（Surfaces across Google）へのフィードも自動で送れるため、広告運用に慣れた方なら、この仕組みがどれほど強力かご理解いただけるはずです。

■ ネットショップ「システム移転」の壁と現実

移転は見た目のリニューアルだけではありません。データ定義・周辺システム・運用手順まで含めて、総合的に組み替える作業です。以下、実際に直面したポイントを記録しておきます。

１）会員データの移動（絶対に失えない“お店の資産”）

長年の運営で蓄積された会員データはお店の宝。ここを失うわけにはいきません。

一度でも移転でリストを失ってしまうと戻りませんし、「サイトが新しくなったから再登録してください」とお願いしても、実際には再登録率は伸びにくい。新規集客のコストをそこへ割くのは、利益面でもかなりのダメージです。

問題は、“項目（フィールド）定義の違い”です。各カートでデータ仕様が微妙に異なるため、単純なCSV乗せ替えでは通りません。

例えば——

• 郵便番号：Aシステムは7桁（ハイフンなし）、Bシステムは3桁-4桁（ハイフンあり）のみ許容、のような違いで自動移行が失敗します。

• 姓名／住所1・住所2なども、必須・文字種・最大桁数・分割規則が違うだけで、前処理（正規化）が必要になります。

• 既存データの不備も現実問題として存在します（例：異なるメールアドレスで重複会員IDを持つ、郵便番号不備のまま住所が登録されている、会員名義は夫だが発送者は妻名義など）。
  
  こうした“人間らしい揺らぎ”と“システムの厳格さ”の橋渡しを、移行スクリプトや手動クリーニングでひたすら整えていく必要があります。ここは地味ですが、移転の“心臓部”です。

２）商品データの移動（点数が増えるほど指数関数的にしんどい）

小川の庄様の場合、商品点数はそこまで多くなかったため、手動登録を選択しました。

この機会にカテゴリ／グループ／タグを整理し、読みやすく・わかりやすくなるよう情報設計も見直しながら登録を進めました。

一方で、200件・1000件といった規模になると手動は現実的ではありません。その場合は、

• 旧システムからのCSVエクスポート

• 新システムへのCSVインポート

• 画像形式・画像ファイル名の統一と一括アップロード

• 属性・バリエーションのマッピング
  
  などを行います。双方のデータ形式を合わせる前処理がとても大変です。
  
  でも、ご依頼いただいたら絶対完了させないといけないので、エンジニアがめっちゃがんばります（笑）。

３）会員特典／カート導線の再設計（“使いやすい”を定義し直す）

会員登録の流れ、会員特典、カートの独自組み込みは、システムごとに思想が違うため、そのままでは再現できません。

「お客様にとって本当にわかりやすいのはどれか」を、ご担当者様と試行錯誤しながら、UIテキスト・ボタン配置・画面遷移まで含めて見直しました。せっかくのリニューアルですから、「使いやすくなった、また買いに来たい」と感じてもらえる導線にする必要があります。

４）出荷システムとの連携（最難関。要件は各社バラバラ）

ここが本当に山場でした。

出荷システムが担うのは、ピッキングデータ出力 → 工場へのデータ連携 → 送り状（伝票）印刷 → 出荷完了番号の反映 → お客様への発送完了メールまで。まずはどのシステムを採用するかの選定から始まります。

現状の課題と理想像を整理し、各社に相談・見積。ただし、事情は各社まったく違うため、「これが絶対の正解」という答えはありません。現場の声を聞きながら、実機テストで最終判断していきます。

今回のケースでは、通販（カタログ・電話）や多拠点への卸も行っている事情から、現在使っている出荷システムをFutureShopでも使えるよう、仕組みをカスタマイズする方針が最善と判断。ヤマトシステムの『産直くん』を特別仕様に改造する形になりました（※ここにも相応の時間と費用がかかっています）。

ご担当者様側にも、ここには書き切れないほどの血と汗と涙 😥 の苦労があったはずです。

例えば——

「複数お届け先」の注文：

Aさんが自宅と、東京のBさん、北海道のCさんへ同時に別送したい場合、ポイントは購入者（Aさん）に付与され、Bさん・Cさんには付かない——これが一般的な仕様です。

このポイント・明細の計上ロジックが、出荷システム側にも正しく連携されていないと、出荷完了処理→産直くん→FutureShopへの実績戻しの際に整合性エラーが発生します。

今回はポイントの例を挙げましたが、レアケースは無数にあります。すべてのパターンを想定して、テストと検証を反復するしかありません。一定規模以上のEC運営とは、つまるところこういう地道な整合の積み上げでもあるのです。

そして、こういうとき本当に頼りになるのが、知識のある高品質なカート／外部システムのサポート体制です。

FutureShop と 産直くん のご担当者様には、何度も何度も質問と検証にお付き合いいただきました。電話がつながらない、メールの返信が遅いといった、いわゆる**“安かろう悪かろう”な体制では、正直、こうした移転プロジェクトは詰みます 😡 。
サポート品質は“コスト”ではなく、移転成功の前提条件だと痛感します。

まとめ：システム移転は「見た目の引っ越し」ではなく、運用の再設計

• 会員データは資産。狙うための正規化と移行設計は不可欠。

• 商品データは規模に応じて戦略を変える。小規模なら情報設計の見直しを兼ねて手動も有効。大規模なら前処理と自動化が肝。

• カート導線は“思想”がカートごとに違う。使いやすさの再定義が必要。

• 出荷システム連携は最難所。現場要件×システム仕様のすり合わせ、例外ケースの潰し込み、テスト反復が成功の鍵。

• そして最後に、高品質なサポートがあるカートを利用することが、移転の成否を左右します。

FutureShop移転の主目的だったGoogleショッピングとの自動連携は、広告運用と無料掲載枠の両輪を自然に回すための、根っこの仕組みです。

移転は大変ですが、やる価値は大きい。同じような案件で見積や検討依頼をいただくたび、今回のような具体的な論点を説明しながら進めています（正直、毎回けっこう疲れます 😥 …）。この記録が、これから移転を検討する方の実務的な資料として役立てば嬉しいです。