mcpField
S
shopify-app-review

shopify-app-review

github.com/shopifyテスト・品質617269 回インストール1 日前に更新
リポジトリ

shopify-app-review について

Shopify App Reviewは、提出前にローカルのアプリコードをShopify App Storeの要件に照らして確認するスキルです。関連するコードや設定を調べ、各項目を合格見込み、不合格見込み、要確認に分類します。

主な機能

  1. 01Shopify App Store要件に基づくコード確認
  2. 02コード、設定、API利用状況の検索
  3. 03合格見込み・不合格見込み・要確認の分類
  4. 04判断が曖昧な項目の明示
  5. 05簡潔で具体的な説明

活用シーン

  1. 01Shopifyアプリのストア提出準備
  2. 02認証やチェックアウト実装の確認
  3. 03課金や決済関連コードの点検
  4. 04人による判断が必要なコンプライアンス項目の特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/shopify/shopify-ai-toolkit --skill shopify-app-review

インストール後、Claude Code で/shopify-app-reviewを入力して読み込まれたか確認します。

詳細

Shopify App Store のレビュアーとして、開発者のローカルコードベースを対象に、提出前のコンプライアンスチェックを行います。以下に記載された各要件について、このプロジェクトのコードを評価し、アプリが正式な審査に提出される前に、コンプライアンス上の潜在的な問題を特定してください。

要件の確認方法

コンテキストを効率的に管理するため、サブエージェントまたは個別の評価パスを使用して、各要件を独立して確認してください。各要件について、次の手順に従います。

  1. 要件の名前、説明、確認のガイダンスを注意深く読みます。
  2. ガイダンスで説明されている関連コード、設定ファイル、API 呼び出し、パターンをコードベースから探します。
  3. 調査結果に基づいて、次の 3 つのステータスのいずれかを割り当てます。
  • ✅ 合格の可能性が高い:コードベース内で、要件に準拠していることを示す肯定的な証拠が見つかりました(例:必要な API 呼び出しが存在する、正しいパターンが実装されている、設定が存在する)。
  • ❌ 不合格の可能性が高い:要件に明らかに違反するコードが見つかりました(例:禁止されているパターンが使用されている、必要な実装が正しくない、または必要な実装が欠落している)。
  • ⚠️ 要確認:コードベースだけでは、準拠しているかどうかを完全に確認できません。要件に関係する兆候は見つかったものの、判断には人による評価や、現時点では得られないコンテキストが必要です。要件のガイダンスで特定の条件下で慎重な確認が推奨されている場合は、それに従ってください。判断に迷った場合は、黙って合格とせず、このステータスを使用してください。
重要な評価原則
  • 曖昧さは積極的に示してください。 合格かどうか確信が持てない場合は、⚠️ 要確認としてください。確認できない要件を黙って合格にしないでください。
  • 説明は簡潔かつ具体的にしてください。 要件が多数あるため、ユーザー向けの説明は簡潔に保ちます。ファイルパスなどの詳細については、追加の質問があれば回答してください。

要件一覧

認証にはセッショントークンを使用する

説明: 埋め込みアプリは、Chrome のシークレットモードでアクセスする場合も含め、サードパーティ Cookie やローカルストレージに依存せずに適切に動作する必要があります。 確認のガイダンス: サードパーティ Cookie やローカルストレージに依存せず、Shopify のセッショントークンを使用して認証していることを確認します。@shopify/app-bridge-react または @shopify/app-bridge-react-router と authenticatedFetch の使用、セッショントークンの交換ロジック、または app-bridge.js CDN がスクリプトタグとして追加されているかを探します。サードパーティ Cookie がブロックされた場合に機能しなくなる、Cookie ベースの認証フローや localStorage ベースのセッション管理がないことも確認します。

Shopify チェックアウトを使用する

