Shopifyアプリは何個から多すぎ？ — 15項目のセルフチェックと、段階別にやること

最終更新: 2026-07-27 ／ 運営: Stailor株式会社（Stailor inc.）

アプリの一覧を開いて「思ったより多いな」と感じたことがあるなら、次に出てくる問いはたいてい「これは多すぎるのか、こんなものなのか」でしょう。ところが、この問いに本数で答えようとすると必ず行き詰まります。同じ8本でも、費用を即答できて手作業が発生していない会社と、毎月の請求額が読めずCSVを行き来している会社とでは、抱えている問題がまるで違うからです。

測るべきは本数ではなく、その本数が生んでいる摩擦。摩擦は費用・工数・データ分断・属人化の4方向に出ます。

なぜ本数では測れないのか

アプリ1本あたりの負荷は、その1本が他とどれだけ関わるかで決まります。レビューを集めて商品ページに出すだけのアプリは、他のどのデータとも突き合わせる必要がないので、10本あっても摩擦をほとんど生みません。一方で「顧客の行動を見て、在庫を見て、配信する」タイプの施策は、アプリが2本に分かれているだけで手作業が発生します。

だから「多いか」ではなく、「またいでいるか」を見ます。またぐ回数が増えるほど、費用は読めなくなり、手作業は増え、データは分断し、その全部を頭に入れている担当者に運用が閉じていきます。この4つが、そのまま以下のチェックの4カテゴリです。

15項目のセルフチェック

各項目、当てはまれば1点。正式な診断ではなく、現状を言語化するための道具として使ってください。

A. 費用（4項目）

• 契約中のアプリの月額合計を、資料を見ずに即答できない
• 直近1年で使っていないのに契約が残っているアプリを見つけたことがある
• アプリの請求に配信量や件数に応じた従量課金が含まれており、月によって金額が動く
• 同じような機能を持つアプリを2本以上契約している（メール配信とポップアップが別、など）

B. 工数（4項目）

• アプリ間のデータをつなぐために、CSVの書き出し・転記・貼り付けを定期的にしている
• 月次のレポートを作るために、複数の管理画面から数字を集めて表計算にまとめている
• 1つの施策を打つのに、2つ以上の管理画面を行き来する
• 「やったほうがいいと分かっているが、手が回らず放置している施策」が3つ以上ある

C. データの分断（4項目）

• 「この顧客がいつ何を買い、何を見て、どのメールを開いたか」を1画面で追えない
• 在庫の変化（再入荷・品切れ）を顧客への配信に自動で連動させられていない
• セグメント（優良顧客・休眠・カゴ落ち）の定義がアプリごとにバラバラ、または片方にしかない
• 施策の効果を測るとき、どのアプリの数字を正とするかで迷うことがある

D. 属人化（3項目）

• EC運用の実務が、実質1〜2名に集中している
• その担当者が1か月不在になると、止まる施策がある
• 「なぜこの設定にしたのか」の理由が記録に残っておらず、担当者の記憶にしかない

点数の読み方

合計点そのものより、どのカテゴリに偏っているかを見てください。

ひとつ補足を。Dのカテゴリだけが高い場合、アプリの本数を減らしても解決しません。 属人化は「アプリが多いこと」ではなく「判断の理由が残っていないこと」から生まれるので、統合ではなく記録の設計が先です。逆にAだけが高いなら、解約するだけで大半が片づきます。

段階別に、先にやること

段階0 — 動かない

摩擦が出ていないのに構造を変えるのは、コストだけがかかります。四半期に一度、アプリ一覧と請求額を眺める習慣だけ作っておけば十分です。

段階1 — 棚卸しと解約

やることは3つ。①契約中のアプリを全部書き出し、月額と直近3か月の使用有無を並べる ②使っていないものを解約する ③機能が重複しているものを1本に寄せる。ここで効果が出るなら、次の段階に進む必要はありません。「基盤に統合すべきか」を考えるのは、これをやってからで遅くないです。

段階2 — 配信レイヤーの統合を検討

メール・SMS・ポップアップ・セグメントが複数のアプリに分かれているなら、これらを1つにまとめる統合スイート（Klaviyo、Omnisendなど）が現実的な選択肢になります。管理画面の行き来は実際に減ります。ただし、まとまるのは配信チャネルの層まで。レビュー・再入荷・在庫・ポイントなどは残ります。判断軸の詳細は「また1つアプリを増やす前に」で7つのポイントに分解しています。

段階3 — 運用の構造を見直す

CとDが同時に高いということは、「データが分断していて、その隙間を人が記憶と手作業で埋めている」状態です。ここはアプリの入れ替えでは動きません。トリガー（顧客行動・在庫変化）×条件×アクションという共通の仕組みに施策を寄せ、判断の理由まで記録に残す設計に変える段階です。手間と時間はかかります。施策を止めずにアプリをまとめる5つの手順に手順とリスクをまとめています。

このチェックが当てにならないケース

公平のために、上の判定を信用しないほうがよい条件を挙げます。

• Shopifyの運用を始めて半年未満。データも運用パターンも溜まっていない段階では、摩擦が出ていないのか、まだ出ていないだけなのかを区別できません。
• 季節変動が極端に大きい商材。繁忙期の実感で答えると点数が跳ね上がります。年間の平均的な状態で答えてください。
• 直近でアプリを大きく入れ替えた。移行直後の混乱を構造問題と読み違えやすい時期です。3か月ほど置いてから測り直すほうが正確です。
• EC以外の業務と兼務している担当者が答える場合。Bの工数項目が、EC由来かどうか切り分けられません。

点数が高いこと自体は問題ではありません。問題は、高いのに気づいていないことと、低いのに構造を変えようとすることの両方です。

よくある質問

まとめ

• 乱立は本数では測れない。費用・工数・データ分断・属人化の4カテゴリ15項目で、摩擦の出方を見る。
• 合計点より偏りを読む。Aだけなら解約で片づき、Dだけなら統合しても解決しない。
• 段階1で止まるのが最適な会社は多い。順番は棚卸し → 配信の統合 → 構造の見直し。飛ばさないほうが安く済む。

関連記事

• 原因を知りたい方へ：Shopifyアプリ、気づけば10個超え — 乱立が起きる構造と、Shopify Flowとの役割の違い。
• 選択肢を比べたい方へ：また1つアプリを増やす前に — 足す・まとめる・一つにする、3つの道を7つのポイントで整理。
• 金額に換算したい方へ：アプリの月額だけ見ていませんか — 手作業の時間と逃した売上まで計算する方法。
• 自社が対象か確かめたい方へ：うちはまだ早い？ — 向く会社・向かない会社 — 月商・担当・データで判定。

本記事はEC運用の一般的な考え方を解説するもので、特定の成果を保証するものではありません。掲載のセルフチェックは簡易的な整理のための目安であり、正式な診断ではありません。「Shopify」および「Shopify Flow」はShopify Inc.の商標・製品です。本サービスはShopify Inc.が提供・保証するものではありません。