利用者のデータを端末の中だけに置く設計と、そこで諦めたこと

作っているアプリは、利用者のデータを一切サーバーへ送りません。 APIキーも、解いた問題の履歴も、登録した参照資料も、すべて端末の中（IndexedDB）にだけ置いています。

privacy を売りにしたかったからではなく、そうするしかなかったというのが正直なところです。 ただ、やってみると副次的な利点のほうが大きくなりました。

そうするしかなかった理由

バックエンドを持たない構成にしたので、そもそもデータを置く先がありません。 サーバーを立てれば月額が発生し、「無料で配る」という前提が崩れます。

つまり、技術的な理想ではなく費用の制約から出発した設計です。

結果として得られたもの

1. 障害対応が発生しない

サーバーが無いので、落ちません。深夜に起こされることもありません。 個人開発で継続するうえで、これが一番効いています。

2. 説明が短くなる

「入力した内容はサーバーに送信されません」の一文で済みます。 プライバシーポリシーで長々と説明する必要がありません。

そして、この一文が実際に選ばれる理由になります。 業務データを扱う人にとって、外部に出ないことは機能の一つです。

3. オフラインでも履歴が読める

端末内にあるので、通信が無くても過去の結果を読み返せます。 PWAとして入れてもらう構成と相性がよいところです。

4. 責任範囲が狭くなる

預かっていないものは、漏らしようがありません。 APIキーを預かる設計にしていたら、その保管に対する責任が発生していました。

代わりに諦めたこと

利点だけではありません。構造的にできなくなることがあります。

端末を変えると引き継げない

これが最大の欠点です。機種変更すると、履歴も設定も消えます。

対処として、設定と履歴をファイルとして書き出し／読み込みできる機能を入れました。 自動同期はできませんが、手動なら移せます。

「同期できないので諦めてください」ではなく、 手作業でも道を残しておくのが現実的な落としどころでした。

複数端末で同じ状態にできない

スマートフォンとPCで別々の履歴になります。 同期にはサーバーが要るので、この構成では原理的に無理です。

利用状況が分からない

サーバーが無いので、何人がどう使っているかを把握できません。 不具合の報告があっても、再現に必要な情報が手元にありません。

そのため、画面上で状態を確認できる要素を増やしました。 たとえば、AIが読み取った図を利用者が開けるようにしています。 運営側が見られない代わりに、利用者自身が気付ける場所を作る考え方です。

ブラウザのデータ削除で消える

利用者がブラウザのデータを消すと、全部消えます。 これは説明しておくしかありません。

保存する場所の選び方

端末内といっても選択肢があります。

保存先	容量	用途
localStorage	数MB	小さな設定
IndexedDB	大きい	履歴、画像から起こしたテキスト
Cache Storage	大きい	アプリ本体（PWA）

履歴を数百件持つ想定だったので IndexedDB を選びました。 localStorage は同期的に動くため、量が増えると画面が固まります。

設定項目を増やすときの決まり

端末内に保存する場合、古いバージョンのデータが残り続けます。 新しい設定項目を足したとき、既存の利用者のデータにはその項目がありません。

そこで運用ルールを決めました。

• 新規の項目は、読み込み時に既定値で自動補完する
• 既存項目の既定値を変える場合だけ、明示的な移行処理を書く

前者を自動化しておかないと、項目を足すたびに移行処理が増えて破綻します。 逆に、既定値の変更まで自動補完に任せると、 すでに保存されている古い値が生き残って意図しない挙動になります。

この線引きは、開発を手伝わせているAIエージェント向けのルールにも書いてあります。

向いている場合

• 無料で配りたい（サーバー費を出せない）
• 扱うデータが個人的なもので、共有の必要がない
• 端末をまたぐ利用が主目的ではない

逆に、複数人で同じデータを見る必要があるなら、この構成は選べません。 制約から出発した設計なので、万能ではありません。