PJ-T&C合同会社

3分でわかるこの記事の要約

カード情報は「持たない」。そのうえで、残る3つの入口を守る。

本記事は約14,000字あります。先に結論だけ知りたい方のために、弊社がクライアントに推奨している対策の全体像をまとめました。

1

カード情報を自社で持たない

保存だけでなく「処理・通過」もさせない。Stripe-hosted Checkout、PayPal標準決済、Shopifyなど、購入者が決済事業者のページへ遷移する方式を第一選択にする。

2

それでも残る3つの入口を守る

• 自社サイトの管理画面（IP制限・多要素認証）
• 自社サイトの決済ページ（スクリプト監視）
• 決済サービスのアカウントと鍵（2段階認証・制限付きAPIキー）

3

今日から確認できること

• 管理画面・決済サービスの全員が2段階認証を設定しているか
• 退職者・契約終了した制作会社のアカウントが残っていないか
• EMV 3-Dセキュアが有効か

PDFチェックリスト（PDF）をダウンロード決済サービス別・優先度別の47項目。制作会社にそのまま渡せます


KEYフィッシング耐性のある認証を始める複数メーカーの物理セキュリティキーを比較・ご相談 — security.pj-tc.com

※ 上記は対策の全体像です。各項目の根拠と前提条件は本文で説明しています。

序章：2026年10月、フィギュア大手の公式ショップで何が起きたか

2026年10月29日、グッドスマイルカンパニーは公式オンラインショップへの不正アクセスについて第3報を公表しました。同社の公表によれば、不正アクセスは10月19日から22日にかけて発生し、10月23日にシステム開発・保守の委託先からの連絡を受けて同日7時に公式ショップを閉鎖しています。その後の調査で、10月21日13時55分から23日7時までの間、クレジットカード決済ページに不正なプログラムが設置されていたことが判明しました。

同社は、この期間に決済ページでカード情報を入力した可能性を否定できない2,800名に対し、カード名義人名、カード番号（全16桁）、有効期限、セキュリティコードが漏洩した可能性があるとして通知を行っています。内訳には、実際にカード決済で注文した384名、予約後に決済用カードの変更手続きを行った185名のほか、決済を試みたものの完了しなかった方が含まれています。同社は、システム上一部の操作記録が保持されておらず区分を完全に特定できないため、対象を広く取って通知したと説明しています。このほか、過去に公式ショップへカード情報を登録したことがある方について、カード番号の下4桁と有効期限が漏洩した可能性があり、対象となりうるカードは重複を除いて402,466枚とされています（この区分では名義人名・セキュリティコードの漏洩は確認されていません）。

ここで注目したいのは、カード情報を入力したものの購入に至らなかった場合にも、漏洩の可能性があるとされている点です。カード情報を自社のデータベースに保存していなくても、顧客が入力した瞬間に抜き取られる攻撃が存在します。カード情報の「非保持化」は正しい方針ですが、それだけで決済ページが守られるわけではありません。

弊社PJ-T&C合同会社は、クライアント企業に対して「クレジットカード情報は自社システムで保持せず、Stripe・PayPal・Shopifyなどの専門サービスに任せる」ことを一貫して勧めてきました。この方針は今も変わりません。ただし、その方針を勧める側として、「非保持化で何が守られ、何が守られないのか」を正確にお伝えする責任があると考え、2025年12月から2026年10月までに公表された事例をもとに整理しました。本記事は公開前に独立したファクトチェック（2回）を経ています。

本記事は、EC事業を運営する経営者・担当者の方に向けて、技術的な前提知識がなくても読めるように書いています。最後に、弊社がクライアントにお渡ししているチェックリスト（PDF）もご用意しました。なお、本記事で取り上げる事例は各社が公表した事実のみを記載しており、各社の対応を評価するものではありません。調査継続中の事案は、今後内容が更新される可能性があります。

第1章：弊社がクライアントに「カード情報を持たない」ことを勧める理由

まず言葉を整理します。本記事でいう「非保持化」とは、単にカード情報をデータベースに保存しないことではありません。クレジットカード・セキュリティガイドラインが求める非保持化は、自社の機器やネットワークでカード情報を「保存・処理・通過」させないことまでを含みます。自社のフォームでカード番号を受け取り、保存せずに決済事業者へ送る構成は、データベースに残らなくても、この意味での非保持化には当たらない場合があります。