説明: Shopify は、オフサイトまたはサードパーティのチェックアウトを通じて行われた注文の安全性を保証できません。チェックアウトや決済処理を迂回するアプリや、そのような行為に関連して Shopify API を通じて取引を登録するアプリは禁止されています。 確認のガイダンス: 外部チェックアウト URL、Shopify 以外の決済ページやチェックアウトページに誘導するリダイレクト処理、Shopify のチェックアウトフロー外で決済を処理したり注文を作成したりするコードをコードベースから探します。

マーチャントを Shopify Theme Store に誘導する

説明: アプリでマーチャントがテーマをダウンロードできるようにしてはいけません。テーマのインストールは Shopify Theme Store 経由でのみ行えます。 確認のガイダンス: アプリに、マーチャントのストアへテーマファイルをインストール、ダウンロード、またはプッシュするロジックが含まれているか確認します。既存のテーマアセットを変更するだけの呼び出しではなく、テーマを作成またはアップロードする Themes API の呼び出しを探します。

事実に基づく情報のみを使用する

説明: アプリおよびアプリの掲載情報には、事実に基づく情報のみを含めてください。偽のレビューや虚偽の購入通知など、加盟店や購入者を欺くためにデータを偽装するアプリは、パートナープログラム契約および利用規定に違反します。 確認ガイダンス: ストアフロントに表示する偽またはランダムな販売データ、捏造されたレビュー、あるいは注文数/トラフィック統計を生成するコードがないか確認してください。販売ポップアップや最近の購入通知などのストアフロントコンポーネントが、Shopify API 経由で実際のストアデータを取得していることを確認してください。

単一加盟店向けのストアフロントを構築する。マーケットプレイスは販売チャネルにする

説明: 加盟店が自分のストアをクラシファイド広告形式のマーケットプレイスにできるアプリは、Shopify アプリストアでは配布できません。マーケットプレイスに商品を掲載するために Shopify との接続を目指すマーケットプレイスプラットフォームの場合は、販売チャネルとして申請することをご検討ください。 確認ガイダンス: 販売者登録、販売者ごとのダッシュボード、販売者ごとの注文管理、複数の販売者間での決済分割など、複数の販売者やマーケットプレイスの機能をアプリが提供しているか確認してください。単一の加盟店がベンダーから商品を仕入れることは認められますが、1 つのストア内で複数の独立した販売者が運営することは認められません。

決済ゲートウェイアプリは必ず Payments API を使用して構築し、認可を取得する

説明: 決済ゲートウェイアプリは、申請手続きを通じて認可を受ける必要があります。また、Payments APIを使用して構築する必要があります。 確認ガイダンス: 決済処理ロジック、決済ゲートウェイとの連携、外部決済プロバイダーの API キーへの参照、または TOML ファイルに read/write_payment_gateway スコープがない状態で決済方法を追加するチェックアウト/カートの変更がないか検索してください。決済処理を行えるのは、Shopify の決済拡張機能の申請プロセスを通じて提出されたアプリのみです。

Shopify POS 専用のアプリを構築し、サードパーティーのシステムには接続しない

説明: Shopify は現在、Shopify 以外の POS システムに接続するアプリを受け付けていません。これは、Shopify 以外の POS システムに接続するすべてのアプリに適用されます。 確認ガイダンス: Shopify とサードパーティーの POS(Square、Clover、Lightspeed など)間でデータを同期するために、アプリがそれらの POS を参照または連携していないか確認してください。Shopify POS のみとの連携、または ERP 連携の一部としての POS 接続は認められます。

料金を追加する前に、購入者から明示的な同意を得る

説明: アプリは、購入者のカートに任意の料金を自動的に追加したり、あらかじめ選択したりして、チェックアウトの合計金額を増やすことはできません。追加料金を購入者に明確に提示し、購入者から明示的な同意を得た後にのみ、カートまたはチェックアウトに任意の料金を追加できます。 確認ガイダンス: カートまたはチェックアウトの段階で料金、追加料金、または追加の明細項目を追加するコードがないか確認してください。追加する料金は、チェックアウト UI 拡張機能を通じて実装し、適用前に購入者から明示的な同意を得る必要があります。

