セキュリティ

あきゅらいず不正アクセス:最大約90万件の対象確認とパスワード変更、退会者データの消し方

あきゅらいず不正アクセス:最大約90万件の対象確認とパスワード変更、退会者データの消し方

化粧品ブランド「akyrise(あきゅらいず)」のECサイトが第三者の不正アクセスを受け、運営するユーグレナが2026年11月5日に公表しました。対象となる可能性があるのはログイン情報が最大約49万件、登録・購入情報が最大約90万件で、退会した人も含まれます。前半で扱うのは、自分は対象か、パスワードはどうするか、届いた連絡は本物かという購入者の疑問と、それに答える公式の文言です。後半ではEC事業者向けに、退会者の個人データを保持期限で匿名化するPythonのバッチを実行結果つきで示します。

まとめ:あきゅらいず不正アクセスの3事象と購入者がまず行うパスワード変更

ユーグレナの公表文には、経路の違う3つの事象が並んでいます。公表文は、ECサイトへの不正アクセスと委託先の2サービスへの不正アクセスを「各々独立した事象」と説明しました。

事象 件数 項目 状況
ECサイト本体(1) 最大約49万件 ID・メール・ハッシュ 精査中
ECサイト本体(2) 最大約90万件 氏名・住所・電話など 精査中
アララのrepica 177,063件 メールアドレスのみ 確定
佐川急便の照会 約5,000件 氏名・住所・電話番号 調査中

クレジットカード番号は、ユーグレナが利用するサーバーで保有しておらず、いずれの対象にも含まれないとされています。公表時点で二次被害は確認されていません。

購入者が今日やることは1つです。あきゅらいずと同じか似たパスワードを他のサービスで使っているなら、そちらを先に変えます。あきゅらいず自体のパスワードの変更方法は、対象者へ個別に届くメールで案内されます。

あきゅらいずの購入者が確かめる対象範囲、届くメールと定期注文の扱い

個別メールで分かる購入者の対象範囲と、退会済みの人も含まれる点

対象は「過去にakyrise(あきゅらいず)ECサイトにおいて商品を購入されたお客さま等(退会された方を含みます)」です。何年も前に一度だけ買った人や、すでに退会した人も外れません。

自分が対象かどうかは、ユーグレナから個別に届くメールで確かめる形です。公表文に、会員番号やメールアドレスを入れて照会するページの案内はありません。補償やお詫びの品についても、11月5日の公表文には記載がありません。メールが届かないまま不安な場合は、後述の専用窓口に電話で尋ねます。

同じパスワードを使う他サービスを先に変える優先順位と具体的な変え方

流出の可能性があるのはハッシュ化されたパスワードで、平文そのものではありません。ただ、ハッシュの方式は公表されておらず、どこまで解読に耐えるかは外から判断できません。公表文が「他のサービスのパスワードを直ちにご変更ください」と書いているのは、このためです。

変える順番は、被害の大きいサービスからです。

  1. 同じパスワードを使っているメールアカウント
  2. ネット銀行、証券、クレジットカードの会員サイト
  3. ポイントや残高を持つ通販・決済サービス
  4. SNSとその他の会員サイト

メールを最初にするのは、他サービスのパスワード再設定がメールで届くからです。変更の際は、サービスごとに別の文字列にします。「Akyrise2024!」を「Akyrise2025!」に変えるような似た形は、公表文の「類似のパスワード」に当たります。漏れた組み合わせが他社のログインで試される手口はパスワードリスト攻撃の検知と漏えい照合の実装で解説しました。

偽の連絡を見分ける基準と、公式が「求めない」と明言した4項目

氏名、住所、電話番号、購入の記録まで揃うと、本物らしい文面を作られます。公表文は「当社または関係先を名乗る連絡であっても」、次の4つを求められたら応じないよう呼びかけています。

  • パスワードやクレジットカード番号の入力
  • 金銭の支払い
  • 送金
  • 認証コードの共有

案内メールが届いた場合も、本文のリンクからカード情報を入れる流れなら偽物です。パスワードの変更方法はメールで案内される予定なので、変更画面を開く前に、ドメインが公式のものかを確かめ、迷ったら窓口に電話します。メール、SMS、電話、郵便物のいずれも注意の対象です。正規の事業者を装う手口の見分け方はフィッシング詐欺の成立の仕組みと対策にまとめています。

専用窓口2本の問い合わせ先と受付時間、サイト閉鎖中の定期注文の扱い

窓口は事象によって分かれます。アララの件もあきゅらいずの窓口で受けています。

