添付ファイル管理の設計ポイント｜保存先・ファイル名・権限・削除をどう決めるか

業務システムを開発するとき、

「案件にPDFを添付したい」
「顧客ごとに契約書を保存したい」
「申請時にExcelや画像をアップロードできるようにしたい」

といった添付ファイル機能が必要になることがあります。

ファイルアップロード自体は一般的な機能ですが、本番の業務システムとして運用する場合は、

• ファイルをどこへ保存するか
• データベースとはどう紐付けるか
• ファイル名をどう管理するか
• 誰が閲覧・ダウンロードできるか
• どの拡張子を許可するか
• 1ファイル何MBまで許可するか
• 削除したファイルをどう扱うか
• 同じ資料を更新した場合は上書きするか
• 退職者がアップロードしたファイルをどうするか
• 不正なファイルのアップロードをどう防ぐか

まで考える必要があります。

結論からいうと、添付ファイル管理の設計では、

「ファイルそのもの」と「ファイルを管理するための情報」を分けて考えることが重要です。

一般的には、ファイル本体はオブジェクトストレージなどへ保存し、データベースには、

• ファイルID
• 元のファイル名
• 保存先
• MIMEタイプ
• サイズ
• 登録者
• 登録日時
• 関連する業務データ

などのメタデータを持たせる設計が考えられます。

この記事では、業務システムの添付ファイル管理を設計するときに押さえておきたいポイントを、具体例とともに解説します。

添付ファイル管理は「アップロード画面」だけの機能ではない

添付ファイル機能というと、

「ファイルを選択してアップロードする」

画面を想像しがちです。

しかし実際の業務では、その後の管理まで必要です。

例えば契約管理システムなら、

1. 契約情報を登録
2. 契約書PDFをアップロード
3. 契約情報とPDFを紐付け
4. 担当者が閲覧
5. 管理者がダウンロード
6. 契約更新時に新しい契約書を登録
7. 過去契約書も必要に応じて参照
8. 契約削除時のファイル処理を実行

といった流れがあります。

つまり設計する対象は、

アップロード・保存・参照・更新・削除というファイルのライフサイクル全体

です。

添付ファイル管理で最初に決めるべきこと

いきなりAWS S3などの技術を選ぶのではなく、まず業務上の利用方法を整理します。

例えば次の項目です。

• 誰がアップロードするのか
• 誰が閲覧するのか
• 誰が削除できるのか
• どの種類のファイルを扱うのか
• 1件につき何ファイル保存するのか
• 1ファイルの最大容量はどの程度か
• 何年間保存する必要があるのか
• 過去バージョンを残す必要があるか
• 社外ユーザーもアクセスするのか

例えば、

「社員20人が利用し、案件ごとにPDFを最大5件保存する」

システムと、

「顧客1万人が画像を自由にアップロードできる」

サービスでは、必要な設計が大きく異なります。

1．添付ファイルの保存先を決める

最初の大きな論点が保存先です。

主な方法として、

• Webサーバー上のファイルシステム
• データベース
• オブジェクトストレージ

などがあります。

Webサーバーへ保存する

例えば、

/uploads/contracts/xxx.pdf

のようにアプリケーションが動いているサーバーへ保存する方法です。

小規模なシステムでは実装しやすい一方、

• サーバーを複数台にすると共有しにくい
• サーバー交換時にファイル移行が必要
• バックアップ管理が複雑になる
• アプリケーションとファイル容量が競合する

といった問題があります。

本番のWebシステムでは、長期運用を考えて別ストレージへ分離することがあります。

データベースへファイルそのものを保存する

PDFや画像をバイナリデータとしてDBへ保存する方法もあります。

データとファイルを一体として管理しやすい場合がある一方、大量のファイルを保存するとデータベース容量が増えます。

バックアップやリストアも重くなる可能性があります。

そのため、

「DBに保存できるから全部DBへ入れる」

ではなく、運用規模を考えて判断します。

オブジェクトストレージへ保存する

Webシステムでは、

