---
title: "マクロミルの不正アクセスで317名の情報が閲覧｜口座情報82名と管理機能を守る設計"
url: "https://www.issoh.co.jp/tech/details/19671/"
published: 2026-11-12
updated: 2026-11-12
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# マクロミルの不正アクセスで317名の情報が閲覧｜口座情報82名と管理機能を守る設計

マクロミルは2026年11月12日、モニタサイトの一部システムが第三者の不正アクセスを受け、317名分のモニタ情報が外部から閲覧された痕跡を確認したと公表しました。うち82名分には、ポイント交換の振込先口座情報が含まれます。全モニタを対象にポイント交換機能が止まっており、再開時期は未定です。本記事では、公式発表に沿って分かっている範囲と、モニタが今やる点検を整理します。後半では、管理機能を外から触らせない設定、閲覧の範囲を数えるログ、メールアドレスを書き換えられた後の交換を保留する処理をコードで示します。

## まとめ：マクロミルの不正アクセスで公表された事実とモニタ・開発者の対応

確定しているのは、10月29日に不正アクセスが確認されたこと、閲覧の痕跡があるのは317名分で、それ以外のモニタの情報には閲覧や流出の形跡が見つかっていないことです。カード情報と金融機関の暗証番号は保持していません。一部のアカウントで登録メールアドレスの書き換えとポイント交換の試みがありましたが、不正な交換の完了や不正ログインは確認されていません。

モニタが最初にやるのは、登録メールアドレスが自分のものかの確認です。開発者が点検したいのは、管理機能が社外から届く場所にないか、誰がどの会員を見たかを後から数えられるかの2点になります。

| 項目        | 公表されている内容   |
| --------- | ----------- |
| 不正アクセスの確認 | 2026年10月29日 |
| 閲覧の痕跡     | 317名分       |
| うち口座情報を含む | 82名分        |
| 金銭的な被害    | 確認されていない    |
| ポイント交換    | 全モニタで停止中    |
| 原因となった脆弱性 | 未公表         |

## 公表内容の整理｜10月29日の確認から11月12日の公表までに分かったこと

### モニタサイトの一部システムと管理機能への不正アクセスで起きたこと

