PCI DSSとは？12要件と準拠レベル・v4.0.1移行を発注視点で整理【2026年時点】

PCI DSSは、クレジットカード会員データを扱う事業者が守るべき国際的なセキュリティ基準です。ECサイトや決済システムを外注・内製しようとすると、審査機関や決済代行から「PCI DSS準拠」を求められ、どこまで自社の責任範囲になるのか判断に迷う場面が出てきます。この記事では、6つの目標と12要件、年間取引件数で決まる準拠レベル(1〜4)、訪問審査・ASVスキャン・自己問診(SAQ)という3つの評価方法を、発注者の目線で整理しました。あわせて最新版v4.0.1への移行スケジュールと、カード情報の非保持化で準拠負担を下げる設計判断まで扱います。

まとめ｜PCI DSS準拠の要否と進め方を発注者目線で先に結論づける

PCI DSSは、カード会員データを「保存・処理・伝送」する事業者すべてが対象です。自社がその3つのいずれかに触れているかで、準拠の要否と範囲が決まります。ECサイトの多くは、決済ページを決済代行(PSP)に外部委託し、自社のシステムがカード番号を持たない「非保持化」を選ぶことで、証明に使う自己問診(SAQ)の範囲を大きく縮小できます。

版の状況もはっきりしています。2026年7月時点の最新はv4.0.1で、旧v4.0は2024年12月末に撤回されました。将来日付だった追加要件は2025年3月末から必須化済みのため、これから準拠を進めるならv4.0.1を前提に設計します。

発注時にまず決めるのは、カード情報を自社で持つか持たないかです。持たない設計に振り切れば、準拠の負担も外注先に求める要件も軽くなります。逆に、独自にカード情報を保持する構成は、レベルに関わらず12要件をほぼ全面的に背負う判断だと理解しておきます。

PCI DSSの定義と適用範囲・運用主体をおさえるための基礎知識

まず、誰が何のために定めた基準なのかを押さえます。名前の印象より適用範囲が広く、カード番号に触れる仕組みを持つなら規模を問わず対象になります。

PCI DSSの成り立ちと運用主体・対象となるカード会員データの範囲

PCI DSS(Payment Card Industry Data Security Standard)は、American Express・Discover・JCB・Mastercard・Visaの国際カードブランド5社が2004年に共同で策定したカード情報保護の基準です。現在はPCI SSC(PCI Security Standards Council)という組織が管理・改訂しています。

対象は、カード会員データを保存・処理・伝送する加盟店やサービスプロバイダです。データには、カード番号(PAN)や有効期限に加え、セキュリティコードや磁気ストライプの中身といった認証データが含まれます。認証データはオーソリ後の保存が禁止されており、この一線を越えているかどうかが、準拠設計の出発点になります。

PCI DSSと国内のカード情報保護制度・法令との位置づけの違い

国内では、割賦販売法とその実務指針である「クレジットカード・セキュリティガイドライン」(日本クレジット協会が策定・改訂)が、EC加盟店に対してカード情報の非保持化またはPCI DSS準拠を求めています。PCI DSSは国際基準、ガイドラインは国内の実務要請という関係です。

つまり日本の事業者にとってPCI DSSは、単なる任意の認証ではありません。決済代行や取得会社(アクワイアラ)との契約で準拠を条件とされ、事実上の参加要件として機能する場面が多くあります。

v4.0からv4.0.1への移行と2025年必須化がもたらす実務影響

時期で内容が変わる主題のため、旧版と現行版を分けて記します。ここは一次情報(PCI SSC公表)を基準に、断定を避けた版表記で整理します。

v4.0系への移行スケジュールと2026年時点の有効バージョン

PCI DSSは、v3.2.1からv4.0へと大きく改訂され、2026年7月時点の現行はv4.0.1(2024年6月公開)です。旧v4.0は2024年12月31日で撤回され、2025年1月1日以降はv4.0.1が唯一の有効版となりました。これから審査や自己問診を行う場合は、v4.0.1のテンプレートを使います。

v4.0.1は、v4.0で分かりにくかった記述の明確化と誤記修正が中心で、要件そのものの新規追加や削除はありません。v4.0への対応が済んでいれば、追加負担は限定的だと考えてよい改訂です。

将来日付要件の必須化と2025年3月末という区切りが持つ意味

