osinaの情報漏洩：約23万人の対象確認とSNS連携の解除、分析ツールへ渡すデータの絞り方

インフルエンサーマーケティングサービス「osina」を運営するNEL株式会社が、2026年10月29日に不正アクセスによる個人情報の流出を公表しました。入口は同社が利用していたデータ分析ツールの脆弱性で、対象者は速報時点で235,329人です。前半では公表文をもとに、自分がどの区分に入るか、漏れた項目、SNS連携の確認、口座を狙う連絡への注意、窓口を整理しました。後半では、分析ツールに本番データを渡している会社向けに、渡す列を許可リストで絞り、会員IDを仮名化するPythonの例を示します。

まとめ：osinaの情報漏洩で流出した項目と会員・取引先がまず行うこと

NEL株式会社の公表文によると、同社は10月14日に事案を発見し、10月17日に個人情報保護委員会へ速報を出しました。漏れた経路は「当社が利用していたデータ分析ツールの脆弱性を悪用した不正アクセス」と説明されています。ツールの名称と脆弱性の種類は、10月31日時点で公表されていません。

会員については、氏名・住所・電話番号・生年月日に加え、銀行口座情報（口座名義を含む）、報酬額、SNS連携用の認証情報まで対象です。一方、会員のメールアドレスとパスワードは同社が持っておらず、クレジットカード情報も扱っていないため対象外です。会員がまず行うことは2つあります。各SNSの連携アプリの設定でosinaとの連携を確かめること。口座の確認や再登録、振込を求める連絡に応じないことです。

会員と取引先が確かめること：4つの対象区分とSNS連携・口座を狙う連絡

osina会員・取引先担当者・問い合わせた人・提携候補クリエイターの4区分

区分(1)はosinaのアプリに登録している会員です。項目は登録状況によって異なり、ログイン用の外部サービスID（LINE・Apple）と利用履歴だけが対象の人もいると同社は書いています。口座を登録して報酬を受け取っていた人ほど、漏れた項目が多くなります。

区分(2)は広告主など取引先の担当者で、管理画面のログインに使うメールアドレスとハッシュ化済みのパスワードが含まれます。区分(3)は同社に問い合わせた人、区分(4)は同社が提携を検討していたクリエイターです。(4)はosinaに登録していなくても、活動名やSNSのURLが同社の候補リストにあれば対象に入ります。このほかIPアドレスなどの技術的な情報も含まれます。

SNS連携用の認証情報が対象の会員が連携アプリの設定から確かめる手順

今回の公表で最も注意が要るのは、SNS連携用の認証情報です。同社は、第三者が会員のSNSアカウントで投稿や閲覧を行うおそれがあると書いています。SNSのパスワードそのものではなく、osinaが会員の代わりにSNSを操作するために受け取っていた鍵が漏れた、という意味です。パスワードを変えてもこの鍵は無効にならない場合があります。

1. 連携しているSNSの公式アプリを開き、設定の「連携アプリ」や「アプリとウェブサイト」に当たる画面を探す
2. osinaとの連携が残っているかを確かめる
3. 身に覚えのない投稿・フォロー・プロフィールの変更がないかを見る
4. 心当たりがあれば連携を解除し、そのSNSのログイン履歴も確かめる

連携を解除すると、SNS側がその鍵を受け付けなくなります。キャンペーンへの参加でまた連携が必要になったら、サービス側の再開の案内を待ってから結び直してください。手順が分からない場合は、同社の窓口に問い合わせるよう公表文に書かれています。

銀行口座と報酬額を知られた会員が警戒する、口座の再登録や振込を求める連絡

口座番号と口座名義、報酬額がそろって漏れると、「報酬の振込に失敗したので口座を再登録してください」という連絡が本物らしく見えます。金額まで一致する連絡は、受け取った人が偽物だと疑いにくいものです。同社は、当社や金融機関を装って口座情報の確認・再登録や振込を求める連絡に注意するよう、名指しで呼びかけています。

同社は、メール・SNSのメッセージ・電話でパスワード、認証コード、銀行口座情報の入力や送金を求めることはないとしています。これを求められた時点で偽物と判断して構いません。身に覚えのない取引があったときは、金融機関の公式窓口に相談します。偽の連絡が成り立つ仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しました。

情報セキュリティ対応窓口と、退会済みの人や通知が届かない人の確認方法

対象者への連絡は、osinaアプリ内のお知らせ、プッシュ通知、メールなどで10月29日に済んだと同社は説明しています。退会済みなどで連絡が届かない人への案内先は、同社の説明では公表ページと窓口です。自分の対象情報の確認や被害の相談は、退会済みの人も含めて「NEL株式会社 情報セキュリティ対応窓口」がメールで受け付けます。受付は平日の10時から19時です。

