ローカルファーストの実際の意味
local-first というフレーズは、多くの場合、「オフラインで動作する」または「ファイルをアップロードしない」にまとめられます。これらは便利な特性ですが、Ink & Switch のオリジナルの ローカル ファースト ソフトウェアの定式化はより広範です。ユーザーはデータに対する所有権と主体性を保持する必要があり、ソフトウェアはローカルでの応答性と有用性を維持する必要があり、サーバーは唯一の正式なコピーを保持するのではなく、同期またはコラボレーションをサポートする必要があります。
この違いにより、混同しやすい 4 つのアーキテクチャが生成されます。
| Model | 信頼できるデータ | ネットワークなしでも動作しますか? | 代表的な強度 | 典型的な弱点 |
|---|---|---|---|---|
| Cloud-first | ベンダーサーバー | 通常は制限されています | 状態の共有、集中管理 | アカウントとサービスの依存関係 |
| Offline-first | 多くの場合、ローカル キャッシュを備えたクラウド | Temporarily | 接続不良時の継続性 | ローカル コピーは耐久性や移植性がない可能性があります |
| Local-only | ユーザーデバイス | Yes | プライバシーとシンプルさ | ユーザーが提供しない限り、コラボレーションとバックアップが弱い |
| Local-first | ユーザー制御のローカル コピー (オプションで同期) | はい、仕様上 | 所有権とコラボレーション | 競合解決とクロスデバイス同期の構築は困難 |
ブラウザ ツールは、完全にローカルファーストではなくても、ローカルのみにすることができます。メモリ内の画像を処理して結果をダウンロードする場合、アップロードは回避されますが、耐久性のあるユーザー所有の作業ドキュメントを維持できない可能性があります。逆に、すべての参加者が使用可能なローカル コピーを持ち、同期が前提条件ではなく拡張機能である場合、共同編集者は真のローカル ファーストになることができます。
ネットワークを切断して、ベンダーが消滅したと想像してください。ユーザーは、作成したマテリアルを開いて、理解し、エクスポートし、作業を続けることができますか?答えが「はい」に近いほど、その製品はよりローカルファーストであると言えます。
なぜ今このようなことが起こっているのか
ブラウザは突然デスクトップ オペレーティング システムになったわけではありません。相互運用可能な機能が十分に蓄積されているため、従来のインストーラーを使用せずに大規模なユーティリティを実用できるようになりました。
リッチ エディター、応答性の高いコントロール パネル、ドラッグ アンド ドロップ キュー、プレビュー、およびアクセス可能なフォームは、ネイティブ UI ツールキットがなくても実行できます。
WebAssembly は、効率的な実行のために設計されたポータブルなコンパイル ターゲットを提供し、確立された画像、オーディオ、PDF、科学、および言語ライブラリをブラウザー サンドボックス内で実行できるようにします。
Web アプリケーションは、ユーザーが選択したファイルを読み取り、ローカル データベースを維持し、サポートされている場合には、進化する ファイル システム アクセス API を通じてファイルおよびディレクトリ ハンドルを操作できます。
キャッシュされたアプリケーション シェルは停止中も読み込みを続けることができ、オプションのサーバーはすべての対話を所有することなく共有、バックアップ、またはコラボレーションを提供します。
WebAssembly が重要なのは、「Web ページでこれができる」と「Web ページでこれを実用的な速度で実行できる」との間のギャップを縮めるためです。公式 WebAssembly プロジェクトでは、ブラウザーの使用目的として、画像とビデオの編集、科学シミュレーション、暗号化、開発者ツール、CAD、言語ランタイムがリストされています。また、Wasm がブラウザのサンドボックス内で実行され、埋め込み環境の同一オリジンおよびアクセス許可ポリシーを継承していることも強調しています。
ワーカーは別の理由で重要です。ワーカーは、計算量の多いタスクによってインターフェイスがフリーズするのを防ぎます。バッチ イメージ ツールは、ファイルのサイズを並行して変更できます。 PDF アプリはワーカーでページをレンダリングできます。 OCR ワークフローは、認識をメインスレッドから分離できます。その結果は、フォームを送信する Web ページというよりは、ローカル ジョブ キューを備えたソフトウェアのように感じられます。
ファイル API は別のギャップを埋めます。古い Web ツールでは、サーバーが価値を追加しない場合でも、ユーザーがアップロード/ダウンロードのループに陥ることがよくありました。最新の API を使用すると、ユーザーはファイルを明示的に選択し、サポートされているブラウザーでファイルを保存したり再度開いたりするための狭いアクセスを許可できます。セキュリティ モデルは意図的に許可されています。アクセスは、デバイスのサイレント トラバースではなく、ユーザー ジェスチャとピッカーによって始まります。
プライバシー以外の利点
1. レイテンシーの短縮と即時フィードバック
サイズ変更、テキストのクリーンアップ、形式変換、または比較をローカルで実行できる場合、ユーザーはアップロード、サーバー キュー、ダウンロードを待つ必要はありません。ファイルが大きい場合、接続が遅い場合、またはユーザーが繰り返し操作を繰り返す場合、利点はさらに大きくなります。
2. より優雅な失敗
アプリケーションのコア機能がすでにデバイス上にある場合、クラウドの停止やアカウントの問題はそれほど致命的ではありません。ローカルファースト設計では障害が排除されるわけではありませんが、障害モードが「サービスが利用できないため、作業ができない」状態から「ローカル作業が継続している間、共有または同期が遅れる可能性がある」状態に変わります。
3. 限界インフラコストの削減
ユーザーが決定論的変換のためのコンピューティングを提供すると、開発者は画像のサイズ変更、PDF 解析、オーディオ正規化パス、またはテキスト分析ジョブのすべてに料金を支払う必要がなくなります。これにより、すべてのタスクをデータ収集やサブスクリプションファネルに変えることなく、無料ツールをサポートできます。
4. データの最小化が容易になる
最も強力なプライバシー ポリシーは、サーバーがファイルを決して受信しないという構造的なものである場合があります。これによってすべてのプライバシー リスクが除去されるわけではありませんが、プロバイダーが保存、保護、管理し、最終的には削除する必要がある機密マテリアルの量が減少します。
5. ユーザー制御による移植性
ローカルファースト システムでは、エクスポートを緊急機能ではなく通常の操作にすることができます。プレーン ファイル、ポータブル アーカイブ、および標準形式により、独自のデータベースや脆弱なアカウントによって生み出される影響が軽減されます。
すべてのドキュメントをアップロードする「プライバシー最優先」のインターフェイスは、政策上の約束を果たしています。変換をローカルで実行するツールにより、機密データ フロー自体が削減されます。 2 番目のアプローチでも、正直なコードとセキュリティ制御が必要ですが、露出面が小さいことから始まります。
ローカルファーストのブラウザー アプリのアーキテクチャ
ファイル ピッカー、貼り付けアクション、またはローカル ドキュメントは、アプリケーションがアクセスできるものの周囲に明示的な境界を作成します。
アプリは、現在のブラウザー セッションまたはローカル データベースで選択されたコンテンツを解析します。
JavaScript または WebAssembly は、インターフェイスをブロックせずにデータを処理します。
プレビュー、差分、警告、設定により、ユーザーはエクスポート前に出力を検証できます。
結果は、コラボレーションで必要な場合にのみ、ダウンロードされ、指定された場所に保存され、または同期されます。
最も防御可能な実装では、データ パスが監視可能になります。これらは、ファイルがデバイスから送信されるかどうか、アプリケーションのロード後に不要なネットワーク要求を回避するかどうか、およびオプションのテレメトリをコンテンツ処理から分離するかどうかを示します。また、永続的な状態だけが不透明なブラウザ ストレージ内に存在する場合、ユーザー制御が不完全になるため、エクスポートが明確になります。
コラボレーション製品の場合、ローカルファーストはより技術的に要求されます。複数のデバイスがオフライン中に同じレコードを変更する可能性があるため、システムには競合解決ルールが必要です。 CRDT と関連する複製データ技術は役立ちますが、どの変更が自動的にマージされるのか、ユーザーにはどのような履歴が表示されるのか、多くのデバイスにコピーが存在する場合にアクセス許可はどのように適用されるのかなど、製品設計上の疑問が生じます。
ローカルファーストでは解決できないこと
地元で加工されたものは貴重ですが、過剰販売されやすいです。
- 信頼できないコードは安全になりません。 悪意のあるアプリケーションまたは侵害されたアプリケーションは、読み取り可能な情報を送信する可能性があります。 WebAssembly セキュリティ モデルは、モジュールからホストを保護します。そのモジュールを使用するアプリケーションの意図を保証するものではありません。
- バックアップは作成されません。 コピーがブラウザ ストレージまたは 1 つのデバイス上にあるだけの場合でも、ハードウェアの損失によって作業が破壊される可能性があります。ローカルファースト製品には、透過的なエクスポートと、必要に応じてオプションの暗号化された同期が必要です。
- 共有デバイス上の機密性は保証されません。 ローカル データは、環境によっては、他のユーザー、ブラウザ プロファイル、拡張機能、マルウェア、またはバックアップにアクセスできる可能性があります。
- ブラウザの制限は削除されません。 メモリ、モバイルの温度制限、バックグラウンド タスクの一時停止、ブラウザの互換性、および大きなファイルの処理は依然として重要です。
- 必ずしも最も安価なアーキテクチャではありません。 リアルタイム コラボレーション、エンタープライズ ポリシー、大規模モデル推論、集中検索、および共有分析には、正当にサーバーが必要な場合があります。
したがって、正しい議論は「ローカルなほうが常に優れている」というわけではありません。それは、「サーバーがユーザーが実際に必要なことを行っている場合以外は、サーバーにデータを送信しない」というものです。
ローカル、クラウド、ハイブリッドをいつ選択するか
| Workflow | ベストデフォルト | Why | 注意してください |
|---|---|---|---|
| 個人ファイルのサイズ変更、変換、透かし入れ、または検査 | Local | 決定的なタスク。アップロードにより遅延と露出が増加します | メモリ制限とエクスポート品質 |
| Markdown の書き込みまたはプレビュー | ローカルかローカルファーストか | テキストは軽量で持ち運びに便利です。同期はオプションのままにすることができます | バックアップとマルチデバイスの履歴 |
| 共有運用データベース | Hybrid/cloud | チームには 1 つの管理された共有状態が必要です | オフラインの競合処理と権限 |
| 独自のデータに対する大規模モデルの推論 | Hybrid | クラウド コンピューティングが必要な場合がありますが、取得と編集はローカルで行うことができます | データ保持、プロバイダーアクセス、モデルログ |
| 規制された記録と一か八かの承認 | ガバナンスされたプライベートシステム | 監査、アクセス制御、保持、および法的義務が主要な要素となります | 消費者向けツールと管理されていないローカル コピー |
便利な製品はモード間を移動することもできます。ドキュメント エディターはデフォルトでローカルで動作し、ユーザーがオプトインすると暗号化されたコピーを同期し、コラボレーションまたは AI 機能の場合にのみサーバーを呼び出すことができます。アーキテクチャは、その移行を 1 つの未差別の「クラウド」ラベルの背後に隠すのではなく、公開する必要があります。
Jivaro のローカル ブラウザ ツールの使用方法
Jivaro のブラウザ ユーティリティは意図的に範囲が狭いため、ユーザーが周囲に大規模なワークスペースを作成することなく、それぞれのユーティリティが特定のタスクを実行します。次のワークフローは、ローカル処理が実際にどのようなものかを示しています。
アプリを開き、画像のバッチを追加し、出力サイズ、形式、圧縮、ファイル名ルールを選択し、キューをプレビューして、結果をエクスポートします。変換はブラウザーで行われるため、製品の写真や未公開のアセットをサードパーティの処理サーバーにアップロードする必要はありません。
PDF、スキャン、画像、Office ファイル、スプレッドシート、HTML ファイル、CSV、マークダウン ドキュメント、またはプレーンテキスト ファイルを選択します。テキストを抽出してクリーンアップし、検索し、有用なチャンクに分割して、結果をエクスポートします。スキャンされたドキュメントの場合は、名前、番号、または引用に頼る前に、OCR 出力を確認してください。
テキスト、ロゴ、組み合わせたウォーターマーク、またはタイル状のウォーターマークをバッチに追加し、配置と出力設定を調整し、プレビューを検査し、個々のファイルまたは ZIP をエクスポートします。ローカル処理は、未リリースの製品画像、クライアント アセット、プライベート ドラフトに特に役立ちます。
マークダウンの下書き、高度な構文のプレビュー、ローカル自動保存の使用、ファイルのインポートまたはエクスポート、ドキュメントをポータブル形式で保存します。ブラウザはインターフェイスですが、コンテンツはアプリケーションの外部でも読み取ることができます。
次に何が起こるか
Wasm、ワーカー、ローカル ファイル API、および高速デバイスは、メディア、ドキュメント、開発者のワークフローをインストール不要のブラウザ インターフェイスに移行し続けます。
小規模なモデルは、機能のあるデバイス上で分類、抽出、および支援を処理しますが、フロンティア推論は依然としてクラウドに依存します。
「ローカルで処理される」ということは、製品がネットワーク動作、ストレージ、エクスポート、およびオプションのテレメトリを明確に開示する場合にのみ意味を持ちます。
最も強力なシステムは、暗号化された同期、共有、アクセス制御、または高価なコンピューティングにサーバーを使用しながら、信頼できるローカル コピーを保持します。
強力な API は今後も不均等に到着するでしょう。本格的な製品は機能を検出し、適切に機能を低下させ、すべてのデバイスが同じワークロードを処理できるかのように装うことを避けます。
エクスポート、標準フォーマット、ユーザー所有のアーカイブを標準化する製品は、サブスクリプションとサービスの解約が増加するにつれて信頼を獲得します。
よくある質問
いいえ。ブラウザ アプリはすべてのデータをサーバーにアップロードし、アカウントに完全に依存する場合があります。ローカルファーストでは、信頼できるデータがどこに存在するか、製品がオフラインでも有用であるかどうか、ユーザーが作業内容を保持およびエクスポートできるかどうかが記述されます。
アプリケーションがそのように誠実に実装されている場合に限ります。ローカル処理によりアップロードの必要性は減りますが、ユーザーは依然として、提供されたコード、ブラウザー、拡張機能、デバイスのセキュリティ、およびアプリに含まれる分析機能やネットワーク機能に依存しています。
WebAssembly はサンドボックス内で実行され、ブラウザーのセキュリティ ポリシーを継承しますが、信頼できる証明書ではありません。 Wasm モジュールはホスト環境によって制約されます。どのデータが読み取られ、保存され、または送信されるかは、周囲のアプリケーションによって決まります。
コラボレーション、一元化されたポリシー、信頼性の高いバックアップ、共有検索、エンタープライズ管理、および大規模なコンピューティングでは、サーバーの恩恵を受けることがよくあります。目標は、すべてのタスクに必須にするのではなく、意図的に使用することです。
はい、ただしデバイス間の同期は難しい部分です。堅牢なシステムには、ID、権限、競合処理、暗号化、およびコピーが信頼できる明確なモデルが必要です。
これらのコア処理はブラウザーを中心に設計されていますが、初期読み込み、更新、一部のライブラリ、および特定の機能には接続が必要な場合があります。ブラウザのストレージをバックアップとして扱うのではなく、常に特定のアプリを確認し、重要な作業をエクスポートしてください。
関連するJivaroアプリ
複数の画像をブラウザー内で安全にリサイズ、圧縮、変換、名前変更、切り抜きし、AVIFやHEICにも対応した複数バリエーションを書き出せます。
アプリを開くPDF、スキャン、画像、Office文書、表計算、HTML、CSV、Markdown、プレーンテキストから文字を抽出・確認し、検索可能なPDFまたは構造化テキストとしてローカルに書き出せます。
アプリを開く画像ごとの配置、ファイル名変数、再利用できるプリセットを使い、文字、ロゴ、複合、タイル状の透かしを追加して、JPG、PNG、WebP、ZIPとしてローカルに書き出せます。
アプリを開くCodeMirror、同期スクロール、Mermaid図、フロントマター、表、シンタックスハイライト、数式に対応し、Markdownの作成、検索、プレビュー、読み込み、自動保存、書き出しができます。
アプリを開く出典と参考文献
- Ink & Switch: ローカルファースト ソフトウェア - クラウドにもかかわらず、データはお客様自身が所有しますXXQPH0002QXZInk & Switch · リファレンス
- WebAssembly プロジェクト: 概要と設計目標ZZQPH0002QXZWebAssembly · リファレンス
- WebAssembly プロジェクト: セキュリティ モデルXXQPH0002QXZWebAssembly · リファレンス
- WebAssembly プロジェクト: ブラウザーの使用例XXQPH0002QXZWebAssembly · リファレンス
- WICG: ファイル システム アクセス仕様WICG · 参照