Shopify2026-05-15約8分で読めます

Shopifyアプリ開発Built for Shopifyソロプレナー

Built for Shopify バッジ取得への30日 — 個人開発者向け準備チェックリストと実装工程

Shopifyアプリを公開した次のマイルストーンは「Built for Shopify（以下 BFS ）バッジ」です。これはApp Storeでの露出を底上げする「品質バッジ」で、公開済みアプリだけが対象の追加審査という位置づけです。わたし（SHIN）は2026年3月にまるっと予約YOYAKUを公開し、現在はBFS取得を目指して準備工程を進めている段階です。本記事は、公式ドキュメントを読み込みながら個人開発者がBFSを30日で取りに行くための準備と実装をまとめた一次情報です。

わたし（SHIN）は2026年4月に独立した個人Shopifyアプリ開発者で、まるっとシリーズ6本（予約YOYAKU/法務作成/フォルダ管理/検索/請求書/売上ランキング）を運営しています。本記事執筆時点（2026-05-15）でBFSバッジは未取得で、これから取得を目指す「準備工程」を公式要件と一次情報視点で整理した内容です。「取得済みの体験談」ではなく「公式要件×個人開発者の実装プラン」として読んでください。

Built for Shopify バッジとは何ですか？

ひとことで言うと、 App Storeで「品質保証付き」と扱われる追加バッジです。アプリ公開＝App Store掲載までは「最低基準」を満たせばOKですが、BFSは「最低基準＋αの品質ライン」を満たした証で、検索順位や信頼バッジ表示で優遇されます。

Performance（性能）

Integration（統合）

Design（UX）

Trust（信頼性）

出典：Built for Shopify achievement criteria（Shopify公式）

想定工数

既存公開済みアプリを前提とした準備工程の見込み

最低インストール数

有料プランのactive shopsでの正味インストール

最低レビュー数

App Storeでの公開レビュー数

BFSは「公開後にもう一段の昇格試験を受ける」イメージです。公開済みでない場合は、まず先に申請〜公開を通すのが先決で、本記事は公開済みアプリを持っている個人開発者向けに書いています。公開までの30日工程はDay 28の記事にまとめてあります。

なぜ個人開発者でも目指す価値があるのですか？

Shopifyアプリ市場は世界中に競合がいて、個人開発者の認知獲得は年々厳しくなっています。BFSバッジは「審査チームに品質を保証された」というシグナルなので、マーケ予算ゼロのソロプレナーにとって最も費用対効果が高い差別化手段です。

01
検索結果での視認性が上がる
App Store内検索でBFSバッジが視覚的に目立つので、同カテゴリの非バッジアプリより選ばれやすくなります。
02
マーチャントの不安を下げる
日本語アプリは海外マーチャントから「英語サポートあるの？」と不安視されることが多いので、客観バッジが補強になります。
03
自分のコードに「審査済みの基準線」が引ける
「Web Vitals 75pでLCP 2.5s以下」のような明確な数値基準が外から与えられるので、ソロ開発で陥りがちな「品質基準が自分の主観だけ」という状態を抜けられます。

30日工程の全体像（Day 1〜Day 30）

ここからが本題です。BFS取得を目指す準備工程を、わたし自身が実装計画として立てている順番に並べます。日付はDay 1を起点にした相対表記です。

1
Day 1〜3｜BFS要件の読み込みと現状ギャップの可視化
まずは公式の Achievement criteria を全文読み、自分のアプリが「すでに満たしている項目」「未達の項目」「未計測の項目」の3区分で棚卸しします。スプレッドシート1枚で十分です。ここで埋めずに走り出すと、Day 25あたりで詰まります。
2
Day 4〜6｜App Bridge最新版への更新
BFSではWeb Vitals計測のため最新の App Bridge（app-bridge.js script タグを各ページのhead内に設置）が前提です。古いバージョンや独自ラッパーで動いている場合、ここを最新版に差し替えます。差し替えだけで丸1日溶けるケースもあります。
3
Day 7〜10｜Polarisコンポーネントへの寄せ替え
独自CSSで組んでいるフォームやテーブルを、Polaris（ Shopify公式デザインシステム）の対応コンポーネントに置き換えていきます。レスポンシブ・横スクロール禁止・ナビでアプリ名が省略されない、などBFS要件にそのまま直結します。
4
Day 11〜14｜Web Vitals計測と改善
管理画面の主要ページについて、 LCP / CLS / INP を Partner Dashboard 経由で確認します。28日間で100コール以上のトラフィックが必要なので、計測が間に合わない場合は社内ドッグフーディングで補います。改善の主軸は画像最適化・初期JSの分割・useEffect依存の整理です。
5
Day 15〜17｜Session Tokenとscope見直し
OAuth直後にSession Tokenで認証する構成になっているか、scopesが過剰になっていないかを点検します。アプリ公開時の審査で「scope過剰」を指摘された経験があれば、ここで再点検すると話が早いです。
6
Day 18〜20｜課金API（Billing API / Managed Pricing）の整合確認
料金プランの変更がマーチャント単独で完結するか、追加課金がリスティング上に明記されているか、を確認します。「サポートに連絡しないと解約できない」状態はBFS要件違反です。
7
Day 21〜23｜ストアフロント/チェックアウトへの影響度測定
ストアフロントに何かをinjectするタイプのアプリは、 Lighthouseスコアを10点以上落としていないかをチェックします。Web Pixels Extensions・Theme App Extensionsへの寄せ替えがここでの主作業です。
8
Day 24〜26｜ダークパターン排除とコピー見直し
タイマー煽り、5つ星評価のご褒美誘導、ロード時のフルスクリーンモーダル、自動消滅エラー文などを排除します。エラーは赤色・コンテキスト付き・自動で消えない、が原則です。
9
Day 27〜28｜社内QAと最終チェックリスト
後述する10項目チェックリストを最後に回します。1人で見ると見落とすので、別の開発者ストアでフレッシュにインストール→操作→アンインストールまで通すのが効きます。
10
Day 29〜30｜申請と結果待ち
Partner Dashboardから BFS achievement の申請を提出します。承認は即時ではなく、要件評価サイクル（Web Vitalsは28日ローリング）に依存するため、ここから2〜4週間の待機期間が発生する想定です。