窓口 電話番号 受付時間
akyrise専用 0120-405-142 10:00〜17:00(月〜土)
佐川急便専用 0120-28-3449 9:00〜17:00(土日祝も可)

akyrise専用窓口は日曜と祝日が休みです。ECサイトはシステムの改修と安全確認のため一時閉鎖中で、再開の時期は示されていません。既存の注文と継続中の定期注文は、確認を行ったうえで順次出荷するとされています。定期注文の手続きが必要な場合は、個別のメールで案内があります。

別々に数えるあきゅらいず3事象の件数と、公表されていない侵入経路

ECサイト本体の最大約49万件と最大約90万件を足せない理由

ログインアカウントの情報が最大約49万件、登録・購入の情報が最大約90万件で、どちらも精査中の最大値です。①は顧客ID、メールアドレス、ハッシュ化されたパスワード。②は氏名、住所、電話番号、生年月日、性別、メールアドレス、購入・配送の情報などです。

同じ人が両方に含まれているかは公表されていないため、足して139万人とは読めません。②のほうが約41万件多い理由も説明がありません。会員登録をせずに購入した人の記録が含まれるのかどうかは、続報を待つしかない部分です。

アララのrepica経由で確定した177,063件のメールアドレス

メールマガジンの配信に委託先が使っていた、アララ株式会社の「repica」を通じて配信を受けていた人が対象です。ユーグレナは11月2日に委託先から報告を受けました。漏えいしたのはメールアドレスのみで、対象と件数は確定しています。

氏名や住所が漏れたECサイト本体の件とは、危険の種類が違います。配信サービス側の事案の全体と、配信を止められた契約企業が行う作業はアララの不正アクセスと契約企業の対応で扱いました。

佐川急便経由の約5,000件と約3,000名分の差、対象となる発送期間

2026年6月21日から9月30日までに、あきゅらいずの注文が佐川急便で発送された人が対象です。定期購入も含みます。件数が約5,000件で人数が約3,000名分と差があるのは、1人に複数回の発送があるためと読めますが、公表文に説明はありません。

項目は氏名、住所、電話番号で、漏えいの対象と件数は佐川急便が調査中です。ユーグレナは10月1日に委託先から報告を受けました。佐川急便の側の発表は2026年10月23日の第5報まで出ており、事案全体の経緯は佐川急便の情報漏洩の解説にまとめています。

公表されていない侵入経路とハッシュ方式、続報で確かめる4項目

11月5日の公表文で、原因は「調査中」です。次の4つは未公表なので、この記事でも推測しません。

  • ECサイトへの侵入経路と利用された脆弱性
  • パスワードのハッシュ方式とソルトの有無
  • 精査後の確定件数と①②の重なり
  • ECサイトの再開時期と再開時の認証の扱い

第2報が出たら、まず確定件数とハッシュ方式を見ます。方式が弱いと分かった場合、他サービスのパスワードを変えていない人の危険は一段上がります。

会員サイト運営者向け:ハッシュが漏れた時点で行う強制変更と保存方式の基準

NIST SP 800-63B-4の強制変更規定と定期変更の扱いの違い

NIST SP 800-63B-4の3.1.1.2は、定期的なパスワード変更を要求してはならないとする一方、認証情報の侵害を示す証拠があれば変更を強制しなければならないと定めています。ハッシュの持ち出しが確認された時点で、この「証拠」に当たります。全会員の強制変更とセッションの失効をまとめて行う実装は、SONICWIREの全会員パスワード無効化と再設定の実装を参照してください。

同じ節は、新しいパスワードを漏えい済みのリストと照合することも求めています。再開時に旧パスワードと同じ値を許すと、強制変更の意味が消えるので、変更画面では旧ハッシュとの一致も拒否します。

Argon2id 19MiB・反復2回など、OWASPの推奨値で点検する保存方式

自社の保存方式はOWASP Password Storage Cheat Sheetの値と比べます。

方式 OWASPの最低設定
Argon2id メモリ19MiB・反復2・並列1
scrypt N=2^17・r=8・p=1
bcrypt(既存向け) コスト10以上・72バイトまで
PBKDF2-HMAC-SHA256 600,000回

MD5やSHA-256を1回かけただけの保存は、この表のどこにも当てはまりません。「ハッシュ化していた」という説明だけでは安全かどうかは決まらない、ということです。bcryptからの移行コードはbcryptのコスト係数とArgon2idへの移行で示しました。

退会者の個人データを保持期限で匿名化するPythonバッチと実行結果の確認

