トップ/記事一覧/3年間、ゲームがあなたの「番号」を送っていた ― アプリの計測タグから識別情報が漏れる仕組みと防ぎ方
app-tracking-identifier-leak-cover-ja

3年間、ゲームがあなたの「番号」を送っていた ― アプリの計測タグから識別情報が漏れる仕組みと防ぎ方

LINEヤフーが「LINEポコポコ」など3作品で利用者の識別情報を約710万件、外部の広告ツールへ誤送信していた問題を入口に、『アプリの計測タグからなぜ識別情報が漏れるのか』『開発現場で意図しないデータ送信をどう防ぐか』を解説。内部識別子とは何か、名前も電話番号も含まないのに問題になる理由、3年10か月気づけなかったデータガバナンスの構造、開発者向けチェックリストと利用者の対処までまとめました。

まとめ2026年7月14日公開 本日更新
目次
この記事のポイント

LINEヤフーが「LINEポコポコ」など3作品で利用者の識別情報を約710万件、外部の広告ツールへ誤送信していた問題を入口に、『アプリの計測タグからなぜ識別情報が漏れるのか』『開発現場で意図しないデータ送信をどう防ぐか』を解説。内部識別子とは何か、名前も電話番号も含まないのに問題になる理由、3年10か月気づけなかったデータガバナンスの構造、開発者向けチェックリストと利用者の対処までまとめました。

2026年7月13日、LINEヤフーが、ゲーム「LINEポコポコ」など3作品で、利用者を識別する情報を約710万件、外部の広告用ツールへ誤って送信していたと発表し、謝罪しました。送信は2022年から3年10か月続いていました。漏れたのは氏名や電話番号ではなく「内部識別子」という文字列で、外部からの攻撃でもなく、設定の確認不足が原因とされています。

この記事では、この事案をもとに2つの点を実務の視点で整理します。1つは「アプリの計測タグから、なぜ利用者の識別情報が漏れるのか」、もう1つは「開発の現場で、この意図しないデータ送信をどう防ぐのか」です。氏名も電話番号も含まない文字列がなぜ問題になるのか、そして攻撃でもないのに情報が3年以上流れ続けた理由も、あわせて見ていきます。専門用語には短い説明を添えます。

何が起きたのか

公表された事実を整理します。以下はすべてLINEヤフーの公式発表にもとづくもので、推測は含めていません。

対象アプリ件数(概数)送信されていた期間
LINEポコポコ約547万件2022/5/25〜2026/4/2
LINEポコパンタウン約79万件2022/5/25〜2026/4/3
LINEポコパン(提供終了済み)約84万件2022/5/25〜2025/6/11
合計約710万件実ユーザー 約610万人

経緯はこうです。2022年5月25日に外部の広告用ツールへの送信が始まり、2026年4月1日にLINEヤフーが問題を発見して調査を開始、4月3日に送信を止める修正を完了しました。およそ3年10か月にわたって、本来送るべきでない識別情報が利用者の端末から自動で送られ続けていたことになります。対象は約710万件、重複を除いた実際の利用者は約610万人(うち国内が約574万人)と説明されています。

この件は、外部からの攻撃(不正アクセス)ではありません。LINEヤフーは原因を、外部の広告計測ツールの設定を変更した際に、本来は送信すべきでない「内部識別子」が利用者の端末から自動的に送られ、それが自社と連携先の双方で設定確認が不十分だったために起きた、と説明しています。攻撃者に盗まれたのではなく、自分たちの設定で送る状態になっていた、という構図です。送信先の外部ツール提供者は当該情報をすでに削除しており、不正利用や二次被害は確認されていないとしています(いずれも公式発表)。

「内部識別子」とは何か。なぜ問題になるのか

漏れたのは氏名でも住所でも電話番号でもクレジットカード番号でもなく、「内部識別子」というランダムな文字列です。それでも問題になる理由を、識別子のしくみから説明します。

内部識別子とは「利用者に振られた背番号」

内部識別子とは、サービスがシステム上で一人ひとりの利用者を区別するために振る、背番号のような文字列です。LINEヤフーも「システム上でユーザー個人を識別するためのランダムな文字列で、友だち追加などに使うLINE IDとは別物」と説明しています。それ自体は「12345…」のような符号で、文字列を見ただけではどこの誰かは分かりません。LINEヤフーも「匿名性が高く、この情報単体では外部の第三者が特定の個人と結びつけることはできない」としています(公式説明)。

問題は「単体」ではなく「突き合わせ」で生まれる