30日のうち、もっとも工数が読めないのが「Day 11〜14のWeb Vitals改善」です。1日で終わることもあれば、1週間溶けることもあります。早めに計測値を取り、ボトルネックを特定するのが最優先です。

フェーズ別の工数見込み（個人開発者前提）

ここまでの30日工程を、ざっくりフェーズごとの工数で並べます。あくまで「わたし個人の見積もり」で、アプリ規模・既存コードの状態で大きく前後します。

出典：Built for Shopify achievement criteria（Shopify公式）を元にSHIN試算

工数の山は「Web Vitals改善」と「Polaris寄せ替え」の2つです。逆にここさえ事前に手を入れておけば、後段は半日〜1日でカタが付くタスクが多いです。

改善前後でWeb Vitalsはどう変わる想定ですか？

BFS要件のWeb Vitals3指標について、改善前（公開時の素のまま）と改善後（BFS狙い）の目安スコアを比較します。これは公式の合格ラインに合わせた「目標値」です。

出典：Web Vitals（web.dev）

CLSは値が小さい指標のため、グラフ上はx1000してプロットしています。LCPとINPはミリ秒単位、CLSは0〜1のスコアです。 BFSの合格ラインはLCP 2.5秒以下/CLS 0.1以下/INP 200ms以下（75パーセンタイル）なので、改善後のバーがそれを下回る位置に来るのが目標値です。

Built for Shopifyが要求する4つの軸

BFSの要件は無数にあるように見えますが、構造としては「性能」「統合」「UX」「信頼」の4軸に集約できます。

性能（Performance）

統合（Integration）

UX（Design）

信頼性（Trust & Utility）

申請通過パターン vs リジェクトパターンを並べて見る

BFSは「公開審査」と違って差し戻し→修正のループが回りにくく、要件未達なら「未達のまま」評価サイクルが終わります。通過パターンとリジェクトパターンを並べて、自分のアプリがどちらに近いかを早めに把握します。

管理画面の主要ページが Web Vitals 3指標すべて合格ライン以下
App Bridge最新版でSession Token認証
UIはPolaris、横スクロールなし、ナビでアプリ名が切れない
ストアフロントへの影響はLighthouse10点未満
料金プランの変更・解約がマーチャント単独で完結
50インストール以上＋5レビュー以上＋健全なPartner評価

出典：Built for Shopify achievement criteria（Shopify公式）

リジェクトパターンの中で、個人開発者がもっとも踏みやすいのは「独自CSS主体でPolarisを使っていない」ケースです。公開審査は通っても、BFSの「Familiar / Helpful」要件で確実に詰まります。Polaris寄せ替えは早めに着手するのが安全です。

申請前の最終チェックリスト10項目

Day 27〜28の社内QAでわたしが回す予定の最終チェックリストです。すべてチェックが入った状態を「申請可」の閾値にします。

App Bridge最新版が app-bridge.js script タグで全ページのhead内に設置されている
OAuth直後にSession Tokenで認証する構成になっている
管理画面の主要ページで LCP 2.5s / CLS 0.1 / INP 200ms をクリア（75p）
ストアフロント Lighthouseスコアの低下が10点未満
UIはPolarisコンポーネントが基本で、横スクロールが発生していない
料金プランの変更・解約がアプリ内のみで完結する
追加課金がApp Storeリスティングの「Description of additional charges」に明記されている
カウントダウンタイマーや5つ星レビューの見返り誘導がない
50インストール以上＋5レビュー以上＋直近レーティングがApp Store基準を満たしている
Partnerアカウントに未対応の違反通知が残っていない

どうしてもやっておきたい準備3つ

工数が限られているソロ開発者でも、これだけは絶対に外せない準備を3つに絞ります。

外せない準備3点

