Shopifyを安心して選べる理由｜セキュリティの仕組みと店舗の対策

Shopifyはセキュリティを重視するEC事業者に勧められるサービスです。カード情報を保護する専用の環境、購入画面の改ざんを防ぐ制限、基盤の更新と監視を、店舗ごとに一から用意せずに利用できます。これらの対策を開店後もShopifyが継続して担うことが、安全性の面で選ぶ大きな理由です。

特に、商品・販促・受注を兼任し、サーバーの保守や夜間の監視を担当する人がいない店舗では、この違いは実務に直結します。店舗は基盤の保守を任せながら、管理画面へ入る人、導入するアプリ、業務で使う顧客情報の管理に取り組めます。

安心して選べる理由を理解するには、認証マークに加えて、カード番号に触れる機能がどこまで分かれているか、購入画面へ入るコードを誰が管理するか、問題を見つけた後に誰が修正するかを見ると分かりやすくなります。以下は2026年10月時点の資料に基づき、Shopifyが提供するオンラインストアとShopify Checkoutを使う構成を中心に説明します。

開店後も続くセキュリティの仕事

ECサイトの安全性は制作時の設定だけでは保てません。ソフトウェアに新しい弱点が見つかれば修正が必要になり、追加した機能が別の問題を起こしていないかも確かめます。異常を知らせる通知が届いたときには、内容を調べ、被害が広がる前に対処できる担当者が必要です。

自社や制作会社でECソフトウェアを保守する場合、更新情報の収集、適用するバージョンの判断、動作確認、失敗時に戻す準備を続けます。保守契約がデザインの修正だけなら、こうした作業は別に用意しなければなりません。開店時に安全な構成でも、更新する人が決まっていなければ、その後に見つかった弱点への対応が遅れます。

Shopifyでは、Shopifyが管理する基盤の修正と更新を同社が担います。店舗が基盤の更新ファイルを探して、自店のサーバーへ適用する運用は必要ありません。購入画面やカード情報を扱う環境の保護も、その基盤に含まれます。

自社で保守する場合も、専門の会社へ適切に委託すれば安全性を維持できます。比較するときは、月額料金に加えて、誰が更新し、休日の異常に誰が対応する契約なのかまで含めると、必要な体制が見えてきます。Shopifyには、その基盤運用をサービスとして利用できる利点があります。

カード情報を店舗の通常業務から分ける仕組み

購入者は一つの購入画面で、氏名、配送先、カード情報を入力します。店舗の発送担当者には配送先が必要ですが、荷物を送るために完全なカード番号を読む必要はありません。Shopifyはこの用途の違いに合わせて情報の扱いを分けています。

通常の注文管理では、店舗は注文内容や決済の状態を使って受注業務を進めます。定期購入など、後の支払いに使う情報を保存する機能でも、店舗が入力後の完全なカード情報を取り出す仕組みにはなっていません。顧客名簿や発送用のシステムにカード番号を保存しなくても、販売を続けられます。

入力欄と周囲の画面を分ける

Shopifyが公開するカード処理の構成では、購入者はShopifyが提供するiframeへカード情報を入力します。iframeはページの中に別の画面を埋め込む仕組みです。カード入力欄を周囲の画面と分けることで、入力した値をページ全体へそのまま渡さずに処理できます。

店舗が用意した通常のフォームでカード番号を受け取り、自社のサーバーを通して決済先へ送る構成にすると、そのサーバーもカード情報を守る対象になります。Shopifyの入力機能を使えば、店舗自身がカード番号を受けるフォームや受付処理を作らずに済みます。保護が必要な情報を、業務に必要な範囲を超えて増やさない設計です。

受け付ける処理と復号する処理を分ける

カード入力欄の先でも、すべてを一つの処理に集めていません。入力を受け付ける処理はカード情報を暗号化して一時的に置き、次の処理へはそのデータを取り出すための識別子を渡します。情報を読める形へ戻す「復号」と、決済先への送信は、別の処理が担います。