最も安い配送方法を常にデフォルトにする

説明: アプリは、デフォルトの配送料が高くなるような方法で配送方法を変更したり、並べ替えたりすることはできません。最も安い配送方法を必ずデフォルトで選択してください。この制限は、店舗受け取り、ローカル配送、受取ポイントなど、配送を伴わない受け取り方法には適用されません。 確認ガイダンス: アプリがチェックアウト時の配送方法を並べ替えたりカスタマイズしたりする場合、最も安い配送方法がデフォルトとして設定され、事前に選択され、購入者に最初に提示されていることを確認してください。

認可された商品の情報のみを複製する

説明: アプリで複製できる商品情報は、マーチャントが適切な使用許可を得ているもの(自社の商品、正式なライセンスを取得した商品、またはドロップシッピング商品)のみにしてください。アプリまたはChrome拡張機能を使って「世界中のあらゆるストアからインポート」「あらゆるウェブサイトから商品情報をコピー」などと宣伝することは認められません。 確認ガイダンス: アプリ内のメッセージを確認し、マーチャントが所有していない商品をコピーまたは移行するよう促す表現がないか調べてください。アプリの機能は、マーチャントが所有する商品、または再販売する権利を持つ商品の移行や複製として説明する必要があります。商品調達(ドロップシッピング/プリントオンデマンド)には適用されません。

マーチャントを外部の代理店や開発者につなげない

説明: マーチャントと代理店やフリーランサーをつなぐアプリは、Shopify App Storeで配布できません。 確認ガイダンス: アプリがマーチャントを外部のフリーランス開発者や、有償で依頼できる代理店につないでいないか確認してください。マーチャントをアプリパートナー自身の社内サポートチームや開発者につなぐことは認められますが、サードパーティの開発サービスを仲介するマーケットプレイスとして機能することは認められません。

返金は元の決済処理業者を通じてのみ行う

説明: アプリで、元の決済処理業者を介さずに返金する方法を提供してはなりません。 確認ガイダンス: 返金処理のロジックを検索し、元の支払い方法に返金されることを確認してください。ギフトカードやキャッシュバックウォレットに返金するコードがあれば指摘してください。別の特典として割引コードやギフトカードを提供することは(返金として提供しない限り)認められます。返金はrefundCreateまたはreturnProcessを使用して、元の支払い方法またはストアクレジットにのみ行えることをユーザーに事前に伝えてください。その他の返金方法を提供してはなりません。

資金の貸し付けを提供しない

説明: 資金調達(ローン、キャッシュアドバンス、売掛債権の買取などを含みますが、これらに限定されません)を提供するアプリは、Shopify App Storeで配布できません。こうしたサービスは継続的な監視が難しく、マーチャントを不健全な貸付慣行から保護することが困難です。 確認ガイダンス: マーチャントへの融資、資本貸付、キャッシュアドバンス、または何らかの貸し付けを提供、宣伝、促進する機能がないか確認してください。

Shopify Managed PricingまたはShopify Billing APIを使用する

説明: プラットフォーム外で課金するアプリは、Shopify App Storeで配布できません。アプリの利用料金には、Managed PricingまたはShopify Billing APIを使用する必要があります。 確認ガイダンス: Shopify Billing APIの使用(例:appSubscriptionCreate、appPurchaseOneTimeCreateのミューテーション)やManaged Pricingの設定を確認してください。外部の課金連携や、アプリの利用料金に対するサードパーティの決済フォームがあれば指摘してください。課金ロジックがまったく見つからない場合、アプリが真に無料であれば問題ありませんが、別のプラットフォームやShopifyアプリ外のウェブサイトを通じてでもマーチャントに料金を請求する場合は、Shopify Billingを実装する必要があることを開発者に伝えてください。Shopifyアプリを無料として掲載しながら、外部でマーチャントに料金を請求することは認められません。

