LINEログインとMessaging APIでユーザーIDが違うとき｜プロバイダーの確認順

同じ人であっても、LINEのユーザーIDはプロバイダーが違うと別の値になります。LINEログインで取得したIDとMessaging APIのWebhookで取得したIDを比べるときは、まず両方のチャネルが、どのプロバイダーに属するかを確認してください。

同じプロバイダー配下であれば、チャネルの種類が違っても同じユーザーには同じIDが割り当てられます。IDの文字列を加工して合わせたり、表示名が似ている人を同じ会員へ結び付けたりする方法は使いません。

「チャネルが違う」と「プロバイダーが違う」は別

プロバイダーはサービス提供者を表し、チャネルはLINEログインやMessaging APIなどの機能を使うための単位です。LINE DevelopersのユーザーIDの説明で、IDがプロバイダー単位に発行されることを確認できます。表示名や、友だち検索に使うLINE IDとも別です。

同じ公式アカウントに見える導線でも、Webサイトのログイン先が別のLINEログインチャネルになっていることがあります。画面の名前やロゴだけで構成を判断せず、開発者が確認できるチャネルIDと所属を照合します。

図：同じ人が操作した場合のIDの関係を、プロバイダーの範囲で分けています。図中のID名は説明用です。会員との対応付けと、情報を使える範囲は別に確認します。

図解画像を開く（保存用）

IDを比較する前に、この順番で確かめる

開発や運用を依頼している場合は、秘密のトークンや実顧客のIDをメールで集めるより、まず設定の対応表を作ってもらいます。

この表にチャネルシークレットやアクセストークンを書き込む必要はありません。設定を確かめる人が正規の管理画面を見られる範囲で、識別子と所属だけを整理します。

同じプロバイダーなのに一致しなければ、同じLINEアカウントで操作したか、想定したログイン先へ遷移したか、別環境の記録を比べていないかへ戻ります。名前の一致を根拠に、片方のIDで上書きしないでください。

違うプロバイダーだった場合、移動で直せるとは考えない

公式のプロバイダー設計の案内では、作成済みのチャネルをあとから別のプロバイダーへ移動できないと説明されています。連携予定のチャネルは作成前に構成を決める必要があります。

すでに運用中なら、先にチャネルを削除したり、新しいチャネルを作って接続先を一括変更したりしないでください。会員ログイン、Webhook、友だち追加の導線、保存済みのID対応表など、影響を受ける場所を洗い出します。利用者がいる環境では、旧データの保全と、移行が必要な人への案内も別の仕事です。

委託先が管理している場合は、「このサービスの提供主体は誰か」「どのプロバイダーの下に作られているか」を担当者と確認します。今の不一致を消すことだけに集中せず、今後の運用者が構成を追える記録を残してください。

IDが一致しても、会員情報まで自動でそろうわけではない

LINEのユーザーIDが同じ値になったことは、自社の会員・注文・予約を本人へ正しく結び付けた証拠とは別です。たとえば、家族が同じ端末で会員サイトを使う場合、直前にログインしていた会員へ無条件に結び付けると、別の人の情報が表示される可能性があります。

一人のお客様の情報を一つのIDへつなぐために、本人確認を伴う対応関係を作ります。何をつなぎ、どの目的と権限で見せるかを決めたうえで、ID連携の実装方法を選んでください。同じプロバイダー配下でも、複数サービス間の情報を無条件に共通利用できるわけではありません。公式の設計案内にあるポリシーと所定の利用条件を、実装前に確認します。

本番の情報を使わずに、境界を試す

自社で用意したテストアカウントを使い、同じプロバイダー、別のプロバイダー、ログインとチャットで違うLINEアカウント、検証用と本番の取り違えを確かめます。期待する一致だけでなく、不一致のときに会員の情報を表示しないことまで確認してください。

確認結果は、チャネルの所属、試した条件、IDの一致・不一致、会員の連携状態を分けて残します。相談中のお客様には、内部構成の説明や情報の再入力を何度も求めるより、必要な本人確認と次の案内を短く返せるように整えます。誤って統合しないための確認待ちの扱いは、顧客データ統合の確認手順で整理しています。

※仕様の確認日：2026年10月8日。IDとチャネル移動の説明は公式資料に基づき、確認表とテストの順番は設計上の提案です。