会員登録・ソーシャルログインのUX設計｜離脱を防ぐフォーム・ボタン・Apple審査要件

会員登録の完了率は、UXの設計で大きく変わります。項目の数、登録を求めるタイミング、入力欄そのものの作り込み、そしてソーシャルログインのボタンの見せ方——どれも離脱に直結します。さらに、ソーシャルログインを載せるなら、避けて通れないものが二つあります。各SNSの公式ボタンガイドラインと、見落とされがちなAppleの審査要件です。これらを外すと、最悪の場合、アプリがリジェクトされたり、規約違反になったりします。この記事では、データにもとづくフォームの原則から、入力欄の実装テクニック、ボタン設計、複数SNSの並べ方、同意・プライバシーまでを、一次情報にもとづいて整理します。離脱の全体像そのものは 「会員登録の離脱を減らす（EFO×ソーシャルログイン）」 にあり、本稿はその中でも“見せ方・ボタン・実装要件”に踏み込みます。

データが示すこと——フォームの「長さ」が離脱を決める

まず、事実から入ります。各種調査の平均でカゴ落ち率は約70%（Baymardで70.22%）、その離脱理由の上位には「アカウント作成を求められた」（約19%）と「手続きが長い・複雑」（約18%）が並びます。フォームの実態を見ると、米国の平均的なチェックアウトはおよそ23の入力要素を並べており、最適化すれば12〜14要素まで削れる（Baymard）。この差は小さくありません。チェックアウト設計の改善で、大規模ECはコンバージョンを最大35%程度改善できるとの推計もあります。

なぜ「長さ」がこれほど効くのでしょうか。入力欄の一つひとつは、ユーザーにとって「入力するか、やめるか」を判断する分岐点です。欄が増えれば判断の回数も、打ち間違いや再入力の可能性も増えます。とくにスマートフォンでは、ソフトキーボードが画面の半分近くを覆い、入力中は次の欄や送信ボタンが見えなくなります。デスクトップの感覚で欄を並べると、モバイルでは体感の負荷が跳ね上がります。フォームの長さは、単なる見た目の問題ではなく、離脱の量を直接決める変数です。

長いフォームは、それだけで機会を捨てている——UX設計の出発点は、この事実の直視です。

登録UXの原則——Nielsen Norman Groupに学ぶ

では、どう設計すべきか。UX研究の Nielsen Norman Group（NN/g）が示す原則は明快です。第一に、求める情報は最小限に。理想はメールとパスワードだけで、生年月日のような非必須項目は、登録後のプロフィール編集に回します。第二に、体験の前に登録を強制しないこと。価値を見せてから登録を促し、ECならゲスト購入を用意して、アカウント作成は購入完了後に提案します。NN/gは長年、体験の入口に立ちはだかる“ログインウォール”に反対してきました。加えて、パスワードはマスクせず可視化して入力ミスを減らし、確認のための2回入力は不要にする。細部ですが、こうした一つひとつが完了率を動かします。

ただし、原則を「知っている」ことと、それを「実装できている」ことの間には距離があります。同じ項目数のフォームでも、入力欄の作り込み次第で入力のしやすさは大きく変わります。次章では、そこに踏み込みます。

入力欄の作り込み——完了率は「属性」で変わる

同じ「メールとパスワード」を尋ねるフォームでも、実装の質でモバイルでの入力体験はまるで違います。ここは画面上の見た目には表れにくい部分ですが、完了率を左右する勘所です。順に見ていきます。

入力を先回りさせる——autocomplete と入力モード

最初の勘所は、ブラウザやOSが持つ自動入力を最大限に活かすことです。各入力欄に autocomplete 属性で正しい値を指定すると、ブラウザは保存済みの情報を的確に候補として提示できます。氏名なら name、メールなら email、電話番号なら tel、既存ユーザーのパスワードなら current-password、新しく設定するパスワードなら new-password を指定します。とくに new-password は、ブラウザやパスワード管理ツールに「ここで強いパスワードを生成・保存してよい」と伝える合図になり、使い回しを防ぎます。

SMSで届く確認コードの欄に one-time-code を指定しておけば、iOSやAndroidは受信した数字をキーボード上部に提示し、ワンタップで入力できます。ユーザーがSMSアプリへ切り替えて数字を覚え、戻って打ち直す——という、最も脱落しやすい往復を丸ごと省けます。あわせて、欄の性質に応じて type と inputmode を正しく選びます。メール欄を type="email" にすればモバイルのキーボードに「＠」が現れ、電話番号を type="tel" や inputmode="numeric" にすれば数字パッドが立ち上がります。確認コードのように数字だけを打つ欄も inputmode="numeric" が向きます。標準のテキスト欄のままだと、ユーザーは入力のたびにキーボードを切り替える手間を強いられます。

ラベルとエラーを、支援技術にも届く形で

