セキュリティ

シェアフル情報漏洩：最大約750万件の対象確認と偽連絡の見分け方、口座情報の扱い

シェアフル情報漏洩：最大約750万件の対象確認と偽連絡の見分け方、口座情報の扱い

スキマバイトアプリ「シェアフル」を運営するシェアフル株式会社は2026年11月9日、社内管理システムへの不正アクセスにより、個人アカウント最大約750万件と求人企業最大約7,500社の情報が流出した可能性があると発表しました。本記事の前半では、自分は対象か、銀行口座と顔写真はどう扱われているか、届いた連絡は本物かを、11月10日時点の発表に沿って整理します。後半では、会員情報を扱う管理画面の開発者に向けて、不審なアカウント作成の検知と閲覧の制限をPythonのコードで示します。

まとめ：シェアフル情報漏洩で流出した可能性のある情報と利用者が取る対応

流出の可能性があるのは、氏名、電話番号、メールアドレス、住所、生年月日、給与振込用の銀行口座情報、顔写真のURL、緊急連絡先、在留資格関連情報などです。暗証番号やパスワードは口座情報に含まれない、と同社は説明しました。原因は調査中で、侵入の経路は公表されていません。出発点はシェアフルの公式発表です。

利用者がまずやることは2つあります。シェアフルや関係機関を名乗る連絡のリンクを開かないこと、銀行の暗証番号を誰にも伝えないことです。求人企業の担当者には、取引先を装う連絡への備えが要ります。開発側が持ち帰る論点は、承認のない管理アカウントをすぐ見つけられるか、1つのアカウントで全件を読める状態になっていないか、の2点になります。

項目 11月10日時点の発表内容
個人の対象 最大約750万件
法人の対象 最大約7,500社
不正アクセス 11月4日23時30分頃
判明 11月5日9時45分頃
経路の遮断 11月5日14時頃
対象外と確認 給与・ポイント、契約・就業データ、本人確認書類画像
保持していない マイナンバー、クレジットカード情報
サービス 通常どおり提供
未公表 侵入経路、原因、確定した流出件数

シェアフル利用者が最初に確かめること：対象の範囲と口座、届いた連絡の真偽

最大約750万件は上限の数字：個別連絡の有無と自分が対象か判断する方法

約750万件は、流出した可能性のある情報を含むアカウントの最大数です。全件の持ち出しが確定したという意味ではありません。逆に、自分だけは外れていると考える材料もまだありません。

対象者には電子メールなどで個別に連絡を順次実施する、と同社は案内しています。時期は示されていないため、連絡が来ていないことは対象外の根拠になりません。登録の覚えがある人は、対象に含まれる前提で動くのが無難です。確認したいことがあれば、公式発表にある個人ユーザー専用のお問い合わせフォームを使います。発表は退会済みのアカウントの扱いには触れていません。

給与振込口座と顔写真URL：含まれる項目と含まれないと発表された項目の境界

口座については「給与振込用銀行口座情報（暗証番号やパスワードは含まれません）」という書き方です。給与金額の閲覧や、即払いを含む給与支払い手続き、ポイント利用に不正な操作がなかったことも確認済みとされました。口座番号の変更を求める案内は、発表にはありません。

顔写真は、画像そのものではなく「保管しているサーバーのURL」が対象項目です。写真データはほかの個人情報と別のサーバーで管理され、そのサーバーへのアクセスも遮断済みと説明されています。画像が取得されたかどうかについて、発表は明言していません。URLの形式も公表されていないので、本記事では「写真は見られていない」とも「見られた」とも書きません。

ログインパスワードにも発表は触れていません。パスワードの記載は銀行口座に関する箇所だけです。同じパスワードを別のサービスで使っている人は、今回の発表と切り離して変えておくと安心できます。

シェアフルを装うメール・SMS・電話の見分け方と不正送金時の相談先3つ

基準は明快です。同社は、電話やメールなどで銀行口座の暗証番号やパスワードを尋ねることは一切ないとしています。これらを聞いてくる連絡は偽物と判断してください。名前や住所、働いた回数が正しく書かれていても、本物の証拠にはなりません。流出の可能性がある情報そのものだからです。

給与の未払いや口座の再登録、本人確認のやり直しを理由に急がせる連絡も、リンクを開かずにアプリや公式サイトから確かめます。警察庁のフィッシング対策の案内も、送信元の名称やアドレスだけで真偽を判断しないよう求めています。手口の全体像はフィッシング詐欺の成立の仕組みと技術的な対策で解説しました。