• Amazon S3
• Google Cloud Storage
• Azure Blob Storage
• その他S3互換ストレージ

などのオブジェクトストレージを利用する構成があります。

概念的には、

ユーザー
↓
Webシステム
↓
ストレージへファイル保存

という構成です。

ファイル本体をストレージへ保存し、DBにはそのファイルを識別する情報だけを持たせます。

大量ファイルを扱いやすく、Webアプリケーション本体とファイル保存領域を分離できるのが特徴です。

ファイル本体とDBのメタデータを分けて管理する

例えば案件管理システムで契約書を保存するとします。

ファイル本体：

契約書PDF → オブジェクトストレージ

データベース：

項目	内容
file_id	F000123
entity_type	project
entity_id	P000456
original_name	A社_契約書.pdf
storage_key	attachments/2026/uuid.pdf
mime_type	application/pdf
size	245678
uploaded_by	U001
uploaded_at	2026/08/10

というように分けます。

この設計なら、

「案件P000456に紐付くファイルを一覧表示する」

といった検索をDB上で行い、実際のファイルだけストレージから取得できます。

2．保存時のファイル名をどうするか

添付ファイル管理で意外に重要なのがファイル名です。

ユーザーがアップロードするファイル名には、

• 契約書.pdf
• 見積書（最終）.pdf
• 2026年8月請求書.xlsx
• IMG_1234.jpg

などさまざまな名前があります。

そのまま保存先のファイル名として利用すると、同名ファイルがアップロードされた場合に衝突する可能性があります。

例えば、

契約書.pdf

を2人がアップロードした場合です。

そのため保存時には、UUIDなどを利用して一意な名前に変換する方法があります。

例えば、

元ファイル名：
A社_契約書.pdf

保存時：
550e8400-e29b-41d4-a716-446655440000.pdf

とします。

ただしユーザーには、

A社_契約書.pdf

と表示します。

つまり、

表示用の元ファイル名と、システム内部の保存名を分けます。

ファイル名だけで業務上の意味を管理しない

例えば、

契約書A社_20260810確定版.pdf

というファイル名だけで、

• 顧客
• 契約日
• バージョン
• ステータス

を判断する設計は避けたほうが管理しやすくなります。

業務上重要な情報はDB側で、

顧客：A社
契約日：2026/08/10
種類：契約書
バージョン：3
状態：確定

のように管理します。

ファイル名はあくまで表示情報として扱うほうが、検索・集計・変更に対応しやすくなります。

3．どの業務データに紐付くファイルなのかを設計する

添付ファイル単独ではなく、通常は何らかの業務データへ紐付きます。

例えば、

• 顧客
• 案件
• 契約
• 申請
• 商品
• 問い合わせ
• 従業員

などです。

例えば案件管理なら、

案件P001
├─ 見積書.pdf
├─ 契約書.pdf
└─ 仕様書.xlsx

という関係です。

DBでは、

file_id
project_id
file_type
original_name
storage_key

などを管理します。

1件につき1ファイルか複数ファイルかも決める

例えば社員プロフィール画像なら、

社員1人につき画像1枚

でよいかもしれません。

一方、案件資料なら、

案件1件につき複数ファイル

が必要です。

この違いはDB設計にも影響します。

さらに、

• 契約書
• 見積書
• 発注書
• その他資料

のようにファイル種別を持たせるかも検討します。

4．誰がファイルを閲覧できるか決める

添付ファイル管理ではアクセス権限が非常に重要です。

よくある問題が、

画面へのアクセス権限は設定されているのに、ファイルURLを知っていれば直接ダウンロードできる

状態です。

例えば顧客管理画面で、

一般社員：
自分の顧客だけ閲覧可能

という制御をしていても、

https://example.com/files/customer-a-contract.pdf

へ直接アクセスすればダウンロードできるのであれば、権限制御が不十分です。

ファイル本体も非公開にする

業務システムで個人情報や契約書などを扱う場合は、ストレージ自体を公開状態にせず、

ユーザー
↓
ログイン確認
↓
権限確認
↓
ダウンロード許可

という流れにします。

