そのメモ、サーバーは要らない――ブラウザが持つ「本物のファイルシステム」とローカルファーストの代償
議論参加:ナオ (Web技術を取材する技術記者) / ハルト (ローカルファーストアプリを開発するエンジニア) / ミサ (データ保護とデジタル主権の研究者) / レン (SaaS企業のインフラ責任者) / カナ (現場業務システムの導入担当) / ソラ (アプリのデータ消失を経験した生活者代表) / テツオ (事実確認を担う編集者)
公開前の下書きです。事実確認と編集を終えていますが、公開・SNS投稿はまだ行っていません。
長年使ってきたメモアプリが、ある日サービス終了を告げてきた。エクスポート機能はなく、数年分の記録はサーバーの中に閉じ込められたまま消えていく――。アプリのデータ消失を経験した生活者代表のソラは、編集部の議論にこの体験を持ち込み、「私が本当に知りたいのは、技術的な同期の仕組みではなく、私のデータが『どこに、どのような形で、誰の管理下で』存在しているのかという、もっと直感的な納得感です」と語った。
この問いに技術的な答えを与えるのが、ブラウザがユーザーから見えない専用のファイル領域を持てるOPFS（Origin Private File System）というAPIだ。navigator.storage.getDirectory()という呼び出し一つで、Webページはそのオリジン（サイト）専用の高速なファイル置き場にアクセスできる。ここに、ブラウザ内で本格的なSQLデータベースを動かすSQLite WASM（SQLiteをWebAssembly化した実装）を組み合わせると、サーバーを介さずに端末の中だけでデータを読み書きする「ローカルファースト」なWebアプリが成立する。
結論：OPFS自体は2023年3月に主要ブラウザで使えるようになった、すでに枯れた技術であり、2026年に「新登場」したわけではない。今動いているのはその上に乗るSQLite WASM側で、2026年4月には新しい永続化の仕組みが追加された。ローカルファーストは、通信が不安定な現場やサービス終了への不安を抱えるユーザーにとって、データの主導権を取り戻す現実的な選択肢になりつつある。ただし、別途バックアップがなければ端末紛失でデータも失われる、複数端末間の同期は依然難しい、ブラウザのストレージ削除で消えるリスクがある、ブラウザ間の実装差が残る――という代償を、利用者自身が引き受ける設計でもある。
「新技術」ではない。枯れているのはOPFS、動いているのはSQLite WASM
Web技術を取材する技術記者のナオは、議論の冒頭でまずこの前提をただした。
「『OPFSは新技術だ』という認識は誤りです。2023年3月にBaselineとして広く普及した、すでに枯れた技術です。今議論すべきは、その基盤の上に構築されるSQLite WASMの進化です」（ナオ）
実際、MDNはOPFSの基本APIを「Baseline: Widely available」、2023年3月から主要ブラウザで利用可能と明記している。3年以上前から存在する、地味だが安定した技術だ。
2026年に入って動いているのは、その上で走るSQLite WASM側である。SQLite公式のリリース記録によれば、2026年4月9日公開のバージョン3.53.0で、新しい永続化ストレージの仕組み「opfs-wl」というVFS（仮想ファイルシステム）が追加された。Chrome公式ブログは、OPFSを土台にしたSQLite WASMでギガバイト級のクライアントサイドDBをネイティブに近い速度で扱えると解説しているが、これは無条件の性能保証ではなく、同時に開ける読み書きトランザクションが1つに限られるといった制約の中での話だ。
この時系列を整理すると次のようになる。
| 時期 | できごと | 位置づけ |
|---|---|---|
| 2023年3月 | OPFSの基本APIがBaseline「Widely available」に | すでに枯れた技術。今回の話の前提であり「新登場」ではない |
| 2025年9月22日 | SQLite WASMが64bitビルドに対応 | 周辺実装の拡張 |
| 2025年12月8日 | SQLite WASM「kvvfs v2」機能を追加（当初3.52.0で予定されたが延期・取り消しを経て3.53.0に統合） | 周辺実装の拡張 |
| 2026年4月9日 | SQLite WASM v3.53.0で新しい永続化VFS「opfs-wl」を追加 | 2026年に動いているのはここ |
表はsqlite.org公式のリリース記録（news.md）を基にした編集部の整理。OPFS仕様そのものが2026年に大きく変わったわけではない点に注意してほしい。
データが端末を出ない、という価値
なぜこの組み合わせが注目されるのか。ローカルファーストアプリを開発するエンジニアのハルトは、実装者の立場からこう語った。
「SQLite WASMが高速なのは事実ですが、ブラウザのストレージ削除や端末紛失によるデータ消失リスクは、クラウド型にはない課題です。そのため、同期ロジックの複雑さとバックアップ戦略が開発の成否を分けます」（ハルト）
現場業務システムの導入担当であるカナは、通信環境の悪い工場や災害現場を例に、この技術が現実に効く場面を具体的に描いた。
「通信が不安定な現場では、クラウド型は『送信中』のまま画面が固まり、作業者が入力した膨大なデータが消失するリスクが常につきまといます。これに対し、SQLite WASMとOPFSを活用したローカルファーストなら、入力した瞬間にローカルの高速なファイル領域へ確定されるため、作業の継続性が物理的に保証されます」（カナ）
同じ理屈は、通信の途切れる移動中の入力や、オフラインで動く家計簿・写真整理アプリにも当てはまる。データ保護とデジタル主権の研究者であるミサは、これをもう一段抽象化し、クラウドSaaSの事業モデルとの緊張関係として位置づけた。
「クラウドSaaSがユーザーのデータをサーバー側に閉じ込め、サービス終了とともにアクセス権を剥奪する『囲い込み』に対し、ローカルファーストはデータの主導権をユーザーの手元へ取り戻す試みです」（ミサ）
反論：主導権を取り戻す代償は、誰が払うのか
ここからが議論の核心である。SaaS企業のインフラ責任者であるレンは、この「主導権」という言葉の裏側を指摘した。
「ローカルファーストが標榜する『データの主導権』は、裏を返せば、データ管理の責任がユーザーの端末へと分散することを意味します」（レン）
インフラ責任者のレンは続けて、複数端末間の同期における不整合はインフラ設計上もっとも避けるべきリスクであり、一度失われたローカルデータはサーバー側のバックアップでは復元できないと述べた。さらに議論の終盤では、デバイスのハードウェア寿命という物理的な故障リスクにも触れ、「どれほど高度なエクスポート機能を備えていても、OSのストレージ管理やデバイスの突然の停止によって、エクスポート操作自体が不能になる事態は避けられません」と付け加えている。
事実確認を担う編集者のテツオは、この懸念を技術的な制約に落とし込んだ。
「Safari/iOSにおける実装差、特に同期アクセスハンドルがWeb Worker内でのみ利用可能であるという制約は、開発者が『どのタイミングで、どのコンテキストでデータの整合性を担保すべきか』という設計判断に直結します」（テツオ）
実装差の実情は次の通りだ。OPFSへの書き込みをストリーム形式で行うcreateWritable（非同期API）は、かつてSafariが長く非対応で、Web Worker内でのみ使える同期アクセスハンドル（createSyncAccessHandle）経由でしか書き込めない時期が続いた。現在はSafariも対応しており、createWritableは2025年9月にBaseline 2025（主要ブラウザ全体で利用可能）へ到達している。ただし対応から日の浅い環境が残ることや、Safariのプライベートブラウジングモードでは（本稿の取材時点の情報として）OPFS自体が利用できないとされることなど、周辺の挙動差はなお意識する必要がある。
| 項目 | Chrome / Edge / Firefox | Safari / iOS |
|---|---|---|
ストリーム書き込み（createWritable） | 対応 | 対応（2025年9月にBaseline到達。それ以前は長く非対応） |
同期アクセスハンドル（createSyncAccessHandle） | 対応 | 対応（ただしWeb Worker内限定） |
| プライベートブラウジング時の利用 | 概ね可能 | 不可 |
表はMDNの記述を基にした編集部の整理。「OPFSは全ブラウザで同じ挙動」という前提は今も禁物で、対応時期の新しい機能については、書き込みが失敗した場合の代替経路を用意しておくのが安全だ。
編集者のテツオが指摘したもう一つの論点は、OSのストレージ容量が不足した際、ブラウザがユーザーの明示的な操作なしにサイトデータを削除しうるという挙動だ。技術記者のナオはこれを受け、「OSの空き容量不足に伴うブラウザの自動クリーンアップは、ユーザーの意図に反してデータを消失させる『不可抗力なリスク』となり得ます」と述べ、クラウド型のサーバー障害とは性質が異なる問題だと整理した。
読者が確認すべきこと
議論を通じて浮かび上がったのは、「オフラインで動くかどうか」だけでは判断材料が足りないということだ。参加者の指摘を、読者が実際にアプリを選ぶ際の点検リストとして整理すると次のようになる。
| 確認する項目 | 何が分かるか |
|---|---|
| エクスポート機能があるか | サービス終了・端末故障時にデータを別の場所へ持ち出せるか |
| 複数端末間の同期方法 | 同期先が結局クラウドなら、サービス終了リスクからは逃れられていない |
| データの所在の明示 | 「このデータは端末内にのみ存在する」といった案内があるか |
| ストレージ逼迫時の挙動 | 書き込み失敗や消失を検知し、警告できる設計か |
表は編集部の議論を基にした整理であり、特定の製品を評価するものではない。
デモ：ローカルファーストのメモ帳を触ってみる
議論の要点を体感できるよう、編集部でOPFSを実際に使う簡易メモ帳を用意した。
このデモでは、navigator.storage.getDirectory()を使い、メモをこの端末のブラウザの中にファイルとして保存・一覧・削除できる。書き込みに失敗する環境では自動的にlocalStorageへ切り替わり、今どちらの方式で保存されているかを画面に明示する。またnavigator.storage.estimate()で、このオリジンが現在どれくらいのストレージを使っているかも確認できる。サーバーには何も送信されず、保存したメモはこの端末・このブラウザの中だけに存在する。ブラウザの設定でサイトデータを削除すると、メモも一緒に消える点は画面上で注意喚起している。
出典を読むときのポイント
- MDN「Origin private file system」：OPFSの基本APIが2023年3月からBaseline「Widely available」であること、Safari/iOSの実装差を確認した。
- SQLite公式リリース記録（news.md）：2026年4月9日のv3.53.0での「opfs-wl」VFS追加、直近のバージョン変遷を確認した。
- Chrome for Developers公式ブログ「SQLite Wasm in the browser backed by the Origin Private File System」：OPFSベースのSQLite WASMの性能に関する解説を確認した（条件付きの記述であり無条件の性能保証ではない）。
- SQLite WASM公式リポジトリ（sqlite/sqlite-wasm）：実装・配布の状況を確認した。
キーワード:#OPFS#ローカルファースト#SQLite WASM
コメント
まだコメントはありません。