問題とスコープ
インストールされたPWAのアプリ アイコンに未読件数を表示する必要があります。Badging APIの機能検出、更新およびクリアのフロー、そしてブラウザがそれをサポートしていない場合や呼び出しが失敗した場合のフォールバックについて説明してください。
面接官が評価するポイント
navigator.setAppBadge()およびclearAppBadge()がサポートされたセキュアコンテキストを必要とすることを理解しているか。- ページとService Workerの
WorkerNavigator機能を区別し、Promiseの失敗を適切に処理できるか。 - APIを未読データの信頼できる情報源（Single Source of Truth）ではなく、単なる表示用のヒントとして扱っているか。
- 更新をスロットリングしつつ、タイトル、アプリ内カウント、アクセシブルなステータステキストなどの知覚可能なフォールバックを提供できるか。
明確化のための質問
- 対象はインストールされたPWAアイコンですか、それとも通常のブラウザタブですか？
- 未読件数の信頼できる情報源は何であり、更新や複数タブ間でどのように一貫性を維持しますか？
- オフライン更新、バックグラウンドプッシュ、特定のブラウザ/OSの組み合わせへの対応は必要ですか？
- スクリーンリーダーのユーザーにはどのように同じ状態を伝え、カウントに上限を設けたり非表示にしたりする必要がありますか？
30秒の回答フレームワーク
バッジは任意のプレゼンテーション層として扱います。HTTPS環境で navigator.setAppBadge を検出し、同期された未読件数から更新し、Promiseの失敗をチェックし、0の場合は clearAppBadge を呼び出します。非対応または失敗した場合は、アプリ内カウント、タイトルまたはファビコンのインジケーター、およびアクセシブルなステータステキストを維持します。ページとService Workerは1つのバージョン管理されたカウントプロトコルを共有し、更新はスロットリングされ、メッセージの閲覧がバッジに依存することはありません。
ステップバイステップの詳細解説
1. 機能と表示の境界を定義する
Badging APIはインストールされたWebアプリのアイコンを対象としています。2026年W3C Working Draftでは、setAppBadge および clearAppBadge を Navigator と WorkerNavigator 上で公開しています。これはセキュアコンテキストの機能であり、ユーザーエージェントによっては省略されたり、値の表示方法が変更されたりするため、クロスプラットフォームで正確な数値を保証することはできません。
2. 信頼できる未読データから更新を駆動する
サーバーまたは同期層から非負の整数を取得し、上限設定と重複排除を行ってから navigator.setAppBadge(count) を呼び出します。0の場合は clearAppBadge() を呼び出します。フラグ（印）のみを表示する場合は数値を省略します。すべてのPromise拒否（rejection）を処理し、機能やエラーの種類をログに記録します。メッセージ内容自体は決して記録しません。
3. フォアグラウンドとバックグラウンドのパスを設計する
ページは同期イベント後に更新でき、Service Workerは実際のブラウザのサポート状況に応じて、バックグラウンドイベント用に該当するワーカー機能を使用できます。両方のパスで同じバージョン管理されたカウントを書き込むため、古いイベントが新しい値を上書きすることはありません。起動時には信頼できるカウントを再同期します。バッジはデータベースではありません。
4. 失敗とアクセシビリティを処理する
機能が存在しない、コンテキストがセキュアでない、PWAがインストールされていない、または呼び出しが失敗した場合は、アプリ内リスト、ナビゲーションのカウント、ドキュメントタイトルの手がかりに加え、「未読メッセージ3件」などの読み取り可能なテキストを維持します。aria-live の通知は変更時のみにスロットリングします。バッジを決して唯一の伝達手段にしてはならず、失敗によってメッセージの閲覧や既読処理が妨げられてはなりません。
質の高い模範解答
まず、プロダクトの対象が通常のタブではなく、インストールされたPWAアイコンであることを確認します。HTTPSページで navigator.setAppBadge を検出し、同期された非負の未読件数で更新を駆動し、0のときはクリアし、Promiseの失敗をキャッチします。ページとService Workerは1つのバージョン管理されたカウントを利用し、起動時に再同期することで、古いイベントによる上書きを防ぎます。サポートが限定的であり、プラットフォームによっては大きな値がマーカーとして描画される可能性があるため、アプリ内カウント、タイトルやファビコンのフォールバック、スロットリングされたアクセシブルなステータステキストを維持します。バッジは単なるヒントであり、その失敗によってメッセージの閲覧が妨げられることはありません。
よくある間違い
- すべてのブラウザタブが正確な数値バッジをサポートしていると思い込むこと。
- HTTPS、インストール状態、メソッドの存在、またはPromiseの拒否チェックを省略すること。
- バッジを唯一の未読データストアとして使用し、リフレッシュやマルチデバイス間でのズレを引き起こすこと。
- ページとService Workerで独立したカウントを保持させ、古いイベントが優先されてしまうこと。
- タイトル、アプリ内カウント、アクセシブルなフォールバックを用意せず、色変更のみを提供すること。
- メッセージごとにAPIを呼び出し、過負荷、バッテリー消費、不要な更新を引き起こすこと。
フォローアップの質問と回答
ファビコンのみを更新しないのはなぜですか？
ファビコンはタブやブックマークに影響を与えるものであり、インストールされたアプリのアイコンを表すことはできません。Badging API、ファビコン、タイトル、アプリ内カウントを、機能に応じたプレゼンテーション層として組み合わせます。
4000を渡すとどうなりますか？
ユーザーエージェントは大きな値を 99+ などに圧縮したり、マーカーのみを表示したりする場合があります。視覚的な値には上限を設け、正確なカウントはアプリ内で保持します。
フォールバックをどのようにテストしますか？
セキュアおよび非セキュアなコンテキスト、未インストールのPWA、メソッドの欠落、Promiseの拒否、0でのクリア、順序が狂ったバックグラウンドイベント、スクリーンリーダーのテキストを網羅します。どのような場合でもメッセージのデータフローが引き続き機能することを検証します。