公開日: 2026 年 5 月 21 日
Google I/O 2026 では、ログインが面倒ではないウェブについて説明しました。ログインは、ユーザーが実際に安全だと感じられる、安全でシンプルなエントリ ポイントであるべきです。 この記事では、アカウント フローを修正し、手間を省き、最初からユーザーを保護する方法について説明します。
クイック アクセス
モダナイゼーションが重要な理由
手間のかかるフロー（煩雑な登録フォーム、「パスワードを忘れた場合」のループ、ログイン ボタンの羅列など）は、ユーザーの意欲を削ぎます。ユーザーを離脱させる「コンテキスト スイッチ キラー」です。従来のパスワードやワンタイム パスワード（OTP）も、フィッシングの標的になりやすいものです。
手間がかかるほど、ユーザーが離脱する可能性が高まります。認証をモダナイズすることで、システムとユーザーを保護できます。ID ジャーニーのすべてのタッチポイントをスムーズにすることで、コンバージョン率を自然に高めることができます。たとえば、pixiv はパスキーを実装した後、ログイン成功率が99% に達しました （パスワードよりも 29% 向上）。脆弱な認証情報から移行することで、より迅速かつ安全になります。
アカウント作成を効率化する
ユーザーがアプリに初めてアクセスしたときの印象は重要です。アカウント作成を効率化することは、導入と安全性を向上させるための第一歩です。
ID 連携をメイン アカウント作成方法にする
ID 連携を使用すると、ユーザーは Google などの信頼できるプロバイダで登録できるため、面倒なアカウント作成フォームをスキップできます。これにより、一般的な登録の手間をかけずにユーザーがアプリにアクセスできる、堅牢で効率的な登録エクスペリエンスを提供できます。
連携により、ユーザーは名前やメールを手動で入力する必要がなくなります。プロバイダがすでにユーザーを確認しているため、個別に確認する冗長な手順をスキップして、より多くのユーザーに利用してもらうことができます。
また、フェデレーション ID ソリューションを導入すると、専用の IdP（ID プロバイダ）のセキュリティ レベルを継承できます。IdP は ID とセキュリティに特化しているため、そのインフラストラクチャを利用することで、認証をゼロから構築するリスクを回避できます。
Federated Credential Management（FedCM）API を採用する
IdP として機能する場合は、FedCM API を採用することをおすすめします。ブラウザ UI を介してやり取りを処理し、トラッキングを防ぐことでプライバシーを保護しながら、 ワンタップでログインできるようにします。また、関連するアカウントのみを表示することで UIを整理します。
「連携してからアップグレード」パターン
「連携してからアップグレード」は、連携の速さとパスキーの長期的なセキュリティを組み合わせたものです。連携ログインの直後にパスキーを求めるようにすると、ユーザーの次回のログインは最初からフィッシングに強くなります。
自動入力用にフォームを最適化する
手動フォームが必要な場合は、説明的な name 属性と id 属性を使用し、正しい autocomplete 値を使用して、ブラウザがユーザーの代わりにフィールドに入力できるようにします。これにより、登録プロセス中の認知負荷と入力ミスを減らすことができます。フォームの最適化について詳しくは、登録フォームのベスト
プラクティスをご覧ください。
<label for="email">Email</label>
<input type="email" id="email" name="email" autocomplete="email">
<label for="password">New Password</label>
<input type="password" id="password" name="password" autocomplete="new-password">
属性の確認をスムーズに行う
ユーザーがアプリを離れてメールでコードを確認する必要があると、コンバージョン率が低下します。コンテキスト スイッチにより、ユーザーは気が散って戻ってこなくなる可能性があります。
メール確認プロトコル（EVP）について
メール確認プロトコル （EVP）は、アプリケーションがブラウザを介して確認済みのメールアドレスを直接取得できるようにする、新しい 機能です。
この機能を使用するには、
autocomplete="email-verification-token" 属性と challenge を持つ非表示の入力フィールドを追加します。ブラウザは入力からメール ドメインを解析し、メール発行者にユーザーがこのメールを管理していることを確認するようリクエストします。確認が成功すると、ブラウザは確認済みのメールのクレームを表示します。バックエンドで即座に確認できます。ユーザーにとって、このフローはシームレスに行われます。メール確認時にのみ通知が表示されます。
EVP を使用すると、ログイン、登録、パスワードの再設定で、ユーザーを離脱させる手間（マジックリンクやメール OTP など）が不要になります。
<input id="email" type="email" autocomplete="email">
<input type="hidden" name="token" challenge="1234" autocomplete="email-verification-token">
EVP のサポートは、個々のメール サービス プロバイダに委ねられています。EVP のサポートを予定しているかどうかは、ご利用のプロバイダにお問い合わせください。カスタム ドメインをお持ちの場合は、EVP をサポートするメール プロバイダに接続して、EVP をサポートすることもできます。
この機能はまだ試験運用段階であるため、 この機能に関するフィードバックをGitHub リポジトリでお寄せください。
Digital Credentials API
戸籍上の姓名や年齢などの機密情報については、Digital Credentials API を使用すると、ブラウザを介した選択的開示により、ユーザーのウォレットから確認済みのデータをリクエストできます。つまり、ユーザーのプライバシーを保護しながら、生年月日や戸籍上の姓名を実際に受け取ることなく、ユーザーが特定の年齢を超えていることを確認できます。
Digital Credentials API: ウェブ上の安全でプライベートな ID をご覧ください。
パスキーを実装してシームレスなログインを実現する
パスキーは、単なるパスワードの代替ではありません。フィッシングに強いシームレスな認証への根本的な移行です。
即時 UI モード
Chrome 149 以降では、即時 UI モードを利用できます。 ユーザーがサイトに移動したときに、ウェブサイトで認証情報を確認できます。パスワード マネージャーでパスキーまたはパスワードが利用可能な場合、ブラウザはログイン ダイアログで利用可能なアカウントのリストを使用してフローを仲介します。
これにより、ユーザーがログイン方法を選択する必要がなくなります。選択したアカウントの認証情報を事前に提供することで、ユーザーにとって魔法のような、手間のかからない「ワンタップ」エクスペリエンスを実現できます。
const credential = await navigator.credentials.get({
password: true,
uiMode: 'immediate',
publicKey: publicKeyObject,
});
ログインの即時 UI モードをご覧ください。
パスキー フォームの自動入力: パスキーへの移行中にフォームの自動入力を使用する
パスワードからパスキーに移行中のウェブサイトのユーザーの場合、パスキー フォームの自動入力により、入力フィールドにフォーカスすると、自動入力の候補にパスキー が表示されます。つまり、ユーザーがすでにパスキーを持っている場合、ログイン フォームのユーザー名フィールドにフォーカスしたときに表示されます。パスキーがない場合は、保存したパスワードを使用できます。
これを有効にするには、ユーザー名フィールドに autocomplete="username webauthn"
のアノテーションを付け、mediation の値を 'conditional' に設定します。
navigator.credentials.get()
これは、パスワードレスの未来への移行において重要な架け橋となります。ユーザーは使い慣れたインターフェースでパスキーに慣れることができます。
パスキー認証 チェックリストをご覧ください。
パスキーの戦略的な導入
導入はタイミングが重要です。適切なタイミングでユーザーにプロンプトを表示すると、パスキーを登録する可能性が大幅に高まります。
パスキーの自動作成
新しいログイン方法を設定するために、セキュリティ設定を掘り下げる必要はありません。既存のパスワード ユーザーに対して、パスキーへのアップグレードをいつ、どのように促すべきでしょうか？
そこで役立つのが、パスキーの自動 作成です。条件付き作成を使用すると、ユーザーがパスワード マネージャーでログインした瞬間に、ブラウザがパスワード ユーザーをパスキーに自動的にアップグレードできます。
パスワード マネージャーに保存されているパスワードを使用してユーザーが最近ログインに成功したときにトリガーされる navigator.credentials.create()
API に mediation: 'conditional' を渡すことで、ブラウザは追加の設定画面を表示することなく、ネイティブに新しいパスキーを生成します。
手間のかからない登録とは、ユーザーがセキュリティを強化するために意識的に判断する必要がないことを意味します。自動的に行われるため、追加の作業は必要ありません。たとえば、adidas はこのプロンプトなしの 戦略を使用して、パスキーの 作成数を 8% 増加させました。
await navigator.credentials.create({
mediation: 'conditional',
publicKey: { ... },
});
パスキー登録 チェックリストをご覧ください。
パスキーの管理と復元
ユーザーは、デバイス、ウェブサイト、サービス間で認証情報をすぐに利用できるようにすることが重要です。また、デバイスの紛失や盗難が発生した場合にアカウントを復元できるように、認証情報を管理する必要があります。
クロスプラットフォームの一貫性
ログイン システムを共有する複数のプロパティ（Android アプリとウェブサイト、複数のウェブサイトなど）がある場合は、ユーザー エクスペリエンスを向上させることができます。シームレスな認証情報の共有により、パスワード マネージャーはすべてのプロパティで適切な認証情報をユーザーに提案できます。
シームレスな認証情報 共有 は、パスワードの Digital Asset Links とパスキーの関連 オリジン リクエストの 2 つのテクノロジーで構成されています。
Digital Asset Links を使用すると、ウェブで作成されたパスワードを Android アプリで使用できるようになります。また、パスワード マネージャーは、同じ認証バックエンドを共有する所有する別のドメインで、すでに保存されている認証情報を提案できます。
関連オリジン リクエストを使用して、ユーザーの 認証情報マネージャーを介して、さまざまなドメインやアプリで パスキーを利用できるようにします。
これは、ユーザーのログイン エクスペリエンスをスムーズにするもう 1 つの方法です。
パスキー管理ページでユーザーを支援する
高度なパスキー エクスペリエンスを実現するには、専用の パスキー管理ページを作成し、 プロバイダ名、使用時間、コントロールを明確にサポートすることをおすすめします。これにより、ユーザーは安心して設定を管理できます。透明性は信頼を築きます。
パスキー管理 チェックリストをご覧ください。
復元力のあるアカウント復元
デバイスが紛失したり、アップグレードされたりする可能性があります。パスキーはハードウェア レベルの保護を使用し、通常はクラウドに同期されるため、本質的に復元力があり、新しいデバイスで復元できます。ただし、確認済みのメールアドレスなどのフォールバックを用意しておくと、ユーザーはデジタル ライフにアクセスできなくなります。
ヘルプデスクへの電話で待機させるのではなく、ID 連携やメール確認など、すでに信頼しているシグナルを使用して、ユーザーが所有者であることを証明できます。
これらのシグナルを復元戦略に組み合わせることで、その場でアクセスを復元できます。復元したら、すぐに新しいパスキーを登録して、フィッシングから保護します。
DBSC によるセッションの保護
アカウントの不正使用からユーザーを保護するには、セッション Cookie を安全に保つことも重要な防御策です。デバイスにバインドされたセッション認証情報 （DBSC）は、セッションをハードウェアにバインドする方法です。Cookie が盗まれても、同じデバイスのみが Cookie の再発行をリクエストできるため、セッション ハイジャックが緩和され、セッションにセキュリティ レイヤが追加されます。
DBSC は試験運用版の機能で、現在 Windows で利用できます。このアップデートについて詳しくは、Windows でのデバイスにバインドされたセッション認証情報 のお知らせをご覧ください。また、macOS への DBSC サポートの拡大にも取り組んでいます。
パスキー エージェントのスキル
この記事で説明した多くの側面をカバーするパスキー スキルを、 弊社の Modern Web Guidance プロジェクトに含めました。パスキー スキルに関するブログ投稿を近日公開予定です。
認証の未来を築く準備はできましたか？
詳細なガイドをご覧になり、今すぐモダナイゼーションを開始しましょう。