写真アップロード機能を、AI構築アプリに落とし穴なく実装する方法

アプリが単なるテキストの世界を出て、写真のアップロードを受け付け始めた瞬間、何かが変わります。画像やファイルのアップロード機能を追加するというのは、ユーザーが自分の端末から写真やレシート、書類をアプリに送り、アプリ側がそれを保存して後で表示できるようにすることです——プロフィール写真、レシート、破損した荷物の写真、PDFの契約書。これは、一見チェックボックスひとつで済みそうに見えて、実はいくつかの鋭い角がある機能の典型です。どれも難しいものではありません。ただ、誰も教えてくれない落とし穴は、たいてい公開から3週間後、しかも一番熱心なユーザーから報告される形でやってきます。

ここでは、誰かが「アップロード」を押した瞬間に実際に何が起きているのか、後になって効いてくる3つのミス、そしてそれを避けるためにビルダーへ正確に何を頼めばいいのかを見ていきます。

アプリに写真をアップロードすると、実際には何が起きているのか？

写真をアップロードすると、順番に4つのステップが動きます。スマホがアプリにファイルを渡す、アプリがそれを別のファイルストレージに送る（データベースではなく）、アプリがそのファイルへのリンクをレコードのそばに保存する、そして後で誰かがそのレコードを見るたびに、そのリンクを使ってファイルを取得する、という流れです。

ステップごとに見ていくとこうなります。

スマホがアプリにファイルを渡す。最近のスマホ写真は4〜12メガバイトになることも珍しくありません。決して小さくない容量です。
アプリはそのファイルをどこかに送って保存します——アプリのデータベースではなく、ファイル専用に作られた別のストレージバケットです。
アプリはそのファイルへのリンクをデータベースに保存し、レコードの他の情報と紐づけます（このレシートはこの経費に属している、というように）。
後で誰かがそのレコードを見るとき、アプリはそのリンクを使ってストレージからファイルを取得し、表示します。

多くの人がつまずくのは、このステップ2と3です。写真が「アプリの中に保存される」とイメージしてしまいがちですが、実際はそうではありませんし、そうあるべきでもありません。ファイルはストレージに置かれ、データベースはその場所を覚えているだけです。この役割分担さえ正しくしておけば、その先のすべてが楽になります。

アップロードされた写真をデータベースに直接保存すべきか？

いいえ——これはアップロードにまつわる最もよくあるミスであり、具体的に指示しない限りAIビルダーがデフォルトでやってしまうことさえあります。10MBの写真をデータベースに直接詰め込むのは、財布に家具をしまい込むようなものです。データベースは名前や日付、価格といった小さく構造化されたデータのために作られています。そこに写真を流し込めば動作は重くなり、バックアップは膨れ上がり、ある日突然、以前は一瞬で開いていたページが、何百枚もの高解像度画像を引きずっているせいで6秒もかかるようになります。

代わりに欲しいのは、ファイルはファイルストレージ（ビルダーによっては「ストレージバケット」や「blobストレージ」と呼ぶこともあります）に送り、データベースにはリンクだけを持たせる形です。これは直接こう伝えましょう。

「アップロードされた画像はデータベースではなくファイルストレージに保存してください。レコードにはファイルのURLだけを保持してください。」

誤った形式やサイズの大きすぎるファイルをアップロードされないようにするには？

事前に何を許可するか——ファイル形式、サイズの上限、わかりやすいエラーメッセージ——を決めて、ビルダーに明確に伝えます。そうしたルールがないと、アプリはどんなファイルでも受け入れてしまい、中にはアップロードそのものを完全に固まらせるファイルも含まれます。テストでは問題なく動いていたアプリで実際に起きた2つの例を見てみましょう。

ある女性は小さなケータリング事業を営んでおり、クライアントが好みのケーキ写真をアップロードできるアプリを作りました。しばらくは問題なく動いていましたが、あるクライアントがプロ用カメラで撮った47MBの写真をそのままアップロードしたところ、アップロードが固まってしまい、そのクライアントは諦めてしまいました。彼女の耳に入ったのは「あなたのアプリ、壊れてる」という声でした。実際には壊れていたわけではなく、単にサイズ上限を設定していなかったため、巨大なファイルを延々と飲み込もうとし続けていただけだったのです。

もう一つの例。あるフリーランサーが、クライアントが「自分のロゴ」をアップロードできるクライアントポータルを作りました。あるクライアントは.zipファイルをアップロードし、別のクライアントは90ページのPDFをアップロードしました。アプリはそのすべてを受け入れてしまいました。ロゴとはどういうものかを、誰もアプリに伝えていなかったからです。

事前に次の3つを決めておきましょう。

