脆弱性情報

クレジットカード決済で必須の申告書（旧セキュリティ・チェックリスト）とは？書き方とWebアプリ脆弱性対策を解説【2026年版】

クレジットカード決済で必須の申告書（旧セキュリティ・チェックリスト）とは？書き方とWebアプリ脆弱性対策を解説【2026年版】

結論――決済導入の「前」に、Webアプリの脆弱性対策の実施証明が求められます

「StripeでWebアプリにクレジットカード決済を入れようとしたら、"セキュリティ・チェックリストに基づく申告書を提出してください"という案内が出てきた」――近年、こうした場面でつまずく事業者が急増しています。

これは決済代行事業者（PSP）やアクワイアラ（カード会社）が独自に課しているハードルではありません。日本では、オンラインでクレジットカード取引を行うすべての事業者が、クレジット取引セキュリティ対策協議会が策定した「クレジットカード・セキュリティガイドライン」に基づき、対策状況の申告を求められる仕組みになっています。

この申告は今も「セキュリティ・チェックリスト」の名前で案内されることがありますが、文書としての「セキュリティ・チェックリスト」（旧附属文書21）は2025年3月に廃止され、附属文書20 別紙b「EC加盟店におけるセキュリティ対策 導入ガイド 補足資料」に統合されました。現在、協議会が示している申告書の様式例は、附属文書20 別紙c「ECサイトのセキュリティ対策実施状況申告書（例）」（1.1版、2026年3月）です。本記事では、これを「申告書」と呼びます。

申告書は「脆弱性対策」「不正ログイン対策」「EMV 3-Dセキュア」の3つで構成されますが、Webアプリやサービスを自社で開発している事業者が最も手を止めやすいのが、脆弱性対策の次の項目です。

③ Webアプリケーションの脆弱性対策
脆弱性診断またはペネトレーションテストを定期的に実施し、必要な修正対応を行う。
SQLインジェクションの脆弱性やクロスサイト・スクリプティングの脆弱性対策として、最新のプラグインの使用やソフトウェアのバージョンアップを行う。
Webアプリケーションを開発またはカスタマイズされている場合には、セキュアコーディング済みであるか、ソースコードレビューを行い確認する。その際は、入力フォームの入力値チェックも行う。

本記事では、この仕組みの背景、申告書のおおまかな構成、そして「項目③をどうやって満たすのか」を、実務で何をすればよいのかまで落とし込んで解説します。

本記事は制度の一般的な解説を目的としたものであり、個別の申告内容や法的な適合性を保証するものではありません。実際の申告要件・様式は契約する決済代行事業者・アクワイアラによって異なります。最終的な提出内容は、契約先の案内に従ってご確認ください。

セキュリティ・チェックリスト（現・申告書）とは何か

クレジット取引セキュリティ対策協議会と「実行計画」

クレジット取引セキュリティ対策協議会は、経済産業省・カード会社・加盟店・決済事業者などが参画し、日本のクレジットカード取引のセキュリティ強化を目的として設立された団体です。同協議会は「クレジットカード・セキュリティガイドライン」（かつて「実行計画」と呼ばれていたものの後継）を毎年更新し、EC加盟店・決済事業者が取るべき対策の指針を示しています。

このガイドラインは、割賦販売法（改正割賦販売法）が求める「クレジットカード番号等の適切な管理」および「不正利用の防止措置」を、実務レベルで具体化したものと位置づけられます。つまり、ガイドラインの対策を講じて申告することは、法令が求めるセキュリティ義務を果たしていることを示すための実務上の枠組みという関係にあります。

「セキュリティ・チェックリスト」は2021年3月に試行運用の資料として作られ、2024年3月に附属文書21になりました。2025年3月のガイドライン6.0版では、EC加盟店の「脆弱性対策」「不正ログイン対策」「EMV 3-Dセキュアの導入」が指針対策に加わり（2025年4月から）、これに合わせてチェックリストは附属文書20 別紙bへ統合、申告書の様式例として別紙cが新設されました。2026年3月の6.1版では指針対策の追加・変更はなく、申告書（例）が1.1版に改訂され、申告書に関するFAQも公表されています。

なぜ「申告書」を出す必要があるのか

