結論――多くのEC事業者は「非保持化」でPCI DSS準拠を回避している
「クレジットカード決済を導入するとPCI DSS準拠が必要と聞いたが、何をすればいいのかわからない」――そう感じている事業者は少なくありません。
先に結論をお伝えすると、カード情報を自社で保持しない構成（非保持化）にすれば、多くのEC事業者はPCI DSSへのフル準拠を求められません。StripeやPayPalなどの決済代行を使い、カード番号を自社サーバーに通さない仕組みにすることで、負担の大きいPCI DSS準拠を回避できるためです。
一方で、カード情報を保存・処理・伝送する構成の場合はPCI DSS準拠が必要になります。この記事では、PCI DSSとは何か、12の要件の概要、そして「非保持化」との違いと自社にどちらが必要かの判断軸を解説します。
本記事は制度の一般的な解説を目的としたものです。実際の準拠要件・区分（マーチャントレベル等）は契約する決済代行事業者・アクワイアラ・カードブランドによって異なります。個別の適用は契約先の案内に従ってご確認ください。
PCI DSSとは何か
PCI DSS（Payment Card Industry Data Security Standard）は、クレジットカード情報を安全に取り扱うための国際的なセキュリティ基準です。VISA、Mastercard、JCB、American Express、Discoverの国際5ブランドが共同で策定し、カード会員データを保存・処理・伝送するすべての事業者が対象となります。
日本では、改正割賦販売法が「クレジットカード番号等を取り扱う事業者」に対して、カード情報の適切な管理（＝PCI DSS準拠または非保持化）を義務付けています。つまりPCI DSSは、クレジットカード決済のセキュリティ・チェックリストにおける「カード情報の適切な管理」を満たす手段の一つという位置づけです。
現在の最新版は2024年6月公開のPCI DSS v4.0.1で、旧版の v3.2.1 は2024年3月末に廃止されています。
PCI DSSの12要件の概要
PCI DSSは、6つの目標と12の要件で構成されています。全体像を把握しておきましょう。
# | 要件の概要 | 目標カテゴリ |
|---|---|---|
1 | ファイアウォールの導入・維持 | ネットワークの構築と維持 |
2 | 初期設定のパスワード等を使用しない | ネットワークの構築と維持 |
3 | 保存されるカード会員データの保護 | カード会員データの保護 |
4 | 公衆ネットワーク上の伝送データの暗号化 | カード会員データの保護 |
5 | マルウェア対策（アンチウイルス等）の導入 | 脆弱性管理プログラムの整備 |
6 | 安全なシステム・アプリケーションの開発と保守 | 脆弱性管理プログラムの整備 |
7 | カードデータへのアクセスを業務上の必要範囲に制限 | アクセス制御 |
8 | 各ユーザーへの一意のIDの割り当て | アクセス制御 |
9 | カードデータへの物理アクセスの制限 | アクセス制御 |
10 | ネットワーク・データへのアクセスの追跡と監視 | 監視とテスト |
11 | セキュリティシステムとプロセスの定期的なテスト | 監視とテスト |
12 | 情報セキュリティポリシーの整備 | セキュリティポリシー |
これら12要件は、技術的対策（暗号化・アクセス制御・脆弱性管理）から運用・ポリシー（監視・教育）まで多岐にわたります。フル準拠には相応の体制とコストが必要になるため、多くのEC事業者は次に述べる「非保持化」を選択しています。
「非保持化」とPCI DSS準拠の違い
ここが多くの事業者にとって最も重要なポイントです。カード情報を扱う方法には、大きく2つのアプローチがあります。
項目 | 非保持化 | PCI DSS準拠（フル準拠） |
|---|---|---|
考え方 | カード情報を自社で保存・処理・伝送しない | カード情報を扱うが、基準に沿って厳格に保護する |
典型的な構成 | 決済代行のトークン方式・リダイレクト方式 | 自社でカード情報を保持・処理するシステム |
事業者の負担 | 比較的小さい | 大きい（監査・体制整備が必要） |
主な対象 | 中小〜多くのEC事業者 | 大規模事業者・カード情報を保持する必要がある事業者 |
非保持化とは
非保持化とは、カード会員データを「保存しない・処理しない・伝送しない」状態にすることです。具体的には、決済代行サービスのトークン方式（カード情報をトークンに置き換える）やリダイレクト方式（決済画面をPSP側でホストする）を採用し、カード番号が自社のサーバーやシステムを通らないようにします。
StripeのElements/Checkout、PayPal、各種決済代行のホスト型決済ページなどがこれに該当します。この構成であれば、カード情報を自社で扱わないため、PCI DSSのフル準拠を求められないケースが大半です。
どちらを選ぶべきか
特別な理由がない限り、多くのEC事業者は非保持化を選ぶのが現実的です。フル準拠は監査・体制整備の負担が大きく、カード情報を自社で保持する明確な必要性（大規模なサブスクリプション基盤、独自の決済処理など）がなければ、非保持化のほうが低コストで安全性も確保しやすいためです。
ただし、非保持化を選んだ場合でも「Webアプリケーションの脆弱性対策」は免除されません。次に述べる要件11の考え方は、非保持化の事業者にとっても実務上重要です。
要件11が求める脆弱性スキャン・ペネトレーションテスト
PCI DSSの12要件のうち、要件11「セキュリティシステムとプロセスの定期的なテスト」は、AEVUSのようなセキュリティ診断サービスと直接関わる部分です。要件11は、主に次の対応を求めています。
- 脆弱性スキャンの定期実施：外部・内部のネットワークに対する脆弱性スキャンを定期的（および大きな変更後）に実施する。外部スキャンはASV（Approved Scanning Vendor）による実施が求められる場合がある
- ペネトレーションテストの実施：ネットワーク・アプリケーション層に対する侵入テストを定期的に実施する
- 検出された問題への対応：スキャン・テストで見つかった脆弱性を修正し、再テストで確認する
ここで重要なのは、この「定期的な脆弱性スキャン・ペネトレーションテスト」という考え方は、PCI DSSフル準拠の事業者に限らず、セキュリティ・チェックリストの項目3でも同様に求められているという点です。つまり、非保持化を選んだ事業者であっても、自社のWebアプリケーションに対する脆弱性診断・ペネトレーションテストの実施は避けて通れません。
脆弱性診断とペネトレーションテストの違いや、どちらを選ぶべきかについてはペネトレーションテストと脆弱性診断の違いで詳しく解説しています。
PCI DSSの比較：v3.2.1とv4.0の違い、ISMS・SOC 2との違い
「PCI DSS 比較」で調べる方の疑問は、たいてい次の3つのどれかです。旧版と現行版で何が変わったのか、非保持化と準拠のどちらを選ぶのか、ISMS や SOC 2 とはどう違うのか。非保持化との違いは前節で述べたので、ここでは残りの2つを表で整理します。
v3.2.1 と v4.0（v4.0.1）の違い
PCI DSS v4.0 は2022年3月に公開され、旧版の v3.2.1 は2024年3月31日に廃止されました。v4.0 で「将来日付」とされていた要件は2025年3月31日から必須になっています。2024年6月には字句の明確化を目的とした v4.0.1 が公開され、現在はこれが最新版です。
観点 | v3.2.1（廃止） | v4.0 / v4.0.1（現行） |
|---|---|---|
準拠の示し方 | 定義された要件をそのまま満たす | 従来の方法に加え、目的を別の手段で満たす「カスタマイズドアプローチ」を選べる |
多要素認証（MFA） | 管理者とリモートアクセスが中心 | カード会員データ環境へのすべてのアクセスに拡大（要件8.4.2） |
決済ページの保護 | 明示的な要件なし | ページ上のスクリプト管理（6.4.3）と改ざん検知（11.6.1）が必須 |
パスワード | 最低7文字 | 最低12文字（8.3.6） |
対象範囲の確認 | 評価時に確認 | 年1回の範囲確認を要件化（12.5.2） |
変更点の詳細と対応手順はPCI DSS 4.0対応ガイド【2026年版】で解説しています。
ISMS（ISO/IEC 27001）・SOC 2 との違い
取引先から「PCI DSS か ISMS か SOC 2 か」を問われたときは、守る対象と証明の相手が違うと考えると整理できます。
観点 | PCI DSS | ISMS（ISO/IEC 27001） | SOC 2 |
|---|---|---|---|
守る対象 | カード会員データ | 組織の情報資産全般 | 受託サービスの統制（セキュリティ・可用性など） |
誰が求めるか | 国際カードブランド・アクワイアラ | 取引先・入札要件・自主的 | クラウド・SaaS の顧客（米国系企業に多い） |
証明の方法 | 自己問診（SAQ）または QSA の審査 | 認証機関による第三者認証 | 監査法人の報告書（Type I / Type II） |
要求の性質 | 技術要件が具体的（暗号化・ログ・脆弱性スキャンなど） | マネジメントの仕組みが中心 | 統制の設計と運用状況の報告 |
カード決済を扱う限り PCI DSS（または非保持化）は避けられません。ISMS や SOC 2 はそれと置き換わるものではなく、別の相手に別の範囲を証明する制度です。
よくある質問（FAQ）
Q1. 決済代行（Stripe等）を使えばPCI DSSは完全に不要ですか？
カード情報を自社で保存・処理・伝送しない「非保持化」の構成であれば、多くの場合PCI DSSのフル準拠は求められません。ただし、決済代行を使っていても実装方法によってはカード情報が自社を経由する場合があり、その際は準拠が必要になります。利用しているサービスの構成を確認してください。
Q2. 非保持化にすれば、セキュリティ対策は何もしなくてよいのですか？
いいえ。非保持化はあくまで「カード情報の管理」に関する対策です。会員登録・ログイン・注文フォームなど、あなたが運用するWebアプリケーション自体の脆弱性対策（SQLインジェクション・XSS対策、定期的な脆弱性診断）は引き続き求められます。
Q3. PCI DSSの「マーチャントレベル」とは何ですか？
年間のカード取引件数などに応じて事業者を区分したものがマーチャントレベルです。レベルによって求められる準拠の証明方法（自己問診票SAQ、または訪問審査）が異なります。自社がどのレベルに該当するかは、契約するアクワイアラやカードブランドに確認する必要があります。
Q4. 要件11の脆弱性スキャンは自社で実施すればよいですか？
内部スキャンは自社で実施できますが、外部スキャンはASV（Approved Scanning Vendor）による実施が求められる場合があります。また、ペネトレーションテストは専門的な知識が必要なため、専門ベンダーへの依頼が一般的です。
Q5. 中小規模のECサイトでもPCI DSSを意識する必要がありますか？
はい。規模にかかわらず、クレジットカード情報を扱う以上は「非保持化またはPCI DSS準拠」が求められます。中小規模の事業者は非保持化を選ぶのが一般的ですが、その場合もWebアプリの脆弱性対策は必要です。
まとめ
この記事では、PCI DSSと非保持化について解説しました。
- PCI DSSとは：カード情報を安全に扱うための国際セキュリティ基準（6目標・12要件）
- 非保持化との違い：カード情報を自社で扱わない非保持化なら、多くの事業者はフル準拠が不要
- どちらを選ぶか：特別な必要がなければ、多くのEC事業者は非保持化が現実的
- 要件11：フル準拠でも非保持化でも、定期的な脆弱性スキャン・ペネトレーションテストと修正対応は避けられない
PCI DSS準拠か非保持化かは「カード情報の管理」の話であり、それとは別にWebアプリケーション自体の脆弱性対策が常に必要です。決済を扱うサイトは、この2つを分けて整理することが重要です。
関連記事
AEVUSに相談する
「非保持化にしたが、Webアプリのセキュリティが不安」「PCI DSS要件11の脆弱性スキャン・ペネトレーションテストを実施したい」という方は、AEVUSにご相談ください。
AEVUSでは、決済フローや会員機能を含むWebアプリケーションの脆弱性診断・ペネトレーションテストを提供しています。要件11やセキュリティ・チェックリストの項目3が求める「定期的な脆弱性の検査と修正対応」を、専門家がサポートします。
まずはお気軽にお問い合わせください。決済構成やカード情報の取り扱い状況をヒアリングしたうえで、最適な診断プランをご提案します。
