LINEログインで取得できる情報｜スコープごとの項目と、会員を見分けるユーザーID

LINEログインで何を受け取れるかは、ログインの途中で利用者に出る同意画面の項目で決まります。その項目は、事業者が認可のURLに書く scope と、事前の申請をしているかで変わります。

当社は、LINEログインを含め、LINE と自社のシステムをつなぐ連携と、LINE公式アカウントの運用を支援している会社です。この記事は、自社のサイトやアプリに LINEログインを入れようとしている事業者の方に向けて書いています。LINEログインの scope を切り替えると、同意画面と事業者に届く値がどう変わるかを確かめられるデモを、当社で作りました。そこで見える値を、LINE Developers の公式ドキュメントと照らし合わせて書きます。項目の条件はスコープの表、IDトークンの説明、APIリファレンスの3か所に分かれていて、1つのページでは読み切れません。扱うのはウェブアプリに組み込む LINEログインで、LIFF と LINEミニアプリに固有の受け取り方は扱いません。LINEログインの仕組みや、会員基盤として使うかどうかの判断は、「LINEログインとは」の記事で書いています。

LINEアプリを使っている方で、自分のログインや、LINEでログインしたサービスを確かめたい場合は、LINEヘルプセンターを見てください。LINEでログインしたサービスは、LINEアプリの［設定］＞［アカウント］＞［連動アプリ］で、許可した内容の確認と連動の解除ができます（LINE Developers「ユーザーによる連動アプリの管理について」）。LINEでログインしたときに「LINE」という名前の公式アカウントから届くログインの通知は、LINEヘルプセンターのこのページで説明されています。

ここからは、説明のための架空の例として、ヨガ教室の「ヨガスタジオ デモ」が体験レッスンの会員登録に LINEログインを入れ、利用者の「デモ 葵」さんがログインする場面で見ていきます。教室と葵さんは、この記事に埋め込んだ当社のデモと同じ架空の設定です。

同意画面に並ぶ3つの言葉が、受け取る範囲を決める

葵さんが教室のサイトの「LINEでログイン」を押すと、LINEの認証の画面（access.line.me）に移り、ログインのあとで同意画面が出ます。同意画面に並ぶ項目は、教室が認可のURLの scope に書いた値で決まり、表示は次の3つです（LINE Developers「ウェブアプリにLINEログインを組み込む」）。

「メインプロフィール情報」は、葵さんが LINEの［設定］＞［プロフィール］で設定している名前や画像のことです。友だちごとに見せるプロフィールを分けられる「サブプロフィール」は、LINEログインでは受け取れません（LINE Developers「IDトークンからプロフィール情報を取得する」）。「内部識別子」は、LINEが利用者を見分けるために発行するユーザーIDで、友だち検索に使う LINE ID とは別のものです。UID とも呼ばれます（LINE Developers の用語集）。

scope は組み合わせで受け取る範囲が変わります（次の節の表）。profile と openid のどちらかは必ず書く決まりで、email を書くときは openid も書きます。守られていないと、INVALID_SCOPE というエラーがコールバックURLに返ります。

葵さんは、同意画面で同意しないこともできます。その場合、教室のコールバックURLには ACCESS_DENIED というエラーが返るので、許可されなかったときの画面（メールアドレスでの登録など）も用意しておきます。一度同意した葵さんにも、同意画面がもう一度出ることがあります。出るのは次の4つの場合です。前回同意していない権限を求めたとき、葵さんが連動を解除したあとでログインしたとき、prompt=consent を付けたとき、そして email を求めていて、前回の同意から一定の期間がたったか、メールアドレスが変わったときです。

同じ項目でも、受け取り方が3つある

葵さんが同意すると、教室のコールバックURLに認可コードが届きます。認可コードの有効期間は10分で、1回だけ使えます。教室のサーバーはこれをアクセストークンとIDトークンに引き換えます。アクセストークンの有効期間は30日です。それより後にプロフィールを取り直すときは、リフレッシュトークンで新しいアクセストークンを取ります。リフレッシュトークンは、アクセストークンの発行から最長90日有効です（LINE Developers「アクセストークンを管理する」）。

LINEログインで項目を受け取る方法は、IDトークンの中身を読む、プロフィールを取得する（GET /v2/profile）、ユーザー情報を取得する（/oauth2/v2.1/userinfo）の3つです。scope の組み合わせごとに、どの方法で何が届くかを、公式の3つのページ（基礎知識の「取得できるプロフィール情報の種類」、APIリファレンス、スコープの表）を突き合わせて1つの表にしました。

表の外の条件が2つあります。pictureUrl と statusMessage は、葵さんが画像やステータスメッセージを設定していなければ含まれません。氏名・性別・誕生日・電話番号・住所は、どの組み合わせでも届かず、LINE Profile+ の申請とスコープが要ります（あとの節）。

