【設計・仕様決め編】「フォト・守」の裏側に隠された、割り切りとUI/UXのリアルなトレードオフ

アプリをビルドするにあたり、最もエネルギーを使うのが「仕様決め」です。特にプライバシーやセキュリティを扱うアプリでは、機能を増やせば増やすほどユーザーの手間が増え、シンプルさが失われてしまいます。

今回は、AIと共に一つずつ課題をクリアしていった、ファイル一覧画面の仕様決め、そして一番悩んだ「データ保存先」の葛藤と見落としがちな罠について記録を残します。

1. ファイル一覧表示画面の機能と「割り切り」の仕様

高齢の両親でも直感的に使えるよう、メニュー周りはサブメニューに格納してメイン画面を極限までシンプルに保ちつつ、裏側のシステムでは以下のようなトレードオフを意識して仕様を決定しました。

サムネイル表示の最適化（画像と動画の処理分離）

一覧画面にサムネイルは必須ですが、すべてを同じタイミングで処理すると端末の動作が著しく重くなります。そこで、「画像ファイルは暗号化するその瞬間にサムネイルを作成」し、「動画ファイルは初回の再生時にサムネイル画像を暗号化して作成する」というハイブリッド方式を採用しました。重い動画処理のタイミングを後ろにずらすことで、アプリ全体の軽快さをキープしています。 *※作成した動画サムネイルのキャッシュクリア機能や、動画の再生位置の記録（レジューム再生）については、今後のバージョンアップでの再検討課題としています。*

フォルダ管理と識別性の向上

ファイルが増えても迷子にならないよう、フォルダ作成機能はもちろん、後からの「フォルダ名変更」にも対応しました。さらに、お年寄りでもパッと見で識別しやすいよう、「フォルダの色を変更できる機能」を用意しています。

暗号化の単位と、あえて「長押し」にした削除UI

使い勝手を考慮し、暗号化は「指定したファイル単体」だけでなく「指定したフォルダごと」一括で行える仕様にしました。
また、一番悩んだのが「ファイルの削除UI」です。「間違って消さないように確認ダイアログを出すべきか？」とも考えましたが、あの「本当に消しますか？」のポップアップは、日常的に使う上で非常に煩わしいものです。今回は引き算の美学としてダイアログを廃止し、「長押しによるスマートな削除UI」を採用しました。

バックアップの代替としての「個別・フォルダ復号」

セキュリティとローカル完結を最優先するため、いわゆる「クラウドバックアップ機能」は一切排除しています。しかし、利便性を完全に捨てるわけにはいきません。「フォト・守」には、画像プレビュー画面や動画再生画面でデータを暗号化したまま安全にスクリーンショットを撮る機能をつけたため、データ取り出し用として「ファイル個別、またはフォルダ毎の復号化機能」をしっかりと用意しました。

【現在迷い中】レイアウトのバリエーション（グリッド数の最適解）

現在は、一般的な「リスト表示」に加え、ベースとなる「2×2のグリッド表示」をすでに実装しています。
ただ、実際に自分で触っていると、「ファイル数が増えてきたときに、もっと一覧性が高い方が便利かもしれない」と感じるようになりました。そのため、4×4や8×8といった、さらに細分化した多段グリッド表示も用意すべきか、それともシンプルさを維持するために現在のままでいくべきか、今後のユーザーの反応を見ながら再検討したいと考えています。

今後の課題：指紋認証（生体認証）の組み込み

過去に別の開発アプリで実装経験のある「指紋認証」の機能についても、このアプリに組み込むかどうか悩んでいます。セキュリティを高めるという意味では強力ですが、アプリの最大の目標である「高齢者でも迷わないUI/UXのシンプルさ」を壊してしまわないか。こちらもバージョンアップの際の重要な課題としてストックしています。

2. 初のGoogle Play掲載と、広告に対する「実験」と「配慮」

実は、今回開発した『フォト・守』が、私にとって初めてのGoogle Playストアへの掲載（リリース）となります。

