エムスリー不正アクセスでMR君から医師情報が漏えい｜対象確認と会員DBの経路分離

エムスリー株式会社は2026年10月15日、製薬企業向けサービス「MR君」のシステムに第三者の不正アクセスがあり、一部の医師会員と製薬企業の担当者の氏名・勤務先などが外部に漏えいしたと公表しました。ログインパスワードとm3ポイントは含まれていません。本記事では、m3.comの会員と製薬企業の担当者が確かめることを公式発表の文言で先に示し、10月21日に公表されたStudio経由の別事案との違いを整理します。後半では、法人向けの機能から会員の情報に届く経路を分ける設定と、アクセスログから対象人数を確定する手順を、実行できるコードで解説します。

まとめ：エムスリー「MR君」不正アクセスで公表された事実と会員の対応

エムスリーの10月15日の公式発表で確定している事実は次のとおりです。不正アクセスと漏えいは10月14日に同日中に確認され、判明している経路は遮断済みです。原因と対象人数は調査中で、2026年10月22日時点で続報は出ていません。

対象の医師会員は全体の1割未満で、製薬企業の担当者は数百名規模です。不特定多数への公開や不正利用については、その事実が確認されていないという公表内容です。

会員がすぐやることは2つだけです。エムスリーを装う連絡に応じないことと、m3.comと同じパスワードを他のサービスで使っているなら替えておくことです。対象かどうかは、エムスリーから順次届く案内で分かります。

m3.com会員と製薬企業の担当者が確かめる4点｜通知・パスワード・偽連絡・窓口

自分が対象かは順次届く案内で分かる・人数が非公表の間にできること

公式発表は、対象となる人に順次案内するとしています。人数と情報の詳細は精査中で、判明しだい続報で知らせる方針です。案内が届く前に自分から照会する手順は示されていないため、今は待つことになります。

待つ間にできるのは、自分のm3.comの登録内容を確かめることです。勤務先とメールアドレスがどの組み合わせで登録されているかを把握しておくと、後から届く連絡が登録情報を知っている者からのものかを判断しやすくなります。

パスワード変更は求められていないが使い回しているなら替える判断

ログインパスワードは漏えいした情報に含まれていないため、公式発表はパスワードの変更を求めていません。ただし、メールアドレスが漏れた人は、同じアドレスとパスワードの組み合わせを試すログインの標的になりえます。m3.comのパスワードを他のサービスと共用しているなら、他のサービス側を別の値に替えてください。

m3ポイントも対象外と明記されています。ポイントの残高や交換履歴に身に覚えのない動きがあれば、本件と結び付けず、まず窓口に知らせることが先です。

エムスリーを装う連絡の見分け方と氏名・勤務先が揃うと起きる手口

公式発表は、エムスリーを装う不審なメール、SMS、電話に注意するよう求めています。氏名と勤務先が揃うと、「○○病院の○○先生」と本人しか知らないはずの宛名で連絡でき、文面の信用度が上がるため、宛名だけで本物かどうかを判断するのは危険です。製薬企業の担当者の名前を名乗り、講演会の案内や資料送付を口実にリンクを踏ませる形が考えられます。

見分ける基準は、メールの中のリンクから操作しないことに尽きます。案内が本物かどうかは、自分でm3.comを開いて確かめてください。添付ファイルとリンクで行動させる手口の全体像は標的型攻撃メールの見分け方で解説しています。

会員はm3.com窓口・製薬企業はエムスリー担当者からの連絡を待つ

問い合わせ先は、医師会員か製薬企業の担当者かという立場ごとに別の窓口です。医師会員はm3.comカスタマーサポートのお問い合わせから連絡します。製薬企業の担当者には、エムスリーの担当者から順次連絡するとされています。自社が対象か社内で判断がつかない製薬企業は、取引のある担当者経由で確かめるのが確実です。

10月15日のMR君事案と10月21日のStudio経由事案を混同しない整理

漏えいの起点・対象サイト・人数で分かれる2つの公表の違いを表で比較

エムスリーは10月21日にも個人情報の漏えいの可能性を公表しました。こちらは同社が使っていたWeb制作ツール「Studio」への不正アクセスが起点で、MR君とは別の事案です。10月21日の公式発表は、本件に関連して同社のシステムへの不正アクセスは確認されていないとしています。