この分け方には、暗号化された受け渡し用データに触れることと、カード番号を読めることを同じ権限にしない意味があります。仮に暗号化した一時データだけを取得されても、復号する機能にアクセスできなければ、そのままカード番号を読み取ることはできません。情報への入口を分け、必要な処理だけに必要な能力を持たせています。

受け渡しに使った一時データは、使用後または1時間以内に削除されます。決済の途中で必要だった情報を残し続けないための仕組みで、この期限は保存済みカード全体の保持期間とは別です。

保存する情報は専用の環境で管理する

Shopifyには、カード情報を保存・処理する専用の環境があります。一般のシステムと分離されており、保存対象として記載されているのはカード番号、有効期限、名義です。入力時に使うセキュリティコードは、この保存項目に含まれません。

入力欄の分離、暗号化した受け渡し、復号処理の分離、専用環境での保管を組み合わせることで、カード情報へ到達する経路を制限しています。店舗はその保管用サーバーやアクセス管理、不要になった受け渡し用データの削除処理を自前で作らずに、決済を受け付けられます。

ここで説明した経路はShopify PaymentsやShop Pay Walletなどを対象にしたShopifyのPCI DSS準拠証明書に基づきます。外部の決済サービスを追加する場合は、そのサービスが用意する入力画面と情報の扱いも合わせて確認します。

注文情報と外部に渡すデータの管理

カード情報を通常業務から分けても、氏名・住所・連絡先・注文履歴は発送や問い合わせ対応に必要です。これらはShopifyの管理画面で、権限を持つ人が利用します。メール配信や物流のアプリを導入すれば、許可した情報がそのサービスへ渡ることもあります。

カード情報を扱う専用環境と、店舗が業務で使う顧客情報は、利用する人や機能が異なります。CSVや外部アプリへ渡した情報には、その保存先での管理も必要です。

たとえば、メール配信アプリに顧客情報の利用を許可しても、専用のカード保管領域へ自由に入れるようにはなりません。一方で、配信のために渡した氏名やメールアドレスは、そのアプリ側でも守る必要があります。この区別が分かると、決済の保護をShopifyへ任せながら、店舗がどの情報を管理するかを具体的に決められます。

購入画面への追加コードを制限する理由

カード入力欄だけを分離しても、その周囲の画面が自由に書き換えられる状態では十分に守れません。周囲のページへ不正なコードが入り、正規のカード入力欄を偽物へ置き換えれば、購入者は偽物に情報を入力してしまうからです。

Shopifyはカード入力欄を囲むCheckout本体も管理しています。店舗やアプリが機能を追加するとき、そのコードに購入画面全体を直接操作する権限を渡す設計にはしていません。追加機能の実行範囲を制限することで、便利な機能を入れるたびに、カード入力欄を書き換えられる相手が増える状態を避けています。

拡張機能に渡す権限を絞る

購入画面へ案内表示などを加えるCheckout UI拡張は、sandboxと呼ばれる隔離された環境で動きます。Shopifyの技術説明では、iframeやWeb Workerを使い、独自のコードをCheckout本体から分けています。Web Workerは画面を直接操作する処理から切り離してコードを動かす仕組みです。

Checkout UI拡張が使えるのは、Shopifyが用意した画面部品と、許可された情報や操作を受け渡すAPIです。拡張からカードなどの機微な決済情報や、Checkout本体のHTMLへ直接アクセスすることはできません。拡張が表示を追加するときも、Shopifyが管理する通信経路を通します。

たとえば、購入画面へ案内文を表示する機能には、案内文を出すための部品があれば足ります。そのためにカード入力欄の中身を読む権限や、購入画面を丸ごと書き換える権限まで渡す必要はありません。必要な表示と、機能に与える権限を対応させる仕組みです。

カード入力用iframeは入力値を周囲の画面から分け、拡張用sandboxは追加コードの動ける範囲を制限します。両方をCheckout本体の管理と組み合わせます。

Checkout本体のコードを管理する

隔離した拡張のほかに、Checkout本体で動くコードも守らなければなりません。Shopifyは利用するコードの審査と更新、読み込むスクリプトの把握、変更管理を行うと説明しています。

