【図解】PCI DSSとは？ クレジットカード情報を守る世界基準をわかりやすく解説

キャッシュレスが当たり前になった一方で、カード情報を狙った攻撃も増え続けている。日本クレジット協会によれば、2024年のクレジットカード不正利用被害額は過去最高の約555億円に達し、その大半がEC(非対面)での不正、手口の中心は「なりすまし」だ¹。

もし自社のサービスから顧客のカード情報が漏れたら、と想像してみてほしい。違約金、損害賠償、調査費用、そして何より「あの会社は危ない」という評判。ビジネスにとって致命傷になりかねない。

この被害から顧客と企業を守るための世界共通のルールが「PCI DSS(Payment Card Industry Data Security Standard)」だ。この記事では、カード決済に関わるすべての事業者が知っておくべきPCI DSSの基本から、12の要件、現実的な対応(非保持化)、そして日本独自の制度までを、図を多めに使って整理する。決済オタクとして言うと、前回のSakana Fuguの回で触れた「決済代行(PSP)」の話とも、実はまっすぐつながるテーマだ。

PCI DSSとは何か

PCI DSSを一言で言えば、「カード情報を安全に扱うための、世界共通のルールブック」だ。

作ったのは、国際カードブランド5社(Visa、Mastercard、JCB、American Express、Discover)が共同で設立した「PCI SSC」という団体²。特定の国の法律ではなく、カード業界が自ら定めた世界標準である、という点がまず大事だ。

対象は、カード情報を「保存・処理・伝送」するすべての事業者³。決済代行会社(PSP)やカード会社はもちろん、自社でカード情報を扱うECサイトや実店舗の加盟店、さらにはサーバーを貸すホスティング事業者まで含まれる。「うちはカードを扱っているだけ」と思っていても、情報の流れに触れていれば対象になる。

守らないと、どうなるのか

なぜここまで厳格なのか。答えは単純で、漏れたときの被害が甚大だからだ。ルールを守らずに情報漏洩を起こすと、おおむね三つの重い代償を負う。

一つ、経済的な損失。カード会社からの違約金、被害者への損害賠償、原因を突き止めるフォレンジック調査の費用など、莫大なコストが一気に発生する。

二つ、カード決済の停止。最悪の場合、クレジットカードの取り扱いそのものを止められる。EC事業者にとっては「売上の道が絶たれる」ことを意味する。

三つ、ブランドの失墜。「セキュリティが甘い会社」という評判は、一度つくと顧客離れを加速させ、信頼の回復には途方もない時間がかかる。

日本でも、2018年施行の改正割賦販売法によって、カードを扱う加盟店に「カード番号の適切な管理」と「不正利用の防止」の措置が義務づけられている⁴。後で触れるとおり、その具体的な中身が「非保持化、またはPCI DSS準拠」だ。

6つの目標と、12の要件

PCI DSSは、ネットワークの設定から物理的な施錠、従業員教育まで、広い範囲をカバーする。全体は「6つの目標」と、それを実現するための「12の要件」で構成されている。詳細は図に整理したが、骨格はこうだ。

安全なネットワークを作り(要件1・2)、保存・伝送するカードデータを暗号化して守り(要件3・4)、マルウェア対策と安全な開発で脆弱性を管理し(要件5・6)、アクセスを業務上必要な人だけに絞って認証と物理管理を固め(要件7・8・9)、ログの監視と定期的なテストで見張り(要件10・11)、最後にこれら全部をポリシーと教育で組織に根づかせる(要件12)。要するに「入口を固め、データを隠し、人を絞り、見張り、ルール化する」という、セキュリティの王道を決済向けに具体化したものだ。

現在の最新版は「v4.0.1」だ⁶。旧v3.2.1は2024年3月末で廃止され、v4.0で新設された厳しめの要件(猶予されていた約60項目)も、2025年4月1日以降はすべて義務化されている⁶。具体的には、カード情報を扱う環境への全アクセスに対する多要素認証(MFA)、決済ページに読み込まれるスクリプトの管理(ECサイトを狙う「Webスキミング」対策)、フィッシング対策などが新たに必須になった⁸。「一度準拠したら終わり」ではなく、脅威の変化に追従し続ける基準だと理解しておきたい。