暗証番号を入力してしまった、身に覚えのない出金があった場合の連絡先は次の順です。

  1. 口座のある金融機関。全国銀行協会の相談窓口の案内も参照できます
  2. 最寄りの警察署、または警察のサイバー事案の窓口
  3. シェアフルの個人ユーザー専用フォーム

緊急連絡先に登録した家族と在留資格情報：本人以外へ及ぶ2つの注意点

緊急連絡先は、続柄（親・配偶者など）と電話番号が対象です。登録した相手は、シェアフルの利用者でなくても電話番号が流れた可能性があります。「お子さんの勤務先でトラブルがあった」といった電話への備えとして、家族に一言伝えておいてください。同社から家族へ個別に連絡が届くかどうかは、発表に書かれていません。

在留資格関連情報が対象に入った点も、この事案の特徴です。外国籍の利用者には、入管や役所を名乗って在留カードの写しや手数料を求める連絡が考えられます。公的機関を名乗っていても、その電話やメールの中では手続きせず、自分で調べた窓口へかけ直してください。発表は運転免許証などの本人確認書類の画像について、不正アクセスを受けたデータに含まれていないとしています。

求人企業の担当者が確かめること：最大約7,500社の情報と社内への周知手順

担当者名と営業管理データが対象：取引先を装う連絡で確認する3項目

法人側の対象は、会社名、電話番号、住所、郵便番号、担当者の氏名・部署・役職・メールアドレス・電話番号、営業管理データの一部です。担当者の名前と肩書きが揃うと、シェアフルの営業担当を装うメールの文面が本物らしくなります。「営業管理データの一部」が何を指すかは公表されていません。

社内には次の3点を先に周知します。

  1. 支払先の口座変更の依頼は、メールの返信ではなく登録済みの電話番号で確かめる
  2. 請求書や求人管理画面への再ログインを促すリンクは開かず、ブックマークから入る
  3. 問い合わせは公式発表にある企業専用フォームに一本化する

自社の担当者の個人情報が含まれる可能性があるので、該当する担当者本人にも知らせます。同社は対象者へ個別に連絡するとしているため、届いた案内は窓口の担当者に集めておくと確認が早く済みます。

公式発表で整理する経緯：11月4日23時30分の発生から11月9日の公表まで

発生から判明まで10時間15分、判明から遮断まで4時間15分の時系列

  1. 11月4日23時30分頃：不正アクセスが発生
  2. 11月5日9時45分頃：同社が検知し、ログと影響範囲の調査を開始
  3. 11月5日14時頃：不正アクセスの経路を遮断
  4. 11月6日〜8日：被害範囲の特定と二次被害の防止策を実施
  5. 11月9日15時30分：PR TIMESで公表

発生から遮断までは約14時間半です。影響範囲の特定により、さらなる流出の可能性は発生していないことを確認したと説明しています。個人情報保護委員会への届出・報告の手続きを進め、警察署へも通報しました。11月10日時点で第二報は確認できていません。なおANNの報道には「9日午後2時までに」遮断したとの表現がありますが、公式発表の記載は11月5日14時頃です。

公式サイト版とPR TIMES版の文言差：不審なアカウント作成という記述

2つの発表を突き合わせると、経緯の欄に差があります。PR TIMES版は「不審なアカウント作成およびアクセス」と書き、公式サイト版は同じ箇所を「不正アクセス」としています。どちらかが訂正されたのかは分かりません。

侵入の手口、アカウントを作れた理由、一度に読めた件数は未公表です。本記事は、認証情報が盗まれた、権限の設定に不備があった、とは書きません。以降の技術章で前提にするのは、「社内管理システムが対象だった」「不審なアカウント作成に言及がある」「個人と法人の情報が同じ事案で対象になった」の3点だけです。

社内管理システムの不審なアカウント作成を検知する監査ログとSQLの実装

記録する操作の決め方：アカウント作成・権限変更・書き出しの3種類と項目

OWASPのLogging Cheat Sheetは、高リスクな機能として、ユーザーの追加・削除と権限変更、管理者の特権操作、機密データへのアクセス、画面上のレポートを含むデータの入出力を記録の対象に挙げています。管理画面でまず押さえるのは、アカウント作成、権限変更、書き出しの3種類です。

