LINEログインで取得できる情報｜「同意」と「取得手段」で取れるものは変わる

「LINEでログイン」を入れると、ユーザーの情報はどこまで手に入るのか。ここは、事業者側の期待と実際が最もずれやすいところです。先に結論を言えば、取得できる情報はすべてユーザーの同意が前提であり、しかもどの“取得手段”を使うかで、取れる範囲そのものが変わります。同じLINEログインでも、プロフィールAPIを呼ぶのと、IDトークンを受け取るのとでは、手に入る項目が違うのです。この二つ——「同意（スコープ）の範囲」と「取得手段」——を分けて理解しておくと、会員登録フォームの設計から、GoogleやAppleとの違い、個人情報保護法との接続まで、まとめて見通せるようになります。

大前提：「ログインを通せば全部見える」ではありません

まず、いちばん多い誤解を解いておきます。ログインを通したからといって、相手の情報が勝手に手に入るわけではありません。取得できるのは、ユーザーが同意画面で許可した範囲だけです。しかも、標準で取れるのはかなり限定的で、氏名・住所・電話といった踏み込んだ情報は、それぞれ別の条件（権限の申請や法人契約）を満たして初めて扱えます。設計は「何が取れるか」ではなく、「何を、どの手段とスコープで、どの条件のもとに取るか」という三点セットで考えると、後からぶれません。

情報を受け取る経路は2つある——プロフィールAPIとIDトークン

LINEログインで情報を受け取る経路は、大きく二つに分かれます。役割がはっきり違うので、この違いを知らないまま実装すると、「メールが取れない」「ステータスメッセージが空になる」といった“詰まり”が起きます。まずはこの二本立てを頭に入れてください。

プロフィールAPI——手軽に呼べるが、範囲はメインプロフィールだけ

一つ目は、ログイン後に発行されたアクセストークンを使って、プロフィール取得のエンドポイント GET /v2/profile を呼ぶ方法です。profile スコープが付いていれば呼べます。返ってくるのはユーザーID（userId）・表示名（displayName）・プロフィール画像のURL（pictureUrl）・ステータスメッセージ（statusMessage）という“メインプロフィール”の4項目のみです。公式ドキュメントでもこの経路は「メインプロフィールのみ」と位置づけられており、メールアドレスやLINE Profile+の情報は、このAPIでは取れません。特徴は、アクセストークンが有効な間はいつでも呼び直して最新の値を取り直せることです。表示名や画像は変わり得る情報なので、常に最新を見たい用途ではこちらが向きます。

IDトークン——ログインの結果として、まとめて受け取る

二つ目は、openid スコープを付けてログインし、認証の結果として発行されるIDトークンを受け取る方法です。IDトークンはOpenID Connectの仕様に沿った署名付きのJWT（JSON Web Token）で、追加のAPIを呼ばなくても、トークンを受け取る応答の中に情報が載って返ってきます。中身には、ユーザーID（sub）・表示名（name）・プロフィール画像（picture）に加えて、申請済みであればメールアドレス（email）やProfile+の氏名・住所などまで含められます。踏み込んだ情報を取りたいなら、こちらが本命の経路です。プロフィールAPIとの決定的な違いは二つ。ステータスメッセージはIDトークンには載らないこと、そしてメールとProfile+はIDトークンにしか載らないことです。IDトークンは“認証したその時点のスナップショット”であり、後から呼び直すものではない、という性格の違いも押さえておきます。

「メールが取れない」の多くは、プロフィールAPIだけを使い、IDトークンを受け取っていないことが原因です。何を取りたいかで、先に経路を決めましょう。

スコープが、取れる範囲を決める

取得手段とセットで理解したいのがスコープです。ログインの認可リクエストで「どのスコープを要求するか」が、そのまま同意画面の内容と、取れる情報の範囲を決めます。主要なスコープと、それぞれの前提を整理します。

ポイントは、profile と openid が同意だけで使える一方、email 以降は事前の申請と審査を通して初めて要求できるようになることです。この“同意だけの層”と“申請が要る層”の境目が、実装スケジュールに効いてきます。

同意画面——ユーザーは「何を渡すか」を見て許可する

ログインの途中では、要求したスコープに応じた同意画面がユーザーに表示されます。ユーザーはそこで「アプリに何を渡すか」を確認し、許可して初めて情報が渡ります。逆に言えば、要求していない情報は同意画面にも出ず、当然取れません。

取得できる情報を、条件の重さで3層に分ける

取れる情報は、満たすべき条件の重さで3つの層に分かれます。この層をまたぐたびに「申請」や「法人契約」という手続きが挟まる、と捉えると分かりやすくなります。

① 基本プロフィール（同意だけで取得）