カード会社やPSPは、加盟店契約を結ぶ（＝決済機能を提供する）にあたり、その加盟店がガイドラインに沿ったセキュリティ対策を実施しているかを確認する責任を負っています。その確認手段として協議会が様式例を示しているのが、ECサイトのセキュリティ対策実施状況申告書です。実際の様式は契約先ごとに異なり、Stripeのようにアカウント登録の画面で同じ内容を質問する決済代行事業者もあります。

事業者は申告書の各対策について「準拠している」「準拠できていない」のどちらかで実施状況を回答し（不正ログイン対策には「ログイン機能を採用していない」の選択肢もあります）、委託先が対策を担っている場合は委託先の情報も記入して提出します。これにより、加盟店側は「対策を講じている」ことを示し、カード会社側は「対策済みの加盟店とのみ契約している」ことを担保できる、という仕組みです。

「開発中」の場合はどう申告するのか

まだシステムを開発中で、決済を導入する前の段階でも申告を求められることがあります。協議会の申告書（例）では、新規に加盟を申し込む事業者は必要な対策がすべてできていることを確認したうえで、加盟申込書類と一緒に提出する流れになっています。

回答の選択肢にも「実施予定」はありません。「今は未実施だが、公開・決済開始までに対応する」という計画ベースの申告ではなく、申告の時点で対策が済んでいることが前提です。開発中であれば、後述する項目③を含む各対策を、申告より前に終えられるよう「いつ・何を・どのように実施するか」を具体的に描いておくことが重要です。対策が間に合わない場合の扱いは、契約先に確認してください。

申告書のおおまかな構成――脆弱性対策・不正ログイン対策・EMV 3-Dセキュア

申告書で問われる内容は契約先によって細部が異なりますが、協議会の申告書（例）1.1版は次の3つで構成されています。最初に販売方法やEMV 3-Dセキュアの対象外となる取引かを確認し、その回答から導入が必要な対策が判定されます。

対策領域

主な内容

代表的な満たし方

（1）脆弱性対策（①〜⑤をすべて導入）

①システム管理画面のアクセス制限と管理者のID/パスワード管理、②データディレクトリの露見に伴う設定不備への対策、③Webアプリケーションの脆弱性対策、④ウイルス対策ソフトの導入・運用、⑤悪質な有効性確認・クレジットマスターへの対策

管理画面のIPアドレス制限・2段階認証または多要素認証・10回以下のログイン失敗でのアカウントロック、公開ディレクトリとアップロードの制限、定期的な脆弱性診断とソースコードレビュー、ウイルス対策ソフト、別紙aに挙げられた対策の1つ以上

（2）不正ログイン対策（実態に合わせて1つ以上）

会員登録・ログイン認証・属性情報変更の各場面での不正ログイン対策（①〜⑧から実施しているものをすべて選択）

不審なIPアドレスからのアクセス制限、2段階認証または多要素認証、会員登録時の個人情報確認、ログイン試行回数の制限、ログイン時・属性変更時の通知、属性・行動分析、デバイスフィンガープリントなど

（3）EMV 3-Dセキュア

なりすましによる不正利用を防ぐ本人認証

決済代行事業者（PSP）の機能で導入。技術的に導入できない取引、BtoBなど特定の者とのみ取引する場合、公共料金・税金などは対象外

カード情報の「非保持化」（または保持する場合のPCI DSS準拠）は、申告書（例）の設問には含まれていませんが、ガイドラインの指針対策として引き続き求められています。Stripeのようにトークン化・リダイレクト方式でカード情報を自社サーバーに通さない構成にすることで、多くの場合「非保持化」として扱えます。ただし協議会のFAQでは、非保持化を実現している加盟店でも申告書の各対策が必要とされています。EMV 3-Dセキュアは決済代行事業者の機能での導入が中心です。

そして、自社でWebアプリやECサイトを開発している事業者が最も対応に迷うのが、脆弱性対策の項目③です。ここは「サービスを契約すれば終わり」ではなく、自社のアプリケーションそのものの安全性を継続的に確認し続ける必要があるためです。次章で詳しく見ていきます。

項目③「Webアプリケーションの脆弱性対策」をどう満たすか

申告書の項目③は、大きく3つの要求で構成されています。

  1. 脆弱性診断またはペネトレーションテストを定期的に実施し、必要な修正対応を行う
  2. SQLインジェクション・クロスサイト・スクリプティング（XSS）の脆弱性対策として、最新のプラグインの使用やソフトウェアのバージョンアップを行う
  3. Webアプリケーションを開発・カスタマイズしている場合は、セキュアコーディング済みかをソースコードレビューで確認し、入力フォームの入力値チェックも行う

