---
url: 'https://www.corbado.com/ja/blog/webauthn-conditional-ui-passkeys-autofill'
title: 'WebAuthn Conditional UI（パスキーの自動入力）の技術解説'
description: 'Conditional UI / Conditional Mediation / パスキーの自動入力は、パスキーの新機能です。本記事では、その概要、仕組み、および実装方法について解説します。'
lang: 'ja'
author: 'Vincent Delitz'
date: '2026-07-03T07:10:04.807Z'
lastModified: '2026-07-03T07:11:02.921Z'
keywords: 'パスキーの自動入力, Conditional UI, Conditional Mediation, パスキー, WebAuthn'
category: 'WebAuthn Know-How'
---
# WebAuthn Conditional UI（パスキーの自動入力）の技術解説
## Key Facts
- Conditional UIには**Discoverable credentials（resident keys）**が必要です。オーセンティケーターはnon-resident keysのユーザー固有のデータを保存しないため、これらを使用すると自動入力が不可能になります。
- サポートされていないブラウザやデバイスでユーザーにエラーが表示されるのを防ぐため、Conditional UIフローを開始する前に**`isConditionalMediationAvailable()`**を呼び出す必要があります。
- HTML入力フィールドの**`autocomplete="username webauthn"`**トークンは、自動入力ドロップダウンでパスワードの提案と並んでパスキーを表示するようにブラウザに指示します。
- `navigator.credentials.get()` 呼び出しで**`mediation: "conditional"`**を設定すると、ブロックするモーダルダイアログでユーザーを妨げることなくパスキーの自動入力が有効になります。
- 自動入力ドロップダウンにはモーダルプロンプトとは異なり、組み込みのキャンセルボタンがないため、進行中のConditional UIリクエストをキャンセルするには**`AbortController`**が必要です。
## 1. はじめに
パスキー（および基盤となるWebAuthnプロトコル）の急速な普及により、認証は多くのユーザーにとってより安全で使いやすいものになりました。パスキーの顕著な進歩の1つは、多くの場合「パスキーの自動入力」またはConditional Mediationと呼ばれるConditional UIの統合です（以下ではConditional UIという用語を使用します）。
ブラウザへの導入や採用が進んでいるにもかかわらず、Conditional UIに関する技術文書や実装に関するアドバイスには明らかなギャップがあります。本記事は、Conditional UIの概要、仕組み、および実装中の一般的な課題への対処方法を解説することで、そのギャップを埋めることを目的としています。
## 2. Conditional UIとは？
Conditional UIは、パスキー / WebAuthnのログインプロセスにおける新しいモードです。ユーザーがデバイス（例：ラップトップ、スマートフォン）のオーセンティケーターに保存されているリライングパーティ（オンラインサービス）に登録されたdiscoverable credential（resident key、パスキーの一種）を持っている場合にのみ、ユーザーインターフェース（UI）にパスキーを選択的に表示します。パスキーは自動入力されたパスワードと混在する選択ドロップダウンに表示され、ユーザーは同じコンテキストで両方を見ることができるため、従来のパスワードシステムと高度なパスキー認証間のシームレスな移行を提供します。このインテリジェントなアプローチにより、ユーザーは不要なオプションに圧倒されることなく、よりスムーズにログインプロセスを進めることができます。
Conditional UIの基盤は、主に3つの柱の上に構築されています：
1. **ユーザープライバシーの尊重：** 利用可能なクレデンシャルの開示、またはこれらのクレデンシャルを明らかにするためのユーザーの同意の欠如を防ぐことにより、ユーザーのプライバシーを確保します。
2. **パスキーが存在しなくても優れたユーザーエクスペリエンス：** リライングパーティが日和見的にWebAuthnを実装できるようにし、パスキーが利用できない場合でもユーザーエクスペリエンスを良好に保ちます。
3. **パスワードからパスキーへのスムーズな移行：** パスキーとパスワードベースの認証を組み合わせて、ユーザーが慣れ親しんだUXパラダイムを活用し、パスワードレス認証方式への移行をスムーズにします。
## 3. Conditional UIのメリットとデメリット
### 3.1 メリット
- **認証の合理化：** プロセスはより合理化され、効率的になり、複数の認証方法に関連することが多い複雑さが排除されます。
- **ユーザーエラーの削減：** 関連するオプションのみを提示することで、ユーザーが認証プロセス中に間違いを犯す可能性が低くなります。
- **ユーザー満足度の向上：** 不要な手順が排除されることで、ユーザーはより迅速かつ簡単にログインでき、ユーザー満足度の向上につながります。
- **シンプルなフロントエンド統合：** Conditional UIの優れた機能の1つは、統合の容易さです。開発者は、数行のコードでフロントエンドにシームレスに組み込むことができます（後述）。
- **パスワードレスおよびユーザーネームレスログイン：** 大きな利点の1つは、Conditional UIがパスワードレス認証だけでなく、ユーザーネームレスまたはアカウントレスのエクスペリエンスも促進することです。ユーザーは、サインアップ時に特定のメールアドレスやユーザーハンドルを思い出す精神的負担から解放されます。代わりに、自動入力メニューで適切なパスキーとペアになったメールアドレス / ユーザーハンドルを含むブラウザの提案に頼ることができます。
- **ブートストラップのジレンマの解決：** 従来のユーザー名とパスワードのシステムからパスキーへの移行は困難な場合があります。Conditional UIは、この移行の課題に対処します。Webサイトは、デバイスに必要なクレデンシャルがない場合に発生する可能性のあるモーダルダイアログエラーを心配することなく、従来のパスワードプロンプトと一緒にパスキー / WebAuthnの呼び出しを開始できます。
### 3.2 デメリット
- **開発者向けの学習曲線：** Conditional UIは新しいパラダイムを導入するため、その複雑さに慣れていない開発者には学習曲線が伴います。
- **デバイス / ブラウザへの依存：** Conditional UIの成功は、ユーザーのデバイスまたはブラウザの互換性にかかっています。現在、すべてのブラウザやデバイスがサポートしているわけではないため、適用が制限される可能性があります。
- **パスワードマネージャーによるオートコンプリートの無効化：** 一部の最新のパスワードマネージャーとそれらのブラウザ拡張機能は、WebサイトのDOMを変更し、独自のオートコンプリート機能を優先して入力フィールドのautocompleteタグを無効にするか、上書きします。これにより、一貫性がなく不満の残るユーザーエクスペリエンスが発生する可能性があります。Conditional UIの標準は比較的新しいため、2つの自動入力メニューが重なったり、目的のメニューがまったく表示されなかったりしないように、状況が改善されることが期待されています。
## 4. Conditional UIの仕組み
以下では、Conditional UIフロー全体の各ステップを段階的に説明します。
一般に、Conditional UIのプロセスフローは2つのフェーズに分けることができます。ページ読み込みフェーズでは、Conditional UIロジックがバックグラウンドで実行されます。一方、ユーザー操作フェーズでは、ユーザーが能動的に何かを行う必要があります。
1. **Conditional UIの可用性チェック：** クライアント（ブラウザ）は、現在のデバイス / ブラウザの組み合わせがConditional UIをサポートしているかを検出するために、`isConditionalMediationAvailable()`関数を呼び出します。応答がtrueの場合のみプロセスが続行され、それ以外の場合はConditional UIプロセスが中止されます。
2. **Conditional UIエンドポイントの呼び出し：** 次に、クライアントはPublicKeyCredentialRequestOptionsを取得するために、サーバーのConditional UIエンドポイントを呼び出します。
3. **PublicKeyCredentialRequestOptionsの受信：** サーバーは、チャレンジやその他のWebAuthnサーバーオプション（allowCredentials、extensions、userVerificationなど）を含むPublicKeyCredentialRequestOptionsを返します。
4. **ローカル認証の開始：** 受信したPublicKeyCredentialRequestOptionsと、`mediation`プロパティをconditionalに設定して`credentials.get()`を呼び出すことで、デバイス上のローカル認証のプロセスが開始されます。
5. **自動入力の選択の表示：** パスキーの自動入力メニューがポップアップ表示されます。具体的なスタイルはブラウザとデバイスによって異なります（例：一部のブラウザではユーザーが入力フィールドにカーソルを置く必要があり、一部のブラウザではページ読み込み時に自動的にメニューが表示されます。後述）。
6. **ローカルユーザー認証：** ユーザーは自動入力メニューから使用したいパスキーを選択し、デバイスの認証ダイアログ（Face ID、Touch ID、Windows Helloなど）を介して認証します。
7. **オーセンティケーターの応答をサーバーに送信：** ローカルユーザー認証が成功した場合、オーセンティケーターの応答はサーバーに送り返されます。
8. **ユーザーのログインとリダイレクト：** サーバーはオーセンティケーターの応答を受信すると、データベース内の対応するユーザーアカウントの公開鍵に対して署名を検証します。検証に成功すると、ユーザーはアクセスを許可され、ログインし、ログイン済みのページにリダイレクトされます。
このプロセスフローに従うことで、Conditional UIはシームレスでユーザーフレンドリーな認証エクスペリエンスを提供します。
## 5. Conditional UIの技術的要件
### 5.1 一般事項
Conditional UIを機能させるには、いくつかの一般的な側面を考慮する必要があります：
- **クレデンシャルの仕様：** Conditional UIは、resident keys / discoverable credentialsでのみ動作するように特別に設計されています。その理由は、オーセンティケーターはnon-resident keys / non-discoverable credentialsのユーザー固有のデータ（名前、表示名など）を保存しないためです。その結果、これらをパスキーの自動入力に使用することはできません。
- **クレデンシャルのフィルタリング：** [allowCredentials](https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialrequestoptions-allowcredentials)機能は引き続きサポートされており、ユーザーのIDをすでに認識しているWebサイト（たとえば、ブラウザのLocalStorageに保存されている可能性があるため、最初のmediation呼び出しでユーザー名が送信された場合など）が、自動入力中にユーザーに表示されるクレデンシャルのリストを絞り込むことができます。
### 5.2 クライアント側
クライアント側でConditional UIを機能させるには、以下の要件を満たす必要があります：
- **互換性のあるブラウザ：** ユーザーがConditional UIをサポートする最新のブラウザを使用していることを確認します（最新のブラウザの対応状況については[こちら](https://caniuse.com/mdn-api_publickeycredential_isconditionalmediationavailable_static)を参照してください）。
- **JavaScriptの有効化：** Conditional UIの操作を容易にするために、JavaScriptを有効にする必要があります。
- **Conditional UIの可用性のテスト：** リライングパーティ（サーバー側）は、WebAuthnのmediation呼び出しを受信したときにクライアント側でConditional UIが利用可能であることを確信し、Conditional UIがサポートされていないシナリオでユーザーに表示されるエラーを引き起こさないようにする必要があります。これに対処するには、`isConditionalMediationAvailable()`メソッドを使用して、Conditional UIの技術的な可用性を確認することをお勧めします（詳細については[後述](#browser-compatibility-check)）。
- **HTML入力フィールドの要件：** Conditional UIを機能させるには、WebページにHTML入力フィールドが必要です。フィールドがない場合は、ボタンのクリックなど、ユーザーの操作によってトリガーされる通常のパスキー / WebAuthnのログインプロセスのサポートを提供する必要があります。
- **タイムアウトプロトコルの削除：** タイムアウトパラメーター（例：ユーザーが自動入力メニューでパスキーを決定するのに非常に長い時間がかかっている）は、この設定では無視する必要があります。
### 5.3 サーバー側
Conditional UIを機能させるには、サーバー側でもいくつかの要件を満たす必要があります：
- **稼働中のWebAuthnサーバー：** まだパスキー / WebAuthnのコンテキストにいるため、認証手順を管理するWebAuthnサーバーが稼働している必要があります。
- **Mediationの開始エンドポイントの提供：** 通常のWebAuthnのログインエンドポイントと比較して、同様の機能を持ちながら、オプションのユーザーハンドル（メールアドレス、電話番号、ユーザー名など）を処理できる別のエンドポイントを提供すると便利です。
## 6. 実践的なコーディングのヒント
2022年後半のConditional UIの正式なロールアウトとそれ以前のベータ版以降、私たちはこれをテストし、広範に作業してきました。以下では、Conditional UIの実装時に役立った実践的なヒントを共有したいと思います。
### 6.1 Conditional UIの完全な例
Conditional UIメソッドの完全で最小限のコード例は次のようになります：
```html
Conditional UI
```
### 6.2 ブラウザの互換性チェック
現在のデバイス / ブラウザの組み合わせがサポートしている場合にのみConditional UIが使用されるように、Conditional UIの検出を実装します。これは、Conditional UIがサポートされていない場合にユーザーにエラーを表示することなく機能する必要があります。ユーザーインターフェース内に`isConditionalMediationAvailable()`メソッドを組み込むことで、この懸念に対処できます。Conditional UIのサポートが確認されたら、Conditional UIのログインプロセスを開始できます。
```javascript
// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
// `window.PublicKeyCredential`の可用性は、WebAuthnが使用可能であることを意味します。
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
// conditional mediationが利用可能か確認します。
const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
if (isCMA) {
// WebAuthnの認証開始エンドポイントを呼び出します
let options = await WebAuthnClient.getPublicKeyRequestOptions();
const credential = await navigator.credentials.get({
publicKey: options.publicKeyCredentialRequestOptions,
mediation: "conditional",
});
/*
...
*/
}
}
```
### 6.3 入力フィールドのWebAuthn Autocompleteトークン
入力フィールドは、webauthnのHTML自動入力トークンを受け取る必要があります。これにより、進行中のリクエストにパスキーを入力するようにクライアントに合図します。パスキー以外にも、他の自動入力値が表示される場合があります。これらの自動入力トークンは、既存の他のトークンと組み合わせることができます（例：
- `autocomplete="username webauthn"`: パスキーの表示に加えて、ユーザー名の自動入力も提案します。
- `autocomplete="current-password webauthn"`: パスキーの表示に加えて、さらにパスワードの自動入力を促します。
```html
```
詳細については、パスキーとパスワードの自動入力 / オートコンプリートトークンの詳細を説明しているブログ記事を読むことをお勧めします。
### 6.4 WebAuthn APIのGet呼び出しにおけるMediationプロパティ
PublicKeyCredentialRequestOptionsオブジェクトを受信した後に利用可能なパスキーを取得するには、`navigator.credentials.get()`関数を呼び出す必要があります（これはパスキーとパスワードの両方を提供します）。クライアントでConditional UIを有効にするには、PublicKeyCredentialRequestOptionsオブジェクトのmediationパラメーターをconditionalに設定する必要があります。代わりにモーダルのパスキープロンプトが必要な場合は、immediate mediationを参照してください。
```javascript
const credential = await navigator.credentials.get({
publicKey: options.publicKeyCredentialRequestOptions,
mediation: "conditional",
});
```
### 6.5 Conditional UIフローのキャンセル
利用可能なパスキーがない場合、またはユーザーが提案されたパスキーを無視してメールアドレスを入力した場合、Conditional UIフローは停止します。これは、常にモーダルを介した標準のパスキー / WebAuthnのログインもサポートすることの重要性を強調しています。
ここで強調すべき重要な点は、進行中のConditional UIリクエストを停止する必要がある可能性があることです。モーダルのエクスペリエンスとは対照的に、自動入力ドロップダウンにはキャンセルボタンがありません。WebAuthnの設計に従い、常に[単一のアクティブなクレデンシャルリクエスト](https://github.com/w3c/webappsec-credential-management/issues/206)のみが進行中でなければなりません。WebAuthnの標準では、WebAuthnプロセスをキャンセルするために[AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController)を利用することを提案しており、これは通常のログインプロセスとConditional UIのログインプロセスの両方に適用できます（詳細については[こちら](https://w3c.github.io/webauthn/#sctn-sample-aborting)を参照してください）。
本番環境のテレメトリでは、このキャンセルパスは多くの場合、予期される制御フローの結果であり、システムの障害ではありません。大量のエラーが発生した場合は、回帰として扱う前に、操作タイプとタイミングによって予期されるケースと予期されないケースを分類する必要があります（WebAuthnエラーを参照）。
ユーザーがページにアクセスするとすぐに、Conditional UIのログインプロセスがアクティブになります。最初のタスクは、グローバルスコープの`AbortController`オブジェクトを作成することです。これは、特にユーザーが通常のパスキーのログインプロセスを実行することを選択した場合に、自動入力リクエストを終了するためのクライアントへのシグナルとして機能します。
`AbortController`が他の関数から呼び出し可能であり、Conditional UIプロセスを再起動する必要がある場合はリセットされることを確認してください。`navigator.credentials.get()`呼び出し内のsignalプロパティを使用し、値として`AbortController`のシグナルを組み込みます。これは、シグナルが中止された場合にリクエストを停止する必要があることをパスキー / WebAuthn関数に合図します。Conditional UIをトリガーするたびに、新しい`AbortController`を設定することを忘れないでください。すでに中止された`AbortController`を使用すると、パスキー / WebAuthn関数が即座にキャンセルされます。残りの手順は、通常のパスキーのログインプロセスと同じです。以下に、説明した手順のコード例を示します：
```html
Conditional UI
```
Conditional UIがサポートされていない場合は、ユーザーを通常のパスキーログインプロセスに誘導します。このパスを提供することは、ハードウェアセキュリティキー（YubiKeyなど）に依存しているユーザーや、オーセンティケーターの制約によりnon-resident keys / non-discoverable credentialsを使用せざるを得ないユーザーにとって重要です。
### 6.6 ネイティブアプリでのConditional UI
iOSやAndroidなどのネイティブアプリを開発する場合、Conditional UIも機能します。Flutter、Kotlin、Swiftでネイティブに実装するか、Chrome Custom Tabs（CCT）、SFSafariViewController、SFAuthenticationSession / ASWebAuthenticationSessionのいずれを使用するかは関係ありません。どちらのアプローチもConditional UIをサポートしています。
#### 6.6.1 iOSアプリでのConditional UI
一般的に、iOSアプリにConditional UIサポートを実装する方法に関するドキュメントはほとんど見つかりませんでした。しかし、私たちの調査の過程で、iOSアプリにConditional UIサポートを追加する2つの方法を発見しました。ユーザーエクスペリエンスも異なります。
**タイプA： 画面のほぼ全体を覆うオーバーレイ / ポップアップ**
最初のタイプAは、画面のほぼ全体に広がるオーバーレイ / ポップアップを表示します。ここでは、このリライングパーティで利用可能なすべてのパスキーが表示されます。この方法でConditional UIを実装している著名な例はKAYAKです。ユーザーが適切な画面を開くと、オーバーレイ / ポップアップが自動的に表示されます。
**タイプB： キーボードの自動入力**
2番目のタイプBは、キーボードの自動入力セクション（パスワードの自動入力も提案される場所）に適切なパスキーを表示します。提案された値をクリックするとFace ID認証が実行され、ログインできます。Corbadoの開発者パネルの現在のiOSアプリバージョンでは、このように実装しています（WebAuthnのユーザー名と共に、「``のパスキーでサインイン」のメッセージを参照してください）。表示するには、ユーザーが入力フィールドをタップする必要があります：
キーボードセクションのこのパスキー自動入力機能は、iOSが新規インストールされた場合に問題が発生する可能性があります。背景では、このリライングパーティのすべての利用可能なパスキーを検索する一種のキャッシングが行われているようです。
提案されたパスキーの右側にある鍵のアイコンをクリックすると、iOSでパスワード / パスキーを選択するための既知のサイトに移動します：
公式のドキュメントは見つかっておらず、私たちの洞察は適切な実装の具体的な証拠ではなく、私たちの経験と仮説に基づいていることに注意してください。
#### 6.6.2 AndroidアプリでのConditional UI
Androidでは、Android Credential Manager APIを活用するConditional UI / パスキー自動入力のタイプが1つしかないため、Conditional UIについての話は少し明確です（ドキュメントは[こちら](https://developer.android.com/training/sign-in/passkeys)を参照してください）。Androidプロバイダーは異なる場合があるため、Credential Managerのパスキーエラーは、ブラウザのみのWebAuthnの障害パターンとは別に監視してください。
Conditional UIが実装されているページを開くと次の画面が表示され、サインインするためのさまざまな方法を見つけることができます：
**「保存した他のサインイン情報」**をクリックすると、サインインに選択できるその他のオプションが提供されます（これには、クロスデバイス認証や、Samsung Passや1Passwordなどの異なるパスキー同期プラットフォームの選択が含まれます）：
## 7. さまざまなデバイス / ブラウザでのConditional UIの例
エンドユーザーに対してConditional UIがどのように見えるかを説明するために、[https://passkeys.eu](https://passkeys.eu)を使用したConditional UIの自動入力メニューのスクリーンショットをいくつか追加しました。
### 7.1 Windows 11（22H2）+ Chrome 118でのConditional UI
### 7.2 macOS Ventura（13.5.1）+ Chrome 118でのConditional UI
### 7.3 macOS Ventura（13.5.1）+ Safari 16.6でのConditional UI
### 7.4 Android 13 + Chrome 118でのConditional UI
### 7.5 iOS 17.1 + Safari 17.1でのConditional UI
## 8. エッジケースにおけるConditional UI
実際のアプリケーションにおけるいくつかの一般的なシナリオを見てみましょう。
### 8.1 パスキーが利用できない場合のConditional UI
サイトにパスキーが保存されていない場合、Conditional UIはブラウザやOSによって異なる動作をします。
#### 8.1.1 macOSのChromeにおけるパスキーなしのConditional UI
**macOSのChrome**では、入力フィールドをクリックすると空の自動入力ドロップダウンが表示されます：
#### 8.1.2 macOSのSafariにおけるパスキーなしのConditional UI
**macOSのSafari**では、ドロップダウンは表示されず、入力フィールドに控えめなアイコンのみが表示されます：
#### 8.1.3 AndroidまたはiOSにおけるパスキーなしのConditional UI
**AndroidまたはiOS**では、ユーザーがフィールドをタップし、OSが一致するクレデンシャルを見つけた場合にのみ自動入力インターフェースが表示されます。
このばらつきは意図的なものであり、WebAuthnのプライバシーモデルの一部です。ユーザーが能動的にパスキーを選択しない限り、Webサイトはユーザーがパスキーを持っているかどうかを検出できません。
### 8.2 Conditional UIと複数のクレデンシャルマネージャー / パスキープロバイダー
ユーザーが複数のパスキープロバイダー（iCloudキーチェーン、Googleパスワードマネージャー、1Passwordなど）をインストールしている場合、ブラウザまたはOSは通常、ユーザーのメインのクレデンシャルマネージャーをデフォルトとします。
パスキーをサポートするさまざまなパスキープロバイダー / クレデンシャルマネージャーのリストについては、以下の[GitHubリンク](https://passkeydeveloper.github.io/passkey-authenticator-aaguids/explorer/)を参照することをお勧めします。
#### 8.2.1 AndroidにおけるConditional UIと複数のクレデンシャルマネージャー
Androidでは、Credential ManagerがSamsung Passや1Passwordなどの異なるプロバイダーを公開します。
1. ユーザー識別子の入力フィールドをクリックすると、このメニューが表示され、ユーザーはパスキーを選択できます。
2. 前の画面で「他のパスキー」をクリックした場合、他のパスキープロバイダー / クレデンシャルマネージャーおよびパスキーの事前選択が表示されます：
3. 前の画面で「保存した他のサインイン情報」をクリックした場合、ユーザーがパスキーを選択できる利用可能な一覧全体が表示されます。
#### 8.2.2 iOSにおけるConditional UIと複数のクレデンシャルマネージャー
iOSでは、鍵のアイコンからさまざまなソースのパスキーの完全なリストが開きます。
1. 最初、iOS 18以降では、デフォルトのパスキープロバイダーによる通常のConditional UIが表示されます。
2. キーボードアイコンをクリックすると、次の選択メニューが表示されます。
3. クレデンシャルマネージャー / パスキープロバイダーを選択した後、ユーザーは使用するパスキーを選択できます。
> アプリやWebサイトとして、どのクレデンシャルマネージャーを使用するかを制御することはできません。OSがユーザーのプライバシーを保護するためにその選択を管理します。
## 9. 結論
Conditional UI / パスキーの自動入力機能を備えたパスキーは、オンラインで認証する新しい方法です。パスワードがますますパスキーに置き換えられる時代に移行するにつれて、堅牢でユーザーフレンドリーな移行メカニズムの必要性は否定できません。本記事は、移行プロセスで非常に役立つConditional UIを正しく実装する方法や、特に注意すべき側面を理解するのに役立ちます。
## よくある質問
### パスキーの自動入力フローを開始する前に、ブラウザがConditional UIをサポートしているか確認するにはどうすればよいですか？
`PublicKeyCredential.isConditionalMediationAvailable()` を呼び出し、trueが返された場合のみ処理を進めます。この確認により、サポートされていないブラウザやデバイスの組み合わせでユーザーにエラーが表示されるのを防ぎます。このメソッドは、`mediation: "conditional"` を指定して `navigator.credentials.get()` を呼び出す前の各ページ読み込み時に評価する必要があります。
### なぜConditional UIはすべてのパスキーではなく、discoverable credentialsでのみ機能するのですか？
オーセンティケーターは、resident keys（discoverable credentials）に対してのみ名前や表示名などのユーザー固有のデータを保存します。non-resident keysはこの情報を保持しないため、自動入力メニューにユーザーが選択するためのアカウント詳細を表示することができません。
### ユーザーがサイトにパスキーを登録していない場合、Conditional UIではどうなりますか？
プラットフォームによって動作が異なります。macOSのChromeでは空の自動入力ドロップダウンが表示され、macOSのSafariでは入力フィールドに控えめなアイコンのみが表示されます。AndroidやiOSでは、ユーザーがフィールドをタップした後にOSが一致するクレデンシャルを見つけた場合にのみ自動入力インターフェースが表示されます。このばらつきは意図的なものであり、WebAuthnのプライバシーモデルの一部です。ユーザーが能動的にパスキーを選択しない限り、Webサイトはパスキーが存在するかどうかを検出できません。
### ユーザーがモーダルでのパスキーログインに切り替えたときに、進行中のConditional UIリクエストをキャンセルするにはどうすればよいですか？
グローバルスコープの `AbortController` を作成し、そのシグナルを `navigator.credentials.get()` に渡します。ユーザーがモーダルログインフローを開始したときに、コントローラーで `.abort()` を呼び出します。すでに中止されたコントローラーを再利用するとWebAuthnリクエストが即座にキャンセルされてしまうため、Conditional UIが再開するたびに常に新しい `AbortController` をインスタンス化してください。
### Conditional UIはネイティブのiOSおよびAndroidアプリで機能しますか、それともWebブラウザのみですか？
Conditional UIはネイティブのiOSおよびAndroidアプリの両方で機能します。iOSは、フルスクリーンのオーバーレイポップアップとキーボードの自動入力提案の2つのバリアントをサポートしています。AndroidはCredential Manager APIを使用し、Samsung Passや1Passwordなどの複数のプロバイダーからのパスキーを表示できます。