技術的には、許可していないスクリプトの実行を制限するCSPや、読み込んだファイルが想定した内容から変わっていないかを照合するSRIなどを使います。CSPには違反を報告する機能もあり、実行を制限することと、不審な状態を把握することを組み合わせています。

店舗が自前の購入画面を作るなら、カード入力の仕組みだけでなく、周囲へ読み込むコードの一覧、更新、改ざん対策まで維持する必要があります。Shopify Checkoutでは、その仕事をShopifyが担います。自由にコードを入れられない制約はありますが、その制約があるからこそ、同社が購入画面全体の保護を管理できます。

購入画面をカスタマイズするときは、対応する拡張機能で必要な表示や操作を実現できるかを制作会社と検討します。情報・配送・支払いステップのUI拡張にはShopify Plusが必要ですが、Checkout本体を保護する仕組みは、UI拡張を導入した店舗だけのものではありません。

更新・アクセス管理・監視を続ける体制

安全な構造を作っても、ソフトウェアの弱点を放置したり、運用担当者の権限が必要以上に広がったりすれば、防御は弱まります。Shopifyは基盤の更新、内部のアクセス管理、変更の審査、異常の監視と対応を、サービス運用の仕事として続けています。

弱点を調べ、修正を反映する

Shopifyは脆弱性の評価と侵入テストを行い、発見した問題を調査して、必要な修正を追跡しています。脆弱性は攻撃に使われ得るソフトウェアや設定の弱点です。侵入テストは実際の攻撃を想定した方法で、防御を破れる箇所がないか調べる検査です。

基盤の修正やセキュリティ更新はShopifyが継続して適用します。店舗ごとに基盤の更新判断や適用作業を抱えないため、「修正が提供されているのに、自店では更新する担当が決まらない」という遅れを避けやすくなります。購入画面で使う外部のコードについても、審査と更新がShopifyの管理に含まれます。

更新そのものが別の不具合を起こすことにも備えています。Shopifyは本番への反映前のテストに加え、変更のレビュー、承認、展開、問題があったときの差し戻しを管理しています。新しい修正を入れることと、その変更で販売や情報の扱いに問題が生じないかを確かめることを、一組の作業にしています。

Shopify内部からのアクセスも管理する

基盤を扱う従業員にも、認証と権限の制限があります。公開SOC 3レポートには、従業員の多要素認証、本番環境で必要な範囲に絞ったアクセス、定期的な権限の見直し、退職時のアクセス削除が記されています。

多要素認証はパスワードだけを知られた場合の侵入を抑えるためのものです。必要な範囲に権限を絞れば、ある担当者のアカウントが使われても、その人の仕事に不要な情報や機能まで自由に操作される範囲を狭められます。異動や退職に合わせて権限を見直すことで、以前の仕事で必要だったアクセスが残り続けることも防ぎます。

カード環境を分ける技術と、その環境へ入れる人を管理する運用は、両方が必要です。Shopifyでは、店舗が使う管理画面の認証だけでなく、サービスを運用する側のアクセスも管理対象にしています。

通知を人が評価し、解決まで追う

Shopifyはシステムのログを集約して関連付け、自動アラートにつなげる運用を公表しています。24時間の当番がアラートを評価し、重大な事案では対応手順を開始して、解決まで追跡します。

監視で通知を出しても、誰も内容を調べなければ対処は進みません。何が起きたかを評価する人と、緩和・調査・対応の手順があることで、検知した後の仕事までつながります。店舗がShopifyの基盤を利用する場合、この当番体制や基盤内部の調査手順を、自店のために一から用意する必要はありません。

これは、商品を登録できる場所を借りることに加えて、基盤の弱点を調べ、修正し、異常に対応する継続的な運用を利用するということです。専任の技術担当者がいない店舗でも、この運用を前提に販売を始められる点を、Shopifyの強みとして評価できます。

第三者評価と外部からの問題報告

Shopifyの対策は提供者自身の説明に加えて、外部から評価を受ける仕組みでも確認できます。カード情報の環境を評価するPCI DSS、一定期間の管理状況を評価するSOC、外部研究者が問題を報告するバグ報奨金制度には、それぞれ異なる役割があります。