この定義を前提に、弊社が非保持化を勧める理由は3つあります。

1. 盗まれるものを、最初から置かない

どれだけ防御を固めても、侵入の可能性をゼロにすることはできません。その前提に立つと、「侵入されたときに何が盗まれるか」を小さくしておくことが現実的な対策になります。カード番号・有効期限・セキュリティコードを自社システムに保存・通過させていなければ、システムが侵害されても、そこに保存されたカード情報が漏洩するリスクは減らせます。

2. 制度上も求められている

日本では、割賦販売法にもとづく「クレジットカード・セキュリティガイドライン」が、EC加盟店に対してカード情報の非保持化、または国際基準PCI DSSへの準拠を求めています。非保持化によってPCI DSSの準拠範囲を削減できる場合が多い一方、適用される自己問診票（SAQ A、SAQ A-EPなど）は決済の実装構成やアクワイアラー等の判断によって異なります。「非保持化すれば自動的に最も軽い区分になる」とは限らない点は、制作会社や決済代行会社に確認してください。

3. 専門事業者に任せる

Stripe、PayPal、Shopifyといった決済事業者・プラットフォームは、PCI DSSへの準拠状況を公表しており、カード情報の処理を専門的に担っています。中小規模のEC事業者が同じ水準の体制を自前で持つことは、費用面で現実的ではありません。

被害の規模を数字で見る

日本クレジット協会の集計によると、2026年1〜6月のクレジットカード不正利用被害額は221.3億円で、そのうち「番号盗用」が206.1億円（93.1%）を占めています。番号盗用とは、カード現物を使用せず、カード番号等を不正に利用する行為を指します。この統計はカード情報の流出元別には集計されていないため、ECサイトからの流出に由来する金額をここから直接読み取ることはできませんが、番号盗用が被害の大部分を占めていることは分かります。

ここまでが「非保持化は正しい」という話です。次の章では、非保持化を済ませていても、あるいはカード番号全桁が対象外であっても起きた事例を見ていきます。

第2章：それでも漏れる——2025年後半〜2026年の事例が示す3つの型

2025年12月から2026年10月までに国内のEC事業者が公表した事例を、各社の公表資料にもとづいて整理すると、大きく3つの型に分かれます。取り上げる事例には、カード情報の非保持化が行われていたと説明されている事例や、カード番号全桁が漏洩対象外だった事例が含まれます（各社の決済方式の技術的構成までは公表資料から確認できないため、企業ごとに断定はしていません）。以下は各社が公表した事実のみを記載しており、各社の対応を評価するものではありません。公表に踏み切り、調査結果を開示している各社の姿勢は、業界全体にとって貴重な情報源です。

型A：決済ページの改ざん（Webスキミング）

ここでは、決済ページ用のJavaScript（ペイメントアプリケーション）が改ざんされたと公表された事例を取り上げます。画面の見た目は変わらないまま、顧客が入力したカード番号・有効期限・セキュリティコードが攻撃者のサーバーへ送られます。カード情報を自社で保存していなくても、入力の瞬間に抜き取られるため、非保持化だけではこの手口を防ぐことはできません。

なお、ビューティガレージは2026年2月6日にカード会社からの連絡を受けて同日カード決済を停止し、8月19日時点でも漏洩の有無・件数とも調査中、カード決済の停止は6か月を超えています。決済ページの改ざんが確認されたとは公表されていないため、本記事では型Aの確定事例ではなく「調査継続中の関連事案」として位置づけます。

型B：スタッフアカウントの乗っ取り

カード情報は無事でも、会員の氏名・住所・電話番号・購入履歴は自社システムに残っています。管理用のアカウントに正規のログインで入られると、それらが丸ごと取り出されます。

関連事例：顧客アカウントへの不正ログイン（チャーム）

チャームは2026年8月13日に不正アクセスを検知し、9月2日の第3報で、漏洩が確認されたもの約37万件と漏洩のおそれがあるもの約2万件の計約39万件を公表しました（カード情報は含まれていません）。公表で確認できるのは顧客239名への第三者による不正ログインで、その認証情報の入手経路は特定に至っていません。10月7日の第4報では、退会済み顧客の情報約2.5万件について追加の調査結果が公表されています。スタッフアカウントの乗っ取りとは公表されていないため、型Bとは別の「不正アクセス・顧客アカウント侵害」の事例として記載します。

