大和証券は2026年10月5日、顧客からのインターネット経由の問い合わせ管理などに使っているサービスの提供元、株式会社スカラコミュニケーションズのサーバーに不正アクセスがあり、約11万人分の氏名・メールアドレス・口座番号などを含む約22万件の情報が漏洩した可能性があると公表しました。大和証券自身のシステムへの不正アクセスは確認されていません。本記事では公表文をもとに経過と対象を整理し、口座番号とメールアドレスが漏れた場合に起きる詐欺の型と、顧客が今日やる点検をまとめます。後半では、問い合わせの本文を外部のサービスへ送る前に口座番号を伏せる実装と、委託先の台帳をコードで点検する手順を、そのまま試せる形で示します。
まとめ：大和証券の不正アクセスで確定した事実と顧客・開発者が今やること
公表文で確定しているのは、問い合わせ管理に使うサービスを提供する委託先（以下SC社）のサーバーに10月2日夜から3日朝にかけて不正アクセスがあったこと、受付済みの問い合わせ履歴が漏洩した可能性があること、件数が約22万件で、そのうち約11万人分に氏名・メールアドレス・口座番号などが含まれることです。一方、侵入の手口と、SC社の他の取引先に影響が及んでいるかどうかはまだ明らかになっていません。
顧客がまず備えるのは、大和証券や関係者を装う電話とメールへの対応です。開発者の側で見るべき論点は別にあります。自社のシステムは破られていないのに、問い合わせの受付で委託先に渡した顧客情報が、委託先のサーバーに履歴として残っていた点です。外部のサービスへ何を送り、いつまで残すかという設計の問題として、自社に引き寄せて点検できます。
| 項目 | 公表されている内容 |
|---|---|
| 公表日 | 2026年10月5日 |
| 侵害を受けた先 | 委託先SC社のサーバー |
| 不正アクセスの時間帯 | 10月2日20時33分頃〜3日8時1分頃 |
| 件数 | 約22万件（うち約11万人分） |
| 漏洩の可能性がある項目 | 氏名・メールアドレス・口座番号等 |
| 大和証券のシステム | 不正アクセスは未確認 |
| 侵入の手口 | 未公表 |
公表内容を時系列で確認する｜10月2日夜の侵入から10月5日の公表まで
委託先スカラコミュニケーションズのサーバーで起きた不正アクセスの経過
大和証券の公表文（2026年10月5日）によると、同社は10月3日にSC社から連絡を受けました。内容は、SC社のサーバーへの不正アクセスにより、大和証券の顧客情報へのアクセスと取得の形跡が確認されたというものです。SC社の説明では、不正アクセスは10月2日20時33分頃から10月3日8時1分頃までの間に発生しています。
侵害の時間帯は金曜の夜から土曜の朝にかけての約11時間半で、連絡は侵害が止んだ10月3日のうちに届いています。SC社は緊急のセキュリティ強化を実施済みで、追加の不正アクセスや情報漏洩は確認されていないと報告したとのことです。委託元が自社のログでは追えない場所で起きた侵害を、どの速さで知らされるかは委託契約の取り決めに左右されます。自社側でログのどこを見るかは不正アクセスのログ確認・解析方法で整理しています。
大和証券の10月5日付の公表文で確定した対象の範囲と約22万件の内訳
大和証券はSC社のサービスを、顧客からのインターネット経由の問い合わせ管理などに使っていました。受付済みの問い合わせ履歴に関わる情報はSC社のサーバーに保存されており、これが漏洩した可能性があると説明しています。範囲は、約11万名の顧客に関わる氏名・メールアドレス・口座番号などの情報と、個人を特定できる情報を含まない問い合わせを合わせた約22万件です。
公表文は、この情報では、オンライントレードを含め証券口座へのアクセスや同社での取引はできないと明記しています。現時点で本件に起因する不正な取引は確認されておらず、情報がインターネット上に公開・拡散された事実も確認されていないとしています。対象の顧客には個別に連絡する方針で、専用窓口（0120-851850・平日9時から17時）が設けられました。
侵入経路と他の委託元への影響が未公表の段階で書けることと書けないこと
公表文は、どの経路から入られたか、SC社のどのサービスやどの機能が狙われたかに触れていません。SC社は問い合わせ管理やFAQの製品を複数の企業に提供していますが、2026年10月6日時点でSC社の公式サイトに本件の告知は見当たらず、他の取引先への影響も公表されていません。
そのため本記事では、特定の製品や脆弱性に結び付けた推測はしません。読み取れるのは構図だけです。顧客が問い合わせフォームに書いた内容が、口座番号を含んだまま委託先のサーバーに履歴として蓄積され、そこが破られました。後半で扱う設計の話は、この構図を前提にしています。
口座番号とメールアドレスの組み合わせで起きる悪用｜取引はできないが詐欺の材料になる
公表文が「口座へのアクセスや取引はできない」とする根拠と残るリスク
証券口座にログインするには、口座番号のほかにパスワードなどの認証情報が要ります。今回の対象にパスワードや暗証番号は含まれていないため、公表文の説明どおり、この情報だけで口座を操作することはできません。
残るのは、本物らしさを高める材料として使われるリスクです。氏名・メールアドレス・口座番号に加えて、顧客が過去に問い合わせた内容まで手元にあれば、攻撃者は「先日お問い合わせいただいた件で」と、実際のやり取りを踏まえた連絡を装えます。公表文も、氏名や問い合わせ内容を使って同社や関係者を装う電話・メールによる詐欺のおそれを挙げています。
2025年からの証券口座乗っ取りの流れの中で今回の一覧が持つ意味
証券業界では2025年春から、偽サイトで盗んだIDとパスワードによる口座の乗っ取りと不正取引が相次ぎました。金融庁の注意喚起ページは2026年9月9日にも更新され、被害の報告が続いていることを示しています。こうした攻撃の入口はフィッシングです。誰が大和証券の顧客で、どんな問い合わせをしたかが分かる一覧は、偽のログイン画面へ誘導するメールの宛先として扱いやすい情報です。
| 想定される悪用 | きっかけ | 顧客側の防ぎ方 |
|---|---|---|
| 偽ログイン画面 | 大和証券を装うメール | ブックマークから開く |
| 問い合わせ装いの電話 | 過去の問い合わせ内容 | 正規窓口へかけ直す |
| 認証情報の聞き出し | 補償や確認を名目にした連絡 | パスワード等を伝えない |
| 不正ログイン | 他サービスと同じパスワード | 多要素認証を有効にする |
手口の全体像はフィッシング詐欺とはで解説しています。
大和証券の顧客が今日やる点検手順｜同社を装う電話とメールの見分け方
公表文が「提供しないで」と明記した情報と正規窓口での確認方法
公表文は、不審な連絡に記載されたリンクや添付ファイルを使わず、取引用のID・パスワード、暗証番号、ワンタイムパスワードなどを提供しないよう求めています。身に覚えのない連絡や取引は、同社の公式ホームページなどで確かめた正規の窓口へ問い合わせるよう案内しています。
判断は、届いた連絡の中のリンクや電話番号を使わず、自分で開いた公式サイトか、公表文の専用窓口で確かめる、の一点に絞ると迷いません。表示名や電話番号は偽装できるため、それだけで本物と決めないことも大切です。不審なメールを受け取ったら、フィッシング対策協議会のサイトで同じ文面の事例が出ていないかを確認できます。
ログインの多要素認証とパスキーを有効にしておく理由と優先順位
日本証券業協会は2025年10月15日にインターネット取引における不正アクセス等防止に向けたガイドラインを改正し、ログインや出金などの重要な操作でフィッシングに耐性のある多要素認証（パスキーなど）を求めています。証券会社側が用意した機能も、顧客が設定しなければ効きません。
優先する順番は、証券口座のログインに使うメールアカウントの保護、証券口座の多要素認証やパスキーの設定、取引や出金の通知の有効化です。同じパスワードを他のサービスで使っているなら、それも変えておきます。仕組みの違いは多要素認証（MFA）とはで比べています。
問い合わせ管理の委託先はなぜ狙われるか｜受付履歴が名簿になる構図
問い合わせ履歴に口座番号や氏名が書き込まれて蓄積していく理由
問い合わせフォームは、本人を特定して早く回答するために、氏名や連絡先に加えて口座番号の入力を求めることがよくあります。自由記述の本文も、顧客が自分で口座番号や電話番号を書き込む箇所です。受け付けた内容は、回答の履歴として問い合わせ管理のサービスに残ります。対応品質の分析や、同じ顧客からの再度の問い合わせに備えて、消さずに置かれる運用が一般的です。
結果として、問い合わせ管理のサービスは、顧客の名前と連絡先と口座番号、さらに困りごとの中身までが並ぶ一覧になります。システムの選び方や自社開発との比較は問い合わせ管理システムとはで解説していますが、セキュリティの面では、この一覧が委託先の環境に置かれる点を前提に設計する必要があります。
自社システムは無事でも委託先の保存データから漏れる構図と過去事例
今回の公表文は、自社のシステムへの不正アクセスは確認されていないと明言しています。それでも約11万人分の情報が漏洩した可能性があるのは、データの写しが委託先に置かれていたためです。同じ構図は、配信停止中のメールアドレスを格納したサーバーが狙われた東京メトロ（メトポ）の不正アクセスや、退会者の本人確認書類まで残っていたタイムズカーの不正アクセスにも見られます。
委託先からの漏えいは、自社の防御をどれだけ固めても止められません。止められるのは、委託先に渡すデータの量と、そこに残る期間です。受託開発の現場でも、外部サービスとの連携仕様を決める段階で「何を送らないか」が議論されないまま、画面の項目をそのまま転送する設計を見かけます。
外部SaaSへ送る前に伏せる｜問い合わせ本文から口座番号を除くPython実装
フォーム受付時に口座番号・電話番号・メールアドレスを検出して置き換えるコード
問い合わせの本文を外部の管理サービスへ送る前に、自社のサーバーで口座番号などを検出して置き換えておけば、委託先が破られても本文から口座番号は出てきません。次はPythonの標準ライブラリreとhmacだけで書いた例です。口座番号は「支店3桁と口座7桁」と仮定しているので、自社の採番規則に合わせて正規表現を書き換えてください。
# 問い合わせ本文を外部の管理サービスへ送る前に伏せる（Python 3）
import hashlib
import hmac
import os
import re
# 鍵は問い合わせDBと別の場所（Secrets ManagerやKMSなど）から読み込む
KEY = os.environ["INQUIRY_HMAC_KEY"].encode("utf-8")
# 例：支店3桁＋口座7桁。区切りなし・ハイフン・空白の3通りを拾う
ACCOUNT = re.compile(r"(^|\D)(\d{3})[-‐－ ]?(\d{7})(?!\d)")
EMAIL = re.compile(r"[\w.+-]+@[\w-]+(?:\.[\w-]+)+")
PHONE = re.compile(r"(^|[^\w-])(0\d{1,4}-\d{1,4}-\d{3,4})(?![\w-])")
def ref_id(account: str) -> str:
digest = hmac.new(KEY, account.encode("utf-8"), hashlib.sha256).hexdigest()
return "ACC-" + digest[:16]
def redact(text: str):
refs = {}
def mask_account(m):
account = m.group(2) + m.group(3)
rid = ref_id(account)
refs[rid] = account # 社内DBにだけ保存し、外部へは送らない
return m.group(1) + "[口座:" + rid + "]"
text = ACCOUNT.sub(mask_account, text)
text = EMAIL.sub("[メールアドレス]", text)
text = PHONE.sub(lambda m: m.group(1) + "[電話番号]", text)
return text, refs
if __name__ == "__main__":
body = "口座番号123-4567890の件です。連絡先は " + "taro" + "@" + "example.jp" + " か 090-1234-5678 です。"
masked, refs = redact(body)
print(masked)
# 口座番号[口座:ACC-…]の件です。連絡先は [メールアドレス] か [電話番号] です。区切りのない10桁の数字は、電話番号であっても口座番号として伏せられます。どちらに分類されても外部へは出ないので、迷う入力は伏せる側に倒しています。検出漏れを減らすには、問い合わせフォームの口座番号欄を自由記述と分け、専用欄の値は本文に入れずに参照IDだけを送る作りが確実です。
伏せた口座番号を社内でだけ引き戻すためのHMAC参照IDとその保存先
伏せた後も、担当者は「どの顧客の問い合わせか」を知る必要があります。そこで、口座番号からHMAC-SHA256で参照IDを作り、外部のサービスに送るのは、その参照IDだけです。対応表（参照IDと口座番号の組）は自社のDBに置き、担当者は社内の画面で参照IDから顧客を引き当てます。鍵を知らない者は、同じ口座番号から同じIDを計算できません。
あわせて、自社側に残す問い合わせ履歴にも保存期限を決めます。次は、回答が済んで180日を過ぎた問い合わせから本文と連絡先を消すPostgreSQLの例です。期限は社内規程と顧客対応の実態に合わせて決めてください。
-- 回答完了から180日を過ぎた問い合わせの本文と連絡先を消す（PostgreSQL）
UPDATE inquiries
SET body = NULL,
email = NULL,
account_ref = NULL,
redacted_at = now()
WHERE status = 'closed'
AND closed_at < now() - INTERVAL '180 days'
AND redacted_at IS NULL;外部の問い合わせ管理サービス側にも、同じ期限での削除を契約で求めるか、APIで定期的に消す処理を組みます。自社だけ消しても、委託先に写しが残れば意味がありません。似た考え方でカード番号を置き換える方式は決済トークンとはで、API経由の送信時に個人情報を伏せる方式の注意点はPIIマスキングの落とし穴で解説しています。
口座番号を伏せる方式を採用する条件と原文が必要になる問い合わせの扱い
問い合わせ管理を外部のサービスに任せていて、本文に口座番号や取引の内容が書き込まれる業務なら、伏せる方式を入れる価値があります。委託先が破られたときの被害を、回答業務の手間をほとんど増やさずに小さくできるためです。証券・銀行・保険のように、口座番号が詐欺の材料として価値を持つ業種では優先度が高くなります。
一方で、本人確認書類の画像を添付させる問い合わせや、口座番号の照合そのものが回答に必要な問い合わせは、伏せるだけでは業務が回りません。その場合は、外部のサービスで受け付けず、自社の環境で受ける専用の窓口に分けます。全てを伏せるか全てを送るかではなく、問い合わせの種類ごとに送る先を分けるのが現実的な線引きです。
委託先台帳をコードで持つ｜金融庁ガイドラインの管理項目を点検に変える
金融分野サイバーセキュリティガイドライン2.6が台帳に求める項目
金融庁の金融分野におけるサイバーセキュリティに関するガイドライン（令和6年10月4日）は、2.6でサードパーティリスク管理を定めています。サードパーティの範囲は、外部委託先だけでなく、クラウドなどのサービス提供事業者も含むものです。基本的な対応事項の⑤は、サードパーティを管理する台帳の整備を求め、管理項目の例として名称、提供する商品・サービスと機能、自組織のシステムに対するアクセスレベル、保持・処理する自組織のデータの種類と機密性、場所を挙げています。
④は、重要な情報（個人情報など）の取り扱いの有無や外部からのアクセスの容易さを踏まえたリスク評価を、⑧は契約やSLAに監査権限、再委託手続、インシデント発生時の対応と報告、データの所在・保管・廃棄の取り決めなどを明記することを求めています。今回のような問い合わせ管理のサービスは、個人情報と口座番号を持ち、インターネットから使われる点で、この評価で上位に来るはずの委託先です。
口座番号を持つ委託先と保存期限・監査日の欠けを洗い出すスクリプト
台帳をExcelで持っていても、項目が埋まっているかを確かめる作業は手作業になりがちです。ガイドラインの管理項目をJSONで持てば、欠けている項目を機械的に洗い出せます。次は台帳の1件分の例です。
[
{
"name": "問い合わせ管理サービス A社",
"service": "Webフォームの受付と回答履歴の管理",
"access": "自社システムへの接続なし・顧客がインターネットから直接送信",
"data": ["氏名", "メールアドレス", "口座番号", "問い合わせ本文"],
"location": "委託先が契約するクラウド（国内リージョン）",
"retention_days": null,
"last_audit": "2025-04-01",
"subcontractors": ["不明"]
}
]次のスクリプトは、口座番号やパスワードなどの機密度の高いデータを持つ委託先のうち、保存期限が決まっていないもの、1年以上監査していないもの、再委託先を把握していないものを一覧にします。
# 委託先台帳（vendors.json）の欠けを洗い出す（Python 3）
import datetime
import json
SENSITIVE = {"口座番号", "パスワード", "暗証番号", "取引履歴", "本人確認書類"}
today = datetime.date.today()
with open("vendors.json", encoding="utf-8") as f:
vendors = json.load(f)
for v in vendors:
held = SENSITIVE & set(v.get("data", []))
if not held:
continue
issues = []
if v.get("retention_days") is None:
issues.append("保存期限が未設定")
last = v.get("last_audit")
if last is None or (today - datetime.date.fromisoformat(last)).days > 365:
issues.append("1年以上監査していない")
if not v.get("subcontractors") or "不明" in v["subcontractors"]:
issues.append("再委託先を把握していない")
if issues:
print(v["name"], sorted(held), "／".join(issues))
# 出力例：問い合わせ管理サービス A社 ['口座番号'] 保存期限が未設定／1年以上監査していない／再委託先を把握していないこのスクリプトを月に1回動かし、出力が空になるまで台帳と契約を埋めていくと、点検が担当者の記憶に頼らなくなります。委託先が第三者認証を持つかどうかはSOC2とはで、委託先を含めた攻撃の型はサプライチェーン攻撃とはで整理しています。
委託契約と日証協ガイドラインで確認する監視・追跡と再委託の条件
証券会社向けには、日本証券業協会のガイドラインが外部委託先の顧客情報について7つの対策を定めています。定期的なモニタリング、ログインIDやパスワードを含む顧客情報が委託先から漏れない措置の確認、委託先での顧客データへのアクセス制限と運用状況を委託元が監視・追跡できる態勢、開発環境と本番環境の間のデータ転送の管理、委託先に付与する権限の使い回しの防止、経営層への報告、二段階以上の委託での再委託先の監督の確認です。同じガイドラインは、クラウドサービスを含む顧客情報の社外移転の状況を把握することも求めています。
個人情報の面では、金融分野における個人情報保護に関するガイドラインの第10条が、委託先の選定基準の策定と定期的な見直し、委託契約への監督・監査・報告徴収の権限や漏えい時の委託先の責任の明記、定期的な監査による遵守状況の確認を求めています。台帳の「last_audit」と「subcontractors」の欄は、この条文に沿って埋める項目です。
漏えい後の報告と二次被害対策｜金融分野の報告先とDMARCのreject設定
金融分野ガイドライン第11条が定める報告先と本人への通知の扱い
同ガイドラインの第11条は、漏えい等の報告を通則ガイドラインに従って行うとしたうえで、金融庁長官等が報告を受理する権限の委任を受けている場合は金融庁長官等へ報告すると定めています。加えて、顧客の個人データの漏えい等が発生し、または発生したおそれがあるときは、関係法令に従って監督当局に報告しなければならないという規定です。委託先で起きた事故でも、顧客情報の取り扱いを委託した事業者が報告と本人への通知の主体になります。
報告の対象になる事態や、速報と確報の期限は個人情報保護委員会の案内にまとまっており、不正の目的をもって行われたおそれがある漏えいは件数にかかわらず対象になりえます。類型の見分け方は個人情報保護委員会への報告義務で、委託先にも及ぶ新しい届出の枠組みはサイバー対処能力強化法とはで解説しています。
顧客を装う偽メールを減らすためにDMARCをrejectまで進める手順
漏れたメールアドレスに届く偽メールの多くは、差出人を実在の金融機関に見せかけます。差出人に自社ドメインそのものを使う偽装は、送信側のDMARCで受信側に拒否させることが可能です。日本証券業協会のガイドラインも、顧客へ送るメールのドメインを特定してDMARCなどの送信ドメイン認証を計画的に導入し、レポートを確かめたうえでポリシーを「reject」にすることを求めています。
進め方は、noneで集計レポートを受け取り、正規の送信元が全て認証を通ることを確かめてから、quarantine、rejectと段階を上げる流れです。2026年5月に標準化されたRFC 9989では、段階適用に使われていたpctタグが廃止され、試験運用はtタグで示します。各ポリシーの差と設定例はDMARCの仕組みとnone・quarantine・rejectの差で詳しく比べています。
外部からの入口と、委託先を含めて破られた後に何が読めるかを第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断で、問い合わせフォームから外部サービスへの連携や会員DBまでの経路を含めて点検できます。
よくある質問
大和証券の不正アクセスについて、顧客と開発者から出やすい質問をまとめました。
大和証券のどの情報が漏洩した可能性がありますか？
公表文によると、インターネット経由の問い合わせに関わる情報のうち、約11万名の顧客の氏名・メールアドレス・口座番号などが漏洩した可能性があります。個人を特定できる情報を含まない問い合わせを合わせると約22万件です。パスワードや暗証番号が漏れたとは公表されていません。
漏洩した情報で証券口座にログインされたり取引されたりしますか？
公表文は、この情報ではオンライントレードを含め証券口座へのアクセスや同社での取引はできないとしています。現時点で本件に起因する不正な取引も確認されていません。ただし、同じメールアドレスとパスワードを他のサービスで使っている場合は、別の経路で認証情報を狙われる材料になりえます。
自分が対象かどうかはどうすれば分かりますか？
大和証券は、対象の顧客に個別に連絡する方針を示しています。届いた連絡のリンクや電話番号は使わず、公表文に記載された専用窓口（0120-851850・土日祝日を除く9時から17時）か、公式サイトで確かめた窓口へ問い合わせてください。
スカラコミュニケーションズの他の取引先にも影響はありますか？
2026年10月6日時点では、SC社の他の取引先への影響は公表されていません。大和証券の公表文はSC社のサーバーへの不正アクセスとしか書いておらず、侵入経路やサービス名も明らかになっていません。続報が出た時点で、各社の公表を確認する必要があります。
自社の問い合わせ管理は何から見直せばよいですか？
最初に、問い合わせフォームから外部のサービスへ送っている項目を洗い出し、口座番号や本人確認の情報が含まれていないかを確かめます。含まれていれば、送る前に伏せる処理か、専用欄の参照ID化を入れます。次に、委託先の台帳に保存期限・監査日・再委託先が埋まっているかを確認してください。
関連記事
- 東京メトロ（メトポ）の不正アクセスと約5.9万件のメールアドレス｜配信停止リストを残さない設計：委託先のサーバーに残ったアドレスが狙われた事例
- タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計：残す必要のないデータが漏れた事例
- セイコーマートの不正アクセスと57万人の会員情報｜アプリAPIの認可を点検する手順：会員情報を守るAPI側の点検
- WebAuthnとは？パスキー認証を実装する仕組みと登録・認証フロー・RP実装の要点：耐フィッシングの認証を実装する手順
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時の報告の段取り
