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

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

ユーザーが簡単に登録、ログイン、アカウントの詳細を管理できるようにします。

Sam Dutton

ユーザーがサイトにログインする必要がある場合は、登録フォームを適切に設計することが重要です。これは、接続状態が悪い人、モバイルデバイスを使用している人、急いでいる人、ストレスを感じている人に特に当てはまります。登録フォームのデザインに問題があると直帰率が高くなります。ユーザーが直帰するたびに、登録機会を失うだけでなく、ユーザーが不満を抱くことにもなりかねません。

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

注意: この投稿は、フォームのベストプラクティスに関するものです。サードパーティの ID プロバイダを介した登録（フェデレーションログイン）を実装する方法や、ユーザーの認証、認証情報の保存、アカウントの管理を行うバックエンドサービスの構築方法については説明していません。登録オプションにフェデレーションログインを追加する方法については、Google ログインをウェブアプリに統合するをご覧ください。ユーザーアカウント、認証、パスワードの管理に関する 12 のベストプラクティスでは、ユーザーアカウントを管理する際のバックエンドの基本原則について説明しています。

チェックリスト

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

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

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

ユーザーにアカウントの作成を依頼することで、ユーザーとユーザーが実現しようとしていることを区別します。個人データについてあなたを信頼するようユーザーに求めています。保存するすべてのパスワードやデータ項目にはプライバシーとセキュリティの「データ負債」が伴い、サイトにとってのコストと責任となります。

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

ログインをわかりやすくする

ページの右上にある [ログイン] ボタンや [ログイン] ボタンなどを使用して、サイトでアカウントを作成する方法が明確にわかるようにします。あいまいなアイコンやあいまいな表現（例: 「参加しよう！」、「ぜひご参加ください」）。ナビゲーションメニューの中のログイン情報を非表示にしないでください。ユーザビリティのエキスパートである Steve Krug は、ウェブサイトのユーザビリティに対するこのアプローチをまとめました。Don't make me?ウェブチームの他のメンバーを説得する必要がある場合は、分析を使用して、さまざまな選択肢の影響を示します。

e コマースサイトのモックアップを Android スマートフォンで表示された 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 プラットフォームを利用できます。

アカウントの切り替えが簡単に

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

Gmail、アカウントの切り替えを示す — Gmail でのアカウントの切り替え

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

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

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

ユーザー名に注意する

必要な場合以外（または必要なとき）は、ユーザー名を強要しないでください。登録とログインに、メールアドレス（または電話番号）とパスワードのみ、または必要に応じて連携ログインを使用できるようにします。ユーザー名の選択や記憶を強要しないでください。

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

また、ユーザー名には必ず autocomplete="username" を使用します。

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

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

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

ユーザーが登録フォームでどのように操作するかを理解するには、ラボデータだけでなくフィールドデータとフィールドデータが必要です。アナリティクスと Real User Monitoring（RUM）により、登録ページの読み込みに要する時間、ユーザーが操作した（またはしない）UI コンポーネント、ユーザーが登録を完了するまでの時間など、実際のユーザーエクスペリエンスに関するデータが提供されます。

ページ分析: 登録フローにおける各ページのページビュー数、直帰率、離脱数。
インタラクション分析: ゴールファネルとイベントでは、ユーザーが登録フローを放棄した場所や、ボタンやリンクなど、登録ページのコンポーネントをクリックするユーザーの割合を把握できます。
ウェブサイトのパフォーマンス: ユーザー中心の指標から、登録フローの読み込みが遅いか、視覚的に不安定かがわかります。

小さな変化が、登録フォームの入力率に大きな違いをもたらすことがあります。分析と RUM を使用することで、変更の最適化と優先順位付けを行い、ローカルテストでは特定できない問題がないかサイトを監視できます。

さらに詳しく

写真撮影: @ecowlierprincess（Unsplash）