識別子の懸念は、それ単体ではなく、他の情報と突き合わせたときに生まれます。同じ識別子が複数のサービスやアプリをまたいで使い回されると、「同じ人が、どのアプリで、いつ、何をしたか」を横串で追える名寄せ(別々のデータを同一人物のものとして束ねること)が可能になります。とくに広告の分野では、この人をまたいで追跡できる番号に価値があります。識別子が広告システムへ渡ると、意図しない形で利用者の行動が結び付けられる素地ができます。個々の文字列は無害に見えても、集めて突き合わせれば個人の輪郭が浮かびます。識別子がプライバシー保護で慎重に扱われるのは、このためです。

ただし、今回の件でLINEヤフーは実際の被害は確認されていないとし、送信先も情報を削除済みです。「実害が出た」と受け取るのは正確ではありません。一方で、実害が確認されていないことと、そもそも送るべきでない情報が3年以上流れていたことは別の問題です。この記事で扱うのは後者、つまりなぜそれが起き、どう防ぐかです。

なぜ計測タグから情報が漏れるのか

現代のアプリやWebサービスは、ほぼ例外なく利用状況を計測しています。その計測を担うのが計測タグ/SDK(アプリに組み込む、行動データを集めて外部の分析・広告ツールへ送る小さな部品。タグはWeb向け、SDKはアプリ向けの呼び方)です。ここで、なぜ余計な情報まで送られてしまうのかを見ます。

計測タグは「何を送るか」を設定で決めている

計測タグは、利用者の端末から広告・分析ツールへどの項目(フィールド)を送るかを設定で決めています。画面の表示回数やクリックだけを送るつもりでも、設定を一つ変えた拍子に、本来は送る必要のない項目、たとえば内部識別子まで一緒に送られることがあります。今回LINEヤフーが「設定変更の際の確認不足」と説明したのは、この部分です。送信は端末側で自動的に行われるため、いったん送る設定になると、誰かが気づいて止めるまで送られ続けます。攻撃のような目立つ痕跡は残りません。

端末から直接送る設計が、事故を見えにくくする

もう一つの弱点は、送信が利用者一人ひとりの端末から直接、外部ツールへ飛ぶ点です。この方式(クライアントサイド計測)は手軽な反面、実際に何が外へ出ているかを提供側が把握しづらくなります。これに対し、いったん自社サーバーを経由させ、そこで送るデータを取捨選択してから外部へ渡す方式(サーバーサイド計測)なら、送信内容を一元的に制御・監査できます。当ブログのサーバーサイドでのタグ管理(サーバーサイドGTM)の解説でも触れたとおり、何を外に出すかを自分の手元で握ることは、意図しない送信を防ぐ有効な手段です。

なぜ3年10か月も気づかなかったのか

この件で重いのは、期間の長さです。数日でも数週間でもなく、3年10か月に及びました。その背景には、多くの組織に共通する「データの流れを管理しきれていない」という問題があります。

LINEヤフーは、この送信の事実が自社のプライバシーセンター(利用者にデータの取り扱いを説明する公式の記載)に記録されていなかったとも説明しています。送っているはずのないデータが、記録にも残らないまま送られていたことになります。これは単なる設定ミスではなく、「自分たちがどのデータを、どこへ、なぜ送っているか」の全体像(データマッピング)が更新され続けていなかったことを意味します。送信先の棚卸しがなければ、余計な項目が混じっても気づけません。設定変更のたびに送信されるデータの差分を確認する仕組みがなければ、変更はそのまま通り抜けます。

現場の視点:計測タグやSDKは、入れたあと放置されがちです。マーケティング側が広告最適化のために足し、開発側は言われるまま組み込み、数年後には、なぜこのツールにどの項目を送っているのかを誰も正確に説明できなくなります。増改築を重ねたアプリでよく見る状況です。しかも計測は動いていても業務に困らないため、点検の優先度が上がりません。見えていないデータの流れは、事故が起きて初めて見えます。だからこそ、平時に送信先とフィールドの棚卸しを仕組みとして回しておくことが効きます。

開発現場で同じ事故を防ぐには

意図しないデータ送信を防ぐ出発点は、どの計測タグ・SDKが、どの外部ツールへ、どの項目を送っているかを一覧にした棚卸し表(データマッピング)を作ることです。これが無ければ、余計な項目が混じっても気づけません。そのうえで、タグの設定を変えたら、実際に外へ出るデータが変わっていないかをリリース前に確認します。今回すり抜けたのは、まさにこの差分の確認でした。送る項目は、計測に必要なものだけを許可リスト方式で通し、内部識別子のような機微な項目は既定でブロックしておくと、安全側に働きます。