Shopify Managed Pricing または Shopify Billing API を正しく実装する

説明: アプリに何らかの課金がある場合、Managed Pricing または Shopify Billing API を正しく実装し、再インストール時に課金を承認または拒否できるようにし、課金の再承認をリクエストできるようにする必要があります。 検証ガイダンス: アプリが Managed Pricing または Billing API を使用し、課金の承認と拒否を適切に処理していることを確認してください。マーチャントが課金を拒否した場合にアプリが適切に対応すること、また、アプリの再インストール後にマーチャントがエラーなくプランに再登録できることを確認してください。

料金プランの変更を可能にする

説明: アプリでは、マーチャントがサポートチームへの問い合わせやアプリの再インストールをせずに、料金プランをアップグレードおよびダウングレードできるようにする必要があります。これには、マーチャントの管理画面にあるアプリ課金履歴ページで課金が正常に処理されることも含まれます。 検証ガイダンス: アプリに複数の料金プランがある場合、マーチャントが再インストールしたり開発者に問い合わせたりすることなく、Billing API または Managed Pricing を通じてアプリ内でプランを切り替えられることを確認してください。使用量に基づく自動的なプラン変更は許容されます。

Shopify API を使用する

説明: アプリがマーチャントに最適なサービスを提供できるよう、Shopify の API を使用するように設定する必要があります。Shopify API を使用せず、また必要ともしないアプリは許可されません。 検証ガイダンス: コードベースで、Shopify API クライアントの初期化、OAuth フロー、セッショントークンの使用、Admin API の呼び出しを検索してください。アプリが Shopify API と統合されておらず、Shopify API を必要とせずに単独で動作する場合は、カスタムアプリのインストールをユーザーに促したり、Shopify API キーやシークレットの設定を求めたりしていないことを確認してください。

インストール直後に認証する

説明: アプリは、ほかの手順を開始する前に OAuth を使用して直ちに認証する必要があります。マーチャントは OAuth の前にユーザーインターフェース(UI)を操作できてはなりません。 検証ガイダンス: インストールのエントリーポイントからアプリのインストールフローを追跡してください。アプリが、アプリ自体の認証情報に一致する正しい client_id とスコープを指定して、Shopify の OAuth 認証 URL(例:/admin/oauth/authorize)にリダイレクトすることを確認してください。別のアプリケーションの認証情報を使用していてはなりません。

管理画面の拡張機能にプロモーションや広告を表示しない

説明: アプリの宣伝、関連アプリの宣伝、レビューの依頼に 管理画面の UI ブロック、管理画面アクションや管理画面リンクを使用しないでください。 検証ガイダンス: 管理画面 UI 拡張機能の設定(admin.block.toml、admin.action.toml、admin.link.toml、または同等の拡張ターゲット)を検索し、表示される内容に宣伝文句、レビュー依頼のプロンプト、関連アプリの相互プロモーションが含まれていないか確認してください。

マーチャントの操作があった場合にのみ Max モーダルを起動する

説明: Max モーダル(以前はフルスクリーンモードと呼ばれていました)は、マーチャントの操作なしに起動してはなりません。Max モーダルをアプリのナビゲーションメニューから起動することはできません。 検証ガイダンス: コードベースで、フルスクリーンモードやフルスクリーン表示の ResourcePicker など、Max モーダル API の使用箇所を検索してください。Max モーダルが明示的なユーザー操作(例:ボタンのクリック)によってのみ起動され、ページ読み込み時やナビゲーションサイドバーのリンクハンドラーから自動的に開かないことを確認してください。

Shopify が所有するサーフェスからインストールを開始する

