インドアゴルフスクールを運営するステップゴルフ株式会社は2026年11月7日、業務システムと予約システムへの不正アクセスにより、個人情報が外部に漏えいした可能性が極めて高いと発表しました。対象になり得るデータは最大21.5万件で、銀行口座情報は暗号化されていない状態で保管されていたと同社が明記しています。本記事の前半では、無料体験だけの人も対象か、口座は大丈夫か、届いた連絡は本物か、どこに問い合わせるのかを、11月9日時点の発表に沿って整理する構成です。後半では、会員の口座情報を扱う開発者に向けて、口座番号をバックアップに残さない実装をPythonのコードで示します。
まとめ：ステップゴルフの不正アクセスで会員と無料体験の申込者が確認すること
対象になり得るのは、無料体験に申し込んだ人と、現在・過去の会員です。氏名や住所に加えて、口座振替に使う金融機関名・支店名・口座番号・口座名義、レッスンカルテ、顔写真、要配慮個人情報が含まれます。詳細はステップゴルフの第一報が起点になります。
利用者がまずやることは2つです。口座の入出金明細で身に覚えのない引き落としがないかを確かめ、同社や金融機関を名乗る連絡のリンクを開かないようにします。専用窓口は準備中で、続報は11月10日を目途に出る予定です。開発側が持ち帰る論点は、バックアップに平文の口座番号が残る設計になっていないか、侵入から検知までの空白を縮める点検があるかの2点です。
| 項目 | 公表されている内容（11月9日時点） |
|---|---|
| 対象になり得る人 | 無料体験の申込者、現在・過去の会員 |
| 最大の件数 | 21.5万件（DB上の登録件数） |
| 基本情報 | 氏名・住所・生年月日・電話番号・メール |
| 銀行口座情報 | 金融機関名・支店名・口座番号・名義等 |
| 口座情報の保管状態 | 暗号化されていない状態 |
| 利用情報 | 契約状況・予約と購入の履歴 |
| その他の項目 | カルテ・顔写真・要配慮個人情報等 |
| 影響なしとされる項目 | カード情報・本人確認書類 |
| 二次被害 | 具体的な被害は確認されていない |
| 未公表 | 侵入経路・実際の漏えい件数 |
会員と無料体験の申込者が最初に確かめる対象範囲と届く連絡の真偽
無料体験だけの人と退会済みの人も対象に入る21.5万件という数の読み方
無料体験の申し込みだけで入会していない人も、すでに退会した人も、対象になる可能性があります。第一報が対象を「無料体験にお申し込みいただいた方および現在・過去の会員様」と書いているためです。入会しなかったから関係ない、とは言えません。
21.5万件という数字は人数ではなく、データベース上の登録件数です。同社は8月の告知で累計会員数を110,689人としていますが、21.5万件には無料体験の申込者も含まれ、1人が複数件を持つ場合の扱いも公表されていないため、単純には比べられません。実際の件数と範囲は調査中で、人によって含まれる項目も異なります。対象者にはメール等で個別に連絡するとされており、連絡がまだ来ていないことは対象外の根拠になりません。
銀行口座の引き落とし確認と口座番号と名義だけでは起きないことの切り分け
同社は「口座番号と名義だけでは預金は引き出せません」としたうえで、身に覚えのない引き落としがないかの確認を呼びかけています。やることは、通帳やインターネットバンキングで直近の入出金を見ることです。見覚えのない引き落としがあれば、取引先の金融機関にすぐ連絡します。
第一報の時点で、口座番号の変更や口座の解約を求める案内はありません。本記事の判断としても、引き落としに異常がなければ、今すぐ口座を作り直す必要はないと考えます。警戒すべきは預金の直接の引き出しより、氏名、住所、電話番号、口座番号を揃えた相手から届く「本物らしい連絡」です。
ステップゴルフや銀行を装うメール・SMS・電話への対応と2つの相談番号
同社は、同社や金融機関を装う不審なメール、SMS、電話への注意を呼びかけ、心当たりのないURLへのアクセス、添付ファイルの開封、暗証番号やパスワードの入力を控えるよう求めています。金融機関名や口座番号の一部が正しく書かれていても、本物の証拠にはなりません。漏えいした情報そのものが使われるおそれがあるからです。手口の全体像はフィッシング詐欺の仕組みと技術的な対策にまとめています。
電話で暗証番号や手続きを求められたら、いったん切って、通帳やカードに書かれた金融機関の番号へ自分でかけ直します。判断に迷うときの相談先は、警察相談専用電話の#9110と、消費者ホットラインの188です。
専用窓口は11月9日時点で準備中：店舗に聞かない理由と続報を待つ確認先
専用の問い合わせ窓口（電話・Web）は設置の準備中で、整い次第ホームページで案内するとされています。店舗では詳細な問い合わせに対応できないため、店舗への連絡は控えるよう同社は求めています。続報の目途は11月10日です。
予約とレッスンは通常どおり利用できます。電話番号やURLが書かれた「窓口のご案内」がメールで届いたら、記載のリンクを開く前に公式サイトのお知らせ欄と突き合わせてください。11月9日時点で、第二報は確認できていません。
公式発表で整理する経緯：10月23日の不正アクセスから11月7日の第一報まで
異常の検知まで13日：10月23日・25日のアクセスと11月5日の判明の時系列
- 10月23日：不正アクセスが行われる（後の調査で判明）
- 10月25日：同じく不正アクセスが行われる（後の調査で判明）
- 11月5日：システムの異常な処理を検知し、第三者の不正アクセスが判明
- 11月7日：第一報を公表。個人情報保護委員会への報告と警察への相談を実施済みと説明
- 11月10日目途：続報の掲載を予定
最初のアクセスから検知までは13日あります。同社は過去のアクセス記録の調査で、個人情報を含むデータベースのバックアップファイル等が外部に漏えいした可能性が極めて高いことを確認しました。緊急対策として、アクセス元の遮断と認証情報の変更を実施し、外部のセキュリティ専門機関に調査を依頼しています。ITmedia NEWSの報道も、要配慮個人情報の具体的な内容は明らかにされていないと指摘しています。
10月23日のPHP脆弱性の告知と今回の第一報の関係：公式に書かれていない範囲
同社は不正アクセスの日付と同じ10月23日に、「PHP」脆弱性の報道に関する告知を出しています。専門業者と連携して必要な一次対策を完了し、その時点で個人情報の漏えいやシステムへの影響は確認されていない、という内容でした。
この告知と今回の不正アクセスを結びつける説明は、第一報にありません。告知はCVE番号も脆弱性の名称も挙げていないため、同時期に修正版が公開されたPHP2Shell（CVE-2026-109618など）を指すのかも、現時点では確定に至っていない状況です。本記事は、PHPの脆弱性が侵入経路だとは書きません。バックアップの置き場所、データベースの種類、口座情報以外の保存形式も未公表です。確定しているのは「バックアップファイル等が漏えいした可能性が極めて高い」「口座情報は暗号化されていなかった」の2点で、以降の技術章もこの2点だけを前提にします。
バックアップと口座情報の平文保存から実装者が持ち帰る保管設計の論点
本番の画面やAPIの認可が堅くてもダンプ1本で全件が渡るという構造の問題
データベースのバックアップは、本番の認可を通らない全件の複製です。画面やAPIで1件ずつ権限を確かめていても、ダンプのファイルを取られれば、その検査は働きません。pg_dumpのような標準の道具が出力するダンプには、列を暗号化していない限り、値がそのまま入ります。
そのためバックアップには、本番と同じか、それ以上の管理が要ります。口座番号の列が平文なら、ダンプの持ち出しはそのまま口座情報の持ち出しです。テーブルごとの権限設計だけで安心してはいけません。
報告対象の4類型と高度な暗号化の要件から逆算する口座番号の保存方式
個人情報保護委員会の漏えい等報告の案内は、要配慮個人情報、財産的被害のおそれ、不正の目的、1,000人超の4類型を報告対象に挙げ、報告は概ね3〜5日以内としています。段取りは個人情報保護委員会への報告義務の実務にまとめました。なお委員会のQ&A（Q6-14）は、銀行口座情報のみの漏えいは直ちに財産的被害の類型には当たらないと整理しています。同じQ&Aは、口座情報がインターネットバンキングのログインに使われていて、パスワードと一緒に漏えいした場合は該当するとしています。
設計に効くのはQ6-19のほうです。「高度な暗号化等の秘匿化」と言えるには、事案が起きた時点の技術水準で第三者が読めない暗号化に加えて、復号鍵の管理が要ります。具体的には、暗号化した情報と復号鍵を分離して鍵の漏えいを防ぐ、遠隔操作で削除できる、第三者が鍵を使えない設計にする、のいずれかです。OWASPの暗号化保存チートシートも、鍵とデータの分離を挙げています。
ただし、口座番号の列だけ暗号化しても、同じダンプに平文の要配慮個人情報があれば、そちらは報告対象に残ります。守る対象は列単位で棚卸しする必要があります。
口座番号を本体DBから分離しダンプの平文を検査するPythonのコードと実行結果
本体DBにトークンと下3桁だけを持たせ口座番号を保管庫へ移す最小のコード
次の例は、口座番号を別の保管庫DBに移し、本体DBには乱数のトークンと画面表示用の下3桁だけを残します。決済トークンの考え方を口座振替の情報に当てはめた形です。あわせて、実在しないダミーの口座番号を登録しておき、ダンプの中にその番号が現れないかを検査します。バックアップの処理に組み込めば、平文が混ざった時点でジョブを止められます。
# 口座番号を本体DBから分離し、ダンプに平文が残らないか検査する最小例（Python 3.9以上・標準ライブラリのみ）
import secrets, sqlite3
CANARY = "9990017" # 検査用に登録する、実在しないダミーの口座番号
app_db = sqlite3.connect(":memory:") # 本体DB（会員・予約）
vault_db = sqlite3.connect(":memory:") # 口座保管庫（別のDB・別の認証情報にする）
app_db.execute("CREATE TABLE before_fix (id TEXT, name TEXT, account_number TEXT)")
app_db.execute("CREATE TABLE after_fix (id TEXT, name TEXT, account_token TEXT, account_last3 TEXT)")
vault_db.execute("CREATE TABLE bank_accounts (token TEXT PRIMARY KEY, account_number TEXT NOT NULL)")
def store_account(member_id, name, account):
token = secrets.token_urlsafe(24) # 口座番号から計算できない乱数にする
vault_db.execute("INSERT INTO bank_accounts VALUES (?, ?)", (token, account))
app_db.execute("INSERT INTO after_fix VALUES (?, ?, ?, ?)",
(member_id, name, token, account[-3:]))
return token
def dump_text(db, table):
return "\n".join(line for line in db.iterdump() if table in line)
def has_plaintext(dump, canary=CANARY):
return canary in dump
def account_for_transfer(token):
"""口座振替のバッチだけが呼ぶ。予約画面の経路からは呼ばせない"""
row = vault_db.execute("SELECT account_number FROM bank_accounts WHERE token = ?",
(token,)).fetchone()
return row[0] if row else None
app_db.execute("INSERT INTO before_fix VALUES (?, ?, ?)", ("M0001", "テスト 太郎", CANARY))
token = store_account("M0001", "テスト 太郎", CANARY)
print("修正前の本体DBダンプに平文:", has_plaintext(dump_text(app_db, "before_fix")))
print("修正後の本体DBダンプに平文:", has_plaintext(dump_text(app_db, "after_fix")))
print("保管庫のダンプに平文:", has_plaintext(dump_text(vault_db, "bank_accounts")))
last3 = app_db.execute("SELECT account_last3 FROM after_fix").fetchone()[0]
print("画面に出す値:", "****" + last3)
print("振替バッチが得る値:", account_for_transfer(token))
print("不明なトークン:", account_for_transfer("unknown"))Python 3.14.10（Windows）で実行した結果です。
修正前の本体DBダンプに平文: True
修正後の本体DBダンプに平文: False
保管庫のダンプに平文: True
画面に出す値: ****017
振替バッチが得る値: 9990017
不明なトークン: None本体DBのダンプからは口座番号が消えました。一方で、3行目のとおり保管庫のダンプには平文が残ります。分離は持ち出される範囲を狭める手段で、暗号化の代わりにはなりません。
保管庫のバックアップを公開鍵で暗号化する手順と採用しない方式の判断基準
保管庫のバックアップは、公開鍵で暗号化してから保存します。バックアップを作るサーバーには公開鍵だけを置き、復号用の秘密鍵は別の場所に分ければ、そのサーバーを取られてもファイルは読めません。GnuPGなら受信者の鍵を指定する--recipientと--encryptを、ダンプのパイプの後段につなぐ形になります。このときBashのset -o pipefailを必ず入れてください。これが無いと、ダンプが途中で失敗しても最後の暗号化が成功した時点で全体が成功扱いになり、中身の欠けたファイルが正常なバックアップとして残ります。この段落の手順は公式ドキュメントに基づく説明で、上のPythonの例のように手元で実行したものではありません。
データベース内で暗号化するPostgreSQLのpgcryptoにはpgp_pub_encryptがあります。ただ、同じ文書は、データやパスワードがサーバーとの間を平文で移動すると注意しています。暗号化だけをDBで行うならまだしも、秘密鍵を渡してDBの中で復号する運用は採りません。復号は振替バッチの側に閉じ込めます。
判断は言い切れます。口座振替の情報を自社で持つなら、本体DBからの分離と保管庫の暗号化は、会員数の多少を問わず実施します。逆に、これから口座振替を始める数百人規模のサービスが自前の保管庫を作るのは過剰です。収納代行の事業者に口座情報を預け、自社は持たない構成を先に検討してください。持たないデータは漏れません。
公開領域のダンプと大きな応答を洗い出し検知までの13日間を縮める点検の実装
Web公開領域のダンプ検出とアクセスログの大きな応答を抜き出すPythonコード
ステップゴルフの事案でバックアップがどこに置かれていたかは公表されていません。ここからは自社の点検として、一般に起きやすい2つを確かめます。Webサーバーが配信する領域にダンプが残っていないか、アクセスログに不自然に大きな応答がないか、です。ログの形式は、Apacheなどの標準的な形式を想定しています。
# 公開領域に置かれたダンプと、アクセスログの大きな応答を洗い出す最小例（Python 3.9以上・標準ライブラリのみ）
import pathlib, re, tempfile
SUFFIXES = (".sql", ".sql.gz", ".dump", ".bak", ".tar.gz", ".zip")
THRESHOLD = 10 * 1024 * 1024 # 10MB。静的ファイルの実サイズを見て調整する
STATIC = (".jpg", ".png", ".webp", ".mp4")
LOG_LINE = re.compile(r'^(\S+) \S+ \S+ \[([^\]]+)\] "(\S+) (\S+) [^"]*" (\d{3}) (\d+)')
def exposed_backups(docroot):
root = pathlib.Path(docroot)
return sorted(p.relative_to(root).as_posix() for p in root.rglob("*")
if p.is_file() and p.name.lower().endswith(SUFFIXES))
def large_responses(lines):
for line in lines:
m = LOG_LINE.match(line)
if not m:
continue
ip, when, method, path, status, size = m.groups()
if status == "200" and int(size) >= THRESHOLD and not path.lower().endswith(STATIC):
yield f"{when} {ip} {method} {path} {int(size) // 1048576}MB"
# 以下は架空のファイルとログで動作を確かめる部分
with tempfile.TemporaryDirectory() as docroot:
for name in ["index.php", "css/style.css", "old/members_backup.SQL.gz", "db.bak"]:
target = pathlib.Path(docroot, name)
target.parent.mkdir(parents=True, exist_ok=True)
target.touch()
print("公開領域のダンプ:", exposed_backups(docroot))
sample = [
'203.0.113.5 - - [01/Oct/2026:03:12:01 +0900] "GET /index.php HTTP/1.1" 200 18234 "-" "curl"',
'203.0.113.9 - - [01/Oct/2026:03:14:44 +0900] "GET /tmp/db.tar.gz HTTP/1.1" 200 734003200 "-" "curl"',
'198.51.100.7 - - [02/Oct/2026:22:01:10 +0900] "GET /img/hero.mp4 HTTP/1.1" 200 52428800 "-" "Mozilla"',
'203.0.113.9 - - [02/Oct/2026:22:05:31 +0900] "POST /api/export HTTP/1.1" 200 52428800 "-" "curl"',
'203.0.113.9 - - [02/Oct/2026:22:06:02 +0900] "GET /tmp/none.zip HTTP/1.1" 404 512 "-" "curl"',
]
for hit in large_responses(sample):
print(hit)実行結果は次のとおりです。ログは動作確認用の架空のもので、IPアドレスは文書用の範囲を使っています。
公開領域のダンプ: ['db.bak', 'old/members_backup.SQL.gz']
01/Oct/2026:03:14:44 +0900 203.0.113.9 GET /tmp/db.tar.gz 700MB
02/Oct/2026:22:05:31 +0900 203.0.113.9 POST /api/export 50MB大文字の拡張子も検出され、404の応答と動画の配信は除外されました。ログの応答サイズは、圧縮の設定や転送方式によって実際のデータ量と差が出ます。しきい値を超えないよう小分けに持ち出す攻撃はこの方法では拾えないので、同じIPアドレスの応答サイズを日単位で合計する集計も併用します。
脆弱性の修正完了の後に侵入の有無まで確かめる順番と外部の診断を頼む条件
パッチの適用と、侵入されていないことの確認は別の作業です。修正版を入れても、それ以前に置かれた不正なファイルや持ち出されたデータは元に戻りません。緊急の更新が終わったら、脆弱性の公表より前までさかのぼってログを確かめ、公開領域のファイル一覧を前回の状態と比較します。
確かめる順番は、公開領域のダンプの有無、バックアップの保管場所と権限、口座番号など平文の列の棚卸し、ログの保持期間です。ログが数日で消える設定なら、13日前の侵入は調べようがありません。API経由の持ち出しへの備えはAPI不正アクセス対策の実装手順で扱っています。
会員の口座情報や要配慮個人情報を預かっていて、社内に本番の構成とバックアップ経路の両方を見られる担当者がいないなら、第三者の点検を入れる場面です。公開領域の露出と認可の抜けは脆弱性診断・セキュリティ診断で相談を受け付けています。
よくある質問
ステップゴルフの不正アクセスと情報漏えいについて、利用者から出やすい質問をまとめました。内容は11月9日時点の発表に基づきます。
無料体験に申し込んだだけでも情報は漏えいしていますか？
対象になる可能性があります。同社が発表した対象は、無料体験に申し込んだ人と、現在・過去の会員です。実際の漏えい件数と範囲は調査中で、人によって含まれる情報の種類は異なります。口座振替の登録をしていない人の口座情報がどう扱われているかは発表に書かれていないため、個別の連絡か続報で確認してください。
銀行の口座番号は変更したほうがいいですか？
第一報の時点で、口座番号の変更を求める案内はありません。同社は「口座番号と名義だけでは預金は引き出せません」と説明し、身に覚えのない引き落としがないかの確認を呼びかけています。まず入出金の明細を確かめ、異常があれば金融機関に連絡してください。金融機関を名乗る相手に暗証番号を伝えることは避けます。
ステップゴルフからのメールやSMSは本物ですか？
対象者にはメール等で個別に連絡すると発表されているため、連絡自体は届く可能性があります。ただし、本物に見えても記載のリンクは開かず、公式サイトのお知らせ欄と内容を突き合わせてください。暗証番号やパスワードの入力を求めるものには応じないでください。氏名や契約内容が正しくても、本物の証拠にはなりません。
クレジットカードの情報も漏えいしていますか？
同社は、クレジットカード情報と本人確認書類は当該システムで保有しておらず、影響はないとしています。カードの利用停止を求める案内も出ていません。一方で、銀行口座情報、住所、電話番号などは対象に含まれるため、カードを装った詐欺の連絡にも引き続き注意してください。見覚えのない請求があれば、カード会社に確認します。
問い合わせはどこにすればいいですか？
11月9日時点では専用窓口の設置準備中で、整い次第ホームページで案内されます。店舗では詳細な問い合わせに対応できないとして、店舗への連絡は控えるよう求められています。続報の目途は11月10日です。不審な連絡を受けて不安なときは、警察相談専用電話の#9110や消費者ホットラインの188に相談できます。
関連記事
- teket不正アクセス：全会員の氏名流出と入場方法、偽メールの確認手順：同時期の会員情報の流出と、発券コードの保存方式
- Maru-Jan不正アクセス：185万人のパスワード流出と変更・ポイント受取の手順：会員全件の持ち出しを防ぐ認可と強制変更
- futureshop不正アクセス：4サーバー停止と1店舗漏えい、店舗が今やる点検：同時期のサーバー停止と店舗側の点検項目
- PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版、悪用の実態と更新できない場合の設定【2026年10月】：修正版の版番号とログの確認範囲
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：会員データを扱うAPIの認可