型C：基盤（カートASP）側の侵害

「外部のプラットフォームに任せているから安心」と考えたくなりますが、その基盤自体が侵害されるケースもあります。

個々の店舗が自社サイトに何も手を加えていなくても、基盤側の事案で被害を受けます。この事例では店舗管理画面のログインID・パスワードも対象となっており、基盤側の事案が個々の店舗の管理画面の安全性に直結することを示しています。これは「外部に任せる」ことの否定ではなく、任せた先との連絡経路と責任分界を、平時に確認しておく必要があるということです。

3つの型に共通すること

非保持化は「保存・通過させない」ための対策であり、「入力画面を守る」「管理画面とアカウントを守る」「委託先を管理する」対策とは別物です。第3章では、この3つを使っている決済サービス別に具体的な設定として整理します。

第3章：非保持化とセットで必須の対策（Stripe / PayPal / Shopify / 自社サイト別）

「カード情報を持たない」を実現したあとに残る攻撃面は、①自社サイトの決済ページ、②外部サービスのアカウントと鍵、③自社サイトの管理画面、の3つです。この3つを、使うサービスごとに具体的な設定として整理します。項目には、ガイドライン等で求められているもの、サービスの利用条件になっているもの、一般的な推奨であるものが混在しているため、記事末尾のチェックリストPDFでは根拠の区分と優先度を付けています。すべてを一度に行う必要はありません。

3-1. 決済方式を選ぶ：ホスト型（遷移型）を優先する

判別の基準は「決済事業者のドメインかどうか」ではなく、「購入者が決済事業者のホストページへ遷移するか、自社ページ内に決済事業者のフォームを埋め込むか」です。埋め込み型でもiframeは決済事業者のオリジンを利用するため、ドメインだけでは区別できません。

ホスト型を選べば、自社サイト上でカード情報を直接扱うリスクは減らせます。ただし、自社サイトが侵害された場合に、遷移先のURLを偽装したり購入者を偽ページへ誘導したりする攻撃の可能性は残ります。ホスト型は、遷移先の改ざん・アカウント侵害・設定ミスまで防ぐものではなく、管理画面の防御（3-5）とあわせて初めて意味を持ちます。

3-2. Stripe を使う場合

決済方式

• Stripe-hosted Checkout（Stripeがホストする決済ページへ遷移する方式）を使う。Checkoutには埋め込み型の実装方法もあるため、製品名ではなく実装方式で確認する。Payment Element を使う場合は、決済ページに読み込むスクリプトの管理と改ざん対策（3-5）を入れる。
• Payment Intents API に移行していることを確認する。Stripeの案内では、3Dセキュアに対応できない古いAPI（Charges API、Orders API）を使ったカード決済は、2025年6月30日までに失敗するようになるとされていました。既に過ぎた期限ですが、プラグイン任せで古い実装が残っていないかは確認しておく価値があります。

アカウント防御

• ダッシュボードにログインできる全メンバーが2段階認証（認証アプリ、セキュリティキー、パスキー）を設定する。
• チームメンバーには「管理者」ではなく、業務に応じたロール（開発者、アナリスト、サポート等）を付与する。制作会社との契約終了後も権限が残っていないか確認する。

APIキー

• 全権限を持つシークレットキー（sk_live_）ではなく、用途を絞った制限付きキー（rk_live_）を使う。Stripeは、可能な限り制限付きキーを使うことを推奨しています。すべてのStripe APIが制限付きキーに対応していますが、必要な権限は用途ごとに設定する必要があります。
• サーバーのIPアドレスが固定で、確実に管理できる場合は、キーにIPアドレス制限を設定する。
• キーをソースコードに書かない。攻撃者は公開リポジトリを常時スキャンして露出したキーを探しています。環境変数か秘密管理サービスに置き、.envファイルはバージョン管理の対象外にする。
• 定期的にキーをローテーションする手順を決めておく。旧キーと新キーの併存期間を設けると、切り替えが日常作業になります。
• Webhookの受信処理では、署名シークレット（whsec_）による検証を行う。検証がないと、偽の「決済完了」イベントで注文を確定させられる可能性があります。あわせて、タイムスタンプの許容範囲とイベントの重複処理にも配慮します。

3Dセキュア