v4.0では、多数の新要件が当初「将来日付要件(ベストプラクティス扱い)」として猶予されていました。この猶予が2025年3月31日で終了し、それ以降は原則すべての事業者に必須化されています。

具体的には、認証における多要素認証の適用拡大や、Webページのスクリプト改ざん検知(要件6.4.3・11.6.1)などが対象です。ECサイトを運用しているなら、決済ページに読み込まれる外部スクリプトの棚卸しと変更検知の仕組みが、済んでいるかを確認する段階に入っています。

PCI DSSの12要件・6つの目標と準拠レベル区分の読み解き方

要件は12項目ありますが、6つの目標にまとめると全体像がつかめます。あわせて、自社がどのレベルに当たるかで、証明の重さが変わる点を確認します。

6つの目標に沿ったPCI DSSの12要件の全体像と実務での読み方

12の要件は、次の6つの目標に分類されます。個別の技術対策を暗記するより、この6分類で「何を守るための要件か」を把握するほうが実務では通用します。

このうち要件6は、安全なシステムとソフトウェアの開発・保守を定めており、Webアプリの脆弱性対策と直結します。設計・開発段階でどんな弱点を潰すべきかは、OWASPの主要プロジェクトとアプリ開発への組み込み方を参照すると、要件6を具体的な実装課題に落とし込めます。

準拠レベル1〜4の区分と年間取引件数で決まる審査の重さの違い

準拠の証明方法は、年間のカード取引件数で決まるレベルによって変わります。件数が多いほど審査は重くなり、少なければ自己問診で足りる設計です。件数基準はカードブランドごとに細部が異なるため、ここでは代表的な目安を示します。

中小のEC事業者はレベル3や4に該当することが多く、その場合の中心は自己問診(SAQ)です。ただしレベルは免除ではなく、件数が少なくても要件そのものが軽くなるわけではない点に注意します。

訪問審査・ASVスキャン・SAQという3つの準拠評価方法の違い

準拠の証明には、大きく3つの方法があります。役割が異なるため、自社がどれを求められるかを取得会社や決済代行に確認しておきます。

• 訪問審査：認定審査機関(QSA)が現地確認し、準拠報告書(ROC)を作成する。レベル1が主対象。
• ASVスキャン：認定業者(ASV)が外部公開システムを四半期ごとに脆弱性スキャンする。
• 自己問診(SAQ)：事業者自身が該当タイプの問診票で自己評価し、準拠証明書(AOC)を作成する。

SAQは決済構成に応じて9種類ほどに分かれます。完全外部委託ならSAQ A、自社ページから外部へ受け渡すが処理に関与するならSAQ A-EP、カード情報を自社で保持するならSAQ Dです。対象範囲は構成次第で段違いに変わります。どのSAQになるかは、次章の設計判断で決まります。

準拠コストを抑えるシステム設計と外注先の選び方を分ける判断基準

ここからは、競合の解説記事があまり踏み込まない「発注者としての判断」を言い切ります。準拠は要件を全部やる話ではなく、カード情報に触れる範囲(スコープ)をどこまで削れるかの設計問題です。

カード情報の非保持・非通過化でSAQの対象範囲を最小化する設計

準拠負担を最も下げるのは、自社システムがカード番号を「保存も処理も伝送もしない」構成にすることです。国内のガイドラインが求める非保持化がこれに当たり、決済入力をPSP側の画面やタグに委ねます。代表的な方式は3つです。

• リンク型(リダイレクト)：決済時にPSPの画面へ遷移させ、自社はカード情報に一切触れない。SAQ Aに寄せやすい。
• トークン型(JavaScript)：入力欄をPSPのタグで生成し、カード情報を自社サーバに通さずトークン化する。
• 非通過型API：カード情報が自社サーバを経由しない前提でAPI連携する。実装次第でSAQ A-EPが必要。

この設計を選べば、12要件のうち自社に残るのはアクセス管理やポリシーなど一部に絞られます。逆に「入力欄だけ自社で作りたい」といった要望は、非保持の前提を崩し、スコープを一気に広げる引き金です。UIの都合で自社通過を選ぶ前に、準拠コストとの綱引きを必ず見積もります。

決済代行への委譲が有効な場面と自社での保持が要る場面の切り分け

