Shopifyアプリ申請から公開まで30日 — まるっと予約YOYAKUの全工程ログ
Shopifyアプリ「まるっと予約YOYAKU」を申請から公開まで通すのに、わたしは約30日かかりました。 準備に10日、Partner Dashboard登録と書類整備に5日、初回審査の往復に10日、最終確認とリリースに5日 という配分でした。詰まったのはコードよりも、Privacy Policy・GDPR mandatory webhooks・サブスクリプション設定など「アプリ審査固有のルール」の部分です。この記事は、わたし（SHIN）が2026年2〜3月に実際に通した30日工程を、後続のソロ開発者向けに残す一次情報ログです。
本記事はわたし（SHIN）が2026年2〜3月にまるっと予約YOYAKUを申請〜公開した一次情報です。所要日数や工数は「わたし個人比の体感値」「設計時の見込み値」であり、Shopify公式の審査SLAではありません。アプリの規模・カテゴリ・審査担当者によって変動します。
なぜ30日もかかったのか？
正直に書きますが、コードを書く時間より「審査のお作法を理解する時間」の方が長かったです。Shopifyアプリは個人開発でもPlay Store / App Storeほど厳格ではないものの、 マーチャント保護のためのルール一式 が独特で、初回はそこに時間を吸われます。
出典：まるっと予約YOYAKU（Shopify App Store）
30日は わたしが初めてShopifyアプリを申請したケースの体感値 です。2本目以降は審査の勘所が分かるため、3本目（まるっとフォルダ管理）は約2週間で公開まで通せました。慣れの効果は大きいです。
なぜまるっと予約YOYAKUを作ったのか？
独立直後で売上ゼロの状態だったわたしが、最初に手を付けたのが予約アプリでした。Shopifyには予約系の日本語アプリが少なく、無料で使えるものはさらに少なかったからです。「自分が欲しい」と「市場に空きがある」が重なった領域でした。
- 01
日本語UIの予約アプリが少ない
Shopifyの予約アプリは海外製が多く、日本語UIや日本の商習慣（事前決済・キャンセルポリシー・受付メール文化）に馴染むものは限定的でした。
- 02
独立直後で実装速度が必要だった
最小機能で公開し、フィードバックをもらいながら育てる戦略が現実的でした。最初から多機能を目指すと公開できません。
- 03
自分自身が欲しかった
自分のサービス紹介ページにも予約導線を置きたかったので、ドッグフーディングが成立する領域でした。作って自分で使う、が最初の動機です。
30日のタイムライン（Day 1〜Day 30）
ここからが本題です。実際の30日工程を時系列で並べます。日付は2026年2月15日を Day 1 として数えています。
- Day 1〜3
Partner Dashboardの整備
Shopify Partnerアカウントを作成し、開発ストア（Development Store）を1つ立てます。本人確認・税務情報・支払い受け取り口座の登録までここで終わらせます。書類が揃わないと後段の課金APIが通せません。
- Day 4〜10
アプリ本体の最終仕上げ
機能実装はほぼ終わっていたので、ここでは「審査で見られる箇所」を仕上げます。OAuth・Session Token・GDPR mandatory webhooks・課金API連携。コードよりも設定の方に時間がかかりました。
- Day 11〜15
App Listingの作成
アプリ名・説明文・スクショ・カテゴリ選択・価格設定。スクショは想像以上に重要で、5回くらい撮り直しました。日本語と英語の二言語版を用意するのが推奨です。
- Day 16
初回提出
ここで初めてSubmitボタンを押しました。審査キューに乗るまで数時間、最初のフィードバックが返ってくるまで約5営業日でした。
- Day 21
初回フィードバック受領
指摘は5項目。Privacy Policyの記述不備、サポートメールアドレスの未設定、scopes過剰、テスト用Demoストアの提示要求、サブスク料金表示の不整合。1日で対応可能な内容と、そうでない内容が混在していました。
- Day 22〜26
修正と再提出
指摘5項目を順番に潰します。Privacy Policyだけは別途URLを公開する必要があり、独自ドメインの運用に時間がかかりました。再提出後の審査は早く、2営業日で結果が返ってきました。
- Day 28
承認
再審査でApprove。Shopifyの審査担当からは「修正対応ありがとう」のメッセージのみ。あっけないくらい静かな承認でした。
- Day 30
リリース
自分のタイミングで公開ボタンを押せます。承認＝即公開ではなく、 公開タイミングは自分で決められる のがポイントです。週末を避け、平日の朝に公開しました。
30日の工程で一番大きな分岐点は Day 21 の初回フィードバックでした。ここで指摘5項目をどれだけ早く潰せるかで、公開日が前後に1〜2週間ずれます。
申請に必要なものは何？
「最低限これが揃っていないとSubmitできない」項目をチェックリストにまとめます。Shopify公式の要件チェックリストに沿っています。
- Shopify Partnerアカウント（本人確認済み）
- Development Storeが最低1つ稼働
- Partner Dashboardでアプリ登録済み（API key発行済み）
- OAuth実装（インストール時の権限同意フロー）
- GDPR mandatory webhooks 3種実装（customers/data_request, customers/redact, shop/redact）
- Privacy Policyの公開URL（自社ドメイン推奨）
- サポートメールアドレス（自動応答ではなく実在）
- App Listing用のスクショ（最低3枚、推奨5〜7枚）
- アプリの紹介動画またはGIF（任意だが審査が早くなる印象）
- Shopify Billing API実装（有料プランの場合）
- テスト用デモストアまたは動作確認手順書
出典：Shopify App Store Best Practices
GDPR mandatory webhooks は 「実装した」だけでは通りません 。Shopifyの審査側はテストリクエストを実際に投げてきます。HMAC検証して200を返す実装を入れていないと、ここで一発で差し戻されます。
出典：Shopify GDPR Webhooks 公式ドキュメント
審査で詰まったポイントは？
初回審査で指摘された5項目を、後続のために具体的に残します。一般論ではなく、わたしのケースで実際に詰まった箇所です。
- 01
Privacy Policyが「準備中」だった
申請時にPrivacy Policyをサイトに公開しておらず、Notionのドラフトリンクを貼っていました。当然NG。独自ドメイン配下に公開URLを用意し直しました。所要1日。
- 02
サポートメールが個人Gmailだった
support@ ではなく個人Gmailを登録していました。審査では弾かれませんが、Built for Shopify を視野に入れると独自ドメインのメールを推奨されます。所要半日。
- 03
scopesが過剰だった
使っていない write_customers と read_inventory を要求していました。最小権限原則違反。 必要なscopeだけに絞る のは審査でほぼ確実に見られます。所要半日。
- 04
テスト用デモストアの提示を求められた
審査担当が動作確認するためのストアURLとログイン情報を求められました。最初は提示せず、後から追加で送る形になりました。所要半日。
- 05
サブスク料金表示の不整合
App Listingの価格表記とBilling APIで設定したRecurringChargeの金額が1円ズレていました。意図せぬ転記ミス。一致させて再提出。所要15分。
5項目のうち、4項目は 再提出を急げば1営業日以内に潰せる内容 でした。Privacy Policy だけは独自ドメインのDNS反映待ちがあったため1日かかりました。事前準備さえ完璧なら、再提出ループは短くできます。
工数の内訳はどうなっていたか？
30日の中身を「フェーズ別の体感工数」で振り返ります。これは わたし個人比の見込み値 であり、アプリ規模やカテゴリで大きく変動します。
上記の数値は わたし個人比の見込み値 です。アプリの複雑度、Shopifyの審査キューの混み具合、審査担当者のレスポンス速度によって、各フェーズは1.5倍程度に伸びる可能性があります。
単独申請 vs 既存アプリのアップデート
「初回申請」と「アップデート申請」では難易度が大きく違います。両者の違いを整理します。
審査項目が全項目フルチェック。Privacy Policy・GDPR Webhooks・OAuth・Billing API・App Listingまで全て初回確認です。所要は約30日（わたしの場合）。
変更箇所のみが審査対象。スコープ追加・新機能追加など差分が小さければ数日で通ります。2本目以降はこちらに近い感覚で進められます。
出典：Shopify App Submission Guide
申請パターン3類型
申請者の状況によって、最適な進め方は変わります。3パターンに分けて整理します。
わたしのケース。30日見積もり。Privacy Policyの公開やサポートメールなどの「外回り」整備に時間が割かれます。
- 独自ドメインを先に取得
- Privacy Policyテンプレを早めに用意
- サポートメールを独自ドメインで作る
申請のメリットと注意点
Shopify App Store公開のメリットと、想定外に詰まった点を整理します。
App Store掲載アプリはShopify審査済みという暗黙の保証が付きます。個人開発でも同じ土俵に乗れます。
自前で決済画面を作る必要がなく、Shopifyの請求書に同梱される形で課金できます。審査も楽です。
海外製アプリが多い中、日本語UIで参入すると検索で見つけてもらいやすくなります。
独自ドメインで公開する必要があり、コードと別の作業として時間を取られます。先回りで準備しておくのが鉄則です。
実装するだけでなく、Shopify側からの実テストリクエストに200を返す必要があります。HMAC検証は省略不可です。
初回フィードバックまで約5営業日、再提出後は2営業日が体感値。コントロール不能な待ち時間が発生します。
再申請を避けるための準備チェックリスト
初回でApprove を狙うための、わたしの個人体感ベースのチェックリストです。これを全部潰してからSubmitすれば、再提出ループに入る確率はかなり下がります。
- Privacy Policyを独自ドメインで公開済み
- サポートメールが独自ドメインで実在
- scopesは最小権限のみ要求
- GDPR mandatory webhooks 3種が200を返す
- HMAC検証コードが本番設定で動く
- Billing APIの料金表示がApp Listingと完全一致
- テスト用デモストアのURLとログインを用意
- App Listingのスクショが最低5枚
- App Listingが日本語と英語の二言語
- アプリ名がブランド名スタートになっている
出典：Built for Shopify status criteria
Built for Shopify を狙うべきか？
公開後すぐに目指す必要はありません。Built for Shopify は 公開後の指標が安定してから 申請する位置付けです。
GDPR Webhooksなど安全性関連はほぼ App Store 申請で満たせます。差分は少ないです。
Lighthouseスコアの低下を10ポイント以内に抑える、などの定量基準があります。公開後の実測が必要です。
Polaris/App Bridgeでの統合度合い。これは初期実装で意識しておくと後で得します。
インストール数・レビュー・評価の蓄積が必要。新規公開直後は満たせない項目です。
わたしも初回申請ではBuilt for Shopify は目指しませんでした。 まずは公開して使われ始めることが最優先 です。指標が貯まってから申請する方が、審査も短く済みます。
公開タイミングの戦略
承認 = 即公開ではありません。承認を受けてから、自分の都合で公開ボタンを押せます。わたしは以下の判断基準を使いました。
- 01
平日の朝に公開する
トラブル発生時に即対応できる時間帯を選びます。週末や深夜の公開は、何かあった時にリカバリが遅れます。
- 02
サポート体制を1日空ける
公開当日は他作業を入れず、問い合わせ対応に集中します。最初の24時間が一番質問が来やすい時間帯です。
- 03
リリース告知を準備しておく
X（旧Twitter）やブログ記事を事前に用意しておき、公開と同時に発信します。発見されない期間を短くする工夫です。
よくある質問（FAQ）
申請前後でわたし自身が気になっていた質問と、後から振り返って答えられるようになった内容をまとめます。
わたしのケースでは初回フィードバックまで約5営業日、再提出後の確認まで約2営業日でした。合計の審査往復で約8〜10営業日というのが個人体感値です。Shopify公式の確定SLAではなく、キューの混雑状況によって前後します。
回数制限はありません。指摘事項を潰して再提出すれば、何度でも審査キューに戻れます。ただし、毎回の再審査でも数営業日のリードタイムが発生するので、一度で全項目潰す方が早く公開に到達できます。
無料アプリなら不要です。有料プラン（サブスク・買い切り・従量）を提供する場合は Shopify Billing APIの利用が必須 です。自前のStripe決済などをアプリ内に組み込むのは禁止されています。
Partner Dashboard上でアプリは「Draft」状態のままで、Development Storeにインストールしてテストできます。さらに、Custom Distributionで特定ストアにのみ配布することも可能です。公開前にUXを詰めるならこの段階が一番自由です。
App Store公開後、安全性・パフォーマンス・使いやすさ・有用性・情報の完全性の5基準を満たすと申請可能です。新規公開アプリは「Proven Usefulness」（インストール・レビュー）の蓄積が必要なため、しばらくは取れません。公開後数ヶ月の実績が前提です。
Partner Dashboardのアプリ詳細ページに、審査担当者からのコメントが残ります。同時にPartner登録のメールアドレスにも通知が来ます。Slackなど他チャネルへの通知連携は基本ありません。
申請自体は無料です。ただしShopify Partnerアカウントの取得時に本人確認や税務情報の登録が必要で、そこに準備の手間がかかります。費用ではなく時間コストの方が大きいです。
可能です。Partner Dashboardから「Unpublish」できます。ただし既にインストール済みのストアにとっては突然使えなくなる挙動になるので、取り下げ前に告知期間を設けるのがマナーです。
わたしが2本目以降で省略できたこと
1本目は30日かかりましたが、2本目以降は約2週間で通せるようになりました。 省略できた工程 を整理します。
- 01
Privacy Policyの再利用
1本目で作ったPrivacy Policyを、アプリ名と取得データ範囲だけ差し替えて流用できました。テンプレ化が効きます。
- 02
サポートメール・サポートページの共通利用
まるっとシリーズはサポート窓口を統一しているため、2本目以降は新規に用意する必要がありません。
- 03
App Listingテンプレの流用
アプリ名・スクショ・カテゴリ以外はテンプレで埋められるようになりました。書く時間が3分の1に短縮されます。
- 04
Billing APIの実装パターン化
1本目で実装したRecurringApplicationChargeのコードを、2本目以降はモジュール化して使い回せます。
1本目は「アプリ審査というゲームのルールを覚える時間」でした。覚えてしまえば、2本目以降は同じルールの上で走るだけなので、コードを書く時間以外は劇的に短くなります。
設計者として伝えたい申請の鉄則
6本のアプリを通しながら見えてきた、申請を通すための鉄則を3つに絞ります。
- 01
Privacy Policy・サポートメール・独自ドメインを先に作る
コードより先にこれを準備しておくと、申請直前で詰まる確率が大きく下がります。後回しにすると必ず痛い目を見ます。
- 02
GDPR Webhooksは実装＋実テスト両方やる
実装しただけで安心せず、自分のサーバに実際にテストリクエストを投げて200を返すことを確認してください。HMAC検証もここで通しておきます。
- 03
scopesは絞るほど審査が早い
将来使うかもしれないscopeを先に取っておくのは悪手です。 使う時に追加申請する 方が、初回審査がスムーズに通ります。
申請プロセスは確かに地味で、コードを書くより面白くありません。それでも、 マーチャントが安心して使えるアプリの土台はここで決まる と考えると、面倒な工程ではなく品質保証のフェーズに見えてきます。
まとめ
Shopifyアプリ「まるっと予約YOYAKU」を申請から公開まで通すのに、わたしは30日かかりました。コードよりも審査のお作法に時間を吸われた30日でしたが、 2本目以降は約2週間に短縮 できたので、初回投資としては妥当な工数だったと振り返れます。
これからShopifyアプリを申請する個人開発者の方は、 Privacy Policyとサポートメールを独自ドメインで先に作っておくこと 、 GDPR mandatory webhooksの実テストまで通しておくこと 、 scopesを最小権限に絞ること 。この3点だけでも初回申請の通過率は大きく変わると感じています。
この記事を読んだ方におすすめ
Shopify予約アプリ
まるっと予約
ストアに予約機能を追加。日時・デポジット・キャンセルに対応。
💡 無料プランあり（月5件まで）
他のまるっとシリーズもチェック
Shopifyストア構築もお任せください
「自分でShopifyを設定するのは不安」という方に、アプリ開発者本人がShopifyストア構築＋まるっと予約の導入をまるごとサポートいたします。