これらは「一度対応すれば終わり」ではなく、継続的に実施していることが求められる点がポイントです。

要求1：脆弱性診断・ペネトレーションテストの「定期実施」

申告書（例）やガイドラインは、「定期的に」の具体的な頻度を定めていません。実務では、年1回以上、あるいはWebアプリケーションに大きな変更を加えたタイミングで実施する運用がよく取られます。契約先が頻度を示している場合は、それに従ってください。実施すべき診断には主に次の種類があります。

診断種別

内容

主な用途

Webアプリケーション脆弱性診断

画面・フォーム・APIに対し、既知の脆弱性パターンを網羅的に検査

申告書の項目③を満たす基本の診断

ペネトレーションテスト

攻撃者視点で実際に侵入を試み、被害範囲まで検証

より高いセキュリティ水準が求められる場合

プラットフォーム診断

サーバー・ミドルウェア・ネットワークの設定不備を検査

基盤側の脆弱性対策

決済フローを持つサイトでは、少なくともWebアプリケーション脆弱性診断を定期的に実施し、検出された問題に修正対応を行い、その記録を残しておくことが申告の裏付けになります。

脆弱性診断とペネトレーションテストは似て非なるものです。どちらを選ぶべきかは、ペネトレーションテストと脆弱性診断の違い――どちらを選ぶべきかで詳しく解説しています。また費用感についてはWebアプリ脆弱性診断の費用相場と会社の選び方をご覧ください。

要求2・3：SQLインジェクション・XSS対策とソースコードレビュー

申告書が名指しで挙げているのが、SQLインジェクションとクロスサイト・スクリプティング（XSS）です。いずれもWebアプリの代表的な脆弱性であり、放置すると顧客情報やカード関連情報の漏洩に直結します。

SQLインジェクションは、ユーザー入力をそのままSQL文に連結してしまうことで、攻撃者が任意のデータベース操作を行えてしまう脆弱性です。

危険なコード例（入力を直接連結している）:

# ユーザー入力をそのままクエリに埋め込んでいる（危険）
def search_orders(keyword):
    query = f"SELECT * FROM orders WHERE product LIKE '%{keyword}%'"
    cursor.execute(query)
    return cursor.fetchall()

対策の基本は、プレースホルダーを使ったパラメータ化クエリ（またはORMの適切な利用）です。

# パラメータ化クエリで入力とSQLを分離する（安全）
def search_orders(keyword):
    query = "SELECT * FROM orders WHERE product LIKE ?"
    cursor.execute(query, (f"%{keyword}%",))
    return cursor.fetchall()

XSS（クロスサイト・スクリプティング）は、ユーザー入力をエスケープせずにHTMLへ出力してしまうことで、攻撃者のスクリプトが他ユーザーのブラウザで実行される脆弱性です。対策の基本は、出力時のエスケープ処理と入力バリデーション、そしてContent-Security-Policy（CSP）ヘッダーの設定です。

申告書は、SQLインジェクション・XSSの対策として「最新のプラグインの使用やソフトウェアのバージョンアップを行う」ことを挙げています。附属文書20 別紙a（セキュリティ対策一覧）では「最新のプラグインの使用（既知の脆弱性が無いものが望ましい）やソフトウェアのバージョンアップを行う。（バージョンアップには必要なセキュリティパッチの適用を含む。）」と説明されています。これはフレームワーク・ライブラリ・CMSプラグインを最新の安全なバージョンに保つことを求めているもので、次のような運用が該当します。

  • 利用しているフレームワーク・ライブラリのバージョンを定期的に更新する
  • npm audit / pip-audit などで依存パッケージの既知脆弱性を確認する
  • WordPressなどのCMSを使う場合、テーマ・プラグインを最新に保ち、不要なものは削除する

3つ目の要求は、Webアプリケーションを自社で開発・カスタマイズしている場合の確認です。申告書には「セキュアコーディング済みであるか、ソースコードレビューを行い確認する。その際は、入力フォームの入力値チェックも行う」とあります。上で挙げたパラメータ化クエリや出力エスケープ、入力バリデーションが実装されているかをリリース前のコードレビューで確かめ、その記録を残しておくと申告の裏付けになります。

