この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、現行プランからの移行を社内で検討している担当者
読了時間: 約14分
「Shopify Plusにしたほうがいいですか」という質問は、制作会社への相談のなかでもとくに答えが割れるものです。営業の立場からすれば「上げましょう」と言うほうが話は早い。けれど実際に構築を担当していると、上げなくても解決する課題のほうが多いというのが正直なところです。
一方で、上げないまま無理を重ねた結果、アプリと個別改修で継ぎはぎだらけになり、かえって高くついている現場も見かけます。どちらに転ぶかは、規模だけでは決まりません。
この記事では、料金そのものではなく、「どの条件が揃ったときに上位プランの検討が意味を持つのか」という判断軸を整理します。読み終えたときに、自社が「まだ通常プランで足りる」のか「そろそろ検討テーブルに載せる時期」なのかを、社内で説明できる状態になることを目指します。
なお、Shopifyの料金体系・プラン名・提供機能は改定が入るため、この記事では具体的な金額やプラン名の断定はしません。最新の料金と機能の対応は必ずShopifyの公式プランページで確認してください。 ここで扱うのは、変わりにくいほうの話——判断の構造です。
「大きくなったら上げる」で足りるケースが多い理由
上位プランの価値は「機能」より「制約の外し方」にある
上位プランを検討する人の多くは、「Plusにすると何ができるようになるのか」という機能リストの発想で入ってきます。ところが実装側から見ると、上位プランで得られるものの大半は新機能というより「通常プランでかかっている制約が外れること」です。
制約が外れることに価値があるのは、その制約に実際にぶつかっている場合だけです。ぶつかっていない制約が外れても、体感は何も変わりません。ここが「大きくなったら上げればいい」と言える最大の理由になります。
意味がある入り方
- 現行プランで「できない」に実際にぶつかった
- 回避のための手作業が毎月発生している
- アプリと改修の積み上げが月額を圧迫している
意味が薄い入り方
- 機能一覧を見て「あったほうが良さそう」
- 売上規模的にそろそろかと思った
- 同業他社が使っているらしい
左側のどれか一つでも当てはまっているなら検討する価値があります。右側だけなら、まだ時期ではありません。
通常プランでできることは、思っているより多い
ECの相談で「これはPlusじゃないと無理ですよね」と言われるものの多くは、通常プランのまま実装できます。判断を曇らせている典型例を挙げます。
| よくある思い込み | 実際のところ |
|---|---|
| 独自のカート挙動を作りたいからPlus | テーマ側のJavaScript実装で対応できる範囲が広い |
| 会員ランクごとに表示を変えたいからPlus | 顧客タグとLiquidの条件分岐で組める |
| デザインを自由にしたいからPlus | テーマのカスタマイズ自由度はプランで変わらない |
| ブログ・お知らせを充実させたいからPlus | 通常プランのブログ機能で足りる場面が多い |
| 決済まわりを細かく作り込みたいからPlus | 決済手段の追加・配送条件の設計は通常プランの範囲 |
とくにテーマの見た目とフロント側の作り込みは、プランによる差がほぼありません。「デザインの自由度」を理由に上位プランを検討しているなら、その理由は成立しないと考えてよいです。
配送条件の設計も同様です。地域ごとの送料、購入金額による送料無料ライン、大型商品だけ別料金、冷蔵便と常温便の分離——このあたりは配送プロファイルと条件の組み合わせで、通常プランのまま相当なところまで行けます。「配送が複雑だからPlus」と言われた案件のほとんどは、設定の詰め方の問題でした。
プラン変更は「後戻りできない決断」ではない
上位プランへの移行を重く考えすぎている担当者は多いのですが、プランの上げ下げ自体は、サイトを作り直す話ではありません。テーマも商品データも顧客データもそのまま残ります。
重くなるのは、上位プラン前提でしか動かない仕組みを組み込んだあとです。上位プラン固有の機能を使って業務フローを作り込むと、下げたときにその部分だけ動かなくなります。つまり、
- プランを上げること自体のリスクは小さい
- 上位プラン固有の機能に業務を依存させることのリスクは大きい
この2つを分けて考えると、判断がかなり楽になります。上げるかどうかで悩む時間より、「上げたときに何に依存するつもりか」を先に決めておくほうが実務的です。
規模・要件・体制——見るべき3つの軸
判断材料を3つの軸に分けます。売上規模だけで決めようとすると、ほぼ必ず判断を誤ります。
規模
- 取引件数・同時アクセスの山
- 商品点数とバリエーション数
- 店舗数・展開している国と通貨
要件
- チェックアウトをどこまで触る必要があるか
- 基幹システムとの連携の深さ
- BtoB・卸の取引条件
体制
- 管理画面を日常的に触る人数
- 権限を分けたい部署の数
- 運用を外注しているか内製か
このうち、「要件」と「体制」のほうが判断への影響が大きいというのが実感です。規模は結果としてついてくる指標で、それ単体では上位プランを正当化しません。
軸1：規模——件数ではなく「山」を見る
規模で見るべきは月商や年商ではなく、ピーク時に何が起きるかです。
- テレビ・SNSでの露出、大型セール、抽選販売のように短時間にアクセスと注文が集中する運用があるか
- 商品点数とバリエーションの掛け算が、通常プランの上限に近づいていないか
- 複数の国・通貨・言語で展開する予定があり、それぞれで運用を分けたいか
平常時が安定していても、年に数回の山が読めているなら、その山で何が起きるかを先に確かめるべきです。確かめ方は単純で、前回の山のアクセスログと注文の時間分布を見ます。注文が何分間に何件入ったか、その間に管理画面の動作が重くならなかったか、在庫の引き当てがずれなかったか。この3点に問題が出ていないなら、次の山も同じ規模なら耐えます。
逆に、山のない安定した通販であれば、月商が伸びただけでは検討の理由になりません。
軸2：要件——「チェックアウトを触りたいか」が最大の分岐
実装の現場で、上位プランかどうかが最も明確に効いてくるのがチェックアウト（購入手続き画面）です。
チェックアウトは、Shopifyが決済の安全性と成功率を守るためにあえて触らせない領域です。通常プランではここへの介入が限定的で、上位プランになると介入できる幅が広がります。
したがって、次のような要件が業務上どうしても外せないなら、上位プランが議論のテーブルに乗ります。
- チェックアウト画面に独自の入力項目や確認ステップを追加する必要がある（法令・業界規制・受注業務の都合など）
- 注文内容に応じた複雑な割引ロジックを、割引コードの組み合わせではなくルールとして走らせたい
- 卸・BtoBの取引条件（取引先ごとの価格、掛け率、支払い条件、承認フロー）を標準機能として持たせたい
- 基幹システムやWMS（倉庫管理システム）と、注文・在庫をリアルタイムに近い粒度で双方向連携させたい
ここで大事なのは、「あったら便利」と「無いと業務が回らない」を分けることです。チェックアウトに項目を足したい理由が「アンケートを取りたい」程度なら、注文後のサンクスページやメール、別フォームで代替できます。「法令上、注文時点で取得していないと出荷できない情報がある」なら、これは代替できません。
判断の分かれ目は、その情報を取り損ねたときに何が起きるかです。取り損ねてもあとから電話やメールで聞けるなら、チェックアウトに置かなくていい。取り損ねると出荷そのものが止まる、あるいは法令違反になるなら、チェックアウトに置くしかありません。この一問で、上位プラン検討の理由の多くは消えます。
注文後のコミュニケーション設計で代替できる範囲は意外と広く、確認メールの作り込みはその代表例です。
軸3：体制——管理画面を触る人数と権限の細かさ
見落とされがちですが、運用体制は上位プランの検討理由として実は強い軸です。
- 管理画面にログインするスタッフが増え、「誰がどこまで触れるか」を分けたい
- 部署ごと・拠点ごとに担当範囲を切り分けたい
- 注文処理・商品登録・マーケティングで担当が分かれており、誤操作のリスクが無視できない
スタッフが2〜3人なら、権限を細かく分けるより「触らないでほしい場所を口頭で共有する」ほうが早い。しかし10人を超えたあたりから、権限設計は事故防止のインフラになります。ここは規模の話に見えて、実は体制の話です。
事故の中身も具体的です。公開前の商品が誤って公開される、セール価格が本番に出たまま戻らない、テーマを編集できる権限が全員にあって誰がいつ何を変えたか追えない——どれも「悪意のない操作」で起きます。人数が増えるほど、誰か一人が気をつけるという運用は成立しなくなります。
逆に、売上が大きくても運用しているのが1〜2人なら、権限の細分化に価値はありません。この場合、上位プランを検討する理由は要件側にしかないはずです。
早めに上げるべき条件——「後から」が高くつくパターン
「大きくなったら上げる」が基本線ではあるものの、先に上げておいたほうが総コストが下がるケースは確かに存在します。
条件1：構築時点でチェックアウト要件が確定している
すでに述べたとおり、チェックアウトは通常プランと上位プランで作り方が根本的に変わります。構築が終わったあとにチェックアウト要件が出てくると、設計をやり直すことになります。
とくに、注文データの持ち方・必須項目の扱い・後続の業務フローが絡む要件は、あとから足すと周辺全部に影響します。要件定義の段階で「チェックアウトに触る必要があるか」を確定させておくことは、プランの話とは別に、発注側がやっておくべき仕事です。
条件2：多店舗・多通貨を最初から計画している
国や地域ごとにストアを分ける計画があるなら、1号店を作る時点で分け方を決めておく必要があります。
「まず国内で作って、うまくいったら海外」という進め方自体は健全です。ただしその場合でも、海外展開時にストアを分けるのか1ストアで多通貨対応するのかを先に決めておかないと、商品データの持ち方・URLの構造・在庫の見せ方を後から作り直すことになります。プランを上げるかどうかより、設計方針を先に決めることのほうが効きます。
とくに商品コード（SKU）の付け方は、あとから直すのが難しい部分です。国ごとに別ストアを立てる前提なら、同じ商品が複数ストアに存在しても在庫と実績を突き合わせられる採番にしておく。1ストアで多通貨をやる前提なら、地域別の価格をどこで持つかを決めておく。どちらを選ぶかより、決めないまま進めることのほうが高くつきます。
条件3：アプリと個別改修の積み上げが、上位プラン相当に近づいている
これが実務でいちばん多い「気づいたら」パターンです。
通常プランのまま、足りない機能をアプリで補い、アプリで足りないところをテーマ改修で埋める。一つひとつの判断は正しいのに、2年経つと月額アプリ費用が積み上がり、テーマは改修が重なって触りにくくなり、表示速度も落ちているという状態になります。
この図の「判断のとき」に来たら、上位プランへの移行は選択肢の一つになります。ただし上位プランに上げればアプリが減るわけではない点には注意が必要です。順番としては、まずアプリの棚卸しをして、それでも残る要件が上位プランでしか解けないかを見ます。
アプリの積み上がりは、上位プランの話と切り離して定期的に点検すべきテーマです。
アプリで足りる線と、テーマ改修が必要な線
上位プランの判断を正しくするには、その手前にある「アプリで足りるのか、テーマを触るのか」の線引きを理解しておく必要があります。ここが曖昧なまま上位プランの話をすると、解決策の順番を間違えます。
アプリで足りる条件
次の3つが揃うなら、アプリで解決するのが妥当です。
- やりたいことが、その分野で一般的な機能である（レビュー、サブスクリプション、在庫通知、多言語など）
- 見た目の細かい調整にこだわらない、もしくはアプリ側の設定で許容範囲に収まる
- サイトの他の部分と密に絡まない——単独の機能として切り出せる
逆に、この3つのどれかが崩れると、アプリは途端に窮屈になります。「アプリを入れたけどデザインが合わないので、結局CSSで上書きし続けている」という状態は、本来テーマ改修で作るべきものをアプリで済ませた結果です。
テーマ改修に倒すべき条件
| 状況 | 判断 |
|---|---|
| サイト全体の体験に関わる（カート挙動、絞り込み、回遊導線） | テーマ改修 |
| 表示速度が売上に直結する規模になっている | テーマ改修 |
| 機能としては単純だが、デザインを完全に合わせたい | テーマ改修 |
| 標準機能に近く、単独で完結する | アプリ |
| 立ち上げ初期で、まず動かして検証したい | アプリ |
立ち上げ初期は迷ったらアプリでかまいません。検証前に作り込むのは投資の順番として不利です。ただし、その機能が事業の柱になったと分かった時点で、テーマ側へ移す判断を一度してください。
シンプルな機能なら、アプリを入れずに実装できるものも多くあります。
アプリを選ぶときに見る箇所
アプリストアの評価点だけで選ぶと、あとで困ります。実際に見るべきなのは次の4点です。
- 最終更新日——1年以上更新が止まっているアプリは、Shopify側の仕様変更に追随できていない可能性がある
- 対応言語——管理画面と店頭表示の両方が日本語に対応しているか。管理画面だけ日本語で、お客様に見える文言が英語のままというケースは珍しくない
- サポート体制——問い合わせの手段と、返答が来る時間帯。海外開発のアプリは時差で1往復に1日かかる
- 自社テーマとの相性——テーマを改修している場合、アプリが想定する標準的なHTML構造とズレて動かないことがある
導入前に確認しておくと後が楽なのは、試用期間の有無と、試用中に本番データを入れてよいかです。試用のあいだに実際の商品データと注文フローで一度通しておかないと、本番で初めて「日本語の住所表記に対応していない」「軽減税率の表示が崩れる」といった問題が出ます。
なお、料金については無料枠のあるものから月額数十ドル規模のものまで幅が広く、しかも改定が入ります。最新の料金は必ず各アプリのページで確認してください。
判断基準をもう少し体系立てて整理した記事もあります。
導入後に効いてくる4つの論点
プランの選択は導入時の判断ですが、影響が出るのは運用に入ってからです。発注前に必ず社内で共有しておきたい論点を4つ挙げます。
論点1：月額の積み上がりは、プラン費用より読みにくい
プラン費用は固定なので予算が立てやすい。読みにくいのはアプリの月額と、従量課金部分です。
- アプリは1本ずつ契約するので、稟議を通さず追加されていくことがある
- 多くのアプリは利用規模に応じて料金帯が上がる——注文件数、送信通数、登録商品数など
- 売上が伸びるとアプリ費用も同時に伸びる構造になっている
つまり、売上が2倍になったときの固定費が2倍にならないかを確認しておく必要があります。プランを上げるかどうかの検討は、この総額の見通しとセットで行うべきです。年間の維持費という視点で整理すると、社内の説明もしやすくなります。
論点2：表示速度はアプリの本数でじわじわ落ちる
アプリの多くは、ストアの全ページに自分のJavaScriptを読み込ませます。1本なら誤差でも、7本8本と重なると体感できるレベルで遅くなります。
厄介なのは、遅くなったことに気づきにくい点です。毎日見ていると徐々の変化は分からない。気づくのは、広告を出したときにコンバージョン率が思ったより低いときや、お客様から指摘を受けたときです。
対策は単純で、アプリを追加したら追加前後で速度を測る。これを習慣にするだけで、判断材料が残ります。測るのはトップページだけでなく、商品ページとカートも含めてください。アプリによって効くページが違うので、トップだけ見ていると影響を見逃します。
論点3：解約したときに何が残るか
アプリを解約すると、そのアプリが提供していた機能は当然止まります。問題はテーマに残った痕跡です。
- テーマのコードに埋め込まれたタグやスニペットが残り、エラーを出し続ける
- アプリが管理していたデータ（レビュー、会員ポイント、翻訳文など）が取り出せない、または移行できない
- アプリ用に作られたメタフィールドが残り、管理画面が散らかる
契約前に「解約したらデータはエクスポートできるか」を確認する——これだけで後年のトラブルが減ります。とくにレビューと会員データは、貯まるほど移せなくなる資産です。
論点4：管理画面を触る人の負担
アプリを1本増やすと、運用担当者が覚える管理画面が1つ増えます。設定の場所も、用語も、更新の仕方もバラバラです。
担当者が変わったときに、この分散が効いてきます。引き継ぎ資料が追いつかず、「誰も設定を変えられないアプリ」が残る。これは機能の問題ではなく、運用設計の問題です。
判断基準としては、その機能を誰が、どのくらいの頻度で触るのかを先に決めること。月1回も触らない設定のためにアプリを増やすなら、テーマ側に固定値で組み込むほうが運用は軽くなります。
Shopifyの使い道を広げてから判断する
上位プランを検討する前に、一度考えてほしいことがあります。現行プランのShopifyを、まだ使い切っていない可能性です。
ShopifyをECの機能としてだけ見ていると、「足りない」の判定が早く出ます。しかし実際には、会社案内・お知らせ・採用情報といったコーポレートサイトの役割まで1つのShopifyに寄せてしまう設計もあり、その場合はサイトを2つ維持するコストと更新の手間がまるごと消えます。
判断のための7つの質問
最後に、社内で使えるチェックリストにまとめます。「はい」が3つ以上なら検討のテーブルに載せる、1つ以下なら現行プランで進めてよい、という目安で使ってください。
| # | 質問 | 判定 |
|---|---|---|
| 1 | チェックアウト画面に、業務上どうしても必要な変更があるか | はい／いいえ |
| 2 | 短時間にアクセスと注文が集中する運用が、年に複数回あるか | はい／いいえ |
| 3 | 複数の国・通貨・言語で、それぞれ別の運用をする計画があるか | はい／いいえ |
| 4 | 管理画面を日常的に触る人が10人を超え、権限を分ける必要があるか | はい／いいえ |
| 5 | BtoB・卸の取引条件を、標準機能として持たせる必要があるか | はい／いいえ |
| 6 | 基幹システムと、注文・在庫を細かい粒度で双方向連携させる必要があるか | はい／いいえ |
| 7 | アプリと個別改修の積み上げが、毎年増え続けて読めなくなっているか | はい／いいえ |
7番だけが「はい」の場合は、上位プランではなくアプリの棚卸しが先です。ここを間違えると、プランを上げてもアプリ費用はそのまま残ります。
2つが「はい」で迷う場合は、その2つが同じ軸に寄っているかを見てください。1番と5番のように要件側で揃っているなら検討の価値がありますが、2番と4番のように軸がばらけているなら、それぞれを個別に解いたほうが安く済むことが多いです。
また、このチェックリストは制作会社に見せる資料としても機能します。相見積もりを取る際、各社に同じ条件で答えてもらうと、提案の質の差が見えます。要件を揃えて比較する型については、こちらが参考になります。
費用の目安を先に知りたい方へ
ページ数や必要な機能を選ぶだけで概算を確認できる費用シミュレーターを用意しています。見積書を読み解く前の物差しとしてお使いください。
よくある質問
Shopify Plusは年商いくらから検討すべきですか
年商の数字で線を引くことはおすすめしません。判断を決めるのは売上の大きさではなく、チェックアウトへの介入が必要か、運用体制で権限を分ける必要があるか、基幹システムとの連携の深さがどの程度かという要件側の条件です。年商が大きくても、運用が1〜2人で標準機能の範囲に収まっているなら通常プランで足ります。
途中でプランを上げるとサイトを作り直すことになりますか
プランを上げること自体ではテーマも商品データも顧客データも失われません。作り直しが発生するのは、チェックアウトまわりの要件が後から出てきた場合です。この部分だけは通常プランと上位プランで実装方法が根本的に変わるため、要件定義の段階で確定させておくのが安全です。
アプリをたくさん入れているのですが、上位プランに上げれば減らせますか
上位プランに上げてもアプリが自動的に不要になるわけではありません。順番としては、まず入れているアプリを棚卸しして、使っていないもの・重複しているものを解約します。そのうえで残った要件が上位プランでしか解けないかを確認してください。棚卸しを飛ばすと、プラン費用とアプリ費用の両方を払い続けることになります。
Shopifyの料金プランはどこで確認すればいいですか
Shopify公式のプランページが唯一の正確な情報源です。プラン名・料金・機能の対応関係は改定されるため、ブログ記事やまとめサイトの情報で判断しないでください。制作会社に相談する場合も、見積もりの前提としてどのプランで試算しているかを明記してもらうと、比較がしやすくなります。
チェックアウトに独自の項目を追加したいのですが、通常プランでは無理ですか
通常プランでもできる範囲はありますが、自由度は限定されます。追加したい項目が「注文時点で必ず取得しなければならない情報」なのか「あったら便利な情報」なのかで判断が分かれます。後者であれば、注文後のサンクスページ・確認メール・別フォームでの取得に置き換えられることが多く、その場合はプランを上げる理由になりません。
まとめ
Shopify Plusの判断で本当に大事なのは、機能一覧の比較ではありません。
- 上位プランの価値は「制約が外れること」にある。ぶつかっていない制約が外れても体感は変わらない
- 規模より、要件と体制のほうが判断への影響が大きい。年商では線を引けない
- 最大の分岐はチェックアウト。ここだけは後から要件が出ると設計をやり直すことになる
- プランを上げること自体のリスクは小さく、上位プラン固有の機能に業務を依存させることのリスクは大きい
- アプリの積み上がりが理由なら、まず棚卸し。プランを上げても費用は残る
「大きくなったら上げる」は逃げの答えではなく、Shopifyの設計思想に合った進め方です。プランは後から変えられますが、チェックアウト要件と多店舗の設計方針だけは先に決めておく。この2点さえ押さえておけば、通常プランで始めて困ることはほとんどありません。
そして、料金・プラン名・機能の対応は変わります。この記事の判断軸を持ったうえで、最新の情報はShopifyの公式プランページで確認してください。