取引先の担当者は、ハッシュ化済みのパスワードが漏れました。同じパスワードをほかの業務サービスで使っているなら、そちらを先に変えます。自分の対象情報と必要な対応は、同じ窓口に問い合わせるよう案内されています。

公表文から読む事案の構造：分析ツール経由で口座とSNSの鍵まで取られた意味

10月14日の発見から17日の速報、29日の公表までの時系列と未公表の点

発見から速報までは3日で、公表は発見の15日後です。公表時点で、新たな不正アクセスは確認されていないとしています。

235,329人は速報に書いた数字で、確定値ではありません。同社は被害範囲の調査を続けるとしています。以降は、公表された事実から読めることに絞ります。

口座情報とSNSの認証情報が分析ツールから取れる位置にあったことの意味

データ分析ツールは本来、会員数の推移やキャンペーンの成果を集計するための道具です。集計に口座番号やSNSの認証情報は要りません。それでも分析ツールの脆弱性から口座と認証情報まで取られたということは、それらが分析ツールから読める場所にあった可能性を示します。本番のテーブルを丸ごと分析用に複製したか、分析ツールに本番データベースへの接続権限を広く与えていたか、どちらかの形が考えられます。

どちらの形だったかを同社は説明しておらず、断定はできません。ただ、この構成は多くの会社で見られます。分析ツールは利用者の手元で設定されやすく、公開範囲や更新状況が本番システムほど厳しく管理されないためです。BIツールの脆弱性が入口になった別の事案はLEAN BODYの不正アクセスとMetabaseの脆弱性で扱いました。osinaの件で使われたツールが同じかどうかは公表されていません。

第三者のサービス経由でも報告対象、施行規則7条3号・4号と確報60日の期限

個人情報保護法施行規則の第7条は、委員会への報告が必要な事態を4つ挙げています。本件は、不正の目的をもって行われたおそれがある行為による漏えい（第3号）と、本人の数が1,000人を超える漏えい（第4号）に当たる事案です。ガイドライン（通則編）の3-5-3-1は、第3号の相手方に「第三者の提供するサービスを利用している場合における当該第三者」も含めています。外部のツールが破られても、データを預けた会社の報告義務は消えません。

速報の目安は、知った時点からおおむね3〜5日以内です。同社の3日はこの範囲に入ります。確報は第3号に当たるため60日以内で、10月14日から数えると12月中旬が期限です。報告と本人への通知の全体の流れは個人情報保護委員会への報告義務の実務にまとめました。

開発側の対策：分析ツールへ渡す列を許可リストで絞り、会員IDを仮名化する

本番テーブルを丸ごと複製する連携で、口座とトークンが分析側に残る構造

ここから先は、NEL株式会社の仕組みを推測するものではありません。分析ツールへの連携でよくあるのは、本番データベースのテーブルを夜間に丸ごと分析用へ複製する作りです。列を選ぶ手間がかからず、後から新しい集計をしたくなっても困りません。その代わり、本番に口座番号やSNSのトークンの列があれば、それも分析側にそのまま入ります。

分析側に入ったデータは、本番より多くの人が触り、本番より多くの経路から読めます。対策は2段です。分析側に秘密情報が入っていないかを定期的に点検すること。そもそも許可した列だけを書き出し、会員IDを分析側で元に戻せない値に置き換えることです。

分析側の秘密情報を見つけ、許可した列だけを書き出すPythonスクリプト

次のコードは、Pythonの標準ライブラリだけで実行できる構成です。auditモードは、分析用データベースの全テーブルの全列について、列名に token・password・bank などの語を含むか、値が32文字以上のランダムな文字列か（トークンの疑い）を調べ、該当があれば終了コード1を返します。exportモードは、許可リストにある列だけを本番から書き出し、会員IDをPythonのhmacで鍵付きのハッシュに置き換えます。鍵は環境変数で渡し、分析側には置きません。

# 分析ツールへ渡すデータを点検し、許可した列だけを仮名化して書き出す
# （Python 3.9以上・標準ライブラリのみ。SQLiteの例。BigQueryやRedshiftでも考え方は同じ）
# 使い方: python analytics_guard.py audit analytics.db          … 分析側に秘密情報らしき列が無いか調べる
#         python analytics_guard.py export prod.db analytics.db … 許可リストの列だけを書き出す
import hashlib, hmac, os, re, sqlite3, sys

# 分析に渡してよい列（テーブルごとの許可リスト）。ここに無い列は書き出さない
ALLOW = {
    "members": ["member_id", "prefecture", "birth_year", "joined_at"],
    "campaign_entries": ["member_id", "campaign_id", "status", "reward_yen", "entered_at"],
}
NAME_NG = re.compile(r"token|secret|password|passwd|bank|account_no|iban|card", re.I)
VALUE_NG = re.compile(r"^[A-Za-z0-9_\-\.]{32,}$")   # 長いランダム文字列＝トークンの疑い

