前回のエラー応答から、保存の話へ

前回のJ-08では、失敗したときのエラー応答の設計を学びました。今回は、処理が成功したデータをどこへしまうかという保存の話です。バックエンドの5責務のうち、DBへの保存・取得の指示に関わる場面です。ただし、保存するデータには2つの種類があり、それぞれ置き場所が違う、という点をここで押さえます。
このスライドのポイント
- J-08: 失敗したときのエラー応答の設計(中は詳しく、外へは最小限)を学んだ
- 今回: 処理が成功したデータを「どこへしまうか」の保存の話
- バックエンドの5責務(J-01)のうち、DBへの保存・取得の指示に関わる場面
- ポイント: 保存するデータには2種類あり、置き場所が違う
オブジェクトストレージと定石

まず用語を定義します。オブジェクトストレージとは、画像・PDF・動画などのファイルをそのままの形で保存しておく置き場です。B-03で学んだストレージの、クラウド版だと考えてください。ここで定石を1つ覚えます。ファイル本体はオブジェクトストレージへ置き、データベースにはその場所、つまりURLやキーと、誰が・いつ・何を、といったメタ情報だけを保存します。データベースそのものの仕組みは、カテゴリLで詳しく扱います。
このスライドのポイント
- オブジェクトストレージ=画像・PDF・動画などのファイルをそのままの形で保存する置き場(B-03のストレージのクラウド版=C-02)
- 定石: ファイル本体はオブジェクトストレージへ置く
- データベースには、その場所(URLやキー)と、メタ情報(誰が・いつ・何を)だけを保存する
- データベースそのものの仕組みはカテゴリLで詳しく扱う
なぜファイルをデータベースに入れないのか

この定石を知らないと、AIが画像をデータベースに直接保存する設計を出してきても、問題に気づけません。ファイル本体をデータベースに入れると、データベースが急激に肥大化し、検索が遅くなり、バックアップも重くなります。領収書の画像を扱う経費アプリでは、この論点に最初から直面します。AIは指定がなければ手近な保存方法を選びがちなので、だからこそ、置き場所の判断を人間が持っておく必要があります。
このスライドのポイント
- 知らないと: AIが「画像をデータベースに直接保存」する設計を出しても問題に気づけない
- ファイル本体をデータベースに入れると起きること: データベースの肥大化/検索が遅くなる/バックアップが重くなる
- 領収書画像を扱う経費アプリでは、この論点に最初から直面する
- AIは指定がなければ手近な方法を選びがち=人間が判断を持つ
2つの置き場所の構造

構造を図で見ます。置き場所は2つに分かれます。左のオブジェクトストレージには、領収書の画像ファイルそのものが入ります。右のデータベースには、申請IDや金額と一緒に、そのファイルがどこにあるかを指す場所の情報が入ります。データベースの側からファイルの場所を指し示す、という関係です。本体と場所を分けて持つ、この形が基本です。こうしておくと、ファイルが増えてもデータベースは軽いままで済みます。
このスライドのポイント
- 置き場所は2つに分かれる
- オブジェクトストレージ: 領収書の画像ファイルそのもの(本体)
- データベース: 申請IDや金額と一緒に、ファイルの場所を保存
- 関係: データベースの側から、ファイルの場所を指し示す
経費申請の領収書で流れを追う

具体例で流れを追います。経費申請で領収書を添付する場合、画像本体はオブジェクトストレージに保存されます。一方、データベースの1行には、expense_idという申請の識別情報と、receipt_urlというファイルの場所が記録されます。A-08で決めた保存データの設計が、ここで2つの置き場所に分かれるわけです。金額のように集計する情報はデータベース、領収書のように出し入れするファイルはストレージ、と役割で分けて考えます。
このスライドのポイント
- 経費申請で領収書を添付する場合の設計
- 画像本体 → オブジェクトストレージに保存
- データベースの1行 → expense_id(申請の識別情報)と receipt_url(ファイルの場所)を記録
- A-08で決めた「保存データ」の設計が、2つの置き場所に分かれる
- 集計する情報はデータベース、出し入れするファイルはストレージ
技術サンプル: アップロードの流れ

サンプルはアップロードの流れです。利用者が画面でファイルを選び、サーバーへ送ります。サーバーはまず本体をストレージへ保存し、次にその場所をデータベースへ書き込み、最後に応答を返します。この①と②の順序が大切で、片方だけ成功して片方が失敗すると、置き場所にゴミのようなファイルや、行き先のない場所情報が残ります。AIに保存機能を作らせたら、この2段階のどちらかが抜けていないかを必ず確認してください。
構造化データとファイルの違い

混同しやすいのは、構造化データとファイルの区別です。金額や日付のように、検索したり集計したりするデータは、データベースに入れます。画像やPDFのように、中身を検索せずそのまま出し入れするものは、オブジェクトストレージに入れます。データの使い方が、置き場所を決めます。検索や集計をするならデータベース、そのまま出し入れするだけならオブジェクトストレージ、と覚えておくと迷いません。
このスライドのポイント
- 構造化データ(金額・日付など、検索・集計する)→ データベース
- ファイル(画像・PDFなど、そのまま出し入れする)→ オブジェクトストレージ
- 判断の基準: データの「使い方」が置き場所を決める
バイブコーディングでの確認点

バイブコーディングでの確認点です。ファイルを扱う機能をAIに作らせたら、3点を確認してください。1つ目はファイル本体の置き場、2つ目はデータベースに残す情報、3つ目は誰がそのファイルにアクセスできるか、というA-08の公開範囲です。質問例は、このアプリのファイル保存はどこに置く設計ですか、データベースに直接保存していませんか、です。
このスライドのポイント
- ファイルを扱う機能をAIに作らせたら、3点を確認する
まとめと次回

最後に一問一答です。領収書画像の本体は、データベースとオブジェクトストレージのどちらへ保存するでしょうか。……答えは、オブジェクトストレージです。データベースには、その場所とメタ情報だけを保存します。30秒でまとめます。ファイルはデータベースに入れず、本体はストレージ、データベースには場所、という定石を覚えてください。次回はカテゴリJの最終回、サーバーは状態を持つべきか、というステートレスの話へ進みます。関連資料は、業務アプリDB設計パターン50と、Supabase入門ハンドブックです。
このスライドのポイント
- 一問一答: 領収書画像の本体は、データベースとオブジェクトストレージのどちらへ保存する?
- 答え: オブジェクトストレージ(データベースには場所とメタ情報だけ)
- 30秒まとめ: 本体はストレージ、データベースには場所
- 次回: J-10 サーバーは状態を持つべきか(ステートレス)
- 関連資料: 「業務アプリDB設計パターン50」「Supabase入門ハンドブック」