Shopifyは、通信の暗号化、カード情報を保護するPCI DSSへの準拠、アプリのセキュリティ審査などの対策を備えています。第三者による評価や、外部研究者から脆弱性の報告を受け付ける制度も、安全性を確認するための根拠になります。
導入時には、これらの保護が自社の扱うデータや利用する決済・アプリに適用されるかを確認しましょう。認証や権限の設定、発送前の注文確認など、自社で行う対応もあります。不正決済への対策と損失の補償は、対象や利用条件が異なります。
この記事では、Shopify本体・決済・アプリの保護範囲と、導入前に確認したい条件を解説します。RuffRuffアプリ独自の設計・運用も具体例として紹介します。
Shopifyの保護範囲と導入前に確認したいこと
導入判断では、提供される対策と、自社で管理する範囲を確認しましょう。決済方法やアプリによって条件が異なるため、次の項目を分けて確認すると整理しやすくなります。
| 対象 | Shopifyが提供する対策・手段 | 導入前に確認すること |
|---|---|---|
| カード情報・通信 | PCI DSS準拠の決済基盤、TLSによる暗号化 | 自社で扱うデータや外部サービスも含め、保護の対象範囲を確認する |
| 不正注文・チャージバック | 不正分析、条件付きのブロックや補償 | 利用する決済方法の不正対策と、補償の対象条件を確認する |
| アプリ経由のデータアクセス | App Store審査、権限・データ保護の要件 | 利用予定アプリの権限と、提供元の保存・削除・保守方針を確認する |
| 管理画面への不正ログイン | 二段階認証・パスキー・権限設定 | 誰が管理画面を使い、どの認証方法・権限で運用するか |
| 誤削除・設定変更 | CSV書き出しやテーマ保存などの手段 | どのデータを保存し、どこまで復元できるかを確認する |
Shopify本体の保護と第三者による評価
Shopifyの安全性を確認する根拠には、カード情報の保護基準への準拠、第三者の評価レポート、公開されている技術・運用上の対策があります。それぞれが対象とするデータやサービスの範囲を確認しましょう。
PCI DSSへの準拠とSOCレポート
Shopifyは、カード情報を保護するための国際的な基準であるPCI DSSのレベル1に準拠していると公表しています。2026年の準拠証明書はPCI DSS v4.0.1に基づき、Shopify Payments、オンラインストア、Shop Payのウォレットなどを対象としています。
また、情報システムの管理体制や運用を第三者が評価した、SOC 2 Type IIとSOC 3のレポートを取得しています。公開SOC 3レポートの対象期間は2025年4月1日〜2026年3月31日です。ストアが独自に接続したシステムも含めて、将来の無事故を保証するものではありません。
TLSによる通信の暗号化
Shopify管理画面やストアとの通信には、データの盗み見や改ざんを防ぐための暗号化技術であるTLSが使われています。ShopifyはTLS 1.2以上をサポートしています。
Shopifyに追加したドメインには、TLS証明書が無料で自動提供されます。外部サービスで取得したドメインは、証明書の発行に最大48時間かかる場合があります。外部から読み込む画像などもHTTPSで配信し、安全な接続を妨げない設定にする必要があります。
脆弱性評価・変更管理・攻撃への防御
Shopifyは、個人データを保護する取り組みとして、必要な担当者へのアクセス制限、脆弱性評価や侵入テスト、システム変更の記録・試験・承認を説明しています。障害復旧、事業継続、セキュリティ事故への対応計画も整備しています。
オンラインストアには、攻撃的な通信を検査するWAFと、大量の通信でサービスを停止させるDDoS攻撃への防御が常時適用されます。Shopifyのボット対策の案内では、これらの保護にストア側の操作は不要と説明されています。
問い合わせ・コメントフォームやお客様アカウントのスパム対策には、既定で有効になっているhCaptchaも使われます。これらとは別に、販売イベント時のチェックアウトに対する追加のボット保護はShopify Plus限定です。
Shopify Payments・Shop Payの決済セキュリティ
Shopify Paymentsには、不正決済への対策と注文のリスク確認を支援する機能があります。疑わしい注文の発送判断はストア側で行い、チャージバックの補償は別に対象条件を確認します。
カード情報の保護と3Dセキュア
Shopify PaymentsやShop Payには、PCI DSSへの準拠を含むカード情報の保護が適用されます。一方、ストア運営者にも、アカウントのアクセス管理やカードのセキュリティコードを保存しないことなど、Shopify Paymentsの規約に沿った対応が必要です。
Shopify Paymentsでは、カード発行会社や規制上の要件、高リスクと判断された状況などに応じて、3Dセキュアによる本人認証が自動的に使われます。すべての決済で追加認証画面が表示される仕組みではありません。認証済みの取引は一般に不正利用に関するチャージバックの責任移転の対象となりますが、例外があり、商品未着などを含むすべての争議で免責されるわけではありません。
不正分析・カードテスティング対策・ルールによる制御
Shopify Paymentsには、盗まれたカード情報を少額決済などで試すカードテスティングへの対策が組み込まれています。また、不正分析は、対象となるオンラインのカード注文について、発送前の確認に役立つリスク情報を提示します。分析結果は不正を確定する判定や損失の補償ではないため、ストア側で注文内容を確認する必要があります。
Fraud Controlは、Shopify Paymentsの提供地域で全ストアプランに対応し、不正に関する分析情報を表示します。Shopify Paymentsを使っていない場合は一部のデータを確認できません。
Shopify Paymentsを利用するストアでは、条件に合うチェックアウトをブロックするルールも利用できます。正当な注文まで止める可能性があるため、条件を確認して設定しましょう。発送前の具体的な確認方法は、以下の記事で紹介しています。
Shopify Protectの機能と補償の条件
Shopifyは、2026年10月28日の発表で、不正の防止、リスクの説明、チャージバックへの回答支援などをまとめた取り組みとしてShopify Protectを紹介しました。発表には提供予定の機能も含まれるため、新しい機能の利用可否は各機能の案内で確認してください。
Fall ’26 Editionsでは、決済承認前の高リスク注文のブロックや、証拠の追加・AIによるチャージバック回答の作成支援が紹介されています。不正対策ルールのカスタマイズや、Shop Pay以外の注文へのチャージバック保護の拡大には、提供予定の案内も含まれます。日本のストアでの利用可否や補償条件は、各機能の最新案内を確認してください。
注文の金銭的な補償には、別途条件があります。注文保護に関するヘルプでは、米国に所在し米国のShopify Paymentsアカウントを持つこと、対象のShop Pay注文であることなどが条件として示されています。配送が必要な物理商品、対応する追跡情報、注文から7日以内の発送処理と10日以内の輸送開始なども必要です。
デジタル商品や店頭受取の商品を含む注文、Shop Payの分割払い、定期購入の2回目以降などは対象外です。保護された注文で対象の不正チャージバックが起きた場合には、金額と関連手数料が補償されます。
日本に所在するストアがShop Payを有効にしても、この補償に自動加入するわけではありません。適用の可否は、個々の注文のProtectステータスと最新条件で確認します。
Shopifyがアプリへ求めるセキュリティ要件
アプリを選ぶ際は、インストール時に求められる権限と、提供元のデータ取扱方針を確認しましょう。Shopify App Storeには公開前の審査があり、公開後も開発者にセキュリティ対策が求められます。
公開前の審査と必要最小限のデータアクセス
Shopify App Storeで公開するアプリには、セキュリティの最低要件が設けられています。代表的な確認項目には、一般的な脆弱性への対策、TLSの利用、不要なポートの公開防止、認証トークンの安全な生成・取り扱いなどがあります。公開前の審査に加え、公開後も開発者が対策を維持する必要があります。
アプリが保護されたお客様データへアクセスする場合には、データの最小化や利用目的の限定、保存・通信の保護などが求められます。公開アプリが氏名・住所・メールアドレス・電話番号を利用する場合は、それぞれ申請が必要です。アクセスするデータの区分に応じて、バックアップの暗号化やアクセス記録、事故対応の方針などの要件もあります。
データ開示・削除の要求とリクエストの認証
App Storeで配布するアプリには、個人データを収集しているかにかかわらず、お客様データの開示要求・削除要求・ストアデータの削除に対応する通知の実装が必要です。開発者は通知の署名を検証し、自社が扱うデータについて要求に対応します。
アプリからデータを参照・更新する際も、リクエストの正当性を検証する必要があります。Shopifyは各リクエストの認証を案内し、認証したストアに属するデータだけを扱う設計を求めています。削除の対象となるデータや手順は、アプリ提供元の説明でも確認しましょう。
導入後の運用に向けて自社で準備すること
導入前に、管理画面を使う人、利用するアプリ、注文を確認・発送する人を整理しておきましょう。Shopifyの保護機能を使うための設定と、日々の運用を担う担当者を決めておくと、導入後に必要な作業を把握できます。
二段階認証と予備のログイン手段を設定する
Shopifyは、パスワードに加えて別の手段で本人確認を行う二段階認証を提供しています。Shopify Paymentsで決済を受け付けるには二段階認証の有効化が必要です。SMSは新しい認証方法として設定できず、既にSMSを設定しているアカウントでは継続利用できます。
顔認証や指紋認証などでログインできるパスキーは、パスワードの代わりになる仕組みです。二段階認証とは設定が分かれており、Shopifyはパスキーに加えて二段階認証も設定するよう案内しています。端末を失ったときに備え、予備の認証手段や復旧コードも用意しましょう。
認証アプリを使った二段階認証の設定手順は、以下の記事をご覧ください。
スタッフの権限と操作ログを確認する
スタッフには業務に必要な権限を付与し、退職や担当変更に合わせて見直します。Shopify Plusの組織向け機能には、組織全体に安全なログイン方法を求める機能や、社内の認証基盤と連携してログイン・ユーザー管理を行う機能があります。
設定の変更やアプリへの権限付与を調べる際には、ストアの操作ログも役立ちます。新しい操作ログは段階的に提供されており、表示できる内容や利用条件はストアの状況に応じて確認してください。
アプリ・注文・バックアップの運用を決める
導入するアプリは、権限と提供元のセキュリティ方針を確認します。運用開始後も、Shopify管理画面に表示される案内を確認しましょう。使っていないアプリは必要性を見直し、削除する場合はデータや機能への影響も調べましょう。
注文は発送前にリスク情報を確認し、疑わしい場合の本人確認や注文保留の手順を決めておきます。商品やテーマの誤削除に備え、必要なデータをバックアップしておきましょう。サーバーの冗長化と、誤操作したデータを戻すための備えはそれぞれ必要です。
手動でのバックアップ方法とアプリの選び方は、以下の記事で解説しています。
RuffRuffはShopifyの要件に加えて独自の対策を実施
弊社・株式会社Tsunが提供するRuffRuffの7アプリでも、Shopifyが求めるセキュリティ要件への対応に加え、自社で定めた設計・運用上の対策を行っています。取り扱うデータや開発・本番運用の方針は、RuffRuffのセキュリティへの取り組みで公表しています。
保存するデータを減らし、必要な権限に限定する
RuffRuffでは、機能に必要な範囲にAPI権限を限定し、1時間で期限が切れるアクセストークンやIP許可リストを利用しています。これらはShopifyの要件に対応する取り組みです。
設計面では、お客様の氏名・住所・メールアドレス・電話番号やカード情報をTsunのサーバーに保存しない方針を採用しています。アプリの設定はShopify内に保存し、動作に使う設定には、そのアプリだけが書き換えられる専用のメタフィールドを使っています。機能に必要なデータを参照することと、Tsunのサーバーへ保存することは異なります。
継続的な検査と本番アクセスの制限
開発・運用では、変更時に公式のセキュリティチェックを実行し、定期的にAIを使った詳しいレビューも行っています。アプリで利用する外部プログラムの脆弱性通知を受けて影響に応じて更新し、公表された脆弱性について自社アプリへの影響を調べ、影響がない場合も告知する方針です。
本番環境は通常のアカウントから操作できない構成とし、承認された担当者が専用アカウントで必要な時間だけアクセスします。社内のAIツールへ本番環境のログイン情報を渡さない方針も定めています。
アンインストールされたストアのデータはアプリのデータベースから削除します。注文制限アプリがShopify内に記録するお客様ごとの累計購入データは、お客様データの削除依頼に合わせて削除します。アプリを選ぶ際には、Shopifyの要件への対応とともに、提供元がどのデータをどこに保存し、どのように検査や事故対応を行うかを確認すると判断しやすくなります。
バグバウンティで外部研究者と脆弱性を改善する
Shopifyは、外部の研究者が発見した脆弱性の報告を受け付け、条件に応じて報奨金を支払うバグバウンティ制度を運営しています。2026年11月13日時点で公表されている最大報奨金は20万米ドルです。報告はHackerOneを通じて受け付け、影響や条件に基づいて評価されます。
公表されている対応の流れには、報告内容の再現や重複の確認、影響評価、報奨金の判断、修正、再テストなどがあります。外部からの指摘を受けて継続的に改善するための仕組みです。
Shopify製アプリと第三者のアプリでは報告先や対象条件が異なります。制度の条件では、第三者アプリの問題はまず開発者へ報告し、1週間応答がない場合にShopifyへ報告できるとしています。第三者アプリの脆弱性に報奨金は支払われません。検証は制度の条件に従って自分で作成したストアに限定され、他者のストアへのアクセスや操作は禁止されています。
アプリ開発者に求められる対策の強化
Shopifyは、公開後のアプリについても要件を強化しています。以下は開発者が対応する内容で、ストア側では利用予定アプリの対応状況を提供元の案内などで確認します。
IP許可リストと期限付きアクセストークン
Shopifyは、アプリがストアのデータを読み書きするためのAdmin APIへの接続について、防御を強化しています。IP許可リストは、APIへの接続元を登録したアドレスやネットワークに限定する機能です。
期限付きアクセストークンは、APIへのアクセスに使う認証情報に有効期限を設け、漏えいした情報が使われ続けるリスクを抑える仕組みです。アプリを開いていない間の処理に使うオフラインアクセストークンについても、期限付きのものへの移行が求められています。
これらは開発者が対応する要件です。ストア運営者は、Shopify管理画面のアプリ設定に表示される対応状況や提供元の案内を確認します。
2026年11月13日時点のIP許可リストの必須化告知と、期限付きオフラインアクセストークンへの移行告知では、次の日程が示されています。
| 施策 | 主な対象 | 期限・対応 |
|---|---|---|
| IP許可リスト | Admin APIを呼ぶ公開アプリ | 2026年11月20日23:59 ET。日本時間は11月21日13:59 |
| IP許可リストの先行適用 | データの一括処理（Bulk操作）を利用する公開アプリ | 2026年11月12日23:59 ET。日本時間は11月13日13:59。未対応の場合、Bulk操作がブロックされる |
| 期限付きオフラインアクセストークン | 移行期限の対象となる既存の公開アプリ | 2027年1月1日が移行期限。2026年4月1日以降に作成された対象公開アプリでは既に必須 |
未対応アプリには、掲載停止や新規インストール停止などの措置が段階的に予定されています。既存インストールに対する対象Admin APIのリクエスト失敗は2027年4月1日からで、Bulk操作には先行した制限があります。期限付きトークンの移行告知では、カスタムアプリやストア運営者が作成したアプリは対象外とされています。
また、Shopifyは公式のセキュリティチェックを開発者に案内しています。コードを機械的に調べる検査と、実装内容を判断するエージェントレビューを組み合わせるツールです。利用は開発を支援する取り組みであり、すべての公開アプリが同じ検査を受けたという意味ではありません。
ストアにスクリプトを追加する旧方式の廃止
Shopifyは、アプリがストアにJavaScriptを読み込む旧方式であるScriptTagの廃止も進めています。2026年10月1日から新規作成・更新ができなくなり、既存のScriptTagも2027年3月1日にストアフロントへ挿入されなくなります。
開発者には、用途に応じてテーマアプリ拡張機能やウェブピクセルへの移行が案内されています。テーマアプリ拡張機能のアプリ埋め込みは、テーマエディタから動作の有無を確認し、有効・無効を切り替えられます。ストア運営者は、利用アプリの提供元に移行の要否と、公開テーマで必要な設定を確認しましょう。
通信先の宣言と開発者の本人確認
2026年10月のアプリセキュリティ更新では、アプリが利用する通信先などを宣言する設定が案内されました。開発者の本人確認も強化され、開発ストアやクライアント移行ストアへのアプリのインストール前に行うとされています。
11月4日に案内された開発ストア向けの検証プレビューでは、未申告の通信に警告を出します。検証時に通信を遮断する機能ではありません。また、開発者の本人確認とコードの安全性の審査は別の手続きです。
導入判断に必要な自社の条件を整理する
利用する決済方法とアプリ、扱うデータの種類、管理画面を使う担当者を整理し、それぞれの保護範囲や利用条件を確認しましょう。社内規定で必要な監査資料やデータの保管条件がある場合は、採用する構成で満たせるかを導入前に確認します。
標準の対策で対応できる範囲と、自社やアプリ提供元が担う作業を把握すると、導入後の運用負担も検討できます。サーバー費用や障害時の確認手順は、以下の記事で紹介しています。