どのファイル形式を許可するか？ 写真だけなら、JPGとPNGを受け入れ、それ以外は親切なメッセージとともに拒否します。
どれくらいの大きさまで許可するか？ 写真の上限としては5〜10MB程度が妥当です。実際のスマホ写真には十分な大きさで、カメラからの丸ごとダンプは防げる大きさです。
形式が違ったらどうするか？ アプリはそれを丁寧に伝えるべきです——「JPGまたはPNGで、10MB以下のファイルをアップロードしてください」というように——ただ固まるのではなく。

ビルダーにはこう伝えます。

「JPGとPNG画像のみ、10MBまでを許可してください。それ以外の形式や大きすぎるファイルがアップロードされた場合は、黙って失敗するのではなく、わかりやすいメッセージを表示してください。」

写真がたくさんあると、なぜアプリが遅く感じるのか？

それは、閲覧者が毎回、縮小版ではなくフルサイズのオリジナルをダウンロードしてしまうからです——スマホで、しかもデータ通信を使って、レコードを開くたびに毎回。たとえば誰かがくっきりした8MBの写真をアップロードしたとして、それ単体なら問題なく動きます。でもそれが20枚並んだギャラリーになると、あなたの快適だったアプリは急に泥の中を歩くように重くなります。

この解決策には名前があり、覚えておく価値があります。ビルダーもその言葉を認識してくれるはずです——サムネイル、つまりリサイズ版です。考え方はシンプルで、オリジナルは保持しつつ、小さくてウェブに適したコピーも作り、一覧やプレビューではその小さいコピーを表示するというものです。フルサイズの画像は、誰かが実際に大きく見たいときだけ読み込まれます。

「画像がアップロードされたら、プレビューや一覧用に小さくリサイズしたバージョンも作成してください。デフォルトでは小さいバージョンを表示し、誰かがクリックして表示しようとしたときだけフルサイズの画像を読み込んでください。」

これがどう実装されるかを理解する必要はありません。ただ、それが存在する選択肢だと知っておけば、アプリが遅く感じてから頼むのではなく、その前に頼めます。

決めておくと得をする、地味だけれど大事なこと

以下の3つは、決めなくてもすぐにアプリが壊れるわけではありませんが、今のうちに決めておいたほうが、後から作り直すより確実に安上がりです。誰がファイルを見られるか、レコードが削除されたときファイルはどうなるか、そしてスマホでもアップロードできるか、の3つです。

誰がファイルを見られるか？ プロフィール写真なら誰でも見られて問題ありません。しかし、身分証のスキャンや署名済みの契約書はそうではありません。ファイルが非公開であるべきなら、そのリンクは誰でも開ける公開URLではなく、ログインを必要とするものにするようビルダーに伝えましょう。機密性のあるものについては、この点を最も強く念押ししておきたいところです。
レコードが削除されたときファイルはどうなるか？ 誰かが経費を削除したら、そのレシート写真も一緒に片付けられるべきでしょうか？そうしないと、いつの間にか使われなくなったファイルが積み上がり、知らないうちに保存料金を払い続けることになります。
スマホでも動くか？ アップロードの多くはスマホで行われ、スマホには「今すぐ写真を撮る」と「ライブラリから選ぶ」の両方の選択肢があります。ファイルをドラッグして放り込むだけのノートパソコンだけでなく、実機のスマホで両方をテストしましょう。

他人になったつもりでテストする

「完成した」と言う前に、実際のユーザーが思わずやってしまいそうな形でわざと壊してみましょう——普通の写真、サイズの大きすぎるファイル、間違ったファイル形式、実際のスマホカメラからのアップロード、そして削除です。

普通のスマホ写真をアップロードする。表示されるか、プレビューは速いか？
巨大なファイルをアップロードする。アプリはわかりやすいメッセージで止めてくれるか、それともただ固まるだけか？
間違った形式をアップロードする——写真が期待される場所にPDFを入れてみる。ルールを説明してくれるか？
スマホでアプリを開き、カメラから直接アップロードする。
レコードを削除し、そのファイルが自分の決めた通りに処理されるか確認する。

この5つすべてが期待通りに動けば、多くの人がつまずくポイントはクリアできたと言えます。

アップロード機能は、「デモではうまくいく」状態と「電車の中で12MBの猫写真を持った見知らぬ誰かでもちゃんと動く」状態の差が、まさに上で挙げた決定事項そのものになる機能です。どれも難しくはありません。ただ、つい省略してしまいやすいだけです——そして、後から修理するより、今のうちに頼んでおくほうがずっと簡単です。

「技術的なハードルが高そうだから」とアップロード機能の追加を先延ばしにしていたなら、実際はそうではありません。ビルダーを開いて、サイズ上限とサムネイル付きの画像ストレージを頼んでみてください。何が返ってくるか見てみましょう。それから、実機のスマホでわざと壊しにいってみてください——それが本当のテストであり、5分もあれば終わります。