• Stripeは、2025年3月末の原則導入に対応するため、対象取引で3Dセキュアを要求する仕組みを提供しています。動的に3DSを要求するRadarのデフォルトルールがダッシュボードで設定できます。
• 注意点として、免除の適用により3DSなしで行われた決済には、不正利用に対するライアビリティシフト（責任の移転）が適用されません。免除取引でも3DSを要求したい場合、PaymentIntentまたはSetupIntentで request_three_d_secure を any に設定する方法があります。ただしこれは3DSを「要求する」設定であり、実際に認証が行われるか、ライアビリティシフトが成立するかは、カード発行会社の判断と取引ごとの認証結果によります。チャージバックの責任分担をどう扱うかは、取引ごとの結果を確認したうえでの判断になります。

3-3. PayPal を使う場合

決済方式

• 標準決済（PayPalボタン／Checkout）を使う。購入者はPayPal側で認証するため、自社サイトにカード情報は触れません。画面遷移の具体的な形は統合方法により異なります。
• カード直接決済（Advanced Credit and Debit Card Payments）は自社ページ内にPayPalのホスト型フィールドを置く方式です。フィールド自体はPayPal側の技術で保護されますが、周囲の自社ページの対策（3-5）は別途必要です。なお旧Website Payments Proは新規受付を終了しており、PayPalは既存ユーザーにEMV 3DS対応のAdvanced Debit and Creditへの移行を案内しています。

アカウント防御

• PayPalアカウントの2段階認証を有効にする。PayPalの開発者向けセキュリティ指針は、アカウントの2FAが開発者ダッシュボードの保護にもなると説明しています。開発者ダッシュボードにアクセスするアカウントも含め、利用者全員の設定を確認します。

API資格情報

• Client Secretはサーバー側でのみ使い、ブラウザ側のコードに含めない。
• 開発者ダッシュボードで資格情報のローテーションができるため、ローテーションのスケジュールを決めておく。使っていない資格情報は削除する。
• Webhookイベントを処理する前に、PayPalの検証APIで署名を確認する。
• SDKを埋め込むページでは、CSPとSRI（3-5）でスクリプトの完全性を担保する。
• アクセストークンや決済情報をログに残さない。

3-4. Shopify を使う場合

Shopifyは決済ページ自体をShopifyが管理するため、加盟店が直接管理する決済ページの範囲は限定されます。ShopifyはPCI DSS Level 1準拠を表明しています。一方で、アカウント・権限、インストール済みアプリ、テーマと外部連携、決済設定と不正注文対応という4つの管理対象は事業者側に残ります。

① アカウントと権限

• Shopify Paymentsで決済を受け付けるには、Shopifyアカウントで2段階認証を有効にする必要があります。未設定の場合、入金が保留される場合があるとShopifyは案内しています。
• Shopifyのヘルプによれば、スタッフは自分のアカウントで2段階認証を設定するものであり、ストアオーナーが他のスタッフに対して有効化することはできません。組織内の全ユーザーに安全なサインイン方法を必須化できるのはShopify Plusプランです。
• Shopifyでは、2段階認証（認証アプリ・セキュリティキー）とパスキーは、いずれも「安全なサインイン方法」に分類されますが、パスキーは2段階認証とは別の方式として扱われています。SMSは新規の2段階認証方式としては設定できません（既存の設定は引き続き利用可能）。
• コラボレーターは、自身のShopifyアカウントで2段階認証を有効にしていないとストアにログインできない仕組みになっています。
• 各スタッフに必要最小限の権限のみを与える。特に「顧客データのエクスポート」ができる人を把握しておく。

② インストール済みアプリ

• アプリを棚卸しし、使っていないアプリを削除する。各アプリが要求する権限（顧客データ・注文データへのアクセス）を確認する。

③ テーマと外部連携

• 制作会社・代理店には、スタッフアカウントではなくコラボレーターアカウントか、Theme Accessアプリを使う。Theme Accessでは、パスワードの受取リンクに期限があり、アクセス権はパスワードの削除によって取り消します。
• チェックアウトの直接編集について：Shopifyの開発者向け文書によれば、情報・配送・決済ステップでのliquid は既にサポート終了しており、サンキューページ・注文状況ページでの checkout.liquid と追加スクリプトは2025年8月28日に廃止されました。従来型の直接スクリプト編集は制限され、Checkout Extensibility、アプリ拡張、Web Pixelsといった許可された拡張機構に移行しています。拡張機構を通じたカスタマイズは残るため、チェックアウトに関わるアプリと拡張の棚卸しは必要です。

