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

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

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

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

申告書はいくつかの対策領域で構成されますが、Webアプリやサービスを自社で開発している事業者が最も手を止めやすいのが、次の項目です。

3. Webアプリケーションの脆弱性対策
脆弱性診断またはペネトレーションテストを定期的に実施し、必要な修正対応を行う。
SQLインジェクションの脆弱性やクロスサイト・スクリプティング（XSS）の脆弱性対策を行う。

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

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

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

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

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

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

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

カード会社やPSPは、加盟店契約を結ぶ（＝決済機能を提供する）にあたり、その加盟店がガイドラインに沿ったセキュリティ対策を実施しているかを確認する責任を負っています。その確認手段が、セキュリティ・チェックリストに基づくセキュリティ対策措置状況申告書です。

事業者はチェックリストの各項目について「実施済み」「実施予定」などの状況を申告し、提出します。これにより、加盟店側は「対策を講じている」ことを示し、カード会社側は「対策済みの加盟店とのみ契約している」ことを担保できる、という仕組みです。

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

まだシステムを開発中で、決済を導入する前の段階でも申告を求められることがあります。この場合は、「決済を導入する前に実施する対策」を申告する形になります。

つまり「今は未実施だが、公開・決済開始までにこう対応する」という計画ベースの申告です。ここで曖昧な回答をすると差し戻しになりやすいため、後述する項目3のように「いつ・何を・どのように実施するか」を具体的に描けるようにしておくことが重要です。

申告書のおおまかな構成――3つの対策領域

申告書で問われる内容は契約先によって細部が異なりますが、大きくは次のような対策領域に整理できます。

①はStripeのようにトークン化・リダイレクト方式でカード情報を自社サーバーに通さない構成にすることで、多くの場合「非保持化」として扱えます。②は本人認証（EMV 3-Dセキュア）の導入が中心です。

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

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

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

1. 脆弱性診断またはペネトレーションテストを定期的に実施し、必要な修正対応を行う
2. SQLインジェクション・クロスサイト・スクリプティング（XSS）などの脆弱性対策を行う

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

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

「定期的に」とは、一般的に年1回以上、あるいはWebアプリケーションに大きな変更を加えたタイミングでの実施が目安とされます。実施すべき診断には主に次の種類があります。

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

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

要求2：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）ヘッダーの設定です。

申告書には「例えば、最新のプラグインの使用（当該脆弱性が無いものが望ましい）やソフトウェアのバージョンアップを行う」とも記載されています。これはフレームワーク・ライブラリ・CMSプラグインを最新の安全なバージョンに保つことを求めているもので、次のような運用が該当します。

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

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

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

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

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

「システムを開発中で、まだ決済を入れていない」段階での申告は、導入前に実施する対策の計画を示すものです。ここでは、開発フェーズ別に「決済を安全に開始するまで」にやるべきことを整理します。

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

よくある質問（FAQ）

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

はい。オンラインでクレジットカード取引を行う事業者であれば、事業規模の大小にかかわらず対応が求められるのが原則です。むしろ小規模事業者は専任のセキュリティ担当者が不在なケースが多く、Webアプリの脆弱性対策が後回しになりやすいため、意識的な対応が重要です。

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

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

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

一般的には年1回以上、あるいはWebアプリケーションに大きな変更（機能追加・改修）を行ったタイミングでの実施が目安とされます。決済フローや個人情報を扱う画面に変更を加えた場合は、その都度診断を検討することが望ましいです。

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

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

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

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

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

セキュアコーディング（パラメータ化クエリ・出力エスケープ・入力バリデーション）を前提に開発を進め、公開前に第三者による脆弱性診断を実施して修正まで行う計画を立てておくことです。申告書には「導入前に実施する対策」として、この計画を具体的に記載できるようにしておきましょう。

まとめ

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

• 背景：オンラインでクレジットカード取引を行う事業者は、クレジット取引セキュリティ対策協議会のガイドライン（改正割賦販売法に基づく）に沿った対策状況を申告する必要がある
• 申告書の構成：大きく「①カード情報の適切な管理（非保持化・PCI DSS）」「②不正利用対策（本人認証）」「③Webアプリケーションの脆弱性対策」の3領域
• つまずきやすい項目3：脆弱性診断・ペネトレーションテストの定期実施と修正対応、SQLインジェクション・XSS対策、ソフトウェアの最新化までが求められる
• 開発中の場合：決済開始前に実施する対策を計画として申告する。公開前の第三者診断がカギ

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

関連記事

• Webアプリ脆弱性診断の費用相場と会社の選び方
• ペネトレーションテストと脆弱性診断の違い――どちらを選ぶべきか
• API脆弱性診断の重要性と実施ポイント
• バイブコーディングのセキュリティリスクと脆弱性診断ガイド

AEVUSに相談する

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

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

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

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