---
url: 'https://www.corbado.com/ja/blog/passkeys-brave-browser'
title: 'Braveブラウザのパスキー（2026年）：何が機能し、何が壊れるのか'
description: 'Braveはパスキーの動作において主にChromiumに追随していますが、Android環境やWindows Hello、およびパスワードマネージャーとの競合による問題は依然として存在します。'
lang: 'ja'
author: 'Vincent Delitz'
date: '2026-07-03T07:07:34.315Z'
lastModified: '2026-07-03T07:08:26.630Z'
keywords: 'Brave パスキー, WebAuthn, Braveブラウザ, Android クレデンシャルマネージャー, Windows Hello, パスワードマネージャー'
category: 'WebAuthn Know-How'
---

# Braveブラウザのパスキー（2026年）：何が機能し、何が壊れるのか

## Key Facts

- **WebAuthnのコードパスはChromiumのままで、ほぼ手つかずです。** `brave/brave-core`リポジトリには、目に見えるWebAuthn関連のカスタマイズが**1つ**だけ含まれています。それは、パスキー保存ダイアログのChromeの「Incognito」ラベルを「Private」に変更する文字列の上書きです。WebAuthnのコードパスに触れるC++のパッチはありません。
- **24件の未解決のパスキー/WebAuthn問題**が2026年4月時点で`brave/brave-browser`に存在していました（GitHubでの`passkey`と`WebAuthn`の検索による）。パスキーのタグが付けられた未解決の課題は、2022〜2023年の年約2件から、2025年には6件に増加しました。
- **macOSのクロスブラウザ利用は機能します。** macOSで作成されたパスキーはiCloudキーチェーンに保存でき、同じApple IDを共有するデバイス上のSafari、Chrome、およびその他のAppleプラットフォームのブラウザで使用可能です。
- **Androidの脱Googleビルドは壊れます。** Google Play開発者サービスがない場合、Androidではパスキーの登録と認証が頻繁に失敗します。課題#45415（2025年4月から未解決）で追跡されています。
- **Windows Helloは完全には抑制できません。** `brave://password-manager/settings`を無効にしても、WindowsがWebAuthnプラットフォームオーセンティケーターとしてHelloを提供するのを止めることはできません。課題#51858（2026年1月作成）で追跡されています。
- **拡張機能のインターセプトは最も活発なリグレッションです。** ネイティブのパスキーUIがBitwardenや1Passwordのプロンプトを上書きする課題#37762は、2024年4月に作成され、2026年3月25日時点でもバグレポートが寄せられています。
- **`web-authentication-new-passkey-ui`フラグの回避策は**、バージョン146（Chromium 146）ではなくなりました（2026年3月25日付の`brave/brave-browser`課題#37762のユーザーレポートによる）。

## 1. はじめに：今日のBraveにおけるパスキーサポート