さらに堅くするなら、端末から直接外部へ送るのではなく、いったん自社サーバーを経由させて送信内容を制御・記録するサーバーサイドでのタグ管理が有効です。設定上どうなっているかだけを見るのではなく、テスト環境で端末から出ていく通信を実測し、想定外の項目が混じっていないかを定期的に確認します。そして、送っているデータは必ずプライバシーの記載(データの取り扱い説明)に反映し、記載に無いのに送っている状態をなくします。記載との突き合わせは、棚卸し漏れを見つける手がかりになります。

根底にある考え方はプライバシー・バイ・デザイン(サービスを作る最初の段階から、データ保護を設計に組み込む考え方)です。あとで点検するのではなく、そもそも余計なものが出ていかない構造にしておきます。計測は事業に不可欠ですが、集めていいデータと外へ渡していいデータは違います。この線引きを設計として持つことが、同じ事故を防ぐ近道です。

利用者はどうすればいいのか

今回のケースについては、利用者側で必要な対応は特にありません(公式)。漏れたのはランダムな内部識別子で、氏名やパスワード、決済情報は含まれておらず、送信先も情報を削除済み、不正利用も確認されていないためです。パスワード変更などを慌てて行う必要はありません。

より一般的な話として知っておきたいのは、無料のアプリやサービスは、多かれ少なかれ利用者の行動データを計測し、外部の分析・広告ツールへ送っているという点です。今回はその送信に不備が混じった例ですが、正常な計測でも一定のデータは外へ流れています。気になる場合は、スマホの設定にある広告識別子のリセットやトラッキングの制限(iPhoneの「Appにトラッキングしないよう要求」Androidの広告ID設定など)を使うと、アプリをまたいだ追跡をある程度抑えられます。特定のアプリだけを責めるより、自分の行動データはどこかへ送られている前提で、コントロールできる範囲を押さえておくほうが現実的です。

まとめ ― いま押さえておきたいこと

この事案から得られる論点は2つです。「アプリの計測タグから、なぜ識別情報が漏れるのか」は、送るデータを設定で決めているというしくみの理解に尽きます。「その意図しない送信をどう防ぐのか」は、データマッピング・差分レビュー・最小化・サーバーサイド計測・定期監査という地道な運用で対応できます。いずれも今日から着手できます。

攻撃されたわけでもないのに、識別情報が3年以上流れ続ける。こうした目立たない事故を防げるかどうかは、自分たちがどのデータをどこへ送っているかを平時に把握しているかで決まります。集めることと外へ渡すことの線引きを設計に組み込むことが、最初の一手になります。

よくある質問

「内部識別子」が漏れると、名前や個人情報がバレるのですか?

内部識別子はランダムな文字列で、それ単体では特定の個人と結びつきません(公式説明)。今回は氏名・住所・電話番号・決済情報・LINE IDは含まれていません。ただし、識別子が複数のサービスをまたいで突き合わされると、行動を横串で追える名寄せの素地になり得るため、慎重に扱うべき情報とされています。

利用者は何かする必要がありますか?

今回のケースでは、特に必要な対応はありません(公式)。送信先は情報を削除済みで、不正利用も確認されていません。より一般的な対策として、スマホの広告識別子のリセットやトラッキング制限を使うと、アプリをまたいだ追跡を抑えられます。

なぜ攻撃でもないのに情報が漏れたのですか?

外部の広告計測ツールの設定を変更した際に、本来送るべきでない内部識別子が利用者の端末から自動送信されたためです。自社と連携先の双方で設定確認が不十分だったと説明されています。攻撃ではなく、送信設定の不備が原因です。

開発者として、同じ事故を防ぐ一番効く対策は?

まず「どのタグ・SDKが、どの外部ツールへ、どの項目を送っているか」の棚卸し(データマッピング)です。そのうえで、設定変更時に送信データの差分をレビューし、識別子など不要な項目は既定で送らない最小化を徹底します。サーバーサイド計測で送信を一元管理できれば、さらに堅牢になります。

更新履歴

  • 2026-07-14初版公開。LINEヤフーのゲーム3作品での識別情報誤送信(約710万件)をもとに、計測タグから情報が漏れるしくみと、開発現場での防ぎ方を解説。
  • 追記予定個人情報保護委員会への報告や行政対応の続報、LINEヤフーの追加説明が出しだい追記します。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go