ローカルファーストソフトウェア：クラウドに関わらず、あなたのデータはあなたのものです

2025年7月5日原文(inkandswitch.com)

概要

クラウドアプリは コラボレーション と 利便性 を提供
しかし、 データ所有権の喪失 や 依存リスク が存在
ローカルファーストソフトウェアは 所有権 と 協働性 の両立を目指す
理想の実現には 7つの指針 が存在
本文ではその理想と課題を解説

クラウドアプリの利点と課題

Google DocsやFigma、Slack、Trelloなどの クラウドアプリ による共同作業の普及
データのどこからでもアクセス 可能、リアルタイム共同編集の実現
クラウドアプリ依存 による、サービス停止時のデータアクセス不能リスク
クリエイティブな仕事 では、自分の作成物への強い愛着や所有感が重要
サービス終了や障害時に データ喪失や操作制限 の危険性
クラウドは「他人のコンピューター」であり、 完全な所有権を持てない 実態

従来型アプリとデータ所有権

ローカルアプリ は自分のPC内にファイルを保持
完全なデータ所有権、バックアップや他ツールでの加工が自由
サーバー依存なし、自分の意思でファイル管理が可能
テキストエディタ、IDE、Git、グラフィック/CADソフトなどが該当

両立の理想：ローカルファーストソフトウェア

コラボレーション と データ所有権 の両立を目指す新しいソフトウェア像
ローカルストレージ と ローカルネットワーク を優先利用
サーバーは 補助的な役割、データの主役はローカルコピー
端末ごとに データのプライマリコピー を保持、サーバーはセカンダリ

ローカルファーストソフトウェアの7つの理想

1. スピナー不要：即応性の高い操作感
- 全操作がローカルディスクで完結、サーバー往復の遅延なし
- ユーザー入力に 即座に反応、スピナー表示不要
- データ同期は バックグラウンド で静かに実施
2. データが端末に縛られない
- 複数端末間での データ同期 による柔軟なワークフロー
- サーバーを利用した バックアップ も可能
- 同一ファイルの同時編集時には 競合発生 の課題
3. ネットワークが必須でない
- オフライン環境でも フル機能 で作業可能
- ネット接続時に 他端末と同期
- BluetoothやローカルWiFi経由での 端末間同期 も対応
- インストール型アプリで オフライン対応 が理想
4. シームレスなコラボレーション
- 複数人による 同時編集 の実現
- 従来型アプリでは編集競合やマージ作業が必要
- Google Docsのような リアルタイム共同編集 の体験を目指す
- 編集提案やレビュー、選択的適用など 多様なコラボフロー への対応
- GitHubのプルリクエストやGoogle Docsのサジェストモードに相当する機能

（以降の理想や技術的詳細は、次セクションで解説予定）

ローカルファーストソフトウェアの今後

即応性・所有権・協働性 の3要素を同時に満たすソフトウェア設計
技術的課題として リアルタイム同期 や 競合解消 の高度化
ユーザー体験 の向上と データの持続的所有 の両立
今後のアプリケーション開発における 新たな標準 への期待

Hackerたちの意見

読む価値ありだし、過去にはかなり活発な議論があったよね。 https://news.ycombinator.com/item?id=19804478 - 2019年5月、191件のコメント https://news.ycombinator.com/item?id=21581444 - 2019年11月、241件のコメント https://news.ycombinator.com/item?id=23985816 - 2020年7月、9件のコメント https://news.ycombinator.com/item?id=24027663 - 2020年8月、134件のコメント https://news.ycombinator.com/item?id=26266881 - 2021年2月、90件のコメント https://news.ycombinator.com/item?id=31594613 - 2022年6月、30件のコメント https://news.ycombinator.com/item?id=37743517 - 2023年10月、50件のコメント

データの部分は置いといて、プラットフォームや機能面について言うと、これらのクラウドや大規模な製品は、残念ながらもっと強力で高度な機能や便利さを提供してるよね。例えば、デバイス間でのシームレスな移動やコラボレーションを可能にするクラウドのマルチデバイス機能とか、標準のmssql dbを超えたあらゆる機能を提供するエンタープライズ製品のスノーフレークやファブリックとか。個人的にはベンダーロックインには反対だけど、彼らには一定の価値があると思う。