def pseudo(member_id):
    key = os.environ["ANALYTICS_PEPPER"].encode()    # 鍵は分析側に置かない
    return hmac.new(key, str(member_id).encode(), hashlib.sha256).hexdigest()[:16]

def audit(db):
    con, hits = sqlite3.connect(db), 0
    for (table,) in con.execute("SELECT name FROM sqlite_master WHERE type='table'"):
        for col in [r[1] for r in con.execute(f"PRAGMA table_info({table})")]:
            sample = [r[0] for r in con.execute(f"SELECT {col} FROM {table} WHERE {col} IS NOT NULL LIMIT 200")]
            bad_values = sum(1 for v in sample if isinstance(v, str) and VALUE_NG.match(v))
            if NAME_NG.search(col) or bad_values:
                hits += 1
                print(f"NG {table}.{col}: name_match={bool(NAME_NG.search(col))} token_like={bad_values}/{len(sample)}")
    print(f"audit done: {hits} suspicious columns")
    return 1 if hits else 0

def export(src, dst):
    s, d = sqlite3.connect(src), sqlite3.connect(dst)
    for table, cols in ALLOW.items():
        d.execute(f"DROP TABLE IF EXISTS {table}")
        d.execute(f"CREATE TABLE {table} ({', '.join(cols)})")
        rows = [(pseudo(r[0]),) + tuple(r[1:]) for r in s.execute(f"SELECT {', '.join(cols)} FROM {table}")]
        d.executemany(f"INSERT INTO {table} VALUES ({', '.join('?' * len(cols))})", rows)
        print(f"exported {table}: {len(rows)} rows, {len(cols)} columns")
    d.commit()
    return 0

if __name__ == "__main__":
    sys.exit(audit(sys.argv[2]) if sys.argv[1] == "audit" else export(sys.argv[2], sys.argv[3]))

架空の会員5,000人で実行した結果と、点検で見つからない氏名・電話番号の扱い

動きを確かめるため、架空の会員5,000人とキャンペーン参加12,000件を入れたSQLiteを用意しました。会員テーブルには口座番号・口座名義・SNSのアクセストークンとリフレッシュトークンの列を持たせ、3人に2人がSNSを連携している設定です。本番を丸ごと複製した分析用データベース（analytics_naive.db）を点検し、次に許可リストで書き出し直しました。Python 3.14.7（Windows）で2026年10月31日に実行した結果です。

$ python analytics_guard.py audit analytics_naive.db
NG members.bank_account_no: name_match=True token_like=0/200
NG members.bank_holder: name_match=True token_like=0/200
NG members.sns_access_token: name_match=True token_like=200/200
NG members.sns_refresh_token: name_match=True token_like=200/200
audit done: 4 suspicious columns
$ echo $?
1
$ ANALYTICS_PEPPER="$PEPPER" python analytics_guard.py export prod.db analytics.db
exported members: 5000 rows, 4 columns
exported campaign_entries: 12000 rows, 5 columns
$ python analytics_guard.py audit analytics.db
audit done: 0 suspicious columns
$ echo $?
0

丸ごと複製した分析用データベースでは、口座の2列とトークンの2列が見つかりました。トークンの列は列名と値の両方で引っかかっています。列名を変えて隠しても、値の形で検出できるということです。許可リストで書き出した後は該当が0件になり、会員テーブルは10列から4列に減りました。会員IDは「91c82b29fa8e684e」のような16文字の値に置き換わり、鍵を持たない分析側からは元のIDに戻せません。

点検で見つからなかった列もあります。氏名と電話番号です。auditが探すのは、漏れるとすぐに不正利用される秘密情報だけで、氏名や電話番号は列名からも値からも判断しません。こちらは許可リストに載せないことで分析側に入れない、という役割分担です。ただし仮名化した会員IDも、本番と突き合わせれば本人に戻せるので、個人情報としての扱いは続きます。分析用データの法律上の位置づけは仮名加工情報の作成基準と分析基盤の設計要件で整理しました。

漏れたSNS連携トークンをRFC 7009の失効要求で無効にし、再連携させる流れ

トークンが分析側から漏れたと分かったら、サービス側でも全件を無効にします。OAuth 2.0には、クライアントが発行元に「このトークンはもう使わない」と伝える失効の仕組みがRFC 7009で定められています。送るのは失効させたいトークンと、その種類のヒントです。

# RFC 7009 の失効要求の形（発行元のエンドポイントとパラメータ名は各SNSの開発者向け文書で確かめる）
curl -X POST https://auth.example.com/oauth/revoke \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d "token=$REFRESH_TOKEN" \
  -d "token_type_hint=refresh_token"

