Shopifyのセキュリティ対策｜店舗側の責任と点検項目

2026年10月2日

公開日: 2026年10月2日

公式ドキュメント・公式発表などの一次情報を確認したうえで、株式会社Nexaが執筆・更新しています。AIツールの仕様や料金は変わることがあるため、導入判断の前に各公式サイトの最新情報もご確認ください。運営会社について

Shopifyのセキュリティは、基盤の保護だけで判断せず、店舗側が担う認証、権限、アプリ、個人情報、決済の5領域を分けて点検します。

基盤と責任: ShopifyはPCI DSSレベル1に準拠しますが、店舗側の個人情報管理も必要です。
アクセス管理: パスキーや二段階認証でログインを守り、担当業務に必要な権限だけを付与します。
連携と決済: アプリの個人情報アクセスと、不正解析を踏まえた発送判断を別々に確認します。

対象読者：EC責任者、店舗管理者。

今日やること: 管理者の認証方法と、退職者や外注先の残存権限を確認します。

この記事の著者

株式会社Nexa 代表取締役川島陸

一橋大学経済学部卒業後、フォーティエンスコンサルティング株式会社（旧株式会社クニエ）にて法人向けAI導入支援等を経験。独立後、AI系メディア運営やDify/n8nの導入支援を経て、株式会社Nexaを創業。法人向けAI研修・AI導入支援・AI関連メディア運営を手掛ける。

詳しく見る AI顧問の無料相談

Shopifyのセキュリティ対策は、サービス側の保護と、自社で管理する運用を分けることから始まります。基盤が保護されていても、共有アカウントや不要なアプリ、持ち出した顧客情報まで管理が済むわけではありません。

では、店舗側の責任はどこに残るのでしょうか。公式情報をもとに、設定の確認事項と担当者を整理します。早見表と点検リストを使い、自社で不足している管理を洗い出してください。

公式情報の確認日：2026年10月2日に公式ページで確認。 管理画面の実機検証ではなく、公開ドキュメントに基づく解説です。画面表示や利用条件は契約と最新の公式案内で確認してください。以下の5領域、10項目、運用頻度は編集上の整理と提案例です。

Shopifyのセキュリティは基盤と店舗運用を分ける

Shopifyが提供する基盤の保護と、店舗が決めるアクセスや情報管理は、別々に確認する必要があります。

Shopifyは、インターネット経由で利用するSaaS型のECサービスです。自社でサーバーを構築する方式とは異なり、提供された基盤上で店舗を運用します。ただし、誰に管理画面を使わせるか、どのアプリに顧客情報を渡すかは店舗側の判断です。

Shopifyのセキュリティ公式ページは、サービスの保護に加え、事業者自身で行う個人情報保護対応があると説明しています。「Shopifyを採用した」という事実と、「自社の情報管理が適切である」という判断は分けてください。導入稟議でも、基盤の確認資料と店舗の運用ルールを別項目にすると、責任者が曖昧になりません。

法人が確認するセキュリティ対策の早見表

店舗側の点検は5領域に分け、設定の有無だけでなく、担当者と確認記録までそろえると進めやすくなります。

領域	店舗側で確認すること	担当者の例	残す確認記録
認証	ログイン方法と予備手段	店舗管理者	設定確認日、復旧担当者
権限	職務に必要な操作と不要なユーザー	EC責任者	権限一覧、付与理由、終了日
アプリ	個人情報アクセスと外部送信先	導入担当者	利用目的、開発者、許可内容
個人情報	保存先、持ち出し、削除方法	情報管理担当者	データ一覧、保存期限
決済	本人認証の条件と発送判断	受注責任者	保留基準、確認結果、承認者

この表は公式の認証区分ではなく、店舗運用を整理するための例です。少人数の店舗で担当者が兼務する場合も、返金や外部送信を承認する人は明記します。「全員で確認する」だけでは、異常時の停止判断が遅れるためです。まず各行に実際の担当者名を記入してください。

Shopifyセキュリティで基盤の保護と店舗側の5領域を分ける責任分担図 図1: Shopifyの基盤保護と店舗側の運用点検は、別々の確認が必要です。

PCI DSS準拠が意味する範囲を確認する

PCI DSS準拠はカード情報を扱う基盤の確認材料であり、店舗の全業務や外部サービスの安全保証ではありません。

