2026.10.24 セキュリティ

カプコン不正アクセス：CAPCOM ID 1,177万件漏えいと196件の乗っ取りへの対処

カプコンは2026年10月22日、オンライン会員サービス「CAPCOM ID」に第三者による不正アクセスがあり、メールアドレスなど1,177万4,247件（全世界合計）が漏えいしたと公表しました。翌23日の第二報では、パスワードを不正に変更された196件のうち19件で、通販サイト「イーカプコン」のマイページから住所や購入履歴まで漏れたことが追加で判明しています。本記事の前半は、公式発表で確認できる件数・項目・時系列と、利用者が今日確かめることの整理です。後半では会員基盤を作る開発者に向けて、共通アカウントのパスワード変更経路と、連携サービスが個人情報を表示する前の再認証をコード例で示します。

まとめ：カプコン不正アクセスで公表された事実と、利用者・開発者が今日やること

漏えいの中心はメールアドレスとログイン履歴の識別情報で、利用者が設定したパスワードとクレジットカード情報は対象外とされています。一方で196件はパスワードが書き換えられ、そのうち19件は共通アカウント経由でイーカプコンの登録情報まで読まれました。

項目	公表されている内容（2026年10月24日時点）
痕跡の発見	2026年10月19日
公表	10月22日（第一報）、10月23日（第二報）
メールアドレス等	11,774,247件（全世界）
生年月日・性別等	上記のうち43件
パスワード不正変更	上記のうち196件（リセット済み）
イーカプコンの漏えい	196件のうち19件（日本国内）
対象外	利用者設定のパスワード、カード情報
専用窓口（日本）	0120-801-271（10時〜20時）

利用者がまずやることは2つです。カプコンを名乗るメール・SMS・電話のURLや添付を開かないこと。マイページでパスワードを替え、認証アプリによる二要素認証を設定することです。開発者が持ち帰る教訓は、共通IDのパスワード変更には現在の認証情報を求め、連携サービスは住所や購入履歴を出す前にもう一度ログインを求める、という2点に尽きます。

公式発表で確かめるCAPCOM ID漏えいの件数・項目・時系列と第二報の追加分

1,177万4,247件の漏えい項目と、43件・196件・19件の入れ子の関係

10月22日の第一報が挙げる漏えい項目は、メールアドレスとシステム固有の識別情報です。識別情報の中身はアカウント作成日時、最終ログイン日時、ログイン回数、最終ログイン時のクライアントIPの4つで、件数は11,774,247件とされました。CAPCOM IDはカプコンのWebサービスや一部のオンラインゲームで使う共通アカウントのため、国をまたいだ件数になっています。

数字は足し算ではなく入れ子で読みます。43件は1,177万件のうち生年月日・性別・国と地域・ニックネームまで漏れたもの、196件は同じく1,177万件のうちパスワードが不正に変更されたものです。10月23日の第二報は、その196件のうち19件でイーカプコンのマイページに不正アクセスがあったと公表しました。

19件で漏れたのは、氏名と氏名（カナ）、電話番号、郵便番号、住所、性別、生年月日、購入履歴、イーカプコンへの問い合わせ履歴、会員アドレス帳です。会員アドレス帳には、贈り物の送り先として登録した家族や知人の住所が入っている場合もあります。クレジットカード情報は第二報でも対象外とされ、ほかのアカウントではパスワード変更による漏えいは確認されなかったとしています。

10月19日の痕跡発見から10月23日の第二報まで5日間の時系列と報告先

10月19日：不正アクセスの疑いがある痕跡を発見し、アクセスを遮断。同日に不正アクセスを確認し、緊急対策と攻撃手段の特定に着手
10月20日：社内に対策本部を設置。登録情報の一部の漏えいと、一部アカウントの不正なパスワード変更を確認し、外部の助言組織であるセキュリティ監督委員会へ報告
10月21日：警察と個人情報保護委員会へ報告
10月22日：第一報を公表し、専用窓口を設置。対象者への個別連絡を順次開始
10月23日：第二報でイーカプコン19件の漏えいを公表し、影響範囲の調査完了を表明

