PCI DSS v4.0 のうち EC 決済ページに直接効く 6.4.3（スクリプト管理）と 11.6.1（改ざん検知）が、2025 年 3 月 31 日をもって正式な要件へ移行しました。要件番号レベルで自社の対応要否を確認したいという担当者にとって、要件本文と接続方式ごとの負担がひとつの画面で見えるかどうかが判断の分かれ道です。
本記事では、v4.0 と v3.2.1 の差分・移行タイムラインを最小限確定した上で、6.4.3 と 11.6.1 の要件本文を PCI SSC の公式ドキュメントから示し、EC 決済ページの接続方式（JS 型・自社ホスト型・iframe 型・リンク型／リダイレクト型・非通過型）別に適用可否・SAQ 種類・実装負担を1枚のマトリクスにまとめます。
SAQ A 適格性の 2025 年 4 月 1 日改定と 6.4.3／11.6.1 の関係も、PCI SSC 公式 FAQ を引きながら分岐で示します。
期日を過ぎたあとでも後追いで対応できるのか、決済代行会社にどう問い合わせればよいか、6.4.3／11.6.1 の負担を TPSP 側に移せる決済代行の選択肢はどれかまで具体で示します。自社の決済ページの現状を確認し、次の一手を組み立てるための素材としてご利用ください。
目次
PCI DSS v4.0 で 2025 年 3 月 31 日に必須化された要件
PCI DSS v4.0 では、公開当初は「ベストプラクティス」として扱われていた新規要件が段階的に必須化されました。EC 決済ページに直接効く 6.4.3（決済ページの全スクリプト管理）と 11.6.1（HTTP ヘッダおよび決済ページコンテンツの改ざん検知）は、いずれも 2025 年 3 月 31 日をもって正式な要件へ移行しています。
ここでは v3.2.1 との差分と移行タイムラインを最小限確定し、以降の節（要件本文・接続方式別マトリクス・対応手法）の前提を揃えます。すでに v4.0 の概要を把握している場合は次節（要件本文）へ進んでください。
v3.2.1 から v4.0／v4.0.1 への変更点
PCI DSS v4.0 は 2022 年 3 月に公開され、12 要件の枠組みは維持したまま、64 の新規要件と「カスタマイズドアプローチ」（従来の要件文言に厳密に従わずに同等の統制を実現する経路）が加わりました。
64 の新規要件のうち 13 件は公開時点で即時適用、残る 51 件は future-dated requirements として 2025 年 3 月 31 日まで「ベストプラクティス」扱いとされ、この期日をもって全面必須化されました。
2024 年 6 月 11 日には v4.0.1 が公開され、記述の明確化と誤植修正を中心とした改訂となりました。v4.0.1 に新規要件の追加はなく、6.4.3／11.6.1 を含む要件番号も v4.0 から変わっていません。2024 年 12 月 31 日をもって v4.0 は廃止されており、2025 年 1 月 1 日以降の準拠評価では v4.0.1 が唯一の有効版として使われます。
- 参考資料：Coffee with the Council Podcast: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025｜PCI Security Standards Council（2025 年 3 月 26 日）
- 参考資料：PCI DSS の基本説明（2025 年 3 月 12 日版）｜日本カード情報セキュリティ協議会（JCDSC）
移行タイムライン
本記事の前提となる主要な期日を年月日で整理します。日付は PCI SSC の公式発表および JCDSC 資料に基づきます。
| 年月日 | できごと |
|---|---|
| 2022 年 3 月 31 日 | PCI DSS v4.0 公開 |
| 2024 年 3 月 31 日 | v3.2.1 廃止（以降の準拠評価は v4.0 系に一本化） |
| 2024 年 6 月 11 日 | v4.0.1 公開（記述明確化・誤植修正、要件番号は v4.0 と共通） |
| 2024 年 12 月 31 日 | v4.0 廃止（2025 年 1 月 1 日以降は v4.0.1 のみ有効） |
| 2025 年 3 月 31 日 | future-dated 51 要件の全面必須化（6.4.3／11.6.1 を含む） |
| 2025 年 4 月 1 日 | SAQ A 適格性条件の改定発効（詳細は本記事「SAQ A 適格性の 2025 年 4 月 1 日改定」の節） |
6.4.3 と 11.6.1 の要件本文（PCI DSS v4.0.1 の逐語）
6.4.3 と 11.6.1 の要件本文は、PCI SSC 公表の原文で押さえておくと、自社の実装や決済代行との会話がぶれません。ここでは PCI DSS v4.0.1（Requirements and Testing Procedures、英語版）の該当条項を公式文書から逐語で示します。
日本語版 PDF（PCI SSC 日本語版）も公開されており、末尾「公式ドキュメントと出典一覧」から参照できます。v4.0 と v4.0.1 で 6.4.3 / 11.6.1 の要件番号・本文は変わっていません。
6.4.3 の要件本文（決済ページの全スクリプトのインベントリ・認可・完全性チェック）
PCI DSS v4.0.1 の 6.4.3 は、消費者のブラウザで読み込まれ実行されるすべての決済ページ用スクリプトに対して、3 つの統制を求めています。
All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
PCI Security Standards Council, Payment Card Industry Data Security Standard — Requirements and Testing Procedures, v4.0.1（2024 年 6 月）Requirement 6.4.3
• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
https://www.pcisecuritystandards.org/document_library/?category=pcidss
ここで求められている「決済ページ用スクリプト」の対象は、自社ドメインから配信する自前のスクリプト（ファーストパーティ）だけでなく、決済ページに読み込まれる第三者スクリプト（サードパーティ：解析タグ・A／B テスト・チャット・広告タグ等）、および第三者スクリプトが実行時にさらに読み込むスクリプト（フォースパーティ）まで含みます。
自社が直接契約していない事業者のスクリプトまで棚卸しの範囲に入る点が実務上の焦点になります。
11.6.1 の要件本文（決済ページの HTTP ヘッダとコンテンツの改ざん検知）
PCI DSS v4.0.1 の 11.6.1 は、決済ページに対する改ざん検知メカニズムの導入と、検知の実行頻度を求めます。
A change- and tamper-detection mechanism is deployed as follows:
PCI Security Standards Council, Payment Card Industry Data Security Standard — Requirements and Testing Procedures, v4.0.1（2024 年 6 月）Requirement 11.6.1
• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
• The mechanism is configured to evaluate the received HTTP header and payment page.
• The mechanism functions are performed as follows:
— At least once every seven days
OR
— Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
https://www.pcisecuritystandards.org/document_library/?category=pcidss
検知の対象は「消費者ブラウザが受信する」HTTP ヘッダと決済ページの内容です。決済ページで実行される JS スクリプトの変更・追加・削除に加え、Content-Security-Policy／X-Frame-Options 等のセキュリティヘッダの脱落や書き換えも検出対象になります。
頻度は 7 日ごと（週次）が既定で、要件 12.3.1 に基づく組織のリスク分析で別頻度を定めた場合はその頻度が適用されます。
EC 決済ページの接続方式別マトリクス（6.4.3／11.6.1／SAQ 種類／実装負担）
6.4.3 と 11.6.1 の適用可否は、自社の決済ページが決済代行事業者（TPSP：Third-Party Service Provider）とどう接続しているかで変わります。同じ EC 事業者でも、TPSP の JS を自社ドメインで動かしているのか、iframe に閉じ込めているのか、外部ページへ完全に飛ばしているのかで、要件の適用範囲・SAQ 種類・実装負担が接続方式ごとに異なります。
次のマトリクスは、EC 決済ページの主要な接続方式ごとに、6.4.3／11.6.1 が事業者側に直接適用されるか、想定される SAQ 種類、実装負担の目安を整理したものです。各行の詳細は下の H3 で解説します。
SAQ（Self-Assessment Questionnaire、自己問診票）は、事業者の構成によって複数の種類があります。本記事で言及する主なものは次の 3 つです。
- SAQ A：EC カード決済を完全にアウトソースしている加盟店向け（最も簡便）
- SAQ A-EP：決済処理は外部委託しているが、EC サイトが決済トランザクションに影響する加盟店向け（SAQ A より詳細）
- SAQ D-Merchant：自社ホスト型で PAN を直接扱う等、上記に当てはまらない加盟店向け（12 要件全域が対象）
| 接続方式 | 6.4.3 適用 | 11.6.1 適用 | 想定 SAQ | 事業者の実装負担 |
|---|---|---|---|---|
| JS 型（TPSP 提供 JS を自社ドメインで実行） | 直接適用 | 直接適用 | SAQ A-EP または D | 大：CSP／SRI／改ざん検知の実装と運用が必要 |
| 自社ホスト型（自社ドメインで PAN を受け付け TPSP に転送） | 直接適用 | 直接適用 | SAQ D-Merchant | 最大：12 要件全域＋ CDE 全体のセキュリティ運用 |
| iframe 型（TPSP の iframe に PAN 入力を委ねる） | 直接適用（TPSP の確認で緩和可） | 直接適用（同上） | SAQ A（適格性条件の充足が前提） | 中：TPSP のスクリプト攻撃対策の確認・記録＋自社側の HTTP ヘッダ改ざん検知 |
| リンク型・リダイレクト型（外部ページへ遷移） | 対象外（適格性追加条件も対象外） | 対象外 | SAQ A（適格性の追加条件は非適用） | 小：TPSP 側の PCI DSS 準拠状況の確認 |
| 非通過型（PAN を自社が扱わない完全アウトソース） | 対象外 | 対象外 | SAQ A | 小：TPSP 選定と契約管理 |
JS 型（TPSP 提供 JS を自社ページで動かす）
TPSP が提供するトークン化 JS（Stripe.js、Adyen Web Components、Braintree.js のような JavaScript SDK）を、自社ドメインの決済ページ内で読み込んで動かす方式です。
PAN（Primary Account Number、カード番号）そのものは TPSP が発行するトークン経由で扱うため CDE（Cardholder Data Environment、カード会員データ環境）は縮小されますが、決済ページで実行される JS は自社ドメインで動くため、6.4.3／11.6.1 の対象は事業者側に直接残ります。
SAQ は A-EP または D の適用が想定されます。CSP（Content-Security-Policy）による認可、SRI（Subresource Integrity）による完全性チェック、専用ツールでの改ざん検知など、決済ページ側の実装と運用体制の構築が実装負担の中心です。
既存の解析タグ・広告タグを決済ページに残しているケースでは、これらも 6.4.3 のインベントリ・認可対象になる点に注意してください。
自社ホスト型（自社ドメインで PAN を直接受け付ける）
自社の決済ページで PAN（カード番号）の入力を直接受け付け、サーバ側で TPSP に送信する方式です。ECサイトが独自の決済フォームを持ち、バックエンド API 経由で決済代行を呼ぶような構成が該当します。この場合、CDE は自社側にも及ぶため PCI DSS の 12 要件全域が対象になり、SAQ は D-Merchant で申告するのが一般的です。
6.4.3／11.6.1 も当然直接適用されます。実装負担は最大で、CDE 全体のセキュリティ運用に加えて決済ページのスクリプト管理・改ざん検知の運用が求められます。iframe 型やリンク型への切り替えを検討する余地がもっとも大きい構成です。
iframe 型（TPSP の iframe に PAN 入力を委ねる）
自社の決済ページ内に TPSP が提供する iframe を埋め込み、PAN の入力・送信は iframe の内側（TPSP のドメイン）で完結する方式です。
PAN が自社ドメインを通らないため CDE は縮小され、SAQ A の対象になり得ますが、その適格性は 2025 年 4 月 1 日改定の追加条件を満たすことが前提です（詳細は「SAQ A 適格性の 2025 年 4 月 1 日改定と 6.4.3／11.6.1 の関係」の節）。
6.4.3／11.6.1 は形式上直接適用されますが、PCI SSC 公式 FAQ は、PCI DSS 準拠済み TPSP がスクリプト攻撃対策を実装していることを事業者が確認・記録できれば、事業者側の実装は「TPSP 実装の確認」に置き換えられる旨を明示しています。
自社側の実装負担は、TPSP 側の対策実装状況の確認・記録と、iframe を囲む親ページの HTTP ヘッダ改ざん検知が中心になります。
リンク型・リダイレクト型（TPSP の外部ページへ遷移）
「お支払いへ進む」ボタン等から HTTP リダイレクト・meta リダイレクト・JavaScript リダイレクトのいずれかで TPSP の外部決済ページへ遷移させ、PAN の入力から決済完了まで TPSP のドメインで完結させる方式です。自社ドメインには決済ページが存在しないため、6.4.3／11.6.1 の適用対象外となります。
SAQ は A で申告できます。2025 年 4 月 1 日改定で追加された「サイトがスクリプト攻撃の影響を受けないことを事業者が確認する」条件も、PCI SSC 公式 FAQ が明示的に「HTTP リダイレクト・meta リダイレクト・JavaScript リダイレクトで TPSP に遷移させる EC 事業者、および外部決済サイトへのリンクを提供する EC 事業者」を対象外と定めています。
実装負担は最小で、選定した TPSP が PCI DSS 準拠であることの確認・記録が中心です。
非通過型（PAN を自社が扱わない完全アウトソース）
ここでは PAN が自社のサーバ・ネットワークをまったく通過しない構成を指します。実装上はリンク型・リダイレクト型に近く、決済導線の起点だけを自社が提供し、以降を完全に TPSP に委ねる形です。6.4.3／11.6.1 は適用対象外で、SAQ は A で対応できます。
実装負担は TPSP 選定と契約管理・準拠状況の定期確認に絞られます。カード情報のクレジットカード・セキュリティガイドライン（日本クレジット協会）で示される「非保持化」の実装形態と重なることが多く、割賦販売法の実務対応と連動して検討しやすい構成です。
- 参考資料：FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants｜PCI Security Standards Council（2025 年 2 月 28 日）
- 参考資料：Self-Assessment Questionnaire A｜PCI Security Standards Council
自社決済ページの接続方式を判定するチェック手順
「iframe に逃がしているつもりが、実は自社ドメインで動いているスクリプトが残っている」といった実装のねじれは珍しくありません。上のマトリクスに自社を当てはめる前に、次の手順で決済ページの実装状況を確認してください。判断が難しい場合は、Web 開発担当者や決済代行会社との会話に持ち込むためのチェックリストとしても使えます。
- 決済フォーム（カード番号の入力欄）は自社ドメインか、TPSP ドメインか：ブラウザで決済ページを開き、カード番号入力欄を選択して「要素を検査」で親要素を辿ります。
iframe要素の内側にあり src が TPSP のドメイン（例：https://cardpay.example-psp.com/）なら iframe 型。iframeではなく自社ドメイン内のform要素内にあれば、自社ホスト型か JS 型のいずれかです。決済フォームの前に別ページへ遷移するなら、リンク型・リダイレクト型に該当します。 - PAN はサーバ側で自社を通過するか：カード番号入力後の POST 先が自社ドメインか（例：
https://自社.example.com/checkout/pay）、TPSP ドメインか（例：https://api.example-psp.com/tokenize）を Network タブで確認します。自社ドメインへ POST しているなら自社ホスト型、TPSP へ POST しているなら JS 型・iframe 型・リンク型のいずれかです。 - TPSP の JS を自社決済ページで読み込んでいるか：決済ページの HTML を「ページのソースを表示」で開き、
<script src="...">を確認します。TPSP のドメイン（例：https://js.example-psp.com/v3/checkout.js）から JS を読み込んで自社ドメイン内で動かしているなら JS 型に該当し、6.4.3／11.6.1 が事業者側に直接適用されます。 - 解析タグ・広告タグ・A／B テストツールは決済ページに読み込まれているか：Google Analytics、Google Tag Manager、A／B テストツール、チャットウィジェット、広告タグ（Meta Pixel など）が決済ページで動いている場合、それらも 6.4.3 の管理対象になります。決済ページからは原則としてこれらを外す（タグマネの発火条件で決済ページを除外する）ことが実装負担を減らす早道です。
各判定の結果に対応する 6.4.3／11.6.1 の適用と SAQ 種類は、前節「EC 決済ページの接続方式別マトリクス」の該当行に対応させて確認してください。判定に迷ったら決済代行会社に接続方式を明示的に確認する（本記事「次の行動」節に確認事項サンプルを掲載）のが確実です。
SAQ A 適格性の 2025 年 4 月 1 日改定と 6.4.3／11.6.1 の関係
2025 年 4 月 1 日から、SAQ A（自己問診 A、簡易版）で申告できる EC 事業者の適格性条件が改定されました。改定後の SAQ A では「サイトがスクリプト攻撃の影響を受けないことを事業者が確認する」条件が追加されており、この条件と 6.4.3／11.6.1 の関係は接続方式によって扱いが分岐します。PCI SSC の公式 FAQ が対象範囲を明示しているため、その原文で確認します。
This SAQ A eligibility criteria does not apply to e-commerce merchants with a webpage that redirects customers from the merchant’s webpage to a TPSP/payment processor (for example, including but not limited to, with an HTTP 30x redirect, a meta redirect tag, or a JavaScript redirect) or e-commerce merchants that fully outsource payment functions to a TPSP/payment processor (for example, by providing customers with an email with a link to a TPSP’s website to pay).
PCI Security Standards Council, FAQ 1588（FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants、2025 年 2 月 28 日ブログで公表）
Note that the SAQ A eligibility criteria only applies to e-commerce merchants with a webpage that includes a TPSP’s/payment processor’s embedded payment page/form (for example, one or more inline frame(s) (iframes)).
https://www.pcisecuritystandards.org/faqs/1588/
公式 FAQ の記述を接続方式別に整理すると、次の 3 分岐になります。
- リンク型・リダイレクト型・非通過型：適格性の追加条件は非適用（対象外）。従来通り SAQ A で申告でき、6.4.3／11.6.1 も適用対象外です。
- iframe 型（TPSP の決済ページ／フォームを埋め込む）：PCI DSS 準拠済み TPSP がスクリプト攻撃対策を実装していることを事業者が確認する必要があります。確認できれば SAQ A の適格性を維持できます。6.4.3／11.6.1 は形式上直接適用されますが、事業者側の実装は「TPSP 実装の確認・記録」に置き換えられます。
- JS 型：自社ドメインで TPSP 提供 JS が動作するため SAQ A の適格性はありません。SAQ A-EP または D での申告となり、6.4.3／11.6.1 の実装は事業者自身が担います。
- 自社ホスト型：自社ドメインで PAN を直接受け付けるため SAQ D-Merchant での申告となり、6.4.3／11.6.1 に加えて 12 要件全域が対象になります。
iframe 型で SAQ A を維持したい場合、TPSP から「決済ページに読み込まれるスクリプトの認可・完全性チェックの実装内容」「HTTP ヘッダ・コンテンツの改ざん検知の実装内容と検知頻度」「PCI DSS 準拠評価の最新レポート（AOC）」を書面で受け取り、社内で保管する運用が現実的です。決済代行会社への確認事項サンプルは、本記事「次の行動」節に掲載しています。
6.4.3（スクリプト管理）の対応手法
6.4.3 が求めるのは、決済ページに読み込まれる全スクリプトについて①インベントリ管理、②各スクリプトの認可、③各スクリプトの完全性チェック、の 3 つです。ここでは 3 要件別に必要な対応と、実装で使える主要な手法を対比します。
3 要件別（インベントリ管理・認可・完全性チェック）に必要な対応
PCI SSC のガイダンス文書 Payment Page Security and Preventing E-Skimming は、6.4.3 が求める 3 要件の粒度を次のように示しています。
- インベントリ管理：決済ページで読み込まれる全スクリプトを一覧化し、それぞれについて「なぜ必要か」の書面による正当化理由を記録します。自社ドメインから配信するファーストパーティ、直接契約のあるサードパーティ、それらが実行時に読み込むフォースパーティまでが対象です。棚卸しは新規スクリプトの追加・既存スクリプトの変更をトリガーに更新する運用が必要です。
- 認可（Authorization）：各スクリプトについて、事業者が読み込みを認可していることを確認できる仕組みが必要です。承認の記録は「誰が」「いつ」「どのバージョンを」認可したかを追跡できる形で保持します。認可されたスクリプトのみが読み込まれる状態であることを確認できるよう、許可リスト＋ CSP による遮断・変更検知＋アラート等を組み合わせて運用することが実務上の選択肢です。
- 完全性チェック（Integrity）：認可済みスクリプトが改ざんされていないことを、ブラウザでの読み込み時に検証する仕組みが必要です。Subresource Integrity（SRI）でスクリプトのハッシュ値を検証する、専用ツールで挙動を監視する、など複数の手法があります。
対応手法の対比（CSP／SRI／タグマネ棚卸し／専用ツール／サプライチェーン管理）
3 要件を実装で満たすには、次の手法を組み合わせるのが一般的です。それぞれの手法がカバーする範囲と限界を整理します。
| 手法 | 主に対応する 6.4.3 要件 | 強み | 限界・注意点 |
|---|---|---|---|
| Content-Security-Policy（CSP） | 認可 | ブラウザ側で許可リスト外のドメインからのスクリプト読み込みを遮断できる | 初期設定と運用（許可リストの継続更新）に工数。同一ドメインからの悪意あるスクリプトは検知できない |
| Subresource Integrity（SRI） | 完全性チェック | スクリプトのハッシュ値検証で改ざんを検出。実装は script タグの integrity 属性のみで軽い | 頻繁に更新される TPSP 提供 JS には不向き（ハッシュ更新の運用負担が大きい） |
| タグマネジメントの棚卸し・発火条件見直し | インベントリ管理・認可 | 決済ページからの不要タグ除外で 6.4.3 のスコープを縮小できる | タグマネで管理していない直接埋め込みタグには効かない |
| 専用ツール（PCI DSS 対応の Web 監視ツール） | 3 要件すべて | スクリプトの自動棚卸し・変更検知・レポートを一気通貫で提供 | ライセンス費用が発生。自社の技術スタックとの相性確認が必要 |
| サプライチェーン管理（TPSP・広告事業者との契約） | 認可（フォースパーティ対応） | フォースパーティが読み込まれる可能性がある場合、契約で挙動制約を明示できる | 実効性は相手方の運用に依存。契約だけで完結せず技術的な監視と併用 |
11.6.1（改ざん検知）の対応手法
11.6.1 は決済ページの HTTP ヘッダとコンテンツの改ざん検知メカニズムを求めます。ここでは PCI SSC のガイダンス文書と、セキュリティベンダー各社が公開している対応手法の整理を踏まえ、実装で選択できる主要手法を 4 種にまとめます。さらに、同じ手法でも接続方式によって実装負担・実効性が変わるため、接続方式軸とのクロス表で選び方を示します。
対応手法 4 種の概要（CSP／プロキシ／専用ソリューション／外部コンテンツ禁止）
11.6.1 の実装で選択できる主要な手法は次の 4 種です。
- CSP（Content-Security-Policy）による違反レポート受信：CSP の report-uri／report-to ディレクティブで、決済ページで発生したポリシー違反（許可外スクリプトの読み込み試行など）をレポート受信します。改ざんの兆候を検出できる一方、CSP 自体の設定変更や HTTP ヘッダ削除は別途検出する必要があります。
- プロキシ経由の監視：決済ページへのアクセスをプロキシ経由に集約し、プロキシ側でヘッダ・コンテンツを定期取得して差分を検出します。既存インフラに組み込みやすい反面、TPSP の iframe など外部リソースを跨ぐ検知には別の仕組みが必要です。
- 専用ソリューション（Feroot・Jscrambler・Human Security 等）：合成監視エージェントが定期的に決済ページを開き、ブラウザで受信した HTTP ヘッダと DOM を実際にキャプチャして改ざんを検知します。6.4.3 と 11.6.1 を一気通貫でカバーする製品が多く、運用の一元化が可能です。
- 外部コンテンツの禁止（決済ページからの外部読み込みを一切禁止）：決済ページを自社ドメインの静的コンテンツのみで構成し、外部スクリプト・広告タグ・チャット等を一切読み込まない構成です。改ざんの発生源を絞れる代わりに、既存の解析・広告基盤との整合を再設計する必要があります。
接続方式別に適した対応手法の選び方
同じ対応手法でも、自社の接続方式によって実装負担と実効性が変わります。次のクロス表で、接続方式別に適した手法の組み合わせを整理します。
| 接続方式 | CSP レポート | プロキシ経由監視 | 専用ソリューション | 外部コンテンツ禁止 |
|---|---|---|---|---|
| JS 型 | ◎ 認可の主軸として必須 | △ TPSP 提供 JS の中身までは追いにくい | ◎ 6.4.3 と一体化でき最も現実的 | △ TPSP JS の読み込みは必要なため厳格化困難 |
| 自社ホスト型 | ◎ CDE 全体の保護に有効 | ◎ 自社インフラで完結できる | ◎ CDE 保護と一体化 | ◎ 実装可能性が高い |
| iframe 型 | ◯ 親ページの HTTP ヘッダ保護に有効 | △ iframe 内部は追えない | ◯ 親ページ側の改ざん検知に活用 | ◯ 親ページから外部タグを外せば効果大 |
| リンク型・リダイレクト型 | N/A（対象外） | N/A | N/A | N/A |
| 非通過型 | N/A（対象外） | N/A | N/A | N/A |
JS 型・自社ホスト型は自社の実装負担が最も重く、CSP と専用ソリューションの併用が現実的な選択肢になります。iframe 型は親ページ側の改ざん検知のみに絞れるため、決済ページから解析・広告タグを外すことで運用負担を軽減できます。リンク型・非通過型は 11.6.1 の対象外です。
未対応のまま放置した場合のリスク
2025 年 3 月 31 日を過ぎて 6.4.3／11.6.1 に未対応のまま運用を続けている場合、罰則・決済代行契約・監査上の扱いにどう影響するかを整理します。
まず、PCI DSS は業界標準（カードブランドとアクワイアラが定めるコンプライアンス基準）であり、国内法上の直接的な罰則はありません。
ただし、日本国内では割賦販売法（改正割賦販売法）に基づく「クレジットカード・セキュリティガイドライン」（一般社団法人日本クレジット協会）が加盟店にカード情報の適切な取り扱いを求めており、EC 事業者はガイドラインが示す「非保持化」または PCI DSS 準拠のいずれかで対応することが実務上の基準になっています。
同ガイドラインは PCI SSC の基準変更に整合して版が改訂されており、6.4.3／11.6.1 対応も PCI DSS 準拠経路の一部として反映されます。
決済代行会社との関係では、加盟店契約に PCI DSS 準拠義務が盛り込まれているケースが多く、未対応が続くと契約上の是正要求・追加報告義務・最悪の場合は契約解除に至る可能性が想定されます。実際の扱いは決済代行会社ごとに異なるため、契約書の該当条項の確認と、決済代行会社への現状報告・対応方針の相談が最初の一歩になります。
監査面では、PCI DSS の外部評価（QSA による ROC（Report on Compliance、外部評価報告書））や自己問診（SAQ）で未対応項目があると、指摘事項として記録され、是正計画の提出が求められます。SAQ A で申告している事業者が iframe 型・JS 型に該当していた場合、適格性の再判定が入ることもあり得ます。
次の行動
ここまでの内容を踏まえて、記事を閉じたあとに実際に進められる行動を 3 つに分けて示します。決済代行会社との会話に必要な要件番号入り確認事項、社内で完結するタグマネ棚卸しの手順、外部相談の目安です。
決済代行会社への確認事項サンプル（要件番号入り実文例）
接続方式の判定と TPSP 側の 6.4.3／11.6.1 対応状況を確認するため、決済代行会社に次のような質問を投げると会話が前に進みます。文面はそのままコピー＆ペーストで利用できます。
- 「弊社の決済ページの接続方式について、iframe 型・リンク型・JS 型・自社ホスト型のいずれに該当するかを明示的に教えてください。」
- 「PCI DSS v4.0.1 の 6.4.3（決済ページの全スクリプトの認可・完全性チェック・インベントリ管理）について、貴社の実装で弊社側の対応が不要となる範囲を教えてください。iframe 型の場合、SAQ A 適格性維持のために弊社側が保管すべき確認書類も併せて教えてください。」
- 「PCI DSS v4.0.1 の 11.6.1（決済ページの HTTP ヘッダとコンテンツの改ざん検知・7 日ごとまたはリスク分析に基づく頻度）について、貴社側で実装している範囲と検知頻度を教えてください。弊社側で追加実装が必要な範囲があれば併せて教えてください。」
- 「貴社の最新の PCI DSS 準拠評価（AOC）を書面で提供いただけますか。SAQ A 適格性の 2025 年 4 月 1 日改定への対応状況も併せて確認したいです。」
タグマネ棚卸しの進め方
決済ページで読み込まれる解析タグ・広告タグ・A／B テストツール・チャット等は、そのまま残すと 6.4.3 のインベントリ・認可対象になります。決済ページから外せるものを外していく棚卸しは、社内で完結する対応の中で最も費用対効果が高い施策です。次の手順で進められます。
- Google Tag Manager など既存のタグマネで、決済ページ URL でトリガーされているタグを一覧化する
- 各タグについて「決済ページで発火する必要があるか」を業務側（マーケ・分析・CS）に確認し、不要なものは発火条件（ページ URL）から決済ページを除外する
- 直接埋め込みタグ（HTML テンプレートに書かれているスクリプト）についても、Web 開発担当と決済ページからの除去可否を確認する
- 棚卸し後に残ったタグを「決済ページで動作するスクリプト」インベントリに記録し、それぞれの必要性・認可者・認可日を書面化する
QSA・専門家への相談を検討すべきケース
次のいずれかに該当する場合は、QSA（PCI DSS の認定審査員）や PCI 対応の実績があるコンサルへの相談を早めに検討することをおすすめします。
- 自社ホスト型で PAN を自社ドメインで直接受け付けており、CDE の範囲や 12 要件の適用範囲を自社内で判断しきれない
- 決済ページの外部スクリプトが多数あり、社内でインベントリ・認可・完全性チェックを設計・運用する体制が組めない
- SAQ A で申告していたが接続方式の判定が iframe 型・JS 型に傾いており、適格性の再判定が必要
- 決済代行会社への確認結果と自社の実装状況に整合性が取れず、どちらの対応で 6.4.3／11.6.1 を満たすかの切り分けができない
6.4.3／11.6.1 の負担を軽くする決済代行サービス
接続方式マトリクスで確認したとおり、iframe 型・リンク型・非通過型で TPSP を利用すれば、6.4.3／11.6.1 の実装負担を軽減できます。ここでは、iframe 型・ホスト型ペイメントページ・非通過型のいずれかを公式に提供している主要な決済代行サービスを 5 社紹介します。自社ホスト型・JS 型からの切り替えを検討する際の候補としてご確認ください。
| サービス名 | サブスクペイ | Paysys（ペイシス） | PGマルチペイメントサービス | VeriTrans4G | SP.LINKS |
|---|---|---|---|---|---|
| 提供会社 | 株式会社ROBOT PAYMENT | 株式会社ペイメントフォー | GMOペイメントゲートウェイ株式会社 | 株式会社DGフィナンシャルテクノロジー | SP.LINKS株式会社 |
| 主な接続方式 | メールリンク型 （ホスト型ペイメントページ） | メールリンク型／フォーム型／API 連携型 | リンクタイプ Plus（ホスト型）／API 連携 等 | API／トークン／リンク（POP・3G-Web）／メールリンク | EC カート連携／アプリ SDK 等 （カード情報非通過設計） |
| PCI DSS v4.0／4.0.1 対応 | △（決済手段ページは「グローバルセキュリティ基準に準拠」、自社 TECH-BLOG で v4.0 対応の取組みを言及） | △（PCI DSS SAQ Type-D 準拠、v4.0 版番号は公式に非明示） | ◎（公式で「PCI DSS Ver4.0.1 に完全準拠」と版番号ごと明示） | △（PCI DSS 準拠を公式訴求、v4.0 版番号は公式に非明示） | △（2006 年より PCI DSS 準拠を公式訴求、v4.0 版番号は公式に非明示） |
| EMV 3-D セキュア 2.0 | ◎（3Dセキュア2.0 対応・標準搭載・追加料金0円） | ◎（無料で標準対応） | ●（EMV 3D セキュア 2.0 対応、追加料金の明示は公式になし） | ●（3Dセキュア2.0 対応、導入支援「ASUKA-3DS」提供） | ●（EMV 3-D セキュア対応） |
| 対応 EC カート | 要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ | EC-CUBE／Welcart／WooCommerce／Magento／e-shops 等 |
| 詳細情報 | 公式資料を見る | 公式資料を見る | 公式サイト | 公式サイト | 公式サイト |
※2026年7月時点の各社公式サイト（決済代行サービスページ・PCI DSS 準拠ページ・会社概要ページ）にもとづく一般的な整理です。PCI DSS 準拠バージョン・EMV 3-D セキュア 2.0 の対応条件・EC カート連携の対応範囲は最新の各社公式資料でご確認ください。
本記事で挙げた 5 社は iframe 型・リンク型・非通過型を提供する主要サービスの一部です。自社ホスト型・JS 型からの切り替え候補を広く比較したい場合は、実店舗・EC・サブスクなど利用シーン別の選び方や手数料相場を整理した以下の記事も併せてご覧ください。
オンライン決済システムおすすめ36選を徹底比較｜実店舗・EC・サブスク別の選び方
ECサイトやWebサービスの決済手段が少なく、購入直前の離脱（カゴ落ち）に悩んでいませんか。クレジットカードに加えてコンビニ払いやQRコード決済、後払いまで顧客の希望に応えようとすると、決済会社ごとの個別契約や入金管理の手間が膨らみ、決済手…
サブスクペイ（株式会社ROBOT PAYMENT）
継続課金・都度課金の両方に対応するサブスクリプション型 EC 向け決済代行で、株式会社ROBOT PAYMENT が提供しています。決済 URL を発行して購入者を PSP 決済画面へ遷移させる「メールリンク型」（ホスト型ペイメントページ）を標準機能として持ち、PAN を自社側で扱わない構成で運用できます。
公式サイトで PCI DSS 準拠を訴求し、自社の技術ブログで v4.0 対応の取り組みを発信しています。EMV 3-D セキュア 2.0 を追加料金 0 円で標準搭載しており、決済ページ関連要件を TPSP に寄せられる帰結の実物として、iframe 型・リンク型への切り替え候補になります。
Paysys（株式会社ペイメントフォー）
株式会社ペイメントフォーが提供する決済代行サービスで、「Paysys-Mail Link」（メールリンク型）・「PayForm」（フォーム型）・「Paysys-API」（API 連携型）と、接続方式を選べる構成が特徴です。メールリンク型・フォーム型では PAN を Paysys 画面で受け付ける非通過設計となり、自社側の CDE を最小化できます。
PCI DSS SAQ Type-D の準拠を公式サイトで明示しており、EMV 3-D セキュアにも標準対応しています。API 連携型を選べば自社実装で決済フローを組み込む選択肢もあり、接続方式マトリクスの「iframe／ホスト／API 型を選ばせる TPSP」として、読者が接続方式マトリクスの iframe 型・ホスト型・API 型のいずれからでも入れる構成です。
PGマルチペイメントサービス（GMOペイメントゲートウェイ株式会社）
GMOペイメントゲートウェイ株式会社が提供する法人向け総合決済代行サービスで、公式 PCI DSS ページで「PCI DSS Ver4.0.1 に完全準拠」を版番号ごと明示している数少ない例です。本記事の主題である v4.0 対応と直結する情報を公式に発信しているため、iframe 型・ホスト型への切り替え候補として最初に検討対象になります。
開発不要で導入できる「リンクタイプ Plus」（ホスト型ペイメントページ）を提供しており、購入者は自社サイトから GMO ペイメントゲートウェイの決済ページへ遷移する形で PAN 入力を完結できます。連結稼働店舗数は 171,257 店舗（2026 年 3 月末）が導入しています。
VeriTrans4G（株式会社DGフィナンシャルテクノロジー）
株式会社DGフィナンシャルテクノロジー（DG グループ）が提供する EC 向け決済プラットフォームで、公式サイトの「決済代行サービスの接続方式」ページで API・トークン・リンク（POP／3G-Web）・メールリンクの 4 形態を明確に整理・提示している点が特徴です。
トークン方式・リンク方式ではカード情報の非保持・非通過を明示しており、接続方式別に読者が自社構成を選び直すときの受け皿として理解しやすい構成です。
DG グループ全体の決済取扱高は 9.1 兆円（2025 年度実績）です。EC 加盟店から金融機関向けまで幅広い導入実績があります。JS 型・自社ホスト型からリンク型・トークン方式への切り替えを検討する際、接続方式の 4 形態が公式で整理されているため比較しやすい構成です。
SP.LINKS（SP.LINKS株式会社）
旧ソニーペイメントサービスから 2025 年 10 月に社名変更した老舗の決済代行会社で、公式会社概要で「PCI DSS を 2006 年より準拠」と長期の準拠実績を明記しています。カード情報の非通過設計と EMV 3-D セキュア対応を公式に打ち出しており、長期の PCI DSS 準拠実績を公式に開示しています。
EC-CUBE・Welcart・WooCommerce・Magento など主要な EC カートとの連携をカバーしており、既存の EC 基盤の変更を抑えつつ TPSP 側の決済画面を使う構成へ移行できます。自社ホスト型からリンク型・非通過型への切り替えを検討する際、カート連携の面で導入摩擦が少ない点が実用的です。
公式ドキュメントと出典一覧
本記事で引用した PCI SSC の公式ドキュメントと、割賦販売法関連の国内公式資料を末尾にまとめます。要件本文を原文で確認する、SAQ A の適格性条件を最新版で確認する、といった目的でご活用ください。
出典・参考資料（7件）
- PCI Security Standards Council｜Coffee with the Council Podcast: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025（2025 年 3 月 26 日）
- PCI Security Standards Council｜FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants（2025 年 2 月 28 日）
- PCI Security Standards Council｜New Information Supplement: Payment Page Security and Preventing E-Skimming
- PCI Security Standards Council｜Payment Card Industry Data Security Standard — Requirements and Testing Procedures v4.0（日本語版 PDF）
- PCI Security Standards Council｜Self-Assessment Questionnaire A（PDF）
- 日本カード情報セキュリティ協議会（JCDSC）｜PCI DSS の基本説明（2025 年 3 月 12 日版 PDF）
- 一般社団法人日本クレジット協会｜クレジットカード・セキュリティガイドライン【5.0 版】
まとめ
PCI DSS v4.0.1 の 6.4.3 と 11.6.1 は、2025 年 3 月 31 日をもって EC 決済ページに対する正式な要件となりました。適用可否は自社の接続方式（JS 型・自社ホスト型・iframe 型・リンク型・非通過型）によって変わり、SAQ A 適格性の 2025 年 4 月 1 日改定と併せて判定する必要があります。
実装負担を最小化する現実的な選択肢は、iframe 型・リンク型・非通過型を提供する TPSP を選定し、6.4.3／11.6.1 の実装を TPSP 側に寄せることです。まずは接続方式のチェック手順で自社の現状を確認し、決済代行会社への確認事項サンプルを使って TPSP との会話を進めてください。
よくある質問（FAQ）
Q. PCI DSS v4.0 の 6.4.3・11.6.1 とは何ですか？
PCI DSS v4.0 の 6.4.3・11.6.1 は、6.4.3 が決済ページで実行される全スクリプトの認可・完全性チェック・インベントリ管理を、11.6.1 が決済ページの HTTP ヘッダとコンテンツの改ざん検知メカニズムを求める要件で、いずれも 2025 年 3 月 31 日をもって future-dated（ベストプラクティス）扱いから正式な要件へ移行しました。
6.4.3 の対象スクリプトは、自社ドメイン配信のファーストパーティ・第三者スクリプト（サードパーティ）・第三者スクリプトが実行時にさらに読み込むフォースパーティまでを含みます。11.6.1 の検知頻度は 7 日ごとが既定で、要件 12.3.1 に基づく組織のリスク分析で別頻度を定めた場合はその頻度が適用されます。
要件本文の逐語は本記事「6.4.3 と 11.6.1 の要件本文」の節に PCI SSC 公式 PDF から引用しています。
Q. iframe 型で TPSP の決済ページを埋め込んでいる EC 事業者も、PCI DSS v4.0 の 6.4.3・11.6.1 への対応は必要ですか？
iframe 型の EC 事業者にも 6.4.3・11.6.1 は形式上直接適用されますが、PCI DSS 準拠済み TPSP がスクリプト攻撃対策を実装していることを事業者が確認・記録できれば、自社側の実装は「TPSP 実装の確認」に置き換えられます（PCI SSC 公式 FAQ、2025 年 2 月 28 日）。
実務としては TPSP から「決済ページに読み込まれるスクリプトの認可・完全性チェックの実装内容」「HTTP ヘッダ・コンテンツの改ざん検知の実装内容と検知頻度」「最新の AOC（PCI DSS 準拠評価レポート）」を書面で受け取り、社内で保管する運用が現実的です。ただし iframe を囲む親ページ側の HTTP ヘッダ改ざん検知は自社側に残る点に注意してください。
Q. 自社の決済ページが PCI DSS v4.0 の 6.4.3・11.6.1 対応済みかを、決済代行会社に確認するには何を聞けばよいですか？
決済代行会社への確認では、①接続方式（iframe 型・リンク型・JS 型・自社ホスト型のいずれか）、②6.4.3 で自社側の対応が不要となる範囲、③11.6.1 の実装内容と検知頻度、④最新の AOC の提供可否、の 4 点を要件番号入りで質問するのが実務的です。
要件番号（6.4.3／11.6.1）を明示して聞くことで、決済代行側の回答が抽象的な「PCI DSS 準拠」ではなく、条項レベルの分担が確認できるレベルまで具体化します。そのままコピー＆ペーストで使える確認事項サンプルは本記事「次の行動」節の「決済代行会社への確認事項サンプル」に掲載しています。
Q. 2025 年 3 月 31 日を過ぎて PCI DSS v4.0 の 6.4.3・11.6.1 に未対応のまま運用を続けた場合、どうなりますか？
PCI DSS は業界標準であり国内法上の直接的な罰則はありませんが、決済代行契約上の是正要求・追加報告義務・最悪の場合の契約解除に至る可能性があり、SAQ／QSA 評価では未対応項目が指摘事項として記録され是正計画の提出が求められます。
日本国内では割賦販売法に基づく「クレジットカード・セキュリティガイドライン」（一般社団法人日本クレジット協会）が EC 事業者に「非保持化」または PCI DSS 準拠のいずれかでの対応を実務基準として求めており、同ガイドラインは PCI SSC の基準変更に整合して改訂されています。
SAQ A で申告している事業者が iframe 型・JS 型に該当していた場合は適格性の再判定が入ることもあり得るため、決済代行契約書の該当条項確認と決済代行会社への現状報告・対応方針の相談が最初の一歩になります。
Q. PCI DSS v4.0 と v4.0.1 で、6.4.3・11.6.1 の要件番号や内容は変わりましたか？
PCI DSS v4.0.1 は 2024 年 6 月 11 日に公開され、記述の明確化と誤植修正を中心とした改訂で新規要件の追加はなく、6.4.3・11.6.1 を含む要件番号は v4.0 から変わっていません。ただし 2024 年 12 月 31 日をもって v4.0 は廃止されており、2025 年 1 月 1 日以降の準拠評価では v4.0.1 が唯一の有効版として使われます。
要件本文を確認するときは v4.0 ではなく v4.0.1 版の PCI SSC 公式 PDF を参照してください（本記事「6.4.3 と 11.6.1 の要件本文」の節に逐語引用と URL を掲載）。
Q. これまで PCI DSS の SAQ A で申告してきた EC 事業者は、2025 年 4 月 1 日改定後も引き続き SAQ A のままでよいですか？
SAQ A のままでよいかは接続方式で分かれます。リンク型・リダイレクト型・非通過型は従来通り SAQ A で申告できます。
iframe 型は「TPSP がスクリプト攻撃対策を実装していることを事業者が確認する」条件を追加で満たす必要があります。JS 型・自社ホスト型は SAQ A の適格性がなく、SAQ A-EP または D-Merchant への切替えが必要です（PCI SSC 公式 FAQ、2025 年 2 月 28 日）。
自社の接続方式が iframe 型・JS 型に傾いているのに SAQ A で申告してきた場合は、適格性の再判定と申告種別の切替えを早めに検討してください。判定手順は本記事「自社決済ページの接続方式を判定するチェック手順」の節を参照できます。
Q. PCI DSS v4.0 では、6.4.2 で WAF が義務化されたと聞きましたが本当ですか？
PCI SSC はWAF を名指しで義務化してはおらず、6.4.2 は「一般公開されている Web アプリケーションを保護する自動化された技術的な仕組み」を求める要件で、WAF はその代表的な実装選択肢のひとつという位置づけです。
ベンダー記事の一部で「WAF が義務化された」と表現されるケースがありますが、要件の文言としては WAF 相当の機能を持つソリューション（クラウド型 WAF・アプリケーションレベルのゲートウェイ等）や自動化された脆弱性検査基盤も選択できます。要件の正確な文言は PCI SSC v4.0.1 公式 PDF の 6.4.2 を直接確認してください。
PCI DSS v4.0 対応の決済代行サービスの料金・手数料を一括チェック
MCB FinTechカタログでは、iframe 型・リンク型・非通過型に対応した決済代行を含む、オンライン決済システム・代行サービスの最新資料を一括で取り寄せられます。PCI DSS v4.0 の 6.4.3／11.6.1 の負担を TPSP 側に寄せる切り替え候補として、下記から資料請求をお申し込みください。
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