例えば、

「このユーザーは案件P001を閲覧できるか」

を確認したうえでファイルを取得させます。

署名付きURLを利用する方法

オブジェクトストレージでは、一時的に有効なURLを発行する仕組みがあります。

例えば、

1. ユーザーがダウンロードボタンをクリック
2. システムがログイン状態を確認
3. 案件への閲覧権限を確認
4. 数分間だけ有効なURLを発行
5. ユーザーがダウンロード

という流れです。

これにより、ストレージ全体をインターネットへ公開せずにファイルを提供できます。

5．アップロードできるファイル種類を制限する

ファイルアップロード機能で、

「どんなファイルでもアップロード可能」

にするのは避けたほうがよいでしょう。

業務上必要なファイルに限定します。

例えば、

• PDF
• JPEG
• PNG
• Excel
• Word

などです。

契約書管理なら、

PDFのみ

でもよいかもしれません。

画像アップロードなら、

JPEG・PNG

だけで十分な場合があります。

必要な形式だけ許可することで、不正ファイルのアップロードリスクを下げられます。

拡張子だけを信用しない

例えば、

malware.exe

を、

document.pdf

へ名前変更しただけでアップロードできてしまう設計は避ける必要があります。

そのため、

• 拡張子
• MIMEタイプ
• 必要に応じてファイル内容

などを確認します。

単純にファイル名の末尾だけで判定するのではなく、複数の観点で検証することが重要です。

6．ファイルサイズの上限を決める

添付ファイルには容量制限を設けることが一般的です。

例えば、

1ファイル：10MBまで

1案件：最大20ファイル

などです。

制限がないと、

• 数GBのファイルをアップロードされる
• ストレージ料金が増える
• 通信時間が長くなる
• サーバー負荷が高くなる

可能性があります。

要件定義では、

• 1ファイル最大容量
• 1回のアップロード件数
• 1ユーザーの保存量
• 1案件の保存量

などを検討します。

7．大容量ファイルは直接ストレージへアップロードする方法もある

小さなPDF程度なら、

ブラウザ
↓
Webサーバー
↓
ストレージ

でも問題にならない場合があります。

しかし大容量ファイルの場合、

ブラウザ
↓
ストレージ

へ直接アップロードする方式もあります。

例えばシステムが一時的なアップロードURLを発行し、そのURLを使ってファイルをストレージへ送信します。

これにより、Webサーバーを巨大なファイルが通過しないため、アプリケーションサーバーへの負荷を抑えやすくなります。

8．アップロードされたファイルの安全性を確認する

社外ユーザーも利用するシステムでは、悪意のあるファイルをアップロードされる可能性も考える必要があります。

例えば、

• マルウェア
• 不正なスクリプト
• 想定外のファイル形式
• 極端に大きなファイル

などです。

必要に応じて、

ファイル受信
↓
一時保存
↓
チェック
↓
安全なら利用可能
↓
問題があれば隔離・削除

という構成を検討します。

重要度の高いシステムでは、マルウェアスキャンなども選択肢になります。

9．アップロード直後に公開しない設計もある

ファイルチェックを行う場合、

UPLOADING
↓
SCANNING
↓
AVAILABLE

のようなステータスを持たせることがあります。

問題があれば、

REJECTED

とします。

利用者画面では、

「セキュリティチェック中」

などと表示できます。

10．ファイルの削除をどう扱うか

添付ファイル管理では削除も重要です。

例えばユーザーが、

「契約書を削除」

した場合に、

• DBのレコードだけ削除する
• ストレージ上のファイルも即削除する
• 一定期間ごみ箱へ残す

など複数の方法があります。

論理削除を使う方法

誤削除に備えて、

削除済みフラグ

を持たせることがあります。

例えば、

active
↓
deleted

とします。

通常画面には表示しませんが、管理者が一定期間復元できるようにします。

その後、

「30日経過後にストレージから完全削除」

といった処理も考えられます。

業務データ削除時の添付ファイルも考える

例えば案件P001を削除した場合、

案件に紐付いていた、