発見から公表まで3日、第二報まで4日という間隔です。ゲームのプレイへの影響は無く、CAPCOM IDを使うサービスは引き続き使えるとしています。攻撃手段は「特定と対応を完了」とだけ書かれ、侵入経路やパスワードが変更された仕組みは公表されていません。

2020年のランサムウェア被害（旧型VPN経由）と今回の事案を分けて読む視点

「カプコン不正アクセス」で検索すると、2020年11月の事案の記事も多く表示されます。2021年4月13日の調査結果（第4報）によると、当時は北米現地法人が予備として残していた旧型VPN装置が攻撃を受け、社内ネットワークに侵入されてランサムウェアでファイルを暗号化されました。流出が確認された個人情報は累計15,649人で、取引先や社員などが中心です。

今回は、会員向けの共通アカウントそのものが標的になった別の事案です。第一報が報告先に挙げた「セキュリティ監督委員会」は、2020年の事案を受けて2021年1月下旬に発足した組織にあたります。報道記事を読むときは、日付が2026年10月かどうかを最初に確かめると取り違えを防げます。

CAPCOM IDの利用者が確かめることと、届いた連絡が本物かを見分ける手順

0120-801-271の専用窓口と、個別連絡・SMS・電話を装う連絡の見分け方

第一報と第二報のPDFが日本向けに記載している窓口は「CAPCOM ID 不正アクセス専用お問い合わせ窓口」で、フリーダイヤル0120-801-271、受付は10時から20時です。北米・中南米と欧州・中東・アフリカはカプコンのサポートサイトのフォーム、アジア（日本を除く）とオセアニアはメールで受け付けています。

カプコンは対象者に順次個別に連絡するとしています。同時に第二報は、漏えい情報を悪用してカプコンや関係先を装ったSMS・電話・メールが届く可能性を挙げました。届いた連絡が本物か迷ったら、連絡に書かれたURLや電話番号ではなく、カプコン公式サイトのIRニュースから辿った番号へ自分でかけ直します。パスワードや認証コード、カード番号を電話やメールで聞かれたら、その時点で偽物を疑ってください。偽の連絡の典型的な手口はフィッシングの手口の種類と見分け方にまとめています。

パスワードの再設定と認証アプリによる二要素認証をマイページで設定する手順

パスワードの漏えいは確認されていないものの、メールアドレスとログイン履歴は1,177万件規模で外に出ました。同じメールアドレスと同じパスワードをほかのサービスでも使っている場合は、CAPCOM ID以外のパスワードも替える対象です。

公式サイト（cid.capcom.com）からログインし、マイページを開く。ログインできない場合はログイン画面の「パスワードをお忘れですか？」から再設定する
パスワードを、ほかのサービスで使っていない文字列に変更する
スマートフォンにGoogle AuthenticatorやMicrosoft Authenticatorなどの認証アプリを入れる
マイページで二要素認証を設定し、ログインのたびに認証アプリのコードを求める状態にする

手順はCAPCOM IDのサポートページの記載に沿って整理したものです。同ページは、機種変更の前に現在の端末で二要素認証を解除しておかないとログインできなくなるおそれがあると注意しています。二段階認証と二要素認証の違いは二段階認証と二要素認証・多要素認証の違いで解説しています。

共通アカウント1つの乗っ取りが通販マイページの住所・購入履歴まで届いた構造

パスワード漏えいなしで196件が変更された事実から言える設計上の論点

第一報には、利用者が設定したパスワードの漏えいは確認されていない一方、196件でパスワードが不正に変更されていたと書かれています。攻撃者が元のパスワードを知らないまま新しいパスワードを設定できた可能性があり、その場合はパスワード変更か再設定の経路そのものが突かれたことになります。どの経路だったかはカプコンが公表しておらず、本記事も特定しません。

ここから言えるのは、ログイン画面の守りとは別に、パスワードを書き換える処理にも独立した守りが要るという点です。ほかのサイトで漏れたIDとパスワードを流し込む攻撃なら元のパスワードで入れるため、ログイン試行の検知が効きます。その手口と検知の指標はパスワードリスト攻撃の検知とレート制限の実装で扱いました。変更処理の側を突かれた場合は、ログイン失敗の監視には何も残りません。

