プロンプトとコンテキスト
このフロントエンドの設問は、ブラウザプラットフォームとリリースエンジニアリングを組み合わせたものです。アプリケーションにはすでにWebGLまたはCPUの処理パスが存在し、制限されたAPIサブセットしか公開していないデバイスにもリーチしつつ、WebGPUによる高速なレンダリングを実現することを目指しています。核心となるのは機能と制限値（limits）の交渉です。アダプターを取得できたからといって、すべてのシェーダー、フォーマット、またはパフォーマンス目標が利用可能であることを意味するわけではありません。
GPUWeb仕様では、互換モードは古いグラフィックスAPIへのマッピングを意図した制限付きWebGPUサブセットとして定義されています。実装によっては、アダプターの要求が拒否されたり、公開される機能や制限値が少なくなったり、実行時にデバイスが喪失したりする可能性があります。可用性、正確性、パフォーマンスは個別に測定する必要があります。
面接官が評価するポイント
- アダプター、機能、制限値を選択する前に機能マトリクスを構築しているか。
- 単一のブール値ではなく、順序付けられたプロダクトのフォールバックとして、コア、互換、WebGL、CPU、静的結果パスを定義しているか。
GPUDevice.lostが非同期の終了シグナルであり、復旧によってリソースとレンダリング状態を再構築する必要があることを理解しているか。- 実機でのロールアウト、品質ゲート、プライバシーに配慮したテレメトリ、迅速なロールバックを設計しているか。
- 「正常に描画される」、「レイテンシ要件を満たす」、「許容可能な消費電力である」を切り分けて評価しているか。
明確化のための質問
- ワークロードはレンダリング、汎用計算、ブラウザ内推論のどれですか？それぞれで必要なストレージ、テクスチャ、精度の機能が異なります。
- ローエンドデバイスではどのような体験を維持する必要がありますか？これにより、最低限必要なWebGL、CPU、または静的結果パスが決まります。
- 初回ロード時に短い機能プローブを実行することは可能ですか？これがないと、過去のデバイスプロファイルが古くなったり誤ったりする可能性があります。
- デバイス喪失後にcanvasとリソースを再初期化できますか？できない場合、アプリケーション状態には復旧可能なUI境界が必要です。
- ロールアウトはブラウザ、GPU、ドライバ、地域、ユーザーのどの単位でセグメント化されますか？セグメンテーションによってドライバ固有のリグレッションを特定する方法が決まります。
30秒の回答
「まずWebGPU、アダプター、機能、制限値を検出し、コア、互換、WebGL、CPU、または静的出力を明確な機能ラダーとして定義します。各段階（ステップ）ではサポートされているシェーダー、パイプライン、リソースのみを作成し、正確性テストとパフォーマンスバジェットを設定します。device.lost を監視し、シングルフライトの復旧フローを使用してデバイス、リソース、canvas状態を再構築します。失敗した場合は縮退して理由を記録します。ロールアウトはブラウザ、GPU、ドライバ、アプリバージョンでセグメント化します。初期化、デバイス喪失、レンダリングエラー、p95フレーム時間、タスク完了率を監視し、古いパスを削除しないリモートキルスイッチを用意します。」
ステップごとの解決策
ステップ 1: 機能検出を契約（コントラクト）として確立する
セキュアコンテキストと navigator.gpu を確認してから、アダプターをリクエストします。サポートされている機能と制限値を読み取ります。APIオブジェクトが存在することを確認するだけでは不十分です。結果をコア、互換、WebGL、またはCPUに分類し、テレメトリ用におおまかなブラウザ、OS、GPUベンダー、ドライバ、アプリバージョンのディメンションを使用します。
互換モードは実行可能なデバイスの範囲を広げますが、機能、制限値、パフォーマンスの上限はより控えめになります。テクスチャフォーマット、バインディングレイアウト、ストレージサイズ、ワークグループ制限、精度など、ワークロードのハード要件をリストとして書き出します。必要な機能が1つでも不足している場合は、シェーダーの作成失敗を待つのではなく、次の段階を選択します。
ステップ 2: 機能段階に応じたリソースを構築する
各段階に固有のシェーダーバリアント、パイプライン記述、リソースバジェットを割り当てます。小さな三角形の描画や小規模な推論スモークテストから開始し、コマンド送信と出力を検証した上で、完全なシーンへと移行します。コア向けに作成されたバインドグループやテクスチャフォーマットが、互換モードでもそのまま受け入れられると仮定してはいけません。
リソース作成に失敗した場合は、構造化エラーを記録し、その段階のオブジェクトを解放します。静的画像、WebGL canvas、またはCPUの結果はプロダクトの状態モデルを共有し、ユーザーがタスクを完了できるようにしなければなりません。フォールバックは、同一のフレームレートや精度を意味するものではありません。
ステップ 3: デバイス喪失と復旧の競合を処理する
GPUDevice.lost は、デバイスのライフタイムが終了したときに解決されます。復旧状態に移行します。新しい作業の送信を停止し、古いフレームをキャンセルまたはマークし、新しいアダプターとデバイスをリクエストし、該当する機能段階向けのシェーダー、パイプライン、バッファ、テクスチャ、バインドグループを再構築して、レンダーズープを再開します。世代トークンまたはシングルフライトのPromiseを使用して、2つの復旧試行が新しいデバイスを上書きしないように防ぎます。
喪失理由がリソース圧迫やドライバの問題を示唆している場合は、リトライ回数とその間隔に上限を設けます。失敗が繰り返される場合はWebGLまたはCPUに切り替え、機能が縮退していることをUIに伝えます。既存のデバイス喪失に関する設問は復旧メカニズムに焦点を当てていますが、本設問は互換性の機能マトリクスとリリースコントロールに焦点を当てているため、スコープを明確に区別してください。
ステップ 4: 段階的ロールアウトとロールバックを設計する
まずは社内デバイスマトリクスから開始し、ブラウザのバージョン、GPUベンダー、ドライバ、OS、地域ごとに展開を拡大します。フラグはリモートで無効化可能である必要がありますが、設定の配信が正確性における単一障害点になってはならず、クライアント側で安全なデフォルトを保持します。
アダプター要求の失敗、デバイス作成の失敗、最初のインタラクションまでの時間、p50/p95フレーム時間または推論レイテンシ、シェーダーおよびパイプラインエラー、デバイス喪失率、復旧成功率、フォールバック率、タスク完了率を追跡します。ハードウェアセグメンテーションによりドライバのリグレッションが浮き彫りになります。テレメトリは完全なフィンガープリントではなく、おおまかなデバイスラベルとバージョンに留めます。
ステップ 5: 正確性、パフォーマンス、消費電力を検証する
WebGPU、互換モード、WebGL、CPUの出力を、ピクセル、ジオメトリ境界、テクスチャカラー、推論結果の許容誤差を設定して比較します。パフォーマンス測定のためにシーン、解像度、バッチサイズを固定し、p50/p95を報告します。フラッグシップデバイスの平均値は保証にはなりません。バックグラウンドや低バッテリーのシナリオで、送信レート、メモリ、デバイステンプのプロキシをテストします。
段階ごとにゲートを設定します。互換モードにはコア向けのバジェットではなく、プロダクトとして最低限必要なフレームレートと出力エラー許容値を適用します。エラー、消費電力、または復旧時間がしきい値を超えた場合は、その段階を無効化し、WebGL/CPU出力を維持した上で、最小限の再現環境とともにドライバの詳細を収集します。
設計上のトレードオフと境界
#### APIプローブ vs デバイスプロファイル
ライブプローブは正確ですが初回ロード時間を消費します。デバイスプロファイルは高速ですが古くなったりフィンガープリントの懸念が生じたりします。厳密な機能判定には短いプローブを使用し、プロファイルは順序付けやロールアウトにのみ使用して、実際の制限値をバイパスするために使用してはなりません。
#### 互換モード vs WebGL
互換モードはWebGPUのリソースおよびコマンドモデルをより多く維持するため、アーキテクチャを共有できます。WebGLはより広範で成熟したカバレッジを持つ可能性がありますが、シェーダー、同期、パフォーマンスモデルが異なります。APIの新規性ではなく、必要な機能、正確性の移行コスト、ユーザータスクに基づいて選択します。
#### 自動復旧 vs 即時フォールバック
制限付きの復旧は一時的なリソース圧迫に対応できますが、無限リトライはドライバ障害をジャンク（描画カクつき）や電力消費の増大へと悪化させます。復旧が失敗したか、喪失の繰り返しがしきい値を超えた場合は、即座に切り替えて診断イベントを1回発行します。
模範解答
「WebGPUのロールアウトを機能マトリクス、リソース構築、復旧ステートマシン、段階的制御に分割します。セキュアコンテキストを検証し、アダプターを要求し、機能と制限値を読み取って、コア、互換、WebGL、CPUを機能ラダーとして順序付けます。各段階ではサポートされているシェーダーとリソースのみを作成します。device.lost の後、送信を停止し、世代トークンを使用して1つの復旧フローでデバイスとすべてのGPUオブジェクトを再構築し、失敗した場合はフォールバックします。ロールアウトはブラウザ、GPU、ドライバ、バージョンでセグメント化し、初期化、フレーム時間、エラー、喪失、復旧、タスク完了メトリクス、およびリモートオフスイッチを用意します。互換モードはカバレッジを広げるものであり、パフォーマンスを保証するものではないため、正確性、レイテンシ、消費電力には個別のゲートを設けます。」
よくある間違い
navigator.gpuのみをチェックする → アダプターやデバイスの作成が依然として失敗する可能性があり、機能や制限値が不十分な場合がある → 機能マトリクスを構築して検証する。- 互換モードをローエンドのコアとして扱う → シェーダー、フォーマット、制限値が異なる場合がある → 各段階に固有の要件とスモークテストを割り当てる。
- 喪失後にレンダリング関数を再度呼び出す → リソースは停止したデバイスに属している → シングルフライト復旧フローを通じてすべてのリソースを再構築する。
- デバイス作成を無限にリトライする → ドライバ障害がジャンクや電力消費の増大につながる → 試行回数と間隔に上限を設け、フォールバックする。
- 平均フレームレートのみを監視する → 特定のGPUやドライバのコホート全体で障害が発生する可能性がある → ブラウザ、GPU、ドライバごとにp95とタスク完了率をセグメント化する。
フォローアップと回答
ワークロードが互換モードの制限値に適合しているかどうかをどのように判断しますか？
機能、テクスチャフォーマット、ストレージ、ワークグループサイズ、精度のハード要件を書き出し、アダプターの制限値と比較します。リストの条件をすべて満たした場合にのみその段階に入り、それ以外の場合はWebGL、CPU、または静的出力を選択して不足している機能を記録します。
ユーザーが編集中にデバイスが喪失した場合、ページをリロードしてもよいですか？
デフォルトではリロードすべきではありません。アプリケーション層で編集状態を永続化し、GPU作業を一時停止して、制限付きの再構築を1回試行します。失敗した場合は状態を保持したままレンダラーを切り替え、視覚的な品質低下をユーザーに伝えます。リロードは状態の移行が安全に行えない場合にのみ、復旧エントリーポイントを設けた上で実施します。
特定のドライバコホートで突然デバイス喪失率が高くなりました。どのようにロールバックしますか？
GPU、ドライバ、ブラウザ、アプリバージョンごとに異常を確認し、他のコホートを有効にしたまま、その組み合わせに対する互換モードのロールアウトを無効化します。初期化、シェーダー、リソース圧迫、喪失理由を調査し、最小限の再現環境を作成して修正後、社内マトリクスから再度展開を開始します。
WebGLへのフォールバックがビジネス上の成果を損なわないことをどのように証明しますか？
同一の入力に対してクロスバックエンドのゴールデンセットを作成し、ピクセルまたは推論出力の許容誤差を比較します。これには空データ、境界値、高負荷ケースを含めます。タスク完了率、結果の正確性、レイテンシに対して個別のゲートを設定します。視覚的な類似性は、数値的またはインタラクション上の同等性を証明するものではありません。