マネックス証券の不正アクセス：口座開設の委託先システムで新規受付停止、公表範囲と受付だけ止める設計

マネックス証券は2026年10月20日、口座開設システムのうち外部委託先が管理するシステムに第三者がアクセスを試みた形跡を確認し、ウェブサイトとアプリからの「証券総合取引口座」の新規開設受付を一時停止したと発表しました。本記事では報道各社が伝えた発表内容を突き合わせ、確定している事実と、まだ公表されていない点を分けて整理します。既存の顧客と申込中の人が今確かめることを先にまとめたうえで、後半で扱うのは本人確認書類が集まる口座開設システムの守り方です。受付の経路だけを切り離すnginxの設定と、アクセス試行をログから数えるPythonのコードも示します。

まとめ：マネックス証券の不正アクセスで公表された範囲と顧客・開発者が今やること

確定しているのは3点だけです。口座開設システムのうち外部委託先が管理するシステムに、第三者がアクセスを試みた形跡があったこと。予防的な措置として、そのシステムが関わる部分に限り新規開設の受付を止めたこと。専門チームが調査中で、再開時期は未定であること。侵入が成功したのか、顧客の情報が漏れたのか、委託先がどこかは、10月21日時点で公表されていません。

既存の顧客がやるのは、届いたメールやSMSのリンクを使わず、自分で開いた公式サイトかアプリからログインしてお知らせ画面を確かめることです。開発者が見るべき論点は、口座開設の仕組みには本人確認書類の画像が集まり、その多くを委託先が運用している点と、異常を見つけたときに受付だけを止められる作りになっているかの2つです。

報道各社の記述を突き合わせる｜10月20日の発表で確定した範囲と未公表の点

外部委託先が管理する口座開設システムへのアクセス試行と予防的な受付停止

Impress Watch、ケータイ Watch、INTERNET Watch、ロイター（ニューズウィーク日本版に転載）の各記事は、いずれも同じ内容を伝えています。マネックス証券は口座開設システムのうち外部委託先が管理するシステムに対し、第三者がアクセスを試みた形跡を確認しました。そのうえで予防的な措置として、当該システムが関わる部分に限り、ウェブサイトとスマートフォンアプリからの証券総合取引口座の新規開設受付を一時停止しています。

発表の言葉は「アクセスを試みた形跡」です。一部の見出しは「不正アクセス」と書いていますが、発表本文が示しているのは試行の痕跡までで、侵入の成立を認めた表現ではありません。調査は専門チームが進めていて、安全性が確認され次第、受付を再開し、見通しは同社のウェブサイトで案内するとしています。

委託先名・侵入の成否・情報漏えいの有無は10月21日時点で未公表

委託先の社名は、どの記事にも出てきません。rocket-boysのセキュリティ対策Labは、発表では委託先企業名などの技術的な詳細が示されていないと書いています。顧客情報の漏えいや顧客データベースへの不正アクセスも公表されていません。

未公表であることは「漏れていない」と同じ意味ではない点に注意が必要です。調査の途中で範囲が広がる例は珍しくなく、10月の証券会社の事案でも、続報で対象者が追加されています。本記事では、続報が出るまで漏えいの有無を前提にした記述をしません。

岩井コスモ証券・大和証券の委託先事案との違いと同一委託先かの未確認点

同じ10月には証券会社の委託先をめぐる公表が続きました。岩井コスモ証券の不正アクセスは、取引システムの運用・保守を受託するトレードワークスのシステムに侵入があり、4,975名の情報漏洩と7口座の不正注文に至った事案です。大和証券の情報漏洩は、問い合わせ管理に使う委託先のシステムからの漏洩でした。

マネックス証券の件は、既存顧客の情報や注文ではなく、新しい顧客を迎える入口で異常が見つかった点が違います。委託先がトレードワークスと同じかどうかを示す報道は、10月21日時点で見当たりません。同じ委託先だと決めつけて読むのは避け、続報で社名が出た時点で照合するのが妥当です。

マネックス証券の顧客と口座開設の申込中の人が確かめる点検と偽連絡への備え

既存口座の取引は停止対象として挙がっていない範囲とお知らせ画面での確認

発表で停止の対象として挙がっているのは、ウェブとアプリからの証券総合取引口座の新規開設受付です。既存口座の取引や入出金を止めるという記載は、各社の報道にもありません。ただしrocket-boysも指摘するとおり、告知の対象外のサービスが平常どおり動くことまで保証した文面ではないため、自分の口座の状況はログイン後のお知らせ画面で確かめます。