ユーザーID、表示名、プロフィール画像、そしてステータスメッセージ。ここは profile／openid の同意だけで取得でき、申請は不要です。とくにユーザーID（IDトークンでは sub）は、ユーザーを識別する“変わらない値”で、表示名や画像が変わっても不変です。だからこそ、後述する会員の名寄せでは、このユーザーIDを主キーに据えます。表示名と画像は、会員登録フォームにそのまま自動反映でき、ユーザーの入力をほぼゼロにできます。

② メールアドレス（権限の申請が前提）

メールは基本プロフィールに含まれず、事前にLINEへ「メールアドレス取得権限」を申請し、付与された場合にのみ、email スコープを通じてIDトークン経由で取得できます。申請は LINE Developers コンソールの「OpenID Connect」の設定から行い、審査では「メールアドレスの取得と利用目的をユーザーに示す画面のスクリーンショット」の提出が求められます。ここが実務の要で、「ログインを入れれば自動でメールも集まる」という思い込みは、一度崩しておくべきです。会員基盤でメールを主キーや連絡手段にしたいなら、この申請と審査を前提に、リードタイムごとスケジュールに織り込む必要があります。

③ LINE Profile+（氏名・住所・電話まで）

さらに踏み込んだ情報を扱えるのが LINE Profile+ です。ユーザーがLINEにあらかじめ登録している情報を、本人の明示的な同意のうえで取得し、登録フォームに自動入力できます。通常のプロフィール（表示名など、ユーザーがLINE上で自由に付けられる“表向きの名前”）とは別物で、こちらは実生活に紐づく本人情報である点が決定的に違います。項目と形式は公式に定義されています——氏名（姓・名・ミドルネームと各カナ表記）、性別（male／female／カスタム値）、生年月日（RFC3339形式）、電話番号（E.164形式）、住所（ユーザーは複数登録できますが、IDトークンには最新の1件が郵便番号・都道府県・市区町村・番地・国コードとして返ります）。指定は項目ごとのスコープ（real_name／gender／birthdate／phone／address）で行い、いずれも openid と併せて使い、結果はIDトークンに載ります。

ユーザーIDの性質——「同じ人」とみなせる範囲

会員基盤を設計するうえで、ユーザーIDの“一意性がどこまで及ぶか”は決定的に重要です。ここは誤解が多いので、正確に押さえておきます。LINEのユーザーIDは、チャネル単位ではなく、チャネルが属する「プロバイダー」単位で一意です。つまり、同じプロバイダーの下に置いたチャネルであれば、たとえLINEログイン用のチャネルとメッセージ配信用（Messaging API）のチャネルという種類の違う組み合わせでも、同じユーザーには同じユーザーIDが返ります。一方で、別のプロバイダーに属するチャネルでは、同じ人でも別のユーザーIDになります。ユーザーIDは U で始まる32桁の16進文字列という決まった形式で発行されます。

この性質は、設計初期の判断に直結します。ログイン用チャネルとLINE公式アカウント（Messaging APIチャネル）を同じプロバイダーにまとめて置けば、ログインで得たユーザーIDと、公式アカウントからメッセージを送る宛先のユーザーIDが一致します。結果として、「ログインで会員を識別する」ことと「その会員へメッセージを届ける」ことが、同じIDで一本につながるのです。逆に、別々のプロバイダーに分けて作ってしまうとIDが揃わず、名寄せに余計な仕組みが必要になります。しかもチャネルは後からプロバイダーを移動できません。連携させたいチャネルは最初から同じプロバイダーの下に作る——これは設計の初手で決めておくべき事項です。

関連して押さえておきたいのが友だち状態の確認です。profile スコープがあれば、友だち状態を確認するエンドポイント GET /friendship/v1/status を呼べます。返ってくる friendFlag は、そのユーザーがログインチャネルに紐づくLINE公式アカウントを友だち追加していて、かつブロックしていないときに true になります。ログイン直後に「この人はもう友だちか」を判定できるので、まだ友だちでなければ追加を促す、といった出し分けに使えます。

取得手段 × 項目——一枚で逆引きする

「何を取りたいか」から「どの手段を使うか」を逆引きできるよう、公式仕様を整理しました。最終的に取れるのは、ユーザーが同意した項目に限られます。

ステータスメッセージはプロフィールAPI側、メールとProfile+はIDトークン側、という住み分けを押さえておくと迷いません。両方が要るなら、openid でIDトークンを受け取りつつ、必要に応じてプロフィールAPIも呼ぶ、という二段構えになります。

受け取ったIDトークンは、必ず検証する

