プロンプトとスコープ
あるWebアプリケーションが、画像アップロードに伴うプライバシーリスクとネットワークレイテンシを削減するために、ブラウザ内でローカルに画像分類モデルを実行したいと考えています。チームは2026年5月のW3C Web Neural Network API Candidate Recommendation Draftの採用を検討しています。WebNNはCPU、GPU、NPUの実行をターゲットにできる計算グラフAPIですが、仕様は現在も策定中であるため、Candidate Recommendation Draftであることはすべてのブラウザでの安定したサポートを保証するものではありません。
モデル変換、グラフ構築とコンパイル、推論のディスパッチ、デバイスの選択、フォールバック、およびリリース検証を網羅した完全な回答を提示してください。
面接官が評価するポイント
面接官は、明確な「1回構築して何度も実行する（build once, execute many times）」ライフサイクル、および非同期のMLGraphBuilder.build()コンパイルと非同期のMLContext.dispatch()実行の区別を確認します。WebNNはハードウェアにとらわれない抽象化として説明されるべきであり、すべての演算子がすべてのデバイスで同等に動作することを保証するものではないと理解している必要があります。
優れた回答では、演算子のカバー率、テンソルバインディング、メインスレッドのブロック、機能検出、プライバシーとフィンガープリント、ブラウザ互換性、およびロールバック可能なカナリアプランについて論じられます。
回答前の明確化のための質問
- モデルは固定形状を使用していますか、それとも動的形状や複数の精度をサポートする必要がありますか？
- 対象となるブラウザとオペレーティングシステムは、同じ演算子とバックエンドを公開していますか？
- 推論はオフラインを維持する必要がありますか、それとも安全なサーバーフォールバックが許容されますか？
- 目標はファーストペイントの速度、フレームごとのレイテンシ、スループット、エネルギー消費、プライバシーのどれですか？
- モデルは機密性の高い画像を処理しますか？また、ハードウェア機能がフィンガープリントのシグナルになる可能性はありますか？
30秒の回答フレームワーク
「WebNNを実行バックエンドの候補として扱います。まずモデル演算子とテンソルレイアウトを検証し、次にグラフの構築とコンパイルを推論パスから外します。コンパイルとディスパッチは非同期であり、名前付きテンソルが入出力をバインドします。リリース前にブラウザ、デバイス、モデルバージョンのマトリクスを構築し、サポートされていない機能やコンパイルの失敗は、明確なデータ境界を持つWebAssemblyまたはサーバーにフォールバックさせます。初回コンパイル、定常状態の推論、メモリ、エネルギー、メインスレッドの応答性を測定し、段階的にカナリアリリースを行い、キルスイッチを維持します。」
ステップバイステップの詳細な回答
モデルコントラクトの確定
入力形状、データ型、レイアウト、正規化、出力ラベル、および誤差許容度を確定します。モデルをサポートされている演算子サブグラフに変換し、ユーザーデバイスでの部分的な実行後ではなく、グラフ構築時にサポートされていない演算子を検出します。レイヤーごとの比較のために、WebAssemblyまたはサーバーのリファレンス実装を保持します。
グラフの構築とコンパイル
コンテキストとMLGraphBuilderをnavigator.ml経由で作成し、入力、定数、演算子を構成します。build()はグラフをコンパイルしてPromiseを返します。各ビルダーは1つのグラフを所有する必要があります。初回のコンパイルがクリックのレイテンシにならないよう、事前に、またはWorker内でグラフをウォームアップ（事前実行）します。
const context = await navigator.ml.createContext({ deviceType: 'gpu' });
const builder = new MLGraphBuilder(context);
const input = builder.input('image', {
dataType: 'float32',
dimensions: [1, 224, 224, 3],
});
const weights = builder.constant(weightDescriptor, weightBuffer);
const logits = builder.conv2d(input, weights, convOptions);
const graph = await builder.build({ logits });デバイスオプションは単なる候補ポリシーです。すべての値を受け入れると仮定するのではなく、対象のブラウザと仕様バージョンに対して実装を検証する必要があります。
非同期実行とメモリフローの設計
dispatch()はグラフの実行を実行タイムラインに投入し、即座に戻ります。名前付きの入力テンソルと出力テンソルをバインドし、実行完了後に結果を読み取ります。フレームごとに割り当てるのではなく、コンパイル済みグラフ、コンテキスト、およびバッファを再利用して繰り返し推論を行います。カメラストリームにはバックプレッシャーが必要です。無限のキューを構築するのではなく、前のフレームがまだ実行されている間に新しいフレームをドロップまたは合体（coalesce）させます。
デバイスとフォールバックの選択
CPU、GPU、またはNPUを選択する前に、API、演算子、およびモデルのサポートを検出します。デバイスが利用可能であるからといって、対象の演算子が効率的であるとは限りません。エンドツーエンドの測定に基づいて選択します。フォールバックチェーンは WebNN → WebAssembly → サーバー とすることができますが、すべてのレベルで前処理と結果チェックを共有する必要があります。サーバーフォールバックは画像をアップロードするため、UIとネットワーク層で同意と保持の境界を明記する必要があります。
メインスレッドとインタラクションの保護
グラフの構築、コンパイル、前処理、後処理はインタラクションに影響を与える可能性があります。負荷の高い処理はDedicated Workerに配置し、メインスレッドは入力キャプチャとUI状態の維持に専念させます。古い結果を破棄するには、キャンセルまたはシーケンス番号を使用します。平均推論時間だけでなく、Long Task、入力バースト、バックグラウンドタブの復帰も測定します。
正確性と互換性のマトリクスの構築
ブラウザのバージョン、オペレーティングシステム、デバイスタイプ、モデルの精度、演算子セットをマトリクス化します。出力、精度、境界入力をリファレンスバックエンドと比較します。コンパイルの失敗、サポートされていない演算子、デバイスの喪失、コンテキストの破棄を記録します。W3CドキュメントはまだCandidate Recommendation Draftであるため、リリース計画では仕様の変更や実装の違いを許容する必要があります。
プライバシー、権限、およびフィンガープリントへの対処
ローカル実行により画像のアップロードは減少しますが、モデルファイル、キャッシュ、テレメトリから情報が漏洩する可能性があります。必要な重みのみをキャッシュし、入力特徴量のログ記録を避け、デバイスタイプをユーザー識別子に変えないようにします。仕様書には、デバイスのスケジューリングがフィンガープリントのシグナルを作成する可能性があると記載されています。したがって、機能検出の結果は最小限かつ短寿命に抑え、ソフトウェアまたはサーバーの代替手段を用意する必要があります。
カナリア、監視、およびロールバック
機密性の低いモデルと小規模なブラウザセットから開始します。初回コンパイル、定常状態のP50/P95、メインスレッドのLong Task、メモリ、エネルギー、失敗率、フォールバック率を比較します。モデルやブラウザのアップグレード時にマトリクスを再実行します。デバイスのクラッシュ、精度の低下、過剰なエネルギー消費、またはプライバシー要件の違反が発生した場合は、WebNNを無効にしてリファレンスバックエンドを使用します。分析のためにバージョン、デバイス、モデルのハッシュを保持します。
質の高い模範回答
「モデルの入力、出力、および誤差のコントラクトを確定し、WebNNへの演算子マッピングを検証します。グラフは一度だけ構築およびコンパイルされます。build()とdispatch()は非同期フローに従い、推論ループはそのコンテキストとバッファを再利用します。リリースマトリクスはブラウザ、デバイス、モデルのバージョンを網羅し、Workerがコンパイルと前処理を処理します。WebNN、WebAssembly、サーバーが監視可能なフォールバックチェーンを形成し、サーバーフォールバックではアップロードの境界を明示します。カナリアメトリクスには初回および定常状態のレイテンシ、Long Task、メモリ、エネルギー、精度、失敗率が含まれ、キルスイッチによって即座にリファレンスバックエンドに復旧できるようにします。」
よくある間違い
- Candidate Recommendationを普遍的なサポートとして扱う → ブラウザや演算子のギャップによりユーザー体験が損なわれる → バージョンと機能のマトリクスを構築する。
- リクエストごとにグラフをコンパイルする → 初回実行のコストが繰り返される → コンパイル済みグラフをウォームアップして再利用する。
- 理想的なGPUのみでベンチマークを行う → CPUまたはNPUのパスが失敗する → 各バックエンドでエンドツーエンドの測定を行う。
- ディスパッチを同期的として扱う → カクつき（jank）や順不同の結果が発生する → 非同期状態とシーケンス番号を使用する。
- すべてのカメラフレームをキューに入れる → レイテンシが無制限に増大する → バックプレッシャーを適用し、古いフレームをドロップする。
- デバイス機能をIDとして報告する → フィンガープリントのリスクが高まる → 検出を最小限に抑え、ソフトウェアフォールバックを維持する。
フォローアップの質問と回答
フォローアップ1：なぜ直接WebGPUを使用しないのですか？
WebGPUはより低レベルのリソースとシェーダー制御を公開しており、カスタム演算子や細かなスケジューリングに適しています。WebNNは、フレームワークやハードウェアバックエンドにより直接マッピングされる、より高レベルのニューラルネットワークグラフの抽象化を提供します。演算子のカバー率、保守性、パフォーマンス目標、プライバシー境界に基づいて選択します。
フォローアップ2：コンパイルに10秒かかります。ユーザーに見える待機時間をどのように回避しますか？
モデルの読み込みとコンパイルをWorkerに移行し、アイドル時間にウォームアップを行い、整合性チェック済みの重みをキャッシュします。最初のリクエストでまだ利用できない場合は、正確な状態を表示してWebAssemblyまたはサーバーフォールバックを使用します。偽の出力の背後にコンパイルの失敗を隠してはなりません。
フォローアップ3：GPUの出力がリファレンスと異なる場合があります。どうしますか？
浮動小数点の丸め、精度の変換、演算子の実装の違い、および実際のモデルの欠陥を切り分けます。固定入力、中間テンソル、および許容しきい値を使用して再現します。製品の許容範囲を超える場合は別のバックエンドを使用し、ブラウザ、ドライバー、モデルのバージョンを記録します。
フォローアップ4：ユーザーが画像のアップロードを拒否し、WebNNが利用できません。どうしますか？
ローカルのWebAssemblyまたは明確な利用不可状態を提供します。ユーザーの選択を無視して迂回してはなりません。プロダクト側でモデルの複雑さを軽減したり手動フローを提供したりすることはできますが、データの境界を透明に保つ必要があります。