Braveのパスキーサポートは、コードレベルではChromiumに近いですが、ユーザーエクスペリエンスはいくつか重要な箇所で異なります。2026年4月現在、より広範な`brave/brave-browser`リポジトリには依然として`passkey`または`WebAuthn`に一致する24件の未解決の課題がありましたが、[`brave/brave-core`](https://github.com/brave/brave-core)には、目に見えるWebAuthn固有のカスタマイズが1つだけ示されていました。主な問題点は、拡張機能のインターセプト、Windows Helloプロンプト、および脱GoogleデバイスでのAndroidフローです。

Braveは、上流のChromiumと同じWebAuthnコードパスを通じてパスキーを提供し、認証情報の保存をオペレーティングシステムに委任しています。このアーキテクチャにより、Braveは机上では標準的に見えますが、実際の動作はパスワードマネージャーの拡張機能、Windows Hello、Google Play開発者サービスなどの周囲のシステムに依存しています。以下のセクションでは、プラットフォーム固有の動作をそれぞれ単独で理解できるように、それらの障害モードを分けて説明します。

## 2. BraveのWebAuthnスタックはChromiumのものとどう違いますか？

BraveのWebAuthn実装は、UIテキストの変更が1つだけ見える事実上のChromiumの実装です。[`brave/brave-core`](https://github.com/brave/brave-core)リポジトリには、WebAuthn関連のカスタマイズが1つだけ含まれており（保存ダイアログの「Incognito」を「Private」に変更する文字列の上書き）、WebAuthnのコアロジックに触れるC++パッチはありません。つまり、BraveはGoogleが2023年6月のChromium 115以降に提供したChromiumのパスキースタックを継承しています。

これが重要な理由は2つあります。第1に、通常の上流マージにより、WebAuthnの修正と機能追加は、Braveが深く分岐したパスキー実装を維持することなく、一般的に到着します。[`brave/brave-core`](https://github.com/brave/brave-core/blob/master/components/webauthn_strings_override.grdp)で、唯一の文字列上書きを直接調べることができます。AAGUIDマッピングでは、Chromiumブラウザのオーセンティケーターパスは通常`b5397666-4885-aa6b-cebf-e52262a439a2`として識別され、参照リストでは「Chromium Browser」というラベルが付いています。第2に、報告された失敗のほとんど（拡張機能のインターセプト、自動入力の競合、AndroidのGoogle Play開発者サービスへの依存）は、自動入力、権限、Shields、またはウォレット統合などの隣接するシステムで発生します。これらはWebAuthnフローを置き換えるのではなく、それを取り囲んでいます。

## 3. macOSで作成したパスキーは、別のAppleデバイスのSafariで使用できますか？

はい、ただしパスキーがiCloudキーチェーンに保存されている場合のみです。macOSでは、BraveはChromiumのWebAuthnスタックを使用し、新しいパスキーをAppleプラットフォームのオーセンティケーターか、作成プロンプトに表示される別のストレージターゲットに保存できます。iCloudキーチェーンに保存されたパスキーは、Apple IDを通じて同期され、そのApple IDを共有するAppleデバイス上のSafari、Chrome、およびその他のWebAuthn対応ブラウザで利用可能になります。

macOSが、BraveがiCloudキーチェーンにアクセスすることを許可されていると確認すると、ブラウザはSafariが認識するのと同じ同期されたパスキーを使用できます。その権限のプロンプトは、Appleデバイスでのクロスブラウザのポータビリティが理論的なものではなく、現実のものになる実践的な瞬間です。

![macOSがBraveブラウザにiCloudキーチェーンに保存されたパスキーへのアクセスを許可するかどうかを尋ねています。これにより、同じApple IDを共有するAppleデバイスのSafari、Chrome、およびBraveで、同じ同期された認証情報が機能するようになります。](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/access_icloud_8252555e93.png)

macOS上のBraveは、クロスデバイス認証フローにも参加できます。ユーザーがBluetoothへのアクセスを許可すると、BraveはCDA中に近くのデバイスを検出して通信できるようになり、デスクトップブラウザからのスマートフォンベースのパスキー承認がほぼシームレスに感じられます。

![macOS上のBraveがクロスデバイス認証の前にBluetoothアクセスを要求し、近くのデバイスの検出とスムーズなスマートフォンベースのパスキー承認フローを可能にしています。](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/bluetooth_brave_macos_c51dd36600.png)

ブラウザプロファイルのストアまたはローカル専用ストアに保存されたパスキーは、別のAppleデバイス上のSafariで自動的に利用可能にはなりません。OSレベルのプラットフォームオーセンティケーターの同期とブラウザプロファイルの同期は異なるルールに従うため、その違いは重要です。BraveはChromeのGoogleパスワードマネージャーのパスキー同期を提供していないため、iCloudキーチェーンのパスのみがAppleデバイスでのAppleスタイルのクロスブラウザのポータビリティを提供します。

## 4. なぜGoogle Play開発者サービスなしのAndroidではパスキーが確実に機能しないのですか？

Androidのクレデンシャルマネージャー自体はGoogle Play開発者サービスの一部ではありません。Android 14以降では、Chromiumはシステムのクレデンシャルマネージャーのパスを使用できますが、古いバージョンのAndroidはGoogle Play開発者サービスが提供するFIDO2レイヤーにより大きく依存しています。実際には、Braveは依然として課題#45415に文書化されている失敗を継承しています。必要なPlay開発者サービスのパスがないGrapheneOS、CalyxOS、/e/OS、およびその他の脱Google化されたAndroidビルドでは、パスキーの登録と認証がタイムアウトする可能性があります。2026年4月の時点で、これはプライバシーを重視するAndroidユーザーにとって未解決の互換性のギャップとして残っていました。

この動作は、2025年4月に作成され、1年後も開かれたままの[`brave/brave-browser`の課題#45415](https://github.com/brave/brave-browser/issues/45415)に文書化されています。Googleの[クレデンシャルマネージャーのドキュメント](https://developer.android.com/training/sign-in/passkeys)は、クレデンシャルマネージャーAPIと、古いバージョンのAndroidで使用されるオプションのPlay開発者サービスの認証依存関係を区別しており、より広範なAndroidガイドでは、Android 14以降が有効なパスワードマネージャーと連携できると記されています。このスレッドはまた、同じ障害モードがより広範にChromiumベースのブラウザに影響を与える一方で、Firefoxベースのブラウザは同じようには影響を受けないことも指摘しています。最初の報告者は、GrapheneOSが独自のChromiumフォークである[Vanadium](https://github.com/GrapheneOS/Vanadium)で依存関係にパッチを当てたことを指摘したため、下流の修正は技術的に可能であるように見えます。ただ行われていないだけです。

複数のユーザーがそのスレッドで動作を独自に確認しました。2025年12月の特に明確なテストでは、同じデバイスを2つのプロファイルで使用しました。BraveでのパスキーはPlay開発者サービスが有効なプロファイルでのみ機能しましたが、VanadiumとCromiteは両方で機能しました。2026年4月の時点で、Braveのメンテナーはそのスレッドで回答していませんでした。不釣り合いな数の脱Googleユーザーを含む、Braveのプライバシーを重視するAndroidのオーディエンスにとって、これは非常に目立つギャップを残します。Android上のFirefoxは独自のWebAuthnスタックを使用しており、同じようにPlay開発者サービスに依存していません。今日の実用的な回避策は、Play開発者サービスのないAndroidでのパスキーフローにFirefoxを使用するか、互換性のあるクライアントを備えたハードウェアセキュリティキーにフォールバックすることです。Androidのより広範な障害の状況については、ネイティブアプリのパスキーエラーを参照してください。Google Play開発者サービスとクレデンシャルマネージャーの詳細については、AndroidおよびGoogle Play開発者サービスのパスキーエラーコードを参照してください。

## 5. パスキーのオプションを無効にしても、Windows Helloのプロンプトが表示されるのはなぜですか？

Braveの「パスキーの保存を提案する」設定を無効にしても、WebAuthnフロー中にWindows Helloが表示されるのを止めることはできません。サイトがWebAuthnを呼び出し、Windows Helloが登録されていると、WindowsはHelloをプラットフォームオーセンティケーターとして宣伝し、Braveはそれをブロックするユーザー向けのコントロールを公開しません。2026年1月現在、デバイスのロック解除にはHelloが必要だがパスキーには必要ないというユーザーにとって、Windows Helloの抑制は未解決のままでした。

2026年1月に作成された[課題#51858](https://github.com/brave/brave-browser/issues/51858)と、より長い[コミュニティのスレッド646042](https://community.brave.app/t/brave-prompts-for-windows-hello-passkeys-even-when-disabled/646042)は、同じことを説明しています。最初の報告者はレジストリの編集、グループポリシー、フラグの切り替え、クリーンインストールを試みましたが、動作は変わりませんでした。

スレッド646042で説明されている技術的な理由は単純です。ブラウザのパスワードマネージャーの設定は、ページとOSの間のWebAuthn境界ではなく、ブラウザ自身の自動入力動作を制御します。WindowsはHelloを独立して公開しており、デバイスのロック解除のためにWindows Helloを維持しつつ、WebAuthnプラットフォームオーセンティケーターとして完全にブロックするような文書化されサポートされた構成は、議論では特定されていません。

現在、これらのプロンプトを確実に抑制する唯一の方法は、Windows Helloの登録を完全に無効にすることですが、これは明らかにほとんどの人がデバイスのロックを解除したい方法と衝突します。Edgeの動作が異なるのは、Windowsのクレデンシャル管理レイヤーとより緊密に統合されており、現在Chromiumフォークが公開していないコントロールを公開しているためです。Windowsのパスキー動作の全体像については、Windows 11でのパスキーを参照してください。

## 6. パスキーはネイティブに保存すべきですか、それともパスワードマネージャーに保存すべきですか？

ネイティブのパスキー保存は単一のシステム内で最もシンプルなオプションですが、パスワードマネージャーの拡張機能は依然として広く機能する唯一のクロスプラットフォーム同期レイヤーです。iCloudキーチェーンはAppleデバイス間で適切に機能し、Windows HelloはWindowsで機能し、1PasswordやBitwardenなどの拡張機能ベースのボルトは、Windows、macOS、Linux、Android間でパスキーをネイティブに利用できるようにしたいユーザーにとって、依然として唯一の現実的なオプションです。クロスデバイス認証（CDA、またはQRコードとBluetoothを介したハイブリッドトランスポート）は、サインイン時にデバイスを橋渡しすることはできますが、認証情報自体を同期したり、デフォルトでどこでもローカルに利用できるようにしたりはしません。トレードオフは信頼性です。ネイティブのフローはよりシンプルで、拡張機能のフローはよりポータブルであり、CDAは保存戦略というよりはフォールバックのパスとして理解するのが最善です。

この決定は主に、いくつのプラットフォームを使用しているか、拡張機能のフローをどの程度信頼しているか、そして現在どこに認証情報を保管しているかの3つの要素にかかっています。主に1つのOSエコシステム（すべてApple、またはすべてWindows）内にとどまる場合は、ネイティブのプラットフォームオーセンティケーターのルートが最もクリーンなオプションです。その構成では、BraveはChromeやSafariとほぼ同じように動作します。パスキーをWindows、macOS、Linux、Android間で一貫して使用する必要がある場合は、1Password、Bitwarden、Dashlane、Proton Passなどのサードパーティのパスワードマネージャー拡張機能が、依然として唯一の広く機能する同期レイヤーです。

複雑なのは、2024年4月以降、ネイティブのパスキーUIが拡張機能主導のフローを断続的にハイジャックするという報告が寄せられ続けていることです。[課題#37762](https://github.com/brave/brave-browser/issues/37762)のユーザーは、Bitwardenや1Passwordが認証情報を所有しているはずなのに、OSの認証ダイアログが表示されると説明しています。2026年3月までに、`brave://flags/#web-authentication-new-passkey-ui`を無効にするという古い回避策は、バージョン146でフラグが削除されたため利用できなくなりました。

| 保存場所 | クロスOS同期 | クロスブラウザ利用 | リカバリの姿勢 | 既知のリスク |
| ----------------------- | ---------------------- | ------------------------- | ------------------- | ---------------------------------- |
| iCloudキーチェーン | Appleのみ | Appleブラウザ | Apple ID | なし |
| Windows Hello | いいえ（デバイスにバインド） | 同じWindowsデバイス | デバイスのロック解除 / PIN | Helloダイアログは無効化できない |
| Googleパスワードマネージャー | GPMが利用可能な場所 | Chrome + Androidの領域 | Googleアカウント | ここではBraveプロファイルに公開されない |
| 1Password / Bitwarden | 完全 | 完全（拡張機能） | ボルトのアカウント | 断続的なネイティブインターセプト |
| ハードウェアセキュリティキー | デバイスにバインド | 任意のブラウザ | 物理的な所持 | なし |

実際に、2026年にプライバシーを重視する多くのユーザーが行き着くパターンはハイブリッドなものです。1つのエコシステム内での毎日のサインインにはOSプラットフォームオーセンティケーターを使用し、クロスプラットフォームのポータビリティが重要な場合はパスワードマネージャー拡張機能を使用し、価値の高いアカウントにはハードウェアセキュリティキーを手元に置いておきます。

## 7. 2026年にユーザーが報告しているパスキーのペインポイントは何ですか？

2026年におけるBraveのパスキーの未解決の課題は、拡張機能のインターセプト、脱GoogleデバイスでのAndroidの障害、およびデスクトップのセキュリティキーの問題という3つの繰り返し発生するテーマに集中しています。2026年4月時点で、より広範なリポジトリには`webauthn`や`passkey`に一致する24件の未解決の課題が依然として存在しており、これは摩擦がランダムではなく集中していることを示唆しています。

最も活発なクラスターは拡張機能のインターセプトであり、ネイティブのパスキーUIが1Password、Bitwarden、またはDashlaneのプロンプトを上書きする可能性があります。Google Play開発者サービスがない場合のAndroidの互換性は2番目に頻発する問題であり、デスクトップのセキュリティキーの検出が3番目です。ここで最も頻繁に参照される課題スレッドは、[`#37762`](https://github.com/brave/brave-browser/issues/37762)、[`#50561`](https://github.com/brave/brave-browser/issues/50561)、[`#45415`](https://github.com/brave/brave-browser/issues/45415)、[`#15650`](https://github.com/brave/brave-browser/issues/15650)、[`#43043`](https://github.com/brave/brave-browser/issues/43043)、[`#34441`](https://github.com/brave/brave-browser/issues/34441)、[`#33237`](https://github.com/brave/brave-browser/issues/33237)、および[`#51858`](https://github.com/brave/brave-browser/issues/51858)です。アクティブなスレッドは、多くの直接の引用を必要とせずに、同じ方向を示しています。

これらの課題のいくつかは、過去90日以内に新しいコメントを受け取っており、歴史的な珍事ではなく、活発なリグレッションとなっています。パスキーフローを構築する開発者にとって、教訓は明白です。Braveで拡張機能主導のフローを明示的にテストし、WebAuthnの呼び出しが失敗した場合に実用的なフォールバックを提供することです。ユーザーにとっても教訓は同様に実践的です。価値の高いアカウントには、ハードウェアセキュリティキーやその他のリカバリ要素を設定しておくことです。

## 8. 結論

Braveでのパスキーの状況は、コードレベルではクリーンですが、ユーザーエクスペリエンスレベルでは乱雑です。WebAuthnパスは事実上Chromiumのものであり、実装が上流にどれほど近いかを確認する単一の文字列の上書きがあるだけです。Appleプラットフォームでは、iCloudキーチェーンが認証情報を所有しているため、パスキーのポータビリティはユーザーの期待通りに機能します。本当の摩擦は他の場所にあります。拡張機能のインターセプト（#37762）、Windows Helloの抑制（#51858）、およびAndroidのGoogle Play開発者サービス依存（#45415）です。これらの課題が解決されるまで、開発者はChromeと同等であると想定せずにBraveを個別にテストすべきであり、ユーザーは重要なアカウントに対して強力なフォールバック（理想的にはハードウェアセキュリティキー）を維持すべきです。

## 9. Corbadoについて

Corbadoは、消費者向けのログインのためのパスキーインフラストラクチャを構築し、パスキーと認証システムを大規模に運用する必要があるチーム向けにパスキーインテリジェンスプラットフォームを提供します。私たちは、実際の展開、直接のソース調査、および基盤となる仕様の綿密な読み取りに基づいて、ブラウザやオペレーティングシステム全体におけるWebAuthnとパスキーの動作に関する技術的分析を公開しています。ご質問や修正はいつでも歓迎します。

## 10. よくある質問

### 10.1 macOS上のBraveで作成したパスキーは、別のAppleデバイスのSafariで使用できますか？

はい、ただしBraveがパスキーをiCloudキーチェーンに保存する場合のみです。macOSでは、BraveはChromiumのWebAuthnスタックを使用し、新しいパスキーをiCloudキーチェーンや、作成プロンプトに表示される別のストレージターゲットに保存できます。iCloudキーチェーンに保存されたパスキーは、Apple IDを通じて同期され、そのApple IDを共有するAppleデバイス上のSafari、Chrome、およびその他のブラウザで利用可能になります。ブラウザプロファイルのストアまたはローカル専用ストアに保存されたパスキーは、別のAppleデバイス上のSafariで自動的に利用可能にはなりません。

### 10.2 なぜGoogle Play開発者サービスなしのAndroid上のBraveではパスキーが失敗するのですか？

Android上のBraveはGoogle Play開発者サービスがないと失敗する可能性がありますが、その理由は「クレデンシャルマネージャーがPlay開発者サービスの一部である」というよりも具体的です。AndroidのクレデンシャルマネージャーはシステムおよびJetpack APIですが、古いAndroidバージョンはGoogle Play開発者サービスが提供するFIDO2レイヤーにより大きく依存しています。実際には、Braveは`brave/brave-browser`の課題#45415に文書化された失敗を依然として継承しています。必要なPlay開発者サービスのパスがないGrapheneOS、CalyxOS、またはその他の脱Google化されたAndroidビルドでは、パスキーダイアログが開かず、登録または認証がタイムアウトします。

Androidのより広範な障害の状況については、ネイティブアプリのパスキーエラーを参照してください。Google Play開発者サービスとクレデンシャルマネージャーの詳細については、AndroidおよびGoogle Play開発者サービスのパスキーエラーコードを参照してください。

### 10.3 BraveはChromeのようにデバイス間でパスキーを同期しますか？

いいえ。Braveは、Googleパスワードマネージャーを介したChromeのブラウザプロファイルのパスキー同期に相当するものを提供していません。Braveで作成されたパスキーは、基盤となるOSプラットフォームのオーセンティケーター（AppleではiCloudキーチェーン、WindowsではWindows Hello、AndroidではAndroidクレデンシャルマネージャー）に保存され、そのOSアカウントを通じてのみ同期されます。一貫したクロスデバイス同期が必要な場合は、OSベンダーまたはサードパーティのパスワードマネージャー拡張機能に依存することになります。

### 10.4 設定でパスキーのオプションを無効にしても、BraveがWindows Helloのパスキーを要求するのはなぜですか？

Braveの`brave://password-manager/settings`の切り替えは、Brave自体がパスキーの保存を提案するかどうかを制御するだけです。Windowsがページに対してWindows HelloをWebAuthnプラットフォームオーセンティケーターとして宣伝するのを止めることはありません。サイトがWebAuthnを呼び出すと、WindowsはHelloを提示し、BraveにはOSダイアログを抑制するブラウザ内のスイッチがありません。この動作は、`brave/brave-browser`の課題#51858で追跡されています。

### 10.5 パスキーはBraveのネイティブフローに保存すべきですか、それともパスワードマネージャーに保存すべきですか？

1つのエコシステム内にとどまり、可動部分を最小限に抑えたい場合は、BraveのネイティブOSフロー（プラットフォームを介したiCloudキーチェーンまたはGoogleパスワードマネージャー）を使用してください。パスキーをWindows、macOS、Linux、Android間で一貫して使用する必要がある場合、またはすでにそこでシークレットを管理している場合は、1PasswordやBitwardenなどのサードパーティのパスワードマネージャー拡張機能を使用してください。2024年以降、BraveのネイティブUIは拡張機能のパスキーフローを繰り返しインターセプトしているため、拡張機能が依然としてプロンプトを所有しているかを確認する価値があります。

### 10.6 Braveのパスキーの動作について、brave/brave-browserリポジトリには現在いくつの未解決のパスキーおよびWebAuthnの課題がありますか？

2026年4月時点で、`brave/brave-browser`には`passkey`または`WebAuthn`の検索に一致する未解決の課題が24件ありました。パスキーのタグが付けられた未解決の課題は、2022〜2023年の年約2件から、2025年には6件に増加しました。Braveの場合、主なテーマはデスクトップでの拡張機能のインターセプト、Windows Helloの抑制、およびAndroidのGoogle Play開発者サービスへの依存です。