項目は、いつ、誰が、何を、何件、どの承認に基づいて、の5つで足ります。件数の列がないと、1件の閲覧と25万件の書き出しが同じ1行に見えてしまいます。一方で口座番号やセッションIDをログに書いてはいけません。同じ資料が、銀行口座のデータやセッション識別子を直接記録しないよう求めています。

承認のない作成と作成直後の大量閲覧を1本のSQLで抽出するPythonコード

次の例は、監査ログから2つの条件を1本のSQLで抽出します。1つは承認番号のないアカウント作成、もう1つは作成から24時間以内の大量閲覧です。実行にはPython標準のsqlite3を使いました。データは説明用の架空の値です。

# 承認のない管理アカウントと、作成直後の大量閲覧を見つける最小例（Python 3.9以上・標準ライブラリのみ）
import sqlite3

con = sqlite3.connect(":memory:")
con.executescript("""
CREATE TABLE audit_log (
    at TEXT NOT NULL, actor TEXT NOT NULL, action TEXT NOT NULL,
    target TEXT, row_count INTEGER NOT NULL DEFAULT 0, ticket TEXT);
INSERT INTO audit_log VALUES
 ('2026-01-13 10:00:00','hr_lead','account.create','op_new',0,'REQ-1042'),
 ('2026-01-13 13:00:00','op_new','pii.read','users',40,NULL),
 ('2026-01-20 02:05:00','op_new','account.create','tmp_user',0,NULL),
 ('2026-01-20 02:12:00','tmp_user','pii.read','users',5000,NULL),
 ('2026-01-20 03:40:00','tmp_user','pii.export','users',250000,NULL);
""")

QUERY = """
WITH created AS (
    SELECT target AS account, at AS created_at, actor AS created_by, ticket
    FROM audit_log WHERE action = 'account.create'
),
early_reads AS (
    SELECT c.account, SUM(a.row_count) AS rows_24h
    FROM created c
    JOIN audit_log a ON a.actor = c.account
     AND a.action IN ('pii.read', 'pii.export')
     AND a.at BETWEEN c.created_at AND datetime(c.created_at, '+24 hours')
    GROUP BY c.account
)
SELECT c.account, c.created_at, c.created_by,
       COALESCE(e.rows_24h, 0) AS rows_24h,
       CASE WHEN c.ticket IS NULL THEN '承認なし' ELSE '承認あり' END AS approval
FROM created c LEFT JOIN early_reads e ON e.account = c.account
WHERE c.ticket IS NULL OR COALESCE(e.rows_24h, 0) >= :threshold
ORDER BY c.created_at
"""

for row in con.execute(QUERY, {"threshold": 1000}):
    print(row)

Python 3.14.10（SQLite 3.50.4・Windows）で実行した結果です。

('tmp_user', '2026-01-20 02:05:00', 'op_new', 255000, '承認なし')

承認番号のある op_new は出ず、承認なしで作られた tmp_user だけが出ました。created_by が op_new なので、次に調べる相手も同時に分かります。しきい値の1000は例です。通常業務の1日あたりの閲覧件数を測って、その数倍に置いてください。datetime() はSQLiteの関数のため、PostgreSQLなら interval に書き換えます。

夜間の検知を人に届ける通知先と遮断手順、ログの改ざん対策の決めごと

このSQLを5分ごとに流しても、結果を朝まで誰も見なければ意味がありません。承認なしのアカウント作成は件数が少ないので、深夜でも当番の電話まで鳴らす設定にします。大量閲覧の警告より、こちらを先に通知の対象に入れるのが実務的です。

遮断の手順は事前に文書にします。該当アカウントの無効化、発行済みセッションの失効、書き出し機能の停止の3つを、誰が判断して誰が実行するかを決めておく内容です。ログを攻撃者に消されないよう、OWASPが挙げる読み取り専用の保存先や改ざん検知も併用します。管理画面と同じサーバーの同じ権限でログを置く構成は避けてください。

1アカウントで全件を読ませない閲覧枠と口座番号・顔写真URLの分離の実装

担当者ごとの閲覧枠と口座番号の別権限を1か所で強制するPythonコード

検知は事後の対策です。読める件数そのものを絞れば、侵入されても被害の上限が下がります。次の例は、担当者ごとの1日の閲覧枠と、口座番号を表示できる役割を1つの関数で強制します。