M3PSPや1人1円ファンドのフォームから問い合わせた覚えがない医師会員は、21日の事案の対象ではありません。Studio側の経緯と、フォームの送信内容まで流出の可能性がある理由はStudioの公式発表と、Studio不正アクセスで利用者が替えるAPIキーとWebhook URLの記事で整理しています。

製薬企業向け機能から医師会員の情報に届く構成と経路分離の実装

MR君は製薬企業がm3.com上で医師へ情報を届ける仕組み・公表の範囲

エムスリーのサービス一覧は、MR君を、m3.comの特性を生かして製薬企業の薬剤プロモーションを支援し、製薬企業のMRが医療情報を医師に届けるサービスと説明しています。利用者は医師会員と製薬企業の2種類で、会員サイトの医師情報と、法人顧客が使う配信の機能が同じサービスの中でつながる構成です。

不正アクセスがどの機能のどの弱点から入ったのかは公表されていません。以下は原因の推定ではなく、医師会員と法人顧客の両方を抱える基盤で一般に点検すべき経路の話です。会員サイトと法人向け機能を同じデータベースで支える構成は、医療に限らず人材・不動産・教育のプラットフォームでも珍しくありません。

法人ユーザーが自社の配信対象だけを読めるか確かめるBOLAの観点

法人向け機能から会員情報が漏れる典型は、要求に含まれる会員IDを書き換えると他社の対象者まで読めてしまう不備です。OWASP API Security Top 10 2023のAPI1はこれをBOLA（Broken Object Level Authorization）と呼び、IDを受け取るすべてのエンドポイントで、その利用者がそのレコードを扱えるかを確かめる認可を求めています。

同じ文書は、セッションの利用者IDと要求のIDを比べるだけでは足りないとも書いています。法人顧客の場合は「ログイン中の担当者の会社が、この医師を配信対象に持つか」まで照合する必要があります。連番IDを推測しにくい値に替えるのは補助策で、認可の代わりにはなりません。レート制限やトークン失効を含むAPI側の守り方はAPI不正アクセス対策の実装手順にまとめています。

PostgreSQLの行レベルセキュリティで会社ごとに医師情報を絞る設定例

アプリケーションの認可を1か所でも書き漏らすと、そのエンドポイントから全件が読めます。データベース側でも会社ごとに行を絞っておけば、書き漏らしがあっても見える範囲は自社の対象者に限られます。PostgreSQL 18の行セキュリティポリシーのドキュメントによると、行レベルセキュリティを有効にしてポリシーが無い表は、既定で1行も見えません。

-- 法人向け機能の接続ロール pharma_app には、自社の配信対象医師だけを見せる
ALTER TABLE doctor_profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE doctor_profiles FORCE ROW LEVEL SECURITY;   -- 表の所有者にも適用する

CREATE POLICY pharma_target_only ON doctor_profiles
  FOR SELECT
  TO pharma_app
  USING (
    EXISTS (
      SELECT 1 FROM delivery_targets t
      WHERE t.member_id  = doctor_profiles.member_id
        AND t.company_id = current_setting('app.company_id')
    )
  );

-- アプリはトランザクションごとにログイン中の担当者の会社IDを設定する
BEGIN;
SET LOCAL app.company_id = 'A';
SELECT member_id, name, workplace FROM doctor_profiles;  -- 会社Aの対象医師だけが返る
COMMIT;

ドキュメントは、スーパーユーザーとBYPASSRLS属性を持つロールは常にポリシーを素通りし、表の所有者も通常は素通りすると説明しています。夜間バッチや管理画面が所有者のロールで接続していると、そこが抜け道になります。FORCE ROW LEVEL SECURITYを付け、法人向け機能には所有者でも特権でもない専用ロールを割り当ててください。配信対象の表をpharma_appが書き換えられると絞り込みが崩れるため、delivery_targetsへの書き込み権限も与えません。この例は構成を示すためのもので、本記事ではPostgreSQLでの実行までは確かめていません。

漏えい範囲を人数で確定する会員別アクセスログ照合と報告期限の関係

「1割未満」「数百名規模」を人数に変えるのに必要なログの粒度

公表が人数でなく割合と規模で書かれているのは、どの会員の情報が読まれたかを1件ずつ照合している段階だからと読めます。照合には、要求ごとに「いつ・どのセッションが・どの会社として・どの会員のレコードを返したか」が残っている必要があります。エンドポイントとステータスコードだけのアクセスログでは、一覧画面で何人分が返ったかが分かりません。