ログインはブックマークか公式アプリから行い、メールやSMSに書かれたリンクは開きません。金融庁の注意喚起ページは令和8年10月9日にも更新されていて、証券会社を装う偽サイトで盗んだIDとパスワードによる不正取引への警戒が続いています。

申込中の人が再開案内を待つ間にマネックス証券を装うメールとSMSを見分ける

申込の途中だった人は、受付の再開を自分から追いかける必要はありません。再開の見通しは同社のウェブサイトで案内されると発表されています。気をつけたいのは「口座開設の手続きを再開してください」「本人確認書類を再提出してください」と誘う連絡です。

口座開設が止まったことは広く報道されているため、それを口実にした偽メールは作りやすい状況です。本人確認書類の画像やマイナンバーカードの情報をメールのリンク先で求められたら、送らずに公式サイトのお知らせと照らし合わせてください。偽メールの典型的な作りと、受け取る側の見分け方はフィッシング詐欺とはで解説しています。

口座開設システムが狙われる理由｜本人確認書類の画像と特定個人情報が集まる場所

日証協ガイドラインⅣ.1(1)が定める本人確認の方式と委託先に残るデータの種類

日本証券業協会のインターネット取引における不正アクセス等防止に向けたガイドライン（2025年10月15日改正）は、Ⅳ.1(1)で口座開設時の本人確認の方法を挙げています。オンラインで完結する方式は、写真付き本人確認書類の画像と容貌の画像、ICチップ情報と容貌の画像、マイナンバーカードの署名用電子証明書などです。

つまり口座開設システムには、顔写真付きの身分証の画像と、本人の顔の画像が組で集まります。証券口座ではマイナンバーの提供も求められるため、同じガイドラインの2.(2)④は特定個人情報の厳重な管理を別立てで求めています。漏れた場合に取り替えが利かない情報が、ログイン前の誰でも触れられる入口の奥にある構造です。eKYCの方式ごとの違いはeKYCとはで整理しています。

本人確認書類は確認後に削除する2.(2)③と犯収法6条の確認記録7年保存の両立

ガイドラインの2.(2)③は、口座開設時の本人確認書類を確認した後、本人へ返すか、廃棄して記録媒体から完全に削除する事務を適時・確実に行う態勢を求めています。ただし、書類やその写しを犯収法の本人確認記録にしている場合は除くとされています。

一方で犯罪による収益の移転防止に関する法律の第6条2項は、確認記録を契約が終了した日などから7年間保存するよう定めています。両立させる設計は、記録として残す分は委託元の保管庫へ移し、審査のために委託先へ一時的に置いた画像は引き渡しが済んだら消す、という分け方です。次のSQLは、委託先のデータベースから引き渡し済みの画像を消す例です。

-- 委託元へ引き渡し済みの本人確認画像を委託先側から消す（PostgreSQL）
DELETE FROM kyc_images
 WHERE handed_over_at IS NOT NULL
   AND handed_over_at < now() - interval '1 day'
RETURNING application_id, image_kind, handed_over_at;

RETURNINGで消した行を出力し、その件数を委託元へ毎日報告してもらえば、消し忘れに気づけます。委託先に何年分の画像が残っているかを委託元が把握していない状態は、ガイドラインの趣旨に沿わない管理状態です。取引時確認の義務全体は犯罪収益移転防止法とはで解説しています。

受付停止の設計｜nginxで口座開設経路を分離し503とRetry-Afterで応答

停止スイッチを1行のファイルに分けて口座開設の経路だけ503を返すnginx設定

マネックス証券は、既存の取引には触れず、新規開設の受付だけを止めました。異常を見つけた時点でこの切り分けができるかどうかは、事前の作りで決まります。次は、口座開設の経路だけを止めるスイッチと、平常時の試行回数の制限を1つの設定にまとめたnginxの例です。回数の制限にはngx_http_limit_req_moduleを使います。

# 口座開設の経路だけを止められるようにする（nginx）
limit_req_zone $binary_remote_addr zone=onboarding:10m rate=10r/m;

server {
    listen 443 ssl;
    server_name www.example.jp;

    # 中身は「set $onboarding_paused 1;」（停止）か「set $onboarding_paused 0;」（受付）の1行だけ
    include /etc/nginx/flags/onboarding_paused.conf;

    location /account/open/ {
        if ($onboarding_paused = 1) {
            add_header Retry-After 86400 always;
            return 503;
        }
        limit_req zone=onboarding burst=20 nodelay;
        limit_req_status 429;
        proxy_pass https://onboarding.vendor.example;
    }

    location / {
        proxy_pass http://trading_app;
    }
}