App Bridge最新版への更新: ここが古いとWeb Vitals計測自体が始まりません。逆に最新化さえ済めば、計測データは自動で蓄積されます。
Polarisコンポーネントへの寄せ替え: BFSのDesign要件を一発で複数満たせます。デザイン体験の品質が上がるので、レビュー評価にも効きます。
料金プラン操作のセルフサービス化: マーチャントがサポート連絡なしで解約できる状態にするだけで、 Built for Shopify achievement criteria（Shopify公式）のBilling要件を多くクリアできます。

よくあるリジェクト要因

逆に、個人開発者が踏みやすい地雷も整理しておきます。

よくあるリジェクト要因

ストアフロントにscript tagで重いJSをinjectしていてLighthouseスコアを15〜20点落としている
「インストール時に有料プラン強制」「7日トライアル後に高額プランへ自動遷移」など課金UXの強引さ
Polarisを使わず独自UIで作ったテーブルが横スクロールする・モバイルで崩れる
5つ星レビューを書くと機能解放、というアンチパターン
古いREST APIや非推奨APIを使い続け、deprecation 90日以内になっている

課金APIまわりで気をつけたいこと

BFSの審査では、課金まわりの「マーチャントへの透明性」が重視されます。以下の3点だけでも、最初に押さえておくと申請後の差し戻しが減ります。

メリット

Billing APIまたはManaged Pricingで料金プランを管理し、プランの変更・解約をマーチャント単独で完結させる構成。

デメリット

Shopify外の決済ページにマーチャントを誘導する、サポート連絡で解約させる、追加課金を未開示にする等の構成。

出典：App Store requirements（Shopify公式）

アクセシビリティの最低ライン

BFSの Design 要件は、アクセシビリティに直接言及するセクションこそ少ないものの、「分かりやすいUI」の中に実質的なa11y要件が含まれています。エラー文の色とコンテキスト、フォーカス可視、見出し階層、アイコンのみのボタンに必ずラベルを付ける、などです。Polarisコンポーネントを素直に使えば、ここの大半は自動で満たせます。

Web Vitals: ユーザー体験の品質を表す Google主導のWeb指標群。 LCP（読み込み速度）/ CLS（レイアウト安定性）/ INP（応答性）の3指標が中核で、Built for Shopifyの管理画面性能評価でも採用されています。

まとめ：30日工程をひとつのフローにすると

ここまでをひとつのストーリーとして整理します。

Day 1〜3
現状把握
公式要件を全文読み、未達ギャップをスプレッドシートで可視化します。
Day 4〜10
土台の差し替え
App Bridge最新化＋Polaris寄せ替え。ここまでで土台が整います。
Day 11〜23
性能と統合の最適化
Web Vitals計測・改善、課金API・ストアフロント影響度の調整。
Day 24〜28
UX磨きとQA
ダークパターン排除、エラー表示見直し、最終チェックリスト10項目。
Day 29〜30
申請と評価サイクル待ち
Partner Dashboardから申請。Web Vitalsの28日ローリング評価が回るまで待機します。

→ まるっとシリーズを見る

FAQ

公開時の審査は「App Storeに掲載できる最低基準を満たすか」のチェックで、すべてのアプリが通る必要があります。BFSはその先で「品質ライン超過の追加バッジ」を取りに行くもので、すでに公開済みのアプリだけが対象です。要件もWeb Vitals数値・Polaris利用・ダークパターン排除など定量・定性とも厳しめです。

取れます。ただし「最初から狙って設計する」のが圧倒的に有利です。公開後にPolaris非対応の独自UIから差し替えるのは大手でも工数が膨らみます。これから新規アプリを設計する方は、最初からPolaris+App Bridgeで組むのが結果的に近道です。

最新のApp Bridgeをhead内に設置していれば、Partner Dashboard上で自動的に75パーセンタイルのスコアが表示されます。28日間で100コール以上のトラフィックが必要なので、利用実績が薄いアプリはまず利用者を増やす必要があります。

あります。管理画面側のWeb Vitals 3指標、Polaris UI、ダークパターン排除、課金APIの透明性などはストアフロントを触らないアプリにも適用されます。「ストアフロント影響10点未満」の要件は0点（=影響なし）でも問題なく満たせるので、むしろ管理画面アプリの方が有利です。

一概には言えませんが、「管理画面で完結し、課金がBilling APIで素直に組めるアプリ」が比較的取りやすい印象です。Carrier Services・Fulfillment Services・Subscription系などはカテゴリ固有の追加要件があり、要件項目数自体が増えます。

BFSは「審査担当が手作業でレビュー」というより「要件達成状況を継続評価する」性質が強いため、Web Vitalsの28日ローリングが回るまでは結果が出ません。最短でも申請後数週間は待機する想定で計画すると安全です。

いいえ。要件未達になればバッジは外れます。たとえばWeb Vitalsが28日平均で合格ラインを下回ると、バッジ非表示の対象になり得ます。取得後の維持運用も含めて設計するのが前提です。

BFSの要件は言語非依存です。日本語UIで作っていても、Polarisコンポーネント・Web Vitals・課金APIなどの技術要件さえ満たせば取得可能です。むしろ「日本語＋BFSバッジ」という掛け合わせは日本市場でかなり強い差別化になります。