元々は自分や家族が使うためのプライベートなアプリなので、そもそも広告を載せる必要性はありませんでした。しかし、アプリをストアへ一般公開するまでの一連の手順や、Google AdMobなどの広告ライブラリの実装仕様を体系的に学ぶ「勉強」の絶好の機会でもあるため、あえて一部に広告表示を組み込んでみる実験を行いました。

もちろん、既存のアプリにありがちな「画面全体を覆い尽くすポップアップ広告」や「動画を見ようとした瞬間に強制挿入される全画面広告」は、自分がユーザーの立場なら絶対に許せない仕様です。特に高齢の両親が使うことを考えると、画面迷子の原因にししかありません。

そこで、広告を表示させる場所は**「ファイル一覧画面の最下部（ボトムバナー）」のみに徹底して限定**しました。

アプリの本来の目的である「写真のプレビュー表示」や「動画再生」を行っている最中は、広告を一切非表示にしています。大切な思い出の空間を、チラチラ動く広告で邪魔されることはありません。

広告を「UIの一部」として同化させるアプローチ

この配置に決めたもう一つの理由は、画面最下部の固定バナーであれば、ファイル一覧画面のUI（デザイン）の中に自然とシステムの一部として同化させることができるのではないか、と考えたからです。
取って付けたような邪魔なポップアップではなく、画面のレイアウトに最初から組み込まれた「帯状のエリア」として処理することで、アプリ全体のシンプルな世界観を壊さずに、技術的な実験（広告配信システムが正しく動くかどうかの検証）を両立させることができました。

3. 【一番悩んだ箇所】暗号化ファイルの保存先はどこが正解か？

このアプリの設計において、最も頭を悩ませたのが「ファイルの保存先（ストレージ領域）」でした。検討した選択肢は2つありました。

候補A：アプリ固有領域（Context.filesDirなど）

メリット：セキュリティが完璧。PCに繋いでも他アプリからも絶対に見えない。

デメリット：アプリをアンインストールすると、データが一緒に消えてしまう。

候補B：共有領域（Picturesフォルダなど）

メリット：アプリを消してもデータは残る。

デメリット：ファイル名や中身をAESで暗号化しているため、Picturesフォルダ内には「ユーザーにとっては意味不明な英数字のファイル」がゴロゴロ並ぶことになる。結果、ユーザーが「これ何だろう？」と誤って削除してしまうリスクが非常に高い。

暗号化アプリの多くがこの問題に直面しますが、私は最終的に、前回の記事でも触れた通り「このアプリはあくまで、自宅のPC等にマスターデータがあることを前提とした、持ち出し端末閲覧用のアプリである」とユースケースを完全に割り切りました。 「アンインストール時に消える」というリスクを受け入れてでも、誤削除を防ぎ、鉄壁のプライバシーを保てる**「アプリ固有領域への保存」**がこのアプリの思想にはベストである、という結論に至りました。

4. 【見落としていた点】実機テストで発覚した「スリープ」の罠

シミュレーター（エミュレーター）での開発中には全く気づかず、実機にアプリを転送して初めて見落としに気づいた致命的なポイントがありました。それが、**「大量のファイルや重い動画を暗号化・復号化している最中に、端末がスリープ（画面消灯）してしまう問題」**です。

暗号化・復号化はCPUをフルに使う重い非同期処理ですが、Androidシステム側から見ると、ユーザーが画面を操作していない時間が続くと「操作がない」と判断され、処理の途中で無慈悲にスリープに入ってしまいます。スリープに入ると処理が中断され、データ破損の原因にもなりかねません。

解決策：

処理が走っている間はシステムに対して画面を消さないように要求する、スリープ防止処理（`FLAG_KEEP_SCREEN_ON` の制御やWakeLockの適切な運用）を組み込むことで、この罠を無事に突破しました。やはり、どれだけAIが優秀でも、実機で動かして初めて分かる泥臭い罠はあるものだと痛感した瞬間です。