「頼んだ修正が2週間返ってこない」「担当者が変わってから話が通じない」「保守費を払っているのに何もしてくれない」——Shopifyサイトを制作会社に任せている事業者から、最も多く寄せられる相談です。しかし感情的な不満だけで乗り換えると、たいていもっと悪い状況になります。本記事では、乗り換えを検討すべき客観的な判断基準、引き継ぎで揉めないためのデータ・権限・契約のチェックリスト、そして「乗り換えるべきでないケース」までを、ドライに整理します。
制作会社の乗り換えとは何か
この定義が示す通り、乗り換えで最も難しいのは新しい会社を選ぶことではありません。今の会社から、必要なものをすべて受け取ることです。ここが不完全なまま乗り換えると、新しい会社は「何がどうなっているか分からないサイト」を渡されることになり、調査だけで数十時間を要し、その工数はそのまま発注側の費用になります。
乗り換えの3つのパターン
① 保守・運用だけを乗り換える
サイト自体はそのまま、日々の更新と保守の担当会社だけを変えるパターン。最も一般的で、リスクも低い。ただし前任者の実装をそのまま引き継ぐため、コードの品質次第で難易度が変わります。
② 作り直しを伴う乗り換え
現行サイトの構造そのものに問題があり、新しい会社で再構築するパターン。費用は大きいが負債を清算できる。URL構造が変わる場合はリダイレクト設計が必須になります。
③ 内製化への移行
外部委託をやめ、社内で運用する体制に移すパターン。最も見落とされがちな選択肢ですが、更新頻度が低い事業者にとっては最も合理的な場合があります。
用語解説
| 用語 | 意味 |
|---|---|
| コラボレーター権限 | 制作会社などの外部パートナーにShopify管理画面へのアクセスを許可する仕組み。ストアオーナーが発行・削除できる。 |
| ストアオーナー | Shopifyストアの最上位権限者。課金情報の管理、権限の付与・剥奪ができる唯一の役割。必ず自社が保持すべき。 |
| テーマファイル | サイトの見た目と動作を定義するコード一式。Liquid、CSS、JavaScriptで構成される。ダウンロードして保管できる。 |
| カスタムアプリ | 特定のストア専用に開発されたアプリ。制作会社が自社アカウントで作成している場合、乗り換え時に引き継げないことがある。 |
| Liquid | Shopifyのテンプレート言語。テーマのカスタマイズはこの言語で行われる。 |
| 技術的負債 | 短期的な対応を優先した結果、後の改修コストを増大させている実装状態。乗り換え時に初めて可視化されることが多い。 |
なぜ制作会社との関係は壊れるのか（業界構造）
個別の会社の良し悪しの前に、構造を理解しておくと判断を誤りません。
構造①：制作と運用でビジネスモデルが違う
制作は数百万円規模の一括案件、運用は月額数万円の継続案件です。収益構造がまったく異なるため、制作が得意な会社が運用も得意とは限りません。公開直後に対応が悪化するのは、多くの場合この構造が原因です。
構造②：担当者の属人化
制作会社側も少人数体制であることが多く、実装内容が特定の担当者の頭の中にしかないケースが頻発します。担当者の退職・異動と同時に、対応品質が急落するのはこのためです。
構造③：保守契約の範囲が曖昧
「月額◯万円で保守」とだけ書かれた契約では、何が含まれるか双方の理解が食い違います。発注側は「何でも頼める」と思い、制作側は「障害対応のみ」と考えている——この認識差が不満の温床です。
構造④：発注側の依頼が言語化されていない
「なんとなく使いにくい」「もっと売れるようにして」という依頼は、制作側から見ると着手不能です。対応が遅い原因が、実は依頼の曖昧さにあるケースは少なくありません。ここは発注側にも改善余地があります。
構造④は特に重要です。乗り換える前に、「自社の依頼の出し方に問題はないか」を一度点検してください。依頼の質を変えずに会社だけ変えても、同じ不満が半年後に再発します。これは厳しい指摘ですが、実務上きわめてよく起きる現象です。
乗り換えを検討すべき7つの客観的サイン
感情ではなく事実で判断するための基準です。4つ以上該当するなら乗り換えの検討価値があります。
- 軽微な修正の対応が、常に2週間以上かかるテキスト修正や画像差し替えといった数十分で終わる作業に2週間以上要する状態が3か月続いているなら、体制上の問題です。繁忙期の一時的な遅延とは区別してください。
- 見積もりの根拠を説明できない「この改修に◯万円」の内訳を聞いても工数や作業内容が出てこない。健全な関係では、金額の理由は必ず説明できます。
- サイトの仕様を誰も把握していない「なぜこの実装になっているのか」を尋ねて「前任者がやったので分かりません」が続く状態。これは最も危険なサインです。障害発生時に復旧できない可能性があります。
- 提案がゼロで、言われたことしかやらない数値レポートも改善提案もなく、依頼した作業だけが返ってくる。保守契約としては成立していても、事業成長のパートナーとしては機能していません。
- 管理権限を渡してもらえないストアオーナー権限やドメイン管理権限を制作会社が握り、移管を求めても応じない。これは契約以前の問題で、即座に乗り換えを検討すべき事案です。
- 担当者が1年で回以上変わっている引き継ぎのたびに同じ説明を繰り返している状態。制作会社側の体制が不安定であり、今後も改善が期待しにくい兆候です。
- 売上が落ちている原因を一緒に考えてくれないサイトの数値が悪化しているのに、「デザインの問題ではない」で議論が終わる。事業視点を持たない相手に、事業成果は期待できません。
⚠️ サイン⑤「権限を渡さない」は例外なく赤信号です
Shopifyのストアオーナー権限、独自ドメインの管理者権限、Google Analyticsやサーチコンソールの所有権——これらはすべて発注側が保持すべき資産です。制作会社がこれらを握っている状態は、乗り換えを事実上不可能にする構造であり、健全な取引関係ではありません。
もし現在この状態にあるなら、乗り換えの検討以前に、まず権限の移管を書面で正式に要求してください。これは発注側の正当な権利です。応じない場合は、契約書の記載を確認の上、専門家への相談を検討してください。
乗り換え前に必ず回収すべきもの（引き継ぎチェックリスト）
ここが本記事の核心です。解約を伝える前に、この一覧をすべて確保してください。解約を伝えた後では、協力が得にくくなるのが実情です。
✅ 権限・アカウント
- Shopifyストアオーナー権限／自社アカウントが保持しているか。制作会社名義なら移管を要求
- 独自ドメインの管理権限／レジストラのログイン情報、DNS設定の管理者
- Google Analytics・Search Consoleの所有権／自社アカウントが「オーナー」になっているか
- 各種アプリの契約名義／制作会社名義で契約しているアプリがないか。あれば自社名義へ変更
- 決済サービスの管理者アカウント／Shopify Payments、その他決済代行の管理権限
✅ データ・ファイル
- 現行テーマファイル一式／Shopify管理画面からダウンロードし、自社で保管
- カスタム実装のソースコード／制作会社のGitリポジトリにある場合は、コピーを受領
- デザインの元データ／Figma、Photoshop、Illustratorの編集可能ファイル
- 画像・動画の元素材／圧縮前の高解像度データ
- 商品・顧客・注文データのエクスポート／Shopifyから出力できるが、切替前の状態を保管しておく
✅ ドキュメント・知識
- カスタマイズ箇所の一覧／標準テーマから何を、なぜ変更したのか
- 導入アプリの一覧と用途／アプリ名、月額費用、何のために入れたか、削除したら何が壊れるか
- 外部システム連携の仕様／連携先、方式、認証情報の管理者、障害時の連絡先
- 運用手順書／商品登録、セール設定、バナー差し替えなどの作業マニュアル
- 過去の障害履歴と対応内容／同じ問題の再発時に、調査時間を大幅に短縮できる
⚠️ 最も揉めるのは「カスタムアプリ」と「デザイン元データ」
カスタムアプリが制作会社のパートナーアカウントで作成されている場合、乗り換え時にそのアプリが使えなくなることがあります。契約時に「カスタムアプリの所有権はどちらか」を確認していないケースが大半で、乗り換え段階で初めて問題化します。該当する場合、新しい会社での作り直しが必要になる可能性を織り込んでください。
デザインの元データも同様です。「納品物はサイトであって、元データは含まない」という契約解釈があり得ます。本来は制作契約時に権利範囲を明記すべき項目ですが、遡って主張するのは難しい。今の会社との契約書を、乗り換えを決める前に必ず読み返してください。
乗り換えの実務手順
順序を守ることが、揉め事を防ぐ最大の要因です。特にSTEP 1とSTEP 2を飛ばして解約を伝えると、回収が困難になります。
契約書の確認と、資産の棚卸し
契約期間、解約予告期間（多くは1〜3か月前）、違約金条項、成果物の権利範囲を確認します。同時に前章のチェックリストで、自社が今どこまで保持しているかを把握します。この段階では制作会社に何も伝えません。
回収できるものを、通常業務の範囲で回収する
テーマファイルのダウンロード、権限設定の確認と修正、アプリ一覧の記録。これらは発注側が自分で実行できる範囲です。「サイトの棚卸しをしたい」という自然な依頼として、ドキュメントの提供を求めるのも有効です。
次のパートナーを決めてから、解約を伝える
空白期間を作らないことが最優先です。次が決まる前に解約すると、障害発生時に対応者が存在しない状態になります。新パートナーには現行サイトの調査期間を確保してもらい、その上で正式契約します。
引き継ぎ期間を設け、三者で情報共有する
理想は現制作会社と新制作会社が直接やり取りできる期間を1〜2週間設けることです。感情的な対立を持ち込まず、「円満に引き継ぎたい」という姿勢を発注側が明確に示すことで、協力を得られる確率は大きく上がります。
権限を切り替え、動作を検証する
旧制作会社のコラボレーター権限を削除し、新会社に付与します。同時に、注文フロー、決済、配送設定、メール送信、外部連携が正常に動作するかを一通り検証します。権限削除でアプリが停止する場合があるため、削除は営業時間内に行ってください。
【独自視点】乗り換えは「相手を変える」のではなく「関係の設計を変える」こと
ここが、乗り換えを繰り返す事業者と、一度で解決する事業者を分ける最大の違いです。
私たちは、乗り換えの相談を受けたとき、必ず「前回どうやって今の会社を選びましたか」と質問します。返ってくる答えの多くは「知人の紹介」「見積もりが安かった」「対応が丁寧そうだった」——つまり、選定基準が明文化されていません。
そして重要なのは、基準を持たずに選んだ結果に不満を持ち、同じく基準を持たずに次を選ぶと、同じ結果になるということです。乗り換えを2回、3回と繰り返している事業者は、例外なくこのループに入っています。
関係の設計を変える3つの打ち手
打ち手①：保守契約の中身を数値で定義する
「月額◯万円で保守」ではなく、「月◯時間まで／軽微修正は◯営業日以内／月次レポート提出」のように定量化します。これだけで「対応が遅い」という主観的不満が、契約上の議論に変わります。
打ち手②：管理権限は必ず自社が握る
ストアオーナー、ドメイン、解析ツールの所有権。この3つを自社が保持していれば、乗り換えはいつでも実行可能になります。「いつでも変えられる」状態そのものが、健全な関係を維持します。
打ち手③：ドキュメント提出を契約に含める
カスタマイズ一覧、アプリ一覧、運用手順書の更新を保守業務に含めます。属人化を制度で防ぐという発想です。担当者が変わっても品質が落ちない仕組みは、契約で作れます。
「ECは戦術ではなく設計で決まる」
ボトルシップが一貫して掲げている考え方です。この思想は、パートナーとの関係にも同じように当てはまります。
制作会社との関係が壊れるのは、多くの場合個人の資質の問題ではなく、関係の設計が存在しないことが原因です。何を、いつまでに、どの品質で提供するのか。権限は誰が持つのか。知識はどこに蓄積されるのか。これらが定義されていなければ、どんなに優秀な担当者がついても、その人が異動した瞬間に関係は崩れます。
逆に言えば、設計さえ正しければ、パートナーは「取り替え可能な状態」で維持できます。これは冷たい話ではありません。取り替え可能な状態を作れているからこそ、相手に依存せず、対等な立場で長期的な関係を築けるのです。乗り換えを検討している今が、この設計を作り直す最良のタイミングです。
自社が保持すべき権限
（ストア・ドメイン・解析）
回収すべき資産
（権限・データ・ドキュメント）
確保すべき
引き継ぎ期間
乗り換えにかかる費用の内訳
乗り換えの費用は「新しい保守契約の月額」だけではありません。実務上は次の4つが発生し、初年度は現状維持よりも総額が上回るのが通常です。この事実を理解した上で判断してください。
| 費用区分 | 内容 | 発生タイミング |
|---|---|---|
| 引き継ぎ調査費 | 現行サイトの実装内容、カスタマイズ箇所、アプリ構成、外部連携の調査と文書化 | 契約直後の1〜2か月に集中 |
| 負債の解消費 | 前任者の実装で問題がある箇所の修正、動かなくなったアプリの代替、放置された不具合の解消 | 調査完了後、随時 |
| 再実装費 | 引き継げなかったカスタムアプリや機能の作り直し | 該当する場合のみ、初期に発生 |
| 社内工数 | 資産の回収、権限の切替、新会社への説明、動作検証。見えにくいが実際に最も重い | 乗り換え前後の3か月 |
とりわけ社内工数は見積書に載らないため、ほぼ確実に過小評価されます。担当者が通常業務と並行して乗り換えを進めると、どちらも中途半端になります。乗り換えを決めたら、その期間は担当者の他業務を意図的に減らしてください。これは制作会社側ではコントロールできない、発注側だけが打てる手です。逆に言えば、担当者の工数を確保できないのであれば、その時点では乗り換えのタイミングではないという判断もあり得ます。
関連する支援メニュー
- ECサイト構築支援｜現行サイトの引き継ぎ調査から、再構築・改修まで対応します。
- ECコンサルティング｜乗り換えの是非の判断、保守契約の設計、選定基準づくりを支援します。
- EC運用代行｜商品登録・受注対応・広告運用まで、運用実務を継続的に巻き取ります。
- 物流支援｜配送設定や在庫連携の引き継ぎ、3PL選定の見直しを行います。
乗り換え後の最初の90日でやるべきこと
乗り換えは契約を切り替えた時点では完了しません。最初の90日で何をするかが、次の乗り換えを防げるかどうかを決めます。ここを放置すると、2年後にまったく同じ不満を抱えることになります。
- 現状調査レポートを提出してもらう（〜30日）新しい制作会社に、現行サイトの実装状況、カスタマイズ箇所、導入アプリ、技術的負債の一覧を文書で提出してもらいます。これが今後の共通言語になります。調査費用は発生しますが、ここをケチると新会社もまた属人的な理解のまま運用を始めることになります。
- 不要なアプリを棚卸しする（〜30日）前任者が導入したまま使われていないアプリは、月額費用を垂れ流しています。調査レポートの「何のために入れたか」欄が空欄のアプリは、削除候補です。ただし削除で何が壊れるかを必ず検証してから実行してください。
- 保守範囲を定量的に定義し直す（〜45日）「月◯時間まで」「軽微修正は◯営業日以内」「緊急障害は◯時間以内に一次応答」。前の会社との関係が壊れた原因の多くはここが曖昧だったことです。同じ失敗を繰り返さないための最重要工程です。
- 依頼のフォーマットを決める（〜45日）発注側の課題も同時に潰します。「何を、なぜ、いつまでに、どうなったら完了か」を書く簡易テンプレートを用意し、依頼はすべてそれで出す。依頼の質が上がると、対応速度は目に見えて変わります。
- 月次レポートの項目を合意する（〜60日）セッション数、CVR、平均注文単価、対応した作業一覧、翌月の提案。数値が共有されていない関係は、必ず「やってくれない」という主観的不満に戻ります。報告の型を決めることが、関係を制度化する第一歩です。
- ドキュメントの更新責任を明記する（〜90日）カスタマイズ一覧、アプリ一覧、運用手順書を保守業務の一部として更新し続けてもらいます。これがあれば、次に担当者が変わっても、あるいは次に会社を変えることになっても、引き継ぎコストは大幅に下がります。
この6項目を90日で完了させておけば、仮に将来もう一度乗り換えることになっても、今回のような苦労は繰り返さずに済みます。乗り換えのコストを二度と払わないために投資する90日だと考えてください。
よくある誤解
誤解①「乗り換えれば対応が速くなる」
新しい会社は現行サイトを知りません。最初の2〜3か月は、むしろ対応が遅くなるのが普通です。調査期間を織り込まずに乗り換えると、「前のほうがマシだった」となります。
誤解②「解約を伝えてから引き継ぎを頼めばいい」
順序が逆です。解約後は協力が得にくくなるのが実情です。回収できるものは、解約を伝える前に通常業務の範囲で確保しておくのが鉄則です。
誤解③「サイトは自社のものだから、全部もらえる」
納品物の範囲は契約次第です。デザイン元データやカスタムアプリの所有権が制作会社側にある契約も存在します。まず契約書を読んでください。
誤解④「安い会社に変えればコストが下がる」
月額は下がっても、引き継ぎ調査費、再実装費、トラブル対応の内部工数を合算すると、初年度はむしろ高くつくのが一般的です。2〜3年の総額で比較してください。
誤解⑤「揉めてもいい、どうせ切るのだから」
感情的な対立は、引き継ぎ品質を直接下げます。ドキュメント提供やコード解説は、契約上の義務でない部分が多い。協力を引き出すほうが、結果的に自社の利益になります。
誤解⑥「不満があるのだから乗り換えるべき」
不満の原因が自社の依頼の出し方にあるケースは珍しくありません。会社を変えても、依頼の質が変わらなければ同じ不満が再発します。まず自社側を点検してください。
乗り換えるべきでないケース
⚠️ 次に該当する場合、乗り換えはおすすめしません
①不満の内容を具体的に説明できない／「なんとなく合わない」だけでは、次の会社を選ぶ基準も作れず、同じ結果になります。
②現制作会社に改善要求を正式に伝えていない／要望を書面で伝え、改善の機会を与えるのが先です。多くのケースは、期待値のすり合わせで解決します。
③大型セールや繁忙期が2か月以内に控えている／引き継ぎ期間中は対応が手薄になります。繁忙期を越えてから着手してください。
④社内に引き継ぎを進められる担当者がいない／乗り換えは発注側にも相応の工数が発生します。担当者不在で始めると、中途半端な状態で止まります。
⑤単に費用を下げたいだけ／それは乗り換えではなく、保守範囲の見直し交渉で解決すべき課題です。現制作会社との再交渉が先決です。
よくある質問（FAQ）
Q1. 解約の何か月前に伝えるべきですか？
契約書に定められた解約予告期間に従いますが、実務的には引き継ぎ期間を含めて2〜3か月前が目安です。予告期間が1か月の契約でも、引き継ぎを丁寧に行いたい場合はそれ以上前に相談するほうが結果的にスムーズです。ただし前述の通り、伝える前に契約書の確認と資産の棚卸しを済ませておいてください。
Q2. 現制作会社が引き継ぎに協力してくれない場合はどうすればいいですか？
まず契約書上、引き継ぎ協力義務が明記されているかを確認します。明記がない場合、法的に強制するのは難しいのが実情です。現実的な対応としては、Shopify管理画面から自社で取得できる情報（テーマファイル、アプリ一覧、設定内容）を最大限自力で回収し、不足分は新しい制作会社に調査してもらう前提で費用を見込みます。この調査費用は数十時間規模になることもあるため、見積もり時に明示的に確認してください。
Q3. 乗り換え時にサイトが止まるリスクはありますか？
正しい手順を踏めば、サイトが停止することはありません。ただしリスクが生じるのは、権限の切り替えとアプリの契約名義変更のタイミングです。制作会社名義で契約されているアプリの契約が解除されると、そのアプリの機能が停止します。権限削除やアプリの名義変更は、必ず営業時間内に、影響範囲を確認した上で段階的に実施してください。
Q4. 新しい制作会社を選ぶとき、何を確認すべきですか？
乗り換え案件では通常の制作案件と確認事項が異なります。最低限、次の4点です。①他社が作ったShopifyサイトの引き継ぎ実績があるか、②引き継ぎ時の調査工数を見積もりに明示しているか、③保守範囲を時間や対応日数で定量的に定義できるか、④ストアオーナー権限を発注側が保持する運用に同意するか。特に④に難色を示す会社は、同じ問題を繰り返す可能性があります。
Q5. 制作会社を変えずに関係を改善する方法はありますか？
あります。多くのケースで有効なのは、保守契約の内容を定量的に再定義することです。「月何時間まで対応」「軽微修正は何営業日以内」「月次レポートの提出」といった具体的な条件を提示し、その上で費用を再交渉します。この提案に前向きに応じる会社であれば、乗り換えるより関係を続けたほうが総コストは低くなります。応じない場合は、乗り換えの判断材料が一つ増えたことになります。
まとめ
この記事の要点
- 制作会社の乗り換えとは、発注先を変える行為ではなく、現制作会社が持つ管理権限・実装知識・運用手順を自社に回収し、新パートナーへ再配布する引き継ぎプロセスである。成否は「回収の完全性」で決まる。
- 検討すべきサインは7つ。中でも「管理権限を渡さない」は例外なく赤信号で、乗り換え以前に権限移管を書面で要求すべき事案。
- 回収すべきものは3種類——権限・アカウント、データ・ファイル、ドキュメント・知識。解約を伝える前に確保するのが鉄則。
- 最も揉めるのはカスタムアプリとデザイン元データ。所有権が制作会社側にある契約も存在するため、乗り換えを決める前に契約書を読み返す。
- 順序が命。契約確認 → 資産回収 → 次のパートナー決定 → 解約通知 → 引き継ぎ期間 → 権限切替。次が決まる前に解約しない。
- 乗り換えは相手を変えることではなく、関係の設計を変えること。保守契約の定量化、権限の自社保持、ドキュメント提出の契約化——この3つで属人化を制度的に防ぐ。
- 乗り換えるべきでないケースもある。不満を言語化できない、改善要求を正式に伝えていない、繁忙期が近い、担当者がいない、単に費用を下げたいだけ——いずれも先にやるべきことがある。
100文字要約：Shopify制作会社の乗り換えとは、管理権限・実装知識・運用手順を自社に回収し新パートナーへ渡す引き継ぎプロセス。解約を伝える前の資産回収と、保守契約の定量化が成否を分ける。
