LINE LoginとMessaging APIのユーザーIDが違う？プロバイダーを確認

同じ人なのにLINE LoginとMessaging APIのユーザーIDが異なる場合は、まず両チャネルが属する LINEプロバイダーを確認してください。LINEはプロバイダー単位でユーザーIDを発行します。同じユーザー・同じプロバイダーならチャネルの種類が違ってもIDは同じですが、プロバイダーが異なればIDも異なります。表示名だけで顧客を統合したり、トークンを変更すれば直ると考えたりしないでください。

要点

• 認証やwebhook設定を変更する前に、プロバイダーの所属を確認します。
• APIのユーザーID、友だち検索用のLINE ID、表示名は別物です。
• 作成済みチャネルは別のプロバイダーへ移動できません。
• メッセージ形式の共通化は、顧客IDの共通化ではありません。

LINE LoginとMessaging APIでユーザーIDが違う理由

LINEのユーザーID取得ドキュメントは、IDの範囲を明確に定義しています。名前空間を決めるのはチャネルの種類ではなくプロバイダーです。

比較条件	公式仕様または判断上の境界	アプリ側の扱い
同じユーザー、同じプロバイダーのLoginとMessaging API	ユーザーIDは同じ	そのプロバイダー内で検証済みIDを比較
同じユーザー、異なるプロバイダー	ユーザーIDは異なる	明示的なアカウント連携が完了するまで別管理
表示名が同じ	同一人物の証明にはならない	自動統合しない
検索用LINE IDとAPIユーザーID	異なる識別子	プロフィールの検索IDではなくAPIの値を取得

たとえば、会員サイトのLoginチャネルとサポート用Messaging APIチャネルを、別チームが別プロバイダーに作成したケースが考えられます。これは設定例であり、実際の顧客障害ではありません。この構成でCRM検索が失敗しても、LINEが突然ユーザーの識別情報を変えた証拠にはなりません。

なお、LINEプロバイダーはLINE Developersコンソール上のチャネルの所属先です。UnifyPortの provider: line はメッセージングプラットフォームを表すため、同じ名前空間ではありません。

設定を変える前の調査手順

1. IDの出所を記録する。 どのチャネルの、信頼できるLogin処理またはMessaging API webhookから取得した値かを確認します。手入力の名前とAPI識別子を比較しないでください。
2. 所属プロバイダーを確認する。 コンソールで両チャネルを開き、テスト環境と本番環境も含めて記録します。似たチャネル名は同じ所属の証拠ではありません。
3. 管理されたテストユーザーを使う。 指定したアカウントでログインし、メッセージを送ります。無関係なスクリーンショットや未検証のクライアント情報ではなく、検証済みサーバー側記録を比較します。
4. 保存処理を調べる。 同じプロバイダーなのに記録が違う場合は、古いセッション、別ユーザーでのログイン、環境の取り違え、フィールド対応ミスを先に確認します。
5. 不確実な統合を止める。 調査中は両方の記録を保持し、検索を通すためだけに片方のIDを上書きしないでください。

複数ツールによる認証情報やwebhookの競合なら、1つのLINE公式アカウントを複数ツールで使うチェックリストが適切です。ユーザーIDの範囲とは別の問題です。

別プロバイダーに作成済みの場合

LINEのLogin導入ガイドによると、作成済みチャネルを別プロバイダーへ移動することはできません。連携するLoginとMessaging APIのチャネルは、最初から同じプロバイダーに作成することが推奨されています。

稼働中のシステムで、削除して作り直す操作を軽い修正として扱わないでください。ログイン、認証情報、コールバック、保存済みID参照への依存を洗い出してから置き換えを計画します。新チャネルの作成は、既存CRMマッピングの継続を保証しません。

アプリ側の設計案として、外部IDと内部顧客レコードを分離します。取得元システム、LINEプロバイダー、チャネルの出所、ユーザーIDを保存し、検証済みの内部顧客との関連を別管理してください。これはローカル管理情報であり、LINE webhookに追加されたフィールドではありません。

プロバイダーをまたぐ連携には、関連アカウントの管理権限を確認し、ユーザーの同意を得る明示的な手順を用意します。連携の根拠を残し、解除できるようにしてください。同じ名前や画像だけでは不十分です。同一プロバイダーでIDが等しくても、権限や同意が別の処理へ移るわけではありません。

UnifyPortの送信者IDと送信先を分ける

UnifyPortの非公式インターフェースは、接続済みアカウント用の独立したメッセージ経路です。標準イベント仕様には provider、account_id、data.sender.id、data.conversation.id が含まれます。senderは送信者、conversationは会話を示します。特にグループでは両者を混同しないでください。

ローカル記録	推奨する識別範囲
公式LINEユーザー	アプリのテナント、LINEプロバイダー、検証済みユーザーID
UnifyPort送信者	ワークスペース、provider、account_id、data.sender.id
UnifyPort会話	ワークスペース、provider、account_id、data.conversation.id
内部顧客との関連	対象の外部IDに対する明示的な検証済みリンク

これは安全側に倒した保存設計であり、UnifyPortが公式LINEユーザーIDを変換するという意味ではありません。その変換は公開仕様にありません。接頭辞の削除、大文字小文字の変更、似た文字列からの同一性推測は避けてください。

連絡先一覧仕様は id、conversation_id、provider_user_id を別々に返し、会話の検索や送信には conversation_id を使うよう説明しています。返された対応を保持し、連絡先IDで代用しないでください。WhatsApp連絡先名の同期でもこの区別が重要ですが、同記事の contact.updated の挙動をLINEに適用してはいけません。

IDの関連付けを更新する前に、webhook配信仕様に従って検証・永続化してください。有効な署名は受信データを認証しますが、2つの外部アカウントが同一人物のものだとは証明しません。

受け入れテストと制限

CRM連携を有効にする前に、同一ユーザー・同一プロバイダー、同一ユーザー・別プロバイダー、同名の別ユーザー、別々のUnifyPortメッセージングアカウントをテストします。不明確な一致は分離したままにし、会話履歴を黙って統合しないでください。

グループメッセージも確認します。送信者を選んだ結果、意図した会話が別の送信先に置き換わってはいけません。ルーティングは後から行う顧客レコード統合と独立させます。

LINE Loginと公式アカウントのID連携が目的なら公式チャネルを使ってください。UnifyPortはチャネル移動、公式権限の付与、プロバイダーをまたぐID同一性の確立を行いません。

FAQ

LINE LoginとMessaging APIのユーザーIDは同じですか？

同じLINEユーザーかつ同じプロバイダーなら同じです。プロバイダーが違えば異なります。

チャネルを移動して修正できますか？

できません。LINEは既存チャネルを別プロバイダーへ移動できないと説明しています。作成前の所属設計が重要です。

表示名やUnifyPort sender IDで自動解決できますか？

できません。表示名はIDキーではなく、公式LINEユーザーIDからUnifyPort sender IDへの変換も公開仕様にはありません。

次のステップと参考資料

まず両公式チャネルの所属プロバイダーを記録してください。独立した接続アカウント用受信箱を作る場合は、UnifyPortイベント構造を読み、連絡先を取り込む前に識別範囲を設計します。

公式資料の確認日：2026-10-05。

• LINE：Get user IDs
• LINE：Getting started with LINE Login
• UnifyPort：連絡先一覧