制作ノート: 個人データを外部送信しないローカルファースト設計

ASSET MANAGEMENTのデータ管理画面 — LOCAL DATA画面。アカウントと同期、バックアップ、復元、全データ消去の各セクションを表示している。

追記（2026年7月27日）: 本文はこの記事を書いた時点（2026年7月14日）の設計判断の記録です。その後、PANTRYは2026年7月17日ごろ、ASSET MANAGEMENTは2026年7月26日ごろに、データの正本をLocal Storageから運営者管理のCloudflare D1（サーバー）へ移行しました。現在の保存先はASSET MANAGEMENTの機能と保存方式とPANTRYの機能と保存方式で確認できます。以下の本文は、移行前にLocal Storageを選んだ理由と、当時利用者へ伝えていた注意点の記録として残しています。

ローカルファーストを選んだ範囲

ここでいうローカルファーストは、入力したデータを利用中のブラウザへ保存し、通常の利用で外部サーバーへ送らない構成を指します。この記事を書いた時点で、ASSET MANAGEMENTでは口座残高、収支、カード利用、予定を、PANTRYでは食品名、数量、保存場所、期限などを扱っており、どちらもアカウント登録やクラウド同期を前提にしていませんでした。

Webアプリ本体は配信元から読み込みますが、当時は利用者が入力した内容がLocal Storageに残る構成でした。「Webだからデータも運営者のサーバーにある」と思われやすいため、保存先、通信の有無、削除条件を紹介ページで明示することも設計の一部にしていました。この明示の方針自体は、サーバー保存へ移行した現在も変えていません。

採用理由は機能との釣り合い

サーバーへ保存するなら、ログイン、本人確認、通信の暗号化、アクセス制御、データベースのバックアップ、退会時の削除などが必要です。それらは複数端末での同期や共同編集には有効ですが、一人が一台の端末で使う小規模な記録ツールには運用負担が大きくなる、というのが当時の判断でした。

この時点でLocal Storageを選んだのは、入力直後に端末内へ保存でき、サーバー側に個人データの保管場所を作らずに済むためでした。アカウントもパスワードも不要でした。通信状態に左右されにくく、画面の再読み込み後も同じブラウザで記録を続けられます。ただし、この簡潔さは「クラウドと同じ安全性」や「永久保存」を意味しませんでした。

外部送信しないことの利点（当時の判断）

Local Storageを選んだ時点で見込んでいた利点は、次のとおりです。

運営者側に入力データが集まらず、サーバーからまとめて漏れる対象を作らない。
登録用のメールアドレスやパスワードを追加で預からない。
入力のたびにネットワーク応答を待たず、軽い操作感を保ちやすい。
保存の仕組みを「このブラウザ内」と短く説明できる。

特に家計データは、残高や支出の内容だけでも生活状況を推測できる情報です。便利だから収集するのではなく、機能に不要なら最初から受け取らない方が管理対象を減らせる、という考え方は現在も変えていません。ASSET MANAGEMENTのアプリ内には当時から広告やアクセス解析を置いておらず、この方針は現在も同じです。ただしContent Security Policyの範囲は、外部送信そのものの禁止から、自身のサーバー以外への通信の禁止へと、サーバー保存への移行に合わせて変わっています。PANTRYも同様に、独立したoriginで他のHub作品の保存領域から分ける構成を維持しています。

Local Storageの限界（当時利用者へ伝えていた注意点）

ここから先は、Local Storageを正本にしていた当時、利用者へ案内していた注意点です。現在のサーバー保存に伴う注意点は、各ツールの詳細ページのFAQで案内しています。

端末間で同期されない

パソコンで入力した記録がスマートフォンへ自動で現れることはありません。同じ端末でも、ChromeとEdge、通常プロフィールと別プロフィールでは保存領域が異なります。家族との同時共有にも向きません。複数端末で同じ記録を使うには、JSONを書き出して明示的に移す必要があります。

サイトデータの削除で消える

ブラウザの閲覧データ整理、サイトデータ削除、プロフィールの初期化、端末故障などで記録を失う可能性があります。運営者側には複製がないため、問い合わせを受けても復元できません。消えて困る記録には、利用者自身が保管するバックアップが必要です。

同じブラウザを使う人から見える

Local Storageは暗号化された金庫ではありません。共有パソコンで同じブラウザプロフィールを開ける人は、アプリ画面から記録を見られる可能性があります。カード番号、暗証番号、口座番号、パスワードのような認証情報は入力対象にしないよう案内しています。

バックアップを機能の一部にする

Local Storageを採用するなら、書き出しだけでなく復元まで一組で用意します。ASSET MANAGEMENTとPANTRYはJSONバックアップの書き出しと復元に対応し、PANTRYでは読み込み時に形式を検証します。ファイル名にはツール名と日付を含めると、どれが新しいか判断しやすくなります。

月末や大きな更新後にJSONを書き出す。
現在の端末とは別の、自分だけが使える保管先へ複製する。
復元後は件数と代表的な2〜3件を照合する。
古いバックアップを捨てる前に、最新ファイルが開けることを確認する。

JSONは機械が扱いやすい一方、入力内容が平文で入ります。公開リンク付きの共有フォルダ、職場や学校の共用領域、メールへの無期限添付は避けます。ファイルを暗号化して保管する場合も、復号用の情報を同じ場所に置かないなど、利用者の環境に合った方法を選ぶ必要があります。

データを分離する設計

ブラウザの保存領域はorigin単位で分かれます。PANTRYを独立したCloudflare Workerドメインで公開するのは、食品データをほかのHub作品と共有しない境界を作るためです。機能が増えたときも、無関係なアプリから同じ保存データへ触れない構成を維持しやすくなります。

一方で、originが変わると以前の保存データは自動で移りません。公開URLの変更はデータ移行に影響するため、安易に行えません。保存キーの形式を変更する更新でも、既存データを読み込む移行処理か、バックアップ経由の手順が必要です。

向いていない用途も明確にする

複数人の共同編集、複数端末の常時同期、端末紛失時の遠隔無効化、厳格な監査履歴が必要な用途には、この構成は向きません。医療情報や認証情報など、漏えい時の影響が大きいデータを、単純なLocal Storageだけで扱う設計も避けるべきです。

ローカルファーストは「サーバーを使わないから安全」と断定するための言葉ではありません。収集しない利点と、端末側で守る責任を分けて説明し、バックアップと共有端末への注意を実際の画面から辿れる場所に置く。その一連の設計によって、利用者が保存先を理解したうえで道具を選べる状態を目指しています。

この記事について

執筆: rin0420。本サイトで公開しているゲームとツールの開発者です。掲載しているスクリーンショットと数値は、公開中の実物を操作して取得したものです。

公開: 2026年7月14日 / 最終更新: 2026年7月27日（ASSET MANAGEMENT・PANTRYのサーバー移行を追記）