返したレコードのIDまで残すと、ログ自体が個人に結び付く情報になります。保管先の改ざん防止と閲覧権限を、本体のデータベースと同じ水準で設計してください。転送の欠損と改ざんを防ぐ保管の作りはFluentdで監査ログ基盤を作る手順で扱っています。

不正なセッションが読んだ会員を種別ごとに数えるPythonと実行結果

次のスクリプトは、不正と判定したセッションのログから、読まれた会員を医師と製薬企業の担当者に分けて重複なく数えます。同時に出力するのは、メールアドレスの登録がある人数と、ログイン中の会社の配信対象ではない会員の人数です。後者が0でなければ、他社の対象者まで読まれたBOLA型の漏れを疑う材料になります。Python標準のsqlite3だけで動き、scope_count.pyとして保存して実行します。

import sqlite3

# 不正と判定したセッションが読んだ会員を、種別ごとに重複なく数える
db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE members (member_id INTEGER PRIMARY KEY, kind TEXT, has_email INTEGER);
CREATE TABLE targets (company_id TEXT, member_id INTEGER);  -- 製薬企業ごとの配信対象医師
CREATE TABLE access_log (ts TEXT, session_id TEXT, company_id TEXT, member_id INTEGER);
""")
db.executemany("INSERT INTO members VALUES (?,?,?)",
    [(i, "doctor" if i <= 8 else "pharma_staff", 0 if i % 3 == 0 else 1) for i in range(1, 11)])
db.executemany("INSERT INTO targets VALUES (?,?)", [("A", 1), ("A", 2), ("B", 3), ("B", 4)])
db.executemany("INSERT INTO access_log VALUES (?,?,?,?)", [
    ("2026-10-14T09:00", "s-normal", "A", 1),   # 自社の対象医師を読む正常な参照
    ("2026-10-14T10:00", "s-bad", "A", 1),
    ("2026-10-14T10:01", "s-bad", "A", 3),      # 他社Bの対象医師
    ("2026-10-14T10:01", "s-bad", "A", 5),      # どの会社の対象でもない医師
    ("2026-10-14T10:02", "s-bad", "A", 5),      # 同じ会員の再読込は1人と数える
    ("2026-10-14T10:03", "s-bad", "A", 9),      # 製薬企業の担当者
])
SUSPECT = ("s-bad",)
q = f"""
SELECT m.kind,
       COUNT(DISTINCT l.member_id)                                    AS 人数,
       COUNT(DISTINCT CASE WHEN m.has_email = 1 THEN l.member_id END) AS メールあり,
       COUNT(DISTINCT CASE WHEN t.member_id IS NULL THEN l.member_id END) AS 自社対象外
FROM access_log l
JOIN members m ON m.member_id = l.member_id
LEFT JOIN targets t ON t.company_id = l.company_id AND t.member_id = l.member_id
WHERE l.session_id IN ({",".join("?" * len(SUSPECT))})
  AND l.ts BETWEEN '2026-10-14T00:00' AND '2026-10-14T23:59'