入力欄には必ずラベルを、プレースホルダーで代用せずに関連付けます。label 要素を for 属性で欄に結びつけておけば、ラベル文字をタップしても欄にフォーカスが入り、スクリーンリーダーも「何を入力する欄か」を読み上げられます。プレースホルダーは入力を始めると消えてしまい、記入例や必須条件を隠してしまうため、ラベルの代わりにはなりません。

エラーの見せ方も設計対象です。エラーは該当する欄のすぐ近く、多くはその直下に、何が問題でどう直せばよいかを言葉で示します。フォームの末尾にまとめて出したり、枠を赤くするだけで「間違い」を伝えたりする方法は、どこを直すべきか分からず、色を判別しにくい人にも届きません。動的に現れるエラーメッセージは aria-live の領域に置き、問題のある欄には aria-invalid を付けて、支援技術にも変化が伝わるようにします。ラベルや補足の説明文は aria-describedby で欄に結びつけておきます。見た目のわかりやすさと、支援技術への伝わりやすさは、両立させて初めて意味を持ちます。

検証のタイミングとパスワードの扱い

リアルタイムバリデーションは、使い方を誤ると逆効果です。ユーザーがまだ入力し終えていないのに「メールアドレスの形式が不正です」と赤字を出すと、急かされ、責められている印象を与えます。定石は、入力中は邪魔をせず、欄からフォーカスが外れた時点（あるいは送信時）に検証すること。そして、いったんエラーを出した欄は、ユーザーが直し始めたら速やかに再評価し、直った瞬間にエラーを消します。「正しく直った」ことがその場で分かると、安心して先へ進めます。

パスワードには可視化トグルを添えます。入力値を伏字にしたままだと打ち間違いに気づけず、送信して初めて弾かれる、という体験になりがちです。目のアイコンなどで表示・非表示を切り替えられれば、ミスをその場で確認できます。前章のとおり、確認のための2回入力は基本的に不要です。可視化と new-password による生成・保存のほうが、二重入力より確実にミスを防ぎます。

レイアウトとタップ領域

配置は1カラムが基本です。横に2つの欄を並べると、視線とカーソルの動きが複雑になり、モバイルでは特に押し間違いが増えます。上から下へ一直線に進む構成が、迷いを生みません。モバイルでは、ボタンやリンク、チェックボックスを指で確実に押せる大きさにし、隣り合う要素との間隔も十分にとります。小さな要素が密集していると、意図しない箇所をタップして入力が乱れます。送信ボタンはキーボードで隠れない位置に置き、入力中でも「次に何を押すか」が見える状態を保ちます。こうした細部は派手さこそありませんが、完了率にそのまま表れます。

同じ項目数のフォームでも、実装の質で完了率は変わります。属性とバリデーションは、地味に見えて効く投資です。

ソーシャルログインボタンは「公式ガイドライン準拠が必須」

ここからが、多くの解説が踏み込まない実務です。ソーシャルログインのボタンは、各社の公式ガイドラインに従う必要があり、自社の好みで統一デザインにするのは認められていません。まず主要3社の要点を表で整理し、その上で個別に補足します。

LINEは、基本色 #06C755 を指定し、文字とロゴは白です。ボタン内の文字は「LINEでログイン」を基本にカスタムもできますが、改行はできず、LINEでログインする機能だと明確に伝わる表現である必要があります（LINEアイコンを単独で使う形も認められています）。文字の左右にはLINEアイコンの吹き出しと同じかそれ以上の余白をとり、ボタンの周囲には他の要素を置かない保護エリア（アイソレーションゾーン）を設けます。指定外の色を使う、古いアイコンを使う、アイコンを別のものに差し替える・改変する、といった扱いは禁止です。加えて、LINEログインボタンの利用ガイドラインへの同意が前提になります。

Googleは、Light・Dark・Neutral の3テーマと、角丸・ピル形などの形状が用意されています。重要なのは、「他社のサインイン手段と少なくとも同等に目立たせる」という決まりで、サイズも視覚的な重みも、他のボタンと同程度にする必要があります。カラフルな「G」ロゴは標準の配色のまま使い、モノクロ化や色の変更はできません。Googleは公式SDKが常に最新のガイドラインに沿ったボタンを描画するため、自前で画像を作り込むより、SDKか公式提供のボタン素材を使うほうが安全です。

Appleは、black・white・whiteOutline の3スタイルが用意され、白は暗い背景、白＋アウトラインは明るい背景、と使い分けます。文言は「Sign in with Apple」「Sign up with Apple」「Continue with Apple」から選び、日本語などへのローカライズは可能です。ロゴと文字は黒か白のいずれかで、独自の色は使えません。角丸は他のボタンに合わせて調整でき、高さの目安は44ptです。

なぜここまで厳密なのでしょうか。理由は二つあります。一つは、各ボタンが商標・ブランド素材であり、利用にあたって各社のガイドライン（LINEのように利用条件への同意が要る場合もあります）に従うことが求められるため。もう一つは——とりわけAppleの場合——見た目の規定が審査と地続きだからです。ボタンの見せ方は、ブランド保護であると同時に、ストアの審査を通すための要件でもあります。

iOSアプリなら必読——Appleの提供要件（審査4.8）

