--- title: "TONARIWA不正アクセス：LINE連携トークン漏えいの恐れと利用企業の失効手順" url: "https://www.issoh.co.jp/tech/details/19644/" published: 2026-11-12 updated: 2026-11-12 categories: ["セキュリティ"] publisher: "株式会社一創" --- # TONARIWA不正アクセス：LINE連携トークン漏えいの恐れと利用企業の失効手順 電通デジタルが提供するLINE公式アカウント向けのマーケティングプラットフォーム「TONARIWA」が第三者の不正アクセスを受け、2026年11月11日にサービスの停止と個人情報漏えいの可能性が公表されました。漏えいの可能性があるのは、一部のクライアント企業が扱うエンドユーザーの氏名・生年月日・連絡先などと、LINE公式アカウント連携用のアクセストークンなどです。本記事の前半では、公式発表で確かめられる原因・項目・時系列と、友だち登録をしていた利用者が不審なメッセージを見分ける点を整理します。中盤はTONARIWAを使う企業の担当者向けに、報告と告知の段取りをまとめました。後半は開発者向けに、LINEのチャネルアクセストークンを取り消し、チャネルシークレットを再発行し、身に覚えのない配信を送信数で照合する手順をコマンド例で示します。 ## まとめ：TONARIWA不正アクセスで公表された事実と利用企業・友だち登録者の対応 原因は、システム基盤で使われていた管理アカウントの認証情報が漏れ、侵入した第三者が権限昇格まで行ったことです。電通デジタルは全サーバーを止めてシステムを隔離しており、再開の時期は決まっていません。 | 項目 | 公表内容（2026年11月11日掲載） | | ---------- | --------------------- | | 不正アクセスの確認 | 11月10日 | | 原因 | 管理アカウントの認証情報の漏えいと権限昇格 | | エンドユーザーの情報 | 氏名・生年月日・連絡先などの属性情報 | | LINE連携の情報 | 連携用アクセストークンなどの管理用情報 | | カード・口座情報 | 対象外と確認済み | | 対象企業と件数 | 特定作業中 | | サービス再開 | 未定（外部機関の検証後に案内） | 利用企業が最初に確かめるのは、自社のLINE公式アカウントの連携情報が対象に入っているかです。電通デジタルからの個別説明を待つ間にも、トークンの取り消しとチャネルシークレットの再発行は自社の権限で進められます。友だち登録をしていた利用者は、公式アカウントから届いたメッセージでも、ログインや決済情報の入力を求めるリンクは開かないことが当面の備えになります。 ## 公式発表で確かめるTONARIWA不正アクセスの原因・漏えい項目・時系列 ### 管理アカウントの認証情報漏えいと権限昇格という公表された原因 [電通デジタルのお詫びとご報告](https://www.dentsudigital.co.jp/news/updates/services/2026-1111-001111)によると、不正アクセスはシステム基盤で使われている管理アカウントの認証情報が漏えいしたことで起き、さらに操作できる範囲を広げる権限昇格が行われていました。認証情報がどこから漏れたのか、侵入がいつ始まったのかは公表されていません。 このお知らせは、停止の措置と並行して進めたログ解析などの調査の中で、個人情報が外部に漏れた可能性が分かったと説明しています。つまり、最初に検知したのは不正アクセスで、漏えいの可能性はその後の調査で判明した順番です。 ### エンドユーザーの氏名・生年月日とLINE連携トークンに分かれる漏えい項目 漏えいの可能性がある情報は、性質の違う2系統に分かれます。1つは、一部のクライアント企業が扱うエンドユーザーの氏名・生年月日・連絡先などの属性情報です。もう1つは、LINE公式アカウントとの連携に使うアクセストークンなどの管理用アカウント情報です。クレジットカード情報と金融機関の口座情報は、対象に含まれないことが確認されています。 実害の出方が大きく違うのは後者です。属性情報の漏えいは、なりすましの電話やメールの材料になります。連携用のトークンは、それ自体がLINE公式アカウントからメッセージを送る鍵です。電通デジタルも、悪用の事実は確認していないとしながら、LINE連携情報を使った不正なメッセージ配信のリスクは排除できないと書いています。 ### 11月10日の確認から全サーバー停止、日本郵便ぽすくまの停止までの時系列 1. 11月10日：TONARIWAへの第三者による不正アクセスを確認し、サービスを一時停止 2. 同時期：不正に使われた認証情報の即時失効と通信経路の遮断、全サーバーの停止によるシステムの隔離 3. 11月11日14時20分頃：日本郵便のLINEアカウント「郵便局\[ぽすくま\]」が緊急メンテナンスで利用停止 4. 11月11日：電通デジタルがお詫びとご報告を掲載し、日本郵便も委託先での不正アクセスを公表 [日本郵便のお知らせ](https://www.post.japanpost.jp/newsrelease/pressrelease/685401036.html)によると、同社は「郵便局\[ぽすくま\]」のアンケートの実施と回答内容の管理などにTONARIWAを使っていました。利用者には当面、コーポレートサイトを使うよう案内しています。電通デジタルは外部のフォレンジック調査会社によるログ解析を進めており、本記事は11月12日に公式ページを確認した時点の内容です。その時点で続報は出ていませんでした。 ## 友だち登録していた利用者がLINEの不正メッセージを見分ける確認点 ### 公式アカウントから届いたメッセージで入力を求められたときの判断基準 今回のリスクが厄介なのは、不正なメッセージが本物の公式アカウントから届く可能性がある点です。連携用のトークンが悪用されると、送信元の表示も、トーク履歴の並びも普段と同じになります。送信元の名前やアイコンで本物かどうかを判断する方法は通用しません。 見分ける基準は内容の側に置きます。メンテナンスの案内、荷物の確認、当選やポイント付与などを理由に、ログイン情報・認証コード・クレジットカード番号の入力を求めてくるメッセージは開かないでください。確かめたいときは、メッセージ内のリンクではなく、企業の公式サイトやアプリを自分で開いて同じ案内が出ているかを見ます。日本郵便のように、公式サイトでLINEアカウントの停止を告知している企業もあります。 自分の氏名や生年月日が対象に入ったかは、TONARIWAを使っていた企業からの案内で確かめることになります。電通デジタルのお知らせに、エンドユーザーが直接照会する窓口は示されていません。 ## TONARIWA利用企業が今週進める報告・告知・トークン再発行の段取り ### 個人情報保護委員会への報告で利用企業が委託元として負う責任の範囲 電通デジタルは、個人情報保護委員会などへの報告に向けてクライアント企業と連携・調整を進めるとしています。エンドユーザーの情報を預けていたのは利用企業なので、報告と本人への通知は、委託元である利用企業の側にも求められます。 [個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正アクセスのように不正の目的によるおそれがある漏えいは、件数にかかわらず報告の対象です。確報の提出期限は、発覚から60日以内です。対象企業と件数の特定は電通デジタル側で続いているため、速報の段階では「特定中」と書いて出し、確報で数値を埋める流れになります。速報と確報の書き方は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。 ### 友だちへの告知を公式サイトで先に出す理由と告知文に載せる4項目 告知の手段で迷うのは、普段使っているLINE公式アカウントそのものが疑われている点です。LINEで「不審なメッセージに注意」と送っても、受け取る側は本物か判断できません。公式サイトにお知らせを先に載せ、LINEのメッセージからはそのページへ誘導する形にすると、正規の連絡を見分けやすくなります。 - TONARIWAへの不正アクセスが原因であることと、自社のアカウントが対象かどうか - 漏えいの可能性がある項目（氏名・生年月日・連絡先のどれを預けていたか） - 自社が送らない内容（ログイン情報やカード番号の入力をLINEで求めないこと） - 問い合わせ窓口と、LINE公式アカウントを再開するときの告知場所 3つ目の「送らない内容」を明記しておくと、友だちが不正なメッセージを受け取ったときに自分で判断できます。 ## LINEチャネルアクセストークンの種類と漏えい時に失効させる手順 ### 長期・短期・v2.1・ステートレスで異なる有効期間と取り消しの可否 TONARIWAから漏れた可能性があるトークンの種別は公表されていません。[LINE Developersのチャネルアクセストークンの説明](https://developers.line.biz/ja/docs/basics/channel-access-token/)によると、Messaging APIのトークンは4種類あり、漏えい時に打てる手が種類ごとに違います。 | 種類 | 有効期間 | 発行数の上限 | 取り消し | | ------------- | -------- | ---------------- | ------ | | 長期 | 無期限 | チャネルごとに1件 | いつでも可能 | | 短期 | 30日 | 30件（超えると最古を取り消し） | 可能 | | 任意の有効期間（v2.1） | 最大30日で指定 | 30件（超えると発行を拒否） | 可能 | | ステートレス | 15分 | 無制限 | 不可 | 最も危ないのは長期トークンで、取り消すまでは有効期限のない状態です。長期トークンを再発行すると、現在有効な長期トークンは無効になります。ただし再発行の際には現行トークンの有効期間を最大24時間まで延ばす選択肢があるため、漏えいへの対応では延長しないで発行します。 ### curlでトークンの有効性を確かめ、v2の短期・長期トークンを取り消す手順 連携先に渡していたトークンが手元に控えてあれば、まだ有効かをAPIで確かめ、有効なら取り消します。[Messaging APIリファレンス](https://developers.line.biz/ja/reference/messaging-api/)に記載されているエンドポイントを呼び出す手順です。`{channel access token}`は控えてあるトークンに置き換えてください。 ``` # 1. 短期・長期トークンの有効性を確かめる（200 なら有効。expires_in は残りの有効期間） curl -X POST https://api.line.me/v2/oauth/verify \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'access_token={channel access token}' # 2. 短期・長期トークンを取り消す（200 と空のボディが返る） curl -X POST https://api.line.me/v2/oauth/revoke \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'access_token={channel access token}' # 3. v2.1 トークンを使っている場合：有効なキーIDの一覧を出して数を確かめる # client_assertion は自社の秘密鍵で署名した JWT curl -G https://api.line.me/oauth2/v2.1/tokens/kid \ --data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \ --data-urlencode 'client_assertion={JWT}' ``` 注意点は、取り消しAPIが無効なトークンを渡してもエラーを返さないことです。200が返っても取り消せた証明にはならないため、取り消しの後に1本目の検証をもう一度流し、400（無効・期限切れ）に変わったことの確認が必要です。手元にトークンの控えが無い場合は、LINE Developersコンソールで長期トークンを再発行すれば、漏れた長期トークンは無効になります。上のコマンドは本記事の環境では実行しておらず、リファレンスの記載に基づきます。 ### チャネルシークレットの再発行とWebhook署名検証のやり直し トークンを取り消しただけでは足りない場合があります。ステートレストークンは、チャネルIDとチャネルシークレットがあれば`https://api.line.me/oauth2/v3/token`へ`grant_type=client_credentials`で発行でき、取り消せません。連携のためにチャネルシークレットも預けていたなら、攻撃者は15分ごとに新しいトークンを作り続けられることになります。電通デジタルは漏えいの可能性がある項目を「アクセストークン等」と書いており、シークレットが含まれるかは明示していません。預けていたなら再発行の対象に入れます。 [LINE Developersの署名検証の説明](https://developers.line.biz/ja/docs/messaging-api/verify-webhook-signature/)によると、チャネルシークレットはコンソールの「チャネル基本設定」タブからAdmin権限で再発行でき、新しいシークレットを発行すると現在のシークレットは無効になります。同じシークレットはWebhookの署名検証の鍵でもあるため、自社サーバーで受けているWebhookの検証も新しい値に切り替えます。 ``` # Webhook の署名検証（Python 3 標準ライブラリのみ） # LINE_CHANNEL_SECRET には再発行後のチャネルシークレットを環境変数で渡す import base64, hashlib, hmac, os def verify_line_signature(body: bytes, signature: str) -> bool: secret = os.environ["LINE_CHANNEL_SECRET"].encode("utf-8") digest = hmac.new(secret, body, hashlib.sha256).digest() expected = base64.b64encode(digest).decode("utf-8") # x-line-signature ヘッダーの値と、タイミング差の出ない比較で突き合わせる return hmac.compare_digest(expected, signature) ``` 入力にはリクエストボディを受け取ったままのバイト列で渡し、JSONとして読み込んだ後の値は使いません。シークレットを切り替えた直後にWebhookが401や400で落ち始めたら、古いシークレットがどこかに残っている合図です。このコードは本記事の環境では実行していません。 ### 送信済みプッシュメッセージ数のAPIで身に覚えのない配信を照合する方法 トークンが悪用されたかどうかは、自社が送った数とLINE側が数えた数を突き合わせると確かめられます。リファレンスには、プッシュメッセージで送られた数を日付ごとに返すエンドポイントと、当月の送信数を返すエンドポイントがあります。 ``` # 指定日（yyyyMMdd・日本時間）にプッシュで送られたメッセージ数 curl -G https://api.line.me/v2/bot/message/delivery/push \ -H 'Authorization: Bearer {channel access token}' \ --data-urlencode 'date=20261110' # 当月に送信されたメッセージ数（概算） curl https://api.line.me/v2/bot/message/quota/consumption \ -H 'Authorization: Bearer {channel access token}' ``` 1本目は`status`が`ready`のときだけ`success`に件数が入ります。TONARIWAの停止後は自社から配信していないはずの日に件数が立っていれば、誰かが送ったと判断できます。照合には新しく発行したトークンを使い、漏れた可能性のあるトークンでは呼びません。このコマンドも本記事の環境では実行していません。 ## 外部のLINE運用基盤に預ける認証情報の判断と自社で持つべき範囲 ### 連携先に長期トークンとシークレットを預けない設計と、その例外 今回の事案で効いてくるのは、連携先に何を渡していたかです。長期トークンは無期限、ステートレストークンはシークレットさえあれば作り直せるため、この2つを外部の運用基盤に預けていると、漏えいから取り消しまでの間ずっと配信の鍵が相手の手にあります。v2.1のトークンなら最大30日の期限を自社で決められ、キーIDの一覧で発行済みの本数も把握できます。 ただし、配信ツールの多くは長期トークンとシークレットの登録を前提にしています。月に数回の一斉配信しかなく、専任の開発者もいない企業が、トークンを自前で発行して渡す仕組みを作るのは過剰です。その場合は、トークンを預けている連携先を一覧にし、担当者が替わったときや連携をやめたときに再発行する運用を決めておくほうが効果は大きくなります。鍵の棚卸しと失効の手順は[APIキー管理の発行・保管・失効](https://www.issoh.co.jp/tech/details/16300/)でまとめています。 ### LINE公式アカウントと会員DBをつないだ自社システムで見直しを急ぐ構成 見直しを急ぐべきなのは、LINE公式アカウントの配信と、会員データベースや予約システムを外部の基盤経由でつないでいる構成です。点検は3点に絞れます。連携先に預けているのは長期トークンかシークレットか、連携先の管理画面のアカウントに多要素認証がかかっているか、配信数を自社の記録と照合する仕組みがあるか、です。TONARIWAの原因が管理アカウントの認証情報だったことを考えると、2点目は委託先任せにできません。委託先のアカウントを監視する考え方は[JAL不正アクセスと委託先アカウントの監視](https://www.issoh.co.jp/tech/details/19621/)でも扱っています。 設定は担当者が自分で確かめられますが、連携の経路に外から突ける穴があるかは、運用担当者だけでは判断しにくい領域です。LINE連携を含む業務システムの認証情報の扱いを外部の目で点検するなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 TONARIWAへの不正アクセスについて、利用企業の担当者や友だち登録をしていた利用者から出やすい質問をまとめました。 ### TONARIWAの不正アクセスで漏れた可能性がある情報は何ですか？ 一部のクライアント企業が扱うエンドユーザーの氏名・生年月日・連絡先などの属性情報と、LINE公式アカウント連携用のアクセストークンなどの管理用アカウント情報です。クレジットカード情報と金融機関の口座情報は含まれないことが確認されています。対象となる企業と件数、詳しいデータ項目は、11月11日の発表時点で特定作業が続いています。 ### LINEで友だち登録していただけでも自分の情報は漏れましたか？ 全ての友だち登録者が対象とは限りません。TONARIWAを使っていた企業が、氏名や生年月日などをどこまで預けていたかによって変わります。自分が対象かは、その企業からの案内で確かめます。電通デジタルのお知らせに、利用者が直接照会する窓口は示されていません。 ### TONARIWAはいつ再開しますか？ 11月11日の発表では再開時期は未定です。電通デジタルは、原因調査を踏まえたセキュリティ対策の強化と、外部機関による安全性の検証を経て、見通しが立ちしだい案内するとしています。日本郵便の「郵便局\[ぽすくま\]」も、再開時はコーポレートサイトで知らせるとしています。 ### LINE公式アカウントから不審なメッセージが届いたらどうすればよいですか？ ログイン情報・認証コード・カード番号などの入力を求めるリンクは開かず、企業の公式サイトやアプリを自分で開いて同じ案内があるかを確かめてください。連携用のトークンが悪用されると、本物の公式アカウントから届くため、送信元の表示では見分けられません。入力してしまった場合は、そのサービスのパスワード変更とカード会社への連絡を急ぎます。 ### 利用企業はチャネルアクセストークンを再発行すれば十分ですか？ 連携先にチャネルシークレットも預けていた場合は不十分です。チャネルIDとシークレットがあれば、取り消せないステートレストークンを15分単位で発行し続けられるためです。長期トークンの再発行に加えて、シークレットを再発行し、Webhookの署名検証も新しい値に切り替えます。その後、送信済みメッセージ数を自社の記録と照合して悪用の有無を確かめます。 ## 関連記事 - [ブラストメール不正アクセス：421契約の配信先漏えいと、ピッコマ・エックスサーバーなど利用企業の公表、報告・通知の手順](https://www.issoh.co.jp/tech/details/18827/)：配信サービスの委託先が侵入された同時期の事例 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：トークン失効を含むAPI側の防御 - [情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】](https://www.issoh.co.jp/column/details/18315/)：委託先経由を含む漏えいの防ぎ方 - [LINEミニアプリとは？未認証と認証済みの違い・LIFFとの使い分け・審査と開発費用【2026年版】](https://www.issoh.co.jp/column/details/15161/)：LINE上の顧客接点を自社で作る場合の選択肢 - [APIキー管理とは？発行・保管・失効とローテーションの実装を解説](https://www.issoh.co.jp/tech/details/16300/)：預けた鍵の棚卸しと失効の手順 --- 出典: [TONARIWA不正アクセス：LINE連携トークン漏えいの恐れと利用企業の失効手順]()（株式会社一創）