---
title: "エディオン不正アクセス第2報：カード番号の対象確認とログ・決済画面の改ざん対策"
url: "https://www.issoh.co.jp/tech/details/19532/"
published: 2026-11-09
updated: 2026-11-09
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# エディオン不正アクセス第2報：カード番号の対象確認とログ・決済画面の改ざん対策

エディオンは2026年11月9日に第2報を公表し、第1報で含まれないとしていたクレジットカード番号とログインパスワードが一部含まれていたと訂正しました。決済の入力処理に不正なプログラムが組み込まれていたことも判明し、ECサイトは11月8日からサービスを停止している状況です。前半では、自分が対象かどうか、カード明細とパスワードをどうするかを公表文の条件で答えます。後半はEC事業者向けに、エラーログへ入力値を残さない実装と、決済画面の未承認スクリプトを見つける実装を実行結果つきで示します。

## まとめ：エディオン不正アクセス第2報で広がった対象と利用者の確認事項

[第2報](https://www.edion.co.jp/system/files/news-release/pdf/ja/2026-11/20261109%5Fpr%5F1%5F0.pdf)と[第1報](https://www.edion.co.jp/system/files/news-release/pdf/ja/2026-11/20261106%5Fpr%5F1.pdf)を合わせると、対象は次の6区分になります。件数は区分ごとの値で、足し合わせて人数にはできません。

| 区分        | 件数       | 情報               | 利用者の対応    |
| --------- | -------- | ---------------- | --------- |
| 決済処理の改ざん  | 最大556回   | カード番号・セキュリティコード等 | 明細の確認     |
| 注文エラーのログ  | 最大5件     | カード番号・セキュリティコード等 | 個別案内の記載なし |
| ギフトカード    | 5,360枚   | 番号・PIN・利用履歴      | 案内を待つ     |
| ログイン情報    | 最大1,141名 | ログインID・パスワード     | 個別メールで変更  |
| 氏名等が紐づくログ | 最大4,131名 | 氏名・住所・電話番号等      | 偽の連絡に注意   |
| 注文情報のログ   | 最大9,554名 | 氏名・注文番号・金額等      | 偽の連絡に注意   |

最初に確かめるのは、11月4日19時以降にパソコンの決済画面でカード番号を新しく入力したかどうかです。心当たりがあれば、カードの利用明細を見ます。スマートフォンからの操作は、この不正プログラムの対象外と確認されています。

EC事業者が受け取る教訓は2つあります。例外時のログに入力値を書かないこと、そしてサーバーにカード番号を残さない方式でも決済画面の改ざんは防げないことです。

## エディオンの利用者が確かめるカード明細、パスワードとギフトカードの扱い

### 11月4日19時以降にパソコンで新規入力した人が確かめるカード明細

不正なプログラムは11月4日の19時過ぎから動いていました。対象の最大556回は「決済情報入力画面で、新規にカード情報を入力された場合」の回数です。パソコンで入力した人が前提なので、次の順で切り分けられます。

1. 11月4日19時以降にエディオンのECサイトで買い物をしたか
2. パソコンから操作したか
3. カード番号を画面に新しく入力したか

3つとも当てはまる場合、番号、有効期限、名義、セキュリティコードが第三者に渡った可能性を否定できません。身に覚えのない請求があれば、カード裏面の窓口へ連絡します。エディオンはカード各社に不正利用の監視強化を依頼済みです。再発行の要否について、第2報に記載はありません。不安が残るなら、カード会社に再発行の可否を尋ねるのが確実な方法になります。

### 個別メールが届く最大1,141名のパスワード変更と停止中サイトの注意点

ログインIDとパスワードが対象になったのは最大1,141名で、該当者には変更を依頼するメールが順次届きます。ECサイトは新規ログインに2段階認証が必要なため、「直ちに不正利用が行われる状況ではございません」とされました。

注意したいのは他のサービスです。同じパスワードを使い回していると、2段階認証のないサービスでは入られるおそれがあります。第2報が求めているのはエディオンの変更だけですが、使い回しがある人は、メール、金融、決済のサービスから先に変えてください。ECサイトが止まっている間の変更手順は公表文に書かれていないので、届いたメールの内容を窓口で確かめる方法が安全です。

### 5,360枚のギフトカードの番号とPINの扱い、店舗で使うときの条件

漏えいが確認されたエディオンギフトカードは5,360枚で、カード番号、PIN、利用履歴が含まれます。番号とPINだけで使える場所はECサイトに限られ、実店舗では原本の提示が必要です。ECサイトが止まっている今は、漏れた情報だけでの不正利用はできない、というのがエディオンの説明になります。

裏を返すと、対策が要るのはECサイトの再開時です。カードの取り扱いは「現在検討」中で、方針が決まり次第、対象者へ案内されます。残高の補償や番号の差し替えについては、まだ何も示されていません。

### 偽の連絡の見分け方と、お客様相談センターの電話番号・受付時間

第1報の時点で、氏名や注文番号、注文金額の入ったログが対象でした。注文番号や金額を正しく言い当てる連絡でも、本物の証拠にはなりません。カード番号やPIN、パスワードを聞かれたら応じず、メールやSMSのリンクも開かずに窓口へ確かめます。手口の見分け方は[フィッシング詐欺の仕組みと対策](https://www.issoh.co.jp/tech/details/13548/)にまとめました。

問い合わせ先はお客様相談センターの0120-77-0095で、受付は9時から18時です。番号は公表文の表記と照らしてからかけてください。

## 第1報から第2報で訂正された項目と、判明までの時系列の読み方

### 11月4日の不正プログラム稼働から11月9日の第2報までの時系列

| 日時            | 出来事             |
| ------------- | --------------- |
| 11月4日 19時過ぎ   | 不正プログラムが稼働      |
| 11月5日 18時30分頃 | ログ領域への不正アクセスを確認 |
| 11月6日         | 第1報を公表          |
| 11月8日 朝       | ECサイトとアプリを緊急停止  |
| 11月8日 21時10分  | アプリの一部機能を再開     |
| 11月9日         | 第2報を公表          |

再開したのは、エディオン公式アプリとエディオンスマートアプリの「デジタル会員証機能」「クーポン表示機能」などです。ECサイトは停止中で、再開は未定とされています。

### 第1報の「含まれない」が覆ったカード番号と、通常どおり利用可の判断

第1報は「クレジットカード番号およびログインパスワードは含まれておりません」と書き、ECサイトは通常どおり使えると案内していました。第2報はこれを訂正しています。詳細な解析で、カード番号とログインパスワードが一部含まれていたと分かったためです。第1報に記載のなかったギフトカードのPINも、第2報で対象に加わりました。

第2報によれば、不正プログラムは第1報より前の11月4日から動いていました。いつ止まったかは公表されていません。自社が公表する側なら、調査が終わるまで「含まれていない」とは書かず、「現時点で確認されていない」と範囲を限って書くべきです。

### 第2報でも公表されていない侵入経路と被害期間の終わり、続報で見る点

次の項目は第2報に記載がないため、この記事でも推測しません。

- 突かれた脆弱性の内容と侵入経路
- 不正プログラムがブラウザとサーバーのどちらで動いたか
- 不正プログラムが止まった時刻
- 漏えいしたパスワードの保存形式
- カードの不正利用が実際に起きたかどうか
- ECサイトの再開時期

個人情報保護委員会と警察署への追加報告は準備中です。第1報で「精査中」だった、氏名と紐づかない情報の件数も確定していません。家電量販店では[ノジマオンラインの約700万件](https://www.issoh.co.jp/tech/details/19223/)も同じ月に公表されましたが、エディオンの公表文に両者の関連を示す記述はありません。

## 注文エラーのログにカード番号が残らないよう入力値を除くPython実装

### カード番号5件が例外時のログへ入った経路と、CWE-532が示す欠陥

第2報によると、注文画面でエラーが起きた際に「例外的に入力内容がシステムログへ一時記録」されていました。件数は最大5件でも、記録された項目にはセキュリティコードまで入っています。通常の処理では問題がなく、例外の経路だけで漏れる形です。

機密情報をログへ書き込む欠陥は[CWE-532](https://cwe.mitre.org/data/definitions/532.html)として分類され、対策に「ログに秘密情報を書かない」ことが挙げられています。[OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging%5FCheat%5FSheet.html)も、パスワード、アクセストークン、決済カードの情報を記録から外す項目に挙げました。カード検証コードは[PCI SSCのFAQ](https://blog.pcisecuritystandards.org/faq-can-cvc-be-stored-for-card-on-file-or-recurring-transactions)が、認可後の保存を認めていません。

### 記録してよい項目だけを列挙する許可リスト方式のPythonコード

消す項目を並べる方式は、項目が増えたときに漏れます。次のコードは逆に、記録してよい項目だけを列挙しました。もう1段の守りとして、[logging](https://docs.python.org/ja/3/library/logging.html)のFormatterで完成した文字列を検査し、Luhnの検査に通る桁列を消します。トレースバックに入力値が混ざる経路まで塞ぐためです。

```
# safe_error_log.py 注文エラーのログに入力値を残さない（Python 3.9以上・標準ライブラリのみ）
import logging
import re
import sys

ALLOW = {"order_no", "payment_method", "item_count"}  # 記録してよい項目だけを列挙する
PAN = re.compile(r"(?<![\d-])\d(?:[ -]?\d){12,18}(?![\d-])")


def luhn_ok(digits):
    total = 0
    for i, ch in enumerate(reversed(digits)):
        n = int(ch)
        if i % 2:
            n = n * 2 - 9 if n > 4 else n * 2
        total += n
    return total % 10 == 0


def scrub(text):
    def repl(match):
        digits = re.sub(r"\D", "", match.group())
        return "[PAN削除]" if luhn_ok(digits) else match.group()
    return PAN.sub(repl, text)


def safe_fields(form):
    kept = {k: v for k, v in form.items() if k in ALLOW}
    kept["dropped_keys"] = len(form) - len(kept)  # 値ではなく捨てた数だけ残す
    return kept


class ScrubFormatter(logging.Formatter):
    """例外のトレースバックまで含めた完成形の文字列を最後に検査する"""

    def format(self, record):
        return scrub(super().format(record))


def charge(form):
    # 外部ライブラリの例外文に入力値が混ざる典型を再現している
    raise ValueError(f"gateway rejected: card={form['card_no']}")


def main():
    handler = logging.StreamHandler(sys.stdout)
    handler.setFormatter(ScrubFormatter("%(levelname)s %(message)s"))
    log = logging.getLogger("order")
    log.addHandler(handler)
    log.setLevel(logging.INFO)

    form = {
        "order_no": "A-1001", "payment_method": "card", "item_count": 2,
        "card_no": "4111 1111 1111 1111", "exp": "12/29", "cvc": "123",
        "holder": "TARO YAMADA", "gift_pin": "9876",
    }
    try:
        charge(form)
    except ValueError:
        log.exception("order failed %s", safe_fields(form))


if __name__ == "__main__":
    main()
```

### 実行結果の確認と、PINやセキュリティコードを検査で拾えない限界

Python 3.14.10（Windows）で2026年11月9日に実行した結果です。ファイルパスだけ短くして載せました。カード番号は例外の文面からも消え、5項目は件数だけが残っています。

```
ERROR order failed {'order_no': 'A-1001', 'payment_method': 'card', 'item_count': 2, 'dropped_keys': 5}
Traceback (most recent call last):
  File "safe_error_log.py", line 58, in main
    charge(form)
    ~~~~~~^^^^^^
  File "safe_error_log.py", line 42, in charge
    raise ValueError(f"gateway rejected: card={form['card_no']}")
ValueError: gateway rejected: card=[PAN削除]
```

Formatterの検査はカード番号の形しか見ていません。3桁のセキュリティコードや4桁のPINは、例外の文面に混ざると素通りします。守りの本体は許可リストのほうで、例外の文面に入力値を入れないこともコードレビューの項目に加えてください。検査は最後の網と割り切るのが正しい使い方です。

### 既存ログのカード番号と秘密値を、値を出さずに数える棚卸しスクリプト

実装を直しても、過去のログは残ったままです。次のスクリプトは件数だけを数えます。検出した値を画面に出すと、調査の記録が新しい漏えい元になるためです。先ほどの `safe_error_log.py` と同じフォルダに置いて実行します。

```
# scan_logs.py 既存ログの機微情報を数える。値そのものは出力しない（Python 3.9以上）
import re
import sys

from safe_error_log import PAN, luhn_ok

SECRET = re.compile(r"""\b(cvc|cvv|security_code|pin|password)["']?\s*[:=]""", re.I)
MAIL = re.compile(r"[\w.+-]+" + chr(64) + r"[\w-]+\.[\w.-]+")
PHONE = re.compile(r"(?<!\d)0\d{1,4}-\d{1,4}-\d{4}(?!\d)")


def scan(lines):
    found = {"card": 0, "secret": 0, "mail": 0, "phone": 0}
    for line in lines:
        found["card"] += sum(luhn_ok(re.sub(r"\D", "", m.group())) for m in PAN.finditer(line))
        found["secret"] += len(SECRET.findall(line))
        found["mail"] += len(MAIL.findall(line))
        found["phone"] += len(PHONE.findall(line))
    return found


SAMPLE = [
    "INFO order ok order_no=A-1000 elapsed=120",
    'ERROR form={"card_no": "4111 1111 1111 1111", "cvc": "123"}',
    "INFO login user=taro" + chr(64) + "example.jp password=hunter2",
    "INFO tel=090-1234-5678 ref=1234567890123456",
]

if __name__ == "__main__":
    for path in sys.argv[1:]:  # 例: python scan_logs.py app.log
        with open(path, encoding="utf-8", errors="replace") as f:
            print(path, scan(f))
    if len(sys.argv) == 1:
        print("sample", scan(SAMPLE))
```

引数なしで実行すると、4行の検証データで次の結果になります。16桁の `ref` はLuhnの検査に通らないので、カード番号に数えていません。

```
sample {'card': 1, 'secret': 2, 'mail': 1, 'phone': 1}
```

1件でも見つかったログは、削除の前に保全の要否と報告の要否を判断します。検出の精度は形式に依存するため、件数0は「無い」の証明にはなりません。

### アクセスログのクエリ文字列と注文日時で結合される断片への対処

第1報には、注文日時などをもとに照合すると情報を組み合わせられる、という注記がありました。1行ごとに個人を特定できなくても、同じ時刻の別の行と結合すれば特定できます。ログの項目を1行単位で点検するだけでは足りない理由がここにあります。

Webサーバーの設定も見直しの対象です。[nginxの既定のcombined形式](https://nginx.org/en/docs/http/ngx%5Fhttp%5Flog%5Fmodule.html)は `$request` を記録するため、URLのクエリ文字列まで残ります。[埋め込み変数](https://nginx.org/en/docs/http/ngx%5Fhttp%5Fcore%5Fmodule.html)の `$uri` に替えた独自の `log_format` を決済や会員の経路で使えば、クエリの値を残さないログ構成に変更可能です。調査用の紐づけには、個人情報を含まないランダムなIDを1リクエストに1つ割り当てます。項目の設計は[構造化ログの実装](https://www.issoh.co.jp/tech/details/15703/)を参照してください。

置き場所の守りも別に必要です。OWASPはログの読み取り権限の制限と定期的な見直しを挙げ、[IPAのECサイト構築・運用セキュリティガイドライン](https://www.ipa.go.jp/security/guide/vuln/guideforecsite.html)も要件12と13でログの保管と保護を扱っています。公開領域の配下にログを置いていないか、まず確かめる価値があります。

## 非保持化でも防げない決済画面の改ざんを、配信されたHTMLから検知する実装

### カード番号を残さない非保持化でも入力の瞬間は盗める、第2報の教訓

エディオンのカード決済は「非保持化」に対応し、サーバーに情報を残さない仕組みでした。それでも第2報は、入力された情報が「直接第三者に漏洩した可能性」を認めています。非保持化が守るのは保存された情報で、利用者が入力する瞬間までは守れません。

カード番号を決済代行へ渡す方式の違いは[決済トークンの実装方式](https://www.issoh.co.jp/tech/details/15726/)で整理しました。自社のページにカード番号の入力欄があるなら、トークン化していても改ざんの対象になります。

### PCI DSS 6.4.3と11.6.1が求めるスクリプト台帳と改ざん検知の中身

[PCI DSS v4.0の要件](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-D-Service-Provider.pdf)は、決済ページのスクリプトについて2つのことを求めています。6.4.3は各スクリプトの承認の確認、完全性の保証、必要な理由を書いた台帳の維持です。11.6.1は、利用者のブラウザが受け取るHTTPヘッダーとページ内容の無断変更を担当者へ通知する仕組みです。v4.0.1で対象の書き方が調整されているので、審査に使うときは最新の文書を確かめてください。

日本では[クレジットカード・セキュリティガイドライン6.0版](https://www.j-credit.or.jp/download/news20250305%5Fa1.pdf)が、EC加盟店のシステムとWebサイトの脆弱性対策を指針対策に加えました。[協議会の関連資料](https://www.j-credit.or.jp/security/document/index.html)には6.1版まで掲載されています。

### 決済画面の未承認スクリプトを洗い出すPythonコードと実行結果

次のコードは、配信されたHTMLからスクリプトを取り出し、承認済みの一覧と比べます。外部ファイルはURLで、インラインはSHA-256で照合する仕組みです。検証用のHTMLを内蔵しているので、そのまま実行できます。

```
# checkout_guard.py 決済画面のHTMLに承認していないスクリプトが無いかを調べる（Python 3.9以上）
import base64
import hashlib
from html.parser import HTMLParser

APPROVED_SRC = {"https://static.example.jp/checkout.v42.js"}  # 承認した外部スクリプト
APPROVED_INLINE = set()  # 承認したインラインのSHA-256（初回の結果を確認して登録する）


class ScriptLister(HTMLParser):
    def __init__(self):
        super().__init__()
        self.found = []
        self._inline = None

    def handle_starttag(self, tag, attrs):
        if tag != "script":
            return
        src = dict(attrs).get("src")
        if src:
            self.found.append(("src", src))
        else:
            self._inline = []

    def handle_data(self, data):
        if self._inline is not None:
            self._inline.append(data)

    def handle_endtag(self, tag):
        if tag == "script" and self._inline is not None:
            body = "".join(self._inline).encode("utf-8")
            digest = base64.b64encode(hashlib.sha256(body).digest()).decode()
            self.found.append(("inline", "sha256-" + digest))
            self._inline = None


def unapproved(page):
    parser = ScriptLister()
    parser.feed(page)
    return [(kind, value) for kind, value in parser.found
            if value not in (APPROVED_SRC if kind == "src" else APPROVED_INLINE)]


CLEAN = '<form id="pay"></form><script src="https://static.example.jp/checkout.v42.js"></script>'
TAMPERED = CLEAN + '<script src="https://cdn.example.net/a.js"></script><script>send(pay)</script>'

if __name__ == "__main__":
    print("正常なページ:", unapproved(CLEAN))
    for kind, value in unapproved(TAMPERED):
        print("未承認:", kind, value)
```

Python 3.14.10（Windows）での実行結果です。後から足された外部スクリプトとインラインの2本だけが検出され、承認済みのファイルは出ていません。

```
正常なページ: []
未承認: src https://cdn.example.net/a.js
未承認: inline sha256-2L7JujwS2ssNvFMa0iFSHATtygeCz57D//QYmHTRCy4=
```

本番では、決済画面のHTMLを定期的に取得してこの比較に渡し、差分が出たら担当者へ通知します。この検査が見るのはHTMLに書かれたスクリプトの一覧だけです。承認済みファイルの中身の書き換えは、ファイルのハッシュの照合が別に要ります。サーバー側で入力値を抜く形なら、HTMLの比較では検知できません。デプロイ成果物とサーバー上のファイルのハッシュも突き合わせてください。

### SRIとCSPで実行を止める設定と、パソコン版・スマホ版を別に見る理由

検知に加えて、実行そのものを止める設定があります。[サブリソース完全性（SRI）](https://developer.mozilla.org/ja/docs/Web/Security/Defenses/Subresource%5FIntegrity)は、`integrity` 属性のハッシュと一致しないファイルの実行をブラウザに拒否させます。[CSP](https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/CSP)はノンスやハッシュで許可したスクリプトだけを動かす仕組みです。既存の画面にいきなり適用すると正規のタグまで止まるので、まず `Content-Security-Policy-Report-Only` で違反の報告だけを集めます。

監視はパソコン版とスマートフォン版を別々に行います。第2報では、パソコン環境向けの入力処理だけが改ざんされ、スマートフォンは対象外でした。監視がスマートフォン用の表示だけを見ていれば、差分は1行も出ません。User-Agentや画面幅で配信が分かれるなら、その種類の数だけ取得してください。

## 個人情報保護委員会への報告範囲と、EC事業者が外部診断を入れる判断基準

### カード番号を含む漏えいは報告対象になる財産的被害の基準と確報の期限

[個人情報保護法のガイドライン（通則編）3-5-3-1](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)は、財産的被害のおそれがある事態の例として「ECサイトからクレジットカード番号を含む個人データが漏えいした場合」を挙げています。送金や決済機能のあるサービスのログインIDとパスワードの組み合わせも同じ扱いです。1,000人超という人数の基準は別の類型の話で、5件のカード番号でも対象から外れません。

速報は事態を知ってから概ね3〜5日以内、不正の目的によるおそれがある事態の確報は60日以内が目安です。エディオンも第2報で、委員会と警察署への追加報告の準備を進めていると説明しました。全体の流れは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)にまとめました。

### 外部診断を入れる条件と、棚卸しと台帳整備で足りる小規模サイトの線引き

カード番号の入力欄が自社のページにあり、会員数が万単位なら、外部の診断を先に入れます。第2報の事案と同じく、保存していないことは安心の根拠にならないからです。管理画面やAPIを自社で作り込んでいる場合も同様で、API側の認可は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で確認できます。

カード番号の入力を決済代行の画面へ完全に任せ、会員情報もほとんど持たない小規模サイトなら、診断は急ぎません。まずログの棚卸しとスクリプト台帳の整備で足ります。一方、例外時のログ出力は誰も読まない経路で、社内のレビューでは見落とされがちです。自社のECサイトに同じ弱点が残っていないかを第三者に確かめたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。

## よくある質問

エディオンの不正アクセスについて、利用者から出やすい質問をまとめました。内容は2026年11月9日の第2報に基づきます。

### エディオンの不正アクセスで自分が対象かどうかはどう確かめますか？

カードについては、11月4日19時以降にパソコンの決済画面でカード番号を新しく入力したかが基準です。パスワードの対象者である最大1,141名には個別のメールが届きます。ギフトカードは方針が決まり次第、対象者へ案内される予定です。第2報に、会員番号などを入れて自分で照会するページの案内はありません。判断がつかないときは、お客様相談センター（0120-77-0095、9時〜18時）に問い合わせます。

### スマートフォンで買い物をした場合もカード情報は漏れていますか？

第2報は、スマートフォンからの操作と決済入力は不正プログラムの対象外だったと確認しています。ただし、これは決済画面の改ざんに限った話です。注文時のエラーでカード情報がログに記録された最大5件については、端末の別が示されていません。ログに残っていた氏名や住所などの区分も、端末で対象が分かれるとは書かれていないので、偽の連絡には引き続き注意してください。

### エディオンで使ったクレジットカードは止めたほうがいいですか？

第2報が利用者に求めているのは、該当期間にパソコンから新規入力した場合の明細確認で、カードの停止や再発行には触れていません。エディオンはカード各社に不正利用の監視強化を依頼しています。セキュリティコードまで対象なので、不安が強い場合はカード裏面の窓口で再発行できるか相談するとよいでしょう。身に覚えのない請求を見つけたときも、同じ窓口へ連絡します。

### 第1報では含まれないとされたパスワードが、なぜ第2報で対象になったのですか？

第2報は、第1報の時点では確認されていなかった情報が、その後の詳細な解析で判明したと説明しています。訂正の対象はクレジットカード情報とログインパスワードです。パスワードが平文だったかどうかなど、保存の形式は公表されていません。対象の最大1,141名には変更を依頼するメールが届きます。新規ログインには2段階認証が必要とされていますが、同じパスワードを他のサービスで使っている人は変更しておくほうが安全です。

### エディオンのネットショップはいつ再開しますか？アプリは使えますか？

2026年11月9日の第2報では、ECサイトは停止中で再開は未定です。エディオン公式アプリとエディオンスマートアプリは、点検のうえ11月8日21時10分から「デジタル会員証機能」「クーポン表示機能」などに限定して再開しました。ギフトカードの番号とPINで買い物ができるのはECサイトだけなので、再開時の扱いは今後の案内を確認してください。最新の状況は[エディオンのニュース一覧](https://www.edion.co.jp/news)に掲載されます。

## 関連記事

- [ノジマオンライン不正アクセス約700万件漏えい：パスワード変更メールの確認と再設定手順](https://www.issoh.co.jp/tech/details/19223/)：同じ月に公表された家電量販店の別の事案
- [Joshin（ジョーシン）不正アクセス：最大600万件の対象とサブスク初期パスワード、メンテナンス中のサービス](https://www.issoh.co.jp/tech/details/18993/)：家電量販店の別の事案
- [決済トークンとは？トークナイゼーションの仕組みと暗号化との違い・実装方式を開発視点で解説](https://www.issoh.co.jp/tech/details/15726/)：カード番号を自社に残さない方式の実装
- [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：事業者が行う報告の流れ
- [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：APIの認可とトークン失効の実装

---

出典: [エディオン不正アクセス第2報：カード番号の対象確認とログ・決済画面の改ざん対策](<https://www.issoh.co.jp/tech/details/19532/>)（株式会社一創）