④ 決済設定と不正注文対応

• 不正分析機能を確認し、リスクの高い注文の扱い（手動確認・自動キャンセル）を決めておく。

3-5. 自社サイト側（WordPress / EC-CUBE / 自社開発）の共通設定

外部サービスの設定を固めても、侵入は自社サイトから起きます。クレジットカード・セキュリティガイドライン【6.1版】（2026年3月）は、EC加盟店に対して、管理画面のアクセス制限と管理者のID/パスワード管理（IPアドレス制限、二段階認証または多要素認証、ログイン失敗10回以下でのアカウントロック）、Webアプリケーションの脆弱性対策（定期的な脆弱性診断またはペネトレーションテスト、ソフトウェアの更新）などを求めています。

管理画面

• 管理画面URLへのIPアドレス制限を基本とし、固定IPがなく難しい場合は、VPN経由への限定や追加認証など、実効性のあるアクセス制限を設ける
• 全管理者の多要素認証、ログイン失敗10回以内でのロック
• 退職者・契約終了した制作会社のアカウントの即時削除
• CMS本体・プラグイン・テーマの更新と、不要プラグインの削除
• 脆弱性診断は定期的に、また大きな改修時には必要に応じて実施する。頻度は環境・リスク・契約上の要求に応じて決める

多要素認証の方式を選ぶ

多要素認証には、主に次の方式があります。

第2章のカインドオルの事例は、プラットフォーム運営会社を装ったフィッシングメールから偽サイトへ誘導され、認証情報を入力してしまったことが起点でした。同種の認証情報窃取を防ぐ有力な手段として、パスキーや物理キーといったフィッシング耐性のある認証方式（FIDO2/WebAuthn）が考えられます。これらは米国NISTの認証ガイドライン（SP 800-63B）でもフィッシング耐性のある認証方式として位置づけられています。

ただし、前提と限界があります。第一に、利用するサービス（CMS、決済事業者、プラットフォーム）がFIDO2に対応していなければ導入できないため、各サービスの対応状況を確認する必要があります。第二に、FIDO2を有効にしても、パスワードやSMSなどの弱い代替ログイン経路や復旧手順が残っていれば、アカウント全体のフィッシング耐性は確保できません。第三に、FIDO2は認証情報を盗むタイプのフィッシングに有効ですが、ログイン後のセッション窃取、端末の侵害、アプリケーションの脆弱性、決済ページの改ざんを直接防ぐものではありません。管理画面・決済サービスの認証強化に有効な対策の一つとして、本章の他の項目とあわせて位置づけてください。パスキーと物理キーの選択は、共有端末の有無、管理者の人数、紛失時の運用などで決まります。

弊社取扱製品のご案内

弊社では、Swissbit、GoTrust、VinCSS、AuthenTrendなど複数メーカーの物理セキュリティキーを取り扱っています。
初期設定、予備キーの用意、紛失時の復旧手順まで含めた導入のご相談も承ります。

セキュリティキー専用サイトはこちらから↓↓↓

決済ページの改ざん対策

埋め込み型の決済を使う場合は、自社ページが決済フォームの周囲に存在するため、改ざん対策が特に重要になります。PCI DSS上の位置づけを先に整理すると、決済ページのスクリプト管理（要件6.4.3）と改ざん検知（要件11.6.1）は、2025年1月の改訂で、決済を外部委託するSAQ A加盟店の要件からは除外されました。代わりに、第三者の決済フォームを自社ページ内のiframe等に埋め込む加盟店には「サイトがスクリプトによる攻撃の影響を受けないことを確認する」という適格条件が追加されています（完全なホスト型・遷移型には適用されません）。PCI SSCのFAQ 1588は、この条件を満たす方法として、6.4.3・11.6.1相当の技術的対策に加え、PCI DSS準拠の決済サービス提供者から所定の実装方法でスクリプト攻撃への保護が組み込まれている旨の確認を取得する方法も示しています。

技術的対策は、監視できる対象が異なる3つの層に分けて考えます。

第2章のAPORITOの事例は、システム内で不審な外部送信プログラムを発見したことが自社検知のきっかけでした。外部への通信先を把握しておくことは、検知の手がかりになります。

意図しない保持を防ぐ