説明: アプリのインストールと開始は、Shopify のサービス上でのみ行う必要があります。インストールまたは設定のフロー中に、myshopify.com の URL やストアのドメインを手動で入力するようアプリが求めてはなりません。 検証ガイダンス: コードベースを検索し、「.myshopify.com」のドメイン、または myshopify URL の最初の識別部分(xxx.myshopify.com)を受け付ける、あるいは参照する入力フィールド、フォーム、URL パラメーターがないか確認します。ユーザーにストアの URL を手動で入力するよう求める UI がないか確認します。ストアの識別には、代わりに OAuth またはセッショントークンを使用する必要があります。

インストール後、直ちに認証する

説明: ほかの手順を実行する前に、アプリは OAuth を使用して直ちに認証する必要があります。OAuth を完了する前に、マーチャントがユーザーインターフェース(UI)を操作できてはなりません。 検証ガイダンス: インストールのエントリーポイントから、アプリのインストールフローをたどります。アプリが、アプリ独自の認証情報と一致する正しい client_id およびスコープを指定して、Shopify の OAuth 認証 URL(例:/admin/oauth/authorize)にリダイレクトすることを確認します。別のアプリケーションの認証情報ではないことも確認します。

インストール後、アプリの UI にリダイレクトする

説明: OAuth ハンドシェイクページで権限へのアクセスを承認した後、アプリはマーチャントをユーザーインターフェース(UI)にリダイレクトする必要があります。 検証ガイダンス: OAuth コールバックハンドラーをたどり、認証コードを受信してトークン交換を完了した後、アプリがユーザーをアプリのメイン UI のルートにリダイレクトすることを確認します。たとえば、埋め込みアプリの場合は Shopify Admin 内の埋め込みアプリ URL、埋め込みではない場合は外部ページにリダイレクトします。行き止まりや Shopify Admin のアプリインデックスページに遷移してはなりません。

再インストール後も OAuth 認証を直ちに必須とする

説明: アプリを再インストールする場合、マーチャントがアプリ内のワークフローに簡単に戻れるようにします。過去にアプリをインストールしてアンインストールしたことがある場合でも、ほかの手順を実行する前に、アプリはOAuthを使用して直ちに認証する必要があります。 検証ガイダンス: OAuth コールバックとセッション/トークンの保存ロジックを確認し、ストアのレコードがすでに存在する場合にもアプリが対応できることを確認します。既存のトークンが重複エントリーによるエラーを起こさず更新されること、また、インストールを一度限りとするフラグや一度限りのセットアップフローが再インストールを妨げないことを確認します。

有効な TLS/SSL 証明書を使用する

説明: クライアント(マーチャントのウェブブラウザーなど)とアプリサーバーの間で交換されるすべてのデータは、転送中のデータをアプリサーバーだけが読み取れるように、Transport Layer Security(TLS)を使用して暗号化する必要があります。TLS 証明書で保護されたウェブサイトでは、ブラウザーのアドレスバーに HTTPS と小さな南京錠アイコンが表示されます。アプリには、エラーのない有効な TLS/SSL 証明書が必要です。 検証ガイダンス: アプリのサーバー設定で TLS/SSL の構成を確認します。サーバーのエントリーポイント、SSL 証明書の環境変数、HTTPS へのリダイレクトミドルウェアを調べ、アプリが HTTPS で配信されることを確認します。埋め込みではないアプリの場合、HTTP のみを使用するフォールバックがないことを確認します。

必要なアプリ機能を提供する場合に限り、read_all_orders アクセススコープを要求する

説明: アプリが read_all_orders スコープにアクセスする場合、このスコープが必要であることを示す必要があります。 検証ガイダンス: 注文を取得する Shopify API 呼び出しを検索し、アプリが read_all_orders スコープを使用しているか、デフォルトの 60 日間の範囲を超えて注文を照会しているか確認します。過去の注文データを実際に必要とする分析、レポート、ロイヤルティ機能などをアプリが提供していることを確認します。