IDトークンは、届いたものをそのまま信用してはいけません。サーバー側での検証が前提です。検証は POST /oauth2/v2.1/verify に id_token とチャネルIDを渡して行い、署名はES256（アプリ・SDK・LIFF）またはHS256（ウェブ）で確かめます。あわせて、発行者（iss）・宛先（aud＝自分のチャネルID）・有効期限（exp）、そしてリプレイ防止の nonce を確認します。ログインの入口でも、CSRF対策の state を必ず用いるのが定石です。ここを省くと、他所で発行されたトークンや、なりすましのトークンを受け入れてしまう穴になります。なお、IDトークンには amr という項目があり、ユーザーがどの方法で認証したか（パスワード・自動ログイン・QRコード・シングルサインオン・多要素認証のいずれか）が記録されます。

他のソーシャルログインと、何が違うのか

GoogleやAppleと比べると、LINEの立ち位置がはっきりします。

Google は、基本のOIDCサインインで識別子・氏名・メール・画像までを素直に返します。プライバシー志向で、それ以上の属性（電話や住所）は別のAPIと追加スコープが必要です。Apple はさらに慎重で、氏名とメールは初回のサインイン時にしか返りません。ここを取りこぼすと再取得できないため、サーバー側で初回に確実に保存する設計が要ります。しかもメールは、ユーザーが選べば @privaterelay.appleid.com の非公開リレーメールになり得ます。

これらに対してLINEは、電話・住所・生年月日といった“実生活に紐づく情報”まで、正規の同意ベースで取得できる数少ない選択肢です（ただしProfile+＝法人・申請・スマホ登録という条件付き、という点は正直に併記すべきです）。会員登録の自動入力という一点では、LINEが一歩踏み込めるのです。

「取らない」も設計する——最小限取得と利用目的の明示

取れる情報を整理すると、つい「取れるものは全部取っておこう」と考えがちですが、これは逆です。使う予定のない情報は取らない——最小限取得が原則です。要求スコープが増えれば同意画面の項目が増えて同意率が下がり、email やProfile+では使わない情報のために申請・審査の工数とリードタイムまで払うことになるためです。そもそもLINEログインで取れるのは本人が同意した本人の属性だけで、友だちのユーザーIDやトークの内容といった他者・非公開の情報は取得対象ではありません。「取れない・取ってはいけない」ものがある、という前提も設計に含めておきます。

そして、集める情報は個人情報保護法との整合が欠かせません。同法は、個人情報を取り扱うにあたって利用目的をできる限り特定することを求め（第17条第1項）、さらに取得に際して、その利用目的を本人に通知するか、あらかじめ公表しておくことを求めています（第21条第1項）。具体的には、「取得したメールアドレスや氏名を、何のために使うのか」をあいまいな表現で済ませず、本人が合理的に予測できる程度に具体的に示す、ということです。実装面では、LINEの同意画面で示す内容と、自社のプライバシーポリシーや利用目的の記載を食い違わせないことが要点になります。同意画面は「LINE側でこの項目を渡してよいか」を確認する場であり、「自社がその情報を何に使うか」は自社側できちんと特定・明示する、という役割分担を押さえておきます。取った情報を、示した目的の外に流用しないことも当然の前提です。

取得の先——会員基盤へ、どうつなぐか

取得はゴールではなく、出発点です。活かし方には型があります。まず安定キーであるユーザーIDを名寄せの主キーに据えること。表示名や画像は変わり得ますが、ユーザーIDは変わりません。次に必要最小限のスコープから始めて、段階的に広げること。入口は profile＋openid で摩擦を最小にし、メールが要るなら申請、本人確認や配送が必要なECならProfile+申請、と広げていきます。

そしてLINE最大の独自価値が、ログインと同時に、LINE公式アカウントの友だち追加までできることです。認可URLに bot_prompt を付ければ、会員登録と友だち化を一度に完了させられ、完了時のコールバックでは友だち状態の変化（friendship_status_changed）も受け取れます。前述のとおり同じプロバイダーに置いていればユーザーIDは一致するので、「会員ID」と「メッセージを送れるチャネル」を、同じIDのまま同時に手に入れられる——これはGoogleやAppleにはない、LINEならではの強みです。

▶ 全体像は 「LINEログインとは？仕組み・できること・導入の判断」 にまとめています。

参考にした一次情報：LINE Developers 公式ドキュメント（ウェブアプリにLINEログインを組み込む／IDトークンからプロフィール情報を取得／ユーザープロフィールの取得〈メインプロフィールのみ〉／LINE Profile+／ユーザーの管理〈プロバイダー単位で一意なユーザーID〉／友だち状態を取得する／IDトークンを検証する／友だち追加オプション）。他プロバイダの取得情報は Google OpenID Connect・Apple 公式（非公開メールリレー、初回のみ氏名・メールが返る挙動）による。個人情報保護法の条番号・要件は個人情報保護委員会の公表資料による。仕様・申請条件は改定される場合があるため、実装時は最新の公式情報をご確認ください（内容は執筆時点）。