共通IDで連携サービスへ入れる範囲と、19件だけが通販側で漏れた意味

CAPCOM IDのパスワードを握った攻撃者は、同じIDでログインできるイーカプコンのマイページにも入れました。共通アカウント（シングルサインオン）は利用者には便利ですが、1つのIDの乗っ取りが、そのIDでつながる全サービスの登録情報への入口になります。この性質はシングルサインオンのデメリットとID漏えいの被害拡大でも整理しています。

196件のうち19件だけでイーカプコンの情報が漏れたのは、イーカプコンに住所などを登録していたアカウントが一部だったためと読めます（カプコンは理由を説明していません）。連携サービス側でできた防御は、住所や購入履歴の画面を開く直前に、直近のログインかどうかを確かめることでした。共通IDの認証が通っていても、表示する情報の重さに応じてもう一度本人確認を求める設計です。実装は後の章で示します。

パスワード変更・再設定の経路を締める実装：再認証・通知・セッション失効

OWASPが求める現在のパスワード確認と、変更完了を旧アドレスへ知らせる通知

OWASPのAuthentication Cheat Sheetは、パスワード変更機能の要件として、有効なセッションでログインしていることと、現在のパスワードの確認を挙げています。メールアドレスなどの登録情報を書き換える前にも、現在の認証情報を求めるよう書いています。セッションを盗まれただけの攻撃者に、パスワードを書き換えさせないための要件です。

通知も同じくらい効きます。パスワードやメールアドレスが変わったら、変更前のメールアドレスへ「変更されました。心当たりが無ければ窓口へ」と送ります。本人が気づけば、乗っ取られたアカウントを数時間で取り戻せます。実務で最初に入れるのは、現在のパスワード確認と変更通知の2つです。

再設定トークンの単回使用と、変更後に全セッションと再設定リンクを失効させる処理

パスワードを忘れた人向けの再設定は、現在のパスワードを求められない経路です。OWASPのForgot Password Cheat Sheetは、再設定トークンを暗号学的に安全な乱数で作り、1回使ったら無効にして期限を付けること、アカウント単位でレート制限をかけることを求めています。再設定が終わっても自動でログインさせず、通常のログインを通すよう書いている点も見落としやすい箇所です。

同じページは、復旧が終わったら既存のセッションと、まだ使われていない再設定リンクを無効にするよう求めています。攻撃者が先にログインしていた場合、パスワードを戻しただけでは攻撃者のセッションが生き残るからです。セッションIDの失効の作り方はセッションIDの発行から失効までの実装、マネージドサービスでの例はCognitoのパスワードリセットとロックアウト設計にあります。

パスワード変更イベントの急増と同一IPからの連続変更を見つける監視SQL

変更経路を突かれた攻撃は、ログイン失敗の監視では見えません。パスワード変更そのものを1件ずつ記録し、件数の偏りを見ます。下の例は、変更履歴のテーブルpassword_change_events（アカウントID・変更元IP・変更日時）から、1時間ごとの変更件数と、1つのIPから複数アカウントを変えた記録を取り出します。

-- 1. 直近7日間で、1時間あたりのパスワード変更件数が多い時間帯
SELECT strftime('%Y-%m-%d %H:00', changed_at) AS hour,
       COUNT(*)                               AS changes,
       COUNT(DISTINCT source_ip)              AS ips
FROM password_change_events
WHERE changed_at >= datetime('now', '-7 days')
GROUP BY hour
ORDER BY changes DESC
LIMIT 10;

-- 2. 1つのIPから24時間で3アカウント以上のパスワードを変えた記録
SELECT source_ip,
       COUNT(DISTINCT account_id) AS accounts,
       MIN(changed_at)            AS first_seen,
       MAX(changed_at)            AS last_seen
FROM password_change_events
WHERE changed_at >= datetime('now', '-1 day')
GROUP BY source_ip
HAVING COUNT(DISTINCT account_id) >= 3
ORDER BY accounts DESC;