「診断して終わり」ではなく「修正対応まで」

見落とされがちですが、項目③が求めているのは「診断の実施」だけでなく「必要な修正対応を行う」ところまでです。診断で脆弱性が見つかったら、優先度をつけて修正し、必要に応じて再診断で修正を確認する――このサイクルまでが対策の一部です。

APIを介した決済・データ連携を行っている場合は、画面だけでなくAPIそのものの診断も重要になります。詳しくはAPI脆弱性診断の重要性と実施ポイントをあわせてご確認ください。

開発中の場合――決済導入「前」にやるべきこと

「システムを開発中で、まだ決済を入れていない」段階でも、申告書を提出する時点では必要な対策が済んでいることが前提です。ここでは、開発フェーズ別に「申告して決済を安全に開始するまで」にやるべきことを整理します。

フェーズ

やること

項目③との対応

設計・実装中

セキュアコーディング（パラメータ化クエリ・出力エスケープ・入力バリデーション）を前提に開発し、ソースコードレビューで確認する

SQLi/XSS対策、ソースコードレビュー・入力値チェック

実装中〜結合前

依存パッケージの脆弱性チェック（npm audit / pip-audit）を継続的に実施

最新バージョンの使用

公開前（決済開始前）

第三者による脆弱性診断を実施し、検出項目を修正

脆弱性診断の実施＋修正対応

決済開始後（運用中）

年1回以上、または大規模改修時など、定期的な診断を継続

定期的な実施

項目③のほか、脆弱性対策の①②④⑤（管理画面のアクセス制限、公開ディレクトリとアップロードの設定、ウイルス対策ソフト、クレジットマスター対策）、不正ログイン対策、EMV 3-Dセキュアも、申告と決済開始の前に済ませておく必要があります。

特に注意したいのは、AIツールや生成コードを使って短期間で開発したWebアプリです。動作はしても、認証の欠如・シークレットのハードコード・SQLインジェクションなどの典型的な脆弱性が残っているケースが少なくありません。決済を扱う前に、必ず第三者の目を通すことをおすすめします。この点はバイブコーディングのセキュリティリスクと脆弱性診断ガイドでも詳しく取り上げています。

カード会員データを保存・処理・伝送する事業者は、PCI DSSへの準拠が求められます。v4.0で何が変わり何を準備すべきかはPCI DSS 4.0対応ガイド【2026年版】変更点と企業が今すぐすべきことで整理しています。

よくある質問（FAQ）

Q1. 小規模なECサイトでも申告書（旧セキュリティ・チェックリスト）への対応は必要ですか？

はい。申告書（例）には「全てのEC加盟店は」ガイドラインに基づいて対策を実施し、その状況を申告する必要があると書かれており、事業規模の大小にかかわらず対応が求められるのが原則です。むしろ小規模事業者は専任のセキュリティ担当者が不在なケースが多く、Webアプリの脆弱性対策が後回しになりやすいため、意識的な対応が重要です。

Q2. Stripeやその他の決済代行を使えば、脆弱性対策は不要になりますか？

いいえ。決済代行サービスを使ってカード情報を「非保持化」できても、それはガイドラインの「カード情報の適切な管理」に関わる部分です。あなたが運用するWebアプリケーションそのもの（会員登録・ログイン・注文フォーム・API等）の脆弱性対策や不正ログイン対策は、引き続き事業者側の責任として求められます。協議会のFAQでも、非保持化を実現している加盟店にも各対策が必要で、申告は加盟店が自ら状況を把握して行うものとされています。

Q3. 「定期的に」とは、どのくらいの頻度で診断すればよいですか？

申告書（例）やガイドラインに具体的な頻度の定めはありません。実務では、年1回以上、あるいはWebアプリケーションに大きな変更（機能追加・改修）を行ったタイミングで実施する運用がよく取られます。契約先が頻度を示している場合は、それに従ってください。決済フローや個人情報を扱う画面に変更を加えた場合は、その都度診断を検討することが望ましいです。

Q4. 自社でOWASP ZAPなどの無料ツールを使えば申告要件を満たせますか？

無料ツールによる自己スキャンは初期チェックとして有効ですが、SQLインジェクションやXSSの検出には、ツールだけでは見落とす箇所（認証後の画面・複雑なロジック・API）が残ります。申告の裏付けとしては、第三者による診断と修正対応の記録を用意しておくほうが確実です。