結論として、一般的なEC事業者は決済代行への委譲＋非保持化に振り切るべきです。自前でカード情報を保持し、独自にレベル1準拠を目指す構成は、月商や取引件数が相当な規模で、かつ決済体験そのものを競争力にする事業でなければ過剰投資になります。

自社保持が正当化されるのは、たとえば継続課金基盤を自社の中核資産として持ち、複数ブランドの決済を横断管理する必要がある場合などです。この判断は、委託先管理(要件12.8)を含む供給網全体のリスク設計と切り離せません。委託先経由の侵害という観点は、サプライチェーン攻撃の起点別3類型と対策の優先順位で全体像を確認したうえで、自社保持の是非を決めると精度が上がります。

準拠を過剰投資にしないための対応優先順位と典型的な失敗パターン

準拠プロジェクトで陥りやすいのは、要件表を上から均等に潰そうとして、範囲を絞る前に対策コストが膨らむパターンです。順序を間違えなければ、投資はかなり圧縮できます。実務では次の優先順位で進めます。

1. スコープ確定：カード情報が通る経路を図に起こし、触れる範囲を最小化する。
2. 非保持化の可否判断：PSP委譲でSAQタイプを軽い側へ寄せられるか検証する。
3. 残った要件への対応：自社に残る領域だけを、要件6や10・11を軸に固める。

採用を見送るべき場面もはっきりしています。取引件数が年数万件規模のECで、非保持化の余地があるのに自社でカード情報を保持し、レベル1相当の体制を丸ごと構築するのは過剰です。まず範囲を削り、それでも残る部分にだけ投資するのが、準拠の実務における鉄則です。

よくある質問

PCI DSSの準拠を検討する事業者から寄せられることの多い質問に、要点を絞って答えます。

PCI DSSに準拠しないと罰則はありますか？

PCI DSSは法律ではないため、行政罰が直接科されるわけではありません。ただし取得会社やカードブランドとの契約上の義務であり、未準拠のまま情報漏えいが起きると、違約金・課徴金や加盟店契約の解除、フォレンジック調査費用の負担といった不利益につながります。国内では割賦販売法とガイドラインが非保持化かPCI DSS準拠を求めるため、実務上は避けて通れません。

PCI DSS v4.0とv4.0.1は何が違いますか？

v4.0.1(2024年6月公開)は、v4.0の記述の明確化と誤記修正が中心で、要件の新規追加や削除はありません。旧v4.0は2024年12月31日で撤回され、2025年1月1日以降はv4.0.1が唯一の有効版です。将来日付だった追加要件は2025年3月31日から必須化されているため、これから対応するならv4.0.1を前提に進めます。

ECサイトはどのSAQを使えばよいですか？

決済ページをPSPへ完全にリダイレクトし、自社がカード情報に一切触れない構成ならSAQ Aが基本です。自社ページに決済タグを埋め込み、処理に関与するがサーバでは保持しない場合はSAQ A-EPになります。カード情報を自社で保存・処理するならSAQ Dとなり、対象要件が大幅に増えます。どれに当たるかは決済構成で決まるため、決済代行に確認するのが確実です。

PCI DSS準拠にかかる費用と期間の目安は？

費用は準拠レベルと構成で大きく変わります。非保持化してSAQ Aで済む中小ECなら、ASVスキャン費用を中心に年数万円台から始まる例が多い一方、レベル1で訪問審査(QSA)を受ける場合は、審査費用だけで数百万円規模におよぶ例も少なくありません。期間もスコープ次第で、範囲を絞れれば短縮できます。まず非保持化で範囲を削ることが、費用と期間の両方を抑える近道です。

決済代行を使えば自社は準拠不要になりますか？

不要にはなりません。決済代行の利用で自社のスコープは小さくなりますが、ゼロにはならず、少なくとも該当するSAQでの自己評価と証明は残ります。自社ページからの決済誘導や外部スクリプトの管理(要件6.4.3など)も、自社の責任範囲に含まれる領域です。委譲によって「軽くなる」と理解し、「消える」とは捉えないことが、準拠設計での取りこぼしを防ぎます。

関連記事

• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位を解説：委託先管理(要件12.8)を含む供給網全体のセキュリティ設計を、攻撃の起点別に整理した記事です。
• OWASPとは？主要プロジェクトの全体像とアプリ開発への組み込み方：要件6の安全な開発に直結する、Webアプリの脆弱性対策の実装視点をまとめています。