この記事でわかること
この記事の目次Contents閉じる開く
Shopify App Storeでアプリを比べていると、一部のアプリに「Built for Shopify」という青いバッジが付いています。検索結果や各カテゴリーのページには、このバッジが付いたアプリだけに絞り込むフィルターも用意されています。
同じような機能のアプリが並んでいるとき、バッジがあるほうを選ぶ。多くの人がそうしていますし、Shopifyもそれを推奨しています。
ただ、このバッジが実際に何を審査していて、何を審査していないのかを知らないまま使うと、選定を誤ります。 認定要件は公開されていて、読むと相当に具体的です。同時に、そこに書かれていない項目もはっきりしています。
この記事では、shopify.devの認定要件とShopifyヘルプセンターの記載をもとに、バッジの中身を分解し、アプリ比較でどこまで判断材料にしてよいかを整理します。調査日は2026年8月31日です。
先に結論
バッジが保証しているのは、パフォーマンス、デザイン、統合方式の3領域です。 いずれもShopify管理画面とストアフロントでの「動き方」に関する基準で、数値も公開されています。
バッジが保証していないのは、料金、サポート品質、日本語対応、機能の充実度、そして事業の継続性です。 認定要件にこれらの項目は含まれていません。
バッジがないことは、品質が低いことを意味しません。 認定には有料プランのアクティブストアからの純インストール50件とレビュー5件という下限があり、新しいアプリやニッチな用途のアプリは、品質と無関係に構造的に取得できません。
一次フィルターとしては優秀で、最終判断には足りません。 候補を絞る段階では使い、最後の1本を決める段階では別の基準を足す。これが実用的な使い方です。
バッジが審査している3領域
Shopifyヘルプセンターは、認定要件を次の3つに整理しています。
パフォーマンス。 アプリがストアフロントの速度を10パフォーマンスポイントを超えて低下させてはいけない、という基準です。ストアの表示速度と検索順位を守るための項目とされています。
デザイン。 Shopifyのデザイン標準に従い、管理画面のなかで一貫した体験を提供すること。
統合。 Shopifyの最新の技術標準を使い、管理画面と主要機能に完全に対応していること。
これだけ読むと抽象的ですが、shopify.devの要件ページには実際の合否基準が数値付きで書かれています。ここから先が本題です。
実際の数値基準
前提条件
認定に進む前提として、まずApp Storeの配布要件を継続的に満たしていること、そしてパートナープログラム規約とShopify API利用規約に違反がないことが求められます。過去の違反は、解消したあとも重大性と頻度によっては一定期間バッジに影響します。
そのうえで、有料プランのアクティブストアからの純インストールが50件以上、レビューが5件以上、そしてApp Store上の直近評価が一定のしきい値以上であることが必要です。
管理画面のパフォーマンス
ここが具体的です。Shopifyは管理画面内でのアプリの表示性能をWeb Vitalsで計測しており、ページ読み込みの75パーセンタイルで次の基準を満たす必要があります。
| 指標 | 基準 | 評価の条件 |
|---|---|---|
| LCP（最大コンテンツの描画） | 2.5秒以下 | 直近28日で100回以上の計測 |
| CLS（レイアウトシフト） | 0.1以下 | 直近28日で100回以上の計測 |
| INP（操作への応答） | 200ミリ秒以下 | 直近28日で100回以上の計測 |
計測を成立させるには、アプリが最新版のApp Bridgeを使っている必要があります。
ストアフロントとチェックアウトのパフォーマンス
ストアフロント側はLighthouseのパフォーマンススコアを10点を超えて下げないこと。
配送料金をリアルタイム計算するキャリアサービス系のアプリには、追加の基準があります。直近28日で1,000回以上のリクエストがあることを前提に、95パーセンタイルで500ミリ秒以内に応答し、99.9%のリクエストに正常応答することが求められます。
統合方式
ここは今後のアプリ選定で効いてくる部分です。
アプリは最新版のApp Bridgeを使ってShopify管理画面に埋め込まれ、主要なワークフローを管理画面のなかで完結できる必要があります。外部サイトへ飛ばさないと使えない構成は、原則として認められません。インストール後に別途サインアップを求めることも、原則不可です。
そして、オンラインストアで使うアプリは、テーマアプリ拡張で要素を作ることが要件になっています。 テーマのコードを書き換えないため、アンインストール時にブロックが自動的に完全に削除されます。
さらに、Asset APIを使ってテーマファイルを作成・変更・削除してはいけません。 例外は3つだけです。テーマのカスタマイズ体験そのものを提供するページビルダーアプリ、テーマファイルをバックアップして復元するアプリ、そしてSEO・コンテンツロック・開発者向けツールを主機能とするアプリ。読み取りのみであれば制限されません。認定申請時には、Asset APIの利用状況が監査されます。
この要件は、2027年3月1日のスクリプトタグ全面停止と地続きです。バッジのあるアプリは、この期限で壊れにくいという読み方ができます。
デザインとダークパターン
デザイン要件はPolarisに沿った見た目の話だけではありません。**「誤解させない、圧力をかけない、圧倒しない」**という項目が明文化されています。
具体的な不合格理由として挙げられているものを抜き出すと、実務的な意味が見えてきます。
「Proプランにアップグレードすれば売上が18%増えます」のように成果を約束する表現は不可。無料トライアルのカウントダウンタイマーでアップグレードを急かすのは不可。5つ星レビューと引き換えに機能を提供するのも不可。「いいえ、売上が少ないほうがいいです」のように罪悪感を持たせるボタンラベルも不可。
そして、プランで制限されている機能は、視覚的にも機能的にも無効化し、どのプランで使えるかを明示する必要があります。 Shopify Plus専用の機能は、非Plusストアには表示してはいけません。フォームを送信してから「この機能は上位プランです」と分かる作りは、明確に不合格理由です。
App Storeのアプリを試して、上位プランへの導線ばかりが目に入る、という経験がある方は多いと思います。バッジは、この種のストレスが一定水準以下であることを示しています。
カテゴリー別の追加要件
一部のカテゴリーには固有の要件があります。
広告・アフィリエイト・分析アプリは、Webピクセル拡張を使ってShopifyのイベントを購読する必要があります。スクリプトタグの使用や、マーチャントにJavaScriptをコピーさせる方式は禁止です。広告アプリはさらに、Shopify管理画面で定義したセグメントをそのまま広告のターゲティングに使えることが求められます。
割引アプリは、Shopify FunctionsのDiscount Functionsか標準の割引APIを使う必要があります。カスタム割引のためにドラフト注文を作る方式は禁止されています。
ここからが本題：バッジが保証していないこと
要件を通して読むと、そこにないものがはっきりします。アプリ選定で誤解が生まれるのは、たいていこの領域です。
料金は審査対象外です。 高いか安いか、値上げ履歴があるか、従量課金の設計が妥当か。認定要件に一切登場しません。バッジ付きの月額299ドルのアプリと、バッジなしの月額9ドルのアプリがあったとき、バッジは価格の妥当性について何も語っていません。
サポート品質も審査対象外です。 返信までの時間、対応の丁寧さ、日本時間での対応可否。いずれも要件にありません。
日本語対応は審査されません。 管理画面のUIが日本語化されているか、日本語で問い合わせられるか、ドキュメントが日本語で読めるか。これらは認定と無関係です。日本のストアにとっては、実務上いちばん効く条件がバッジの外側にあります。
機能の充実度は審査対象外です。 バッジは「よくできている」ことを示しますが、「機能が多い」ことは示しません。むしろデザイン要件は、情報を詰め込みすぎないことを求めています。機能比較はバッジと別に行う必要があります。
事業の継続性は保証されません。 開発元が来年もサービスを続けるか、買収されて料金体系が変わらないか。認定はアプリの品質を見るものであって、会社の財務を見るものではありません。
そして、自分のストアでの速度影響は保証されていません。 ここは誤解が多いところなので、次の節で分けて書きます。
「Lighthouse10点」の読み方
パフォーマンス要件は「ストアフロントのLighthouseパフォーマンススコアを10点を超えて下げないこと」です。
これは**「速度に影響しない」ではなく、「10点までは下げてよい」**という基準です。
バッジ付きのアプリを5本入れれば、理屈のうえでは最大50点分の余地があることになります。実際にそこまで落ちることは稀ですが、バッジは1本あたりの上限を定めているだけで、積み上げの結果については何も保証していません。
アプリを追加したあとにストアの速度を実測する作業は、バッジの有無にかかわらず必要です。Shopify管理画面のオンラインストア速度レポート、あるいはPageSpeed Insightsで、導入前後を比較しておくことをおすすめします。
バッジがないアプリをどう扱うか
もうひとつ、選定で誤りやすい点があります。
認定には有料プランのアクティブストアからの純インストール50件以上、レビュー5件以上という下限があります。これは品質基準ではなく、規模の基準です。
つまり、次のようなアプリは品質と無関係にバッジを取れません。リリースしたばかりの新しいアプリ。日本市場だけを対象にした、そもそも母数の小さいアプリ。特定業種向けのニッチなアプリ。無料アプリしか提供しておらず、有料プランのストアでのインストールが伸びないアプリ。
Web Vitalsの評価にも「直近28日で100回以上の計測」という条件があり、利用が少ないアプリはそもそも評価されません。
日本語対応や国内の配送・帳票・決済に特化したアプリを探している場合、この構造的なバイアスは無視できません。バッジのフィルターだけで絞り込むと、日本のストアにとって最適なアプリが候補から消えることがあります。
実務での使い方
以上を踏まえて、アプリ比較での現実的な手順をまとめます。
候補を10本から3本に絞る段階では、バッジを使います。 同じカテゴリーで機能が近いアプリが並んでいるなら、バッジ付きを優先するのは合理的です。管理画面での操作感、アンインストール時の後始末、ダークパターンの少なさについて、一定の水準が担保されます。
そのうえで、バッジの外側を自分で確認します。 確認すべきは次の5点です。
料金体系と、自分のストアの規模で実際にいくらになるか。日本語UIと日本語サポートの有無（この2つは別物なので分けて確認します）。直近3か月の低評価レビューに何が書かれているか。必要な機能が、自分が払うつもりのプランに含まれているか。そして、アプリをアンインストールしたときにデータをどうエクスポートできるか。
最後に、導入後の速度を実測します。 バッジは1本あたりの上限を示すだけです。
バッジのないアプリを検討する場合は、要件のうち何を満たしていないかを推測します。 単に新しいだけなのか、規模が小さいだけなのか。それとも、テーマのコードを直接書き換えるような統合方式を採っているのか。後者は、今後のShopifyの仕様変更で壊れるリスクを抱えます。App Storeのリスティングに「テーマのコードを編集する」といった手順が書かれていないかは、確認する価値があります。
まとめ
Built for Shopifyは、パフォーマンス、デザイン、統合方式について、公開された数値基準で審査された印です。LCP2.5秒、CLS0.1、INP200ミリ秒、Lighthouseで10点以内、テーマアプリ拡張の使用、Asset APIによるテーマ改変の禁止。これらは、アプリを長く使ううえで確かに効いてきます。認定は毎年見直され、基準を下回れば失われます。
一方で、料金、サポート、日本語対応、機能の充実度、事業継続性は、認定の対象外です。そして50インストール・5レビューという下限があるため、バッジがないことは品質が低いことを意味しません。
バッジは、候補を絞るための強力なフィルターです。ただし、最後の1本を決めるための基準ではありません。この線引きを持っておくと、App Storeでの比較はかなり楽になります。
Sources:
Shopifyの管理画面側の住所検証は、全プランで常時有効、無料で、米国に対応している。チェックアウト時の検証もトグル1つで有効にできる。そのうえで公式ドキュメントは、サードパーティの住所検証アプリを同時に使うと提案が競合してチェックアウトのコンバージョンを下げうるため、どちらか一方にせよと明記している。ここでカテゴリの見え方が変わる。アプリは配送可能性の判定を二重化するためのものではなく、Shopifyの検証がやらない「私書箱の拒否」「部屋番号の必須化」といったポリシー強制のためのものだ。2026-09-02時点で米国App Storeの実在アプリ4本を確認した。月額4.99ドルの定額、1注文あたり0.04ドル、そしてShopifyの請求とは別に契約が必要なものまで幅がある。