オフプライスストア「アエナ」を運営する株式会社アエナは2026年10月14日、ECアプリへの不正アクセスで会員のマイページ情報が閲覧されたと公表しました。閲覧されたおそれがあるのは最大817,215人で、氏名・住所・電話番号に加え、登録カードの下4桁と有効期限まで含まれます。本記事の前半では、自分が対象か、届いた連絡は本物か、どこに問い合わせ、どう退会するかを公式発表に沿って答えます。9月末に公表されたヤマト運輸の後払いサービスの件とは別の事案である点も整理しました。後半は、公表された原因「機械的な連続アクセス」でマイページが読まれる型を取り上げ、会員サイトの開発者が同じ被害を止める実装をPythonのコードで示します。
まとめ：アエナECアプリ不正アクセスで公表された事実と会員がまずやること
今回の件は、アエナのECアプリの会員マイページが第三者に閲覧されたものです。同社がシステムログの解析で把握したのは10月13日5時58分で、翌14日に公表しました。カード番号の全桁とセキュリティコードは同社が保存しておらず、ログインパスワードも閲覧されていません。会員情報の書き換え、購入、退会の操作も行われていないと確認されています。
会員がやることは3つです。アエナや金融機関を名乗る連絡で、URLを開かず、パスワードやカード番号を伝えないこと。不安があれば公式のフリーダイヤルで確かめること。アプリを使い続けないなら、10月15日に開設された退会専用ページで会員情報の削除を申し込むことです。開発者が受け取る教訓は、マイページのように「本人の情報だけを返す画面」でも、送信元ごとの回数や触れた会員の数を数えていなければ、機械的に読み続けられるという点にあります。
| 項目 | 公表内容（10月15日時点） |
|---|---|
| 対象 | 最大817,215人（アプリ会員） |
| 対象外 | LINE会員・Amazon・楽天 |
| 判明 | 10月13日5時58分 |
| 原因 | 機械的な連続アクセス |
| 流出なし | カード全桁・パスワード |
| 窓口 | 0120-532-565 |
| 未公表 | 手口・期間・補償 |
会員が最初に確かめること：対象の範囲、届く連絡の真偽、窓口と退会手続き
対象は最大817,215人のアプリ会員：LINE会員とAmazon・楽天の購入者は対象外
10月14日のお知らせによると、対象はアエナのアプリ会員、つまりアプリに個人情報を登録した人です。LINEで会員証を使っている人と、Amazonや楽天などのモール経由で買った人は対象外と明記されています。店舗だけで買い物をしていて、アプリに住所や電話番号を登録していない人も、この区分に当てはまりません。
対象の可能性がある会員には、個別のメールで順次案内していると同社は説明しています。ただし、メールが届いていないことは対象外の証明にはなりません。アプリに登録した覚えがあれば、届く連絡に注意を払い、気になる点は下の公式窓口で確かめるのが確実です。
個別メールと不審な連絡の見分け方：公式が尋ねないと明言したパスワードとカード
同社は「メール、SMS、電話でパスワードやクレジットカード情報をお伺いすることはございません」と書いています。見分ける基準はここです。アエナや公的機関、金融機関を名乗っていても、パスワードやカード番号、セキュリティコードを聞いてきた時点で偽物として扱って構いません。個別メールの件名と送信元アドレスは、10月15日時点で公表されていません。
今回閲覧されたのは住所、電話番号、メールアドレス、生年月日に、登録カードの下4桁と有効期限、名義です。下4桁や有効期限を言い当てる電話やメールは「本物の会社だから知っている」ように見えますが、それこそが流出した情報を使う手口です。メール本文のURLは開かず、問い合わせは自分で調べた公式の番号から行います。偽の連絡がどう組み立てられるかはフィッシング詐欺の仕組みと技術的な対策で解説しています。
お客様専用フリーダイヤル0120-532-565の受付時間とメール窓口の使い分け
本件専用の窓口は2つあります。電話はお客様専用フリーダイヤル0120-532-565で、受付は9時〜21時で、土日祝日も対象です。メールは[email protected]で、問い合わせの状況により返信に時間がかかる場合があると案内されています。
急ぐ確認は電話が向いています。「この電話番号やメールは本当にアエナからか」を確かめたいときも、相手から聞いた番号ではなく、公式のお知らせに載った0120-532-565へかけ直してください。メールの窓口は、住所変更や配信停止の希望など記録を残したい用件に向いています。
10月15日開設の退会専用ページ：正しいURLと削除で消える購入履歴・ポイント
ECアプリは止まっており、アプリ上での退会手続きは使えません。そこで同社は10月15日、ECアプリ会員の退会専用ページを開設しました。ページの正しいURLはhttps://ec-kaiin-sakujo.aena.co.jp/で、同社のニュースページからリンクされています。手順は次のとおりです。
- 会員登録に使ったメールアドレスを入力する
- そのアドレスに届く確認メールのリンクを開く
- 「削除を確定する」を押すと受付が完了する
氏名、電話番号、生年月日の入力は求められません。それらを入力させるページは別物と疑ってください。削除すると購入履歴、お届け先、獲得したポイントがすべて消え、元に戻せません。LINE会員の退会はこのページではできず、LINEの「会員証メニュー」から「お問い合わせ」で申し出ます。なお、退会は今後の保有をやめる手続きで、すでに閲覧された情報が取り消されるわけではありません。
公式発表で整理する事実：閲覧された項目と閲覧されていない項目、未公表の点
マイページに表示される4区分の情報とカード全桁・パスワードが対象外の理由
| 区分 | 閲覧されたおそれがある項目 |
|---|---|
| 基本情報 | 氏名・住所・電話・メール等 |
| お届け先 | 住所・氏名・電話（第三者宛含む） |
| 設定情報 | お気に入り店舗・配信設定 |
| カード（一部） | 下4桁・有効期限・名義 |
基本情報には氏名、フリガナ、住所、電話番号、メールアドレス、生年月日、性別、職業が含まれます。見落としやすいのはお届け先です。家族や知人へ贈り物を送った会員なら、その相手の住所と氏名、電話番号まで閲覧の対象に入ります。会員本人だけでなく、送り先の相手にも不審な連絡に注意するよう伝えておくのが無難です。
カード番号の全桁とセキュリティコードは、同社のデータベースとサーバーにそもそも保存していないため流出しようがない、という説明です。ログインパスワードも閲覧・流出は無いとされています。閲覧されたのが「マイページに表示される情報」に限られることと合わせると、画面に出す項目だけが読まれた事案と整理できます。
9月28日のヤマト後払い漏えいと10月13日判明の今回の件を分けて読む
アエナは10月1日と5日にも、不正アクセスに関するお知らせを出しています。こちらはアエナのシステムではなく、公式アプリの決済手段「代金後払い決済」を提供するヤマト運輸のサービスが9月28日に不正アクセスを受けた件です。10月5日の続報では、後払いで支払った人の氏名、住所、電話番号、メールアドレス、請求金額、購入商品の明細が含まれる可能性があるとし、その時点では公式アプリのシステムから流出した形跡は無いと書いていました。
今回の817,215人の件は、その後の10月13日にアエナ自身のシステムログから判明したものです。2つの件の関係について、同社は何も述べていません。後払いを使った会員は、両方の対象になりうると考えておくのが安全です。ヤマトの10月9日の第3報によると、同社の後払いサービス自体は10月9日13時に再開し、支払期限を17日延ばしています。後払いの請求や支払いに関する問い合わせ先はヤマト運輸です。加盟店側の点検はヤマト運輸の後払いサービス不正アクセスと加盟店・開発者の点検手順で扱っています。
10月15日時点で公表されていない手口・閲覧期間・遮断までの経過
公表文が原因として書くのは「不正アクセスを通じて、機械的な連続アクセスが行われた」の一文だけで、詳細は調査中です。どの経路でマイページに入られたのか、いつから閲覧が続いていたのか、817,215人のうち実際に閲覧された人数はいくつかは、いずれも示されていません。対応としてECサイトへのアクセスを遮断し、再発防止策を構築中と説明しています。
個人情報保護委員会への報告の有無、補償やお詫びの品の有無も、公表文に記載がありません。本記事はこれらを推測で補いません。次の章では、公表された「機械的な連続アクセス」と「パスワードは閲覧されていない」という2つの事実と矛盾しない攻撃の型を、一般論として整理します。
「機械的な連続アクセス」でマイページが読まれる2つの型とOWASPの防御策
他サイトのID・パスワードを試すリスト型攻撃と会員IDを順に変える列挙の違い
パスワードを盗まずにマイページを読む方法は、大きく2つあります。1つ目はリスト型攻撃です。他のサイトから漏れたメールアドレスとパスワードの組を大量に用意し、ログインを機械的に試します。使い回しの会員だけがログインに成功し、そのマイページが読まれます。この場合、サイト側のパスワードは漏れていません。
2つ目は列挙です。マイページを返すAPIが、URLやパラメータに入った会員IDを信用して応答する作りだと、IDを1つずつ変えるだけで他人の情報が返ります。OWASPのIDOR防止チートシートは、この不備を「対象ごとのアクセス制御の確認が欠けている」ことと定義し、会員IDはURLではなくセッションから決めるよう勧めています。権限の確認漏れ全般は認可バイパスの仕組みとサーバー側で止める実装を参照してください。
どちらでも「機械的な連続アクセス」と「パスワードは閲覧されていない」は両立します。アエナの件がどちらの型か、あるいは別の手口かは公表されていません。運営者としては、両方を前提に点検するのが筋です。
OWASPが示す多要素認証と、IP遮断だけに頼らない段階的な対処の組み合わせ
リスト型攻撃について、OWASPのCredential Stuffing防止チートシートは多要素認証を「群を抜いて最良の防御」と位置づけています。全員に毎回求めるのが難しければ、新しい端末やIPアドレスからのログイン、複数のアカウントにログインを試したIPアドレス、1つの送信元からの大量ログインといった条件でだけ2要素目を求める方法も示しています。
同じ資料は、IPアドレスの遮断は簡単に回避されるため、唯一の防御にしてはならないとも書いています。短い時間の急増と長い時間の低い一定量の両方を見ること、多数のIPアドレスが少しずつ要求してくる場合を想定することが求められます。上限を超えた要求には、RFC 6585が定める429 Too Many Requestsと、待つべき秒数を示すRetry-Afterヘッダで応じるのが標準の返し方です。
マイページAPIに送信元ごとの要求上限と触れた会員数の上限を入れるPython実装
10分で60回・3会員を超えたら429を返す判定コードと5通りの実行結果
マイページは本来、ログインした本人の情報を返す画面です。普通の会員が1つの送信元から触れる会員は、自分か、家族と共有する端末でもせいぜい数人にとどまります。そこで要求回数の上限に加えて「1つの送信元が一定時間に触れた会員の数」を数えると、リスト型攻撃と列挙のどちらも同じ仕組みで止められます。下のコードはPython標準のcollectionsのdequeで10分間のスライディングウィンドウを作り、上限を超えたら429を返す判定です。
# マイページへの機械的な連続アクセスを「送信元ごとの上限」と「触れた会員数」で止める最小例（Python 3.9以上・標準ライブラリのみ）
import time
from collections import defaultdict, deque
WINDOW = 600 # 判定の時間幅（秒）
MAX_REQ = 60 # 1送信元あたりの要求上限（10分）
MAX_ACCOUNTS = 3 # 1送信元が10分で触れてよい会員数
class MypageGuard:
def __init__(self):
self.hits = defaultdict(deque) # 送信元 -> 要求時刻
self.accounts = defaultdict(dict) # 送信元 -> {会員ID: 最終時刻}
def check(self, src: str, member_id: str, now: float):
q = self.hits[src]
while q and now - q[0] > WINDOW: # 時間幅の外を捨てる（スライディングウィンドウ）
q.popleft()
seen = {m: t for m, t in self.accounts[src].items() if now - t <= WINDOW}
self.accounts[src] = seen
if len(q) >= MAX_REQ:
return 429, "要求回数の上限"
if member_id not in seen and len(seen) >= MAX_ACCOUNTS:
return 429, "触れた会員数の上限"
q.append(now)
seen[member_id] = now
return 200, "表示"
def can_view(session_member: str, requested_member: str) -> bool:
"""マイページは本人のセッションの会員IDだけ。URLやパラメータの会員IDは信用しない"""
return session_member == requested_member
if __name__ == "__main__":
g, t0 = MypageGuard(), time.time()
# 1 普通の会員：同じ送信元から自分のマイページを5回
print("1 本人が5回閲覧:", [g.check("198.51.100.7", "m-1001", t0 + i * 30)[0] for i in range(5)])
# 2 家族で1台を共有：3人がそれぞれログイン
print("2 共有端末で3会員:", [g.check("198.51.100.8", f"m-20{i}", t0 + i)[0] for i in range(3)])
# 3 機械的な連続アクセス：1送信元が1秒ごとに別の会員へ
r = [g.check("203.0.113.50", f"m-{3000 + i}", t0 + i) for i in range(10)]
print("3 機械的に10会員:", [c for c, _ in r], "->", r[-1][1])
# 4 10分経過後は数え直し
print("4 10分後の同じ送信元:", g.check("203.0.113.50", "m-3999", t0 + 700)[0])
# 5 会員IDの差し替え（セッションはm-1001、URLはm-1002）
print("5 他人の会員IDを指定:", "表示" if can_view("m-1001", "m-1002") else "拒否")Python 3.14.7（Windows）で実行した結果です。
1 本人が5回閲覧: [200, 200, 200, 200, 200]
2 共有端末で3会員: [200, 200, 200]
3 機械的に10会員: [200, 200, 200, 429, 429, 429, 429, 429, 429, 429] -> 触れた会員数の上限
4 10分後の同じ送信元: 200
5 他人の会員IDを指定: 拒否3の送信元は1秒ごとに別の会員へ要求しており、4人目から429で止まりました。1と2のような通常の使い方は妨げません。5は列挙への備えで、会員IDはURLやパラメータではなくセッションから決めます。この判定が入っていれば、IDを書き換えても他人のマイページは返りません。数値は業態で変えてください。家族で1台を共有する利用が多いサービスなら会員数の上限を5に上げ、要求回数はアプリの画面遷移1回あたりのAPI呼び出し数から逆算します。送信元の単位にIPアドレスだけでなく端末IDやセッションも組み合わせるのが、多数のIPアドレスに分散した攻撃への備えです。上限の方式ごとの比較はAPIレート制限の5方式と429の設計にまとめています。
アクセスログから1送信元が20人以上の会員に触れた痕跡を数える集計コード
上限を入れる前に確かめたいのは、自社のマイページがすでに読まれていないかです。マイページAPIへの成功応答を送信元ごとに集め、触れた会員の数が多い順に並べます。ログに会員IDが残っていることが前提で、残していなければ、まずそこから直します。
# アクセスログから「1送信元が多数の会員のマイページに触れた」痕跡を数える（Python 3.9以上・標準ライブラリのみ）
import re, sys
from collections import defaultdict
# 例：203.0.113.50 m-3001 [13/Oct/2026:05:41:02 +0900] "GET /api/mypage HTTP/1.1" 200
LINE = re.compile(r'^(\S+) (\S+) \[([^\]]+)\] "(\S+) (\S+)[^"]*" (\d{3})')
def scan(lines, path_prefix="/api/mypage", threshold=20):
members = defaultdict(set)
count = defaultdict(int)
for line in lines:
m = LINE.match(line)
if not m or not m.group(5).startswith(path_prefix) or m.group(6) != "200":
continue
src, member = m.group(1), m.group(2)
members[src].add(member)
count[src] += 1
return sorted(((len(v), count[s], s) for s, v in members.items() if len(v) >= threshold), reverse=True)
if __name__ == "__main__":
sample = [f'198.51.100.7 m-1001 [13/Oct/2026:05:{i:02d}:00 +0900] "GET /api/mypage HTTP/1.1" 200' for i in range(8)]
sample += [f'203.0.113.50 m-{3000 + i} [13/Oct/2026:05:41:{i % 60:02d} +0900] "GET /api/mypage HTTP/1.1" 200' for i in range(250)]
sample += [f'203.0.113.51 m-{4000 + i} [13/Oct/2026:05:42:{i % 60:02d} +0900] "GET /api/mypage HTTP/1.1" 200' for i in range(40)]
src = open(sys.argv[1], encoding="utf-8") if len(sys.argv) > 1 else sample
for n_members, n_req, ip in scan(src):
print(f"{ip}: 会員 {n_members} 人分 / 成功 {n_req} 回")サンプルのログで実行すると、次の2行が出ます。普通の会員の198.51.100.7は8回とも同じ会員なので出てきません。
203.0.113.50: 会員 250 人分 / 成功 250 回
203.0.113.51: 会員 40 人分 / 成功 40 回実際のログで1つの送信元が数十人分のマイページに成功していれば、それだけで調べる理由になります。閾値の20は出発点で、共有端末の多い職場や学校からの接続を外したうえで下げていきます。nginxやAPI Gatewayでの上限設定とUser-Agentの抽出手順は、API不正アクセス対策の実装手順を参照してください。
EC・会員アプリ運営者の判断：自社で直す範囲と診断を頼む条件、報告の期限
マイページAPIの点検4項目：本人確認・上限・多要素認証・閲覧ログの保存
アエナの件の手口は未公表ですが、会員マイページを持つECアプリなら、同じ被害を防ぐ点検は事前にできます。優先度の高い順に4つです。
- マイページAPIが、会員IDをセッションから決めているか（URLやパラメータの会員IDで応答していないか）
- 送信元ごとの要求回数と、触れた会員数の上限があるか
- 新しい端末や大量ログインの送信元に、2要素目を求めているか
- マイページAPIの成功応答に、送信元と会員IDを残しているか
判断ははっきりしています。1つ目が「いいえ」なら、他の対策より先に直す対象です。4つ目が「いいえ」のままだと、被害が起きても何人分が読まれたかを数えられず、通知の範囲を最大値で出すしかなくなります。逆に、会員数が数百人規模でカード情報も持たないサイトに、端末指紋やボット判定の有料サービスまで入れるのは過剰です。上限と本人確認の2つで足ります。アプリとAPIの作りを第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断で点検できます。
個人情報保護委員会への報告と本人通知：速報3〜5日・確報30日と60日
個人情報保護法26条は、一定の漏えい等が起きたときに委員会への報告と本人への通知を事業者に義務づけています。個人情報保護委員会の案内では、速報は事態を知った日から3〜5日以内、確報は30日以内、不正アクセスのように不正の目的によるおそれがある場合は60日以内です。閲覧された件数が数えられないと、確報の段階でも「最大」の数字で報告することになります。
報告書に書く項目と段取りは個人情報保護委員会への報告義務の実務で解説しています。前の章の閲覧ログを残しておくことは、攻撃を見つけるためだけでなく、報告と通知の範囲を絞るための備えでもあります。
よくある質問
アエナのECアプリの不正アクセスについて、会員から出やすい質問をまとめました。
アエナから情報流出のメールが届きました。本物ですか？
同社は対象の可能性がある会員に個別メールで順次案内していますが、件名と送信元アドレスは10月15日時点で公表されていません。同社はメール、SMS、電話でパスワードやカード情報を尋ねないと明言しています。入力や回答を求めるものは偽物として扱い、確かめたいときは公式のお知らせに載ったフリーダイヤル0120-532-565へ自分でかけてください。
自分の情報が閲覧されたかどうかはどう確認できますか？
対象はアプリに個人情報を登録した会員で、最大817,215人です。LINE会員と、Amazonや楽天などで買った人は対象外です。個別メールが届かないことは対象外の証明にならないため、アプリに登録した覚えがあれば、フリーダイヤル0120-532-565（9時〜21時・土日祝日も受付）か[email protected]へ問い合わせます。
クレジットカードは止めたほうがよいですか？
カード番号の全桁とセキュリティコードは同社が保存しておらず、流出していないとされています。閲覧されたおそれがあるのは下4桁、有効期限、名義です。これだけでカードを使われることは考えにくい一方、下4桁を言い当ててカード番号を聞き出す詐欺には使われえます。利用明細に覚えのない請求があればカード会社に連絡し、再発行を相談してください。
アエナの退会はどこからできますか？
アプリが止まっているため、10月15日に開設された退会専用ページ（https://ec-kaiin-sakujo.aena.co.jp/）から申し込みます。登録したメールアドレスを入力し、届いた確認メールのリンクから「削除を確定する」を押すと受付完了です。購入履歴、お届け先、ポイントはすべて消えます。LINE会員はLINEの会員証メニューの「お問い合わせ」から申し出ます。
ヤマト運輸の後払いの件とは関係がありますか？
別の事案として公表されています。後払いの件は9月28日にヤマト運輸のサービスで起きたもので、後払いで支払った人の請求情報などが対象です。今回の件は10月13日にアエナのシステムログから判明しました。2つの件の関係について同社は説明していません。後払いを使った会員は両方の対象になりうるため、それぞれのお知らせを確認してください。
関連記事
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：マイページAPIの上限と認可をnginx・API Gatewayで入れる手順
- APIレート制限（レートリミット）とは？5方式の比較と429設計・分散実装【2026年版】：送信元ごとの上限を複数サーバーで数える方式
- ヤマト運輸の不正アクセスと後払いの請求情報漏えい｜加盟店と開発者の点検手順：アエナも利用していた後払いサービスの件
- 銀のさら不正アクセス：最大650万件の対象確認と窓口、パスワード変更の手順：同じ週に公表された会員情報の事例
- 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：運営者として点検する範囲の全体像