Q5. 脆弱性診断にはどのくらいの費用がかかりますか？

対象範囲や診断の深さによって幅がありますが、小〜中規模のWebアプリのツール診断で30万〜80万円、認証機能・API・決済フローを含むマニュアル診断で80万〜300万円程度が一つの目安です。詳細は費用相場の記事をご確認ください。

Q6. 開発中でまだ決済を入れていませんが、今から準備すべきことは何ですか？

セキュアコーディング（パラメータ化クエリ・出力エスケープ・入力バリデーション）を前提に開発を進め、公開前に第三者による脆弱性診断を実施して修正まで行う計画を立てておくことです。協議会の申告書（例）では、新規に加盟を申し込む事業者は必要な対策がすべて済んでいることを確認してから提出する流れのため、診断と修正を申告の前に終えられるようスケジュールを組んでおきましょう。

申告書の各対策領域は、それぞれ深掘りした解説記事があります。本人認証（不正利用対策）はEMV 3-Dセキュア（本人認証）とは？2025年義務化対応、カード情報の管理はPCI DSSとは？非保持化との違いをあわせてご覧ください。

2026年に公表された決済ページ改ざん・管理アカウント乗っ取りの実例（インク革命・カインドオル・チャームなど）と、ガイドライン6.1版が求める対策はECサイト・小売のサイバー攻撃事例【2026年版】で時系列にまとめています。

まとめ

この記事では、クレジットカード決済の導入時に求められる申告書（旧セキュリティ・チェックリスト）について解説しました。

  • 背景：オンラインでクレジットカード取引を行う事業者は、クレジット取引セキュリティ対策協議会のガイドライン（改正割賦販売法に基づく）に沿った対策状況を申告する必要がある。2025年4月（6.0版）から脆弱性対策・不正ログイン対策・EMV 3-Dセキュアの導入が指針対策となり、2026年3月の6.1版でも変わっていない
  • 申告書の構成：「脆弱性対策①〜⑤（すべて）」「不正ログイン対策①〜⑧（1つ以上）」「EMV 3-Dセキュア」の3つ。旧「セキュリティ・チェックリスト」は2025年3月に附属文書20 別紙bへ統合され、申告書の様式例は別紙c（1.1版）
  • つまずきやすい項目③：脆弱性診断・ペネトレーションテストの定期実施と修正対応、SQLインジェクション・XSS対策としてのソフトウェアの最新化、自社開発・カスタマイズ時のソースコードレビューと入力値チェックまでが求められる
  • 開発中の場合：申告の時点で必要な対策が済んでいることが前提。公開前の第三者診断と修正がカギ

非保持化とEMV 3-Dセキュアは決済代行サービスの導入で多くをカバーできますが、項目③をはじめとするWebアプリの脆弱性対策は、自社アプリケーションの安全性を継続的に確認し続ける必要がある領域です。ここを「診断して修正する」体制として整えておくことが、申告をスムーズに通し、かつ実際の情報漏洩リスクを下げる両面で重要になります。

関連記事

AEVUSに相談する

「決済を導入したいが、申告書（旧セキュリティ・チェックリスト）の項目③をどう満たせばいいかわからない」「公開前にWebアプリを診てほしい」――そうお考えの方は、AEVUSにご相談ください。

AEVUSでは、SQLインジェクション・XSSをはじめとするWebアプリケーションの脆弱性を網羅的に検査するWebアプリケーション脆弱性診断を提供しています。決済フローや会員機能を含むサイトの診断から、検出された問題への修正アドバイス、定期診断による継続的な対策まで対応可能です。

Webアプリケーション脆弱性診断サービスの詳細を見る →

まずはお気軽にお問い合わせください。現在のシステム構成や決済導入の状況をヒアリングしたうえで、申告書の項目③を満たすための最適な診断プランをご提案します。

← ブログ一覧に戻る

関連記事

「脆弱性情報」の記事をもっと見る →

申告書の「脆弱性対策」、PHPの版数から確認しませんか？

サポート終了版や修正が当たっていないPHPは、カード情報漏えいの入口になります。影響の判定からパッチ適用・移行まで対応します。

PHP脆弱性対応サービスの詳細 対象かどうか30秒で確認する