表の openid の行で表示名と画像が入らないのは、APIリファレンスとIDトークンの説明に、profile スコープを指定しなかった場合は含まれない、とあるためです（APIリファレンス）。基礎知識のページの一覧（基礎知識）だけを見ると、ユーザー情報の取得とIDトークンのどちらにも表示名が入るように読めます。3つのページの間で食い違っていたのは、この1つでした。

教室が葵さんの表示名とメールアドレスの両方を受け取るなら、scope に profile openid email を書き、IDトークンを検証して受け取ります。プロフィールの取得はアクセストークンが有効な間は呼び直せるので、葵さんが表示名や画像を変えたあとの値を取り直せます。画像を小さく表示するなら、画像のURLの末尾に /large（200×200）か /small（51×51）を付けます（APIリファレンス「ユーザープロフィールを取得する」）。

メールアドレスは、申請が通ってから email を書く

メールアドレスは、ユーザーIDや表示名と違い、申請しないと scope に書いて求めることもできません。申請は LINE Developers コンソールの、チャネルの［チャネル基本設定］から行います。

申請には、利用者に示す文面の画面のスクリーンショットが要ります。そのため、申請の前に、教室の会員登録の画面に「メールアドレスを何に使うか」の文面ができている必要があります。

申請が通ったあと scope に email を書くと、同意画面に「メールアドレス」が並び、葵さんが許可すればIDトークンに email が入ります。アクセストークンを発行したときの応答の scope には、許可されていても email は出てきません。葵さんが許可したかどうかは、IDトークンに email があるかで見ます。

氏名・住所・電話番号は LINE Profile+ から

入力に手間のかかる氏名や住所は、葵さんが LINE Profile+ に登録していれば、IDトークンで受け取れます。LINE Profile+ は、利用者が LINEアプリの［設定］＞［プロフィール］＞［LINE Profile+］に、住所や電話番号などを登録しておく仕組みです（LINE Developers「ユーザーのプロフィール情報を取得する」）。

受け取れるのは、所定の申請等をした日本の法人ユーザーだけです。申し込みは、LINEヤフーの担当営業かパートナーへの問い合わせから行います。LINEミニアプリで使う場合は、認証済ミニアプリに限られます。LINEログイン v2.0 以前では使えません（LINE Developers「LINE Profile+」）。項目ごとにスコープが分かれていて、どれも openid と一緒に書き、あらかじめ申請しておきます。なお LINEミニアプリには、別の利用申請をして「共通プロフィールのクイック入力」で氏名や住所などを受け取る方法もあります（この記事では扱いません）。

住所は最大10件まで登録できますが、IDトークンに入るのは、最近更新されたか使われた1件だけです。郵便番号と番地は空のこともあります。phone を求めていると、前回の同意から一定の期間がたったか、電話番号が変わったときに、同意画面がもう一度出ます。

教室が会員登録で氏名と電話番号まで入力を省きたいなら、LINE Profile+ の real_name と phone が候補になります。どの項目を求めるかは、あとの「取らない項目」の節で決めます。

同じ人を見分けるのに使えるのは、ユーザーIDだけ

ここまでで、教室は葵さんの表示名やメールアドレスを受け取れるようになりました。では、受け取った値のうち、葵さんを見分けるのに使えるのはどれか。答えは、利用者が変えられないユーザーIDです。表示名、プロフィール画像、ステータスメッセージは利用者がいつでも変えられるので、利用者を見分ける目的には使えません（LINE Developers「ユーザーを管理する」）。ユーザーIDは U で始まり、16進数の32文字が続く文字列です。会員台帳の行は自社の会員番号のままにして、ユーザーIDは会員番号に結び付ける列として持ちます。この形の台帳は、当社のデモ「LINE×CRM連携の流れ」（会員番号でログインして結び付けるアカウント連携の例）で見られます。

ユーザーIDで気をつけるのは、同じ葵さんでも、プロバイダーが違えば別の値になることです。プロバイダーは LINE Developers コンソールでチャネルを束ねる単位で、サービスを提供する事業者ごとに作ります。同じプロバイダーの下なら、LINEログインのチャネルでも、LINE公式アカウントの Messaging API のチャネルでも、葵さんのユーザーIDは同じ値です（LINE Developers「ユーザーIDを取得する」）。そしてチャネルは、後から別のプロバイダーへ移せません（「プロバイダーとチャネル管理のベストプラクティス」）。教室が LINEログインで受け取ったユーザーIDに LINE公式アカウントからメッセージを送りたいなら、2つのチャネルを最初から同じプロバイダーの下に作ります。ただし、同じプロバイダーにするのは送るための前提の1つです。台帳のユーザーIDを指定するマルチキャストで送れるのは、LINE公式アカウントを友だち追加していて、ブロックしていない人です（Messaging API リファレンス「マルチキャストメッセージを送る」）。プッシュは、7日以内に1対1のトークで公式アカウントへメッセージを送ってきた人にも送れますが（「プッシュメッセージを送る」）、LINEログインをしただけの葵さんはこれに当たりません。ログインのときに友だち追加を案内する仕組みが、あとの節の友だち追加オプションです。

