209 lines
20 KiB
Markdown
209 lines
20 KiB
Markdown
---
|
||
source_url: "https://developer.chrome.com/blog/io26-web-identity?hl=ja"
|
||
ingested: 2026-07-16
|
||
sha256: 847c6231c50ea6fe85642a9d041856d4a11e78a8ce30e160bcd78b419423ad5b
|
||
discovered_from:
|
||
platform: discord
|
||
channel_id: "1028287639918497822"
|
||
channel_name: "chat"
|
||
message_id: "1522471639093088318"
|
||
author_id: "890908900520505354"
|
||
posted_at: "2026-07-03T05:18:44.915000000Z"
|
||
message_excerpt: "https://developer.chrome.com/blog/io26-web-identity?hl=ja"
|
||
---
|
||
Google I/O 2026 では、ログインが面倒ではないウェブについて説明しました。ユーザーが実際に安全だと感じられる、安全でシンプルなエントリ ポイントであるべきです。 この記事では、アカウント フローを修正し、手間を省き、最初からユーザーを保護する方法について説明します。
|
||
|
||
## クイック アクセス
|
||
|
||
- [モダナイゼーションが重要な理由](https://developer.chrome.com/blog/io26-web-identity?hl=ja#why-modernization-matters)
|
||
- [アカウント作成を効率化する](https://developer.chrome.com/blog/io26-web-identity?hl=ja#streamline-account-creation)
|
||
- [属性の確認をスムーズに行う](https://developer.chrome.com/blog/io26-web-identity?hl=ja#frictionless-attribute-verification)
|
||
- [パスキーを実装してシームレスなログインを実現する](https://developer.chrome.com/blog/io26-web-identity?hl=ja#implement-passkeys)
|
||
- [パスキーの戦略的な導入](https://developer.chrome.com/blog/io26-web-identity?hl=ja#strategic-passkey-adoption)
|
||
- [パスキーの管理と復元](https://developer.chrome.com/blog/io26-web-identity?hl=ja#passkey-management)
|
||
|
||
## モダナイゼーションが重要な理由
|
||
|
||
面倒なログイン フォーム、煩わしい「パスワードを忘れた場合」のループ、ログイン ボタンの羅列など、手間のかかるフローはユーザーの意欲を削ぎます。ユーザーを遠ざける「コンテキスト スイッチ キラー」です。従来のパスワードやワンタイム パスワード（OTP）も、フィッシングの標的になりやすいものです。
|
||
|
||
手間がかかるほど、ユーザーが離脱する可能性が高まります。認証をモダナイズすることで、システムとユーザーを保護できます。ID ジャーニーのすべてのタッチポイントをスムーズにすることで、コンバージョン率が自然に向上します。たとえば、 [pixiv はパスキーを実装した後、ログイン成功率が *99% に達しました （パスワードよりも 29% 向上）。*](https://web.dev/case-studies/pixiv-passkeys?hl=ja) 脆弱な認証情報から移行することで、より迅速かつ安全になります。
|
||
|
||
## アカウント作成を効率化する
|
||
|
||
ユーザーがアプリに初めてアクセスしたときの印象は重要です。アカウント作成を効率化することは、導入と安全性を向上させるための第一歩です。
|
||
|
||
### ID 連携をメイン アカウント作成方法にする
|
||
|
||
[ID 連携を使用すると、ユーザーは面倒なアカウント作成フォームをスキップできます。ID 連携では、Google などの信頼できるプロバイダを使用してユーザーが登録できます。](https://developers.google.com/identity/gsi/web/guides/fedcm-migration?hl=ja) これにより、一般的な登録の手間をかけずにユーザーがアプリにアクセスできる、堅牢で効率的な登録エクスペリエンスを提供できます。
|
||
|
||
連携により、ユーザーは名前やメールアドレスを手動で入力する必要がなくなります。プロバイダがすでにユーザーを確認しているため、ユーザーを個別に確認する冗長な手順をスキップして、より多くのユーザーに利用してもらうことができます。
|
||
|
||
また、フェデレーション ID ソリューションを採用すると、専用の IdP（ID プロバイダ）のセキュリティ レベルを継承できます。IdP は ID とセキュリティに特化しているため、そのインフラストラクチャに依存することで、認証をゼロから構築するリスクを回避できます。
|
||
|
||
### Federated Credential Management（FedCM）API を採用する
|
||
|
||
IdP として機能する場合は、 [FedCM API](https://developer.chrome.com/docs/identity/fedcm/overview?hl=ja) を採用することをおすすめします。ブラウザ UI を介してやり取りを処理し、トラッキングを防ぐことでプライバシーを保護しながら、ユーザーに ワンタップ ログインを提供し、 [関連するアカウントのみを表示することで UI](https://developer.chrome.com/docs/identity/fedcm/overview?hl=ja#improved_user_experience) を整理します。
|
||
|
||
|
||
|
||
FedCM: アクティブ モードの UI ダイアログ。FedCM が提供する 利用可能な UI モード の詳細をご覧ください。
|
||
|
||
### 「連携してからアップグレード」パターン
|
||
|
||
「連携してからアップグレード」は、連携の速度とパスキーの長期的なセキュリティを組み合わせたものです。 *連携ログインの直後にパスキーを求めるようにすると、ユーザーの次回のログインは最初からフィッシングに強くなります。*
|
||
|
||
### 自動入力用にフォームを最適化する
|
||
|
||
手動フォームが必要な場合は、説明的な `name` 属性と `id` 属性を使用し、正しい `autocomplete` 値を使用して、ブラウザがユーザーの代わりにフィールドに入力できるようにします。これにより、登録プロセス中の認知負荷と入力ミスの可能性が軽減されます。フォームの最適化について詳しくは、 [登録フォームのベスト プラクティス](https://web.dev/articles/sign-up-form-best-practices?hl=ja) をご覧ください。
|
||
|
||
```
|
||
<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）](https://github.com/WICG/email-verification-protocol) は、新しい 機能で、アプリケーションがブラウザを介して確認済みのメールアドレスを直接 取得できるようにします。
|
||
|
||
この機能を使用するには、 `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 リポジトリ](https://github.com/WICG/email-verification-protocol) でフィードバックをお寄せください。
|
||
|
||
<video controls="" width="900"><source src="https://developer.chrome.com/static/blog/io26-web-identity/video/EVP-cropped.mp4?hl=ja" type="video/mp4"></video>
|
||
|
||
メール確認プロトコル（EVP）フローの例。
|
||
|
||
### Digital Credentials API
|
||
|
||
戸籍上の姓名や年齢などの機密情報については、 [Digital Credentials API](https://developer.chrome.com/blog/digital-credentials-api-shipped?hl=ja) を使用すると、ブラウザを介した *選択的開示* により、ユーザーのウォレットから確認済みのデータをリクエストできます。つまり、ユーザーのプライバシーを保護しながら、生年月日や戸籍上の姓名を実際に受け取ることなく、ユーザーが特定の年齢を超えていることを確認できます。
|
||
|
||
[Digital Credentials API: ウェブ上の安全でプライベートな ID をご覧ください](https://developer.chrome.com/blog/digital-credentials-api-shipped?hl=ja) 。
|
||
|
||
## パスキーを実装してシームレスなログインを実現する
|
||
|
||
パスキーは、単なるパスワードの代替ではありません。フィッシング防止に効果的なシームレスな認証への根本的な移行です。
|
||
|
||
### 即時 UI モード
|
||
|
||
Chrome 149 以降では、 [即時 UI モード](https://developer.chrome.com/blog/webauthn-immediate-ui?hl=ja) を使用できます。 ユーザーがサイトに移動したときに、ウェブサイトで認証情報を確認できます。パスワード マネージャーでパスキーまたはパスワードが利用可能な場合、ブラウザはログイン ダイアログで利用可能なアカウントのリストを使用してフローを仲介します。
|
||
|
||
<video controls=""><source src="https://developer.chrome.com/static/blog/io26-web-identity/video/immediate-mediation-explicit-flow.mp4?hl=ja" type="video/mp4"></video>
|
||
|
||
これにより、ユーザーがログイン方法を選択する必要がなくなります。選択したアカウントの認証情報を事前に提供することで、ユーザーにとって魔法のような、手間のかからない「ワンタップ」エクスペリエンスを実現できます。
|
||
|
||
```
|
||
const credential = await navigator.credentials.get({
|
||
password: true,
|
||
uiMode: 'immediate',
|
||
publicKey: publicKeyObject,
|
||
});
|
||
```
|
||
|
||
ログインの [即時 UI モード](https://developer.chrome.com/docs/identity/immediate-ui-mode?hl=ja) をご覧ください。
|
||
|
||
### パスキー フォームの自動入力: パスキーへの移行中にフォームの自動入力を使用する
|
||
|
||
パスワードからパスキーに移行中のウェブサイトのユーザーの場合、 [パスキー フォームの自動入力](https://web.dev/articles/passkey-form-autofill?hl=ja) により、入力フィールドにフォーカスすると、自動入力の候補にパスキー が表示されます。つまり、ユーザーがすでにパスキーを持っている場合、ログイン フォームのユーザー名フィールドにフォーカスしたときに表示されます。パスキーがない場合は、保存したパスワードを使用できます。
|
||
|
||
<video width="300"><source src="https://developer.chrome.com/static/blog/io26-web-identity/video/form-autofill-v2.mp4?hl=ja" type="video/mp4"></video>
|
||
|
||
フォームの自動入力によるパスキー選択の例。
|
||
|
||
これを有効にするには、ユーザー名フィールドに `autocomplete="username webauthn"` のアノテーションを付け、 `mediation` の値を `'conditional'` に設定します。 `navigator.credentials.get()`
|
||
|
||
これは、パスワードレスの未来への移行における重要な橋渡しとなります。ユーザーは使い慣れたインターフェースでパスキーに慣れることができます。
|
||
|
||
[パスキー認証 チェックリスト](https://web.dev/articles/passkey-checklist?hl=ja#passkeys_authentication) をご覧ください。
|
||
|
||
## パスキーの戦略的な導入
|
||
|
||
導入はタイミングが重要です。適切なタイミングでユーザーにプロンプトを表示すると、パスキーを登録する可能性が大幅に高まります。
|
||
|
||
### パスキーの自動作成
|
||
|
||
新しいログイン方法を設定するために、セキュリティ設定を掘り下げる必要はありません。既存のパスワード ユーザーに対して、パスキーへのアップグレードを求めるプロンプトをいつ、どのように表示すればよいでしょうか。
|
||
|
||
そこで、 [パスキーの自動 作成](https://developer.chrome.com/docs/identity/webauthn-conditional-create?hl=ja) が役立ちます。条件付き作成を使用すると、ユーザーがパスワード マネージャーでログインした瞬間に、ブラウザがパスワード ユーザーをパスキーに自動的にアップグレードできます。
|
||
|
||
<video controls="" height="480" width="640"><source src="https://developer.chrome.com/static/blog/io26-web-identity/video/conditional-create.mp4?hl=ja" type="video/mp4"> 条件付き作成によるパスキー リクエスト フロー。</video>
|
||
|
||
条件付き作成によるパスキー リクエスト フロー。
|
||
|
||
パスワード マネージャーに保存されているパスワードを使用してユーザーが最近ログインに成功したときにトリガーされる `navigator.credentials.create()` API に `mediation: 'conditional'` を渡すことで、ブラウザは追加の設定画面を表示することなく、新しいパスキーをネイティブに生成します。
|
||
|
||
手間のかからない登録とは、ユーザーがセキュリティを強化するために意識的に判断する必要がないことを意味します。自動的に行われ、余分な手間をかけずに保護されます。たとえば、 [adidas はこのプロンプトなしの 戦略を使用して、パスキーの 作成数が 8% 増加しました。](https://web.dev/case-studies/adidas-passkeys?hl=ja)
|
||
|
||
```
|
||
await navigator.credentials.create({
|
||
mediation: 'conditional',
|
||
publicKey: { ... },
|
||
});
|
||
```
|
||
|
||
[パスキー登録 チェックリスト](https://web.dev/articles/passkey-checklist?hl=ja#passkeys_registration) をご覧ください。
|
||
|
||
## パスキーの管理と復元
|
||
|
||
ユーザーは、デバイス、ウェブサイト、サービス間で認証情報をすぐに利用できるようにすることが重要です。また、認証情報を管理し、デバイスの紛失や盗難が発生した場合にアカウントを復元できるようにする必要があります。
|
||
|
||
### クロスプラットフォームの一貫性
|
||
|
||
ログイン システムを共有する複数のプロパティ（Android アプリとウェブサイト、複数のウェブサイトなど）がある場合は、ユーザー エクスペリエンスを向上させることができます。 *シームレスな認証情報の共有により、パスワード マネージャーはすべてのプロパティで適切な認証情報をユーザーに提案できます。*
|
||
|
||
[シームレスな認証情報 共有](https://developers.google.com/identity/credential-sharing/set-up?hl=ja) は、パスワードの Digital Asset Links とパスキーの関連 オリジン リクエストの 2 つのテクノロジーで構成されています。
|
||
|
||
[Digital Asset Links](https://developers.google.com/identity/credential-sharing/set-up?hl=ja) を使用すると、ウェブで作成されたパスワードを Android アプリで使用できるようになります。また、パスワード マネージャーは、同じ認証バックエンドを共有する所有する別のドメインで、すでに保存されている認証情報を提案できます。
|
||
|
||
[関連オリジン リクエスト](https://web.dev/articles/webauthn-related-origin-requests?hl=ja) を使用して、ユーザーの 認証情報マネージャーを介して、さまざまなドメインやアプリで パスキーを利用できるようにします。
|
||
|
||
これは、ユーザーのログイン エクスペリエンスをスムーズにするもう 1 つの方法です。
|
||
|
||
### パスキー管理ページでユーザーを支援する
|
||
|
||
|
||
|
||
高度なパスキー エクスペリエンスを実現するには、専用の [パスキー管理ページ](https://web.dev/articles/passkey-management?hl=ja) を作成し、 プロバイダ名、使用時間、コントロールを明確にサポートすることをおすすめします。これにより、ユーザーは安心して設定を管理できます。透明性は信頼を築きます。
|
||
|
||
[パスキー管理 チェックリスト](https://web.dev/articles/passkey-checklist?hl=ja#passkeys_management) をご覧ください。
|
||
|
||
### 復元力のあるアカウント復元
|
||
|
||
デバイスが紛失したり、アップグレードされたりする可能性があります。パスキーはハードウェア レベルの保護を使用し、通常はクラウドに同期されるため、本質的に復元力があり、ユーザーは新しいデバイスで復元できます。ただし、確認済みのメールアドレスなどのフォールバックを用意しておくと、ユーザーはデジタル ライフにアクセスできなくなります。
|
||
|
||
ヘルプデスクへの電話を待つのではなく、ID 連携やメール確認など、すでに信頼しているシグナルを使用して、ユーザーが所有者であることを証明できます。
|
||
|
||
これらのシグナルを復元戦略に組み合わせることで、その場でアクセスを復元できます。復元したら、すぐに新しいパスキーを登録して、フィッシングから再び保護します。
|
||
|
||
## DBSC によるセッションの保護
|
||
|
||
アカウントの不正使用からユーザーを保護するには、セッション Cookie を安全に保つことも重要な防御策です。 [デバイスにバインドされたセッション認証情報 （DBSC）](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials?hl=ja) は、セッションをハードウェアにバインドする方法です。Cookie が盗まれても、同じデバイスのみが Cookie の再発行をリクエストできるため、セッション ハイジャックを軽減できます。これにより、セッションのセキュリティが強化されます。
|
||
|
||
DBSC は試験運用版の機能で、現在 Windows で利用できます。このアップデートについて詳しくは、 [Windows でのデバイスにバインドされたセッション認証情報 のお知らせ](https://developer.chrome.com/blog/dbsc-windows-announcement?hl=ja) をご覧ください。また、macOS への DBSC サポートの拡大にも取り組んでいます。
|
||
|
||
## パスキー エージェントのスキル
|
||
|
||
この記事で説明した多くの側面をカバーするパスキー スキルを、 弊社の [Modern Web Guidance プロジェクト](https://goo.gle/mwg) に含めました。パスキー スキルに関するブログ投稿を近日公開予定です。
|
||
|
||
## 認証の未来を築く準備はできましたか？
|
||
|
||
詳細ガイドをご覧になり、今すぐモダナイゼーションを開始しましょう。
|
||
|
||
- [パスキーのデプロイ チェックリスト](https://web.dev/articles/passkey-checklist?hl=ja)
|
||
- [Chrome デベロッパー - ID](https://developer.chrome.com/docs/identity?hl=ja)
|