自作Webツールのデータはどこに置く？ブラウザ保存・ファイル・スプレッドシート・Firebaseの比較
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。
結論から言うと、保存先は「何人が使うか」より先に、次の3つで決めるのが近道です。 1. 端末をまたぐか(スマホで入れたものをPCでも見たいか) 2. 他の人と共有するか(自分以外が同じデータを見る・書くか) 3. 消えて困るか(消えたら作り直せるか) 3つとも「いいえ」なら、ブラウザ保存(localStorage)で足ります。どれかが「はい」になった時点で、ブラウザだけに置くのは危うくなります。ここではこの3条件を軸に、4つの保存先を選ぶ判断表を作ります。
この記事の目次
先に判断表:3つの条件で保存先を選ぶ
次の表は、公式資料で確認した性質をもとにした、編集上の目安です。
- いいえ、共有する：いいえ、消えて困る：いいえ、第一候補：ブラウザ保存、理由：サーバー不要で最も簡単
- いいえ、共有する：いいえ、消えて困る：はい、第一候補：ブラウザ保存+書き出しファイル、理由：手元にバックアップを残せる
- はい、共有する：いいえ、消えて困る：どちらでも、第一候補：スプレッドシート、またはFirebase、理由：自動同期には端末外の保存先が必要。手動で移すならファイルも候補
- はい/いいえ、共有する：はい(少人数で同じデータを扱う)、消えて困る：どちらでも、第一候補：スプレッドシート、理由：共有の見える化と手修正がしやすい
- はい/いいえ、共有する：どちらでも(ログインで本人ごとに分ける)、消えて困る：どちらでも、第一候補：Firebase、理由：利用者ごとの権限を設計できる
本人ごとにアクセス権限を分けたい場合は、最終行を優先します。「消えて困る」が「はい」なら、スプレッドシートやFirebaseでも、誤削除に備えた書き出しや復元方法を決めておきます。
迷ったら、まず上から順に「ブラウザ保存で足りないか」を疑ってください。足りない理由を言葉にできたときだけ、一段重い保存先へ進みます。
ブラウザ保存(localStorage):手軽だが「その端末のそのブラウザだけ」
localStorageはキーと値の組を、文字列として保存する仕組みです。ブラウザを閉じても残りますが、オリジン(スキームとホスト名とポート)ごとに分かれて保存されます(MDN: Web Storage API)。端末間の自動同期はありません。MDNの説明でも、ブラウザの保存領域は端末ローカルのものとして扱われています。
注意点は3つあります。
- 容量:MDNによると、Web Storageは合計10 MiB(localStorageとsessionStorageで各5 MiB)までです。画像や大量の履歴には向きません。
- 消える可能性:ブラウザの保存領域は既定では「ベストエフォート」で、ディスクが逼迫すると削除されることがあります。Safariでは、7日以上操作のないオリジンが削除対象になると説明されています(MDN: Storage quotas and eviction criteria)。
- プライベートブラウズ:localStorageがsessionStorageのように振る舞い、ウィンドウを閉じると消えます。
つまり「消えて困る」が「はい」なのに、ブラウザ保存だけにするのは避けたほうが安全です。
ファイル:バックアップと持ち運びに強い
ここでの「ファイル」は、JSONやCSVを画面から書き出し、必要なときに読み込む方式を指します。サーバーもアカウントも要らず、データが目に見える形で手元に残ります。
- 向く場面:自分専用のツールで、ときどき別の端末へデータを移したい。ブラウザ保存の保険にしたい。
- 向かない場面:常に最新を複数端末で見たい。複数人が同時に更新する。
書き出し・読み込みは自動では同期しないので、「どちらが新しいか」は人が管理します。ここが運用上の弱点です。
スプレッドシート:共有と手修正が得意、ただし仕組みは一段増える
Googleスプレッドシートを保存先にする場合、多くは Google Apps Script をウェブアプリとして公開し、ツールからそこへ読み書きする形になります。デプロイ時に「自分として実行」か「アクセスしたユーザーとして実行」かを選べます(Apps Script: Web Apps)。
確認できた範囲では、次のような制限があります(Apps Script: Quotas、取得時点でページに表示されていた更新日は2026-09-03)。
- 1回の実行時間は最大6分
- 同時実行はユーザーあたり30、スクリプトあたり1,000
- 一部の上限は個人アカウントとWorkspaceで異なる
小さな家族・サークル用途ならこの範囲で足りる場面が多いと考えられますが、利用者が増える見込みなら、上限の再確認が必要です。
「自分として実行」で「全員がアクセス可」にすると、URLを知っている人が自分の権限で処理を走らせられる形になります。公式資料もOAuthトークンの扱いに注意を促しています。そのため、スプレッドシートには公開されて困る情報を置かないのが基本です。
Firebase(Firestore):ログインと権限まで設計するときの選択肢
利用者ごとにデータを分けたい、端末をまたいでリアルタイムに近い形で見たい、という場合に候補になります。ただし最初に理解すべきは機能よりセキュリティです。Firebaseの公式ドキュメントは、セキュリティルールで「サーバー側で強制されるアクセス制御」を定義し、Firebase Authenticationと組み合わせて使うよう説明しています(Firebase: Security Rules をはじめる)。
初心者が陥りやすいのは、動作確認のためにルールをゆるくしたまま公開することです。ルールを設計せずに公開すると、他人にデータを読み書きされる恐れがあります。ログイン済みかどうかの確認だけでは、本人ごとの分離にはなりません。本人のデータだけを読み書きできる条件を設け、未ログインの人や別の利用者からのアクセスが拒否されるか確認します。
Cloud Firestoreの無料枠は、1プロジェクトにつき1データベースが対象で、保存データ1 GiB、ドキュメントの読み取り1日50,000件、書き込み・削除はそれぞれ1日20,000件、外向きデータ転送は月10 GiBです。無料枠を超えて利用するには課金の有効化が必要で、バックアップや復元などは無料枠に含まれません。有料の単価はロケーションによって異なるため、導入前に公式の料金ページで最新の条件を確認してください。
AIに任せる範囲と、人が確認すること
AIに保存先の候補を絞らせるときは、次の依頼文をそのまま使えます。
自作のWebツールの保存先を選びたいです。次の条件で、
ブラウザ保存/書き出しファイル/スプレッドシート/Firebase
の中から第一候補と、その理由、避けるべき落とし穴を3つ挙げてください。
最後に「この条件が変わったら保存先を変えるべき」という境目も書いてください。
- ツールの内容:(例)読んだ本の記録
- 使う人:(例)自分だけ
- 端末をまたぐか:(例)スマホとPCの両方で見たい
- 他の人と共有するか:(例)しない
- 消えたら困るか:(例)困る
- 入れるデータ:(例)書名、読了日、ひとことメモ(個人情報は入れない)
- 私の経験:(例)HTML/JavaScriptは少し書ける説明用の例(実際に試した結果ではありません)
上の条件で入力した場合、「端末をまたぐ」「消えて困る」が「はい」で共有は「いいえ」なので、判断表の3行目に当たります。一人用なら、本人だけがアクセスできるよう設定したスプレッドシート方式も候補です。Firebaseを選ぶ場合も、ログインに加えて本人のデータだけを読み書きできるルールが必要です。こうしたアクセス制限と、消えた場合の復元方法まで比較が返ってくるのが望ましい形です。
AIの回答は、次の点を人が確認してください。
- 示された上限や料金が、公式ページの最新内容と合っているか
- 「公開URLを知る人は誰でも書けないか」が説明されているか
- 本当に必要な条件を、依頼文に入れ忘れていないか
- 実名・連絡先・社外秘は、依頼文にも保存データにも入れていないか(例は架空の値に置き換える)
迷ったときの進め方
- 判断表の3条件に、はい/いいえで答える
- ブラウザ保存から始める場合も、書き出しボタンだけは最初から付けてもらう
- 共有や端末またぎが必要になった時点で、スプレッドシートかFirebaseに移す。そのとき、既存データはファイルで書き出して移行する
最初から重い保存先を選ぶより、「書き出せる」設計にしておくと、後で保存先を替えるときの負担が小さくなります。