身近にある「PCI DSS」

ここまでは仕組みの話だ。けれども、PCI DSSは実のところ、私たちが毎日のように体験している。

たとえば、ECサイトによっては、カード番号は保存されているのに、セキュリティコード(裏面の3桁か4桁)だけは毎回入力を求められることがある。これはPCI DSSが、セキュリティコードのような「機密認証データ(SAD)」を、たとえ暗号化してであっても認証後に保存することを固く禁じているからだ。カード番号は条件を満たせば保存できても、セキュリティコードは認証のために一瞬だけ「通過」させ、その直後にサーバーから完全に消す。これがルールになっている。

ここで面白いのは、PCI DSSが命じているのは「保存するな」であって、「毎回入力させろ」ではない、という点だ。だから、セキュリティコードを毎回求めるかどうかは、PCI DSSそのものではなく、その先の事情で決まる。

求めない代表が「On-Us(オンアス)取引」だ。カードの発行会社(イシュア)と加盟店側(アクワイアラ)が同じ、あるいは同じ経済圏の中にある場合、決済は外部の国際ブランド網を回らず、自社のクローズドループで完結する。自社IDに紐づいていれば、属性も購買履歴もログイン端末もすべて自社で把握できるので、「このユーザーは間違いなく本人だ」とデータで言い切れる。だからUXを削るセキュリティコードの入力を省ける。ほかにも、Amazonのようにチャージバック(不正時の損害)を自社で被る覚悟でカゴ落ちを嫌い一切求めない判断、決済の裏で端末や行動をAIが採点する「リスクベース認証(EMV 3-Dセキュア)」で低リスクと出ればフリクションなしで通す方法、初回にきちんと認証して以降は国際ブランド発行の「ネットワークトークン」で請求する方法など、静的なセキュリティコードに頼らずに本人性を担保する道が増えている。

つまりここに見えているのは、「カード情報を持てないなら、毎回入力させるしかない」という物理的な制約を、データと経済圏の力でどう乗り越えるか、という各社の戦略だ。たかが3桁の入力欄に、その会社が持つデータ量と、リスクをどこまで自分で背負うかの覚悟が透けて見える。

サブスクや毎月の公共料金が、カード情報を都度入力させずに課金できるのも、同じ発想の応用だ。ここで効くのが「トークン化」である。利用者が初回に入力したカード情報はPSPへ直接送られ、PSPが本物を安全な環境に保管し、加盟店には「意味のない文字列(トークン)」だけを返す。加盟店は自社に「顧客Aさん＝トークンX」とだけ持ち、毎月の請求はそのトークンをPSPに渡すだけで済む。加盟店は一度もカード情報を持たない。

店頭でカードを使うとき、暗証番号をレジ本体ではなく手元の小さな端末(ピンパッド)で入力するのも、偶然ではない。あれは「PCI PTS」という、暗証番号を入力する端末専用の別のハードウェア基準を満たした機械だ。入力された暗証番号は端末の中で即座に暗号化され、レジ本体には解読できないデータしか渡らない。こうしてレジ本体を「暗証番号を持たない」状態にし、レジ全体が重い審査対象になるのを避けている。

電話で注文するコールセンターにも、同じ配慮がある。トラブル防止のために通話は録音されているが、顧客が読み上げたセキュリティコードをそのまま録音すれば、音声として保存禁止のデータを持ってしまい、違反になる。そこで最近は、決済の入力画面を開いた瞬間に録音を自動で一時停止する、あるいは顧客自身に電話のプッシュ音(DTMF)で入力させ、オペレーターにはマスキングして見せる、といった仕組みが使われている。

現実解は「準拠」か「非保持化」か