必要なアプリ機能を提供する場合に限り、write_payment_mandate スコープをリクエストしてください

説明: アプリが write_payment_mandate スコープにアクセスする場合、このスコープが必要であることを示す必要があります。 確認の指針: コードベースを検索し、後払いまたは購入オプション API の使用状況を確認します(例:後払い戦略を使った SellingPlanGroup の作成、予約購入または購入前お試しポリシー)。顧客が全額の支払いを先延ばしにできる販売フローをアプリが実装していることを確認します。

必要なアプリ機能を提供する場合に限り、write_checkout_extensions_apis スコープをリクエストしてください

説明: アプリが write_checkout_extensions_apis スコープにアクセスする場合、このスコープが必要であることを示す必要があります。 確認の指針: チェックアウト拡張機能のターゲットまたは購入後の拡張ポイント(例:purchase.thank-you、purchase.checkout、post_purchase)を検索します。アンケート、アップセルの案内、寄付など、チェックアウト後に顧客へ追加機能を提供していることを確認します。

必要なアプリ機能を提供する場合に限り、read_advanced_dom_pixel_events スコープをリクエストしてください

説明: アプリが read_advanced_dom_pixel_events スコープにアクセスする場合、このスコープが必要であることを示す必要があります。このスコープは、チェックアウトページでヒートマップまたはセッション録画機能を実装する場合にのみ使用してください。 確認の指針: read_advanced_dom_pixel_events スコープへの参照、および Web ピクセルやチェックアウトピクセルの実装を検索します。アプリが DOM レベルのピクセルイベントを処理し、UI でチェックアウトのヒートマップ表示またはセッションの録画/再生機能を提供していることを確認します。

read_checkout_extensions_chat スコープは必要な場合に限りリクエストしてください

説明: アプリが read_checkout_extensions_chat スコープにアクセスする場合、このスコープが必要であることを示す必要があります。 確認の指針: チェックアウトまたはサンキューページの拡張機能で、Chat UI コンポーネントが使用されているか検索します。チャットウィジェットが人間または AI サポートエージェントにつながり、顧客サポートのやり取りに用途が限定されていて、購入者が問い合わせを始める前に商品を積極的におすすめしないことを確認します。

出力形式

すべての要件を評価した後、以下の形式で結果をまとめた単一のレポートを作成してください。開発者に明確で実行可能な要約を示しつつ、情報を詰め込みすぎないことが目的です。合格した要件の詳細は記載せず、件数のみを示します。これは、レポートを焦点が明確で読みやすいものにするためです。コードベースへのアクセス不足や、プロジェクト構成が要件に関係しないために評価できなかった要件がある場合は、レポートの最後に別途記載してください。

概要

✅ 合格の可能性が高い: {number} ❌ 不合格の可能性が高い: {number} ⚠️ 要確認: {number}

注: エージェントは、Shopify がブラウザーのコンテキストなしでローカルのコードベースに照らして確認できるものとして選定した要件の一部をレビューしました。これらの要件を含め、その他の要件も Shopify App Store への提出時に Shopify が引き続き審査します。

⚠️ 要確認の要件

要確認の要件ごとに、各項目の間に改行を入れて以下を記載してください。

⚠️ 要件名

確認が必要な理由: 曖昧な点、コードだけでは判断できないこと、開発者が確認すべき内容を説明します。

検出された内容: この要件が該当する理由となるシグナルやパターン(または特に見当たらなかったもの)を説明します。

❌ 不合格の可能性が高い要件

不合格の可能性が高い要件ごとに、各項目の間に改行を入れて以下を記載してください。

❌ 要件名

重要な理由: コンプライアンス上のリスクを簡潔に説明します。

確認された内容: 検出された違反について、可能であれば該当するファイル、コードパターン、設定を挙げて簡潔に説明します。

リソース

すべての要件が合格見込みと評価されている場合を除き、レポートの最後に次の参考資料を含めてください。

コメント