同じプロバイダーにまとめるときは、もう1つ条件があります。同じプロバイダーで複数のサービスを運営し、サービスごとに受け取った LINEの利用者の情報を結び付けて共通で使うことは、LINEユーザーデータポリシーで原則禁止されています。プロバイダーページを公開し、各サービスにプロバイダーページへの案内を置くなどの条件を満たした場合に認められます。プロバイダーページは認証プロバイダーだけが設定できる、法人向けのオプションです（LINE Developers「プロバイダーページ」）。

枠の中はスクロールできます。画面いっぱいで試すときは別のタブで開く。

教室・利用者・ユーザーID・トークンの値は架空です。scope の組み合わせ、同意画面の項目の文言、受け取る項目と含まれない条件は、デモの出典の欄に並べた LINE Developers のページにそろえてあります。受け取ったユーザーIDを台帳とどうつなぐかはLINEと今の顧客管理をつなぐ方法と費用の記事、ECの会員と結ぶ場合はLINEのID連携でEC・CRMを強くする記事で書いています。

ログインと同時に、LINE公式アカウントを友だち追加してもらう

LINEログインのチャネルに自社の LINE公式アカウントをリンクしておくと、葵さんがログインする画面で友だち追加を案内できます。LINE Developers では「友だち追加オプション」と呼んでいます。リンクの条件の1つは、LINE公式アカウントの Messaging API のチャネルが、LINEログインのチャネルと同じプロバイダーにあることです。設定は、LINEログインのチャネルの［チャネル基本設定］タブ、［リンクされたLINE公式アカウント］の［編集］から行います。1つのチャネルにリンクできる LINE公式アカウントは1つです（LINE Developers「友だち追加オプション」）。

案内を出すには、認可のURLに bot_prompt を付けます。normal は同意画面に友だち追加の選択肢を出し、aggressive は同意画面のあとに、友だち追加するかを確かめる画面を出します。葵さんがすでに友だちなら選択肢は出ず、ブロックしていればブロックを解除する選択肢が出ます。認証プロバイダーの下のチャネルでは、normal の選択肢が最初からオンになっています。上のデモの「4. ログインのときに友だち追加を促す（bot_prompt）」で、2つの違いを試せます。

結果は、コールバックURLに付く friendship_status_changed で分かります。ログインの間に友だち追加かブロック解除をしたら true、変わらなければ false です。選択肢が出なかったときは、この値自体が付きません。あとから確かめるときは、profile スコープのアクセストークンで GET /friendship/v1/status を呼びます。友だち追加していてブロックしていなければ friendFlag が true で返ります（APIリファレンス）。

同意は取り消せる。取り消されたら受け取れなくなる

葵さんは、教室に許可した内容を LINEアプリの連動アプリの画面でいつでも確かめ、［連動を解除］で取り消せます。取り消すと、すぐにアクセストークンとリフレッシュトークンが無効になります。教室は、葵さんがもう一度同意してログインするまで、ユーザーIDもプロフィールも受け取れません。

もう一度同意しても、葵さんのユーザーIDは変わりません。そのため、ユーザーIDに結び付けて記録した情報は、取り消し後も使えると考えられます。ただし LINE Developers は、取り消しを尊重して、使うときにアクセストークンを確かめて情報を取り直すよう求めています。これに沿うなら、台帳に残した表示名を、連動を解除した人への案内にそのまま使い続ける作りは避けることになります。受け取った情報は、LINEユーザーデータポリシーに従って扱います。

逆に、葵さんが教室を退会したときや、教室のサイトで LINE との連携を解除したときは、教室が権限を取り消す API（POST /user/v1/deauthorize）を呼びます。これは開発ガイドラインの必須事項です。退会や連携の解除で何が起きるかを、その機能のそばか、会員登録のときに同意してもらう規約に書くことも必須事項に入っています（LINE Developers「LINEログイン開発ガイドライン」）。

受け取った値は、サーバーで確かめてから使う

IDトークンは、ヘッダー・ペイロード・署名をピリオドでつないだ JWT です。届いたIDトークンは、なりすましを狙った攻撃者が作ったものかもしれないので、サーバーで検証してから中身を使います。手早いのは検証のエンドポイント（POST https://api.line.me/oauth2/v2.1/verify）に、id_token とチャネルID（client_id）を送る方法です。通れば、ペイロードがそのまま返ります。APIリファレンスに載っている応答の例は次のとおりです（APIリファレンス「IDトークンを検証する」）。