2本ともSQLiteの日時関数で書いており、2026年10月24日に手元のsqlite3でダミーデータを入れて実行し、1つのIPから6アカウントを変えた行が抽出されることを確かめました。PostgreSQLならdate_trunc('hour', changed_at)とnow() - interval '7 days'への置き換えが必要です。しきい値の3アカウントは例で、普段の件数を2週間ほど測ってから決めます。API全体のレート制限やトークン失効の設計はAPI不正アクセス対策の実装手順に譲ります。

連携サービスが個人情報を表示する前にOIDCのmax_ageで再認証を求める実装

max_age・prompt=login・auth_timeの仕様とクライアント確認項目

共通IDの仕組みにOpenID Connectを使っているなら、連携サービスの側から再認証を求める手段が仕様にあります。OpenID Connect Core 1.0の3.1.2.1節は、認証リクエストのmax_ageを「最後に能動的に認証してからの許容秒数」と定め、超えていればIdP（共通IDの認証サーバー）は再認証を試みなければならないとしています。max_age=0はprompt=loginと同じ扱いです。

仕様は、max_ageを送ったときIDトークンにauth_time（認証した時刻）を必ず含めるとしています。3.1.3.7節の13項目めは、クライアントがauth_timeを確かめ、時間が経ちすぎていれば再認証を求めるべき（SHOULD）としています。IdPがmax_ageを無視する実装だった場合に備え、受け取る側でも時刻を見るのが安全です。IDトークンの署名検証から始まる全体の手順はOIDCのIDトークン検証手順で解説しています。

住所や購入履歴の画面だけ直近5分のログインを求めるPythonの実装例

全画面で毎回ログインさせると利用者が離れます。住所・電話番号・購入履歴・アドレス帳を表示する画面と、配送先を変える操作だけに絞って再認証をかけます。

import secrets
import time
from urllib.parse import urlencode

AUTHZ_ENDPOINT = "https://id.example.com/authorize"
MAX_AGE = 300  # 個人情報を表示する画面は、直近5分以内のログインだけを認める

def build_reauth_url(client_id: str, redirect_uri: str) -> tuple[str, str]:
    """マイページの住所・購入履歴を開く前に、IdP へ再認証を求めるURLを作る"""
    state = secrets.token_urlsafe(32)
    params = {
        "response_type": "code",
        "client_id": client_id,
        "redirect_uri": redirect_uri,
        "scope": "openid",
        "state": state,
        "max_age": str(MAX_AGE),
    }
    return f"{AUTHZ_ENDPOINT}?{urlencode(params)}", state

def is_recent_login(claims: dict, now: float | None = None) -> bool:
    """署名・iss・aud・exp を検証済みの ID トークンのクレームで、ログイン時刻を確かめる"""
    auth_time = claims.get("auth_time")
    if not isinstance(auth_time, int):
        return False  # max_age を送ったのに auth_time が無いなら通さない
    now = time.time() if now is None else now
    return now - auth_time <= MAX_AGE

マイページの住所画面を開く処理でis_recent_loginが偽なら、build_reauth_urlのURLへ転送し、戻ってきたIDトークンで再び判定します。stateはセッションに保存して、戻りの値と一致するかを確かめます。上のコードは2026年10月24日にPython 3.14.7で実行し、60秒前のログインで真、1時間前とauth_time欠落で偽になることを確かめました。IdPとの実際の通信は行っていません。再認証で二要素認証のコードまで求めるかは、IdP側の認証ポリシーで決まります。

事業者の判断：共通IDで複数サービスをつなぐ会員基盤で見直しを急ぐ範囲

共通ID・会員基盤で点検する4項目と、ここまでは不要と言える小規模構成

見直しを急ぐべきなのは、1つの会員IDでゲーム・アプリ・通販・ファンクラブなど複数のサービスに入れる構成で、そのうちどれかが住所や購入履歴を持っている事業者です。点検は4項目に絞れます。