RFC 7009では、発行元が200を返した後、クライアントはそのトークンを使ってはいけません。発行元の方針によっては、関連するトークンと認可そのものも一緒に無効になる仕組みです。失効させた会員には再連携を求め、保存するトークンは暗号化して鍵を別に管理します。鍵の入れ替えと失効の運用はOWASPのSecrets Management Cheat Sheetが項目を分けて示しています。アクセストークンを短命にしてリフレッシュトークンで更新する設計はリフレッシュトークンの寿命設計、認可の流れの基本はOAuth 2.0の仕組みと認可フローで解説しました。

外部SaaSを使う会社の判断：分析ツールに本番データを渡し続ける条件

分析ツールの公開範囲・版・アカウント・渡す列を棚卸しする5つの点検項目

外部の分析ツールを使っている会社が点検する項目を、優先度の高い順に並べました。上から2つは、今日のうちに確かめられます。

1番目は前の章のauditで機械的に確かめられます。SaaSの設定とOAuth連携の棚卸しを広く行う手順はSaaSセキュリティ対策の実装手順にまとめました。分析ツールがAPIで本番とつながっている場合の認可とトークン失効はAPI不正アクセス対策の実装手順で扱っています。

外部診断を急ぐべき連携構成と、年1回の定期診断で足りる連携構成

次のどれかに当てはまる会社は、外部の脆弱性診断を急いでください。本番のテーブルを丸ごと分析用に複製していること。分析ツールがインターネットから開け、版を誰が上げているか答えられないこと。口座やSNSのトークンなど、漏れるとすぐ不正利用される情報を平文で保存していることです。osinaの件は、この3つのうち1つでも当てはまれば同じ形で起こりえます。

許可リストで列を絞って会員IDを仮名化し、分析ツールを社内網か多要素認証の内側に置いているなら、年1回の定期診断で足ります。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準にまとめました。自社の分析ツールやデータ連携に同じ弱点が残っていないかを第三者に確かめてもらいたい場合は、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

osinaの情報漏洩について、会員や取引先から出やすい質問をまとめました。

自分がosinaの情報漏洩の対象かどうか、どうすれば分かりますか？

NEL株式会社は、対象者へosinaアプリ内のお知らせ、プッシュ通知、メールなどで10月29日に連絡したと説明しています。まずアプリのお知らせを確かめてください。退会済みで連絡が届かない人や、自分の対象情報を確かめたい人は、退会済みの人も含めて同社の情報セキュリティ対応窓口がメールで受け付けます。受付は平日10時から19時です。osinaに登録していなくても、提携候補のクリエイターとして活動名やSNSのURLが対象になっている場合があります。

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

会員についてはどちらも対象外です。同社は会員のメールアドレスとパスワードを持っておらず、クレジットカード情報も扱っていないと説明しています。ただし、ログイン用の外部サービスID（LINE・Apple）は対象項目に挙がっています。取引先の担当者はハッシュ化済みのパスワードが対象なので、同じパスワードをほかのサービスで使っていれば変更してください。

SNSとの連携は解除したほうがいいですか？

SNS連携用の認証情報が対象になっている会員は、各SNSの公式アプリの連携アプリの設定でosinaとの連携を確かめてください。身に覚えのない投稿や設定の変更があれば、連携を解除します。同社は、第三者が会員のSNSアカウントで投稿や閲覧を行うおそれがあると書いています。SNSのパスワードを変えるだけでは連携用の鍵が無効にならない場合があるため、連携の解除が確実です。

口座情報が漏れた場合、口座を変える必要はありますか？

口座番号と名義だけで預金を引き出すことはできないため、すぐに口座を変える必要はありません。警戒すべきは、口座の再登録や振込を求める偽の連絡です。同社は、パスワード・認証コード・銀行口座情報の入力や送金を求めることはないとしています。身に覚えのない取引があった場合は、金融機関の公式窓口に相談してください。

osinaで使われた分析ツールの名前と原因は分かっていますか？

10月31日時点で、ツールの名称、悪用された脆弱性の種類、侵入の期間は公表されていません。公表文にあるのは「当社が利用していたデータ分析ツールの脆弱性を悪用した不正アクセス」という説明までです。同社は発見後にアクセス制限などを行い、10月29日時点で新たな不正アクセスは確認されていないとしています。被害範囲の調査と再発防止策は続いており、新しい情報は同じ公表ページで知らせるとしています。

関連記事

• LEAN BODYの不正アクセスと約44万件の情報漏洩｜Metabaseの脆弱性とBIツールの公開設定・パッチ適用：分析ツールの脆弱性が入口になった別の事案
• SaaSセキュリティ対策の実装手順｜設定診断・OAuth棚卸し・ログ監視を解説：外部サービスの設定と連携の棚卸し
• リフレッシュトークンとは？トークンローテーションの仕組みと更新フロー・寿命設計を実装者向けに解説：漏れても被害を小さくするトークンの設計
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時に求められる報告と本人通知
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：診断を外注するときの判断