ここまで読んで、「要件が多すぎて、自社で全部やるのは無理だ」と感じた人は多いはずだ。実際、一般のEC事業者や加盟店が単独でPCI DSSの完全準拠を達成するのは、コストも人手も現実的でないことが多い。

そこで多くの事業者が選ぶのが「カード情報の非保持化」だ。これは、カードの入力から処理までをPCI DSSに準拠した決済代行会社(PSP)に任せ、自社のサーバーにはカード情報を「通さない・保存しない」仕組みを指す。リンク型決済、トークン決済、入力画面をPSP側で持つ非通過型などが代表的な手段だ⁶。

ここが、前回のFuguの回で書いた話と同じ構図になる。あのとき、Fuguは「ユーザーと複数のAIモデルの間に立つ、AIのPSP」だと書いた。決済の世界では、加盟店とカードネットワークの間にPSPが立ち、危険なカード情報を加盟店に触れさせずに処理する。自社でカード情報を本当に持つ必要があるのか。多くの場合、優れたPSPを使って「非保持化」するのが、最も安全でコスパの高い選択になる。逆に、自社サーバーでカード情報を直接持つPSP・大規模プラットフォーマー・カード会社などは、逃げ場なくPCI DSS準拠が必要になる。

「準拠」は、現場をどう縛るか

非保持化やPCI DSS準拠は、守る側の現場では「不便」として現れる。決済オタクとしては、むしろここが面白い。

まず、決済ページにはマーケティングタグを勝手に足せない。コンバージョン計測や行動分析のタグを、GTMでノンコードにサッと入れる。普段なら当たり前のこの運用が、カード番号を入力するページでは止まる。v4.0の要件6.4.3で、決済ページで動く外部スクリプトをすべて管理(棚卸しと改ざん検知)することが義務づけられたからだ⁸。マルウェアがスクリプトを書き換えてカード情報を抜き取る「Webスキミング」を防ぐため、1行のスクリプトを足すにもコードレビューと、許可したスクリプトしか動かさない制御(CSPなど)が要る。

次に、テスト環境で本番データを使えない。バグ調査では「本番のデータをそのまま検証環境にコピーして再現したい」という誘惑が常にあるが、本番のカード番号を開発やテストの環境に持ち込むことは厳格に禁じられている。もし混入すれば、そのテスト環境や開発者のPCまでが審査対象になり、監査コストが跳ね上がる。だから開発チームは、最初からダミーのカード番号を生成する仕組みを用意しておく。

共通アカウントも使えない。「adminでみんなでログインして作業」は一発アウトだ。カード情報を扱う環境での操作は「誰が、いつ、何をしたか」を個人単位で追えなければならず、v4.0からはすべてのアクセスに多要素認証(MFA)が必須になった⁸。本番システムに触るエンジニアは、社内VPNの中からの接続であっても、毎回ワンタイムパスワードや生体認証を通す。

そして、穴になるのはシステムだけではない。カード情報環境にアクセスできる権限を持つ社員や委託先には、採用や配属の段階で適切な審査(要件12.7)を行うことが求められる。各国の法律が許す範囲で、経歴の確認などを人事や労務のフローに組み込む。セキュリティはシステム部門だけで完結せず、組織の採用にまで及ぶ。

結局のところPCI DSSは、「データをどう守るか」だけでなく「組織がどう動くか」までを規定するルールだ。だからこそ現場では、開発スピードや運用の手軽さとのトレードオフになりやすい。少しの不便を引き受けることが、カード情報を守るコストなのだと思う。

日本のいま：割販法、ガイドライン6.0、EMV 3-Dセキュア

日本では、PCI DSSは「クレジットカード・セキュリティガイドライン」という実務指針を通じて効いてくる。このガイドラインは割賦販売法のセキュリティ対策義務の「実務上の指針」と位置づけられ、ガイドラインに沿った対策を講じていれば、法が求める「必要かつ適切な措置」を満たしているとみなされる⁵。

