Three Months of Shopify App Store Rejections — A Solopreneur Submission Diary
2026年3月、独立して最初のアプリ「まるっと予約」をShopify App Storeに申請したとき、送信ボタンを押す手が忘れられないくらい覚えています。
前職のグローバル企業を辞めて、自分の名前で出す最初のプロダクトです。完璧に仕上げたつもりでした。
3日後、レビュアーから返ってきたメールには 「rejected(拒否)」 の四文字。理由のリストが、ずらっと続いていました。
今日書きたいのは、それから2ヶ月のあいだ、 まるっとシリーズ5本(予約・法務作成・フォルダ管理・検索・請求書)を申請し続けて、ほぼ毎回リジェクトをもらった独立3ヶ月目のリアルな記録 です。わたしが実際に踏んだ穴と、レビュアーの指摘で学んだことを、嘘なく残しておきたいと思いました。
これは観察記事ではなく、 わたし自身が2026年3〜5月にまるっとシリーズ5本の申請で経験した一次情報 です。リジェクトの指摘内容、対応にかかった時間、再申請の判断、すべてSHIN本人の体験として書いています。
なぜ独立直後に5本もアプリを作ろうと思ったか
そもそもなぜ、独立してすぐ5本ものアプリを並べる計画を立てたのか。理由はシンプルで、 ソロプレナーとして食べていくには、1本のホームランより、複数本の安打のほうが現実的 だと考えたからです。
前職時代、副業でShopifyのストアをいくつか触っていて、運営者から「予約も、特商法の法務ページも、Filesのフォルダ整理も、日本語検索も、インボイス対応の請求書も、それぞれ専用アプリやサービスを探さないといけないのが面倒」という声を、別々の業種の方から繰り返し聞いていました。1ジャンル1機能で5本並べれば、ひとつのストアで複数アプリを使ってもらえる可能性も出てくる。ソロでも「シリーズ」として打ち出せば、ブランドが立ち上がる。そう判断して、独立前から5本のリリース計画を引いていました。
独立計画の最初のドラフトでは、半年で5本を並べるつもりでした。実際には3月から5月の3ヶ月間で5本を出すことになり、結果的に 申請のたびにリジェクトされながら同時並行で改善する 修行のような期間になりました。
やったこと: 5本の申請を時系列で振り返る
ここからが本題です。1本目から5本目まで、それぞれの申請でどんな指摘を受け、何を直したか、時系列で書き出します。
- 2026年3月 / アプリ1: まるっと予約
初回審査リジェクト:GDPR Webhooks未実装
記念すべき1本目の申請結果は、初回リジェクトでした。指摘されたのは主に2点。 「Mandatory Compliance Webhooks(customers/data_request, customers/redact, shop/redact)が未実装」 と、 「アプリのスクリーンショットが英語環境で撮られていない」 。前者は完全な見落としでした。日本語向けに作ったので英語のテストストアでの動作確認も甘く、レビュアーが英語で叩いたら200を返さない状態だったのです。修正して再申請、2回目で通過。最初のリジェクトは正直しんどかったですが、必須Webhookの存在を体に刻めたのは大きい収穫でした。
- 2026年3月末 / アプリ2: まるっと法務作成
初回リジェクト:Billing APIの透明性
2本目で踏んだのは課金まわり。特商法・プライバシーポリシーの法務ページを生成するアプリで、トライアル後の課金条件を、アプリ内の説明文と App Listing の料金欄でうまく統一できておらず、レビュアーから 「ユーザーが支払う金額・タイミングが、インストール前に明確にわからない」 と指摘を受けました。Shopify Billing API は使っていたものの、 App Listing 側の料金表示と、アプリ内 RecurringApplicationCharge の金額が文言上ズレていたのが原因です。料金表示をすべて1ファイルから生成するように直し、再申請で通過。
- 2026年4月中旬 / アプリ3: まるっとフォルダ管理
初回リジェクト:アンインストール時のデータ削除
3本目では、アンインストール時の挙動を指摘されました。Shopify Files をフォルダ構造で管理するアプリだったので、保存しているフォルダ階層やタグの情報が、 「app/uninstalled webhook 受信時に、48時間以内に削除する処理が見当たらない」 という内容です。実装はしていたつもりでしたが、ジョブキューにエンキューはしているものの、テストショップで実際に削除されることを示すログが残っておらず、レビュアー側からは未実装に見えていたわけです。削除完了を構造化ログに残し、Webhook受信から48時間以内のフローをドキュメント化したPDFを添付して再申請、通過。
- 2026年4月末 / アプリ4: まるっと検索
初回リジェクト:Polarisデザイン基準
4本目で初めて受けたのが、UIに関する指摘でした。検索のフィルター画面を独自のCSSで凝って作っていたら、 「Polarisコンポーネントから過度に逸脱しており、Shopify 管理画面との一貫性を損ねている」 という指摘。具体的には独自のドロップダウン・独自のチェックボックス・独自のテーブルで、Polarisの
SelectCheckboxIndexTableを使っていなかった部分です。デザインへのこだわりはあったのですが、Embedded App では「管理画面の延長」として一貫性のほうが優先されるという原則を体で理解しました。Polaris に置き換えて再申請、通過。 - 2026年5月 / アプリ5: まるっと請求書
初回通過:5本目で初めての一発OK
5本目のまるっと請求書で、ようやく 初回審査一発通過 を経験しました。それまで踏んだ4本分の指摘を全部チェックリスト化して、申請前に自分で潰してから出したのが効いたと思います。指摘ゼロのメールを受け取った瞬間、自宅デスクで小さく拍手しました。地味な感動でしたが、独立3ヶ月で一番うれしかった瞬間のひとつです。
5本通して見えた、リジェクトの典型パターン
5本のうち4本でリジェクトを経験して、ようやく Shopify App Store 審査の指摘パターン がうっすら見えてきました。わたしのケースに限らず、公式の App requirements checklist に書かれている観点とも重なります。
わたしが実際に指摘された4つのパターンは次のとおりです。 これから1本目を出す方は、この4点だけは申請前に必ずセルフチェック してください。
- Mandatory Compliance Webhooks(GDPR系3種)が、英語テストストアで実際に200を返すか
- 課金条件が App Listing と アプリ内表示で完全に一致しているか
- app/uninstalled 受信後に、マーチャントデータの削除がログで証跡できるか
- 管理画面のUIが Polaris コンポーネントで実装されているか
出典:Shopify App requirements checklist (公式)
レビュアーの指摘は、どれも「公式ドキュメントを最初に丁寧に読んでいれば防げたもの」ばかりでした。情けない話ですが、独立直後は機能の実装に意識が向きすぎて、こうした審査要件を後回しにしていたのが正直なところです。
- 1
英語テストストアで実機動作を一周
Development Store を英語・USD・US タイムゾーンで作り直し、自分のアプリをインストールして1ユーザーフローを最後まで触る。日本語ローカル環境では発見できない不具合が、ここで7割は出てきます。
- 2
Mandatory Compliance Webhooksの応答確認
customers/data_request, customers/redact, shop/redact の3つに、HMAC 付きで実際にPOSTしてみて200が返ってくるかを確認する。さらに app/uninstalled のあと、48時間以内のデータ削除がログに残ることを確認します。
- 3
課金条件の文言を1ファイルから生成
App Listing の Pricing 欄、アプリ内の RecurringApplicationCharge、ヘルプページの料金説明、これら3箇所が同じ文言になるよう、料金定義を1ファイルから生成する仕組みにしておく。文言ズレは初学者が必ず踏むリジェクト要因です。
- 4
Polaris コンポーネントへの揃え直し
独自CSSで作ったUI要素を、Polaris の Select / Checkbox / IndexTable / Card / Page 等に置き換える。デザイン的な遊びは「ユーザーの主作業画面の外」だけに留めるのが安全です。
- 5
App Listing をストアオーナー目線で読み直す
自分がインストールするとしたら、料金・解約条件・対応範囲・サポート手段が、不安なく理解できるかを基準に書き直す。ここはレビュアーが「買い手の代理人」として最も厳しく読むパートです。
リジェクトはレビュアーの粗探しではなく、Shopify がエコシステム全体の品質を守るためのフィードバックなのだと、3本目あたりでようやく腹落ちしました。
3本目のリジェクトを受けた夜のわたし
学んだこと: ソロで5本通すために変わった習慣
5本目で初回通過できたのは、才能でも運でもなく、 習慣がいくつか変わったから です。具体的には次の3つでした。
1: 申請前に「英語テストストア」で必ず一周触る
これが最初に身につけた習慣です。日本語のローカルストアでは動いていても、Shopify のレビュアーは英語環境で動作確認をします。タイムゾーン、通貨、言語、ストアプラン、すべてが想定外の組み合わせになることを前提に、Development Store を英語・USD・US タイムゾーンで作り直し、自分のアプリをそこにインストールして一周触る。これだけで、初回リジェクトの確率がぐっと下がりました。
2: 「Mandatory Webhooks」専用の自動テストを書いた
2本目以降、 GDPR系3種の Webhook(customers/data_request, customers/redact, shop/redact)と app/uninstalled は、すべての新規アプリで共通実装にして、それぞれに対するエンドポイントが200を返すかを自動テストするスクリプトを用意しました。申請前に npm run review-check を1コマンド叩けば、必須Webhookの応答を一括で確認できる状態にしてあります。
Mandatory Compliance Webhooks は、レビュアーが必ず手で叩いて確認してきます。HMAC 検証 → 200応答 → 48時間以内のデータ削除実行、という3点セットで実装し、ログに証跡を残しておくと、再申請時の説明もスムーズになります。
出典:Shopify Privacy law compliance Webhooks (公式)
3: App Listing は「ユーザー目線」で書き直す
これは課金リジェクトのあと身につけた習慣です。料金、トライアル、機能制限、対応言語、サポート連絡先。ストアオーナーがインストール前に「自分はいくら払うのか」「何ができないのか」を不安なく理解できるか、を基準に App Listing を書き直すようになりました。レビュアーは「ストアオーナーの代理人」として読むので、技術的な正しさより、買い手の納得感が優先されます。
独立3ヶ月のいま、わたしの申請前チェックリストは20項目を超えています。そのうち15項目は、 過去のリジェクトで指摘された具体的な内容 から逆算して作ったものです。失敗の数だけ、自分のレールが太くなる感覚がありました。
2026年以降アプリの申請が多くなったことが原因でアプリ審査の時間がかなりかかっている印象です。
最初のアプリ審査時は2週間で1回目のフィードバックがきたのですが、後発のアプリは審査から1ヶ月連絡がないものもありました。
余裕を持って提出することが大事なのと、初回で厳重なテストを行い精度高いものを提出することをお勧めします。
独立3ヶ月目で残った気づき
5本の申請を通して、わたしのなかに残った気づきを3つだけ。
リジェクトは恥ずかしいことではなく、審査の一部
これが一番大きな気づきです。最初の1本目でリジェクトされたとき、わたしは正直、自分の能力不足を恥じていました。独立して最初のプロダクトでこれかと、自宅デスクで頭を抱えた夜もあります。でも5本通してわかったのは、 リジェクトは品質保証のための対話プロセス であって、開発者を篩い落とす儀式ではない、ということでした。指摘は具体的で、対応すれば次に進めます。
考えてみれば、Shopify App Store には世界中から毎日大量のアプリが申請されてきます。そのなかで、ストアオーナーが安心してインストールできる品質を保つには、誰かが「最初の他人」として叩く必要がある。その役を、Shopify のレビュアーが、丁寧に文章で説明してくれているのです。これを「篩」と読むか「対話」と読むかで、開発者としての気持ちはずいぶん変わります。
ソロだからこそ、レビュアーは最初の他人の視点
会社員時代であれば、社内のQAチームやプロダクトマネージャーが、リリース前に何重ものレビューをしてくれました。ソロには、そのレイヤーがありません。 Shopify のレビュアーが、わたしのアプリを最初に「他人の視点」で叩いてくれる存在 なのです。そう思うと、リジェクトメールに書かれた一行ずつが、社内レビューの議事録のように読めるようになりました。
5本通すと、自分なりの「事前チェックリスト」ができる
これはソロにとって、地味だけれど大きな資産です。1本目のときは何をチェックすべきかさえ分からず、闇雲に申請ボタンを押していました。5本目では、20項目以上のチェックリストを順番に潰してから申請する。 このチェックリストは、半年後に6本目を作るときも、来年新しいシリーズを始めるときも、ずっと使える 。失敗の数だけ、未来の自分が楽になる構造です。
リジェクトは未来の自分への手紙だと思っています。1本目で指摘された Webhook の話は、5本目のわたしには当たり前の前提になっていました。
5本目を通したあとの自分
これからアプリを出す人へ
最後に、これから独立してShopifyアプリを出そうとしている方、社内で初めてShopifyアプリを審査に出す方に向けて、3つだけ書きます。
ひとつ。 初回リジェクトを「失敗」ではなく「審査の続き」として受け取ってください 。レビュアーの指摘は、ほぼ確実に公式ドキュメントのどこかに書かれている内容です。指摘されたら、その箇所を読み直して、次の申請で完璧にしてくる。それだけのことです。
ふたつ。 英語テストストアでの動作確認を、申請前の必須工程にしてください 。日本市場向けのアプリでも、レビュアーは英語で叩きます。タイムゾーン・通貨・言語のすべてが英語デフォルトで動くか、申請前に必ず一周触ってください。これだけで、典型的なリジェクトの半分は防げます。
みっつ。 5本同時並行ではなく、1本ずつ通してチェックリストを育てる方法もあります 。わたしは独立直後の勢いで5本同時に走らせましたが、振り返ると1本目の通過から学びを抽出して、次に活かすほうが効率的だったかもしれません。ソロの体力に合わせて、無理のないペースを組んでください。
それから、これは独立3ヶ月の自分への戒めでもあるのですが、 リジェクトメールが来た夜に、すぐ再申請の準備を始めない ほうがいいです。一晩寝かせて、翌朝レビュアーの指摘を読み直すと、感情的に反発したくなる箇所が「たしかにそうだな」に変わっていることが多い。落ち着いた頭で読むレビュアーの指摘は、ほぼいつも、ストアオーナーの未来の声を代弁しています。
リジェクトの夜は、再申請のフォームを開かないこと。コードエディタも閉じて、散歩に出るくらいでちょうどいいです。翌朝の自分は、前夜の自分より2割は冷静で、2割は素直になっています。
2026年5月時点の体験記です。Shopify App Store の審査基準は継続的にアップデートされているため、申請前に必ず最新の公式ドキュメントを確認してください。


この記事を読んだ方におすすめ
Shopify予約アプリ
まるっと予約
ストアに予約機能を追加。日時・デポジット・キャンセルに対応。
💡 無料プランあり(月5件まで)
他のまるっとシリーズもチェック
Shopifyストア構築もお任せください
「自分でShopifyを設定するのは不安」という方に、アプリ開発者本人がShopifyストア構築+まるっと予約の導入をまるごとサポートいたします。
関連記事

What Shopify Merchants Actually Wanted from a Booking App — A Solopreneur Founder Note

The Reality of Building Shopify Apps from Home
3 Shopify App Architecture Pitfalls I Hit Building the Marutto Series

Three Things That Changed for Indie Salons After Switching to Shopify Booking

Five Tactics I Stopped in My First Three Months as a Solopreneur




