防災情報配信「SpeeCAN RAIDEN」を運営するアルカディアへの不正アクセスで、最大約313万6千件のメールアドレスほかに漏えいの可能性。同社は3拠点DC・冗長化・24時間365日監視・ISMS認証まで備えていた。対策があっても全国規模の影響が広がった理由を、侵入口・検知・被害拡大の三層で読み解き、侵入経路が未特定でも防御側が検証できる設計課題（自治体間のデータ・権限分離）を示す。
監視も冗長化もISMSもあった会社で、なぜ全国規模の漏えい懸念とサービス停止が起きたのか
2026年10月11日の夕方、大阪府箕面市の株式会社アルカディアが運営する一斉情報配信サービス「SpeeCAN RAIDEN」で、不正アクセスが疑われる不審な挙動が確認された。
二日後の13日、同社は最大で約313万6千件のメールアドレスが漏えいした可能性を公表する。翌14日には、消防職員や消防団員が使う119RAIDEN、音声での119番通報が難しい人などが使うNET119にも、調査範囲が広がった。
SpeeCAN RAIDENは全国700以上の自治体で導入されているとされる。国内の自治体の相当数が、一社の提供する共通基盤に相乗りしている計算になる。
ただ、この事案を「件数の大きさ」で語ると、肝心のところを外す。
この会社は、ISMS認証を持ち、国内3拠点のデータセンターを使い、サーバーの冗長化、別拠点への世代別バックアップ、24時間365日の監視まで、自社サイトで明記している。個人情報を格納するデータベースは「ネットワーク的に第三者が容易にアクセスできない場所に設置」しているとも書いている。脆弱性が見つかれば社内評価のうえで適用する体制がある、とも。
つまり、何も備えていなかった会社の話ではない。備えを公言していた会社で、それでも全国に影響が広がった。サーバーを分けても、監視していても、認証を取っていても、防げなかった——その理由のほうを見たい。
公開情報と、外から確認できるシステムの構成をもとに考える。
同社の公式発表を時系列で並べる。
最初に示されたSpeeCAN RAIDENの漏えい可能性は、メールアドレス約313万6千件、電話番号約10万5千件、FAX番号約1万5千件。ここに連絡先の名前、担当者・契約情報、そして「履歴として保存された配信本文」が加わる。
配信本文は見逃せない。災害・避難情報だけでなく、使い方によっては職員の参集連絡、消防団への指令、関係機関への業務連絡なども保存対象になる。漏えいの可能性があるのは、住民のメールアドレスだけではない。
消防向けの119RAIDENはメール約9万7千件、電話約1万7千件など。NET119は約1万3千件で、こちらは氏名・生年月日・性別・住所まで含む。NET119への登録という事実そのものから、本人が音声での通報に困難を抱えている事情がうかがえる場合もある。件数の小ささと情報の重さが逆転している箱だ。
もう一つ、時系列で引っかかる点がある。
さいたま市の公表によると、10月13日12時50分、市民から不審メールの問い合わせが入った。送信元アドレスに、システム名の文字列が含まれていたという。市はその2分後、12時52分にアルカディアへ確認し、不正アクセスを把握した。
一方、アルカディアが不審な挙動を確認したのは11日16時30分である。事業者の検知から、この市の覚知まで、およそ44時間が空いている。
この間にどのような連絡が行われていたかは、公表資料だけでは分からない。実際、愛知県豊川市は13日10時48分に事業者から連絡を受けたと説明しており、連絡が始まっていた自治体もある。それでも、防災情報を預かる自治体が、住民からの不審メールの問い合わせを契機に事態を知った、という事実は重い。
同社はサポート体制として「24時間365日リモート監視」を掲げている。監視は、異常を検知して終わりではない。検知した情報が、サービスを使う自治体へ、どれだけ早く、どんな内容で伝わるか。今回の事案は、検知から利用者への連絡までを含めた運用のあり方を問うている。
アルカディアは1993年設立、箕面市の会社だ。日本語の音声合成技術を強みとし、代表の天白成一氏は音声合成の研究者出身である。自社エンジン「SpeeCAN」を土台に、メール・電話・FAX・防災行政無線・SNSへ一斉配信するサービスを展開し、J-ALERTや気象情報とも連携する。2023年にはSpeeCAN RAIDENがASPICクラウドアワードの総務大臣賞を受けた。音声合成という独自技術を、防災・消防という公共性の高い分野へ展開してきた会社であり、技術そのものには受賞歴がある。
導入もしやすい。公式サイトではSpeeCAN RAIDENの基本料金を初期費用20万円・月額2万円(いずれも税別)と案内している(登録数・通信費・オプションで追加あり)。第三者の比較サイトでは、より低い初期費用での紹介も見られる。いずれにせよ、各自治体が自前でサーバーを建てて監視し保守するより、共通サービスを使うほうが合理的な場面は多い。利用者が増えれば、事業者も運用や設備への投資を集約できる。共同利用には明確な利点がある。
独自の音声合成技術を持ち、自治体が個別にシステムを構築するより安く提供する。それが全国700以上の自治体への普及につながったのだろう。低価格は弱点ではなく、この事業の競争力だった。そして、利用する自治体が増えるほど、共通基盤の重要性も高まっていった。
一方で、多くの自治体が同じ事業者に依存することにもなる。その共通基盤に問題が起きれば、影響は広い範囲に及ぶ。今回、その現実が表れた。
ここが、この事案の中心だ。
同社のサポート体制の説明は、一般的な中小のクラウド事業者としてはむしろ丁寧な部類に入る。全国3拠点のデータセンター。別拠点への世代別バックアップ。サーバーの冗長化と待機系への自動切替。24時間365日のリモート監視と、異常時の自動通知。個人情報のデータベースは「第三者が容易にアクセスできない場所に設置」。なりすましメール対策として、顧客の設定支援やチェックまで実施するとある。少なくとも公に示された設計と運用方針には、可用性とセキュリティの基本が並んでいる。
それでも、情報漏えいの可能性は全国に広がった。
ここで区別したいのは、サーバーを分散することと、セキュリティ上の影響を分離することは別だ、という点だ。
複数のデータセンターにサーバーを置いていても、認証基盤や管理権限、アプリケーション、データへのアクセス経路を共有していれば、その共通部分が破られたとき影響は全体に及ぶ。冗長化はサーバーの「故障」には効くが、共通のアプリケーションに潜む「欠陥」を自動では直さない。バックアップはデータの「消失」には効くが、データの「持ち出し」は止めない。DBを奥に置いても、そのDBに正規にアクセスする経路のどこかが乗っ取られれば、奥に置いた意味は薄れる。
3拠点で運用していたことは、むしろ今回を考えるうえで重要だ。何を分散し、何を共有していたのか。入口となった配信サービスと、アプリの違うNET119まで対象に入ったこと。そこに、技術的な論点がある。
今回、公開DNS、外から閲覧できるログイン画面、画面が読み込むJavaScript、証明書、送信ドメインの認証設定を確認した。侵入経路を探すためではなく、長く運用されてきたシステムの構成を外形から知るためだ。被害対応が続いているため、具体的なホスト名は出さず、用途だけを記す。
確認できた範囲で、三つの特徴があった。
第一に、配信サービスの管理画面は、2010年前後に広く使われた世代のJavaScript(画面構築ライブラリ)で作られていた。15年以上前のフレームワークが、現在も現役で動いている。しかも複数の配信サービスが、まったく同じ古い作りを共有していた。今回「漏えいの可能性あり」に加わった消防向けの119RAIDENも、配信サービスとほぼ同一の画面構成だと分かる。独立したシステムに見えて、画面側では同じ古い実装を共有していた、ということだ。ただし、ログイン画面が似ているからといって、サーバー側の認証処理やデータベースまで同一とは限らない。バックエンドが共通なのか別々なのかは、外からは判断できない。
この世代の技術も、導入された当時は新しい選択肢だったはずだ。問題は古い技術を選んだことではない。その上に独自の機能や複数のサービスを積み重ねていれば、後からフレームワークだけを交換するのは難しくなる。実際にどこまで依存しているかは外から分からないが、複数サービスで同じ古い実装が残っていることは、その可能性を考える材料になる。
第二に、自治体向けの「配信履歴サイト」——住民が過去の放送内容を見るページ群は、数百サイトが同じ一つか二つの公開基盤に収容され、その多くが数年前の世代のWordPressで動いていた。一方、会社のコーポレートサイトは最新のWordPressだった。会社の顔は新しく、現場で動く配信履歴の箱は時が止まっている。問題はバージョン番号そのものより、古い世代を使い続けるなら、どうやって修正を当て、どのプラグインを管理し、公開側と内部をどう分離しているか、だ。
第三に、メール送信に関わるドメインで、なりすまし対策(DMARC)の設定に差があった。本稿執筆時点(2026年10月15日)の観測では、speecan.jp は p=none、ktaiwork.jp は p=quarantine だった。p=none は、そのドメインを騙るメールを拒否するよう受信側に求めていない設定で、p=quarantine(隔離)より弱い。配信サービスや消防向けサービスの一部は speecan.jp 配下で提供されている。
ここで切り分けておく。p=none は「そのドメインのなりすましを止める設定になっていない」という事実であって、そのドメインが今回の不審メールに実際に使われたかは別問題だ。さいたま市などで確認された不審メールがこの差を突いたものかは、実際のメールヘッダーと認証結果がなければ分からない。それでも、漏えいが疑われるアドレスに対してサービスや自治体を装うメールが来る危険を思えば、送信ドメインの管理は重要な対策になる。そして同社自身が、なりすまし対策を「設定支援やチェックまで実施する」と掲げていた点は、記録しておきたい。
これらは今回の侵入原因を示す証拠ではない。入口がどこだったかは公開情報では特定できない。だが、長年運用され、複数の公共サービスに使われてきたシステムの保守状況を点検する材料にはなる。
ここで、いちばん誤解されやすい点に踏み込んでおきたい。「古いソフトに穴があって、そこから入られた。最新版にしていれば防げた」——今回を、この一文でまとめてよいのか。結論から言えば、それほど単純ではない。
侵入の手口は公開情報では明かされていない。「古い」と一口に言っても、そこには性質の違う三つの可能性がある。
一つ目は、古いフレームワークや外部ライブラリの、公に知られた脆弱性を突かれたケース。これなら、最新版への更新やパッチ適用で塞げた可能性が高い。
二つ目は、自社で作り込んだアプリケーション自身の欠陥——認証の回り込み、SQLインジェクション、権限チェックの漏れなど——を突かれたケース。これは外部ベンダーのパッチが存在しない。自分たちのコードの問題だから、「最新版にする」という対処がそもそも当てはまらない。
三つ目は、ソフトの穴ではなく、管理画面のログインそのものを、盗まれた、あるいは弱い認証情報で通られたケース。この場合、フレームワークが最新だろうと関係ない。正規の鍵で、正規の扉を開けられている。同社が最初の手当てに「攻撃元IPの拒否」を選んだ点は、ログインを経由する侵入と矛盾しない。ただし、脆弱性を突く攻撃でも攻撃元IPは分かるので、これだけで手口を断定することはできない。
つまり、「最新版にしていれば防げたか」の答えは、それがどの入口だったかに丸ごと依存する。一つ目なら「防げたかもしれない」。二つ目と三つ目なら、外部ライブラリを最新版にするだけでは防げない。
そして、ここが肝心だ。どの入口であっても、今回を「全国規模」にした要因は、入口の新旧とは別のところにある。配信サービスだけでなく、作りの異なるNET119にも不正アクセスの形跡が確認された。個別の入口がそれぞれ侵害されたのか、それとも共通する認証や管理機能を通じて影響が広がったのか——この違いは重要だ。後者なら、一つの侵入が複数サービスへ波及し得る設計だったことになる。そして後者だった場合、仮に入口のフレームワークを最新にしても、その先の共有構造がそのままなら、次に別の入口を抜かれたとき、同じ規模の被害が出る。最新版は入られる確率を下げるが、入られた後の被害範囲は変えない。
監視についても、同じ切り分けが要る。
同社は11日16時30分に「不審な挙動」を検知している。だから、何らかの監視は現に動いていて、何かを捉えた。これは事実だ。
問われるのは、その監視が「今回の種類」を捉える設計だったか、だ。同社のサポート説明で前面に出ているのは、メールを確実・迅速に届けるための監視——配信の遅延やキャリアブロック、サーバーの死活といった、運用上の異常を見る監視である。これは可用性には効く。だが、攻撃者が正規の認証情報で入り、正規の「一覧表示」や「エクスポート」機能を使ってデータを読み出すと、通信そのものは正常な利用と見分けがつきにくい。死活監視や配信監視では鳴りにくい。ここを捉えるには、アクセス量やクエリの異常、外向きの持ち出しを見る、セキュリティ寄りの監視が要る。
同社は12日未明に応急措置を講じ、その翌日には侵入経路となったサービスを停止している。応急措置が不十分だったのか、調査によって新たな経路や影響が判明したのかは分からない。少なくとも、検知した時点で被害の全体像が明らかになっていたわけではない。実際、さいたま市では、事業者からの異常通知ではなく、住民の不審メール報告をきっかけに事態を把握している。監視が異常を捉えたこと(事実)と、その監視が攻撃の全体像を素早く描いて利用者へ届けられたか(今回の課題)は、分けて考える必要がある。
ここで、古いソフトが残っていることと、運用が止まっていることを、混同してはいけない。
公式ブログをさかのぼると、直近にも対応の記録がある。9月22日にはデータベースサーバーの障害で一部サービスが約33分止まり、復旧している。9月28日にはサーバー設備の増強に伴う計画停止を案内している。サポートページには、脆弱性が見つかれば社内評価のうえ適用する体制がある、と明記されている。
つまり、今回を「更新を忘れていた会社」の話として片づけることはできない。むしろ同社は、保守や監視の仕組みを整えていると説明してきた。
会社として技術が止まっていたわけではない。一方で、設備増強や障害対応が続けられる中でも、古い世代の画面部品は残っていた。インフラの更新と、アプリケーションの更新は、必ずしも同じ速度では進まない。障害として鳴る部分——サーバーの死活、バックアップ、設備の増強、OSのパッチ——には、現に手が入っている。だが、動いているアプリケーションを現代的に作り直すことは、障害として鳴らない限り後回しになりやすい。
700以上の自治体が日々使っている土台を、止めずに載せ替えるのは、重く、危険で、相応の投資が要る。導入先が少ないうちは変更できたものも、全国に普及し、自治体ごとの設定や他システムとの連携が増えれば、簡単には変えられなくなる。
低価格で普及したことは成功だった。しかし、その成功によって、システムを大きく変更する際の影響も大きくなった。古い技術を放置したというより、動いている中核ほど触りにくくなった可能性がある。
だとすれば、問いはこう変わる。その管理対象に、アプリケーションの古い部品や、複数サービスに共通する実装、認証やアクセス権限の設計まで、含まれていたのか。
OSにパッチを当てていても、アプリのアクセス制御に穴があれば侵害は起きる。監視装置が動いていても、正規の機能を使った不正なデータ取得は、異常として鳴りにくい。サーバーを冗長化しても、同じ認証や管理権限を共有していれば、影響は横へ広がる。「脆弱性が見つかれば適用する」体制があっても、2010年前後のフレームワークが管理の網に入っていなければ、適用の対象にすらならない。個々の対策があることと、システム全体のリスクが抑えられていることは、同じではない。公言された体制が、どのソフトウェアまでを本当に見ていたのか——ここが、この事案の検証すべき核心だと考える。
10月12日未明に侵入経路を塞ぐ応急措置が行われ、翌13日に「外部からの侵入経路が判明した」として二つのサービスが緊急停止された。最初の措置と翌日の停止がどういう関係にあるかは、詳細が公表されていない。一度措置した経路について、調査が進んでから影響を受けるサービスを止めた、とも読める。緊急対応と範囲調査が並行していたことは分かる。
14日には消防向けへ対象が広がり、同じ日のうちに対象URLや映像通報の説明が訂正された。調査中に範囲が動くこと自体は珍しくない。だが受け取る自治体は、どの機能を使ってよいかという判断を、更新のたびに読み替えねばならなかった。
実際、自治体の対応は割れた。横浜市の複数区は13日11時から緊急時情報伝達システムの停止を告知した。墨田区は、不正プログラムの混入は確認されていないとしつつ、安全が確認できるまでメール配信を止めるとした。一方、出雲市はNET119の漏えい可能性を注意喚起しながら、運用には影響がないと説明した。同じ事業者のサービスでも、継続と停止の判断は分かれた。利用する機能が違えば判断が割れるのは当然で、それ自体を責めることはできない。問題は、自治体が安全性を判断する材料を、どれだけ受け取れていたか、だ。
そして、情報が漏れたかどうかとは別の影響も出た。東京都港区では、個人情報を預けていないにもかかわらず、緊急速報メール(エリアメール)の配信システムが使えなくなった。山形県鶴岡市では一括配信が止まり、当面は各キャリアのサイトへ手入力で配信するという。情報を守るために止めると、必要な情報が届かなくなる。この二つを同時に成り立たせる備えがあったかどうかが問われる。
アルカディアは、プライバシーマークもISMSも取得している。認証の登録範囲は、まさに今回影響が出た防災・減災ソリューションの提供だ。10月15日には、個人情報保護委員会への報告に加え、ISMS事務局やプライバシーマーク事務局へも相談・通報したことを公表した。認証を持ち、調査票にも答え、監視や保守の仕組みを整えていた。それでも、不正アクセスは起きた。
これは、ISMSが無意味だという話ではない。ISMSは、組織が情報セキュリティのリスクを管理し、継続的に改善する「仕組み」を評価するものだ。個々のソフトに脆弱性が存在しないことまで保証する認証ではない。古いソフトを使うこと自体も、そのリスクを正しく評価し、管理策を選び、実施し、見直している限り、直ちに不適合になるわけではない。
だから、委託先を評価する自治体の側も、「認証を持っているか」の確認だけでは足りない。たとえば、次のような点まで把握できていただろうか。
認証の有無に加えて、技術的な管理の実態と運用の継続性を評価する必要がある。ISMS認証を持つ事業者で事故が起きたという今回の事実は、その距離を改めて示している。
同社が打った手は、侵入経路となったサービスの停止、攻撃元IPの拒否設定、他サービスの点検、そして自治体を通じた不審メールへの注意喚起だ。いずれもインシデント対応として必要な措置ではある。
だが、攻撃元IPを拒否したことと、侵入の原因を取り除いたことは、同じではない。別のIPから来れば効果は薄い。「不正なプログラムが見つからなかった」ことも、アクセス制御や認証処理に問題がないことまで保証するものではない。点検した範囲で不正なプログラムが確認されなかった、という意味にとどまる。
今後重要になるのは、侵入経路の技術的な原因と、影響が広がった仕組みを明らかにすることだろう。外形調査で古い画面部品や複数サービスに共通する構造が見えた以上、少なくともそれらについて、継続利用の妥当性とセキュリティ管理の状況を再評価する価値はある。すべてを書き直すことだけが答えではない。既存を維持しながら、脆弱性の修正、認証と権限の見直し、サービス間の分離、監視の改善を進める道もある。大切なのは、今回見つかった入口を塞ぐだけでなく、同じ種類の問題が別の入口に残っていないかを確かめることだ。
そして、ここが技術者にとっていちばん具体的な点検材料になる。侵入経路がまだ確定していない段階でも、防御側が検証できることがある。 それが、自治体ごとのデータと権限の分離だ。仮に一つのアプリケーションが侵害されたとしても、アプリケーション・データベース・管理権限まで分離されていれば、他のテナントへの被害拡大を抑えられる。逆に、一つの入口を抜けた先で全テナントのデータが見通せる作りなら、入口一つの突破が全国規模の漏えいに直結する。これは、古いJavaScriptや古いWordPressの話とは独立した、複数の顧客が一つの基盤を共有するマルチテナントサービスに固有の設計課題だ。入口の古さは直せても、テナント間が地続きなら、次の入口でまた同じ規模の被害が出る。
だから、700以上の自治体が同じサービスを使っていること自体が問題なのではない。問われるのは、その共有基盤の内側で、自治体ごとの権限とデータがどこまで分離されていたか、だ。侵入経路の特定を待たずとも、事業者はこの一点を今すぐ自己点検でき、自治体は委託先に対してこの一点を具体的に確認できる。
全国700以上の自治体が使うサービスを、一つの事業者が提供している。技術の普及という意味では成功だ。各自治体が独自に配信システムを作って維持するより、共通サービスを使うほうが合理的な場面は多い。
当時の技術で優れたサービスを作り、低価格で普及させた。その成功が、長い年月の中でシステムを変更しにくくする要因にもなり得る。今回の事案には、そうした長期運用システムに共通する問題も見えてくる。
しかし、多くの自治体に使われるようになった時点で、そのサービスの社会的な重みは変わる。一つの不具合、一つの侵害、一つの運用判断が、全国の住民と職員に及ぶ。その重みに応じて、求められる安全性、分離、運用管理、緊急時の連絡体制も、変えていかねばならない。
今回、アルカディアは3拠点のデータセンターを使い、冗長化も監視も行い、ISMSも取得していた。それでも、大規模な漏えいの可能性が生じ、自治体の防災配信が一部止まった。サーバーの故障に備えることと、不正アクセスの影響を限定することは違う。ISMSを取ることと、日々のソフトの安全を保つことも違う。情報を守るために止めることと、災害時に届け続けることも違う。
共同利用そのものが問題なのではない。共通化で生まれたリスクを、誰が引き受け、どこまで対策し、その費用を誰が負担するのか。月額2万円から使える便利な防災サービスを、全国規模の重要基盤として安全に保つには、どんな運用と投資が要るのか。事業者だけでは解けない問題でもある。発注する自治体の側も、調達価格や認証の有無だけでなく、継続的な脆弱性対応、データの分離、緊急時の代替手段まで確かめる必要がある。
見直すべきなのは、一社のサーバーだけではない。全国の自治体が、防災情報を届ける仕組みをどう共同利用し、どう守り続けるか——その運用と調達のあり方そのものだ。
本稿は2026年10月15日午前までの公開情報(アルカディアおよびSpeeCAN RAIDEN公式の公表、同社の会社概要・製品/サポート説明、各自治体の告知、報道)と、同日時点で公開情報を用いて行った外形調査に基づく。外形調査で観測したソフトウェア構成やDMARC設定と、今回の侵入原因との関係は確認されていない。被害対応が継続しているため、具体的なホスト名は記載せず用途のみを記した(ドメイン単位の設定は再現可能な公開情報のため記載した)。「700以上の自治体」は導入規模であり、その全てで漏えいが発生したことが確定した数字ではない。漏えい件数は事業者が公表した最大推定件数であり、実際に漏えいした件数を示すものではない。新たな事実が判明すれば、記述は更新され得る。
Aikido Community Japan
公開日: 2026/10/15
最終更新: 2026/10/15
セキュリティの最新情報をお届けします。