結論:WebAIは「AI推論をブラウザの標準機能にする」提案
WebAIは、Webサイトや拡張機能がブラウザに組み込まれたローカルモデルを呼び出すためのAPI群です。開発者がモデル配布、GPUサーバー、APIキー、トークン請求を直接管理しなくても、対応ブラウザ上で文章生成、要約、分類、埋め込みを実行できる構想です。OperaはGoogleやMicrosoftなどが関わるproposed web standardと説明していますが、W3Cの正式な勧告や複数ブラウザの安定実装になった段階ではありません。
コスト面では、クラウドAI事業者への1リクエストごとの支払いを避けられるのが最大の特徴です。ただし推論コストが消えるわけではなく、CPU・GPU・メモリ・電力・モデルdownload・端末差へのsupportという形で利用者側へ移ります。事業者にとっての限界費用は下がり得ますが、性能と可用性を自社で一律に保証しにくくなります。
現時点では、機密性が高く、応答品質を端末内モデルで満たせる補助機能に向きます。すべてのユーザーが同じモデル・速度を必要とする基幹処理や、複雑な推論をWebAIだけへ移すのは早計です。cloud APIを完全に置き換えるより、local-firstとfallbackを組み合わせる基盤として評価します。
| 項目 | WebAI早期preview | 実務上の意味 |
|---|---|---|
| 実行場所 | ユーザー端末のbrowser内 | page dataをcloudへ送らず処理可能 |
| API | Prompt・Decision・Embeddingほか | 生成、分類、類似検索を共通化 |
| 課金 | per-requestのWebAI料金は非公表/不要 | hardware・電力・support costは残る |
| model | Gemma、Apple on-device modelなど | browser・OS・端末で利用modelが変わる |
| 提供段階 | opt-inのearly preview | 仕様・互換性・提供範囲が変わり得る |
この節の一次情報:Opera公式|WebAI発表 / Opera公式|Web AI developer page
開発元と公開状況:Opera Oneで始まった早期プレビュー
開発元はブラウザ企業のOperaです。Operaは2024年にもdeveloper buildでローカルLLMを試していましたが、今回の違いはブラウザ自身のAI機能に閉じず、Webサイトと拡張機能から利用できるAPIとして公開した点です。ブラウザをローカル推論runtimeとして扱うため、ユーザーは別のAIアプリやOllama serverを構成する必要がありません。
2026年10月28日の確認時点で、WebAIは設定から明示的に有効化するearly previewです。何もdownloadされない状態が初期値で、ユーザーが有効にすると対応modelが取得されます。Webサイトからの利用にはsite-specific permissionを使うとOperaは説明しています。
対応端末は64-bit Windows PCのIntel/AMDとApple silicon Macです。Intel Mac、Linux、Windows on Armには未対応です。公式press releaseはOpera Oneで先行しOpera GX・Neonは後続と説明する一方、公式blogは3製品でearly previewと記載しており、配布状況の表現が一致していません。実装前に対象versionと実機のAPI availabilityを確認してください。
仕組み:Webページからブラウザ内のモデルを呼び出す
従来のcloud AIでは、Webアプリが自社backendへrequestを送り、backendがOpenAIやGeminiなどのAPIへ接続します。API key、利用量、retry、data retention、請求はservice運営者が管理します。WebAIでは、pageやextensionがbrowser APIを呼び、選択されたlocal modelが端末内で処理します。model weightsとinference engineはbrowser側が管理するため、Webアプリへprovider keyを埋め込む必要がありません。
Operaはmodel-agnosticを掲げ、open-weight modelと端末に既にあるcompatible modelを利用すると説明しています。launch時の例はGoogle Gemmaと、Mac上のApple on-device foundation modelです。つまり同じJavaScript APIを呼んでも、OSやbrowserが選ぶmodel、量子化、利用hardwareによって品質・latency・memory消費が変わる可能性があります。
privacy上は、処理対象をcloud AI providerへ送らずに済みます。ただしページ本体、extension、browser sync、telemetryまで自動的に安全になるわけではありません。アクセス許可の範囲、入力の保存、悪意あるpageからの呼び出し、model download元を別々に確認する必要があります。
| 処理経路 | cloud AI API | Opera WebAI |
|---|---|---|
| 推論 | providerのdata center | user deviceのbrowser |
| API key | 通常はserver側で管理 | WebAI利用にprovider key不要 |
| 課金単位 | token・request・imageなど | cloud従量課金なし。local資源を消費 |
| 品質・速度 | model/tierごとに比較的一定 | 端末とbrowser実装に依存 |
| data経路 | 外部providerへ送信 | 対象処理は端末内で完結可能 |
API仕様:Prompt、Decisions、Semantic Embedderなどを提供
developer pageにはPrompt、Summarizer、Writer、Rewriter、Translator、Proofreader、Semantic Embedder、Decisionsのplaygroundが掲載されています。Prompt APIは会話生成とstreaming、conversationのforkを扱います。Semantic Embedder APIは文章をvectorへ変換し、semantic similarityによるrankingやclusteringに使います。
Decisions APIは、textについてYes/No、複数候補、score付きの質問を1 passで処理します。schemaへcontextとboolean・choice・scoreを定義し、confidence thresholdも指定できるUIが公開されています。文章を生成してJSONへparseするより、tab分類、spam判定、job postの関連度、記事の優先度付けに適しています。
ただし、stableなcross-browser specification、model IDの固定方法、token上限、同時実行数、timeout、error code、versioning policyは十分に公開されていません。Prompt APIはChromeのbuilt-in AI documentationへlinkされていますが、Opera独自APIを含む全機能が他browserで同じ挙動になる保証はありません。
| API | 処理 | 用途例 |
|---|---|---|
| Prompt | 生成・会話・streaming | 補助文、質問応答 |
| Summarizer/Writer系 | 要約・執筆・書換・校正 | page内text処理 |
| Translator | 翻訳 | 閲覧中contentのlocal翻訳 |
| Semantic Embedder | vector化・類似度・cluster | local search、関連度ranking |
| Decisions | boolean・choice・score | 分類、filter、routing、risk gate |
この節の一次情報:Opera公式|Prompt API playground / Opera公式|Semantic Embedder API / Opera公式|Decisions API
料金と原価:token請求は減るが、costがゼロになるわけではない
Operaは、WebAIによりdevelopersがper-requestのcloud costやAI infrastructureを持たずに機能を追加できると説明しています。2026年10月28日時点でWebAI API自体の有料料金表、token単価、request単価は公開されていません。early previewの範囲では、一般的なcloud APIのように処理量に応じた請求を受ける仕組みは示されていません。
運営者側の直接原価は下がり得ます。例えば記事の関連度判定を100万回行っても、cloud providerへ100万回分のtoken料金を支払わず、ユーザー端末で処理できます。一方、利用者はmodel downloadの通信量とstorage、推論中のCPU・GPU・電力、battery、発熱、待ち時間を負担します。企業は問い合わせ対応、端末要件の案内、fallback用cloud APIも原価へ含めます。
比較では『1000回当たりAPI料金』だけでなく、WebAIが利用可能だった割合、local処理の成功率、fallback率、平均処理時間、端末離脱率を測ります。local 70%、cloud fallback 30%なら、削減対象はcloud利用量の70%であり、運用・support costを差し引いた金額が実際の効果です。
| cost項目 | WebAI | 確認方法 |
|---|---|---|
| cloud token料金 | local成功分は原則不要 | fallbackを含む実request数を計測 |
| model配布 | download・storageをuserが負担 | 初回容量と更新頻度を実測 |
| compute・電力 | user deviceで消費 | 代表端末でCPU/GPU・batteryを測定 |
| 運用 | 端末差・browser差のsupport | 利用不可率と問い合わせ工数を計上 |
| 品質補償 | 端末modelで差が出る可能性 | model別ではなく実端末populationでeval |
この節の一次情報:Opera公式発表|No per-request cloud costs
速度・モデル仕様:公式benchmarkは未公開
Operaはperformanceが端末hardwareに依存すると説明していますが、modelごとのparameter数、量子化、memory使用量、tokens/秒、TTFT、battery消費の標準benchmarkを公開していません。Apple foundation modelとGemmaでは能力とresource要件が異なるため、『WebAIは何ms』という単一の速度は出せません。
外部報道も現時点では発表内容と製品positionの確認が中心で、同一promptを複数端末で比較した独立benchmarkは見つかりませんでした。TechCrunchはlocal実行がcomputer performanceへ負荷をかけ、速度はhardware次第になるtrade-offを指摘しています。数値がない段階でcloud APIより高速、安定、低消費電力と断定することはできません。
導入前の最低検証は、low-end/median/high-endの3端末で、初回download時間、availability、TTFT、総処理時間、memory、battery、成功率を測ることです。classificationではaccuracyとconfidence calibration、embeddingでは検索recall、生成ではtask successと出力長を合わせて評価します。
この節の一次情報:TechCrunch|Opera introduces WebAI
従来方式との違い:cloud API、Ollama、WebGPUとどう使い分けるか
cloud APIはbrowserを問わず同じmodelとSLAを提供しやすく、heavy reasoningや監査にも向きます。OllamaやLM Studioはlocal serverへOpenAI互換APIで接続でき、modelを開発者が選べますが、ユーザーに別appのinstallと起動を求めます。Transformers.jsやONNX Runtime WebはWebGPU/WASMでpage自身がmodelを配布・実行し、自由度が高い一方、downloadとruntime管理をapplicationが負います。
WebAIはruntimeとmodel管理をbrowserへ寄せることで、site側の実装とper-request costを減らします。その代わり、Opera adoption、permission、利用可能modelに依存します。企業向けWeb SaaSで全面採用するより、Opera利用者にはlocal処理、他browserにはcloud処理というprogressive enhancementが現実的です。
Decisions APIについては、OpenAI Decisions APIやJev、Decision 3.0と同じ『判断』を扱いますが、提供層が異なります。WebAI Decisionsはuser deviceのbrowser primitive、他はhosted APIまたはself-host modelです。同じlabel付きdataでaccuracy、latency、cost、coverageを比較してください。
| 方式 | 強み | 弱み |
|---|---|---|
| Opera WebAI | browser標準API、key不要、local | early preview、Opera・端末依存 |
| cloud AI API | model・容量・SLAを揃えやすい | 従量課金、network、data送信 |
| Ollama/LM Studio | modelを選べるlocal server | install・起動・port管理 |
| WebGPU/WASM runtime | browser内で自由に実装 | model配布と最適化をappが担当 |
| self-host server | 企業側でdata・model・capacity管理 | GPUと運用負荷 |
この節の一次情報:関連記事|OpenAI Decisions API / 関連記事|Decision 3.0
海外で注目されている根拠
発表当日の2026年10月27日にTechCrunchがAI categoryで報道し、WebAIをcloudへ依存せずbrowserでAIを実行する新しいstandardとして取り上げました。9to5MacはApple silicon上でApple foundation modelをbrowserから使える点、Digital TrendsとThurrottはWebサイト・extensionへlocal AIを開放する点を報じています。
Opera自身もProject Lens、Got It?、Semantic Artなど6つのextension exampleを同時公開しました。classification、quiz生成、semantic similarityを、単なるchat UIではなく閲覧中pageの機能へ組み込む具体例があるため、developerが用途を試せる段階には進んでいます。
一方、Hacker Newsの大規模discussion、GitHubでの独立実装、実利用のperformance reportはまだ確認できません。海外mediaの反応は速いものの、developer adoptionが証明されたとは言えません。日本語では速報・翻訳が出始めた段階で、APIの使い分けと総原価をまとめた解説はまだ限られます。
この節の一次情報:9to5Mac|Opera One and Apple foundation model / Digital Trends|Opera WebAI / Thurrott|Opera brings local AI with WebAI
利用例と、導入に向くケース・向かないケース
向くのは、閲覧中textの分類、要約、翻訳、local search、privacy重視の補助機能です。ユーザーごとに大量の小さな判定を行うtab整理や記事rankingは、cloud token料金を避ける効果が出やすく、多少の端末差も許容しやすい用途です。offlineまたは不安定なnetworkで動かしたい場合にも候補になります。
向かないのは、全ユーザーへ同じ品質・速度・model versionを保証する必要がある処理です。契約、決済、医療、安全制御の最終判断をearly previewへ依存することや、low-end端末へ長いgenerationを強制することも避けます。browser非対応時に機能全体が停止する設計は採用せず、rule、cloud API、人手のfallbackを用意します。
- 向く:page内要約・翻訳・書換・校正
- 向く:tab、記事、求人、商品情報の分類とranking
- 向く:個人文書を外部providerへ送れないlocal search
- 向く:cloud request数が多いが1件ごとの判断が軽い機能
- 向かない:browserを問わず同じSLAが必要なcore workflow
- 向かない:高度なreasoning、長文生成、厳格なauditが必要な最終処理
制約・未検証事項
WebAIはearly previewであり、正式な標準化段階、API version、browser間互換性、長期support、料金、quota、model更新policyが未確定です。Operaが『GoogleとMicrosoftなどがbacking』と説明していても、各社browserが同じAPIを正式提供することを意味しません。product roadmapとstandard statusを分けて判断します。
modelのexact version、parameter、quantization、context length、download size、latency、energy、accuracyも公開情報が不足しています。端末で処理するためprivacy上の利点はありますが、pageやextensionが不要なdataへアクセスしない保証にはなりません。権限、Content Security Policy、extension review、local logを含むsecurity設計が必要です。
本番導入はfeature detectionから始め、利用可能な場合だけlocal処理を試します。shadow testでcloud baselineと結果を比較し、quality thresholdを下回る、timeout、resource不足、permission拒否ではfallbackします。local成功率とcloud削減額を継続計測し、単に『無料AI』と表示しないことが重要です。
FAQ
Q. WebAIは無料ですか? A. 2026年10月28日時点で、cloud APIのようなtoken単価は公表されておらず、Operaはper-request cloud costが不要と説明しています。ただし端末の電力、hardware、download、support、fallback APIのcostは残ります。
Q. ChromeやSafariでも動きますか? A. Operaのearly previewとして公開された機能です。APIの一部はChrome built-in AIと近いものの、同じcodeが全browserで動く保証はありません。feature detectionと代替経路が必要です。
Q. どのmodelを使いますか? A. OperaはGemmaと、Apple silicon MacではApple on-device foundation modelを例示しています。model-agnosticを掲げていますが、exact modelとavailabilityは端末・browser versionで確認します。
Q. cloudへdataは送られませんか? A. WebAIの推論対象は端末内で処理できると説明されています。ただしsite、extension、browserの他機能による通信やloggingは別問題です。network logとprivacy policyを検証してください。
Q. AI APIコストをすべて置き換えられますか? A. 現状は難しいです。軽い分類、要約、埋め込みから始め、複雑な処理、非対応端末、低信頼結果だけcloudへfallbackする構成が現実的です。
参考資料
料金・仕様は変更される可能性があります。導入時は各社の最新情報をご確認ください。