岩井コスモ証券は2026年10月16日と20日、インターネット取引のシステム運用・保守を委託している株式会社トレードワークスのシステムに不正アクセスがあり、4,975名の氏名・メールアドレスなどが漏洩したと公表しました。10月20日の第2報では、同じ10月14日に売買管理システムへの攻撃もあり、7口座で顧客の意図しない注文が出ていたことも明らかになったとの説明です。本記事では2本の公表文をもとに経過と対象を整理し、顧客が今日確かめることを先にまとめます。後半では、顧客ログインの多要素認証を通らない運用の経路から注文が出る構図を取り上げ、データベースで承認の無い注文を拒否する実装と、ログインに結び付かない注文を洗い出すコードを示します。
まとめ：岩井コスモ証券の不正アクセスで確定した事実と顧客・開発者が今やること
確定しているのは次の4点です。委託先のトレードワークス（以下TW社）のシステムに10月14日に不正アクセスがあったこと。4,975名の氏名・メールアドレスなどが漏洩し、取引暗証番号は含まれないこと。同日に7口座で意図しない売買注文が出て、うち5口座で約定したものの、取引前の状態に戻す措置が済んでいること。不正注文には漏洩した個人情報は使われていないこと。
顧客がまずやるのは、届いた連絡のリンクや電話番号を使わず、ログイン後のお知らせ画面か公表文の窓口で確かめることです。開発者の側で見るべき論点は、顧客のログインを守る多要素認証が効いていても、運用・保守のための管理機能という別の入口から注文まで届いた点にあります。
| 項目 | 公表されている内容 |
|---|---|
| 公表日 | 初報10月16日・第2報10月20日 |
| 侵害を受けた先 | 委託先TW社のシステム |
| 検知日 | 2026年10月14日 |
| 漏洩の対象 | 4,975名（初報4,611名＋364名） |
| 漏洩した項目 | 氏名・メールアドレス他 |
| 不正注文 | 7口座（うち5口座で約定） |
| 侵入の手口 | 未公表 |
公表文を時系列で確認する｜10月14日の検知から10月20日の第2報まで
10月16日の初報で公表された4,611名の漏洩と委託先トレードワークス
岩井コスモ証券の初報（2026年10月16日）によると、同社は10月14日に第三者による不正アクセスを検知し、直ちにTW社へ連絡してアクセス制限などの緊急措置を講じました。TW社は同社のインターネット取引のシステム運用・保守を受託している会社です。
初報の時点で公表された対象は4,611名で、項目は氏名・メールアドレス他。対象者には公表前に個別の報告が済んでいました。脆弱性のある箇所の特定と修正も完了したとしたうえで、TW社に再点検とセキュリティ管理体制の強化を要求したと説明しています。
10月20日の第2報で追加された364名と通信記録の再精査で分かった範囲
第2報（2026年10月20日）では、アクセス記録に加えて通信記録も精査した結果、新たに364名の漏洩が判明し、対象は4,975名になりました。追加分は10月14日の不正アクセスの際に生じていたものを再調査で把握したもので、その後に新しい侵入があったわけではないと明記されています。
アクセス記録だけでは件数を取り切れず、通信記録まで見て初めて範囲が確定した経過です。自社で調べる際にどのログを突き合わせるかは不正アクセスの調べ方とログの確認方法で整理しています。
第2報で初めて明かされた売買管理システムへの攻撃と7口座の不正注文
第2報は、10月14日に売買管理システムへの攻撃も発生し、7口座で顧客の意図しない売買注文が発注され、うち5口座で約定したと公表しました。対象の顧客には当日中に個別に連絡し、取引前の状態に戻す措置を完了していて、顧客の負担は生じていません。
初報で触れなかった理由は、同様の被害を防ぐ対策を段階的に進めている最中で、手口につながる情報の公表を控えていたためと説明されています。TW社が他の金融機関に提供しているシステムも点検され、同様の不正アクセスは確認されていないとのことです。
岩井コスモ証券の顧客が今日確かめる点検と同社を装う連絡の見分け方
対象かどうかの確認方法とログイン後のお知らせ画面・専用窓口の使い分け
対象の顧客には、岩井コスモ証券からログイン後のお知らせ画面とメールで個別に連絡が届いています。メールだけを根拠にせず、ブックマークや公式アプリから自分でログインし、お知らせ画面に同じ内容があるかを確かめるのが確実な方法です。
電話で問い合わせるなら、公表文に記載されたお客様相談室（0120-405-546・平日9時〜17時）を使います。届いたメールやSMSに書かれた番号やリンクは使いません。初報も、同社を装う電話やメールが来るおそれがあると注意を促しています。
取引暗証番号は漏れていない段階でパスワード変更と多要素認証を見直す順番
公表文は、漏洩した情報では証券口座へのログインや取引はできないとしています。それでも、氏名とメールアドレスの組は偽のログイン画面へ誘うメールの宛先として使われるおそれがある情報です。金融庁の注意喚起ページは令和8年10月9日にも更新され、偽サイト経由の不正取引への警戒が続いています。
見直す順番は、ログインに使うメールアカウントの保護、証券口座の多要素認証やパスキーの設定、取引や出金の通知の有効化です。同じパスワードを他のサービスで使い回しているなら、それも変えます。方式ごとの強さの差は多要素認証（MFA）とはで、偽メールの手口はフィッシング詐欺とはで解説しています。
漏洩と不正注文は別経路｜顧客ログインの多要素認証の外側にある管理機能
第2報が「漏洩した個人情報は不正取引に使われていない」と明記した意味
第2報は、今回の不正取引は漏洩した個人情報が利用されたものではないと書いています。つまり、誰かが漏れたメールアドレスで顧客になりすましてログインし、注文したわけではありません。侵入者は顧客のログインとは別の経路から、売買管理システムに届いていたことになります。
ここが大和証券の事案との違いです。大和証券の情報漏洩は問い合わせ履歴という保存データが漏れた事案でした。今回はデータが読まれただけでなく、委託先のシステムから注文という操作まで実行された点で、守る対象が一段深くなります。
追加対策の筆頭に管理機能のアクセス制限が挙がった構図と未公表の範囲
第2報によると、TW社は追加の対策として、管理機能のセキュリティ強化（アクセス制限）、不正な通信を遮断する仕組みの強化とログインの異常を即時に検知する仕組みの追加、監視体制の強化を実施しました。最初に挙がったのが管理機能です。
報道では、TW社が顧客の通常のログイン経路には多要素認証などが入っていた一方、一部の管理機能に設定の不備があったと説明したと伝えられています。ただし、本記事の執筆時点でTW社の開示の原文は確認できておらず、どの管理機能がどう悪用されたかも公表されていません。本記事では、顧客の入口とは別に運用・保守の入口がある、という構図だけを前提に設計を考えます。管理画面のURLを接続元で絞るnginxの設定はスカラコミュニケーションズの不正アクセスで、管理APIの認可はAPI不正アクセス対策の実装手順で扱っているため、ここでは注文の入口に絞ります。
運用経路の注文を止める｜PostgreSQLのロール判定と二者承認で守る売買の入口
運用・保守用アプリのDBロールを分けて承認の無い注文をトリガーで拒否する
管理機能が破られても注文まで届かないようにするには、注文を書き込む最後の地点、つまりデータベースで経路を判定します。前提は、顧客向けアプリと運用・保守用アプリが別々のDBロールで接続していることです。次は運用側のロール（ops_app）からの注文を、別の担当者の承認記録が無ければ拒否するPL/pgSQLのトリガー関数の例です。
-- 運用・保守用ロールからの注文は、別担当者の承認が無ければ拒否する（PostgreSQL）
CREATE TABLE ops_approvals (
approval_id bigserial PRIMARY KEY,
account_no text NOT NULL,
requested_by text NOT NULL,
approved_by text NOT NULL CHECK (approved_by <> requested_by),
expires_at timestamptz NOT NULL
);
ALTER TABLE orders ADD COLUMN approval_id bigint;
CREATE FUNCTION reject_unapproved_ops_order() RETURNS trigger AS $$
BEGIN
IF current_user = 'ops_app' AND NOT EXISTS (
SELECT 1 FROM ops_approvals a
WHERE a.approval_id = NEW.approval_id
AND a.account_no = NEW.account_no
AND a.expires_at > now()) THEN
RAISE EXCEPTION '承認の無い運用経路の注文を拒否: %', NEW.account_no;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER orders_ops_guard
BEFORE INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION reject_unapproved_ops_order();判定に使うのはアプリが送る値ではなく、接続しているロール名です。画面の入力欄で「顧客の操作」と偽っても、運用側のロールで接続している限りトリガーを通れません。承認表は依頼者と承認者が同じ値になれない制約を持ち、期限も切ってあります。運用側ロールには承認表への書き込み権限を与えず、承認は別の画面と別のロールから入れる構成にします。
二者承認を採用する条件と緊急時の代理発注が止まるときの見送り判断
このトリガーを入れる価値が高いのは、運用・保守の機能から顧客口座の注文や出金に触れられる作りになっているシステムです。委託先の担当者が操作する経路があるなら、まず入れます。承認の手間は増えるものの、管理機能を1つ破られただけで注文が出る状態を残すよりは小さな負担で済むからです。
一方、運用側から注文を出す機能そのものが不要なら、トリガーより先に機能を消すべきです。障害時の代理発注のように、夜間に承認者がいないと業務が止まる場面では、期限付きの承認を当番2名で回す運用を決めてから入れます。承認者を1名で済ませる例外を作るなら、入れない方がましです。例外が常態化すると、監査で承認記録があっても中身は自己承認になります。
顧客のログインに結び付かない注文を検知｜Pythonでの突合と日証協GLの振る舞い検知
MFA済みセッションと注文ログを突合して口座違い・時間外を洗い出すコード
トリガーは入口を塞ぎますが、すでに通った注文の点検は別に要ります。顧客の注文なら、その前に同じ口座で多要素認証を通ったログインがあるはずです。次はログインの記録と注文の記録をPython標準のcsvモジュールで読み、結び付かない注文を出力する例です。
# 顧客のMFA済みログインに結び付かない注文を洗い出す（Python 3）
import csv
from datetime import datetime, timedelta
WINDOW = timedelta(hours=8) # セッションの有効時間。自社の設定に合わせる
def load(path):
with open(path, encoding="utf-8", newline="") as f:
return list(csv.DictReader(f))
sessions = {}
for row in load("logins.csv"): # session_id,account_no,login_at,mfa
if row["mfa"] == "passed":
sessions[row["session_id"]] = (row["account_no"],
datetime.fromisoformat(row["login_at"]))
for o in load("orders.csv"): # order_id,account_no,ordered_at,session_id
s = sessions.get(o["session_id"])
at = datetime.fromisoformat(o["ordered_at"])
if s is None:
reason = "MFA済みのログインが無い"
elif s[0] != o["account_no"]:
reason = "ログインした口座と注文の口座が違う"
elif not (s[1] <= at <= s[1] + WINDOW):
reason = "セッションの有効時間外"
else:
continue
print(o["order_id"], o["account_no"], o["ordered_at"], reason)
# 出力例：A-10023 1234567 2026-10-14T10:05:00 MFA済みのログインが無い出力が1件でもあれば、その注文がどの経路から入ったかを調べます。日次の夜間処理で回すだけでも、翌朝には異常に気づくことが可能です。リアルタイムに止めたい場合は、同じ条件を注文受付の直前に置き、該当したら保留にして顧客へ確認の連絡を入れる作りにします。
日証協ガイドライン5.(1)(2)が求めるログ項目と委託元へ転送する運用操作記録
日本証券業協会のインターネット取引における不正アクセス等防止に向けたガイドライン（2025年10月15日改正）は、5.(1)でログイン時の振る舞い検知と、位置情報・端末情報・接続元IPアドレス・接続元ポート番号などログイン・取引時の情報の保存を求めています。5.(2)は評価に応じた追加の本人認証や遮断、ベストプラクティスとしてログイン後の振る舞い検知を挙げています。
上のコードが動くには、注文の記録にセッションIDが残っていることが条件です。運用・保守の操作も同じく、誰が・どの端末から・どの口座に何をしたかを1行ずつ残し、委託先のサーバーだけでなく委託元の側にも転送して保管します。委託先の中だけにある記録は、委託先が破られたときに消される可能性があるためです。
委託元が監視・追跡できる態勢｜日証協GL外部委託先7項目と報告の段取り
日証協ガイドライン3.(2)③⑤に沿い委託先の管理者権限を委託元から見える化する
同じガイドラインの3.(2)は、外部委託先の顧客情報について7つの対策を定めています。今回の事案に直接つながるのは③と⑤です。③は委託先での顧客データへのアクセス制限やその運用状況を、委託元として監視・追跡できる態勢の構築を求めています。⑤は委託先に付与するアクセス権限の使い回しの防止などの権限管理です。3.(1)④も、社外からの不正アクセス対策として侵入可能経路の特定を挙げています。
実務では、委託先の管理機能にログインできるアカウントの一覧と接続元、付与した権限を、月に1回委託元が受け取って差分を確かめます。前月に無かった管理者アカウントや、許可していない接続元からのログインがあれば、その場で理由を聞く運用です。委託先の正規アカウントが攻撃の足場になった例はNEC委託先の不正アクセスで、委託先を起点にした攻撃の型はサプライチェーン攻撃とはで整理しています。
個人情報保護委員会への報告と顧客への通知を委託先任せにしない理由
委託先で起きた事故でも、顧客の個人データの取り扱いを委託した事業者が報告と本人通知を担う主体です。個人情報保護委員会の案内のとおり、不正の目的をもって行われたおそれのある漏えいは件数にかかわらず報告の対象になりえます。報告の期限や類型は個人情報保護委員会への報告義務で解説しています。
今回、岩井コスモ証券は検知した当日に不正注文の対象顧客へ連絡し、2日後に漏洩を公表しました。委託元が自分のログで異常に気づき、委託先へ連絡した流れです。委託先から知らされるのを待つ作りでは、この速さは出ません。管理機能の接続元や注文の経路を第三者の目で点検したい場合は、脆弱性診断・セキュリティ診断で、委託先が運用する管理機能から注文の受付までを含めて確認できます。
よくある質問
岩井コスモ証券の不正アクセスについて、顧客と開発者から出やすい質問をまとめました。
岩井コスモ証券のどの情報が漏洩しましたか？
第2報によると、対象は4,975名で、項目は氏名・メールアドレス他です。初報の4,611名に、通信記録の再精査で判明した364名が加わりました。取引暗証番号は含まれておらず、公表文はこの情報では証券口座へのログインや取引はできないとしています。
不正注文は漏洩した情報を使って行われたのですか？
第2報は、不正取引に漏洩した個人情報は使われていないと明記しています。10月14日に売買管理システムへの攻撃があり、7口座で意図しない注文が出て、うち5口座で約定しました。対象の顧客には当日に連絡があり、取引前の状態に戻す措置が完了しています。
自分が対象かどうかはどうすれば分かりますか？
対象の顧客には、ログイン後のお知らせ画面とメールで個別に連絡が届いています。メールのリンクは使わず、自分で開いた公式サイトや公式アプリからログインして確かめてください。電話なら公表文のお客様相談室（0120-405-546・平日9時〜17時）が窓口です。
トレードワークスのシステムを使う他の証券会社にも影響はありますか？
第2報によると、TW社が他の金融機関に提供しているシステムも点検され、同様の不正アクセスは確認されていません。TW社のシステムを使う他社の名前や点検の結果の詳細は公表文に書かれていないため、続報が出た場合は各社の公表文で確認する必要があります。
自社の取引システムは何から点検すればよいですか？
最初に、運用・保守の機能から顧客口座の注文や出金に触れられる経路があるかを洗い出します。あれば、その経路の接続元と多要素認証、注文時の承認の有無を確かめます。次に、注文の記録にセッションIDが残り、顧客のログインと突き合わせられるかを確認してください。
関連記事
- 大和証券の情報漏洩・不正アクセス：約11万人の対象確認と委託先i-askの経緯、口座番号を委託先に残さない設計：同じ10月に起きた証券会社の委託先事案
- スカラコミュニケーションズの不正アクセスと最大71万件：管理サイトから他社へ広げない設計：管理サイトの接続元制限と多要素認証
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：管理APIの認可を既定拒否にする実装
- NEC委託先の不正アクセスとは｜顧客システム暗号化・情報漏えいの経緯と委託元が点検する正規アカウント：委託先の正規アカウントを点検する手順
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時の報告の段取り
