Smashing Magazine が 2026 年 5 月 6 日に The Architecture Of Local-First Web Development を公開しました。Local-First（ローカルファースト）と呼ばれるアーキテクチャパターンが、CRDT（Conflict-free Replicated Data Type）系ライブラリの成熟と Web Standards の進化で 「研究テーマ」から 「受託で実装可能な実装スタック」に格上げされたことを、実装事例ベースで整理した記事です。
弊社では、業務 SaaS 受託案件で 「営業先で電波が無くて使えない」「現場の地下で同期が切れる」といった現実問題に頻繁にぶつかります。本記事では、Local-First Web アーキテクチャを受託案件で採用するときの設計指針、実装スタック、契約条項を整理します。
何が “Local-First” なのか — 4 つの構造原則
Smashing の記事から、Local-First の定義を受託で扱える形に整理しました。
| 原則 | 内容 | 受託案件での意味 |
|---|---|---|
| ローカル優先 I/O | データの読み書きはローカル DB が一次情報源 | オフラインでも全機能が動く |
| 同期は非同期 | サーバとの同期はバックグラウンドで | UI が止まらない |
| 競合解決 (CRDT) | 複数端末の同時編集を自動マージ | “上書き戦争” が消える |
| エンドツーエンド永続性 | サーバが落ちてもデータは消えない | 業務継続性が上がる |
特に **「ローカル優先 I/O」が思想の中心で、「サーバが応答しなくてもアプリは普段通り動く」**という体験を、業務 SaaS にも持ち込めるようになった点が画期的です。
これは Hono + Cloudflare Workers で構築するエッジ API 基盤 で扱った “エッジコンピューティングで遅延を削る” という流れの 次のステップにあたり、「クライアント側にデータベースを持つ」ことで遅延を 0 にする発想に近づきます。
受託で組む Local-First スタック 4 階層
受託案件で Local-First を採用する場合、実装スタックは以下の 4 階層で整理すると設計が進めやすくなります。
[Tier 1: ローカルストレージ]
├ IndexedDB を直接 / または Dexie.js でラップ
├ Origin Private File System (OPFS) で大容量
└ SQLite WASM で本格的な RDB 操作
[Tier 2: 同期エンジン]
├ Yjs / Automerge で CRDT 同期
├ ElectricSQL / Cloudflare D1 同期
└ 自社実装の場合は Operational Transform
[Tier 3: 認証 / 認可]
├ JWT をローカル保存 + リフレッシュ
├ オフライン中の権限変更を競合解決
└ デバイス紛失時のリモート無効化
[Tier 4: 同期可視化]
├ "未同期" バッジを UI に常時表示
├ 同期失敗時のユーザー通知
└ 強制再同期ボタンの設置特に Tier 4 の “未同期” 表示は 「データが手元にあるのに同期されていないことを知らせる」重要な UX で、これを抜くと 「自分は保存したつもりが、他端末に反映されていなかった」事故が起きます。
これは 現場の Excel が限界を迎えたら — AppSheet で業務アプリ化する受託の勘所 で扱った 「現場はスマホを持って各拠点を回るのに、記録は事務所に戻ってから転記する」という二重運用の課題と地続きです。あちらはノーコードで作り直す道筋でしたが、そもそも通信が切れる現場を前提に置くなら、Local-First は同じ二重運用を設計レベルで断つ選択肢になります。
受託契約に書く「Local-First 運用条項」
Local-First を採用した受託案件で契約に明記すべき条項です。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| オフライン稼働範囲 | どの機能がオフラインで動くか | 業務上の必要範囲 |
| 同期 SLA | 再接続後 N 分以内に同期完了 | 業務上の許容時間 |
| 競合解決ポリシー | 同時編集時の優先順位 | 業務ルールとの整合 |
| ローカル DB 暗号化 | 端末紛失時の保護 | 機微データの扱い |
| データ保持期間 | ローカルに何日保持するか | 法規制との整合 |
| デバイス無効化 | リモート無効化のトリガー | セキュリティ運用 |
特に **「ローカル DB 暗号化」は最初に明文化しないと、「端末紛失で個人情報流出」**事故になります。OPFS + Web Crypto API で暗号化保存することを契約条件に組み込んでおくべきです。
これは ソースコード secrets 監査を受託で運用する で扱った “受託のセキュリティ責務” の延長で、「クライアント側にデータがある」という構造変化に対応する条項を追加で明記する必要があります。
ハマりやすい 5 つの落とし穴
最後に、Local-First を受託で取り込むときに踏みやすい落とし穴を共有します。
落とし穴 1: 全機能オフライン化を最初から狙う
「全機能を Day 1 でオフライン対応」にするとスコープが破綻します。業務上の必須 20% をまず Local-Firstにし、残りはオンライン専用で出すのが受託の現実解です。
落とし穴 2: CRDT を自前で作る
CRDT は理論上美しいですが 自前実装は地獄です。Yjs / Automerge / ElectricSQL のいずれかを必ず採用し、自前実装は避けます。
落とし穴 3: ローカル DB のスキーマ変更
オフライン端末に古いスキーマのデータが残った状態で、サーバ側を変更すると 競合解決が壊れます。スキーマバージョンをクライアント側に持ち、起動時に強制マイグレーションを入れます。
落とし穴 4: 同期可視化を作らない
「未同期データがあること」を UI に出さないと、ユーザーが 「保存したつもり問題」を起こします。画面上部に常時バッジを出すのが UX 上の鉄則です。
落とし穴 5: 暗号化を後回し
「とりあえず動かしてから暗号化を入れる」は事故の元です。最初の MVP からローカル DB を暗号化し、後から対応にしないこと。鍵管理は WebAuthn / Passkey に寄せると運用が楽になります。
まとめ — 「ネット必須」から「現場で止まらない SaaS」へ
Smashing Magazine の記事は、**「Local-First は受託で実装可能な実装スタックになった」ことを実装事例ベースで示しました。業務 SaaS 受託の世界では、「ネット必須」を前提にした設計が、現場・移動中・通信不安定環境で 「使い物にならない」**評価を受ける時代に入っています。
「営業先で電波が無くて業務が止まる」「地下や現場で同期が切れて使えない」という声が現場から上がっているなら、次にやるべきことは全機能のオフライン化ではありません。落とし穴 1 で書いたとおり、まず 「電波が無い場所で止まると本当に困る業務はどれか」を絞り込むことです。ここが定まらないまま話を進めると、Tier 2 の同期エンジンをどこまで作り込むかも、契約に書く同期 SLA と暗号化の水準も決められず、要らないオフライン化に工数が流れていきます。既存 SaaS の一部を後付けでオフライン化するのか、Local-First 前提で組み直すのかによっても、必要な設計は別物になります。その切り分けからご一緒できますので、いま現場で止まっている業務の話を お問い合わせフォーム にお聞かせください。