停止するときは、フラグのファイルを1に書き換えて nginx -s reload を実行するだけです。口座開設の経路は503を返し、ログインや取引の経路はそのまま動く構成です。RFC 9110は503を一時的に処理できない状態の応答と定め、Retry-Afterで再試行までの目安を伝えられるとしています。申込画面の側では503を受けたら「受付を一時停止しています」と表示し、入力済みの内容を送り直させない作りにします。

停止スイッチを入れる条件と口座開設以外まで止める場面の見送り判断

このスイッチを用意する価値が高いのは、口座開設や会員登録の処理を委託先のシステムが受け持ち、自社の取引や会員サービスと同じドメインで公開しているケースです。委託先で異常が見つかったとき、ドメイン全体を止めるか何もしないかの二択になると、判断が遅れます。止める範囲を経路単位で選べることが、予防的な停止を早く決める前提になります。

反対に、委託先から自社の基幹側へ接続する経路が開いていて、どこまで影響するか分からない段階なら、口座開設だけを止めて様子を見るのは不十分です。その場合は接続そのものを先に遮断します。受付の停止は、委託先と自社の間の通信が限定されていると確認できているときに選ぶ手段と考えてください。管理系の入口を接続元で絞る設定はスカラコミュニケーションズの不正アクセスで扱っています。

アクセス試行の形跡を見つける｜口座開設の経路への探索をPythonで集計する手順

アクセスログから認証失敗と存在しないパスへの探索を接続元ごとに数えるコード

「アクセスを試みた形跡」は、多くの場合ログの中の偏りとして現れます。同じ接続元から認証の失敗が続く、存在しないパスを次々に叩く、といった動きです。次は、nginxのcombined形式のアクセスログを読み、口座開設の経路に対する認証失敗と探索を接続元ごとに数える例です。集計にはPython標準のcollections.Counterを使います。

# 口座開設の経路への認証失敗と探索を接続元ごとに数える（Python 3）
import re
from collections import Counter

LINE = re.compile(r'(?P<ip>\S+) \S+ \S+ \[[^\]]+\] "\S+ (?P<path>\S+) [^"]*" (?P<status>\d{3})')
WATCH = ("/account/open/", "/api/onboarding/")

fail = Counter()   # 401・403 の回数
paths = {}         # 404 になったパスの種類

with open("access.log", encoding="utf-8", errors="replace") as f:
    for line in f:
        m = LINE.match(line)
        if not m or not m["path"].startswith(WATCH):
            continue
        if m["status"] in ("401", "403"):
            fail[m["ip"]] += 1
        elif m["status"] == "404":
            paths.setdefault(m["ip"], set()).add(m["path"])

for ip in set(fail) | set(paths):
    kinds = len(paths.get(ip, ()))
    if fail[ip] >= 20 or kinds >= 10:
        print(ip, "認証失敗", fail[ip], "探索したパス", kinds)

# 出力例：203.0.113.45 認証失敗 3 探索したパス 57

しきい値の20回と10種類は出発点で、平常時のログで1週間ほど回してから調整します。探索したパスが多い接続元は、管理画面や設定ファイルの置き場所を探している可能性が高い動きです。見つかった接続元は、前述のnginx設定で個別に拒否するか、制限を強めます。痕跡の探し方をサーバーやPCの側まで広げる手順は不正アクセスの調べ方で解説しています。

委託先のアクセスログを委託元へ転送して日証協ガイドライン3.(2)③に沿い監視する

上のコードは、ログが手元にあって初めて動きます。口座開設のシステムを委託先が運用している場合、アクセスログが委託先のサーバーにしか無い状態はよくある例です。ガイドラインの3.(2)③は、外部委託先での顧客データへのアクセス制限やその運用状況を、委託元として監視・追跡できる態勢の構築を求めています。

実務では、委託先のロードバランサーとアプリのログを、委託元が管理するログ基盤へ毎日転送してもらう契約にします。転送が止まったら、その日のうちに気づける監視も付けます。委託先の中だけにあるログは、委託先が破られたときに消されたり書き換えられたりするおそれがあるためです。今回のように委託先のシステムで異常が見つかった場面で、委託元が自分のログで範囲を確かめられるかどうかが、判断の速さを分けます。

委託先の口座開設システムを委託元が監督する体制と報告・公表の段取り