• 見積書
• 契約書
• 画像

をどうするのか決めておく必要があります。

業務データだけ削除しファイルがストレージへ残り続けると、どこからも参照されない「孤児ファイル」が増えます。

反対に案件削除と同時に契約書まで完全削除すると、監査や問い合わせで困る可能性があります。

そのため、

• 業務上の保存期間
• 法令や社内規程
• 復元要件

などを踏まえて決めます。

11．ファイルを上書きするか、バージョンを残すか

業務資料では、

仕様書v1.xlsx 仕様書_v2.xlsx 仕様書最終.xlsx
仕様書_最終修正版.xlsx

のような状態になりがちです。

システム側でバージョン管理する方法もあります。

例えば、

ファイル	バージョン	状態
仕様書	1	過去
仕様書	2	過去
仕様書	3	最新

と管理します。

ユーザーには最新だけ表示し、

「過去バージョンを見る」

から履歴を確認できるようにする方法があります。

上書きすると過去の状態が追えなくなる

例えば契約書をそのまま上書きすると、

「2025年時点ではどの内容だったか」

を確認できなくなる可能性があります。

契約・申請・承認・仕様書など、過去状態が重要な資料ではバージョン管理を検討します。

12．誰がアップロード・削除したかを記録する

添付ファイルも操作ログの対象になります。

例えば、

• アップロード
• ダウンロード
• 削除
• 復元
• バージョン更新

などです。

最低限、

誰が
いつ
どのファイルを
何に対して
何をしたか

を記録するとトラブル調査に役立ちます。

例えば、

2026/08/10 10:30
山田太郎
案件P001
「A社_契約書.pdf」をアップロード

といった履歴です。

ダウンロード履歴が重要なケースもある

個人情報や機密資料の場合、

「誰がファイルを持ち出したか」

が重要になることがあります。

例えば、

• 顧客一覧CSV
• 人事資料
• 契約書
• 給与関連資料

などです。

その場合は閲覧だけでなくダウンロード履歴も検討します。

すべてのシステムで必要ではないため、データの重要度に応じて判断します。

13．ファイルの保存期間を決める

ファイルを無期限に保存し続けると、ストレージ容量が増え続けます。

例えば、

• 契約終了後7年間保存
• 退会から一定期間保存
• 一時アップロードファイルは24時間で削除
• エクスポートファイルは7日間で削除

など、用途によって保存期間を分けることがあります。

特に、

「CSV出力結果を一時ファイルとして生成する」

ような機能では、永続保存する必要がないケースも多いでしょう。

一時ファイルと正式ファイルを分ける

例えば、

正式ファイル

• 契約書
• 申請書
• 納品資料

長期保存する。

一時ファイル

• CSVエクスポート
• 一括PDF
• インポート途中ファイル

短期間で自動削除する。

というルールに分けると管理しやすくなります。

14．バックアップと復旧も考える

ファイルストレージを利用しているからといって、削除事故が絶対に起きないわけではありません。

例えば、

• 管理者による誤削除
• プログラム不具合
• ストレージ設定ミス

などがあります。

重要なファイルでは、

• バージョニング
• バックアップ
• 別領域への複製
• 削除保護

などを検討します。

重要なのは、

「バックアップされているか」

だけでなく、

削除してしまったときに実際に復元できるか

です。

添付ファイル管理の設計例

例えば顧客・案件管理システムで、案件資料を保存するとします。

業務要件

• 案件ごとに複数ファイル登録
• PDF、Excel、Word、画像を許可
• 1ファイル20MBまで
• 営業担当と管理者だけ閲覧可能
• 一般ユーザーは削除不可
• 管理者のみ削除可能
• 削除後30日間は復元可能
• アップロード履歴を記録

システム構成

ユーザー
↓
Webシステム
↓
認証・権限確認
↓
ファイル検証
↓
オブジェクトストレージ保存
↓
DBへメタデータ登録

DBで管理する情報

