綴Photo の勉強ノートに戻る
プロダクト設計2026.06.26

ログアウトで端末のデータを消す、をやめた — 消す道を一本増やすほうが怖い

設計判断データ保全綴Photo

写真日記アプリ(綴Photo)のモバイル版を多角レビューに掛けたとき出た「ログアウトでローカルデータを消すべきでは?」という指摘に、消さないと決めた。その判断の記録です。

レビューで、ログアウトの挙動に指摘が付いた。いまのコードは、ログアウトすると認証トークンは消すが、端末ローカルのデータベース(綴った言葉や、どの写真に紐づくか)には一切手を付けません。「同じ端末で別のアカウントに切り替えたら、前の人のデータが残るのでは?」という、共有端末を想定した指摘だ。

定石どおりなら、ここは「ログアウト時にローカルDBも消す」で塞ぎます。でも今回は、あえて消さないと決めた。この記事は、その「消さない」をなぜ選んだかの話だ。

この記事で扱う観察ポイント

  • 「ログアウトしたら消す」がなぜ一見正しく見えるか
  • 思い出アプリで「消す経路を増やす」ことの怖さ
  • 守りたいリスクと、増やしてしまうリスクを天秤にかける
  • 「壊して守る」より「気づいて守る」という代替

そもそも「ローカルDB」「ログアウトで消す」って?

コードで起きていたこと

ログアウトの処理は、構造だけ書くとこうなっていた(実際のコードとは変えてある)。

dart
// ログアウト/認証失効でこの状態に落とす
Future<void> _toUnauthenticated() async {
  await _store.clear();        // トークンだけ消す
  state = const AuthState(status: AuthStatus.unauthenticated);
  // 端末ローカルのDB(綴った言葉・写真の紐づけ)には触れない
}

レビューの指摘はこうだ。トークンしか消していないので、A さんがログアウト → 同じ端末で B さんがログインすると、A さんの綴りが B さんの本棚に残って見えてしまいます。さらにこの先「ログイン中は自動で同期」のような常時同期を入れると、B さんの同期で A さんの写真がサーバに上がってしまう経路まで開きます。指摘自体は正しい。

ここで判断が分かれる。「じゃあログアウトで端末のDBを消そう」でいいのか?

なぜ「消す」を選ばなかったか

消すと決める前に、AI に「このアプリでデータが消える経路」を一通り並べてもらった。並べたうえで、天秤にかけた。

いま綴りが消える経路天秤にかけた2つアンインストールOS の「ストレージを消去」端末の初期化(再インストールでは戻らない)+ ログアウトでも消す?消す経路を、一番踏みやすい所にもう1本守れるもの共有端末でのアカウント切替= このアプリでは現実に薄い増えるもの未同期の綴りを、ログアウトで失う= 一点物・戻らない引き合わない → 消さない守り方は「壊す」だけじゃない。全消去ではなく「持ち主が違う」の検知に寄せる

いまの同期は「選んだ写真だけを手動で web に上げる」もので、端末の全データを自動でバックアップする類のものではありません。だから未公開の綴りは端末の中にしかありません。そこへ「ログアウトでも消す」を足すと、トークンの不調で入り直そうとしただけで、まだ同期していない綴りが黙って消えます。

一方の「共有端末でアカウント切り替え」は、綴Photo では現実にかなり薄いです。アプリのログインは 紡Book のアカウント前提で、わざわざ別アカウントで入り直す動機がほとんどありません。

薄いリスクを塞ぐために、言葉が主役のアプリで一番やってはいけない「綴りを失う」を増やします。これは引き合わない。だから消さない、と決めた。

代わりに置いたもの

消さない代わりに、コードには「これは消し忘れではなく仕様だ」と理由を書き残した。レビューで同じ場所がまた「バグでは?」と指摘されないように、なぜ消さないかを判断ごとコメントにしている。

そして将来、本当に共有端末のデータ混在を塞ぎたくなったときの方向も決めておいた。**全部消す(壊して守る)のではなく、「いま入ろうとしているアカウントが、この端末のデータの持ち主と違う」を検知する(気づいて守る)**ほうだ。検知なら、取り違えが起きそうなときだけ警告できて、普通のユーザーの綴りは巻き込みません。

学びポイント

  • 「安全のために消す」は、消すこと自体がそのプロダクトの価値を壊すなら逆効果になります。 何を守るアプリかで、同じ対策の正しさが変わります。
  • データ喪失の経路を「増やす」設計は、一点物データのアプリでは特に慎重に。 すでにある喪失経路(アンインストール・データ削除)に、踏みやすい一本を足していないか。
  • 守り方は「壊す」だけじゃありません。 全消去でなく検知に寄せれば、守りたいケースだけを狙って、巻き込み事故を避けられます。

このテーマの括り

通底しているのは、定石は「何を守るアプリか」を通してから採るものだということ。「ログアウトで消す」は多くのアプリで正しいです。でも、消えてはいけないものを抱えるアプリでは、同じ対策が一番の事故装置になりえます。

一般論として正しい対策ほど、自分のプロダクトの文脈を通さずに通り過ぎてしまいやすいです。だから「これは定石だから入れる」と思ったときほど、一度「うちのアプリで、この対策が守るものと壊すものは何か」を並べてみます。今回は並べた結果、守るものより壊すもののほうが大きかった。

おわりに

レビューで「ここ、消したほうがよくないですか」と言われると、つい「たしかに」で消す方向に倒したくなります。でも消すのは不可逆です。消して守れるものと、消して失うものを両方並べてから決めると、定石に逆らう判断にも理由が立ちます。

この記事は2026年6月時点の自分の理解で書いています。仕様や認識が変わってる可能性があります。