iOSアプリを持つなら、これは知らないでは済まされません。iOSアプリで他社のソーシャルログイン（Google・X・Facebook など）を使って主要アカウント（アプリ上で本人確認・サインイン・機能利用のために作るアカウント）を作成・認証させる場合、App Store 審査ガイドライン4.8「Login Services」により、次の3条件を満たす別のログイン手段を“同等の選択肢”として併せて提供しなければなりません。

ここで押さえておきたいのは、「別のログイン手段」は必ずしも Sign in with Apple でなくてよい、という点です。上の3条件を満たす認証サービスであれば、選択肢として認められます。逆に、この併設義務そのものが生じない場合もあります。たとえば、アプリが自社の会員基盤だけで登録・サインインを完結している場合や、企業・教育機関の既存アカウントでのサインインを求めるアプリ、行政・業界の本人確認（電子ID等）を使うアプリなどは、対象外とされています。裏を返せば、他社のソーシャルログインを“主要アカウントの入口”として一つでも出した瞬間に、この条件が効いてくるということです。

つまり、iOSアプリで「LINEログインだけ」を出すような設計は、審査で引っかかる可能性があります。ボタンをどう出すかは、見た目の問題である前に、審査を通すための要件だと理解しておくべきです。日本のユーザーにはLINEログインが最も摩擦の少ない入口であることが多いだけに、iOSでは3条件を満たす別手段を併設する前提で設計しておくと、後戻りを避けられます。

複数のソーシャルログインは「並べすぎない」

選択肢は多いほど親切、ではありません。むしろ逆です。カラフルなボタンを3つも4つも並べると、本来の主導線であるゲスト購入やメール登録が埋もれ、ユーザーを選択で迷わせます（Baymard）。しかも、以前どの方法で登録したかを忘れたユーザーは、「Googleで作ったのか、メールだったのか」を思い出せず、別の手段で二重にアカウントを作ってしまうこともあります。手段の多さは、それ自体が新たな混乱の種になり得ます。

定石は、主要な2〜3手段だけを目立たせ、それ以外は「その他のログイン方法」に折りたたむこと。そして何より、ゲスト購入・メール登録という“誰でも使える主導線”をいちばん目立たせ、ソーシャルログインはそれを速める“加速装置”として補助的に置くのが正解です。どれを主役にするかは、ユーザー層で決めます。新規と既存を分けたくない入口には、「◯◯で続ける（Continue with 〜）」という、登録とログインのどちらにも読める文言が向きます。日本のスマホ主体サービスなら、まずLINEログインを主軸に、ユーザー層に応じてGoogle/Appleを併設——という構成が現実的でしょう（ただし前章のとおり、iOSアプリでは4.8の併設要件を忘れずに）。ソーシャルログインそのものの仕組みは ソーシャルログインとは で解説しています。

同意・プライバシーの見せ方——最小限を、必要な時に

最後に、取得情報の見せ方です。要求するスコープ（情報の範囲）は最小限に。ソーシャルログインでは、事業者が要求した情報の一覧が同意画面に並びます。ここで住所や友だちリストまで欲張ると、ユーザーは「なぜこの情報が要るのか」と身構え、その場で離脱します。同意画面は、信頼が試される最後の関門です。

有効な考え方が、Googleが推奨するインクリメンタル認可です。登録の入口では本人確認に要る最小限（多くは氏名とメール）だけを求め、追加の情報や権限は、それを使う機能にユーザーが進んだ時点で、理由を添えて改めて求めます。たとえばカレンダー連携やファイル添付といった機能は、その機能を使おうとした瞬間に認可を求めれば、ユーザーは「何のためか」を理解した状態で許可でき、拒否されにくくなります。最初の同意画面に全部を積み上げる設計より、離脱も不信も生みにくくなります。なお、LINEでメールアドレスを取得するには、あらかじめ権限（メールアドレス取得）の申請が前提になります。何が取得されるのかは 取得できる情報 に整理しています。

法令面でも、この“最小限”は理にかなっています。個人情報保護法（第21条）により、本人から直接取得する場合は、入力画面などで利用目的を閲覧できるようにし、目的は「できる限り具体的に特定」する必要があります。「運営に必要な一切の目的」といった包括的な表現は認められません。取得する項目を絞り、それぞれ何に使うのかを具体的に示すことは、離脱対策であると同時に、法令上の要請でもあるのです。

過剰な要求を避けることは、離脱対策であると同時に、コンプライアンスでもあります。

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

参考にした一次情報：Baymard Institute（カゴ落ち率・チェックアウト要素数）、Nielsen Norman Group（登録／ログインのUX、ログインウォール）、各社公式ボタンガイドライン（LINE Developers／Google「Sign in with Google」／Apple「Sign in with Apple」HIG・審査ガイドライン4.8）、個人情報保護委員会（個人情報保護法・利用目的の特定）。仕様・ガイドライン・要件は改定される場合があるため、実装時は各社の最新情報をご確認ください（数値・要件は執筆時点）。