項目	内容
file_id	ファイル内部ID
project_id	関連案件
original_name	元のファイル名
storage_key	ストレージ上の保存先
mime_type	ファイル種類
size	ファイル容量
uploaded_by	登録ユーザー
uploaded_at	登録日時
status	有効・削除済み等

このように整理すると、保存・検索・権限・削除を一貫して管理できます。

【コピペ用】添付ファイル管理の要件整理チェックリスト

添付ファイル機能を開発会社へ相談するときは、次の項目を整理すると話を進めやすくなります。

利用方法

• [ ] 何のデータにファイルを添付するか
• [ ] 1件につき1ファイルか複数ファイルか
• [ ] 社内ユーザーのみ利用するか
• [ ] 顧客・取引先もアップロードするか

ファイル種類

• [ ] PDF
• [ ] Excel
• [ ] Word
• [ ] JPEG
• [ ] PNG
• [ ] その他必要な形式を整理した

容量

• [ ] 1ファイル最大容量を決めた
• [ ] 1回の最大アップロード件数を決めた
• [ ] 大容量ファイルを扱うか確認した

保存

• [ ] ファイル保存先を決める
• [ ] 元ファイル名を保持する
• [ ] システム内部の保存名を一意にする
• [ ] DBとファイルの紐付け方法を決める

権限

• [ ] アップロードできる人を決めた
• [ ] 閲覧できる人を決めた
• [ ] ダウンロードできる人を決めた
• [ ] 削除できる人を決めた
• [ ] ファイルURLへの直接アクセスを制限する

セキュリティ

• [ ] 許可するファイル形式を制限する
• [ ] ファイルサイズを制限する
• [ ] MIMEタイプ等を確認する
• [ ] 必要に応じてマルウェアチェックを行う
• [ ] ストレージを不用意に公開しない

更新・削除

• [ ] 上書き可能か決めた
• [ ] 過去バージョンを残すか決めた
• [ ] 削除後の復元期間を決めた
• [ ] 完全削除のタイミングを決めた
• [ ] 関連データ削除時の扱いを決めた

ログ・運用

• [ ] アップロード履歴を残す
• [ ] 削除履歴を残す
• [ ] 必要に応じてダウンロード履歴を残す
• [ ] 保存期間を決める
• [ ] バックアップ・復旧方法を確認する

すべての項目を最初から決める必要はありません。

例えば、

「案件ごとにPDFやExcelを5件程度保存したい」
「社外には見せない」
「削除は管理者だけにしたい」

まで分かれば、そこから必要な設計を具体化できます。

添付ファイル管理でよくある失敗

ファイルをWebサーバーへ置くだけ

小規模な検証環境では問題なくても、サーバーの移行や複数台構成になったときに管理が難しくなる可能性があります。

長期運用を想定して保存先を決めましょう。

元のファイル名をそのまま保存名にする

同じ名前のファイルによる上書きや、扱いにくい文字列の問題が発生する可能性があります。

内部保存名と表示名を分ける方法があります。

URLを知っていれば誰でも見られる

業務画面に権限制御があっても、ファイル本体が公開状態なら情報漏えいにつながります。

ファイル取得時にも認証・認可を行うことが重要です。

拡張子だけチェックする

ファイル名だけで形式を判断すると、不正なファイルを偽装される可能性があります。

ファイル形式の検証方法を設計しましょう。

ファイルサイズに上限がない

巨大ファイルのアップロードによって、サーバーやストレージへ過度な負荷がかかる可能性があります。

業務上必要な最大容量を決めます。

DBだけ削除してファイルが残り続ける

画面上では削除されているのに、ストレージには不要なファイルが蓄積し続けることがあります。

削除処理や定期的なクリーンアップも設計します。

上書きして過去資料が消える

契約書や仕様書などでは、過去バージョンが重要になることがあります。

上書きでよいのか、履歴を残すべきなのかを業務側と確認しましょう。

添付ファイル管理に関するよくある質問

添付ファイルはDBに保存したほうがよいですか？

必ずしもDBへファイル本体を保存する必要はありません。

