このページは Cloud Translation API によって翻訳されました。

登録フォームのベストプラクティス

ユーザーが手間をかけずに登録、ログイン、アカウントの詳細の管理を行えるようにします。

Sam Dutton

ユーザーがサイトにログインする必要がある場合は、登録フォームを適切に設計することが重要です。これは、接続が不安定な場合、モバイルを使用している場合、急いでいる場合、ストレスを感じている場合に特に当てはまります。登録フォームの設計が不適切だと、直帰率が高くなります。バウンスは、見込み顧客の獲得機会を逃すだけでなく、不満を抱えたユーザーを失う可能性もあります。

以下に、すべてのベストプラクティスを示す非常にシンプルな登録フォームの例を示します。

チェックリスト

可能であればログインを避ける。
アカウントの作成方法を明確にします。
アカウントの詳細にアクセスする方法が明確にわかるようにする。
フォームの煩雑さを解消する。
セッションの長さを考慮する。
パスワードマネージャーがパスワードを安全に提案して保存できるようにする。
不正使用されたパスワードを許可しない。
パスワードの貼り付けを許可する。
パスワードを平文で保存または送信しないでください。
パスワードの強制更新は行わない。
パスワードの変更や再設定を簡単にする。
連携ログインを有効にします。
アカウントの切り替えを簡単にする。
多要素認証の提供を検討する。
ユーザー名には注意してください。
ラボだけでなくフィールドでもテストします。
さまざまなブラウザ、デバイス、プラットフォームでテストできます。

登録フォームを実装してユーザーにサイト上でアカウントを作成するよう求める前に、本当に必要なかどうかを検討してください。可能な限り、ログイン後に機能を制限することは避けてください。

最適な登録フォームは、登録フォームを使わないことです。

アカウントを作成するようユーザーに求めると、ユーザーが達成しようとしている目標の邪魔になります。個人データについて信頼してもらい、ユーザーに好意的を伝えています。保存するパスワードやデータアイテムには、プライバシーとセキュリティの「データ債務」が伴い、サイトの費用と責任になります。

ユーザーにアカウントの作成を求める主な理由が、ナビゲーションやブラウジングセッション間で情報を保存することである場合は、代わりにクライアントサイドストレージの使用を検討してください。ショッピングサイトの場合、購入のためにユーザーにアカウントの作成を強制することが、ショッピングカートの放棄の主な理由として挙げられています。ゲスト購入をデフォルトにする必要があります。

ログインを明確にする

ページの右上にある [ログイン] ボタンや [ログイン] ボタンなど、サイトでアカウントを作成する方法を明確にします。曖昧なアイコンやあいまいな文言（「参加する」、「「参加」）し、ナビゲーションメニューにログインを非表示にしないでください。ユーザビリティの専門家である Steve Krug は、ウェブサイトのユーザビリティに対するこのアプローチを「Don't make me think!（考えさせないで！）」とまとめています。ウェブチームの他の人に説得する必要がある場合は、アナリティクスを使用して、さまざまなオプションの影響を示します。

Android スマートフォンで表示された e コマースウェブサイトのモックアップのスクリーンショット（2 枚）。左側は、ログインリンクにわかりにくいアイコンを使用しています。右側は「ログイン」とだけ表示しています。 — ログインをわかりやすくします。アイコンはわかりにくい場合がありますが、[**ログイン**] ボタンやリンクはわかりやすいものです。

Gmail のログインのスクリーンショット: [ログイン] ボタンが表示された 1 つのページをクリックすると、[アカウントを作成] リンクのあるフォームが表示される。 — Gmail のログインページには、アカウントを作成するためのリンクがあります。
ここで示されているよりも大きなウィンドウサイズでは、Gmail に [**ログイン**] リンクと [**アカウントを作成**] ボタンが表示されます。

Google などの ID プロバイダ経由で登録し、メールアドレスとパスワードでも登録したユーザーのアカウントを必ずリンクしてください。ID プロバイダのプロファイルデータからユーザーのメールアドレスにアクセスし、2 つのアカウントを一致できれば、これを簡単に行うことができます。次のコードは、Google ログインユーザーのメールデータにアクセスする方法を示しています。