パスワード変更とメールアドレス変更で、現在のパスワードを求めているか
変更を変更前のメールアドレスへ通知し、変更後に全セッションを失効させているか
パスワード変更の件数を記録し、同一IPからの連続変更を検知できるか
住所や購入履歴を出す連携サービスが、表示の前にauth_timeで再認証を求めているか

優先は1項目めと4項目めです。逆に、サービスが1つだけで住所もカード情報も持たない会員サイトなら、連携サービス側の再認証までは過剰で、1〜3項目めで足ります。共通IDの再認証の設計や、IdPと連携サービスの責任の分け方を外部と一緒に詰めるなら、認証基盤・ID管理システム開発で相談を受けています。

個人情報保護委員会への報告と、連携サービスごとに分かれる通知範囲

カプコンは発見から2日後の10月21日に個人情報保護委員会へ報告しました。個人情報保護委員会の案内のとおり、不正アクセスなど不正の目的によるおそれがある漏えいは、件数にかかわらず報告と本人通知の対象になります。報告の期限と速報・確報の書き方は個人情報保護委員会への報告義務の実務にまとめています。

共通IDの基盤では、どの連携サービスでどの項目が読まれたかによって、通知する内容が利用者ごとに変わります。今回もメールアドレス等の1,177万件と、住所まで漏れた19件とでは、利用者に伝える中身が別物でした。連携サービスへのアクセス記録をIDごとに追える形で残しておかないと、影響範囲を確定できず、通知が遅れます。

よくある質問

CAPCOM IDへの不正アクセスについて、利用者と開発者から出やすい質問をまとめました。

カプコンの不正アクセスで漏えいした情報は何ですか？

第一報では、メールアドレスと、アカウント作成日時・最終ログイン日時・ログイン回数・最終ログイン時のIPアドレスが1,177万4,247件です。うち43件は生年月日・性別・国と地域・ニックネームも漏れました。第二報で、パスワードを不正に変更された196件のうち19件について、イーカプコンの氏名・住所・電話番号・購入履歴・アドレス帳などの漏えいが加わっています。

CAPCOM IDのパスワードやクレジットカード情報は漏れましたか？

カプコンは、利用者が設定したパスワードの漏えいは確認されていないとしています。ただし196件ではパスワードが第三者に書き換えられており、該当アカウントはリセット済みです。クレジットカード情報は第一報・第二報とも漏えいの対象に含まれていません。

自分が対象かどうかはどうやって確かめればよいですか？

カプコンは対象者へ順次個別に連絡するとしています。連絡を待たずに確かめたい場合は、日本の専用窓口0120-801-271（10時〜20時）に問い合わせます。メールやSMSに書かれたリンクや番号ではなく、カプコン公式サイトに掲載された窓口を使ってください。

カプコンを名乗るメールやSMSが届いたらどうすればよいですか？

第二報は、漏えい情報を悪用してカプコンや関係先を装ったSMS・電話・メールが届く可能性を挙げ、URLへのアクセスや添付ファイルの開封をしないよう求めています。届いた連絡のリンクは開かず、自分でブックマークや公式サイトからCAPCOM IDにログインして状況を確かめます。

2020年のカプコンの不正アクセスと同じ事件ですか？

別の事案です。2020年11月の事案は北米現地法人の旧型VPN装置から社内ネットワークに侵入されたランサムウェア被害で、流出が確認されたのは取引先や社員などを中心とする累計15,649人でした。2026年10月の事案は、会員向けの共通アカウントであるCAPCOM IDが標的になったものです。

講談社の個人情報流出3,812件｜フィッシング起点のアカウント侵害の技術解説：アカウント侵害から個人情報が漏れた別の事例
パスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装：ログイン側の守りと検知
API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：API全体のレート制限とトークン失効
シングルサインオンのデメリット：単一障害点とID漏えいの被害拡大、費用と打ち消し方：共通IDの被害が広がる理由と打ち消し方
不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：企業として点検する範囲の全体像

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

カプコン不正アクセス：CAPCOM ID 1,177万件漏えいと196件の乗っ取りへの対処

まとめ：カプコン不正アクセスで公表された事実と、利用者・開発者が今日やること