個人情報保護法22条の消去努力義務と、消してはいけない項目の線引き

今回の対象に「退会された方」が含まれていた点は、購入者より事業者が受け止めるべき事実です。退会した人のログイン情報や住所が残っていれば、その人は退会後も漏えいの当事者になります。

個人情報保護法22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを定めています。ガイドライン(通則編)3-4-1は、利用目的との関係で保有する合理的な理由がなくなった場合を挙げ、法令で保存期間が定められている場合は例外としています。実務の線引きは次のとおりです。

項目 退会後の扱い
パスワードのハッシュ 退会時点で消す
メール・電話・生年月日 問い合わせ期間の後に消す
注文の宛名・配送先 保持期限の後に消す
注文の金額・日付 税務の保存期間まで残す

ハッシュは退会時点で役目を終えます。残す理由がありません。保持する日数は業種と規程で決まるので、税務の保存期間は顧問税理士に確かめてください。

退会者の個人データが何人分残っているかを保持期限別に数える棚卸しSQL

消す前に、残っている量を数えます。次のSQLは、会員を在籍中・退会して期限内・期限切れに分け、ハッシュと電話番号が残っている人数を出します。列名は自社の表に読み替えてください。

-- :cutoff に「今日から保持日数を引いた日時」を渡す
SELECT
  CASE WHEN withdrawn_at IS NULL THEN '在籍中'
       WHEN withdrawn_at < :cutoff THEN '退会・期限切れ'
       ELSE '退会・期限内' END AS 区分,
  COUNT(*) AS 人数,
  SUM(password_hash IS NOT NULL) AS ハッシュあり,
  SUM(phone IS NOT NULL) AS 電話番号あり
FROM members
WHERE anonymized_at IS NULL
GROUP BY 区分
ORDER BY 区分;

4人の検証データで実行すると、次の結果になりました。期限切れの2人に、ハッシュと電話番号が残っています。

('在籍中', 1, 1, 1)
('退会・期限内', 1, 1, 1)
('退会・期限切れ', 2, 2, 2)

dry-runを既定にして束ごとに更新する匿名化バッチのPythonコード

次のコードは、期限切れの会員の個人情報を消し、注文の宛名を消し、セッションを削除します。行そのものは消さず、注文の金額と日付は残す仕組みです。Pythonの標準ライブラリsqlite3だけで動き、検証用の表をメモリ上に作るのでそのまま実行できます。

# 退会から保持期限を過ぎた会員の個人データを匿名化する(Python 3.9以上・標準ライブラリのみ)
# 既定は件数を数えるだけ。--apply を付けたときだけ更新する
import argparse
import sqlite3
from datetime import datetime, timedelta, timezone

RETENTION_DAYS = 90  # 退会後に問い合わせ対応で残す日数。自社の規程で決める
BATCH = 500          # 1トランザクションで処理する人数

SETUP = """
CREATE TABLE members (id INTEGER PRIMARY KEY, email TEXT, password_hash TEXT,
    name TEXT, phone TEXT, birth_date TEXT, withdrawn_at TEXT, anonymized_at TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, member_id INTEGER, total INTEGER,
    ship_name TEXT, ship_address TEXT, ordered_at TEXT);
CREATE TABLE sessions (token_hash TEXT PRIMARY KEY, member_id INTEGER);
"""


def seed(db, now):
    db.executescript(SETUP)
    rows = [
        (1, "mail-1", None),                            # 在籍中
        (2, "mail-2", now - timedelta(days=10)),        # 退会して期限内
        (3, "mail-3", now - timedelta(days=400)),       # 期限切れ
        (4, "mail-4", now - timedelta(days=1200)),      # 期限切れ
    ]
    for mid, mail, gone in rows:
        db.execute(
            "INSERT INTO members VALUES (?,?,?,?,?,?,?,NULL)",
            (mid, mail, "$argon2id$dummy", f"氏名{mid}", "090-0000-0000", "1980-01-01",
             gone.isoformat() if gone else None))
        db.execute("INSERT INTO orders VALUES (?,?,?,?,?,?)",
                   (mid * 10, mid, 3300, f"氏名{mid}", "東京都", "2023-04-01"))
        db.execute("INSERT INTO sessions VALUES (?,?)", (f"t{mid}", mid))
    db.commit()


def targets(db, cutoff):
    return [r[0] for r in db.execute(
        "SELECT id FROM members WHERE withdrawn_at < ? AND anonymized_at IS NULL "
        "ORDER BY id LIMIT ?", (cutoff.isoformat(), BATCH))]