• お問い合わせフォームに「カード番号は記入しないでください」と明記し、可能ならカード番号の形式を検出して送信を止める
• 注文確認メール・管理画面の注文詳細にカード番号を転記しない（下4桁のみ）
• アプリケーションログでリクエストの内容をマスクする

3-6. 弊社の推奨構成

共通して言えるのは、「決済代行を使っているから対象外」という整理は成り立たない、ということです。3-5の管理画面対策は、ガイドライン上、EC加盟店に求められている事項です。

第4章：非保持でも残る「事業者の責任」

カード情報を持たないことで、自社システムが侵害された際に保存されたカード情報が漏洩するリスクは減らせます。ただし、事業者としての責任が消えるわけではありません。クライアントにお伝えする際、弊社が必ず触れているのは次の4点です。

1. 個人情報はカード情報以外にも残っている

氏名・住所・電話番号・メールアドレス・購入履歴は、非保持化しても自社システムに残ります。個人情報保護法では、個人データの漏洩等のうち、要配慮個人情報を含む場合、財産的被害のおそれがある場合、不正の目的によるおそれがある場合、1,000人を超える場合など、一定の法定事由に該当するものについて、個人情報保護委員会への報告と本人への通知が義務となります。ECサイトへの不正アクセスによる漏洩は、この事由に該当することが多いと考えられます。第2章の型Bの事例は、カード情報が対象外であっても数十万件規模の個人情報が対象になっています。

2. 加盟店としての責任は残る

カード不正利用に関するチャージバック（売上の取り消し）では、加盟店が損失を負担する場合があります。責任の所在は、取引の種別、カードブランドのルール、3Dセキュアの認証結果、異議申立ての理由などによって異なります。EMV 3-Dセキュアで認証された取引では責任がカード発行会社側に移る場合がありますが、免除取引にはこれが適用されない点は第3章で触れたとおりです。

3. 「非保持」の例外が、意図せず生まれる

システムとしては非保持でも、実態として保持してしまうケースがあります。お問い合わせフォームにカード番号を記入してくる顧客、注文確認メールへの転記、デバッグ用ログへのリクエスト内容の出力などです。これらは設計段階で防げるものなので、制作会社に確認を依頼してください。

4. 外部サービスへの依存リスク

決済事業者やプラットフォームのアカウント凍結・資金保留、規約変更、そして第2章の型Cのような基盤側の侵害は、自社ではコントロールできません。だからこそ、代替決済手段の用意と、基盤側で事案が起きたときに自社顧客へ案内する手順を、平時に決めておく必要があります。

これらは「だから非保持化は不十分だ」という話ではなく、「非保持化は出発点であり、その先にやるべきことが明確になっている」という話です。

第5章：カード会社から連絡が来たときの初動

第2章で見たとおり、決済ページ改ざん型の事例では、カード会社からの「不正利用の懸念」の連絡が起点になったものが複数あります。この連絡は、どれだけ対策をしていても来る可能性があるものです。来たときに慌てないよう、手順を先に決めておくことが大切です。

連絡を受けたら

現実には、一つずつ順番にではなく、並行して進める必要があります。

• カード決済の停止を含む封じ込めを決定する
• 並行して、サーバーのログとファイルを保全する（調査のため、上書きや削除を避ける）
• 決済代行会社・カートASP・制作会社など関係事業者に連絡する
• 法的な報告義務の要否を確認し、該当する場合は個人情報保護委員会への速報を準備する
• 警察への相談を検討する

報告義務が生じる場合、個人情報保護委員会への報告は、速報が事態を知った時点から概ね3〜5日以内、確報が30日以内（不正の目的によるおそれがある場合は60日以内）が目安とされています。

2025年後半から2026年の事例を見ると、通知後に決済停止等の措置を取った例があります。インク革命は2025年12月9日の連絡の翌日に、ボンフォームは2026年1月14日の連絡後の1月16日に、それぞれ決済停止・サイト停止を行っています。

平時に用意しておくもの

• カード決済停止中の代替決済手段（銀行振込、コンビニ決済、後払いなど）
• 顧客への第一報の文面のひな形
• フォレンジック調査を依頼できる専門会社の連絡先
• 決済代行会社・カートASP・制作会社との連絡経路と責任分界

公表までの期間や理由は各社で異なります。たとえば佐嘉平川屋はカード会社の連絡から公表まで98日、ジャストカーテン（インテリックス）は250日でした。各社は、調査、関係機関との調整、対象者の特定などに時間を要したと説明しています。代替決済と顧客向け文面が平時に用意されていれば、売上が止まる期間と顧客への説明の負担は軽くできます。