PCI DSSは、カード情報を保護するためのセキュリティ基準です。Shopifyはレベル1への準拠を公表しています。PCI準拠の公式説明では、Shopify上の全ストアに標準適用され、ショッピングカートとホスティングを含むと案内しています。

一方、店舗が別途契約したシステムや、担当者の端末まで無条件に安全と証明するものではありません。たとえば、受注データを表計算ファイルに書き出して外注先へ渡す業務には、別途アクセス管理が必要です。社内の審査資料では、基盤の準拠状況と、外部サービスの契約や管理状況を分けて記載しましょう。

AI導入に関するお困りごとは、株式会社NexaのAI顧問がサポートします。「何から始めればいいか分からない」という段階からご相談いただけます。

AI顧問の無料相談はこちら →

TLSによる暗号化と外部コンテンツを確認する

通信の暗号化はデータを送る途中の保護であり、受信後の保存や、担当者による持ち出しの管理とは異なります。

TLSは、ブラウザーとサーバーの間の通信を暗号化する仕組みです。SSLという呼び方で案内されることもあります。Shopifyの安全な接続に関する説明では、追加したすべてのドメインにTLS証明書を無料提供するとしています。

外部でホストする画像、動画、フォントなどもHTTPSで配信する必要があります。独自ドメインは接続設定も確認してください。店舗担当者は自社の主要ページを開き、接続警告の有無を確認します。制作会社には、外部素材の配信元も点検してもらいましょう。HTTPSで表示できることだけで、サイトの運営者や送信先を信用してはいけません。

管理者のログインはパスキーや二段階認証で守る

管理者のログインは本人ごとに管理し、安全な認証方法と、主な手段が使えない場合の予備手段を用意します。

パスキーは、顔、指紋、PINなどでサインインする方法です。二段階認証は、ログイン時に認証アプリやセキュリティキーなどの確認を追加します。安全なサインイン方法の公式案内は、複数の手段を設定すると予備になると説明しています。

予備手段を用意しても、担当者全員で同じ認証情報を共有すると、操作した人を追いにくくなります。個人ごとのアカウントを使い、端末の紛失時に連絡する相手を決めてください。予備の認証情報は、誰でも閲覧できるチャットへ貼らず、アクセスを限定した場所で管理します。

なお、Shopify Paymentsでは、二段階認証を有効にするまで入金が保留される場合があります。入金に関する公式要件も確認し、売上入金への影響を含めて設定を点検しましょう。

フィッシング対策はメールと業務端末まで含める

ログイン画面の設定に加え、不審な依頼を別経路で確認する手順と、業務端末の管理をそろえてください。

フィッシングは、正規のサービスなどを装って認証情報を入力させる手口です。「支払い情報の確認が必要」といったメールでも、本文中のリンクからすぐにログインしない運用にします。普段使うブックマークなどから管理画面を開き、同じ案内があるかを確かめます。

Shopifyのフィッシング対策も、送信元の真正性が確かでないメールのリンクを避けるよう案内しています。表示名だけでは判定できません。社内ルールの例として、端末の更新、画面ロック、不審メールの報告先を決めます。誤って入力した場合は隠さず報告し、パスワード変更と公式サポートへの連絡を進めてください。

＼ AI活用の「次の一手」を一緒に考えませんか／

AI顧問の無料相談はこちら

スタッフ権限は職務単位で必要最小限にする

スタッフには担当業務に必要な権限を付与し、複数のロールを持つ人は合算された操作範囲まで確認します。

ロールとは、担当業務に必要な権限をまとめたものです。Shopifyのロールに関する公式説明では、複数のロールを割り当てると権限が累積するとしています。ロール名が適切でも、組合せによって不要な操作まで可能になっていないか点検してください。

たとえば、商品説明を編集する担当者に、業務上不要な顧客情報へのアクセスを与える必要はありません。職務ごとに「閲覧」「変更」「出力」の必要性を整理し、実際に設定可能な権限と照合します。利用できるカテゴリや権限は組織やプランなどで異なります。異動時には権限を足すだけでなく、旧職務の権限を外す確認も行いましょう。

外注先のアクセスは作業終了時に解除する

外注先のアクセスは、依頼内容に必要な範囲と期限を決め、作業終了後に継続する理由がなければ解除します。