オンライン依存のものは、必然的に継続的なメンテナンスとコストがかかるよね。もしシステムがローカルファースト（理想的にはローカルオンリー）じゃなかったら、長期的な信頼性には向いてない。接続された家電や車って、実用的な観点から見ると、ほんとにバカなエンジニアリングだと思う。

└

すべてはサブスクリプション収益のせいだよね。サブスクリプション収益を得ている企業は、収益も高く、評価も上がるから、資金調達がしやすくなって、そういうモデルを取らない企業を打ち負かすことになる。これがローカルファーストのソフトウェアが消えた理由だよ。

これの背後にある原則を見るのは面白いけど、確実に消費者向けに向いてると思う。ちょっと宣伝になるけど、関連して言うと、今私たちは産業資産や産業データのためにこれをやってるんだ（www.sentineldevices.com）。全てのトレーニング、分析、意思決定プロセスが顧客の設備で行われるんだよ。データを送るサーバーすら持ってないし、私たちのモデルはすべてデバイス上で完結するように設計されてる（だから、記事で話されてたネットワークの原則がすごく興味深かった）。これは、データを外の世界に持ち出せないSCADAや産業オートメーションのユースケースをサポートするためなんだ。実際、データやAIの企業が無視してる大きな顧客基盤とユースケースがあると思う。顧客やユーザーがいる場所でサービスを提供するのは難しいから、彼らはデータを自分たちのところに持ってきたがるし、ベンダーロックインを維持したがる。面白いのは、顧客との話し合いの中で、「いや、これはローカルだから、外部接続はないよ」ってことをはっきり伝えないといけないこと。どこでもそんなこと聞かないから、時には一歩一歩説明しないと理解してもらえないことがある。これ、ソフトウェアベンダーの頭も混乱させることが多いよね。消費者向けでもローカルファーストのソフトウェアがもっと普及して、産業分野でも慣れていくといいな。

└

エキサイティングな分野だし、あなたとチームがそこに取り組んでいるのは嬉しいよ。キャリアページを見たけど、すべてのポジションがリモートじゃないね。これはローカルファーストのソフトウェアを扱う上で、対面が必要だから？それとも主に管理の問題？

理論的には、ローカルファーストの構築方法が大好き。プライバシーやデータ所有権が基本にある「スモールテック」哲学とよく合ってる。でも実際は難しい！同期エンジンを構築したり、競合解決を扱ったり、スキーマの移行を管理したりする責任があるからね。とはいえ、ローカルファーストのソフトウェア開発のためのツールは、ここ数年で改善されているみたい。ジャズツール、エレクトリックSQL、ロキコープのゼロを注目してるんだけど、他に何かある？

└

最近、オートマージのことを指摘している人を見た気がする。 https://automerge.org/ RustとJavaScriptの実装があって、いくつかのネットワーク戦略もあるみたい。ジャズツールのような無料や有料のオファリングはないけど、かなり良いよ。

└

サーバーにCouchDB、クライアントにPouchDBを使うのは、そんな環境を作ろうとした試みだったんだよね。 - https://couchdb.apache.org/ - https://pouchdb.com/ それから、"ローカルファースト"なアプリ開発についての考察が「数年前」（約10年くらい前）にここに載ってるよ: https://unhosted.org/

└

あのウェブサイト知ってる？ https://www.localfirst.fm 追記: 実は「ランドスケープ」リンク（上のメニューにあるやつ）を指摘したかったんだけど、そのURLはちょっと使いづらいね。

└

自分はローカルソフトを使って、ファイルをgitや時々fossilで同期してるよ（例えば、Androidのtermuxで使うやつね）。サーバーをホストしたり、特別な方法でデータを同期するソフトは使ってない。

└

このサイトにはデブツールのディレクトリもあります: https://lofi.so/

Hacker Newsで議論の続きを見る

ハクソク