def anonymize(db, ids, now):
    marks = ",".join("?" * len(ids))
    with db:  # 途中で失敗したらこの束ごと巻き戻す
        db.execute(
            f"UPDATE members SET email = NULL, password_hash = NULL, name = NULL, "
            f"phone = NULL, birth_date = NULL, anonymized_at = ? WHERE id IN ({marks})",
            [now.isoformat(), *ids])
        # 金額と日付は会計の保存用に残し、宛先だけを消す
        db.execute(f"UPDATE orders SET ship_name = NULL, ship_address = NULL "
                   f"WHERE member_id IN ({marks})", ids)
        db.execute(f"DELETE FROM sessions WHERE member_id IN ({marks})", ids)


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--apply", action="store_true")
    args = parser.parse_args()

    db = sqlite3.connect(":memory:")
    now = datetime.now(timezone.utc)
    seed(db, now)
    cutoff = now - timedelta(days=RETENTION_DAYS)

    ids = targets(db, cutoff)
    print(f"対象 {len(ids)} 人: {ids}")
    if not args.apply:
        print("dry-run のため更新していません")
    else:
        done = 0
        while ids:
            anonymize(db, ids, now)
            done += len(ids)
            ids = targets(db, cutoff)
        print(f"匿名化 {done} 人 / 再実行時の対象 {len(targets(db, cutoff))} 人")

    print("--- members")
    for row in db.execute("SELECT id, email, password_hash, name FROM members ORDER BY id"):
        print(row)
    print("--- orders")
    for row in db.execute("SELECT id, member_id, total, ship_name FROM orders ORDER BY id"):
        print(row)
    print("--- sessions", [r[0] for r in db.execute("SELECT member_id FROM sessions ORDER BY 1")])


if __name__ == "__main__":
    main()

既定をdry-runにしているのは、消した個人データは戻せないからです。本番では、まず件数を確かめ、バックアップの保持期間も合わせて決めます。バックアップに同じデータが何年も残っていれば、本番だけ消しても持ち出される範囲は変わりません。

–apply の実行結果と、途中で失敗したときの巻き戻しの確認

Python 3.14.10(Windows)で2026年11月9日に --apply を付けて実行した結果です。期限切れの3番と4番だけが消え、在籍中の1番と期限内の2番は変わっていません。

対象 2 人: [3, 4]
匿名化 2 人 / 再実行時の対象 0 人
--- members
(1, 'mail-1', '$argon2id$dummy', '氏名1')
(2, 'mail-2', '$argon2id$dummy', '氏名2')
(3, None, None, None)
(4, None, None, None)
--- orders
(10, 1, 3300, '氏名1')
(20, 2, 3300, '氏名2')
(30, 3, 3300, None)
(40, 4, 3300, None)
--- sessions [1, 2]

途中失敗も試しました。sessions テーブルを消した状態で実行すると no such table: sessions で止まり、3番と4番のメールアドレスと注文の宛名は元のまま残りました。会員だけ消えて注文の宛名が残る、という半端な状態にならないことを確かめています。

注意点が1つあります。このコードで処理の対象になるのは、自社のデータベースだけです。配信サービスや配送会社の管理画面に渡した同じ情報は、別に消す手順が要ります。

委託先に渡す項目と個人情報保護委員会への報告、EC事業者の判断の分かれ目

委託先に渡す項目の差が被害の項目の差になった、repicaと配送の例

3事象を項目で比べると、外部サービスの漏えいは渡していた項目に沿っています。配信サービスからはメールアドレスのみ、配送の照会サービスでは氏名、住所、電話番号です。配信に使う項目がアドレスだけなら、配信サービスが破られても住所は出ません。

配信の差し込みに使うという理由で、生年月日や購入履歴まで同期している構成は、ここで見直す対象です。委託先ごとに扱うデータとアクセス権を台帳で管理し、契約終了時の返却や削除まで確かめる方法は、委託先管理の監督義務とチェックリストで整理しています。

確認の翌日に出した速報と、不正アクセスで60日になる確報の期限

ユーグレナは11月4日に不正アクセスを確認し、11月5日付で個人情報保護委員会へ速報を出しました。ガイドライン3-5-3-3の速報の目安は、事態を知った時点から概ね3〜5日以内です。3-5-3-4の確報は、不正アクセスのような不正の目的によるおそれがある事態では60日以内となります。

