- ローカルファースト・ソフトウェアは、クラウドベースのコラボレーションと個人データ所有権の利点を同時に実現しようとするアプローチである
- 既存のクラウドアプリはリアルタイムコラボレーションとアクセシビリティに優れているが、データ所有権や長期的なアクセス性といった問題を引き起こす
- ローカルファースト・ソフトウェアは、ローカルストレージをデータの基本的な保存場所と見なし、同期やコラボレーション機能を付加的に提供する
- このようなソフトウェアは、速度、オフライン対応、プライバシー、ユーザーコントロールなどで利点を提供する一方、リアルタイムコラボレーションやマルチデバイス同期などでは実装難易度も存在する
- ローカルファースト・ソフトウェアを現実のものにするため、さまざまな既存技術モデルが比較・分析されており、将来的にはさらに理想的なモデルが開発される可能性が模索されている
クラウドアプリとデータ所有権の限界
- ほとんどのユーザーは、Google Docs、Figma、Slack など、さまざまなクラウドアプリを通じて文書作成、設計、コラボレーションなどに活用している
- こうしたサービスはブラウザまたはモバイルアプリを通じて利用され、その多くはサーバーにデータを保存する
- クラウドベースのソフトウェアは、コラボレーションやどこからでもデータにアクセスできるという利点を持つが、アプリに時間を投資するほどその中のデータ価値は大きくなる
- 専門家へのインタビューを通じて、クラウドアプリの機能的な利点の裏側に、所有権の喪失、長期アクセス性の不確実性といった致命的な欠点があることが確認された
- ユーザーが自ら創作または生産した資料やデータを保存・所有する権利が制限されるという点で、心理的な不安と実際的なリスク要因が存在する
データを本当に所有するとは何か
- クラウドに保存されたデータは「自分のもの」のように見えても、実質的な管理・アクセス制御権限はクラウドサービス提供者にある
- サービス停止やサーバー障害の際には、データにアクセスできなくなることや長期的なデータ保存の困難を招く
- 実際の知的財産権そのものではなく、ユーザーが感じるデータの所有感と制御力こそが問題の核心である
- ローカル保存中心の昔ながらのアプリケーション（テキストエディタ、バージョン管理、各種ツール）は、完全なデータ所有権と自律性を保証する
クラウドとローカルの長所と短所の比較
- 「クラウドアプリ = コラボレーション・アクセシビリティ」「ローカルアプリ = 所有権・自律性」
- 二者択一ではなく、ハイブリッド方式による最善の組み合わせを追求する必要性が提起される
- データ所有権とリアルタイムコラボレーション性は相反するものではなく、両方を達成できるソフトウェアモデルは設計可能である
- これをローカルファースト・ソフトウェアと定義し、ローカルストレージ・ネットワークと補助的なサーバーの組み合わせを基本構造として提案する
ローカルファースト・ソフトウェアの7つの理想
- クラウドアプリではサーバーがデータの「正本」として機能するため、あらゆるリクエストでサーバー往復が必要になり、ユーザー体験の遅延が発生する
- 一方、ローカルファースト・ソフトウェアはローカルストレージ上のコピーをデータの基本バージョンとして扱い、（サーバー経由の）同期は副次的に処理する
- この視点の転換は、応答速度、オフライン対応、データ制御権などにおいて実質的な利点をもたらす
1. 速度（高い応答性）
- ローカルファーストアプリはすべての作業をローカルファイルシステムで処理するため、サーバー応答待ちの遅延なしに即時のユーザー応答性を実現できる
- 同期はバックグラウンドで静かに処理されるため、どの瞬間でもユーザー体験が中断されない
2. マルチデバイス同期
- 現代のユーザーは複数のデバイスで作業するため、ローカルファーストアプリでもデバイス間のデータ同期が必須である
- ファイル単位の同期は単独ユーザーであれば容易だが、多人数による同時編集ではコンフリクトの問題が発生する
3. オフラインファースト性
- ローカルファースト・ソフトウェアでは、オフライン状態でもデータの作成や編集がいつでも可能で、後からネットワークに復帰した際に自動で同期される
- Bluetooth、ローカル WiFi などさまざまな方法で、デバイス間のデータ共有や同期が可能である
- 真のオフライン対応のためには、ローカルインストール型の実行ファイルという形態が好ましい
4. コラボレーションとコンフリクト管理
- 従来の方式（メール添付、バージョン管理ツールなど）では、複数人が同じファイルを同時に扱う際に競合や手動マージの不便さがある
- クラウドアプリ（Google Docs など）は、リアルタイム同時編集機能によってコラボレーションの難しさや衝突を最小化する
- ローカルファースト・ソフトウェアにも、リアルタイムコラボレーション、変更提案と承認など多様な協業フローを実装できる可能性があり、技術的挑戦領域でもある
5. データの長期保存
- ローカルファーストアプリを使えば、ソフトウェア開発元がなくなってもデータへのアクセス権が保証される
- 一般的なファイル形式（テキスト、PDF、JPEG など）は長期間互換性を保ちやすく、互換性のないフォーマットであっても仮想マシンやエミュレーターでアクセスできる
- データの真の長期保存がなければ、デジタル暗黒時代の問題（未来の人類が今日のデータにアクセス・解釈できないこと）が現実になる可能性がある
6. プライバシーとセキュリティ
- クラウドの中央集権型構造は、ハッキングや内部従業員による悪用など、さまざまなセキュリティ事故に脆弱である
- 個人情報や機密データなどを扱う専門家は、ローカルファースト構造においてエンドツーエンド暗号化によるセキュリティとデータ独立性を確保できる
- Google などの大企業は内部的にデータをさまざまな方法で活用できるが、ローカルファースト・ソフトウェアはデータ主体に制御権を与える
7. ユーザーの所有権と制御権
- クラウドサービス事業者によって、データへのアクセスが任意に遮断・制限される可能性がある（誤った自動フラグ付け、ポリシー変更など）
- ローカルファースト環境では、データの利用や修正、バックアップ、保管など、あらゆる権利をユーザー自身が決定する
- これは単なる法的著作権ではなく、ユーザーの実質的な自律性とデータ制御権の問題である
さまざまなソフトウェアモデルの比較
- メール添付 + ローカルファイル: 速度、オフライン、長期保存、制御権には優れるが、コラボレーション、デバイス同期は不便
- クラウド Web アプリ（Google Docs、Trello など）: リアルタイムコラボレーション、アクセシビリティには優れるが、速度、オフライン、所有権、プライバシーは弱い
- ファイル同期サービス（Dropbox など）: 速度、オフライン、長期保存、制御権には優れるが、コラボレーションやモバイル環境に限界がある
- バージョン管理システム（Git など）: 速度、オフライン、長期保存、制御権に優れるが、非テキストファイルやリアルタイムコラボレーションには弱い
- モバイルクライアント（Firebase、CloudKit など）: 同期、オフラインに強みがあるが、個人情報、プライバシー、長期的なサービス存続などに限界がある
- マルチマスター複製方式（DB、例: CouchDB）: オフラインと同期に強みがあるが、コラボレーション、プライバシー、制御権など理想の実現は難しい、または不十分
ソフトウェア開発者の視点と今後の方向性
- 理想的なローカルファースト・ソフトウェアは、初期段階からオフライン、マルチデバイス同期、リアルタイムコラボレーション、プライバシー、ユーザー制御を設計・実装しなければならない
- しかし現実には、すべての理想を同時に満たす公開技術はまだ存在しない
- 最新のコンピューターサイエンス研究で考案された新技術（例: Conflict-free Replicated Data Types（CRDTs）、分散データ同期方式など）が、将来のローカルファースト・ソフトウェア実現の中核的基盤になり得る
結論
- ローカルファースト・ソフトウェアは、デジタル時代のコラボレーション性と独立性、プライバシー、そしてデータ主権のバランスを実現できる重要な方向性である
- 専門家やクリエイターなどに、データに対する所有感と長期的な保護を提供し、さらに産業全般にわたって前向きな変化を生み出すことが期待される
- 今後は、こうした理想を実現するより良いインフラと開発ツール、アーキテクチャ、アルゴリズムの研究・実験が継続して必要である
1件のコメント
Hacker News のコメント
本当に100%共感する。自分もこうした問題を解決するために開発していて、自分の情報をクラウドに入れて購読料だけ払い続ける方式にはうんざりしている。今は fitness tracking アプリを作っていて、Sublime モデルを適用する予定。最初に一度購入し、数年間アップデートを提供し、すべてのデバイスと同期し、生涯使える。その後アップデートが欲しければ新バージョンを買い直せば十分。十分に良い品質なら、そのままずっと使い続けられることを目指したい。全ソフトウェアのうち90%はこのモデルが望ましいと思う。適正価格で買えて、製品そのものが良く、クラウド連携がなくてもしっかり動く構造が重要。データプライバシーだけでなく、このモデルには多くの利点がある。まだツーリングなど課題は残っているが、技術的基盤は十分にある。local-first ソフトウェアの最大の利点は、健全なインセンティブ構造にあること。広告・ユーザートラッキング・「エンゲージメント」最大化ではなく、製品そのもので報われる構造だからだ。本当にユーザー中心のソフトウェアだと感じる。
Obsidian のノートアプリのモデルも本当に良い手本。クライアントは無料で、同期サービスはオプションとして販売されている。ノートは Markdown ファイルなので、クライアントが必須ではない点も強み。
クラウドインフラを使わずに、同期処理はどう計画しているのか気になる。
完全に同感。もし差し支えなければ、その fitness tracking アプリの tech stack も知りたい。特にクロスデバイス同期をどう処理しているのか気になる。
広告で収益化する純ローカルアプリも多いので、「広告を付けない」が常に成り立つわけではない。
今ベルリンで Local-first Software カンファレンス(https://www.localfirstconf.com/)が Ink and Switch 主催で活発に開催されていて、今年11月にはサンフランシスコで Sync Conf(https://syncconf.dev/)まで始まる。最近のカンファレンスでは論文の共著者たちが直接パネル討論も行っており、local-first ソフトウェアの開発ツールという文脈で学んだことを語っていて有益だった。パネル討論動画は強くおすすめしたい。今コミュニティでは「Sync」が local-first の中核要素として定着しつつあり、同期エンジンのような dev tool は local-first の特性を支えるツールであって、それ自体が local-first なのではない、という流れになっている。ここ数年の講演全体のまとめもここにアップロードされている。リアルタイム・非同期コラボレーション支援ツールの開発が非常に活発に進んでおり、最近の AI の登場によって、こうした同期エンジンがますます必要とされる市場環境が生まれている。AI アプリは本質的にマルチユーザーの協業環境なので、同期エンジンコミュニティの技術基盤が求められる時代になっている。
このテーマについては以前にも非常に活発な議論があったので、興味があれば読む価値がある: 2019-05, 191 コメント
2019-11, 241 コメント
2020-07, 9 コメント
2020-08, 134 コメント
2021-02, 90 コメント
2022-06, 30 コメント
2023-10, 50 コメント
すべてのアプリがそれぞれ独自の sync プラットフォームを持つ必要はない、という主張。これはモバイルアプリ特有の、プログラム間の組み合わせやモジュール化のしにくさから来ているように思える。本当に local-first を望むならファイルシステムを使えばいい。ユーザーの立場では、git や box など既存のさまざまなソリューションを自分で選べばよい。各アプリごとの sync 登録手続き自体が SaaS と同じくらい不透明で壊れやすく、負担になる。
すべてのアプリに sync エンジンが必要ないという点には同意するが、ファイルシステムが local-first の万能解だとは思わない。理由は2つある。1つ目は concurrency。本当に local-first だけでよいならどんな sync でも構わないが、それ以上を求めている。たとえば妻と2人で通信不能な状況でも、それぞれのスマホで独立に編集し、それが自動でうまくマージされる体験が欲しい。DropBox のような本当に自然な同期を期待している。2つ目は、データ構造や意味を同期エンジンが深く理解してこそ、より良い sync 体験を実現できること。git や box には、こうした意味的な同時編集の要求の前では多くの限界がある。
実際にファイルシステムだけを使う方式を実装してみたが、いつファイル編集を許可するかをクライアント間で調整するのが難しく、結局ファイル衝突の問題は避けられなかった。
オンライン依存性を持つシステムは、必然的に維持・運用コストを伴う。local-first、local-only 設計でなければ、長く信頼できるシステムにはならない。接続型の家電や自動車類は、実用性の観点から本当にばかげたエンジニアリングの例だ。
自分はむしろ、クラウドの信頼性問題を技術的に（中央集権的構造を避けることで）解こうとする見方には批判的だ。以前は閉鎖的ソフトウェアの制御不能・信頼不能の問題を、ビジネスモデル（オープンソース開発、保守契約など）で解決してきた。クラウドの問題にもこうしたビジネスモデル上の解決策が必要だと思う。たとえば標準契約やライセンスを作ってユーザーの権利を明記し、そうした認証ライセンスを実施するベンダーだけを選ぶよう市場を誘導できる。ユーザーのデータ移行保証、透明なデータ利用履歴の公開、サービス終了時の対応手順の明示など、多くの条項を追加できる。もちろん最大の難関は、なぜベンダーがそんな制度を受け入れるのかという点だ。ベンダーは顧客離れを恐れるので、こうしたライセンスを提供する代わりに年次サブスクリプションのみを認めたり、追加費用を要求したりする可能性がある。
ビジネスや政治の問題を技術的解決で対処できるなら、その方がむしろ堅牢な方法だと思う。敵対する利害関係を技術的に封じられるからだ。代表例が暗号化（client-side encryption）。プライバシーポリシーや官僚的なルールに頼るには誘惑が多すぎるし、監視や摘発も難しい。もしデータが数学的にサーバー側で読めないよう暗号化されていれば、心配事は消える。ただしサーバーでデータを実際に処理したい場合には、実際には自分のサーバーを使わなければならない状況になる。
たとえば終了時の契約などで解決するとしても、クラウドサービス業者が廃業して通知し、データを書き出してくれたとしても、結局手元に残るのは巨大な JSON ファイルだけ。自分でアプリを作るか、誰かが作ってくれない限り、実質的には役に立たない。意図は良いが、寿命の尽きたアプリのデータを長期的に使い続けられるローカルアプリに比べると見劣りする点がある。
データ移行保証条項も、実際の大規模なデータ移転は現実的に難しく時間もかかる。危機的状況で急いでやればなおさらひどくなる。同じバージョンのオープンソース DB 同士ですら、サービスごとに変数が多くて簡単ではない。結局、データを最初から自分の環境に保管し、必要になったら「アンプラグ」できる構造が現実的な代替策になる。BYOC（Bring Your Own Cloud）とオープンソースの組み合わせもあり得る。私たちの会社でも BYOC データ製品を運用しているので、この構造が実際に可能だと実感している。
クラウドサービス終了時に契約書で責任を明記しても、いざ廃業が決まったときに、それを実際に執行し管理する方法があまり思い浮かばない。
ビジネス上の問題だけでなく、データ安全性そのものも問題だ。サブスクリプションやクラウドモデルを避ける主な理由は、自分のデータを守りたいからだ。ローカル暗号化なしで送信されるデータは、本当にいつでも漏えいし得る。
この記事を読むと新鮮な気持ちになる。もっと多くのアプリが local-first になるべきだと思う。ユーザーがクラウド同期を望まないなら、その選択肢は必ず保証されるべきだ。自分が作っている Brisqi(https://brisqi.com) も、こうした offline-first の哲学に基づくアプリだ。local-first アプリとは、基本的にオフラインで無期限に完全動作する構造を意味する。オフライン体験が基本で、クラウド sync は追加的な改善にすぎない。一時キャッシュベースのアプリは offline-first とは言えない。ローカル DB にデータを保存し、真の offline-first とは、インターネットと無関係にデータが保持される構造だ。大半の「offline-first」を名乗るアプリは、実際には offline-tolerant（限定的なオフライン対応）にすぎない。offline-first アプリを作るのは、online-only の Web アプリよりはるかに難しい。オフラインとオンラインの切り替え状況でもデータ損失なく確実に同期されるメカニズムが必須だ。自分の実装方法はブログを参照してほしい(https://blog.brisqi.com/posts/how-i-designed-an-offline-firs...).
こうした原則は、消費者向けに集中していても意味がある。私たちは現在 Sentinel Devices(www.sentineldevices.com) で、SCADA や産業自動化のようにデータを絶対に外部へ出せない産業現場向けに、完全ローカルで実行・分析・意思決定がすべて自前の機器上で行われる構造を開発中だ。外部サーバー自体を提供していない。こうしたオンデバイス原則に集中する構造は、顧客にもベンダーにも一種の発想転換をもたらす。多くのデータ/AI 企業は、実際には顧客現場へのサービス提供が難しすぎるという理由でこうした市場を無視している。ところが私たちは、ノーコネクティビティ、完全ローカル処理であることを強調しないと顧客に伝わらない場面がよくある。こうした現象が消費者領域で local-first として定着すれば、産業分野ももっと速く変革するはずだ。
SCADA 業界ですら最近はみなクラウドへ誘導しようとしている。「工場をスマホで管理しましょう」というキャッチフレーズだ。しかし今や単なる趣味のハッカーにまで工場制御が開かれる状況になり、危険性が増している。
この分野はとても興味深いし、活動を応援している。ひとつ気になるのは、採用ページを見ると全員オンサイト採用になっていることだ。local-first 開発は実際にオフライン勤務が必要だからそうしているのか、それとも経営上の理由なのか気になる。
自分のプロジェクト（selfhostblocks, skarabox）も、NixOS ベースで誰でも簡単にセルフホスティングできることを目指している。https、SSO、LDAP、バックアップ、ZFS スナップショットなど、ほぼすべてを宣言的に提供する。Vaultwarden、Nextcloud など大半のデータを保存でき、Home Assistant のようなサービスも含む。YUNoHost の競合だが、より良いものを目指している。SelfHostBlocks は複数のパッケージビルディングブロックの形で、誰でも自由に拡張・セルフホスティングできる。フレームワークというよりライブラリ的なアプローチだ。NAS の代替でもあり、完全オープンソース。技術知識のある人には簡単かもしれないが、（nix や CLI なしで）一般の人でもハードウェアにインストールできるよう、参入障壁をなくすことを目標にしている。
こういうプロジェクトは本当に応援したい。驚くほど優れた FOSS（オープンソース）の代替はたくさんあるのに、実際には技術者だけが簡単にインストールできる（「docker compose up」レベル）ものが多く、一般の人には壁がある。セルフホスティング可能なアプリの多くは Web アプリ + DB + サーバー + フロントエンド構成だが、自分の場合は実質1台の機器でしか使わない。完全ローカルなデスクトッププログラムで十分なのに、開発者でなければそれすら圧倒的に難しい。高品質なセルフホスティング FOSS と実利用者の間には、明らかなミスマッチがある。この隔たりを埋めるプロジェクトがもっと必要だ。自分も selfhostblocks を使ってみるつもりだし、発展を応援している。
hledger が含まれているのがとても良い。プレーンテキスト会計に初めて触れる人には少しなじみが薄いかもしれないが、非常に優れたソフトウェアだ。
きれいに作ってくれて本当にありがとうという気持ち。
本文をざっと見ると重要なポイントの大半は押さえているが、第1段落の動機づけが弱く感じられる。「アップルパイはおいしくて栄養もあるけれど、いつか突然燃えてなくなり、私が大事にしていたよだれかけまで消えてしまうかもしれない」といった話に読める。