自治体の防災メールや防災情報の電話・FAX配信に使われている一斉配信サービス「SpeeCAN RAIDEN」が第三者の不正アクセスを受け、運営する株式会社アルカディア（大阪府箕面市）は2026年10月13日、メールアドレス最大約313万6千件などが漏洩した可能性があると公表しました。翌14日には、消防のNET119と119RAIDENにも不正アクセスの形跡が見つかっています。前半は、自分は対象か、どこに問い合わせるか、配信が止まっている間の防災情報をどう受け取るか、届いたメールは本物かという登録者の疑問への、公式発表に沿った回答です。後半では、配信元ドメインのSPF・DMARCを実測した結果と、受信メールの差出人を判定するPythonを示し、配信を委託する自治体や企業が見直す範囲を整理します。
まとめ：SpeeCAN RAIDEN不正アクセスで公表された事実と登録者・委託元の対応
公表されているのは、10月11日16時30分に不審な挙動を確認し、12日3時ごろに侵入経路を塞ぐ応急措置を取り、13日に漏洩の可能性を発表したという経過です。件数はいずれも推定値で、外部に取られたと確定した数ではありません。侵入経路は判明したとされていますが、内容は公表されていません。
登録者がまずやることは2つです。自治体やサービス名を名乗るメールのURLと添付ファイルを開かないこと、配信が止まっている自治体では防災情報を自治体の公式サイトや気象庁の情報で確かめることです。配信を委託している側は、配信履歴の本文まで漏洩対象に入った点を重く見て、本文に何を書いてきたかを点検します。
| 項目 | 公表されている内容（2026年10月15日時点） |
|---|---|
| 運営会社 | 株式会社アルカディア（大阪府箕面市） |
| 検知と応急措置 | 10月11日16時30分に検知、12日3時ごろ遮断 |
| RAIDENの最大件数 | メール・電話・FAX（推定値は表の直後） |
| RAIDENの対象項目 | 連絡先・担当者・契約情報・配信履歴の本文 |
| 追加の対象 | NET119・119RAIDEN |
| 決済情報 | RAIDENでは扱っておらず対象外 |
| 問い合わせ先 | 個人情報相談窓口 050-5830-0750 |
| 未公表 | 侵入経路の内容、確定した件数 |
RAIDENの最大件数は、メール約313万6千・電話約10万5千・FAX約1万5千です。対象項目の連絡先には名前・メール・電話・FAXが含まれ、担当者、契約情報、配信履歴の本文も対象です。NET119・119RAIDENの追加公表は10月14日でした。個人情報相談窓口の受付時間は平日9〜17時で、土日祝と年末年始を除きます。
登録者が最初に確かめること：対象サービスの見分け方と問い合わせ先・配信停止の状況
過去に届いた防災メールの差出人ドメインで対象サービスかを確かめる手順
アルカディアの公式ブログは、漏洩の可能性がある対象として、raiden.ktaiwork.jp、raiden2.ktaiwork.jp、raiden3.ktaiwork.jp、raiden2.speecan.jp、s.ktaiwork.jp、s2.ktaiwork.jpの6つを挙げています。NET119と119RAIDENについては、net119.speecan.jp、net119fd.speecan.jp、fs119.ktaiwork.jpが対象です。
登録者の手元で確かめやすいのは、これまでに受け取った防災メールの差出人アドレスです。たとえば島田市の防災メールの案内は、受信許可リストに「raiden.ktaiwork.jp」を登録するよう求めています。差出人の「@」より後ろが上の一覧と同じなら、対象サービスに登録している可能性が高いと考えられます。ただしこれは目安です。自分の登録情報が実際に含まれるかは、住んでいる自治体の発表で確かめてください。
個人で登録していなくても、勤務先の安否確認で使われている場合があります。NTTドコモビジネスはSpeeCAN RAIDEN for ビジネスプラスとして、社員への安否確認や業務連絡の一斉配信に提供しているサービスです。会社から届く安否確認メールの差出人も同じ方法で確かめられます。
個人情報相談窓口050-5830-0750と自治体の問い合わせ先の使い分け
アルカディアの窓口は個人情報相談窓口で、電話番号は050-5830-0750、受付は午前9時〜午後5時（土日祝・年末年始を除く）です。10月15日の更新では問い合わせが多く電話がつながりにくいとして、つながらない場合は公式ブログに載ったメールアドレスへ連絡するよう求めています。
自分の自治体の登録件数や再開の予定は、自治体の窓口が答える範囲です。さいたま市の第1報は防災課、香川県は危機管理課を問い合わせ先にしています。電話をかけるときは、届いたメッセージに書かれた番号ではなく、公式サイトに載った番号を使ってください。漏洩後に届く連絡の真偽を確かめた別の事例はタイムズカーの情報漏洩と0120-25-8924の真偽で整理しています。
配信停止中の防災情報の受け取り方と10月15日15時ごろの一部復旧
アルカディアは10月13日11時から、侵入経路となったSpeeCAN RAIDEN（raiden3.ktaiwork.jpの利用者）とライデン・スクール（s2.ktaiwork.jpの利用者）を緊急停止しました。10月15日13時30分の更新では、安全性を社内で確認したとして、同日15時ごろを目途に2つのサーバを復旧する予定とし、利用する管理者にログインパスワードの変更を求めています。
サーバが復旧しても、各自治体がすぐに配信を再開するとは限りません。香川県は10月13日11時から配信を止め、復旧日時は未定としていました。岡山市は停止中の気象情報や避難情報について、気象庁、岡山県、岡山市のホームページや報道で確かめるよう案内しています。大雨や地震の時期と重なると、防災メールが来ないことに気づかないまま過ごすおそれがあります。停止中は防災行政無線や自治体の公式サイトを自分から見に行く運用に切り替えてください。
不審メールへの備え：システム名を名乗る送信元のメールと自治体が出した注意喚起
さいたま市に寄せられた不審メールの問い合わせと注意喚起の文言
さいたま市の第1報によると、10月13日12時50分、市民から「送信元アドレスにシステム名の文字列が入った不審メールを受信した」という問い合わせがあり、市は12時52分にアルカディアへ確認して不正アクセスを把握しました。その不審メールが今回の漏洩と関係するかは、発表では確かめられていません。
アルカディアは10月14日、自治体などの管理者に向けて、登録者への注意喚起の文例を公開しました。不審な連絡に対して氏名、住所、パスワード、口座情報などの個人情報を決して提示・入力しないこと、身に覚えのない送信元や不審なメッセージに記載されたURL・添付ファイルを開かないことの2点です。香川県と岡山市も、自治体をかたる不審な電子メールの添付ファイルやURLを開かないよう呼びかけています。
漏洩の可能性がある項目から想定される連絡と、応じてはいけない依頼
RAIDENで対象とされたのは、メールアドレスや電話・FAX番号に加えて、配信履歴として保存された本文です。攻撃者の手にあるかもしれないのは「この人はこの自治体の防災メールに登録している」という事実と、過去に届いた防災メールの文面です。それらしい件名と文面を作るのは難しくありません。
警戒すべき名目は、配信再開に伴う「再登録」「本人確認」「登録情報の更新」です。防災メールの登録に氏名や電話番号の入力を求めない自治体もあり、島田市の案内には「氏名や電話番号などの個人情報の入力はありません」と書かれています。再登録をうながすメールが来ても本文のリンクは使わず、自治体の公式サイトから登録ページを開き直してください。偽の連絡が成り立つ仕組みはフィッシング詐欺の仕組みと技術的対策で解説しています。
公式発表で追う経過：10月11日の不審な挙動の検知からNET119への拡大まで
10月11日16時30分の検知から10月15日の一部復旧予定までの時系列
- 10月11日16時30分：SpeeCAN RAIDENで不正アクセスが疑われる不審な挙動を確認
- 10月12日3時ごろ：侵入経路を塞ぐ応急措置を講じ、影響範囲の調査を開始
- 10月13日：漏洩の可能性を公表、11時からraiden3とs2の環境を緊急停止
- 10月13日18時47分：侵入経路が判明、不正なアクセス元のIPアドレスを拒否
- 10月14日15時：NET119と119RAIDENにも不正アクセスの形跡と公表
- 10月14日16時：fs119.speecan.jpと119r.speecan.jpは対象外と訂正
- 10月15日10時12分：個人情報保護委員会への報告と、警察・総務省などへの相談を公表
- 10月15日13時30分：停止した2つのサーバを15時ごろ復旧する予定と告知
検知から公表までは約2日です。13日の更新では、停止していないサービスについてもサーバを点検し、不正なプログラムが設定されていないことを確認したとしています。14日には、全サービスを対象に不正なプログラムの有無を調べる範囲の拡大を伝えました。侵入経路は「判明した」とだけ書かれ、どの機能のどの脆弱性かは公表されていません。
RAIDENとNET119・119RAIDENで異なる対象項目と件数の読み方
| 対象 | 漏洩の可能性がある項目 | 最大件数（推定） |
|---|---|---|
| SpeeCAN RAIDEN | 連絡先・担当者・契約情報・配信履歴の本文 | メール・電話・FAX（内訳は表の直後） |
| NET119・119RAIDEN | 上記に加え利用者の名前・生年月日・性別・住所など | 「約13000件」（内訳は表の直後） |
RAIDENの連絡先は名前・メール・電話・FAXで、担当者、契約情報、配信履歴の本文も含みます。最大件数の推定内訳はメール約3,136,000・電話約105,000・FAX約15,000です。NET119・119RAIDENは「約13000件」と記載され、内訳にはメール約97,000・電話約17,000・FAX約400とあります。
NET119と119RAIDENでは、利用者の生年月日、性別、住所まで項目に入っています。RAIDENより件数は少ないものの、1件あたりの情報はより詳しい内容です。なお、NET119の映像通報は10月14日17時12分の更新で、現時点で漏洩の可能性は無いとされています。
NET119側の件数表記には注意が要ります。「最大件数 約13000件」の下に「メールアドレス：約97000件」が並び、内訳が合計より大きくなっています。13,000件が利用者の人数を指すのかなど、関係は説明されていません。本記事は数字を補正せず、公表のとおり載せています。RAIDENのメールアドレス約313万件も、公式は「あくまでも推定値」とし、調査を続けている段階の数字です。
送信ドメインのSPF・DMARCを実測し、受信メールの差出人をPythonで判定する手順
ktaiwork.jpとspeecan.jpのSPF・DMARC設定をDNSで確認
本物の防災メールかを機械的に確かめる手がかりは、送信ドメインが公開しているSPFとDMARCです。2026年10月15日に、配信元の2つのドメインをnslookupで調べました（宛先アドレスなどは省略しています）。
> nslookup -type=TXT _dmarc.ktaiwork.jp 8.8.8.8
"v=DMARC1; p=quarantine; rua=mailto:（省略）; ruf=mailto:（省略）"
> nslookup -type=TXT _dmarc.speecan.jp 8.8.8.8
"v=DMARC1; p=none"
> nslookup -type=TXT ktaiwork.jp 8.8.8.8
"v=spf1 +ip4:（3つのアドレス範囲） -all"ktaiwork.jpとspeecan.jpはどちらも、SPFで送信を許すサーバのアドレス範囲を列挙し、末尾を-all（それ以外は不可）で閉じています。差が出るのはDMARCです。DMARCの仕様（RFC 9989）では、p=quarantineは認証に失敗したメールを疑わしいとみなすよう受信側に求める値で、p=noneは扱いについて何も希望しないという値です。raiden3.ktaiwork.jpやnet119.speecan.jpには個別の_dmarcレコードが無く、上位のドメインの方針が使われます。
つまり、ktaiwork.jpを名乗って認証に失敗したメールは、DMARCに従う受信サービスで迷惑メールフォルダ側に送られやすくなります。speecan.jpを名乗るメールは、認証に失敗しても受信側への指示がありません。SPFとDMARCの書き方はSPFレコードの書き方と設定の判断基準、quarantineとrejectの差はDMARCのquarantineとrejectの違いで解説しています。
Authentication-Resultsから受信メールの差出人を調べるPython
受信したメールの真偽は、メールソフトで「メッセージのソースを表示」してヘッダを見ると確かめられます。受信サーバは認証結果をAuthentication-Resultsヘッダ（RFC 8601）に書き込む仕組みです。次のスクリプトは、.eml形式で保存したメールから差出人のドメインと、SPF・DKIM・DMARCの結果を取り出して判定します。解析にはPython標準のemail.parserを使っています。
# 受信したメール（.eml）の差出人ドメインと認証結果を表示する（Python 3.9以上・標準ライブラリのみ）
# 使い方: python check_mail.py 受信メール.eml
import re, sys
from email import policy
from email.parser import BytesParser
from email.utils import parseaddr
# 自治体の案内に載っている配信元ドメイン（自分の自治体の案内で必ず確かめて書き換える）
OFFICIAL = ("ktaiwork.jp", "speecan.jp")
with open(sys.argv[1], "rb") as f:
msg = BytesParser(policy=policy.default).parse(f)
name, addr = parseaddr(str(msg["From"]))
domain = addr.rpartition("@")[2].lower()
official = any(domain == d or domain.endswith("." + d) for d in OFFICIAL)
print("差出人ドメイン:", domain, "（案内のドメイン）" if official else "（案内に無いドメイン）")
# 受信側サーバが付けた認証結果。複数ある場合は先頭（自分の受信サーバに近い側）を見る
ar = msg.get_all("Authentication-Results") or []
results = {}
if ar:
for key in ("spf", "dkim", "dmarc"):
m = re.search(key + r"=(\w+)", str(ar[0]))
results[key] = m.group(1) if m else "記載なし"
print("認証結果:", results or "Authentication-Results ヘッダなし")
if not official:
print("判定: 案内のドメインではない。リンクを開かず、自治体の公式サイトで確かめる")
elif results.get("dmarc") != "pass":
print("判定: ドメイン名は案内どおりだが DMARC が pass ではない。なりすましの可能性がある")
else:
print("判定: 送信元の認証は通っている。それでも本文のURLから個人情報は入力しない")試験用メール3通での実行結果と、DMARCでは防げない似たドメイン
架空のメールを3通作り、Python 3.14.7（Windows）で実行しました。1通目は似た名前の別ドメイン、2通目はraiden3.ktaiwork.jpを詐称して認証に失敗したもの、3通目は認証に成功したものです。いずれも実在の配信内容ではありません。
差出人ドメイン: raiden-support.example （案内に無いドメイン）
認証結果: {'spf': 'pass', 'dkim': 'pass', 'dmarc': 'pass'}
判定: 案内のドメインではない。リンクを開かず、自治体の公式サイトで確かめる
差出人ドメイン: raiden3.ktaiwork.jp （案内のドメイン）
認証結果: {'spf': 'fail', 'dkim': 'none', 'dmarc': 'fail'}
判定: ドメイン名は案内どおりだが DMARC が pass ではない。なりすましの可能性がある
差出人ドメイン: raiden3.ktaiwork.jp （案内のドメイン）
認証結果: {'spf': 'pass', 'dkim': 'none', 'dmarc': 'pass'}
判定: 送信元の認証は通っている。それでも本文のURLから個人情報は入力しない1通目の結果が要点です。攻撃者が自分で取った似た名前のドメインなら、SPFもDMARCも正しく設定でき、認証は「pass」になります。DMARCが守るのは配信元のドメイン名そのものだけで、システム名を含む別ドメインは防げません。最初に見るべきは認証結果ではなく、差出人のドメインが自治体の案内と一致するかどうかです。3通目のように認証が通っていても、配信システムそのものが不正に使われた場合は見分けられないため、本文のリンクから個人情報を入力しない原則は変わりません。
委託元の判断：配信SaaSに預けた登録者データと配信履歴本文の見直し範囲
配信履歴の本文が漏洩対象になった意味と本文に個人情報を書かない運用
今回の発表で見落とせないのは、連絡先だけでなく「履歴として保存されている本文に記載されている内容」が対象に入ったことです。防災メールなら公開済みの気象情報が中心ですが、同じ仕組みを安否確認や業務連絡に使う企業や学校では、本文に氏名、所属、避難先、病状などを書いてきたかもしれません。香川県は、県や市町の職員が参集や安否確認に使う「職員安否確認システム」の職員名、メールアドレス、職員番号、所属も漏洩した可能性があるとしています。
判断は言い切れます。一斉配信の本文には、個人を特定できる情報を書かない運用に切り替えるべきです。個別の事情は本文ではなく、ログインが必要な画面や電話で伝えます。配信サービスに履歴の保存期間を短くする設定があれば使い、無ければ契約更新時の要件に入れる方針です。自治体や学校がメール配信システムに求める要件は業種別のメール配信システムの選び方、安否確認の仕組みと選び方は安否確認システムの仕組みと費用相場で解説しています。
委託先の事故でも残る報告・通知の責任と配信事業者の点検を外部に頼む場面
アルカディアは個人情報保護委員会へ報告したと公表しています。委託元の自治体や企業も、預けた個人データが漏洩した可能性があれば、自らの立場で本人への通知や報告の要否を判断しなければなりません。個人情報保護委員会の案内では、不正の目的によるおそれがある漏洩は件数にかかわらず報告の対象です。判断の手順は個人情報保護委員会への報告義務の実務で解説しています。委託先を経由した被害の全体像はサプライチェーン攻撃の起点別3類型にまとめています。
見直しを急ぐべきなのは、住民や社員の連絡先を外部の配信サービスに預け、そのサービスの管理画面に共有アカウントでログインしている組織です。点検は、管理者パスワードの変更と多要素認証の有無、送信ドメインのDMARCの値、履歴の保存期間の3点から始めます。サービスそのものの作りに脆弱性が残っていないかは、利用者側からは確かめにくい部分です。自社で開発・運用する配信システムや会員サイトを外部の目で点検するなら、脆弱性診断・セキュリティ診断で相談できます。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準にあります。
よくある質問
SpeeCAN RAIDENの不正アクセスについて、登録者と委託元の担当者から出やすい質問をまとめました。
防災メールに登録していると個人情報が漏れたのですか？
アルカディアの発表は「漏洩した可能性」で、外部に取られたと確定したわけではありません。対象はraiden.ktaiwork.jpなど6つの環境で、項目は連絡先の名前、メールアドレス、電話・FAX番号、配信履歴の本文などです。自分の自治体の防災メールが対象環境で配信されていたかは、差出人ドメインを目安に確かめ、最終的には自治体の発表で確認してください。
050-5830-0750はアルカディアの正式な窓口ですか？
アルカディアの公式ブログで、本件の個人情報相談窓口として載っている番号です。受付は午前9時〜午後5時で、土日祝と年末年始を除きます。10月15日時点では電話がつながりにくく、公式ブログはメールでの問い合わせも案内しています。番号は届いたメッセージではなく、公式ブログから確かめてかけてください。
防災メールの登録は解除したほうがよいですか？
10月15日時点で、アルカディアと自治体の発表に登録の解除を求める記載はありません。解除しても、すでに取られた可能性のある情報が戻るわけではありません。防災情報を受け取る手段を減らすことにもなるため、自治体の続報を待って判断するのが無難です。不安な場合は自治体の窓口に、解除した場合の情報の扱いを確かめてください。
NET119の映像通報は影響を受けていますか？
10月14日17時12分の更新で、映像通報は現時点で漏洩の可能性は無いとされています。NET119と119RAIDENでは、net119.speecan.jp、net119fd.speecan.jp、fs119.ktaiwork.jpが対象です。fs119.speecan.jpと119r.speecan.jpは調査の結果、対象外と訂正されました。通報の可否は利用している消防本部の案内で確かめてください。
防災メールを装った不審なメールが届いたらどうすればよいですか？
本文のURLや添付ファイルを開かず、返信もしないでください。差出人の「@」より後ろが自治体の案内にある配信元ドメインと同じかを確かめ、違えば偽物と考えます。同じでも、再登録や本人確認を名目に氏名やパスワードの入力を求める内容なら、自治体の公式サイトに載った番号へ自分で問い合わせてください。
関連記事
- 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：企業として点検する範囲の全体像
- 日経の不正アクセスとなりすましメール約9,000件｜M365・Google Workspace乗っ取りの調査手順：漏洩後に届くなりすましメールを調べる手順
- DMARCのquarantineとrejectの違い｜日経225企業の設定率69.8%とドメイン保護率18.5%：送信ドメインを守る設定の選び方
- 業種別のメール配信システムの選び方｜不動産・製造業・学校・自治体の要件と設定例：自治体や学校が配信システムに求める要件
- タイムズカー情報漏洩・流出：対象の確認と補償、0120-25-8924は本物か、免許証画像への備え：漏洩後に届く連絡の真偽を確かめる手順