コラボレーターは、許可したShopify Partnerにストアや組織へのアクセスを認める仕組みです。公式のコラボレーター説明は、必要な権限を慎重に検討し、支援が不要になったらアカウントを削除するよう案内しています。

依頼時には、作業範囲、承認者、終了予定日を記録します。保守契約が続く場合も、制作時の権限をそのまま残すのではなく、保守業務に合わせて見直してください。解除の確認に加え、作業用に渡した顧客データや認証情報の返却、削除も依頼します。管理画面のアクセスを消しても、外部に保存されたファイルの処理は別途確認が必要です。

追加アプリは権限と個人情報の利用目的で選ぶ

追加アプリは機能や評価だけで選ばず、アクセスする個人情報と開発者の利用方針を導入前に確認してください。

Shopifyのアプリ管理ガイドでは、アプリ詳細のPrivacyから個人データへのアクセスと開発者のプライバシーポリシーを確認できると説明しています。必要な機能に対して、求められるデータの範囲が妥当かを検討します。

導入台帳には、アプリ名、目的、社内担当者、扱う情報、開発者への問い合わせ先を残します。配送業務と販促分析では、必要な情報は同じではありません。用途を説明できないアクセスがある場合は、導入前に開発者へ確認してください。導入後も、用途の変更や担当者の異動に合わせて再点検します。ログにも個人情報が入り得るため、ログの共有先にも注意が必要です。

API連携と独自開発の秘密情報を管理する

API連携では、接続できることだけでなく、許可する操作、認証情報の保存先、失効する担当者を確認します。

APIは、システム同士でデータや操作をやり取りする窓口です。認証は接続する相手を確かめること、認可はその相手に許す操作を決めることです。接続用のトークンなどが漏れると、許可された範囲で第三者に使われるおそれがあります。

Shopifyの開発者向けセキュリティ指針は、コードに秘密情報を含めないことなどを示しています。これは標準機能がすべて自動で処理するという意味ではありません。独自開発や委託先の実装で確認する項目です。

委託先には、秘密情報をテーマや公開リポジトリへ埋め込んでいないか確認します。あわせて、接続先、許可操作、管理者、交換や失効の手順を一覧にしてください。契約終了後も旧担当者しか解除できない状態を避けるため、運用手順を納品物に含める方法があります。

Shopifyセキュリティで認証と職務権限、アプリ認可、秘密情報を分けた管理図 図2: 接続する相手の確認と、許可する操作やデータの範囲を分けて管理します。

顧客情報は保存先と持出し経路を把握する

顧客情報の管理対象はShopify内に限らず、出力したファイル、連携先、バックアップまで含めて整理します。

たとえば出荷用CSVをダウンロードする場合、端末、共有フォルダー、配送業務の委託先へ情報が広がります。元の顧客データを修正しても、外部のコピーまで同時に更新されるとは限りません。ファイルを作る業務ごとに、必要な項目と保存先を確認してください。

開発者向けの公式指針は、個人データの収集最小化、アクセス制限、保存期限、削除手順の確認を求めています。店舗側でも、委託先に保管方法を質問する際の確認軸として使えます。記録には「何を、何のために、誰が、どこへ、いつまで保存するか」を書きます。保存期限は一律に決めず、法令や契約上の必要性も踏まえ、情報管理担当者と設定しましょう。

決済の本人認証と管理者認証を混同しない

購入者の決済時の本人認証と、店舗管理者のログイン認証は目的が異なるため、それぞれの条件を確認します。

3D Secureは、カード決済時に購入者の本人確認を行う仕組みです。管理者が使う二段階認証とも、通信を暗号化するTLSとも別です。日本向けShopify Paymentsの公式案内では、3D Secureを含む保護について説明しています。

ただし、日本のShopify Paymentsの説明を、別の決済サービスへそのまま当てはめることはできません。利用中の決済手段ごとに、本人認証の適用条件と問い合わせ先を確認してください。「認証があるから発送確認は不要」とも判断しないでください。受注担当者が参照できるよう、決済手段別の確認先と保留時の連絡先を一覧にしておきます。

不正解析の判定後に発送可否を決める

不正解析は発送判断を助ける情報であり、低リスク判定や決済の成立だけで、損失が生じないとは保証できません。

Shopifyの不正解析は、Shopifyが支払いを確認できるオンラインのカード注文を対象に設計されています。不正の推奨判定には、Grow以上のプラン、または任意のプランでShopify Paymentsを利用するという条件があります。