外部委託先7項目のうち口座開設に効く②⑤⑦とアクセス権限の棚卸し

ガイドラインの3.(2)は外部委託先について7つの対策を定めています。口座開設の仕組みに直接効くのは、委託先への不正アクセスで顧客情報が漏れない措置の確認（②）、委託先に付与するアクセス権限の使い回し防止（⑤）、二段階以上の委託での再委託先の監督の確認（⑦）です。本人確認の審査を委託先がさらに別の会社へ出している構成は珍しくないため、⑦が抜けると画像の置き場所を誰も把握していない状態になります。

棚卸しは、委託先の管理画面にログインできるアカウントの一覧、接続元、付与した権限、本人確認画像を保持しているシステムと保存期間を、月に1回受け取って前月と比べる形が回しやすい方法です。委託先を起点にした攻撃の類型はサプライチェーン攻撃とはで整理しています。

漏えいが未確認の段階でも報告と公表の準備を委託元が先に進める理由

委託先のシステムで起きた事故でも、顧客の個人データの取り扱いを委託した事業者が、個人情報保護委員会への報告と本人への通知を担います。個人情報保護委員会の案内のとおり、不正の目的をもって行われたおそれのある漏えい等は、件数にかかわらず報告の対象になりうる事象です。報告の期限と類型は個人情報保護委員会への報告義務で解説しています。

マネックス証券は、漏えいを確認する前の段階で受付を止め、そのことを公表しました。ガイドラインの6.(1)も、不正アクセスの疑いが生じた段階で顧客への連絡などを求めています。委託先から結果が届くのを待つ作りでは、この順番は取れません。口座開設や会員登録の入口から委託先の管理画面までを第三者の目で点検したい場合は、脆弱性診断・セキュリティ診断で、委託先が運用する経路を含めて確認できます。

よくある質問

マネックス証券の口座開設システムへのアクセス試行について、顧客と開発者から出やすい質問をまとめました。

マネックス証券の不正アクセスで個人情報は漏れましたか？

10月21日時点で、情報が漏えいしたという公表はありません。発表が確認したと伝えているのは、外部委託先が管理する口座開設システムに第三者がアクセスを試みた形跡です。ただし調査は続いていて、漏えいが無いと確定したわけでもありません。再開の見通しは同社のウェブサイトで案内されるとしているため、続報もログイン後のお知らせ画面と合わせて確かめてください。

既存のマネックス証券の口座で取引や出金はできますか？

発表で停止の対象として挙がっているのは、ウェブとアプリからの証券総合取引口座の新規開設受付です。既存口座の取引や入出金を止めるという記載は、報道各社の記事にもありません。自分の口座の状況は、メールのリンクではなく、公式サイトかアプリからログインして確かめるのが確実です。

マネックス証券の口座開設の受付はいつ再開されますか？

再開時期は決まっていません。発表は、専門チームによる調査と安全性の確認を進め、確認でき次第速やかに受付を再開するとしています。見通しは同社のウェブサイトで順次案内される予定です。再開を知らせると称して本人確認書類の再提出を求める連絡が届いたら、公式サイトのお知らせと照らし合わせてください。

岩井コスモ証券の不正アクセスと同じ委託先ですか？

10月21日時点で、マネックス証券は委託先の社名を公表しておらず、同じ委託先だと示す報道も見当たりません。岩井コスモ証券の件は、委託先トレードワークスのシステムへの侵入で既存顧客の情報漏洩と不正注文が起きた事案で、口座開設の入口で試行の形跡が見つかった今回とは内容も異なります。

自社の口座開設や会員登録の仕組みは何から点検すればよいですか？

最初に、本人確認書類の画像がどのシステムに何日分残っているかを確かめます。委託先や再委託先に残っているなら、引き渡し後に消す運用があるかを見ます。次に、口座開設の経路だけを止める手段があるかと、その経路のアクセスログを委託元で見られるかを確認してください。

関連記事

• 岩井コスモ証券の不正アクセス：4,975名の漏洩と7口座の不正注文、委託先の管理機能を守る設計：同じ日に続報が出た証券会社の委託先事案
• 大和証券の情報漏洩・不正アクセス：約11万人の対象確認と委託先i-askの経緯、口座番号を委託先に残さない設計：委託先に顧客データを残さない設計
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：申込APIのレート制限と認可の実装
• eKYCとは？方式の違いと2027年4月の犯収法改正で変わる本人確認要件：口座開設で使う本人確認の方式
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えいが判明したときの報告の段取り