GROUP BY m.kind ORDER BY m.kind
"""
print("種別          人数  メールあり  自社対象外")
for kind, n, mail, cross in db.execute(q, SUSPECT):
    print(f"{kind:12} {n:5} {mail:10} {cross:10}")

2026年10月22日にPython 3.14.7（SQLite 3.50.4）で実行した結果です。ログの行は5行ありますが、同じ医師の再読込を1人と数えるため医師は3人になります。

$ python scope_count.py
種別          人数  メールあり  自社対象外
doctor           3          2          2
pharma_staff     1          0          1

実運用では、SUSPECTに入れるセッションの選び方で人数が大きく変わります。不審な接続元や異常な件数の参照から始め、同じ認証情報が使われた別のセッションへ広げていく順で確定させます。

ログで追えない期間や項目を「おそれ」として数える判断と報告期限

ログが残っていない期間や項目は、読まれていないと証明できません。その分は漏えいの「おそれ」として対象に含めて数えるのが安全側の判断です。個人情報保護委員会の漏えい等の対応ページは、不正の目的をもって行われたおそれがある行為による漏えいを報告対象の類型に挙げ、速報は発覚日から3〜5日以内、確報は30日以内、不正な目的のおそれがある場合は60日以内としています。

エムスリーの公式発表も、監督官庁への報告など必要な対応を進めているとしています。人数の確定を待たずに速報を出し、確報までにログ照合で人数を詰める流れです。類型ごとの判断と様式の書き方は個人情報保護委員会への報告義務で整理しています。

会員情報を法人顧客に見せる基盤で今週点検する事業者と過剰な事業者

法人向け管理画面とAPIが会員テーブルに直接届く構成の事業者

会員サイトと法人顧客向けの管理画面・APIを同じデータベースで動かしている事業者は、今週中に次の3点を確かめてください。法人向けの全エンドポイントで、会員IDを他社の対象者に書き換えた要求が拒否されること。法人向け機能のデータベース接続が、所有者や特権のロールでないこと。不正が起きたときに、返したレコードのIDまでログから引けることです。

3点目が満たせないと、事故のあとに人数を確定できず、本人への通知も報告も「おそれ」の広い範囲で出すことになります。会社ごとのデータの分け方はシングルテナントとマルチテナントのテナント分離も参考にしてください。他社IDへの書き換えは自社の開発者ほど見落としやすい観点なので、脆弱性診断・セキュリティ診断で第三者に法人向けAPIの認可を試させるのが近道です。

会員情報を外部の法人に見せない単一用途のサービスで過剰な対応

会員が自分の情報だけを見る通販や予約のサイトで、法人顧客向けの画面が無いなら、行レベルセキュリティの導入は過剰です。この構成で先にやるべきは、会員本人のIDを他人のIDに替えた要求を拒否できるかの確認と、パスワードの使い回し攻撃への備えです。対策の重さは、会員情報を誰に見せているかで決まります。

よくある質問

エムスリーのMR君への不正アクセスについて、医師会員と製薬企業の担当者から出やすい質問をまとめました。

m3.comのパスワードは変更したほうがよいですか？

公式発表ではログインパスワードは漏えいした情報に含まれておらず、変更は求められていません。ただし同じパスワードを他のサービスでも使っているなら、そちらは別の値に替えてください。メールアドレスが漏れた人は、そのアドレスで他のサービスへのログインを試される可能性があるためです。m3.comのパスワードを替えること自体に不都合はありません。

自分の情報が漏れたかどうかはどうすれば分かりますか？

エムスリーは対象となる人に順次案内するとしており、その案内で分かります。2026年10月22日時点で人数は公表されておらず、自分から照会する手順も示されていません。気になる医師会員はm3.comカスタマーサポートのお問い合わせから、製薬企業の担当者はエムスリーの担当者経由で確かめてください。案内を名乗るメールのリンクは使わないでください。

m3ポイントが勝手に使われる心配はありますか？

公式発表は、保有するm3ポイントは漏えいした情報に含まれないと明記しています。クレジットカード番号等はエムスリーが保持していない情報です。とはいえ、身に覚えのないポイントの交換や利用を見つけた場合は、公式発表の窓口に連絡するよう案内されています。本件と関係があるかどうかの判断は、会員側でせず窓口に任せてください。

10月21日に公表された271名と127名の件はMR君と同じ事案ですか？

別の事案です。10月21日の公表は、エムスリーがM3PSPと1人1円ファンドのWebサイト運営に使っていたStudioへの不正アクセスが起点で、両サイトのフォームに入力した人が対象です。エムスリー自身のシステムへの不正アクセスは確認されていないとしています。MR君の事案の人数は、10月22日時点でまだ公表されていません。

不正アクセスの原因は分かっていますか？

2026年10月22日時点では公表されていません。公式発表は原因を詳細に調査中としており、判明している経路は遮断して監視を続けているとしています。報道や解説で原因を特定したように書かれていても、公式の続報が出るまでは推測と考えてください。続報は、エムスリーのコーポレートサイトのお知らせに掲載されます。

関連記事

• Studio不正アクセスで全顧客の情報流出か｜パスワード・APIキー・Webhook URLを今日替える手順：エムスリーの10月21日公表の起点になった事案
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：法人向けAPIの認可と失効の実装
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時の報告の段取り
• Fluentdで監査ログ基盤を作る｜欠損させない転送設定と改ざん防止の保管【v1.19】：範囲特定に使えるログの残し方
• 標的型攻撃とは？手口の種類と標的型攻撃メールの見分け方・多層防御による対策を解説：氏名と勤務先を使う偽連絡への備え