[マクロミルのお知らせ（2026年11月12日）](https://www.macromill.com/press/info/20261112.html)は、対象を「マクロミル モニタサイトの一部システム」と書いています。対応の欄に記されているのは、該当する管理機能への外部からのアクセスを制限・遮断したという措置です。会員が使う画面ではなく、運営側が会員情報を扱う機能に外から手が届いたと読めます。

侵入の経路や悪用された脆弱性の種類は示されていません。本記事では製品名や手口を推測しません。分かっているのは、閲覧に加えて、登録メールアドレスの書き換えとポイント交換の操作が試みられた痕跡があることです。情報を見るだけでなく、換金につながる操作まで狙われていました。

### 閲覧された317名と振込先口座情報を含む82名、カード情報を持たない範囲

閲覧の痕跡がある情報は、基本情報と登録された属性情報です。82名分には振込先口座情報も含まれます。銀行名や口座番号などの個別項目は列挙されていません。クレジットカード情報と金融機関の暗証番号は、もともと保持していないと説明されています。

モニタ全体の規模に対して、閲覧の範囲を317名まで絞り込めている点は見逃せません。どの会員の画面が開かれたかが記録に残っていなければ、全件を対象として公表するしかなくなります。範囲の数え方は後の章でSQLにしました。

### 10月31日のメール配信委託先の停止は別件、交換停止が長引く理由

公表文は、互いに独立した2件の事象を並べています。もう1件は、10月31日に外部のメール配信委託先で不正アクセスによるサービス停止が起き、マクロミルからの一部のメールが届かなくなったものです。委託先の調査では、マクロミルに関する個人情報の漏えいは起きていないと報告されています。

交換停止にはこちらも関わっています。ポイント交換ではメールの送受信が必須で、それが正常に行えないことも停止を続ける要因との説明です。モニタサイトとアプリの両方で交換が止まっており、保有ポイントは停止に伴う失効などの不利益が出ないよう対応するとしています。

## マクロミルのモニタが今やる点検｜登録メールアドレスと偽の連絡の見分け方

### 登録メールアドレスが書き換えられていないかと口座情報の確認手順

一部のアカウントで登録メールアドレスの書き換えが試みられているため、まずログインして登録アドレスが自分のものかを確かめてください。見覚えのないアドレスになっていれば、ポイント交換の連絡がそちらへ届く状態です。すぐに問い合わせ窓口へ伝えます。

対象の317名には、不正利用を防ぐ措置をとったうえで個別に連絡するとしています。振込先口座を登録している人は、口座番号だけで預金が引き出されるわけではありません。ただ、口座番号と氏名が合っている偽の連絡は本物らしく見えます。問い合わせ先はモニタサポートのメール窓口で、登録メールアドレスから送るか、本文に登録アドレスを書くよう求められています。

### マクロミルを装うメール・SMS・電話とワンタイムパスワードの扱い

同社は、マクロミルを装った不審なメール、SMS、電話への注意を呼びかけています。ワンタイムパスワードやパスワードを他人に伝えないよう明記しています。「ポイント交換の再開手続き」や「口座情報の再登録」をうたう連絡は、リンクを開かず、公式サイトのお知らせから確かめてください。

電話でワンタイムパスワードを聞き出すのは、メールアドレスの変更やログインを本人になりすまして通すための手口です。届いた文面で入力させる仕組みは[フィッシング詐欺の成立の仕組みと実装者向けの対策](https://www.issoh.co.jp/tech/details/13548/)で解説しています。

## 管理機能を外から触らせない設計｜接続元の制限と閲覧ログで範囲を数える

### 管理画面をインターネットから切り離すnginxの接続元制限の設定例

今回の封じ込めの最初の手は、管理機能への外部アクセスの遮断でした。会員向けと同じドメイン・同じサーバーで管理画面を公開していると、ログイン画面の手前まで誰でも到達できます。到達できなければ、認証の抜けや脆弱性を突かれる機会そのものが減ります。

[nginxのngx\_http\_access\_module](https://nginx.org/en/docs/http/ngx%5Fhttp%5Faccess%5Fmodule.html)では、`allow`と`deny`が書いた順に評価され、最初に一致した規則が使われます。次は、管理画面のパスを社内ネットワークとVPNの出口だけに絞る設定例です。アドレスは説明用です。

```
# 管理画面は社内とVPNの出口からだけ受け付ける（上から順に評価される）
location /admin/ {
    allow 10.0.0.0/8;        # 社内ネットワーク
    allow 198.51.100.24;     # VPNの出口アドレス
    deny  all;               # それ以外はすべて403
    proxy_pass http://admin_backend;
}
```

`deny all`を先頭に書くと全員が拒否されるため、順番を入れ替えないよう注意します。本番では、管理画面を別のホスト名と別のサーバーに分け、会員向けの公開サーバーからは経路ごと届かない構成にする方が確実です。管理用エンドポイントをアプリ解析で見つけられる問題は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱いました。

### 閲覧監査ログで誰が誰の情報を見たかを残し、影響範囲を数える方法

[OWASPのLogging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging%5FCheat%5FSheet.html)は、機微なデータへのアクセスとアプリケーション管理者によるアクセスを記録すべきイベントに挙げています。一方で、銀行口座や決済カードのデータについては、ログへの直接の記録を避けるよう求める内容です。次の[Pythonのsqlite3](https://docs.python.org/3/library/sqlite3.html)だけで書いた例は、管理画面で会員を表示するたびに、誰が、どこから、どの会員の、どの列を見たかを残します。記録の対象は列名だけで、口座番号の値を残さない設計です。

```
# 管理画面の閲覧監査ログと、メールアドレス変更後の交換保留（Python標準ライブラリのみ）
import sqlite3
from datetime import datetime, timedelta

db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE members (id INTEGER PRIMARY KEY, email TEXT, bank_account TEXT, email_changed_at TEXT);
CREATE TABLE admin_view_log (id INTEGER PRIMARY KEY, admin_id TEXT, src_ip TEXT,
                             member_id INTEGER, fields TEXT, viewed_at TEXT);
""")
HOLD = timedelta(hours=72)  # メールアドレス変更後に交換を保留する時間

def admin_view(admin_id, src_ip, member_id, fields, now):
    # 画面に出す前に必ず記録する。口座番号の値はログに書かず、見せた列名だけを残す
    db.execute("INSERT INTO admin_view_log (admin_id, src_ip, member_id, fields, viewed_at) VALUES (?,?,?,?,?)",
               (admin_id, src_ip, member_id, ",".join(fields), now.isoformat()))
    email, account = db.execute("SELECT email, bank_account FROM members WHERE id=?", (member_id,)).fetchone()
    shown = {"email": email}
    if "bank_account" in fields:
        shown["bank_account"] = "****" + account[-3:]  # 管理画面でも下3桁だけ表示する
    return shown

def change_email(member_id, new_email, now, notify):
    old = db.execute("SELECT email FROM members WHERE id=?", (member_id,)).fetchone()[0]
    db.execute("UPDATE members SET email=?, email_changed_at=? WHERE id=?", (new_email, now.isoformat(), member_id))
    notify(old, "登録メールアドレスが変更されました。心当たりがなければ連絡してください")

def can_exchange(member_id, now):
    changed = db.execute("SELECT email_changed_at FROM members WHERE id=?", (member_id,)).fetchone()[0]
    if changed and now - datetime.fromisoformat(changed) < HOLD:
        return "保留（メールアドレス変更から72時間以内）"
    return "交換可"

# 検証用データ：会員1,000人、うち300人が振込先口座を登録
now = datetime(2026, 10, 29, 9, 0)
for i in range(1, 1001):
    db.execute("INSERT INTO members VALUES (?,?,?,NULL)",
               (i, f"mail-{i}", f"{i:07d}" if i <= 300 else None))
admin_view("staff01", "10.0.0.5", 500, ["email"], now)          # 社内からの通常業務
for i in range(1, 318):                                          # 外部から317人分を閲覧
    fields = ["email", "bank_account"] if i <= 82 else ["email"]
    last = admin_view("staff07", "203.0.113.10", i, fields, now + timedelta(seconds=i))
print(last, admin_view("staff07", "203.0.113.10", 1, ["email", "bank_account"], now))

# 調査：社外の送信元から閲覧された会員数と、そのうち口座情報まで表示された会員数
print(db.execute("""
SELECT COUNT(DISTINCT member_id),
       COUNT(DISTINCT CASE WHEN fields LIKE '%bank_account%' THEN member_id END)
  FROM admin_view_log
 WHERE src_ip NOT LIKE '10.%' AND viewed_at >= ?
""", (now.isoformat(),)).fetchone())

sent = []
change_email(1, "mail-attacker", now, lambda to, body: sent.append(to))
print(sent, can_exchange(1, now + timedelta(hours=1)), can_exchange(1, now + timedelta(hours=73)))
```

Python 3.14.10（SQLite 3.50.4）で実行すると、2行目に`(317, 82)`が出ます。社外の送信元から閲覧された会員が317人、そのうち口座情報まで画面に出た会員が82人という集計です。数値は公表文の件数に合わせた検証用のデータで、マクロミルが同じ仕組みで数えたという意味ではありません。

このログが無いと、閲覧された会員を絞り込めず、保有する全件を対象として扱うことになります。ログの保存先を分ける際の条件は、管理画面と同じ権限では消せない場所であることです。侵入後の痕跡をサーバー側のどのログで追うかは[不正アクセスの調べ方とログの確認方法](https://www.issoh.co.jp/tech/details/2788/)で整理しています。

### 口座番号は管理画面でも下3桁だけ表示し、ログには値を残さない設計

上のコードの1行目は`{'email': 'mail-317'} {'email': 'mail-1', 'bank_account': '****001'}`です。口座情報の列を求めた閲覧でも、画面に出るのは下3桁だけになります。振込の照合や問い合わせ対応なら、下3桁と名義で足りる場面がほとんどです。

全桁を見る必要がある業務は、振込データを作る処理など一部に限られます。その処理はバッチ側に置き、画面からは全桁を出さない形にすれば、管理画面が乗っ取られても読み出せる情報が減ります。データベースの権限を画面ごとに分ける設定は[Qzooの不正アクセスとSQLインジェクション対策](https://www.issoh.co.jp/tech/details/19019/)で、PostgreSQLの列単位GRANTとして示しました。

## メールアドレス書き換えからポイント交換を狙う手口と保留期間の実装

### 旧アドレスへの通知と72時間の交換保留をPythonで書く手順と実行結果

公表文には、登録メールアドレスの書き換えとポイント交換の試みが並んで書かれています。交換の連絡がメールで届くサイトでは、アドレスを自分のものに変えられれば、本人に気付かれないまま交換を進められます。

[OWASPのAuthentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication%5FCheat%5FSheet.html)は、登録メールアドレスの変更時に、旧アドレスへ変更の予告と想定外の操作を報告するリンクを送り、新アドレスでは変更の確認を求める手順を示しています。上のコードの`change_email`は、変更と同時に旧アドレスへ通知を送り、`can_exchange`は、変更から72時間にわたり交換を保留する処理です。3行目の出力は`['mail-1'] 保留（メールアドレス変更から72時間以内） 交換可`で、通知は旧アドレスに届き、1時間後は保留、73時間後に交換できます。

保留の72時間は、本人が旧アドレスの通知に気付いて連絡できる猶予として置いた値です。週末をまたぐと気付くまでに2日かかる人もいるため、48時間より短くはしない方が無難です。換金できる機能そのものを止めるスイッチと流量での自動停止は、[infoQの不正アクセスとポイント交換を止める設計](https://www.issoh.co.jp/tech/details/18164/)でコードにしています。

### 交換の本人確認をメール1経路に頼ると委託先の停止で交換も止まる問題

マクロミルでは、ポイント交換に必須のメールが委託先の停止で届かず、それが交換停止を続ける要因の1つになっています。本人確認の手段がメール1本だと、配信事業者が止まった時点で、正規の会員も交換できなくなります。

対策は、確認の経路を2本持つことです。メールに加えて、SMSや認証アプリのワンタイムパスワード、パスキーのいずれかを登録できるようにし、どちらでも本人確認を通せるようにします。メール配信の委託先も、障害時に切り替えられる2社目の設定を用意しておくと、停止期間を短くできます。

## 採用の判断と報告の実務｜会員サイトの管理機能を点検する順番と期限

### 接続元制限と閲覧ログを先に入れるべきサイトの条件と過剰になる場面

会員の口座情報や住所を持っている、管理画面が会員向けと同じドメインで公開されている、管理画面での閲覧が記録されていない。この3つのうち1つでも当てはまるなら、接続元の制限と閲覧ログを先に入れるべきです。どちらも、侵入を受けた後に被害の範囲を狭く確定させるための仕組みだからです。

反対に、管理画面がすでに社内ネットワークからしか届かず、扱う会員情報がメールアドレスとニックネームだけなら、列単位の閲覧ログまで作り込むのは過剰です。画面単位のアクセスログと、メールアドレス変更時の旧アドレス通知で足ります。

### 317名でも報告対象になる不正目的の類型と速報・確報の提出期限

[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、本人の数が1,000人を超える漏えい等のほか、不正の目的をもって行われたおそれがある行為による漏えい等も報告の対象です。第三者の不正アクセスによる閲覧は後者にあたるため、317名でも報告が必要になります。速報は発覚から3〜5日以内、不正目的の場合の確報は60日以内とされています。

マクロミルは個人情報保護委員会とプライバシーマークの審査機関へ速報を済ませたとしています。人数が少ないから報告しなくてよい、という判断は不正アクセスでは成り立ちません。類型の見分け方と報告の書き方は[個人情報保護委員会への報告義務と速報・確報の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。

### 自社の管理機能と口座情報の持ち方を第三者の目で点検する依頼の進め方

点検で確認する順序は、次に示すとおりです。最初に、管理画面のURLに社外の回線からアクセスし、ログイン画面が表示されるかを確かめます。次に洗い出すのは、画面とログの中で口座番号が全桁で出ている箇所です。最後に、メールアドレスの変更から交換までを、本人以外が通せないかを試します。

社内の担当者は自分たちの構成を前提に見てしまうため、管理機能の露出やアカウント変更の抜けは外部の目で確かめる方が見つかりやすい領域です。[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)では、公開範囲の確認からアカウント変更の手順の検証まで含めて点検できます。

## よくある質問

マクロミルの不正アクセスについて、モニタと開発者から出やすい質問をまとめました。

### マクロミルの不正アクセスで自分の情報は漏えいしましたか？

閲覧の痕跡が確認されたのは317名分で、それ以外のモニタの情報には閲覧や流出の形跡は確認されていないと公表されています。対象の317名には、不正利用を防ぐ措置をとったうえで個別に連絡するとしています。連絡は順次進められているため、まだ届いていなくても対象外とは限りません。気になる場合は、登録メールアドレスからモニタサポートの窓口に問い合わせてください。

### マクロミルのポイント交換はいつ再開しますか？

11月12日時点で再開時期は未定です。システムの改修と安全性の検証を進め、目途が立った時点でサイトで知らせるとしています。メール配信委託先の停止で交換に必要なメールが届かないことも、停止が続く要因に挙げられています。

### 停止中にポイントが失効することはありますか？

マクロミルは、交換機能の停止に伴って保有ポイントの失効などの不利益が生じないよう対応するとしています。具体的な延長の方法は示されていないため、公式のお知らせで続報を確認してください。

### 振込先口座の番号が漏れたら預金を引き出されますか？

口座番号と名義だけで預金を引き出すことはできません。マクロミルは金融機関の暗証番号を保持しておらず、本件による金銭的な被害も確認されていません。注意したいのは、口座情報が正しく書かれた偽の連絡で、暗証番号やワンタイムパスワードを聞かれても答えないことです。

### マクロミルの問い合わせ窓口はどこですか？

公表文が案内しているのはモニタサポートのメール窓口です。登録メールアドレスから送るか、本文に登録アドレスを書くよう求められています。窓口のアドレスはお知らせの本文で確かめ、届いたメールに書かれた連絡先は使わないでください。

## 関連記事

- [infoQの不正アクセスで89万件持ち出し｜ログインできない理由・退会・補填とポイント交換を止める設計](https://www.issoh.co.jp/tech/details/18164/)：アンケートサイトのポイント交換を狙われた事例と停止スイッチ
- [Qzooにログインできない理由：不正アクセスで約40万件が対象、会員の対処とSQLインジェクション対策](https://www.issoh.co.jp/tech/details/19019/)：口座情報を持つアンケートサイトの事例とDB権限の分離
- [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：管理用エンドポイントを外から見つけさせない実装
- [不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例](https://www.issoh.co.jp/tech/details/2788/)：侵入後の痕跡を追うログの見方
- [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：不正アクセスで報告が必要になる類型

---

出典: [マクロミルの不正アクセスで317名の情報が閲覧｜口座情報82名と管理機能を守る設計](<https://www.issoh.co.jp/tech/details/19671/>)（株式会社一創）