{
 "iss": "https://access.line.me",
 "sub": "U1234567890abcdef1234567890abcdef",
 "aud": "1234567890",
 "exp": 1504169092,
 "iat": 1504263657,
 "nonce": "0987654asdf",
 "amr": ["pwd"],
 "name": "Taro Line",
 "picture": "https://sample_line.me/aBcdefg123456",
 "email": "taro.line@example.com"
}

自分で検証する場合、署名はウェブのログインでは HS256（鍵はチャネルシークレット）、ネイティブアプリ・LINE SDK・LIFF では ES256 です（LINE Developers「IDトークンからプロフィール情報を取得する」）。検証のエンドポイントで失敗すると、理由が文言で返ります。Invalid IdToken Issuer.（https://access.line.me 以外で作られた）、IdToken expired.（期限切れ）、Invalid IdToken Audience.（client_id と違う）、Invalid IdToken Nonce.（nonce が違う）などです。

ログインを始めるたびに第三者が推測できない state を作り、戻ってきた値と一致するかを確かめることも、セキュリティチェックリストの項目です。スマホアプリで LINEログインを使う場合は、アプリからサーバーへ葵さんのユーザーIDや表示名を送るのではなく、IDトークンかアクセストークンをそのまま送り、サーバーで検証して受け取ります。アプリが送ってきたプロフィールをそのまま信じると、なりすましに弱くなるためです（「アプリとサーバーの間で安全なログインプロセスを構築する」）。

IDトークンの amr には、葵さんがどの方法でログインしたかが入ります。pwd（メールアドレスとパスワード）、lineautologin（自動ログイン）、lineqr（QRコード）、linesso（シングルサインオン）、mfa（2要素認証）です。ログインの方法で処理を分けるときに使えますが、条件によっては amr 自体が入らないので、無いときも動くように作ります。

Google・Apple のログインと比べると

同じソーシャルログインでも、受け取れる範囲と、受け取れるタイミングが違います。

Google は、IDトークンの email はアカウントごとに一意とは限らず変わることもあるので、利用者の鍵には sub を使うよう書いています。LINE のユーザーIDと同じ考え方です。Apple は、受け取った氏名などをすぐに保存するよう求めています。

取らない項目を決めて、利用目的と画面の文面をそろえる

受け取れる項目が分かったら、教室が次に決めるのは、どの項目を求めないかです。scope に足した項目はそのまま葵さんの同意画面に並び、email や LINE Profile+ は申請も要ります。会員登録の画面で何に使うかを説明できない項目は、最初から求めないほうが、申請の手間も同意画面の項目も少なく済みます。

個人情報保護法は、個人情報を扱うときに利用目的をできる限り特定すること（第17条第1項）、取得したときは、あらかじめ公表している場合を除き、速やかに利用目的を本人に通知するか公表すること（第21条第1項）を求めています（e-Gov 法令検索「個人情報の保護に関する法律」）。葵さんが同意画面で選ぶのは、LINEがどの項目を教室に渡すかです。何に使うかを特定し、通知や公表をするのは教室の側です。メールアドレスの申請で出す画面の文面、会員登録の画面、自社のプライバシーポリシーで、同じ目的を同じ言葉で示しておきます。

当社の会員証のデモ「デジタル会員証とポイント」（架空の店舗・データ）では、会員登録で入れてもらう情報を、ニックネームと誕生月（任意。お誕生月の特典に使います）の2つにしています。デモの画面には、実際に作るときは LINEログインで本人の LINE アカウントを確かめ、自社の会員IDと結び付けると書いてあります。使い道を項目に添える形（誕生月）の例として見てください。

開発を始める前に、自分の設定で見直す3か所

LINE公式アカウントをすでに運用している会社は、3つ目の確認として、その Messaging API のチャネルがどのプロバイダーにあるかを LINE Developers コンソールで見てから、LINEログインのチャネルを作ってください。受け取ったユーザーIDを会員台帳のどこに結び付け、LINE公式アカウントの配信や結果とどうつなぐかは、当社のLINE運用・伴走支援で一緒に決められます。

項目・条件・画面の名前は、2026年10月13日と14日に LINE Developers の公式ドキュメント（LINEログインの組み込み手順、IDトークン、APIリファレンス、基礎知識、開発ガイドライン、LINE Profile+、プロバイダーページ、Messaging API リファレンス、FAQ など20ページ）と、Google・Apple の公式の文書、e-Gov の法令を開いて突き合わせたものです。申請の条件や画面は変わることがあるので、実装の前に LINE Developers の最新のページで確かめてください。