『このAI処理はクラウドかブラウザか』をestimateQoS()で自動判定する──W3CのDAOP提案を読む

Webアプリが画像のぼかし処理や写真加工にAIモデルを使う際、その推論をユーザーの端末（ブラウザ）で動かすべきか、クラウドに投げるべきかを、開発者は今のところ静的なハードウェア仕様の推測に頼るしかない。W3C WebMLインキュベーションの提案「Dynamic AI Offloading Protocol（DAOP）」（提案者はIntel所属のJonathan Ding氏）のExplainer文書を確認すると、この判断をestimateQoS()という単一のAPIで動的かつプライバシー保護的に行えるようにする設計であることが分かる。

3行まとめ

• DAOPは、アプリが「重みなし」のモデルグラフ（構造だけを表現し、実際の重みデータを含まない記述）をブラウザに渡し、ブラウザ側がハードウェア・現在のシステム状態（発熱・バッテリー等）・ソフトウェア環境を総合して性能を見積もる「callee responsible（呼び出される側が責任を持つ）」モデルを採用する
• estimateQoS()はperformanceTierという文字列を返す。ティアは"excellent"（16ms未満、60fps相当のリアルタイム）から"poor"（60秒以上、ほとんどの用途で許容不可）まで7段階で、正確な指標値ではなく粗い区分にすることでハードウェアの特定（フィンガープリンティング）を防ぐ設計
• GitHubリポジトリの直近pushは2026年6月4日で、README内の「Stakeholder Feedback / Opposition（利害関係者のフィードバック・反対意見）」の項目は「初期段階でいくつかのISVから関心が寄せられている、今後文書化予定」という1行のみで、この記事の執筆時点ではまだ実質的な内容は書かれていない

「呼び出される側」が責任を持つ設計

DAOPが採用する設計思想はこう説明されている。

The preferred approach is Model-Centric, where the device (the callee, i.e., the responder to the AI request) is responsible for evaluating its own ability to handle the requested AI workload. [...] This "callee responsible" design ensures that sensitive device details remain private, as only broad performance tiers are reported back to the application.

（望ましいアプローチはモデル中心型であり、デバイス（呼び出される側、つまりAIリクエストへの応答者）が、要求されたAIワークロードを処理する自身の能力を評価する責任を持つ。この「呼び出される側が責任を持つ」設計は、アプリケーションに報告されるのが大まかな性能ティアのみであるため、機微なデバイスの詳細がプライベートに保たれることを保証する）

estimateQoS()というAPI

具体的なAPI設計はこうだ。

dictionary MLQoSReport {
  MLPerformanceTier performanceTier;
};

partial interface MLContext {
  Promise<MLQoSReport> estimateQoS(MLGraph graph, optional MLQoSOptions options);
};

返されるperformanceTierは7段階で、"excellent"（16ms未満、60fpsのリアルタイム処理相当）・"good"（100ms未満、対話的な応答性）・"fair"（1秒未満）・"moderate"（10秒未満、バッチや単発タスクなら許容範囲）・"slow"（30秒未満）・"very-slow"（60秒未満）・"poor"（60秒以上、ほとんどの用途で許容不可）と定義されている。ティアの正確な境界値は「実装依存」とされており、「フィンガープリンティングを避けられるほど粗く、かつアプリケーションが有用なオフロード判断を下せるほど細かい」というバランスが要件として明記されている。

実装の中身は仕様の外——透明性を持たせる設計

興味深いのは、実際にどうやって性能を見積もるかという実装手法自体は、仕様が規定する対象から明確に切り離されている点だ。

These strategies are internal implementation details of the AI stack and are transparent to the application developer. It is important to note that these strategies are not part of the DAOP specification or proposal; they are discussed here only to illustrate possible implementation choices and feasibility.

（これらの戦略はAIスタックの内部実装の詳細であり、アプリケーション開発者には透過的だ。これらの戦略はDAOP仕様や提案の一部ではないことに注意が必要であり、ここでは可能な実装の選択肢と実現可能性を示すためだけに議論されている）

Explainer文書は例として、静的コストモデル（Roofline modelなど解析的な数式やルックアップテーブル）・ドライラン（実際の重みを使わない高速シミュレーション）・ブラックボックスプロファイリング（ダミーの重みでモデルを実際に動かして計測する）の3手法を挙げているが、これらはあくまで実装例であり、仕様が特定の手法を強制するわけではない。

Web Machine Learningの「公式インキュベーション一覧」にはまだ載っていない

Web Machine Learning（WebNNを所管するW3C Working Groupと、その姉妹組織であるCommunity Group）は、公式サイトに「Incubations（インキュベーション）」という一覧ページを公開している。これは「選定された(selected)タスク特化型API」を掲載する場所で、記事執筆時点(2026年8月31日)では次の5件が並んでいた。

このリストにDAOPは含まれていない。README中の「Dynamic AI Offloading Protocol」という名称、estimateQoS()というAPI設計は、あくまでwebmachinelearning Organization配下の独立したGitHubリポジトリとして存在しているだけで、Community Groupが正式に「選定した」インキュベーションの段階にはまだ達していないことが、この一覧との照合から確認できる。

GitHubリポジトリ自体の統計も、この「まだ初期段階」という見立てと整合する。2026年8月31日確認時点で、スター数6・ウォッチャー数2・フォーク数1・コミット数4、ライセンスはGitHub上で「Other(NOASSERTION)」と判定されていた(README内には別途ライセンス表記がある可能性があるが、この記事ではLICENSE.mdの中身までは確認していない)。

ブラウザベンダーの反応はまだ判断材料がない

このExplainer文書は、W3C WebMLインキュベーション（Community Group的な提案段階）のIssueとして議論されている段階にあり、正式なワーキンググループの仕様として採択されているわけではない。「Stakeholder Feedback / Opposition」の節はこの記事の執筆時点で実質的な内容が書かれておらず、ブラウザベンダーやWeb標準コミュニティからの具体的な反応がどうなっているかは、この記事のExplainer本文だけからは分からない。この記事を書いている自分自身は、WebNNやブラウザ内AI推論の実装経験がなく、この提案がブラウザベンダーに採用される見込みについての判断材料は持たない。日本語ではZenn・Qiitaともに、DAOP単体を扱った記事は検索時点で見当たらなかった。

関連記事: AIチップ 業界地図──NVIDIA/AMD/Intel/Apple/独自チップ【2026年】

感想・指摘はコメント欄へ。