# 担当者ごとの閲覧枠と、口座番号の別権限を1か所で強制する最小例（Python 3.9以上・標準ライブラリのみ）
from collections import defaultdict

DAILY_LIMIT = {"support": 200, "payroll": 2000}
BANK_ROLES = {"payroll"}
used = defaultdict(int)


class Denied(Exception):
    pass


def mask_account(number):
    return "*" * (len(number) - 3) + number[-3:]


def read_users(operator, role, users, reason=None):
    """画面もCSV出力もこの関数だけを通す"""
    limit = DAILY_LIMIT.get(role, 0)
    if used[operator] + len(users) > limit:
        raise Denied(f"閲覧枠超過: {operator} {used[operator]}+{len(users)} > {limit}")
    show_bank = role in BANK_ROLES and reason is not None
    used[operator] += len(users)
    return [
        {"id": u["id"], "name": u["name"],
         "bank_account": u["bank_account"] if show_bank else mask_account(u["bank_account"])}
        for u in users
    ]


one = [{"id": 1, "name": "山田", "bank_account": "1234567"}]
bulk = one * 500

print("問い合わせ対応:", read_users("op_a", "support", one))
print("経理・理由あり:", read_users("op_b", "payroll", one, reason="REQ-2201"))
print("経理・理由なし:", read_users("op_c", "payroll", one))
try:
    read_users("op_a", "support", bulk)
except Denied as err:
    print("拒否:", err)
print("op_aの消費:", used["op_a"])

実行結果は次のとおりです。

問い合わせ対応: [{'id': 1, 'name': '山田', 'bank_account': '****567'}]
経理・理由あり: [{'id': 1, 'name': '山田', 'bank_account': '1234567'}]
経理・理由なし: [{'id': 1, 'name': '山田', 'bank_account': '****567'}]
拒否: 閲覧枠超過: op_a 1+500 > 200
op_aの消費: 1

問い合わせ担当の画面では口座番号が下3桁だけになり、500件の一括取得は拒否されて枠も消費しません。未登録の役割の枠は0なので、誰も何も読めない状態が既定です。本番では、枠をプロセスのメモリではなくデータベースやRedisで原子的に加算し、reason は承認システムの番号と照合します。CSV出力など別の経路を残すと枠が効かないため、経路は1つにまとめる必要があります。

顔写真URLに有効期限を付ける署名付きURLとAWS CLIの発行コマンド

今回の発表で顔写真が「URL」として対象に挙げられたことは、設計上の論点を示しています。データベースに恒久的なURLを持つ構成では、URLの列が読まれた時点で写真に届く経路も一緒に渡ることになります。対策は、データベースには保管キーだけを持ち、表示のたびに短命の署名付きURLを発行する方式です。S3なら次のコマンドで試せます。

aws s3 presign s3://example-photo-bucket/users/1001.jpg --expires-in 300

AWS CLIのpresignの説明によれば、--expires-in の既定は3600秒、最大は604800秒です。管理画面の表示用なら既定の1時間は長いので、この例では300秒にしました。署名付きURLは受け取った人が誰でも取得できる点に注意が要ります。バケットの直接公開を止め、発行の処理にも前項の閲覧枠を掛けてください。

管理画面の認証はフィッシング耐性のある方式：NIST文書の要件と適用範囲

管理画面のログインは、社内の人だけが使うからこそ狙う価値があります。NIST SP 800-63Bは、AAL2の検証者に少なくとも1つのフィッシング耐性のある認証の選択肢を提供するよう求めました。手入力するワンタイムコードはフィッシング耐性があるとはみなされず、WebAuthn（FIDO2）などが該当します。

再認証の目安は、AAL2で全体24時間以内、無操作1時間以内です。個人情報を一括で読める役割には、パスキーやセキュリティキーを必須にすることを推奨する立場です。方式ごとの違いは多要素認証の3要素と耐フィッシングMFAの実装にまとめています。管理用APIの認可まで含めた点検はAPI不正アクセス対策の実装手順が参考になります。

人材・会員サービスの開発者が今月直す順番と見送ってよい対策の判断基準

着手順は作成通知・閲覧枠・口座分離の順、SIEM導入を見送る人数の条件

順番は言い切れます。最初はアカウント作成の承認と通知です。ログと通知の追加だけで済み、数日で入ります。次に閲覧枠、その次が口座番号の別権限と画面のマスクになります。列の暗号化はこの後です。アプリの権限で復号できる構成のままでは、管理画面の経由で読まれる被害を暗号化だけでは防げないからです。

