メール配信サービス「アララ メッセージ」を運営するアララ株式会社が不正アクセスを受け、親会社のペイクラウドホールディングスが2026年11月2日に第2報を開示しました。当初の約301万件から範囲が広がり、契約企業のサーバー97台からメールアドレス約77百万件と会員情報が持ち出されています。送信元 news@arara.com からカード会社を装うメールも最大約713万通送られました。前半では受信者と利用者が確かめることを、後半では契約企業が行う認証情報の再設定、送信ドメインの点検、通知メールを別の配信元へ切り替える実装、個人情報保護委員会への連名報告を整理します。
まとめ：アララ メッセージの不正アクセスで起きた3つの被害と契約企業が先にやること
ペイクラウドホールディングスの第2報は、被害を3つの区分に分けています。件数はどれも11月1日時点で、精査中です。区分の間で同じアドレスが重なる可能性があるため、合算はされていません。
| 区分 | 時期 | 対象 | 件数 |
|---|---|---|---|
| (1) サービス経由の侵入 | 10/28〜31 | 契約企業のサーバー97台 | アドレス約77百万件と会員情報 |
| (2) 共用環境 | 10/27〜28 | 契約企業61社 | アドレス3,386,187件ほか |
| (3) 不審メール送信 | 10/28〜30 | 2つの環境 | 最大約713万通 |
約77百万件はアドレスの数で、利用者の人数ではありません。会員情報は契約企業が登録した項目で、氏名・性別・生年月日・電話番号・会員番号・住所などが含まれます。クレジットカード番号はアララのサービスでは保有していません。
契約企業が先にやることは4つです。自社の環境が対象かをアララからの個別連絡で確かめる。APIキーと管理画面のパスワードを再設定する前提で、使っている箇所を洗い出す。止まっている認証・通知メールを別の経路で送る。個人情報保護委員会への報告を連名で出すか決め、11月9日18時の申込期限に間に合わせる。
受信者・利用者向け：news＠arara.comの不審メールと会員情報の流出範囲
「利用内容確認のご依頼」などカード会社を装うメール約713万通への対処
10月28日から30日にかけて、送信元 news@arara.com から「利用内容確認のご依頼」「ご利用明細確認のご依頼」などの件名のメールが届いた場合、本文のURLは開かずに削除するよう第2報は求めています。アララの配信基盤そのものが第三者に使われたため、送信元のドメインは本物です。送信元アドレスを見て本物かどうかを見分けることはできません。
リンク先でカード情報を入力してしまった人は、すぐにカード発行会社へ連絡します。アララとペイクラウドホールディングスは、パスワードやカード情報の入力をメールで求めることはないとしています。正規の送信元からでも偽の内容が届く仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しました。
不審メールを受け取っても自分の情報が流出したとは限らない理由
第2報は、不審メールの送信先を「第三者が外部から持ち込んだメールアドレス」と書いています。つまり、このメールが届いたことは、アララの契約企業の会員だった証拠になりません。不正送信そのものでアドレス以外の情報が漏れたことも確認されていない、という説明です。
反対に、不審メールが届いていなくても、区分(1)や(2)で会員情報が持ち出されている可能性は残ります。自分が対象かどうかは、登録していた通販サイトや会員サービス（＝アララの契約企業）からの連絡で確かめます。アララが公表している窓口は契約企業向けのもので、個人からの照会先は示されていないためです。
契約企業の公表で対象を知る、再委託を含む利用の形と沖縄県の例
アララ メッセージは、企業が直接契約するほか、販売代理店や業務の受託事業者を通して使われています。沖縄県の10月29日の公表は後者の例です。県が委託した事業者がメールマガジンの配信にアララ メッセージを使っており、会員のメールアドレス2,560件が漏れた可能性があるとしています。
このように、利用者から見るとアララの名前は表に出ません。県や企業は、自社の名をかたる不審メールへの注意も呼びかけています。漏れたアドレスあてに、会員登録先を装った連絡が届くおそれがあるためです。同型の構造で会員のアドレスが流出した事案は東京メトロ（メトポ）の情報漏洩でも扱いました。
公表資料で追う経緯：10月27日の偵察から31日の全面停止までの時系列
別表1から抜き出した主な日時と、区分ごとの発生時刻と把握時刻のずれ
第2報の別表1は、既報の後の調査で分かった日時を含めて経緯を並べています。データの持ち出しと把握の間には、区分(1)で1日以上の差がありました。
| 日時 | 出来事 |
|---|---|
| 10/27 08:36 | 偵察とみられるアクセス |
| 10/28 03:59頃 | 不審メールの送信が始まる（区分3） |
| 10/28 11:09〜15:43 | 共用環境の管理画面に不正ログイン・搬出（区分2） |
| 10/28 16:31 | 共用環境を緊急停止 |
| 10/29 01:36〜10/30 02:22 | サービス経由の持ち出し（区分1） |
| 10/30 13:26 | 別環境の通信を遮断（13:32が最後の送信） |
| 10/31 午前 | 区分1の持ち出しを把握 |
| 10/31 19:53 | 全サービスの停止を完了 |
区分(1)の持ち出しは10月29日の未明に始まり、把握されたのは31日の午前です。アララは10月30日の続報で「それ以外の環境での流出はない」と知らせていましたが、この説明は第2報で覆りました。
共用環境の管理画面への不正ログインと、持ち出しに使われたデータ出力機能
区分(2)では、第三者が共用環境の管理画面に不正にログインし、データの出力機能などを使って持ち出しました。アララの公式お知らせの過去分では、この環境を「bvam001」と呼んでいます。メールアドレス3,386,187件（重複を除いた数）のほか、契約企業5社が登録した氏名・会社名などの顧客データ最大411,827件が含まれます。
管理画面に正規の出力機能がある以上、ログインを許した時点で一括の持ち出しは止められません。原因について第2報は、初報の「Webサーバーの脆弱性」に加えて「システム環境における問題」も関係していたと書いています。脆弱性の名称、侵入の経路と開始時期は11月2日時点で公表されていません。
契約企業のサーバー97台に広がった侵入と、無効化された認証情報
区分(1)は、第三者がアララのサーバーに入り、そこを足がかりに多数のサーバーへ侵入してデータベースの中身を持ち出したものです。アララは10月31日、不正に使われたアカウントと鍵の無効化、各サーバーの通信の遮断を順に行いました。対象の契約企業の数は推計で最大約380社です。
第2報は、一連の不正アクセスを攻撃元の共通性などから同じ第三者によるものとみています。同じペイクラウドホールディングスのグループでは10月にモスカードの不正アクセスも公表されていますが、別のサービスの事案で、本件との関係は示されていません。
契約企業が今日行う作業：APIキーと管理画面パスワードの再設定と送信ドメインの点検
停止中の7サービスと予約配信が実行されないことによる業務への影響
アララは10月31日14時50分から、次のサービスをすべて止めています。管理画面とAPIは使えません。オンプレミス版のrepicaシリーズは停止の対象外です。
- アララ メッセージ GUI、API v1、API v2
- ASP repica editor、sender、auto-mail
- BMAエラーリスト取得機能
停止前にAPIや管理画面で予約した配信も実行されません。会員登録の確認メール、ワンタイムコード、購入完了の通知などをアララのAPIで送っていた場合、その機能は今も止まったままです。再開の時期は未定なので、復旧を待つのではなく、別の送信経路を用意する判断になります。
APIキーを使う箇所の洗い出しと、再開時に求められる認証情報の再設定
第2報の別表2は、契約企業がAPI接続に使う認証情報（APIキー等）について、区分(1)を「利用停止中」としています。管理画面を使う担当者の氏名やメールアドレスが漏れたかは「確認中」です。再開にあたっては、管理画面のパスワードとAPIキーの再設定を契約企業に求める予定だとしています。
再開の連絡が来てから慌てないよう、APIキーを置いている場所を今のうちに洗い出します。本番と検証の環境変数、CIのシークレット、バッチサーバーの設定ファイル、外部のMAツールの連携設定などです。同じパスワードをほかの業務サービスで使っている担当者は、そちらを先に変えます。鍵を入れ替えるときに古い鍵を確実に失効させる手順はAPIキーの発行・保管・失効とローテーション、SaaS側の侵害で鍵とWebhook URLを替えた同型の事案はStudioの不正アクセスとAPIキー・Webhook URLの交換手順にまとめました。
自社ドメインのSPF・DMARCを確かめるコマンドと、配信元を外す判断
自社ドメインから送るために、DNSのSPFレコードに配信事業者を加えている契約企業は多いはずです。今回の不審メールは news@arara.com から送られており、契約企業のドメインがかたられたとは公表されていません。それでも、使っていない配信元を自社ドメインの送信者として認めたままにしておく理由はありません。
# 自社ドメインのSPFとDMARCを確かめる（Windows・macOS・Linuxで同じ）
nslookup -type=TXT example.co.jp
# "v=spf1 include:... include:... ~all" の include に、止めた配信事業者の値が残っていないか
nslookup -type=TXT _dmarc.example.co.jp
# "v=DMARC1; p=none; ..." のままなら、p=quarantine 以上へ上げる計画を立てるSPFの include は、指定したドメインの許可リストをそのまま取り込む仕組みです（RFC 7208）。配信元を別のサービスへ移したら、古い include を外し、新しい配信元の値を足します。ただし外すと、アララが再開しても自社ドメインでの配信は届きにくくなります。再開後も使うなら残し、使わないと決めた時点で外す、が判断の線です。レコードの書き方はSPFレコードの書き方と設定の判断基準、DMARCを上げる手順はフィッシング対策ガイドラインのDMARC要件と移行手順で解説しました。
止まった配信基盤の代わりに認証・通知メールを副系の配信元へ切り替える実装
主系の配信APIが503や401を返したら副系へ送るPythonの切り替え処理
今回のように配信事業者が全面停止すると、主系のAPIは接続できないか、5xxを返します。再開後に古いAPIキーが無効になれば401です。次のコードは、主系が失敗したら副系の配信APIへ送り直し、失敗した主系は5分間候補から外します。Pythonの標準ライブラリurllib.requestだけで動き、URLとキーは環境変数で渡します。
# 認証・通知メールを主系の配信APIで送り、止まっていれば副系へ切り替える
# （Python 3.9以上・標準ライブラリのみ。URLとキーは環境変数で渡す）
import json, os, time, urllib.error, urllib.request
PROVIDERS = [
{"name": "primary", "url_env": "MAIL_PRIMARY_URL", "key_env": "MAIL_PRIMARY_KEY"},
{"name": "secondary", "url_env": "MAIL_SECONDARY_URL", "key_env": "MAIL_SECONDARY_KEY"},
]
HOLD_SEC = 300 # 失敗した配信元を候補から外しておく秒数
FAILOVER = {401, 403, 429} # 鍵の無効化・権限・流量制限は切り替えで逃がす
_down = {} # 配信元名 -> 外した時刻
def send(to, subject, body):
for p in PROVIDERS:
if time.time() - _down.get(p["name"], 0) < HOLD_SEC:
print(f"skip {p['name']} (held)")
continue
req = urllib.request.Request(
os.environ[p["url_env"]],
data=json.dumps({"to": to, "subject": subject, "text": body}).encode(),
headers={"Authorization": "Bearer " + os.environ[p["key_env"]],
"Content-Type": "application/json"},
method="POST")
try:
with urllib.request.urlopen(req, timeout=5) as r:
print(f"sent via {p['name']}: HTTP {r.status}")
return p["name"]
except urllib.error.HTTPError as e:
if e.code < 500 and e.code not in FAILOVER:
raise # 400や422は宛先・本文の誤り。切り替えても直らない
reason = f"HTTP {e.code}"
except (urllib.error.URLError, TimeoutError) as e:
reason = type(e).__name__
_down[p["name"]] = time.time()
print(f"{p['name']} failed ({reason}) -> next")
raise RuntimeError("all providers failed")リクエストの形（JSONの項目名と認証ヘッダ）は配信事業者ごとに違うため、実際には事業者ごとに組み立て部分を分けます。副系の候補としては、Amazon SESのSMTPとAPIのように、自社のクラウド環境の中で用意できる送信元が切り替えに向いています。
ローカルの偽APIで5つの状況を再現した実行結果と、切り替えない失敗
動きを確かめるため、127.0.0.1に主系と副系の偽APIを立て、主系の返す状態を変えながら5回呼び出しました。Python 3.14.7（Windows）で2026年11月2日に実行した結果です。アララ メッセージのAPI仕様を再現したものではありません。
# case1: primary 503
primary failed (HTTP 503) -> next
sent via secondary: HTTP 202
# case2: 直後の2通目（主系は保留中）
skip primary (held)
sent via secondary: HTTP 202
# case3: 保留解除後、主系がAPIキー無効で401
primary failed (HTTP 401) -> next
sent via secondary: HTTP 202
# case4: 主系が復旧（200）
sent via primary: HTTP 200
# case5: 本文の誤り（400）は切り替えない
raised: HTTP Error 400: Bad Request2通目は主系を試さずに副系へ送っています。止まった配信元に毎回5秒待たされると、ワンタイムコードの画面が利用者を待たせ続けるためです。case5のように400で例外を返すのは、宛先や本文の誤りを副系へ回すと、同じ誤りのメールが2つの配信元から出ていくからです。
この切り替えを入れてよいのは、認証コードや購入完了など、1通ずつ即時に送るメールです。メールマガジンのような一斉配信は副系へ流さず、配信停止の申し出をした人の一覧を副系でも守れると確かめてから移します。一覧を移さずに送ると、配信停止を申し出た人にもメールが届くためです。配信サービスの乗り換え先を比べる軸はメール配信システムの選び方と到達率・料金の選定軸で整理しています。
個人情報保護委員会への報告：連名報告の申込期限11月9日と自社で報告する場合の期限
委託元と委託先の双方が報告義務を負う、ガイドライン3-5-3-2の考え方
個人情報保護法ガイドライン（通則編）は、個人データの取扱いを委託している場合、報告の対象になる事態では原則として委託元と委託先の双方が報告義務を負うとしています。そのうえで、両者の連名で報告できるとしています。アララに会員のアドレスを預けていた契約企業は委託元にあたり、アララが報告したから自社は関係ない、とはなりません。
本件は不正アクセスによる漏えいで、確報の期限は事態を知った日から60日以内です。30日以内の通常の事態より長いものの、速報の目安はおおむね3〜5日です。報告と本人通知の全体の流れは個人情報保護委員会への報告義務の実務にまとめました。
アララの連名報告・代行報告を選ぶ条件と、JIPDECへの報告を自社で行う点
アララの案内ページによると、民間の企業・団体・個人事業主は連名報告、行政機関・独立行政法人・地方公共団体は代行報告になります。申込期限は2026年11月9日（月）18時です。申し込んだ契約企業は、自社で個別に委員会へ報告する必要はありません。
| 項目 | アララの案内 |
|---|---|
| 民間の契約企業 | アララとの連名報告 |
| 行政機関・自治体等 | アララによる代行報告 |
| 他社から受託して利用 | 連名・代行の対象に含む |
| 速報の目安超過 | 遅延として扱わない旨を委員会に確認済み |
| JIPDECへの報告 | 対象外。プライバシーマーク付与事業者は自社で |
連名報告で足りるのは委員会への報告だけです。本人への通知、プライバシーマークの報告、取引先への説明は自社に残ります。沖縄県の例のように自社が別の会社から業務を受けてアララを使っていた場合は、その会社への連絡も先に済ませます。委託先が起点になる事案での報告の分担はサイバー対処能力強化法と委託先への影響でも整理しました。
事業者の判断：配信SaaSを使い続ける条件と、第三者診断を入れる範囲
再開後もアララ メッセージを使い続けてよい条件と、乗り換えを決める場面
再開後に使い続けるかは、第3報以降で次の3点が示されるかで決めます。侵入の経路と開始時期が特定されたこと。認証情報の全面的な変更とシステムの再構築を終えたこと。区分(1)で自社の環境が対象だったかと、持ち出された項目が個別に示されたことです。前の2点は、第2報が再開の判断材料として自ら挙げている項目です。
乗り換えを決めるのは、認証コードや決済完了の通知など止まると売上や問い合わせに直結するメールを、単一の配信事業者に頼っている場合です。この場合は再開を待たず、副系を用意したうえで主系を選び直します。会員数が少なくメールマガジンだけを送っている会社なら、再開を待って認証情報を替える対応で足ります。
外部の配信サービスと自社システムのつなぎ目を診断で確かめる範囲
今回の事案で、契約企業のシステム自体が破られたとは公表されていません。それでも、外部サービスに渡しているAPIキーの権限、管理画面のアカウントの棚卸し、出力機能を誰が使えるか、会員データを丸ごと配信側へ同期していないか、は自社側で決めている設定です。配信に要らない生年月日や住所まで同期している構成なら、渡す項目を減らすだけで次の事故の被害が小さくなります。
自社のWebシステムと外部サービスの連携に同じ弱点が残っていないかを第三者に確かめてもらいたい場合は、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
アララの不正アクセスについて、受信者・利用者・契約企業から出やすい質問をまとめました。
news＠arara.comからのメールは開いても大丈夫ですか？
10月28日から30日にかけて news@arara.com から届いた「利用内容確認のご依頼」「ご利用明細確認のご依頼」などのメールは、第三者がアララの配信基盤を使って送った不審メールです。本文のURLにはアクセスせず、削除してください。リンク先でカード情報などを入力した場合は、すぐにカード発行会社に連絡します。アララはパスワードやカード情報の入力をメールで求めないとしています。
自分の個人情報がアララの件で流出したかを確かめる方法はありますか？
アララは個人からの照会窓口を公表していません。アララのサービスは企業のメール配信に使われていたため、対象かどうかは、登録していた通販サイトや会員サービスなどの契約企業からの連絡やお知らせで確かめます。アララは契約企業へ、各社の環境が対象かと流出した内容を個別に連絡するとしています。不審メールが届いたことは、流出の対象だった証拠にはなりません。
アララの不正アクセスでクレジットカード番号は漏れましたか？
第2報によると、アララのサービスではクレジットカード番号を一切保有していません。流出したのは、メールアドレスと、契約企業が登録した氏名・性別・生年月日・電話番号・会員番号・住所などの会員情報、配信の宛先などの記録です。項目は契約企業ごとに違います。ただし、偽のカード会社のメールでカード情報を入力させる手口が実際に使われているため、入力してしまった場合は発行会社へ連絡してください。
アララ メッセージはいつ再開しますか？
11月2日時点で再開の時期は未定です。アララは、侵入経路の特定、認証情報の全面的な変更、システムの安全性の確認などを行ったうえで判断するとしています。再開時には、契約企業に管理画面のパスワードとAPIキーなどの再設定を依頼する予定です。停止中は予約済みの配信も実行されないため、止められない通知メールは別の経路での送信を検討します。
契約企業は個人情報保護委員会へ自分で報告する必要がありますか？
アララの連名報告（行政機関などは代行報告）を11月9日18時までに申し込めば、自社で個別に報告する必要はありません。連名報告を申し込まず、自社で個別に報告する方法も選択可能です。ガイドラインでは、委託している場合は原則として委託元と委託先の双方が報告義務を負い、連名で報告できるとされています。プライバシーマーク付与事業者は、JIPDECへの報告を自社で行う必要があります。
関連記事
- Studio不正アクセスで全顧客の情報流出か｜連名報告の受付とAPIキー・Webhook URLを今日替える手順：SaaS側の侵害で契約企業が鍵を替えた同型の事案
- APIキー管理とは？発行・保管・失効とローテーションの実装を解説：再設定のときに古い鍵を確実に止める手順
- フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：正規の送信元から偽の内容が届く仕組み
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：連名報告の前提になる報告の流れ
- 東京メトロ（メトポ）の情報漏洩・不正アクセス｜約5.9万件のメールアドレスと会員の対処：会員のアドレスが漏れた別の事案