カード情報の保護を評価するPCI DSS

PCI DSSはカード情報を保存・処理・送信する環境のセキュリティ基準です。ShopifyはLevel 1の準拠を公表し、専門の評価機関による年次評価と、四半期ごとの外部脆弱性スキャンを受けています。Level 1は評価区分の名称であり、サービスを安全な順に並べた順位ではありません。

店舗にとっての価値は、カード情報を扱う環境の対策と評価を、Shopifyの決済基盤として利用できることです。カード保管環境を自前で設計し、その保護と評価を維持する範囲を減らせます。Shopifyの公開資料では、入力から保管までの構成も確認できるため、認証名に加えて、その対象を社内の導入審査へ示せます。

一定期間の運用を評価するSOC

SOC 3には、対象サービスのセキュリティなどに関する管理が、定めた期間にわたって有効に働いていたかについて、独立監査人の意見が含まれます。公開されているレポートの対象期間は、2025年4月から2026年3月です。

方針としてアクセス制限や監視を掲げるだけでなく、一定期間の管理を外部が評価する点に意味があります。自社でサービスを選ぶ担当者も、対象と期間を持つ資料を確認し、社内で求められる安全管理と照らし合わせられます。レポートはShopifyの公式一覧から案内されています。

外部研究者から弱点を受け付ける

定期的な評価のほかに、Shopifyはバグ報奨金制度を設けています。外部の研究者が、許可されていない個人情報へのアクセス、権限の不備、権限昇格などの弱点を報告できる窓口です。対象と報告方法を定め、サービスの外から見つかった問題も調査・修正へつなげます。

Shopifyは問題を報告した外部研究者へ継続して報奨金を支払っています。公式のバグ報奨金ページで公表している実際の支払額は、2026年10月18日時点で次の規模です。

重大な脆弱性には影響度に応じて最大20万ドルの報奨額を設定しています。報告を受けると、問題を再現して有効性を確認し、影響を評価して報奨額を決めます。その後、開発担当が修正し、再テストで問題が解消されたかを確かめます。

外部の専門家による発見を、修正と再テストまでつなげる活動を続けています。定期的な評価に加え、研究者の参加を報奨金で支える仕組みがあることも、Shopifyを選ぶ理由になります。

他の管理型ECサービスにも、PCI DSSへの準拠や基盤の保守を提供するものがあります。選ぶ際は、自店に必要な安全管理を満たすことに加え、標準機能でどこまで運営できるかを比べてください。Shopifyの標準機能で要件を満たせる店舗では、独自に保守する部分を増やさずに、ここまでの保護と運用を利用できます。

店舗が続ける認証・権限・データの管理

基盤の保護を利用しながら、店舗では「誰が管理画面へ入るか」「何の情報を外へ渡すか」を管理します。発送や問い合わせのために正規の権限で使える情報は、アカウントを奪われたり、不要な相手へ権限を残したりすると、そこから持ち出される可能性があるためです。

ログインを守り、復旧手段も用意する

オーナーとスタッフは、それぞれのアカウントを使います。オーナーのパスワードを共有する運用をやめれば、担当者ごとに権限を決め、退職時にはその人のアクセスだけを外せます。

個人のプロフィールから［セキュリティ］を開き、利用できる端末でパスキーを設定します。パスキーは顔認証や指紋認証などを使ってパスワードの代わりにログインする仕組みです。［パスキー］から作成を進め、作成後に同じ欄で登録と保存先を確認します。端末を失ったときに備え、予備のパスキーや別の認証手段も用意してください。パスキーの設定手順

Shopifyではパスキーと二段階認証は別の設定です。同じ個人アカウントのセキュリティ設定で二段階認証も設定し、復旧コードを、認証用の端末を失っても取り出せる安全な場所へ保管します。ログイン用メールにも二段階認証を設定し、不審な転送設定がないかを確認してください。メールはアカウントの復旧と重要な通知に使われます。