// auth2 is initialized with gapi.auth2.init()
if (auth2.isSignedIn.get()) {
  var profile = auth2.currentUser.get().getBasicProfile();
  console.log(`Email: ${profile.getEmail()}`);
}

アカウントの詳細情報にアクセスする方法を明示する

ユーザーがログインしたら、アカウントの詳細にアクセスする方法について明確に説明します。特に、パスワードを変更または再設定する方法を明確にしてください。

フォームの不要な要素を削減する

登録フローでの仕事は、複雑さを最小限に抑え、ユーザーの作業に集中できるようにすることです。不要なものを削減。気を散らすものや誘惑に負ける時間ではありません。

ユーザーの注意をそらさず、登録を完了できるようにする。

登録時に、できるだけ少ない情報を尋ねます。追加のユーザーデータ（名前や住所など）は、必要な場合と、ユーザーがそのデータの提供に明確なメリットを感じている場合にのみ収集してください。通信して保存するデータはすべて、費用と責任を伴うことに注意してください。

ユーザーが連絡先情報を正しく入力できるようにするためだけに、入力を重複させないでください。これにより、フォームの入力が遅くなり、フォームフィールドが自動入力されている場合は意味がありません。代わりに、ユーザーが連絡先情報を入力したら確認コードを送信し、ユーザーが返信したらアカウントの作成を続行します。これは一般的な登録パターンであり、ユーザーは慣れています。

新しいデバイスやブラウザでログインするたびにユーザーにコードを送信する、パスワード不要のログインを検討することもできます。Slack や Medium などのサイトでは、このバージョンが使用されています。

medium.com でパスワード不要のログイン。

連携ログインと同様に、ユーザーのパスワードを管理する必要がないという利点もあります。

セッションの長さについて検討する

ユーザー ID にどのようなアプローチを採用する場合でも、セッションの長さ（ユーザーがログインしたままの状態を維持できる時間と、ログアウトする原因となる可能性のあるもの）について慎重に判断する必要があります。

ユーザーがモバイルかパソコンか、パソコンで共有しているかデバイスを共有しているかを検討します。

パスワードマネージャーがパスワードを安全に提案、保存できるようにする

サードパーティ製およびブラウザに組み込まれたパスワードマネージャーがパスワードを提案して保存できるようにすることで、ユーザーがパスワードを選択、記憶、入力する必要がなくなります。パスワードマネージャーは最新のブラウザで適切に動作し、デバイス間、プラットフォーム固有のアプリやウェブアプリ間でアカウントを同期します。また、新しいデバイスでも機能します。

そのため、登録フォームを正しくコーディングし、特に正しい自動入力値を使用することが非常に重要です。登録フォームでは、新しいパスワードに autocomplete="new-password" を使用し、可能であれば他のフォームフィールド（autocomplete="email" や autocomplete="tel" など）に正しい自動入力値を追加します。また、登録フォームとログインフォームで、form 要素自体、および input、select、textarea 要素に異なる name 値と id 値を使用すると、パスワードマネージャーの利便性を高めることができます。

また、適切な type 属性を使用して、モバイルで適切なキーボードを提供し、ブラウザによる基本的な組み込み検証を有効にする必要があります。詳しくは、お支払いフォームと住所フォームのベストプラクティスをご覧ください。

ユーザーが安全なパスワードを入力できるようにする

パスワードマネージャーでパスワードの候補を表示できるようにするのが最善の方法です。ブラウザやサードパーティのブラウザマネージャーが提案する強力なパスワードをユーザーに受け入れるよう促してください。

ただし、多くのユーザーは自分のパスワードを入力するため、パスワードの安全度に関するルールを実装する必要があります。米国国立標準技術研究所は、安全でないパスワードを回避する方法について説明しています。

不正使用されたパスワードを許可しない

パスワードにどのようなルールを選択する場合でも、セキュリティ侵害で漏洩したパスワードは決して許可しないでください。