速報の時点では、把握している内容を報告すれば足ります。今回のように「最大約」「精査中」のままでも、速報は出せるということです。本人通知を含む全体の流れは個人情報保護委員会への報告義務の実務にまとめました。

退会者データを残してよい条件と、第三者の診断を先に入れる場面

退会者の個人データを残してよいのは、法令の保存義務があるか、返品や問い合わせの対応期間内であるか、の2つの場合に限ります。「また戻ってくるかもしれない」「分析に使うかもしれない」は残す理由になりません。分析に使いたいなら、個人を特定できない集計値に変えてから残します。

ログインにパスワードしか使っていないECサイトは、IPAのECサイト構築・運用セキュリティガイドラインの要件10(利用者のログイン時の二要素認証の導入)も確認します。ただ、会員数が数百人規模で、住所を持たず、外部の決済と配送に任せきりのサイトなら、まず匿名化バッチと項目の棚卸しで足ります。診断に予算を回すのはその後です。

外部へ診断を依頼すべきなのは、会員数が万単位である、管理画面やAPIを自社で作り込んでいる、購入履歴や住所を長年ためている、のいずれかに当てはまる場合です。会員情報を返すAPIの認可とトークンの失効はAPI不正アクセス対策の実装手順で確認でき、自社のECシステムに同じ弱点が残っていないかを第三者に確かめたい場合は脆弱性診断・セキュリティ診断で相談できます。

よくある質問

あきゅらいずの不正アクセスについて、購入者から出やすい質問をまとめました。内容は2026年11月5日の公表文に基づきます。

あきゅらいずの不正アクセスで自分が対象かどうかはどう確かめますか?

対象の人にはユーグレナから個別にメールが届きます。公表文に、自分で照会するページの案内はありません。対象は過去にakyriseのECサイトで商品を購入した人などで、退会した人も含まれます。メールが届かず確かめたい場合は、akyrise専用窓口(0120-405-142、10時〜17時、月〜土、日祝除く)に問い合わせます。なお、アララや佐川急便の件は対象の条件が別です。

退会済みでも個人情報が漏れている可能性はありますか?

あります。公表文の対象には「退会された方を含みます」と明記されています。ログイン情報が最大約49万件、登録・購入情報が最大約90万件で、どちらも精査中の最大値です。退会済みの人も、あきゅらいずと同じか似たパスワードを他のサービスで使っているなら、そちらを変更します。登録していたメールアドレスに届く案内も確認してください。

クレジットカードの情報は漏れましたか?

公表文によると、クレジットカード番号はユーグレナが利用するサーバーで保有しておらず、対象に含まれていません。ただし、購入の記録や住所を使って、カード番号の入力を求める偽の連絡が届くおそれがあります。ユーグレナからの呼びかけは、関係先を名乗る連絡でカード番号や認証コードを求められても応じないように、というものです。不審なサイトに入力してしまった場合は、カード発行会社へすぐ連絡します。

あきゅらいずのパスワードはどう変更すればいいですか?

ECサイトは一時閉鎖中で、変更方法は対象者へ個別に届くメールで案内されます。先に手を付けられるのは、同じか似たパスワードを使っている他のサービスの変更です。メール、銀行、決済のサービスから順に変えます。案内メールのリンクを開くときは、カード番号や認証コードを求められないか確かめ、迷ったら窓口に電話します。

あきゅらいずの通販サイトはいつ再開しますか?定期便は届きますか?

2026年11月5日の公表文に再開の時期は書かれていません。システムを改修し、安全性を確認したうえで再開するとしています。既存の注文と継続中の定期注文は、確認を行ったうえで順次出荷されます。定期注文について手続きが必要な場合は、対象者に届くメールで案内される予定です。サイトが閉じている間の問い合わせはakyrise専用窓口で受けています。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.07 コラム サイバーセキュリティ緊急対策パッケージとは?4本柱の施策と期限、企業と委託先が今やること
  2. 2026.11.06 テックブログ ドコモ不正アクセス:最大29.5万件の流出項目と見舞金、My docomo停止の経過と偽連絡の見分け方
  3. 2025.04.30 テックブログ IMSIキャッチャー(偽基地局)とは?2Gフォールバックの手口と日本での対策
  4. 2026.11.03 テックブログ ネットマイル不正アクセスで最大約549万人に漏えいの可能性:ログイン・マイル・退会・登録した覚えがない場合
  5. 2026.11.06 テックブログ あいおいニッセイ同和の不正アクセス:44.4万件の漏えい項目と窓口、止まった手続きの代わり

RELATED POSTS 関連記事

目次