スタッフの設定は、権限を持つ人が［設定］→［ユーザー］→対象ユーザーを開き、安全なサインイン方法を必須にする項目を確認します。必須に変更すると対象者がログアウトするため、作業の区切りを合わせて実施します。Plusでは全ユーザーへの必須設定も利用できます。画面の表記や設定できる範囲は、管理画面の更新やプランによって異なります。

仕事に必要な権限だけを渡す

［設定］→［ユーザー］で、スタッフのロールと許可する操作を確認します。たとえば問い合わせ担当者に顧客情報の閲覧が必要でも、全顧客をCSVへ書き出す権限まで必須とは限りません。顧客情報の閲覧とエクスポートは別の権限として判断できます。

発送補助の担当者なら、発送に必要な注文操作を基準に権限を選びます。アプリの導入やテーマ編集まで担当するのかは別に決め、異動・退職時には権限を変更し、不要なアクセスを削除します。これは役割を決める例なので、実際に必要な操作は各担当者と合わせてください。

制作会社にはコラボレーターとしてアクセスしてもらい、依頼した相手と要求権限を確認して承認します。作業や保守が終わったら、既存のアクセスを外します。コラボレーターの申請コードを変えるだけでは、承認済みのアクセスは消えません。

アプリとCSVの保存先を把握する

［設定］→［アプリ］→対象アプリでは、アクセスできる領域や、閲覧・編集の権限、扱う個人データを確認できます。メール配信に使うなら、メールアドレスだけで足りるのか、住所や注文履歴も使う機能なのかを、利用目的と照らし合わせます。保存先と解約後の削除条件は、提供元の案内やプライバシーポリシーで確認し、不明なら導入前に問い合わせます。

使わないアプリは季節業務などで必要なものかを担当者に確かめたうえで連携を止めて削除します。外部に保存された顧客情報の削除と、テーマに残った追加コードの整理は、提供元や制作会社にも確認してください。

CSVを書き出す場合は、そのコピーの共有者と保存期間を決めます。たとえば配信先の登録に使う作業用CSVなら、必要な項目だけを用意し、担当者だけが開ける場所へ置き、登録結果を確認した後に作業用コピーを削除する運用が考えられます。外部の顧客管理システムに残すデータは、別に保存期間と削除担当を決めます。法令上の保存が必要な記録や、事故調査の証拠まで一律に削除するものではありません。

独自に作った部分には保守担当を置く

独自フォーム、外部の顧客管理システム、標準テーマとは別にサイトを作るHeadless構成を採用する場合は、そのサーバーやログイン処理、保存データ、外部CMSにも保守が必要です。Shopifyの基盤更新と、自社が追加した機能の更新は分けて担当を決めます。ドメインの管理アカウントと更新通知も、店舗が把握できる状態にしておきます。

制作会社への確認には、次のような依頼文を使えます。

独自フォームと外部連携について、どの顧客情報を、どこへ送り、どこに保存しているかを一覧にしてください。各システムの更新担当と事故時の連絡先も記載してください。独自アプリの権限が必要な範囲に限られているか、秘密のトークンが購入者のブラウザーやログへ出ていないか、漏えい時に失効・再発行できるかも確認をお願いします。秘密の値そのものは報告書に記載しないでください。

万が一、Shopify側から漏えいの通知が届いたとき

万一に備え、通知を受けたときの確認先と対応の担当を決めておきます。Shopify側の問題による漏えいでは、基盤内部の調査・修復をShopifyが担い、店舗は自店の顧客への影響を確かめて必要な連絡を進めます。

影響の調査、被害拡大の防止、報告期限の管理は、必要に応じて並行して進めます。調査の全容が分かるまで、ほかの対応を待つ流れではありません。

公式窓口で影響を確認する

通知メールのリンクからすぐにログインせず、普段使う管理画面や公式サポートを自分で開き、通知が本物か、自店が対象かを確かめます。受信日時、対象ストア、受付番号を記録し、社内の連絡担当を決めます。

提供元への問い合わせでは、対応を決めるために次の情報を確認します。以下は問い合わせの文例です。

当店が対象であるか、影響した期間、情報の項目、対象人数、閲覧または持ち出しが確認された範囲を教えてください。カード番号などの決済情報と、氏名・住所・注文履歴は分けて回答をお願いします。

