ECにLINE・ソーシャルログインを導入する|Shopify/EC-CUBE別の実装・費用と名寄せ
目次 クリックで開く
ネットショップが売上を取りこぼす大きな原因の一つが、購入直前の「会員登録」で離脱されることです。ここに効くのがソーシャルログイン/LINEログインで、入力の手間を消して離脱を減らせます。ただし見落としてはならないのは、使っているECプラットフォームによって、実装方法・費用・制約がまったく違うという点です。「LINEログインを入れる」と一言でいっても、標準機能でそのまま入るのか、有償プラグインが要るのか、上位プラン限定の専用APIを叩くのかで、作業も投資もまるで変わります。この記事では、まず「なぜ効くのか」をデータで押さえ、そのうえでShopify・EC-CUBE・MakeShop・futureshop・カラーミーショップ・自社ECそれぞれの入れ方と費用、さらに実装の勘所であるEC会員とLINE会員の名寄せまでを、仕組みのレベルで整理します。
会員登録は「離脱の主犯」——まずデータで押さえる
最初に事実からです。オンライン購入のカゴ落ち率は、各種調査の平均で約70%(Baymardで70.22%)にのぼります。そして離脱理由を並べると、価格や送料と並んで「アカウント作成を求められた」(約19%)が上位に顔を出します。カートまで進んだ、つまり「買う気のある」人が、最後の登録フォームで五人に一人近く逃げているということです。ここを削るだけで、広告費を増やさずに購入率を底上げできる余地があります。
ゲスト購入とソーシャルログインは対立しない
ここで一つ、設計上の誤解を解いておきます。「ゲスト購入を許すと会員が増えない、だから登録を必須にすべきだ」という考えは、多くの場合むしろ逆効果です。よく知られたUX事例では、ある大手小売がチェックアウトでの会員登録必須をやめ、「登録」ボタンを「ゲストのまま購入」に変えただけでコンバージョンが大きく改善しました。しかも購入した人の多くは、結局あとからアカウントを作っています。つまり人は登録が嫌なのではなく、買う前に登録を強制されるのが嫌なのです。
ソーシャルログインは、この構図にきれいに噛み合います。ゲスト購入で「買う前の壁」を外しておき、購入完了後の画面やマイページで「LINEで登録すればパスワード不要、友だち追加も一度に」と案内すれば、摩擦の少ない導線で会員化へつなげられます。ゲスト購入とソーシャルログインは二者択一ではなく、並べて置くほど効く組み合わせだと考えてください。並存させるときは、同じメールアドレスのゲスト注文とソーシャルログイン会員を後から突き合わせられるよう、注文時のメールアドレスを鍵に名寄せできる設計にしておくと、購入履歴が分断されずに済みます。
障壁は「登録」そのものではなく「購入前に登録を強制されること」で、ゲスト購入で壁を外しつつソーシャルログインで会員化の入口も残すのが現実解です。
日本のECでは、LINEログインが主軸です
どのソーシャルログインを主役に据えるか、日本のECでは答えがはっきりしています。LINEです。業界調査では、ソーシャルログイン利用に占めるLINEの割合が2019年の約56%から、2025年には約88%へ拡大しました(いずれもフィードフォース系のデータ)。スマホ経由が大半を占めるECなら、まずLINEログインを軸に設計するのが現実的です。GoogleやYahoo! JAPAN、Appleなどを併設する選択肢もありますが、主導線はLINEに置き、他はサブとして添えるのが日本市場では素直な組み立てです(LINEログインの全体像は 「LINEログインとは?」、そこで取得できる情報は こちらにまとめています)。
プラットフォーム別——どう入れるか、いくらか
ここが実務でいちばん差が出るところです。同じ「LINEログインを入れる」でも、使っているECによって、標準機能で入るのか、有償プラグインなのか、上位プラン限定のAPIが要るのかが大きく分かれます。まず全体像を表で示し、そのあと主要なプラットフォームごとに仕組みまで踏み込みます(費用は執筆時点・各社公式の情報にもとづきます)。
| プラットフォーム | 入れ方 | 費用の目安 | 注意 |
|---|---|---|---|
| Shopify | 正規の連携は Multipass(+対応アプリ) | Multipassは Shopify Plus限定(Plusは月$2,000〜) | 下位プランはMultipass不可。ID/PWを外部アプリに保存する方式は危険 |
| EC-CUBE | 公式マーケットの有償プラグイン(またはカスタム) | ソーシャルログインプラグイン 39,800円(税込) 等 | 本体バージョン(4.2/4.3等)への対応を確認 |
| MakeShop | 「LINE ID連携」を標準提供 | 標準機能 | 連携はスマホのみ |
| futureshop | 「LINE連携オプション」 | 月額3,000円(税別)/約15営業日 | スマホからのログイン(PCは非対応) |
| カラーミーショップ | 「LINEでログイン」設置(LINEログイン連携) | 標準機能 | 連携後はLINEとメール/PWの両方でログイン可 |
| 自社EC/カスタム | LINE DevelopersのLINEログインをOAuth2/OIDCで実装 | 開発費(範囲次第) | 自由度が高い。友だち追加は bot_prompt で制御 |
同じ「LINEログインを入れる」でも、標準機能・有償プラグイン・上位プラン限定APIのどれになるかは、使っているECで決まります。
Shopify:正規の連携はMultipass(Plus限定)
Shopifyで外部の会員システムやLINEログインと安全につなぐ正攻法が、Multipassという仕組みです。これはShopify Plusでのみ使える機能で、下位プランでは選べません(Plusは月$2,000〜)。Multipassの要点は、ユーザーのShopifyパスワードを一切やり取りせず、「この人は確かに本人です」という事実だけを暗号技術で受け渡すところにあります。流れを追うと、こうなります。
まず管理画面でMultipassを有効にすると、Shopifyからシークレット(共有鍵)が発行されます。自社側は、自分のサイトでログイン済みのユーザーについて、メールアドレスと生成時刻(created_at)を含む顧客情報を一つのJSONにまとめます。このJSONを、シークレットから導いた鍵でAES(共通鍵暗号)で暗号化し、さらにその暗号文にHMAC(ハッシュベースの署名)を付けます。鍵の作り方も決まっていて、シークレットをSHA-256でハッシュ化し、その前半を暗号化用、後半を署名用に使い分けます。暗号化にはランダムな初期化ベクトル(IV)を用い、IV・暗号文・署名をつなげてURLセーフなBase64に変換したものが「トークン」です。最後に利用者を /account/login/multipass/(トークン) というURLへリダイレクトすると、Shopify側が同じシークレットで署名を検証し、正しければそのメールアドレスの顧客としてログインさせます。
この設計の利点は二つあります。ひとつは、署名(HMAC)によって改ざんを検知できること。トークンの中身を書き換えても署名が合わなくなるため、他人のメールアドレスに差し替えて「なりすます」ことができません。もうひとつは、JSONに含めた生成時刻によって古いトークンの使い回し(リプレイ)を防げること。トークンは発行から短時間で失効し、一度使うと無効になる使い捨てなので、あらかじめページに埋め込んで再利用するのではなく、リダイレクトの直前にサーバ側で都度生成するのが前提です。つまりMultipassは「パスワードを渡す」のではなく「本人だと確認済みだという署名付きの通知を渡す」仕組みだ、と押さえておくと理解が早くなります。
EC-CUBE:有償プラグイン(バージョン整合が肝)
EC-CUBEは自社サーバに設置するオープンソースのECで、ソースコードに手を入れられるのが特徴です。ソーシャルログインは、公式マーケットプレイスの有償プラグインを導入するのが一般的で、たとえばソーシャルログインプラグインが39,800円(税込)といった価格帯です。プラグインは会員登録・ログインの処理に差し込む形で動くため、注意したいのは本体バージョンとの整合です。EC-CUBEはメジャー/マイナーバージョン(4.2系・4.3系など)ごとに内部構造が変わるので、使っている版に対応したプラグインを選ばないと、そもそも入らなかったり、本体を更新したときに動かなくなったりします。要件が特殊なら、プラグインではなくカスタム開発でLINEログインを組み込むこともできますが、その場合は自分たちで保守を負う前提になります。自前でコードを触れる自由と、更新のたびに互換性を確かめる手間は、表裏一体だと考えてください。
MakeShop・futureshop・カラーミー:ASPは「用意された連携」を使う
この三つはいわゆるASP(クラウド型)で、ソースコードには触れません。だからこそ実装は「事業者が用意した連携機能を有効にする」形になり、自由度は低い代わりに手離れがよいのが特徴です。MakeShopは「LINE ID連携」を標準提供していますが、連携はスマホからのみです。futureshopは「LINE連携オプション」で、月額3,000円(税別)・約15営業日が目安、こちらもスマホからのログインが対象でPCは非対応です。カラーミーショップは「LINEでログイン」を設置でき、連携後はLINEとメール/パスワードの両方でログインできます。ASPを使うときの考え方はシンプルで、「どの情報を、どこまで、どのタイミングで連携できるか」は提供機能の範囲に収まります。逆にいえば、細かな挙動を作り込みたい要件があるなら、その要件がプラン内で満たせるかを事前に確かめておくのが安全です。
自社EC:LINEログインを自前実装(OAuth2/OIDC)
自社ECやフルスクラッチなら、LINE DevelopersのLINEログインを、OAuth2.0/OpenID Connect(OIDC)にのっとって自前で実装します。標準的な「認可コードフロー」の流れはこうです。まず、LINEの認可エンドポイントへ response_type=code、client_id(チャネルID)、redirect_uri、推測困難な state、必要な scope(profile・openid・email など)を付けてリダイレクトします。ユーザーがLINEで認証・同意すると、コールバックに認可コード(code)と state が返ります。ここで送ったときの state と照合し、なりすまし(CSRF)を弾くのが要点です。
次にサーバがこの認可コードをトークンエンドポイントに渡し、access_token と(openid を要求していれば)id_token を受け取ります。id_token はJWTという署名付きのトークンで、ユーザー識別子(sub、すなわちそのユーザーの userId)や表示名、email スコープが許可されていればメールアドレスを含みます。この署名を検証してはじめて「本物のログイン結果」として扱う、という順番が大切です。パッケージECと違って状態管理・トークン検証・後述の友だち追加まで自分たちで設計できるため自由度は高い反面、標準仕様に忠実に組む責任も自分たちにある、と捉えておくとよいでしょう。
自社ECなら「友だち追加も同時に」できる——bot_prompt
自社実装の最大の利点は、会員登録と同時に、LINE公式アカウントの友だち追加まで一度に終わらせられることです。これは認可リクエストに bot_prompt パラメータを添えて制御します。normal を指定すると同意画面のなかに友だち追加の選択肢を差し込み、aggressive を指定すると別画面で追加をうながします。控えめに出すか、はっきり出すかを、体験に合わせて選べるわけです。さらにコールバックでは friendship_status_changed が true/false で返るため、そのログインを機に友だちになったかどうかも、その場で判定できます。獲得したまさにその瞬間に「その後の接点」まで作れるのは、パッケージECの標準機能ではなかなか実現しにくい、自社実装ならではの強みです。ただし、この友だち追加を成立させるには、次に述べるチャネル構成の前提を満たしている必要があります。
EC会員とLINE会員を「名寄せ」する
ログインを入れたら、次に効いてくるのがECの会員データとLINEの友だちを、同一人物として結びつける(名寄せ)ことです。ここを飛ばすと「ECの会員Aさん」と「LINE友だちのAさん」が別データのまま残り、購買履歴に応じたセグメント配信ができません。主な方式は三つあります。
第一に、ECの登録/ログイン画面にLINEログインボタンを設置し、新規登録やログインと同時に紐づける方法です(このとき前述の自動友だち追加も同時に発火させられます)。第二に、LINE公式アカウントのリッチメニュー等に連携用URLを設置し、そこからのログインで自動的に会員IDと結びつける方法。第三に、Botサーバ側が一度きりの連携トークンを発行し、LINEの userId と自社の会員IDを突き合わせて保存する方法です。どれを選ぶかは、既存会員が多いのか、それとも新規獲得が主戦場なのかといった状況で変わります。
そして、自動友だち追加や安定した名寄せを成り立たせる技術的な前提が、チャネルの置き方です。友だち追加オプションを使うには、LINE公式アカウントにひもづくMessaging APIチャネルと、LINEログインチャネルが同一プロバイダーに属し、操作する人がLINEログインチャネルのAdmin権限と、LINE公式アカウントの管理権限の両方を持っていることが求められます。ここを最初に整えておかないと、後から「友だち追加が有効にできない」「権限が足りない」と手戻りが発生します。
userId が割り当てられます。つまりLINEログインで得た userId と、Messaging APIで友だちを識別する userId が一致するため、名寄せが「同じ鍵どうしの突き合わせ」になり、余計な変換や推測が要りません。逆にプロバイダーを分けて作ってしまうと、同一人物でもチャネルごとに別のIDになり、後からの名寄せが一気に難しくなります。最初のチャネル設計が、そのまま名寄せの難易度を決める、と考えてください。名寄せの全体設計は、会員基盤そのものの作り方(会員基盤の正しい作り方)や、CRM/ECとのID連携の考え方(LINEのID連携(EC/CRM))とあわせて考えると、全体の見通しがよくなります。
実店舗もあるなら——LINEミニアプリの会員証
実店舗とECの両方を持つなら、LINEミニアプリのデジタル会員証で、店頭とECの会員情報・ポイントを一元化できます。専用アプリのダウンロードが要らないぶん会員化のハードルが下がり、利用者はLINEのなかで会員証を提示・利用できます。ここでも土台になるのは同じ名寄せの考え方で、オンラインで登録した会員も、店頭で来店した会員も、同じ会員IDに束ねられれば、購買の全体像が一続きで見えてきます。ミニアプリからECへ導線を引けば、会員証の提示と購入を同じLINEのなかで完結させることもできます(詳しくは 「LINEミニアプリのデジタル会員証」をご覧ください)。
「どのECに、どう入れて、どう名寄せするか」まで
効果を出すには、ログインの実装単体ではなく、プラットフォームに合った正規の入れ方とEC会員×LINE会員の名寄せを、一続きで設計するのが近道です。Shopify(Multipass)・EC-CUBE・自社ECなどでのLINE/ソーシャルログイン実装、名寄せ、実店舗との一元化まで、設計から実装までまとめて相談したい場合は、LINE活用の実装支援へ。「うちのECだと何が使えて、どう名寄せするか」の整理からで大丈夫です。
あわせて読みたい
参考にした一次情報:Baymard Institute(カゴ落ち率・離脱理由)、各ECプラットフォームの公式情報(Shopify Multipass、EC-CUBE公式マーケットプレイス、MakeShop/futureshop/カラーミーショップの公式マニュアル)、LINE Developers(LINEログイン・OAuth2/OIDC・bot_prompt・友だち追加オプション・プロバイダー/チャネル管理)、パスワード再利用に関する調査(Okta「Customer Identity Trends 2025」ほか)、および会員登録の強制と離脱に関するUX事例。費用・仕様は改定される場合があるため、導入時は各社の最新情報をご確認ください(数値は執筆時点)。
LINE公式アカウント支援
LINE公式アカウントの配信設計からCRM連携、LINEミニアプリ開発まで。顧客接点のデータを統合し、LTVと売上を上げるLINE活用を実現します。