ブラウザはなぜPDF処理やAIまで動かせるのか。File API、IndexedDB、WebAssembly、WebGPUなど、15年以上の技術の積み重ねを一次資料から整理します。
目次（7）
昔のWebブラウザには、「Webページを見るためのソフト」という印象がありました。
もちろんJavaScriptは昔からあり、フォームやアニメーション、簡単なゲームも動いていました。それでも、重い処理やファイル編集、データベース、動画編集のような仕事は、基本的にデスクトップアプリ側の領域だと思っていました。
ところが今はかなり違います。
ブラウザだけでPDFを編集し、画像を圧縮し、SQLiteを動かし、動画を処理し、機械学習モデルを端末上で実行することまでできます。ツールによっては、ファイルをサーバーへアップロードせずに処理を完結させることもできます。
自分でもブラウザ完結のツールを作っていると、「そもそも、いつからブラウザはこんなことまでできるようになったんだろう」と気になりました。
調べてみると、答えはWebAssemblyひとつではありませんでした。
ファイルを読む、状態を保存する、裏で処理する、ネットがなくても動く、高速なコードを実行する、GPUを使う。そうした能力が15年以上かけて積み重なった結果が、今のブラウザです。
先に結論：ブラウザは「小さなOS」ではなく、OS機能への安全な窓口を増やしてきた
今のブラウザを単なるHTMLビューアとして考えると、できることが多すぎて不思議に見えます。
でも構造を分けると理解しやすくなります。
現在のブラウザには、ユーザーが選んだファイルを読む仕組み、端末内にデータを保存する仕組み、バックグラウンドで計算する仕組み、高速なバイナリコードを実行する仕組み、GPUへ計算を投げる仕組みがあります。
一方で、普通のネイティブアプリのようにPC全体へ自由にアクセスできるわけではありません。
ファイルを触るにはユーザー操作や権限が必要で、WebAssemblyはサンドボックス内で動き、WebGPUもGPUドライバを直接操作するのではなくブラウザが提供するAPIを通します。
つまりブラウザはOSそのものになったのではなく、OSの能力を安全なAPIへ変換し、Webアプリへ少しずつ公開してきた実行環境と考える方が近そうです。
ブラウザが最初に獲得したのは、「手元の状態を扱う力」だった
高性能な計算以前に、アプリとして成立するには手元のファイルや状態を扱えなければなりません。
今振り返ると、ブラウザが「表示する場所」から「作業する場所」へ変わる土台は、このあたりから作られていました。
File APIで、ローカルファイルをブラウザ内から読めるようになった
PDFや画像をブラウザ内で処理するには、まずファイルの中身をJavaScriptから読めなければ始まりません。
現在のFile APIでは、ユーザーが選択したファイルを File や Blob としてJavaScriptから扱えます。
W3Cの公開履歴を見ると、File APIの仕様検討は2000年代半ばまで遡ります。
この仕組みがあることで、ブラウザは単に「ファイルをサーバーへアップロードするための入力欄」ではなく、ユーザーが選んだファイルを端末内で読み、その場で処理する場所にもなれました。
ここには誤解しやすい点があります。
<input type="file"> でファイルを選んだからといって、自動的にサーバーへ送信されるわけではありません。JavaScriptで読み込み、端末内だけで処理して終える実装もできます。
逆に、File APIを使っているから「送信されない」とも限りません。読み取った後にAPIへ送るコードを書くこともできます。
ファイルを読めることと、処理場所がローカルかどうかは別問題です。
参考：W3C File API
参考：W3C File API publication history
IndexedDBで「ページを閉じたら全部消える」状態から抜けた
ファイルを一時的に読むだけでは、ページを閉じれば状態が消えてしまいます。
アプリらしくするには、作業状態を端末へ残す必要があります。
その代表がIndexedDBです。
IndexedDBはブラウザ内に構造化データを保存できるデータベースAPIで、W3Cでは2009年にWorking Draftが公開され、2015年にRecommendationになっています。
これによってWebアプリは、原稿、キャッシュ、ユーザー設定、検索用データなどをローカルへ保持できるようになりました。
「Webアプリは毎回サーバーから状態を取り直すもの」という前提が、ここで少しずつ崩れていきます。
参考：W3C Indexed Database API publication history
Web Workersで、重い処理を画面から分離できるようになった
JavaScriptで重い処理をそのまま実行すると、画面操作まで固まることがあります。
Web Workersを使うと、ページ本体とは別のWorkerで処理を動かせます。W3Cの初期Working Draftは2009年です。
今では当たり前に見えますが、これはかなり重要です。
画像変換、ファイル解析、検索インデックス作成、暗号処理、AI推論のような仕事をメイン画面から分離できるからです。
「計算できる」だけでなく、計算しながらアプリとして操作できるようになりました。
参考：W3C Web Workers, 2009 Working Draft
Service Workerで、Webアプリはネットワークが切れても成立し始めた
ネイティブアプリとWebサイトの大きな違いとして、昔は「ネットが切れたら使えない」がありました。
その差を縮めた技術の一つがService Workerです。
Service WorkerはWebアプリとネットワークの間に入り、リクエストを処理したり、キャッシュ済みのデータを返したりできます。W3Cでは2014年に最初の公開Working Draftが出ています。
これによってWebアプリは、「毎回サーバーから全部取得するページ」から、アプリ本体や必要なデータを端末側にも持ち、ネットワーク状態に応じて振る舞えるソフトウェアへ近づきました。
PWAがアプリらしく見える理由は、ホーム画面へ置けることだけではありません。オフライン動作や端末内の状態管理まで含めて、Web側の責任範囲が広がったことの方が本質に近いと思います。
次に起きたのは、「ネイティブ向けの重い処理」をWebへ持ち込める変化だった
ファイルを読み、状態を保存し、裏で処理できても、JavaScriptだけでは持ち込みにくい計算資産があります。
PDF処理、動画コーデック、画像変換、SQLite、科学計算、機械学習。こうした世界との距離を一気に縮めたのがWebAssembly、その先でGPU計算まで開いたのがWebGPUでした。
WebAssemblyで、C/C++やRustの計算資産がWebへ近づいた
WebAssembly（Wasm）は、Web向けの高速なバイナリ命令形式です。
公式のHigh-Level Goalsでは、幅広いハードウェア上で高い実行性能を引き出せるポータブルなコンパイルターゲットを目標にしています。
重要なのは、「JavaScriptを速くする技術」というより、C/C++やRustなどで書かれた既存の計算資産をブラウザへ持ってきやすくしたことです。
公式Use Casesを見ると、設計時点から画像・動画編集、ゲーム、音楽、画像認識、VR/AR、CAD、科学計算などが挙げられていました。
2017年には主要ブラウザで初期MVPの実装経験が揃い、WebAssembly 1.0は2019年にW3C Recommendationになりました。
これによって、ネイティブ環境向けだったPDFライブラリ、画像処理ライブラリ、SQLite、圧縮処理などをWebへ持ってくる選択肢が現実的になりました。
最近、ブラウザだけでPDF編集や画像処理ができるサービスが増えた背景には、この変化がかなり効いています。
参考：WebAssembly High-Level Goals
OPFSによって、Webアプリ専用の「ファイルシステム」まで持てるようになった
さらに最近の変化として面白いのがOPFS、Origin Private File Systemです。
これはWebアプリ専用のローカルファイル領域で、通常のファイルとしてユーザーから直接見える場所ではありません。
MDNでは、OPFSはパフォーマンス向けに最適化され、ファイル内容へのin-place writeもできるストレージとして説明されています。2023年3月以降、主要ブラウザで広く利用可能になっています。
なぜ重要なのか。
SQLiteのように大量のランダム読み書きを行う処理に向いているからです。
Webページを開いたら、ブラウザ内にアプリ専用のファイル領域があり、その上でSQLiteまで動く。ここまで来ると、かなりデスクトップアプリに近い構造になります。
参考：MDN Origin private file system
WebGPUで、ブラウザはGPUを「描画以外の計算」にも使えるようになった
そして現在のブラウザをさらに変えているのがWebGPUです。
WebGPUは、WebアプリからGPUの描画機能だけでなく、汎用的な並列計算能力へアクセスするためのAPIです。
Chromeでは2023年のChrome 113からWebGPUがデフォルトで利用可能になりました。当時Chromeチームは、高性能3Dグラフィックスだけでなく data-parallel computation、つまりGPUを使ったデータ並列計算も特徴として挙げています。
W3Cの仕様でも、WebGPUはGPU上でレンダリングや計算を行うためのAPIと定義されています。
ここでAIとつながります。
機械学習の推論は、大量の行列計算を並列に処理します。WebGPUを使えば、対応するモデルやランタイムではその処理を利用者のGPU側へ持っていけます。
つまり「AIを使う＝必ずサーバーのGPUへデータを送る」という構造ではなくなり始めています。
参考：W3C WebGPU
WebAssemblyとWebGPUは競合ではなく、担当する計算資源が違う
この2つはどちらも「ブラウザで高速処理する技術」と説明されるので、最初は近いものに見えます。
でも役割は違います。
WebAssemblyは主にCPU上で効率よくコードを実行するためのポータブルな実行形式です。
WebGPUはGPUへ描画・計算処理を投げるためのAPIです。
競合ではなく、むしろ組み合わせるものです。
ブラウザ内AIでも、端末や処理内容に応じてWebGPUを使い、CPU向きの処理やフォールバックではWebAssemblyを使う構成があります。
「WasmがGPUを使えるようにした」のでも、「WebGPUがWasmを置き換える」のでもありません。
ブラウザは、CPU・ストレージ・GPUといった異なる資源へアクセスする窓口を、それぞれ別の層で増やしてきました。
ここまで高機能になっても、WebページがPC全体を自由に触れないのはなぜか
ファイル、データベース、CPU、GPUまで利用できるなら、普通に考えるとかなり危険です。
ブラウザの進化で重要なのは、能力を増やすと同時に直接触らせない設計を維持してきたことです。
サンドボックスと権限が「強い機能」を囲っている
WebAssemblyの公式目標には、メモリ安全なサンドボックス環境で動作し、Webへ組み込む場合はブラウザのsame-originやpermission modelに従うことが明記されています。
ユーザーの通常ファイルへアクセスするAPIも、原則としてユーザーが対象を選ぶ、あるいは権限を与える必要があります。
WebGPUも、JavaScriptからGPUドライバへ自由な命令を投げる仕組みではありません。ブラウザがAPIを仲介し、検証や制約を挟みます。
この構造があるからこそ、Webページへかなり強い機能を渡せます。
ブラウザが高機能になったというより、危険なOS機能を直接公開せず、安全な窓口を少しずつ増やしてきたと見る方が正確です。
だから「ブラウザ完結」という設計が現実的になった
ここまでの技術をつなぐと、最近ブラウザ完結ツールが増えている理由が見えてきます。
File APIでファイルを読み、IndexedDBやOPFSへ状態を持ち、Workerで重い処理を分離し、Service Workerでオフラインに対応する。さらにWebAssemblyで既存の処理資産を動かし、必要ならWebGPUへ計算を渡す。
以前なら「サーバーへアップロードして処理するしかない」と思っていた仕事でも、現在は利用者の端末へ計算を戻せるケースがあります。
ブラウザ側へ戻しやすい処理
PDFの結合、画像圧縮、Markdown変換、簡単なOCR、検索インデックス、軽量なAI推論のように、入力と結果を1人の端末内で完結できる処理は相性が良いです。
ファイルを外部へ送らない設計にできれば、サーバーコストだけでなくプライバシー上の通信経路も減らせます。
実際にブラウザ完結ツールがどこまで「送信しない」と確認できるかは、ブラウザだけで動くツールを自分で確かめる方法でも整理しています。
それでもクラウド側に置く理由は残る
もちろん何でもブラウザに向いているわけではありません。
巨大なAIモデル、高い計算資源を要求する処理、複数利用者で共有するデータ、中央で一元管理すべき業務、端末スペックに結果を左右されたくないサービスでは、クラウド側に処理を置く理由があります。
「ブラウザでできるようになった」と「ブラウザでやるべき」は同じではありません。
技術的に選択肢が増えたことが重要です。
一番面白かったのは、1つの革命ではなく「地味なAPIの積み重ね」だったこと
最初は、JavaScriptが速くなったか、WebAssemblyが登場したからブラウザアプリが増えたのだと思っていました。
もちろんそれらも大きな要因です。
でも調べてみると、ブラウザは約15年以上かけて、OSが持つ能力を一つずつ安全な形へ変換してWebへ持ち込んでいました。
ファイルを読む。状態を保存する。別スレッドで処理する。オフラインでも動く。既存の計算資産を実行する。専用ストレージを持つ。GPUで計算する。
一つ一つだけなら地味な機能です。
しかし全部が揃うと、その上にかなり本格的なアプリを作れます。
Webサイトとデスクトップアプリの境界は、もうかなり曖昧になっている
今でもネイティブアプリにしかできないことは大量にあります。
それでも利用者から見た境界は小さくなっています。
URLを開いたら、その場で大きなデータを扱い、ローカルDBを読み書きし、オフラインでも動き、GPUでAIを推論する。処理が終わったらタブを閉じるだけです。
これは20年前の「ホームページを見る」というブラウザ像からはかなり遠いところまで来ています。
最近、自分がブラウザ完結の小さなツールを作ることが増えたのも、この変化が大きいと思います。
Webならインストール不要でURLだけ渡せる。そのうえ、処理内容によってはファイルをサーバーへ預ける必要もない。
最初は「なぜブラウザでPDFやAIまで動くのか」という疑問でした。
調べ終わってみると、答えは一つの革新的な技術ではありませんでした。
Webは長い時間をかけて、OSの機能を安全なAPIとして少しずつ取り込み続けてきた。
今の高機能なブラウザは、その積み重ねの結果なのだと思います。
このテーマ以外の調査記事は、WebとAIを調べてみた記事一覧から確認できます。