見送ってよいものもあります。管理画面の利用者が数十人までで、監査ログが1つのデータベースに集まっているなら、SIEMの新規導入は今月の優先事項ではありません。上のSQLと通知で、承認なしの作成は拾えます。複数のシステムをまたいで相関を見る必要が出た段階で検討すれば十分です。IPアドレス制限だけで済ませる判断は採りません。許可された拠点の端末やVPNが侵害された場合に、制限は効かなくなるからです。

漏えい等報告の期限確認：速報3〜5日と不正目的の確報60日に備える記録

個人情報保護委員会の案内によれば、不正アクセスなど不正の目的によるおそれがある漏えいと、本人の数が1,000人を超える漏えいは報告の対象です。速報は発覚日から3〜5日以内、不正の目的が疑われる場合の確報は60日以内とされています。件数と項目を確定するには、前述の監査ログがそのまま材料になります。報告の項目と段取りは個人情報保護委員会への報告義務の実務で扱いました。

個人情報を扱う管理画面を自社で運営している場合、確かめる順番はアカウント作成の経路、全件を読める役割の有無、書き出し機能の記録です。第三者の目で権限や認証の弱点を点検したいときは、脆弱性診断・セキュリティ診断で相談を受け付けています。

よくある質問

シェアフルの不正アクセスと情報流出について、利用者から出やすい質問をまとめました。内容は11月10日時点の発表に基づきます。

シェアフルを退会していても情報は流出していますか？

発表には退会済みアカウントの扱いが書かれていないため、対象かどうかは現時点で判断できません。対象の表現は「個人アカウント最大約750万件」のみです。過去に登録した覚えがある人は、対象に含まれる場合を想定して偽の連絡に注意してください。確認が必要なら、公式発表にある個人ユーザー専用のフォームから問い合わせます。

個別の連絡が届いていなければ対象外ですか？

そうとは言えません。同社は対象者への個別連絡を順次実施するとしており、完了の時期は示されていません。連絡手段は電子メールなどと案内されています。届いたメールのリンクを開く前に、公式サイトのお知らせと内容が一致するか確かめてください。登録メールアドレスを長く使っていない人は、連絡が届かない可能性も考えておく必要があります。

銀行口座を変えたりパスワードを変更したりする必要はありますか？

発表は口座の変更を求めていません。暗証番号やパスワードは口座情報に含まれないとの説明です。不安がある場合は、通帳アプリなどで入出金を確かめ、心当たりのない動きがあれば金融機関に連絡します。シェアフルのログインパスワードについて発表に記載はないものの、同じパスワードを他のサービスで使い回しているなら変更しておくと安全です。

シェアフルから補償やお詫びの支払いはありますか？

11月10日時点の発表に、補償や金銭に関する記載はありません。原因究明と影響範囲の特定が続いている段階です。「補償金を受け取るために口座や暗証番号を入力してください」という連絡が届いても応じないでください。補償の案内が出る場合は、公式サイトのお知らせで確認できるはずなので、メールのリンクからではなく公式サイトを開いて確かめます。

シェアフルのアプリは今も使って大丈夫ですか？

同社は不正アクセスの経路を遮断したことを確認したうえで、サービスを通常どおり提供しています。「シェアフルシフト」では、現時点で不正アクセスは確認されていないとのことです。ただし原因の調査は続いています。利用を続ける場合も、アプリはストアや公式サイトから開き、メールやSMSに書かれたリンクからはログインしないようにしてください。

関連記事

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

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

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

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.07　コラム サイバーセキュリティ緊急対策パッケージとは？4本柱の施策と期限、企業と委託先が今やること
  2. 2025.04.30　テックブログ IMSIキャッチャー（偽基地局）とは？2Gフォールバックの手口と日本での対策
  3. 2026.11.06　テックブログ ドコモ不正アクセスの見舞金・対象確認とMy docomo再開状況：最大29.5万件の流出項目【11月9日第四報】
  4. 2026.11.06　テックブログ あいおいニッセイ同和の不正アクセス：44.4万件の漏えい項目と窓口、止まった手続きの代わり
  5. 2026.11.06　テックブログ TeamSpirit不正アクセス：28,824件流出の原因と利用企業の確認点、開発用サーバーの認証情報を守る実装

RELATED POSTS 関連記事

一覧へ戻る

目次