--- title: "IDARE不正アクセス：12.9万人の漏えい項目と対象確認、不審な連絡と補償" url: "https://www.issoh.co.jp/tech/details/18371/" published: 2026-10-15 updated: 2026-10-15 categories: ["セキュリティ"] publisher: "株式会社一創" --- # IDARE不正アクセス：12.9万人の漏えい項目と対象確認、不審な連絡と補償 キャッシュレスアプリ「IDARE（イデア）」を運営する株式会社Fivotは2026年10月13日、第三者の不正アクセスで利用者の個人情報が外部に漏えいしたと公表しました。対象は9月27日までに登録した129,659人で、退会した人も含まれます。漏れたのは電話番号・メールアドレス・生年月日・残高・取引履歴などで、ログインパスワードやカード番号の全桁は含まれていません。前半では、自分は対象か、カードは再発行すべきか、届いた連絡は本物か、補償と窓口はどうなっているかに公式発表とFAQで答えます。後半は、カスタマーサポート用の外部ソフトウェアからデータベースが読まれた構図と、同じ経路を塞ぐための権限設定と検知の手順をコードで示します。 ## まとめ：IDARE不正アクセスで漏えいした情報と、利用者が今日確かめること 公表された経路は、Fivotがカスタマーサポート等の業務に導入していた外部ソフトウェアの脆弱性です。8月10日から9月27日にかけて複数回、データベースの情報が第三者に取得されました。経路は遮断済みで、当該ソフトウェアの利用は終了し、関連する認証情報も更新したとしています。10月13日時点で本件に起因する不正な取引は確認されておらず、残高は保全され、サービスは通常どおり使えます。 利用者がやることは3つに絞れます。1つ目は、IDAREを名乗るメール・SMS・電話でパスワードや認証コードを聞かれても答えないこと。2つ目は、アプリの取引履歴に身に覚えのない決済がないかを見て、あればカードロックをかけてから問い合わせること。3つ目は、個別に届く案内メールをリンクからではなく、アプリ内のお知らせや公式サイトと照らし合わせて読むことです。カードの再発行は、公式FAQでは必須ではないとされています。 | 項目 | 公表されている内容（2026年10月15日時点） | | ---------- | ------------------------- | | 運営会社 | 株式会社Fivot（前払式支払手段の発行者） | | 公表日 | 2026年10月13日 | | 対象者 | 9月27日までの登録者129,659人（退会者も） | | 不正取得の期間 | 8月10日〜9月27日に複数回 | | 経路 | CS業務等に使う外部ソフトウェアの脆弱性 | | 漏えいしていない情報 | パスワード・本人確認書類の画像・カード全桁など | | 不正取引 | 本件に起因するものは確認されていない | | 未公表 | ソフトウェアの名称・脆弱性の識別番号・お詫びの有無 | ## 利用者が最初に確かめること：対象かどうか、ログインの安全、届いた連絡の真偽 ### 9月27日までの登録者は退会済みでも対象、個別メールで範囲が届く見通し [IDAREの公式発表](https://idare.jp/news/1926/)は、漏えいの対象者を「2026年9月27日までにIDAREに登録されたお客さま（退会済のお客さまを含む）」としています。この日までに一度でも登録したなら、すでに退会していても対象です。照会用のページは設けられておらず、9月28日以降に登録した人は対象に含まれていません。 漏えいした情報の範囲は利用状況で変わるため、詳細はメールで個別に案内すると書かれています。本人確認を済ませたか、入金用にクレジットカードや銀行口座を登録したかで、漏れた項目が変わる仕組みです。案内が届いたら、メール内のリンクは開かずに、アプリを自分で起動してお知らせや取引履歴を確かめると安全です。 ### ログインパスワードは漏えいせず、SMS認証が必須という公式の説明と残る懸念 公式発表によると、ログインパスワードは漏えいしていません。ログインには多要素認証が必須で、漏えいした情報だけで第三者がアカウントに入ることはできないと説明しています。[IDAREのログイン手順](https://idare.jp/faq/191/)は、携帯電話番号とパスワードを入力したあと、SMSで届く認証コードを入れる流れです。 ただし電話番号は全員分が漏れています。電話番号を知った第三者が偽のSMSを送り、認証コードを聞き出そうとする手口には注意が必要です。SMSに頼らない方法として、[IDAREの二要素認証は認証アプリへの切り替え](https://idare.jp/faq/1731/)に対応しており、iPhoneはパスワードアプリ、AndroidはGoogle Authenticatorで設定できます。公式が切り替えを求めているわけではありませんが、不安が残る人が選べる手段の1つです。 ### IDAREやカード会社を名乗るメール・SMS・電話を受けたときの確かめ方 公式発表は、IDAREを装った不審なメール・SMS・電話が来る可能性があると注意を促しています。そのうえで、IDAREがメール・SMS・電話でパスワード、暗証番号、セキュリティコード、多要素認証の認証コードを聞くことはないというのが、公式発表に明記された説明です。[サポート窓口のFAQ](https://idare.jp/faq/87/)には、電話でのサポートは行っていないとあります。 今回は残高と取引履歴まで漏れているため、「◯月◯日の◯◯円の取引について確認したい」と本物らしい具体を添えた連絡が届く可能性があります。中身が合っていても、それだけで本物とは判断できません。リンクや添付ファイルは開かず、カード会社を名乗る連絡ならカード裏面の番号へ自分でかけ直します。偽の連絡が成立する仕組みは[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)で解説しています。 ## 漏えいした情報の内訳：全員分の残高・取引履歴と一部の本人確認情報 ### 全129,659人に共通する3項目と、利用状況で一部の人だけが対象の6項目 公式発表は、漏えいした情報を「全ての対象者」と「一部の対象者」に分けて書いています。 | 区分 | 漏えいした情報 | | -- | ------------------------- | | 全員 | 電話番号・メール・生年月日・ユーザーID・表示名等 | | 全員 | アカウントの設定とステータス・残高・取引履歴 | | 全員 | IDAREカードの名義・有効期限 | | 一部 | 本人確認の申請内容（氏名・住所・性別・書類番号等） | | 一部 | IDAREカード番号の下4桁 | | 一部 | 入金用クレジットカード番号の先頭6桁と下4桁 | | 一部 | 入金用銀行口座番号の下3桁 | | 一部 | リアルカードのアクティベーションコード | | 一部 | 年収・勤務先など（貸付サービスLADDER用） | マイナンバーと本人確認資料の画像は流出していません。本人確認書類の画像や容貌の画像は、不正アクセスを受けたシステムからは参照できない仕組みで管理していたと説明されています。アクティベーションコードについては、第三者のアカウントからは使えないという説明です。表のメールはメールアドレス、書類番号は本人確認書類の番号を指します。最後の年収や勤務先は、2021年10月までに登録し、同月に終了した貸付サービスLADDERを使うために入力した人だけが対象です。 ### 入金用カードの先頭6桁と下4桁だけでは決済できない理由と、再発行を決める基準 10月13日以降、[IDAREのFAQ「入金用クレジットカードの番号の一部が漏えいした場合について」](https://idare.jp/faq/1940/)が追加されました。16桁のカードでは1〜6桁目と13〜16桁目が漏れ、7〜12桁目は保持していないため漏れていません。有効期限とセキュリティコードも保持しておらず、漏れたのは番号の一部だけです。先頭6桁はカード会社とカードの種類を表す共通の番号で、下4桁はレシートや明細に印字される番号です。 FAQは、カード情報の国際的な基準であるPCI DSSで画面や帳票に表示してよい上限が先頭6桁と下4桁だと説明しています。基準の要件は[PCI DSSの12要件と準拠レベル](https://www.issoh.co.jp/column/details/13185/)の記事で整理しました。再発行についてFAQは「必須ではないと考えています」としたうえで、不安な場合は当社窓口と発行カード会社に相談するよう案内しています。判断の目安は、利用明細に身に覚えのない請求が出ていないかです。出ていなければ明細の確認を続け、出ていればすぐにカード会社へ連絡します。 ## 補償と問い合わせ：不正利用の補償制度、カードロック、窓口の使い分け ### 身に覚えのない取引を見つけた日にカードロックをかけ、30日以内に申告する手順 本件そのもののお詫びとして金銭やポイントを配るという記載は、10月15日時点の公式発表にはありません。一方で、第三者に残高を不正に使われた場合の[IDAREの不正利用補償制度](https://idare.jp/faq/1685/)は以前から定められています。不正な決済が行われた日から30日以内にIDAREと警察署へ申告したものが対象で、損害発生の時点で本人確認が済んでいないアカウントは対象外です。手順は次のとおりです。 1. アプリでカードロックをかける（ロック中も入金・残高・履歴の確認はできる） 2. アプリ内のお問い合わせで「身に覚えのない取引」を選び、決済日時・金額・加盟店名を書いて送る 3. 警察署へ相談し、届出の受理番号を控える 4. 受理番号を添えてIDAREへ補償申請をする [カードロックのFAQ](https://idare.jp/faq/77/)によると、ロックは決済だけを止める機能で、アプリからいつでも解除できます。1円や200円の少額請求は、加盟店がカードの有効性を確かめるための仮の請求である場合も多いとFAQにあります。それでも心当たりがなければ、ロックしてから問い合わせるのが先です。補償は不正内容の確定後に手続きされ、最大60日ほどかかる場合があるとされています。 ### 問い合わせはアプリ内フォームが基本で、電話窓口は設けられていない 本件の問い合わせ先は、アプリ内の「お問い合わせ」か、公式サイトのお問い合わせフォームです。FAQは、アプリから問い合わせると担当者が利用状況を確かめられるため対応が早いと説明しています。回答は順番に行うため、混雑時は時間がかかる場合があります。 電話の窓口は設けられていません。「IDAREサポートセンター」を名乗って電話がかかってきた場合や、メールに専用ダイヤルの番号が書かれている場合は、その番号にかけず、アプリのお問い合わせから事実を確かめてください。不正利用の連絡先は、[IDAREの資金決済法に基づく表示](https://idare.jp/payment-act/)にもメールアドレスが載っています。 ## 公式発表で追う経過：8月10日からの複数回の取得とCS用外部ソフトウェアの経路 ### 約7週間の取得期間と、ソフトウェアの名称が公表されていない現状 公式発表の経過を並べると、次のようになります。 1. 8月10日〜9月27日：CS業務等に導入していた外部ソフトウェアの脆弱性を悪用され、複数回にわたりデータベースの情報を取得される 2. 9月27日まで：この日までの登録者が漏えいの対象になる 3. 公表までの間：不正アクセス経路を遮断し、当該ソフトウェアの利用を終了、関連する認証情報を更新 4. 10月13日：公式サイトで公表。法令に基づく報告と、弁護士を含む第三者による調査を進めていると説明 5. 10月13日以降：入金用クレジットカード番号の一部の漏えいについてFAQを追加 どの製品のどの脆弱性が使われたのか、いつ気付いたのかは公表されていません。脆弱性の識別番号も出ておらず、同じソフトウェアを使う他社が自社への影響を確かめられない状態です。再発防止策には、ソフトウェアの脆弱性情報を継続して監視する体制と、アクセスログの監視・アラート体制の整備が挙がっています。後者は、7週間にわたる複数回の取得に途中で気付けなかったことの裏返しと読めます。 ### 前払式支払手段の発行者としての位置付けと、個人情報保護委員会の報告類型 IDAREのポイント残高は、資金決済法の前払式支払手段です。資金決済法に基づく表示によると、Fivotは発行額の半額を供託しており、全額の保全は法律上の義務ではないとの注記もあります。前払式支払手段と資金移動業の違いは[資金決済法の区分とポイント・チャージ設計](https://www.issoh.co.jp/column/details/18204/)で解説しています。 [個人情報保護委員会の「漏えい等の対応」](https://www.ppc.go.jp/personalinfo/legal/leakAction/)は、報告が義務になる場合として、不正の目的をもって行われたおそれがある漏えい等と、本人の数が1,000人を超える漏えい等を挙げています。今回はどちらにも当たり、不正な目的のおそれがある場合の報告期限は発覚日から60日以内です。同じページは、カード番号の下4桁と有効期限の組合せだけの漏えいは直ちに報告対象にはならないとも例示しています。報告の段取りは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)にまとめました。 ## 開発側の教訓：サポート用ツールに読ませる列を絞り、大量読み出しを検知する手順 ### 顧客テーブルを直接渡さず、マスク済みビューだけを許可するPostgreSQLの権限 今回の経路は、サポート業務のための外部ソフトウェアが、残高や取引履歴まで含むデータベースを読めたことにあります。一方で本人確認書類の画像は、そのシステムからは参照できない仕組みにしていたため漏れていません。分けて保管した情報は守られたという事実が、対策の方向を示しています。問い合わせ対応に要る列だけを見せるビューを作り、ツールの接続アカウントにはそのビューだけを許可します。 ``` -- サポート用ツールの接続アカウントには顧客テーブルを直接見せない（PostgreSQL 18系の構文） CREATE ROLE cs_tool LOGIN; -- パスワードは別途 \password で設定する REVOKE ALL ON customers, transactions FROM cs_tool; CREATE VIEW support_customers AS SELECT user_id, display_name, '***-****-' || right(phone, 4) AS phone_tail, -- 電話番号は下4桁だけ date_part('year', birth_date) AS birth_year, -- 生年月日は年だけ account_status FROM customers; -- 残高・本人確認情報の列は含めない GRANT SELECT ON support_customers TO cs_tool; ``` [PostgreSQLのCREATE VIEW](https://www.postgresql.org/docs/current/sql-createview.html)は、既定ではビューの所有者の権限で元の表を読みます。このため`cs_tool`に元の表の権限が無くても、ビューに並べた列だけは読めます。`security_invoker`を付けると使う側の権限で判定されるので、この使い方では付けません。列単位で許可する方法も[GRANTの公式ドキュメント](https://www.postgresql.org/docs/current/sql-grant.html)にありますが、マスクした値を返せるビューのほうが、ツールが受け取る情報を小さくできます。このSQLは公式ドキュメントで構文を確かめたもので、本記事の検証環境では実行していません。 ### 1時間に読んだ顧客数が普段の10倍を超えたら知らせる監査ログ検知スクリプト 権限を絞っても、許可した範囲を一気に読まれる危険は残ります。そこで、接続アカウントごとに「1時間に何人分の顧客を読んだか」を数え、普段の値から大きく外れた時間帯を抽出するのが、ここでの検知方法です。監査ログを時刻・アカウント・顧客IDのCSVに書き出せば、次のスクリプトで判定できます。 ``` # 監査ログから「1時間に読んだ顧客の人数」をアカウントごとに数え、普段の何倍にも跳ねた時間帯を出す（Python 3.8以上・標準ライブラリのみ） # 使い方: python bulk_read_alert.py audit.csv 10 500 # audit.csv の列: ts（ISO 8601）, account（DB接続アカウント）, customer_id（読まれた顧客ID） import csv, sys from collections import defaultdict from datetime import datetime from statistics import median src, ratio, floor = sys.argv[1], float(sys.argv[2]), int(sys.argv[3]) seen = defaultdict(set) # (アカウント, 時間帯) -> 読まれた顧客IDの集合 with open(src, encoding="utf-8", newline="") as f: for r in csv.DictReader(f): hour = datetime.fromisoformat(r["ts"]).strftime("%Y-%m-%d %H:00") seen[(r["account"], hour)].add(r["customer_id"]) # 同じ顧客を何度読んでも1人と数える per_acct = defaultdict(dict) for (acct, hour), ids in seen.items(): per_acct[acct][hour] = len(ids) alerts = 0 for acct, hours in sorted(per_acct.items()): base = median(hours.values()) # そのアカウントの「普段の1時間」 for hour, n in sorted(hours.items()): # 普段のratio倍を超え、かつ絶対数でもfloor人を超えたときだけ鳴らす（少人数の揺れで鳴らさない） if n > base * ratio and n > floor: alerts += 1 print(f"ALERT {hour} {acct}: {n}人（普段の中央値 {base:.0f}人）") print(f"検査した時間帯: {len(seen)} / アラート: {alerts}") ``` 集計は[Python標準のcsvモジュール](https://docs.python.org/3/library/csv.html)で読み、[collectionsのdefaultdict](https://docs.python.org/3/library/collections.html)でアカウントと時間帯ごとに顧客IDの集合を作ります。同じ顧客を何度開いても1人と数えるので、担当者が1件の問い合わせで画面を何度も更新しても誤って鳴りません。 実在のデータは使わず、14日分の架空の監査ログ（73,229行）で試しました。担当者2名が営業時間に1時間20〜60人、サポートツールが1時間5〜15人を読む通常の記録に、サポートツールが2日の深夜にそれぞれ1時間で3万人分を読む記録を混ぜています。Python 3.14.7（Windows）の実行結果は次のとおりです。 ``` $ python bulk_read_alert.py audit.csv 10 500 ALERT 2026-09-17 02:00 cs_tool: 30008人（普段の中央値 10人） ALERT 2026-09-24 03:00 cs_tool: 30006人（普段の中央値 10人） 検査した時間帯: 588 / アラート: 2 ``` 588の時間帯のうち、混ぜた2つだけが出て、通常の時間帯は1件も鳴りませんでした。運用では1時間ごとにcronなどで動かし、アラートを担当者のチャットへ送ります。閾値の10倍と500人は検証用の値なので、自社のログで2週間ほど動かして通常の最大値を確かめてから決めてください。 ## 事業者の判断：外部サポートツールを使い続ける条件と、第三者診断に頼る場面 ### 外部ツールを使ってよい構成と、残高や本人確認情報に届く構成を見送る基準 問い合わせ管理やチャットの外部ツールを使うこと自体を避ける必要はありません。使ってよいのは、ツールに渡すのが問い合わせ対応に要る列のマスク済みの値だけで、残高や取引履歴、本人確認情報には届かない構成です。ツールの脆弱性情報を誰が追い、更新を何日以内に当てるかを決めていることも条件になります。 見送るべきなのは、ツールが本番データベースへ広い権限で直接つながり、接続アカウントの読み出し量を誰も見ていない構成です。この形は今回と同じく、ツール側の欠陥がそのまま顧客全員分の漏えいにつながります。ツール選びの観点は[ヘルプデスクツールの4タイプと自社構築の判断](https://www.issoh.co.jp/column/details/15692/)、管理ツールが入口になった別の事案は[NewsPicks不正アクセスと管理ツールの教訓](https://www.issoh.co.jp/tech/details/18349/)で扱っています。 ### 連携ツールまで含めた点検を自社だけで回せないときの脆弱性診断の使い方 自社で作ったアプリやAPIは診断していても、外部ツールとの連携部分は点検の範囲から抜けがちです。どのアカウントがどのデータに届くのか、ツールの更新が止まっていないかは、連携の数が増えるほど担当者1人では追い切れません。診断の種類と費用の考え方は[脆弱性診断の種類・費用相場と外注の判断基準](https://www.issoh.co.jp/column/details/13101/)で整理しています。 残高や本人確認情報を預かるサービスで、連携ツールを含めた権限と経路を第三者の目で確かめたいなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 IDAREの不正アクセスについて、利用者から出やすい質問をまとめました。 ### IDAREの不正アクセスで自分の情報は漏れましたか？ 2026年9月27日までにIDAREに登録した人は、退会済みでも全員が対象です。電話番号・メールアドレス・生年月日・残高・取引履歴などは全員分が漏えいしました。本人確認時の申請内容やカード番号の一部は、利用状況によって一部の人だけが対象です。どの項目が自分に当てはまるかは、Fivotからメールで個別に案内されます。 ### IDAREは今も使えますか？残高は大丈夫ですか？ 公式発表によると、残高は安全に保全されており、サービスは通常どおり使えます。10月13日時点で本件に起因する不正な取引は確認されていません。ログインパスワードは漏えいしておらず、ログインにはSMSなどの多要素認証が必須です。不安な場合は、アプリの取引履歴に身に覚えのない決済がないかを確かめてください。 ### 入金に登録したクレジットカードは再発行したほうがよいですか？ 公式FAQは、漏れたのは先頭6桁と下4桁だけで、残りの番号・有効期限・セキュリティコードは保持していないため漏れていないと説明しています。そのうえで示されているのは、カードの再発行は必須ではないという考えです。不安な場合はIDAREの窓口と発行カード会社に相談するよう案内されています。利用明細に心当たりのない請求があれば、すぐカード会社へ連絡してください。 ### IDAREから補償やお詫びはありますか？ 本件のお詫びとして金銭やポイントを配るという案内は、10月15日時点の公式発表にありません。第三者に残高を不正に使われた場合は、既存の不正利用補償制度で申請できます。不正な決済の日から30日以内にIDAREと警察署へ申告することが条件で、本人確認が済んでいないアカウントは対象外です。補償は残高へのポイント加算で行われます。 ### IDAREの問い合わせ窓口に電話番号はありますか？ ありません。公式FAQは電話でのサポートは行っていないと案内しており、本件の問い合わせはアプリ内の「お問い合わせ」か公式サイトのお問い合わせフォームから受け付けています。IDAREを名乗る電話がかかってきても、パスワードや認証コードを答えてはいけません。IDAREはそれらを電話やメールで聞くことはないと明記しています。 ## 関連記事 - [不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順](https://www.issoh.co.jp/column/details/18313/)：企業として点検する範囲の全体像 - [決済トークンとは？トークナイゼーションの仕組みと暗号化との違い・実装方式を開発視点で解説](https://www.issoh.co.jp/tech/details/15726/)：カード番号を持たない設計の実装方式 - [アットリンク不正アクセス：最大787医療機関の患者情報と予約・問い合わせ窓口](https://www.issoh.co.jp/tech/details/18369/)：同時期に起きた漏えいと問い合わせ先の整理 - [タイムズカー情報漏洩・流出：対象の確認と補償、0120-25-8924は本物か、免許証画像への備え](https://www.issoh.co.jp/tech/details/17925/)：漏えい後に届く連絡の真偽を確かめる手順 - [資金決済法とは？前払式支払手段と資金移動業の区分をポイント・チャージ設計で解説](https://www.issoh.co.jp/column/details/18204/)：チャージ式サービスが負う法律上の義務 --- 出典: [IDARE不正アクセス：12.9万人の漏えい項目と対象確認、不審な連絡と補償]()（株式会社一創）