最新は2025年3月公表の「6.0版」だ⁵。EC加盟店に求められる対策は、大きく四つに整理できる。カード情報の保護(非保持化、またはPCI DSS準拠)、システムやWebサイトの脆弱性対策、EMV 3-Dセキュアの導入、そして不正ログイン対策(MFAなど)だ。

特に大きい変化が二つある。一つは、EMV 3-Dセキュア(3Dセキュア2.0)が2025年3月末までに原則すべてのEC加盟店で必須化され、原則として決済の都度、本人認証を行うことになった点⁷。もう一つは、これまで「非保持化していれば安心」とされてきたのに、非保持化済みのEC加盟店でも漏洩や不正が多発したため、6.0版で脆弱性対策と不正ログイン対策が明確に追加されたことだ⁴。背景には「面ではなく、線で守る」という発想がある。決済前(不正ログイン対策)、決済時(EMV 3-Dセキュア)、決済後(配送・転売対策)と、取引の流れの各場面で手を打つ、という考え方だ⁴。

数字が示すとおり、脅威は止まらない。2024年の不正利用被害は過去最高の約555億円¹。「ルールが厳しくなった」のではなく、「被害が厳しいから、ルールが追いかけている」のだ。

まとめ

PCI DSSは、単なるITの専門用語ではない。カードを扱う事業者が商売を続けるための「最低限の防衛線」だ。

決済サービスを導入するときは、手数料や使い勝手だけで選ばないこと。自社のシステムがセキュリティ基準(または非保持化の要件)を満たしているか、そして使う決済代行会社がPCI DSSに準拠しているか。この二つは必ず確認したい。カード情報は、持たないのがいちばん強い。これは決済の世界でも、AIの世界でも、同じことなのだと思う。

出典

1. 「クレジットカード・セキュリティガイドライン6.0対応」Proactive Defense（日本クレジット協会による2024年の不正利用被害額 約555億円・過去最高、EC・なりすましが中心） https://www.proactivedefense.jp/blog/blog-vulnerability-assessment/post-6691

2. 「PCI DSS v4.0.1とは？最新版の主要要件とv4.0からの変更点を解説」Cloudbric（PCI SSCと国際カードブランド5社、6つの目標と12の要件、対象事業体） https://www.cloudbric.jp/blog/2026/05/pcidss-v401/

3. 「PCI DSS v4.0解説｜12の要件と対応のポイント」BTNコンサルティング（6つの目標と12の要件、対象、新要件の具体例） https://www.btncon.com/blog/pci-dss-guide

4. 「EC加盟店の脆弱性対策は待ったなし クレジットカード・セキュリティガイドライン6.0のポイント」LAC WATCH（平成30年〈2018年〉改正割賦販売法による加盟店の義務、6.0版での脆弱性対策・不正ログイン対策の追加、線の考え方） https://www.lac.co.jp/lacwatch/service/20250930_004507.html

5. 経済産業省「クレジットカード・セキュリティガイドラインが改訂されました」（2025年3月公表の6.0版、割賦販売法の実務上の指針としての位置づけ） https://www.meti.go.jp/press/2024/03/20250305002/20250305002.html

6. PCI SSC公式トレーニング「PCI DSS v4.0：今後のスケジュールと最新情報」（v3.2.1の廃止と移行スケジュール／最新版はv4.0.1）。非保持化・非通過型については一般社団法人日本クレジット協会「安全・安心なクレジットカード取引への取組」も参照 https://training.pcisecuritystandards.org/pci-dss-v4-0-timelines-japanese https://www.j-credit.or.jp/security/document/index.html

7. 「すべてのECサイト事業者が対象 EMV 3-Dセキュア(3Dセキュア2.0)が必須化へ」DGフィナンシャルテクノロジー（2025年3月末までに原則すべてのEC加盟店で必須化、原則・決済の都度の認証） https://www.dgft.jp/tips/column/3d_secure.html

8. BTNコンサルティング（v4.0.1が現行、2025年4月1日に新要件〈MFA、決済ページのクライアント側スクリプト管理、フィッシング対策など〉が全面義務化） https://www.btncon.com/blog/pci-dss-guide