ユーザーがパスワードを入力したら、すでに不正使用されているパスワードではないことを確認する必要があります。サイト Have I Been Pwned にはパスワードチェック用の API が用意されています。また、これをサービスとして自分で実行することもできます。

Google のパスワードマネージャーでは、既存のパスワードが不正使用されていないかを確認することもできます。

ユーザーが提案したパスワードを拒否する場合は、拒否された理由を具体的に伝えます。問題をインラインで表示し、解決方法を説明する: ユーザーが値を入力したらすぐに（ユーザーが登録フォームを送信してサーバーからの応答を待つまで待つ必要はありません）。

パスワードが拒否された理由を明確にします。

パスワードの貼り付けを禁止しない

サイトによっては、パスワード入力欄にテキストを貼り付けることができない場合があります。

パスワードの貼り付けを禁止すると、ユーザーの不満が増大し、覚えやすいパスワード（そのため侵害されやすくなる）が推奨されるようになります。英国国家サイバーセキュリティセンターなどの組織によると、実際にはセキュリティが低下する可能性があります。ユーザーは、パスワードを貼り付けようとした後に初めて貼り付けを禁止することに気づきます。そのため、パスワードの貼り付けを無効にしてもクリップボードの脆弱性は回避できません。

パスワードを平文で保存または送信しないでください

パスワードをソルトとハッシュにすることを忘れないでください。独自のハッシュアルゴリズムを考案しようとしないでください。

パスワードを強制的に更新しない

ユーザーにパスワードの任意の更新を強制しないでください。

パスワードの強制更新は、IT 部門にとって費用がかさみ、ユーザーにとって煩わしく、セキュリティにはあまり影響しません。また、安全ではない覚えやすいパスワードの使用や、パスワードの物理的な記録の保存を奨励する可能性もあります。

パスワードの強制更新ではなく、アカウントの異常なアクティビティをモニタリングしてユーザーに警告する必要があります。可能であれば、データ侵害によって漏洩したパスワードもモニタリングする必要があります。

また、アカウントのログイン履歴にアクセスできるようにし、ログインした場所と日時をユーザーに示すことが必要です。

パスワードの変更や再設定を簡単にする

アカウントのパスワードを更新する場所と方法をユーザーに明確に示します。サイトによっては、驚くほど難しい場合があります。

もちろん、ユーザーがパスワードを忘れた場合に簡単に再設定できるようにすることも必要です。Open Web Application Security Project では、パスワードを紛失した場合の対応方法について詳細なガイダンスが提供されています。

ビジネスとユーザーの安全を守るために、パスワードの不正使用に気付いたユーザーがパスワードを変更できるようにすることは特に重要です。これを簡単にするには、パスワード管理ページにリダイレクトする /.well-known/change-password URL をサイトに追加する必要があります。これにより、パスワードマネージャーは、ユーザーをサイトのパスワードを変更できるページに直接移動させることができます。この機能は現在 Safari と Chrome に実装されており、今後他のブラウザにも導入される予定です。パスワード変更用のよく知られた URL を追加して、ユーザーが簡単にパスワードを変更できるようにするでは、この実装方法について説明します。

また、ユーザーが希望する場合は、アカウントを簡単に削除できるようにする必要があります。

多くのユーザーは、メールアドレスとパスワードの登録フォームを使用してウェブサイトにログインすることを好みます。ただし、ユーザーがサードパーティの ID プロバイダ（連携ログイン）経由でログインできるようにすることも必要です。

Google と Apple のログインオプションがある WordPress のログインページ。

このアプローチには次のようなメリットがあります。連携ログインを使用してアカウントを作成するユーザーに対して、パスワードの入力、伝達、保存を要求する必要はありません。

フェデレーションログインから、メールアドレスなどの確認済みの追加のプロフィール情報にアクセスできる場合もあります。つまり、ユーザーがそのデータを入力する必要はなく、管理者が自分で確認する必要もありません。フェデレーションログインを使用すると、ユーザーが新しいデバイスを入手する際にも非常に簡単にログインできます。