なお、対象となった事業者には地方の食品ECやカー用品ECも含まれており、小規模なEC事業者でも攻撃対象となった事例があります。

結論：「持たない、かつ守る」

弊社がクライアントにお伝えしている方針を、そのまま書きます。

クレジットカード情報は自社で持たず、専門の決済サービスに任せてください。これにより、万一侵入された場合の被害を限定できます。ただし、自社サイトの管理画面と決済ページ、そして決済サービスのアカウントと鍵を守ることは、引き続き貴社の責任として残ります。この3つには、アカウント設定などすぐに確認できる項目と、開発や費用が必要な項目があります。まず前者から着手してください。

2026年に公表された事例は、「非保持化が無意味だった」ことを示しているのではなく、「非保持化の次に何をすべきか」を具体的に教えてくれています。この記事が、その整理の一助になれば幸いです。

チェックリスト（PDF）のご案内

第3章の内容を、使っている決済サービス別・優先度別のチェックリストにまとめました。制作会社や開発者にそのまま渡していただける形になっています。

EC決済セキュリティ チェックリスト（PDF）をダウンロード

チェックリストの項目について、貴社の環境でどう対応すべきか判断に迷う場合は、お気軽にご相談ください。また、フィッシング耐性のある認証方式として物理セキュリティキーの導入をご検討の場合は、security.pj-tc.com で各社製品を比較いただけます。

参考情報（一次情報）

本記事の事実関係は、2026年10月30日時点で確認できる各社の公表資料および公的機関・業界団体の公開情報にもとづいています。調査継続中の事案は、今後内容が更新される可能性があります。

事例（各社公表文）

• グッドスマイルカンパニー「不正アクセスによるお客様情報流出の可能性について（第3報）」2026年10月29日 — goodsmile.com
• 株式会社エーツー（駿河屋）公式お知らせ、2025年12月4日
• ボンフォーム（2026年1月16日、4月27日）、インテリックス「ジャストカーテン」（2026年1月26日）、ビューティガレージ（2026年2月6日〜8月19日）、佐嘉平川屋（2026年6月15日）、シー・コネクト「インク革命」（2026年7月29日）、RIZAP「APORITO」（2026年8月10日〜9月18日）の各公表文
• カインドオル（2026年8月28日、9月2日追記）、チャーム（2026年8月13日〜10月7日）、Eストアー「ショップサーブ」（2026年8月1日〜10月16日最終報）の各公表文

制度・統計

• 日本クレジット協会「クレジットカード不正利用被害の発生状況」（2026年9月7日公表）
• クレジット取引セキュリティ対策協議会「クレジットカード・セキュリティガイドライン【1版】」（2026年3月11日）
• 経済産業省「クレジットカード・セキュリティガイドライン【0版】」（2024年3月15日）— EMV 3-Dセキュア導入の原則義務化
• PCI Security Standards Council「Important Updates Announced for Merchants Validating to SAQ A」（2025年1月30日）— pcisecuritystandards.org
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」— 漏えい等の報告
• PCI Security Standards Council FAQ 1588 — SAQ A適格条件（スクリプト攻撃への保護の確認方法）
• NIST SP 800-63B「Digital Identity Guidelines: Authentication and Lifecycle Management」— フィッシング耐性のある認証方式の位置づけ
• 日本クレジット協会「クレジットカード不正利用被害の発生状況」2026年9月7日公表 — j-credit.or.jp

各決済サービスの公式ドキュメント

• Stripe「API keys」「Best practices for managing secret API keys」「日本における3DSの導入の義務化について」「日本の3Dセキュア必須化の例外」— stripe.com / support.stripe.com
• PayPal「Security guidelines for developers」— paypal.com
• Shopify「Account security best practices」— shopify.com
• dev「checkout.liquid（Deprecated）」— shopify.dev

事例の整理にあたり参照した二次資料

• AEVUS「ECサイトのサイバー攻撃事例【2026年版】」（2026年9月14日、10月20日更新）
• Spider AF「情報漏洩の事例まとめ【2026年最新版】」（2026年7月1日）
• KAI-YOU「グッドスマイルカンパニー、クレカ番号全16桁が情報漏洩か」（2026年10月29日）