結論――多くの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は、クレジットカード決済のセキュリティ・チェックリストにおける「カード情報の適切な管理」を満たす手段の一つという位置づけです。
現在の最新版はPCI DSS v4.0（およびその改訂版）で、旧バージョンからの移行が進められています。
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アプリケーションに対する脆弱性診断・ペネトレーションテストの実施は避けて通れません。
脆弱性診断とペネトレーションテストの違いや、どちらを選ぶべきかについてはペネトレーションテストと脆弱性診断の違いで詳しく解説しています。
よくある質問（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が求める「定期的な脆弱性の検査と修正対応」を、専門家がサポートします。
まずはお気軽にお問い合わせください。決済構成やカード情報の取り扱い状況をヒアリングしたうえで、最適な診断プランをご提案します。