チャージバックは、カード発行会社を通じて支払いが取り消される処理です。公式説明では、返金の判断はカード発行銀行が行い、Shopifyは銀行による支払いの取り消しを補償しないとしています。不正解析の一般機能を、全注文への補償制度と扱わないでください。

運用例として、高リスク注文は出荷を保留し、受注責任者が判定理由と注文内容を確認します。発送する場合も確認記録を残します。個別の補償サービスを契約している場合は、その適用条件を別途確認し、一般機能の説明と区別してください。

AIや自動化に渡す情報と操作を制限する

AIや自動化を連携するときは、渡すデータと許す操作を絞り、返金や外部送信などは人が確認する設計にします。

たとえば問い合わせ返信案の作成で、全顧客の住所や購入履歴を渡す必要があるとは限りません。まず対象業務を定め、その処理に必要な項目だけを送る方法を検討します。文章の下書きと実際の送信も分ければ、誤りに気付いた段階で止められます。

Shopifyの開発者向け指針も、AIには最小限の権限とデータ範囲を与えるよう求めています。破壊的な操作、金銭に関する処理、外部から見える操作の前には、人による明示的な確認を求めています。店舗側は連携先の保存条件も確認してください。自動化を試す際は、実顧客情報を使う前に、個人情報を含まないテストデータで送信内容と停止手順を確かめます。

あわせて読みたい

生成AIの情報漏洩対策：外部AIへ送る情報の管理と社内ルールを確認できます。

AIに個人情報を入力してよい？判断基準と安全な使い方：顧客情報を入力する前の判断基準を補足します。

アプリ削除とデータ復旧の手順を用意する

アプリの削除、外部契約の終了、保存データの処理は別作業として確認し、必要なデータは復旧方法も用意します。

アプリのアンインストールに関する公式案内では、削除後もテーマにコードが残る場合があるとしています。Shopify外で請求される料金も、アンインストールだけでは停止しません。終了時は開発者の案内に従い、残存コードと外部契約を確認してください。

顧客データが外部で保管される場合は、削除の条件や確認方法も問い合わせます。「アプリが一覧から消えた」だけでは、社外のデータが全消去された根拠になりません。独自連携でバックアップを持つ場合は、アクセス制限と暗号化に加え、復元できるかも試します。復元後に古い送信処理が動かないかなど、業務再開の条件を委託先と決めておきましょう。

追加の管理機能はプラン条件を確認して選ぶ

追加機能は名称だけで比較せず、自社が必要とする管理と、利用できるプランや組織の条件を照合して選びます。

追加セキュリティ機能の公式案内は、Shopify Plus組織向けにSAML認証などを説明しています。SAMLは、社内の認証基盤とサービスのログインを連携するための仕組みです。従業員のアクセスを会社側で管理する設計に利用します。

全プランで同じ機能が使えるとは考えないでください。社内の認証基盤、対象ユーザー、ドメイン所有確認などの条件を確認します。プラン選定では、「退職時のアクセス解除をどう管理するか」といった自社の要件を先に書き出します。上位プランの導入後も、権限の割り当てや外部アプリの審査は店舗側の運用として残ります。

日常運用は10項目のチェックリストにする

点検は担当者と記録を伴う作業にし、定期確認だけでなく、人員やアプリが変わったタイミングでも実施します。

以下は編集部による運用例です。月次などの頻度は公式の一律要件ではなく、自社の業務量やリスクに合わせて調整します。

番号	点検項目	実施タイミングの例	残す記録
1	管理者の認証方法と予備手段	入社、端末変更時	設定確認日
2	退職者や異動者のアクセス	退職、異動時	解除内容と担当者
3	複数ロールの合算権限	月次、職務変更時	権限と付与理由
4	外注先のアクセス継続理由	作業終了時	継続承認または解除
5	アプリの個人情報アクセス	導入、用途変更時	許可範囲と目的
6	APIの認証情報と失効手順	連携追加、担当変更時	管理者と手順の保管先
7	顧客情報の外部保存と削除	月次、委託終了時	保存先と削除確認
8	不正解析後の発送判断	対象注文の発送前	判定理由と承認者
9	独自連携の復元と停止手順	改修後、定期訓練時	試験結果と未解決事項
10	事故時の連絡先と担当者	月次、体制変更時	最新の連絡網