危険が現在も続いているか、当店で停止すべき処理や変更すべき認証情報があるかも確認したいです。貴社が実施する通知・対応の範囲と、当店が行うべき対応、次の情報更新をいつ予定しているかもご案内ください。

通知、取得できるログ、設定の変更履歴、誰がいつ何を実施したかを残します。不審なファイルやログをまとめて削除すると、原因を調べる手がかりも失われます。記録を保存する場所の閲覧権限も限定してください。

被害が続く経路を止める

不正なアクセスが続いている場合は、提供元や開発担当と、影響する連携の停止、アカウントのアクセス削除、漏れた認証情報の失効などを進めます。証拠を残すことと被害拡大を止めることは並行して判断し、全容の解明まで危険な経路を残さないようにします。

自店のアカウントを奪われた疑いがあれば、その点もShopifyサポートへ伝え、Shopifyとログイン用メールの認証、不審なログインや設定変更を確認します。基盤内部の問題ならShopifyに修復を求め、自店では受け取った通知に基づいて必要な措置を進めます。止める範囲は、影響する情報と継続中の危険に合わせて決めます。

報告と顧客への通知を進める

日本の個人情報保護法では、一定の漏えい等、またはそのおそれがある場合に、個人情報保護委員会（PPC）等への報告と本人への通知が必要です。対象は、要配慮個人情報を含む場合、財産的被害のおそれがある場合、不正目的の行為によるおそれがある場合、本人の数が1,000人を超える場合の4類型です。不正アクセスによる漏えいなどは、人数が少なくても対象になり得ます。

起算をShopifyの最終報告まで待つものではありません。法人では、いずれかの部署が報告対象の事態を知った時点が基準になります。情報の暗号化状態や委託関係、報告先、本人通知が困難な場合の扱いは、PPCのガイドラインに沿って、実際の事案ごとに法務担当者や専門家と判断します。

提供元から通知が来た場合も、店舗と提供元のどちらが報告・本人通知を担うかを明確にします。所定の条件で委託先から委託元へ通知し、委託元が対応する制度もあるためです。顧客への案内には、対象の情報、分かっている原因と影響、二次被害への注意、問い合わせ先を載せます。確認できた事項と調査中の事項を分けて伝えてください。

カード情報が関係する場合の連絡先

カード情報の漏えいが発生した、または疑われる場合は、利用している決済事業者や加盟店契約会社へ速やかに連絡し、必要な調査と決済停止の範囲、顧客への案内を確認します。行政への報告とは別に、決済契約上の連絡を進めます。

カードの再発行などの案内は対象になった情報と決済事業者の判断に合わせます。氏名・住所の漏えいだけを確認した段階で、カード番号も漏れたと案内しないようにしてください。

導入時に決めておきたい運用の範囲

Shopifyはカード情報を扱う機能の分離と購入画面の保護に、更新、監視、問題の修正、外部評価を組み合わせています。店舗がその基盤運用を個別に作り、維持し続けなくてよい点から、安全性を重視する導入・移行先として勧められます。

導入を決めるときは、販売要件をShopifyの標準機能で満たせる範囲と、独自に作る必要がある範囲に分けてください。そのうえで、管理画面へ入る人、顧客情報を渡すアプリと保存先、独自部分の保守担当、事故時の連絡先を一覧にします。制作会社へ依頼する場合も、この一覧を共有すると、開店後に誰が何を続けるかまで決められます。

すでに運営している店舗なら、オーナーとスタッフの認証、不要な権限、使っていないアプリ、保存先が不明なCSVから確認できます。Shopifyが維持する基盤の保護を利用し、自店の人とデータの管理を具体的な仕事として続けることが、安心して運営するための現実的な方法です。

参考資料

• Shopify：セキュリティとコンプライアンスのレポート一覧
• Shopify Developers：Checkout UI拡張のセキュリティ
• 個人情報保護委員会：漏えい等の対応と報告先
• PCI SSC：カード情報侵害時の連絡先に関するFAQ