Webシステムでは、ファイル本体をオブジェクトストレージへ保存し、DBにはファイル名や保存先、関連データIDなどを保持する設計もよく利用されます。

ファイル数や容量、バックアップ、運用方法を考えて選択します。

S3などに保存すれば、そのURLをDBへ保存するだけでよいですか？

保存先を識別する情報をDBへ持たせる方法はありますが、公開URLをそのまま誰でも閲覧できる状態にするのは注意が必要です。

機密ファイルの場合は非公開ストレージにし、認証・権限確認後に一時URLを発行する構成などを検討します。

ファイル名は変更したほうがよいですか？

内部保存名は一意なIDへ変更し、元ファイル名は別項目として保持する設計が扱いやすいケースがあります。

これにより同名ファイルの衝突を防ぎながら、ユーザーには元の名前を表示できます。

ファイルを削除したらすぐ完全削除するべきですか？

業務によります。

誤削除から復元したい場合は一定期間論理削除状態にし、その後完全削除する方法があります。

契約書など保存義務や監査上の要件がある資料については、業務ルールを確認してから決める必要があります。

添付ファイルの閲覧履歴は必要ですか？

すべてのファイルで必要とは限りません。

個人情報や機密性の高いファイルで、

「誰が閲覧・ダウンロードしたか」

を後から確認する必要がある場合は、履歴を残すことを検討します。

画像やPDFをブラウザ上でプレビューできますか？

可能です。

ただし、プレビュー時にもユーザーの閲覧権限を確認する必要があります。

ダウンロードボタンだけ制御して、プレビューURLは誰でもアクセスできる状態にならないよう注意しましょう。

hiro-dev-labでは添付ファイル管理を含む業務システムの設計から相談できます

添付ファイル機能は、

「PDFをアップロードできればよい」

というところから始まっても、実際に要件を整理すると、

• 案件ごとに複数ファイルを持たせたい
• 契約書だけ削除権限を制限したい
• 顧客には一部資料だけ公開したい
• 過去バージョンも残したい
• ダウンロード履歴を確認したい

といった業務ルールが出てくることがあります。

hiro-dev-labでは、現在のファイル管理方法を確認しながら、

• 業務ヒアリング
• 要求整理
• 要件定義
• ファイル管理設計
• 権限設計
• データ設計
• 操作ログ設計
• 画面一覧作成
• Webシステム設計
• 業務システム開発

などを検討できます。

例えば現在、

「共有フォルダに顧客名のフォルダを作り、その中に契約書や見積書を保存している」

のであれば、

顧客
↓
案件
↓
ファイル種別
↓
添付ファイル

という構造へ整理し、システム上から検索・閲覧できる形へ変えることもできます。

まだ保存先やクラウドサービスが決まっていなくても、現在の業務と必要な権限から適切な構成を検討できます。

まとめ｜添付ファイル管理は「保存する」だけでなくライフサイクル全体を設計する

添付ファイル管理では、ファイルアップロード画面だけを作れば終わりではありません。

少なくとも、

• どこへ保存するか
• DBとどう紐付けるか
• 保存時のファイル名をどうするか
• 誰が閲覧・ダウンロードできるか
• どのファイル形式を許可するか
• 容量をどこまで許可するか
• 不正ファイルをどう防ぐか
• 上書きかバージョン管理か
• 削除後どうするか
• どのくらい保存するか
• 操作履歴を残すか
• バックアップ・復旧をどうするか

まで考える必要があります。

特に重要なのは、

ファイル本体と、ファイルを管理するためのメタデータ・権限を分けて設計することです。

例えばファイル本体はオブジェクトストレージへ保存し、

• ファイルID
• 元ファイル名
• 関連案件
• 登録者
• 登録日時
• ファイル種別
• 状態

などをDBで管理すれば、業務システムとして検索・権限・履歴を実装しやすくなります。

添付ファイルは一度導入すると、契約書、見積書、画像、申請資料などが長期間蓄積していきます。

後から保存先や権限構造を変更するのは負担が大きくなるため、システム開発時点で「アップロード後にどう管理するか」まで整理しておくことが重要です。