ウェブアプリへの Google ログインの統合では、登録オプションに連携ログインを追加する方法について説明しています。他にも多くの ID プラットフォームが利用可能です。

注: 新しいデバイスを受け取ったときの「初日のエクスペリエンス」はますます重要になっています。ユーザーは、スマートフォン、ノートパソコン、パソコン、タブレット、テレビ、自動車など、複数のデバイスからログインすることを期待しています。登録フォームとログインフォームがシームレスでない場合、ユーザーを失うリスクが生じます。少なくとも、ユーザーが再び設定するまで、ユーザーとの連絡が途絶える可能性があります。新しいデバイスでユーザーがサイトを使い始められるように、できるだけ迅速かつ簡単に設定できるようにする必要があります。この点でも、フェデレーションログインが役に立ちます。

アカウントの切り替えを簡単にする

多くのユーザーは、デバイスを共有し、同じブラウザを使用してアカウントを切り替えています。ユーザーがフェデレーションログインにアクセスするかどうかにかかわらず、アカウントの切り替えをシンプルにする必要があります。

多要素認証の提供を検討する

多要素認証とは、ユーザーが複数の方法で認証を行うことを確認することを意味します。たとえば、ユーザーにパスワードの設定を要求するだけでなく、メールまたは SMS テキストメッセージで送信されるワンタイムパスコード、アプリベースのワンタイムコード、セキュリティキー、指紋センサーを使用して確認を強制することもできます。SMS OTP のベストプラクティスと WebAuthn による強力な認証の有効化で、多要素認証を実装する方法について説明します。

サイトが個人情報や機密情報を扱う場合は、多要素認証を提供（または適用）する必要があります。

ユーザー名に注意する

必要な場合以外（または必要なときまで）でない限り、ユーザー名を要求しないでください。ユーザーがメールアドレス（または電話番号）とパスワードのみで登録およびログインできるようにします。必要に応じて、認証連携ログインも有効にします。ユーザー名を選択して覚えておくことを強要しないでください。

サイトでユーザー名が必要とされている場合は、ユーザーに不当なルールを適用したり、ユーザーがユーザー名を更新するのを妨げたりしないでください。バックエンドで、ユーザー名などの個人データに基づく識別子ではなく、ユーザーアカウントごとに一意の ID を生成する必要があります。

また、ユーザー名には autocomplete="username" を使用してください。

さまざまなデバイス、プラットフォーム、ブラウザ、バージョンでテストできる

ユーザーが最もよく使用するプラットフォームで登録フォームをテストします。フォーム要素の機能は異なる場合があります。また、ビューポートのサイズが異なると、レイアウトの問題が発生する可能性があります。BrowserStack では、さまざまなデバイスやブラウザでオープンソースプロジェクトの無料テストを行うことができます。

分析とリアルユーザーモニタリングを実装する

ユーザーが登録フォームをどのように使用しているかを把握するには、フィールドデータとラボデータが必要です。アナリティクスとリアルユーザーモニタリング（RUM）では、ユーザーの実際の操作に関するデータ（登録ページの読み込み時間、ユーザーが操作した（または操作しなかった）UI コンポーネント、ユーザーが登録を完了するまでの時間など）が提供されます。

ページ分析: 登録フローの各ページのページビュー、直帰率、離脱数。
インタラクションアナリティクス: 目標到達プロセスとイベントにより、ユーザーが登録フローを放棄した場所と、登録ページのボタン、リンク、その他のコンポーネントをクリックしたユーザーの割合を確認できます。
ウェブサイトのパフォーマンス: ユーザー中心の指標を使用すると、登録フローの読み込みが遅いかどうか、視覚的に不安定かどうかを把握できます。

小さな変更が、登録フォームの完了率に大きな影響を与えることがあります。アナリティクスと RUM を使用すると、変更を最適化して優先順位を付け、ローカルテストでは検出されない問題がないかサイトをモニタリングできます。

学習を続ける

写真撮影: @ecowarriorprincess（Unsplash より）