ファイル添付機能の開発依頼｜種類・権限・削除を決める

ファイル添付機能の開発を依頼するとき、「文書を登録して後から開ける」だけでは見積条件が定まりません。許可する形式と容量、誰が取得・差し替え・削除できるか、危険なファイルをどう扱うか、いつまで残すかを先に決める必要があります。

発注前には、添付ファイルの入口から削除までをつないだ確認表を作ります。画面の要望とともに、未決定の項目へ「初回見積に含める」「追加範囲として分ける」「運用で決めてから再見積する」のどれかを記します。ただし、各欄にどこまで具体的な条件を書くべきかは迷いやすいところです。

ファイル添付機能の開発前に使う発注確認表

以下は、公式資料の推奨事項と個人データの管理指針を、発注者が判断できる形にした運用上の提案です。そのまま仕様とせず、自社で扱う文書と利用者の役割に合わせて記入してください。

この表では、機能名に条件と確認方法を対応させます。「添付」「セキュリティ対応」「削除可能」といった短い記載だけでは、開発対象と運用担当の作業を切り分けられません。要件全体の抜けを整理する場合は、システム要件定義のチェックリストと併用すると、利用者や業務フローとの関係も確認できます。

許可形式と容量は別々に決める

許可形式の欄には、利用者が実際に扱う文書の拡張子を記します。「一般的な文書はすべて」という曖昧な指定を避け、業務に必要なものを許可対象として列挙し、対象外を拒否する条件まで発注先へ渡します。

2026年9月21日時点で、OWASPのFile Upload Cheat Sheetは、業務上必要な拡張子だけを許可リストにすることを推奨しています。また、利用者が送るContent-Typeヘッダーは偽装できるため信頼せず、ファイル署名の検証も単独では使わないよう勧めています。したがって、発注書には「拡張子を限定する」だけでなく、形式の検証方法を発注先と確認する欄を設けます。

容量は形式と同じ欄にまとめません。1ファイルの上限をどうするか、圧縮ファイルを許可するか、受け取った圧縮ファイルをシステムで展開・処理するかを分けます。OWASPは、保存容量を守るため適切なファイルサイズ上限を設け、圧縮ファイルを展開・処理する場合には展開後の大きさを考慮するよう推奨しています。ここで特定の容量値を流用せず、対象文書と既存環境を発注先へ伝えて条件を決めます。

ダウンロードにも確認が要ります。同資料は、ダウンロード機能がある場合、サービス妨害への対策としてリクエスト上限を設けることを推奨しています。アップロード容量だけを見積条件にしても、取得側の制限は自動的には決まりません。取得できる役割と、取得要求の制限を開発範囲に含めるかを別々に回答します。

権限は操作ごとの表にする

「ログイン済みなら利用可能」では、操作の違いを表せません。運用上の提案として、利用者の役割を行、操作を列に置いた権限表を作ります。

未決定を残せる形にすると、発注者の判断待ちと開発漏れを区別できます。とくに削除は、添付した本人だけに許すのか、管理者も行えるのかを明記します。差し替えも削除と同じ扱いだと推測せず、独立した操作として決めます。

2026年9月21日時点で、OWASPはアップロードを認可された利用者だけに許し、ファイルへのアクセスまたは変更に適切な権限を求め、保存先のファイル権限には最小権限の原則を適用するよう推奨しています。画面上のボタン表示だけでなく、権限のない役割がファイルを取得・変更できないことを納品確認に含める根拠になります。

権限表には、実在する役割名を入れます。担当者と管理者の境界がまだ決まっていない場合は、その決定を見積の前提条件として残します。見積書を比べる際は、システム開発の見積もりで確認する項目も参照し、権限設定や確認工程が対象範囲に含まれるかを照合してください。

隔離と検査を「添付保存」に埋め込まない

ファイルを受け取って保存する処理と、保存先の分離や悪意あるデータの検査は、同じ一語で発注しないほうが範囲を確認しやすくなります。どの構成を採るか、検査をいつ行うか、異常を検知したファイルを誰がどう扱うかを切り分けます。

2026年9月21日時点で、OWASPはアップロードファイルを別ホストに保存し、それができない場合にはWebルート外へ保存することを推奨しています。また、利用可能ならウイルス対策ソフトまたはサンドボックスで悪意あるデータを検査し、公開前に人が確認する場合はサンドボックス環境を使うとしています。すべてを一律の必須要件と読み替えず、採用する対策と実施条件を発注先に確認します。

運用上の提案として、検査結果を「利用可能」「利用不可」だけで終わらせず、検査前、異常検知時、確認待ちの各状態でダウンロードを許すかを決めます。さらに、異常時の連絡先と、削除または保持を判断する担当を記入します。こうすれば、検査機能の実装と、人が判断する運用を同じ見積項目に混ぜずに済みます。

別ホストでの保存、ウイルス対策ソフトによる検査、サンドボックス、公開前の手動確認を求めるなら、それぞれを追加範囲の候補として明示します。「安全に保存する」という依頼文だけで、いずれも実施されるとは判断しません。

保存期限と削除は起点・例外・方法まで書く

個人データを含む可能性がある添付では、「一定期間保存」の一文だけでは、見積に必要な処理条件が決まりません。運用上の提案として、保存期限、期限を数え始める業務上の状態、法令による保存の例外、期限が来たときの削除方法を発注確認表へ記入します。この確認表は自社の運用案を決めるものであり、共通の保存年数や自動削除を一律の義務として示すものではありません。

2026年9月21日時点で、個人情報保護委員会の個人情報の保護に関する法律についてのガイドライン（通則編、令和8年6月一部改正）は、利用目的の達成に必要な範囲で個人データの正確性・最新性を保つための手段例として、保存期間の設定などを挙げています。また、個人データを利用する必要がなくなったときは遅滞なく消去するよう努めるとしており、法令で保存期間などが定められている場合は例外です。

この指針を踏まえた発注時の整理として、どの添付が個人データを含む想定か、利用する必要がなくなったことを何で判定するか、法令保存の対象を誰が判断するかを決めます。具体的な期間や法令上の扱いは一律に決めず、自社の利用目的と適用される法令を確認してください。

削除方法は「利用者が画面から削除する」と「期限到来を受けて処理する」を分けます。本人による削除、管理者による削除、期限判定、例外の保持のうち、システムが担う部分と運用担当が担う部分を示します。自動化を求める場合は、期限の起点と例外をシステムが判別するために必要な情報も開発対象です。

見積依頼と納品確認を同じ表でつなぐ

記入済みの発注確認表には、各行について「初回見積に含む」「追加範囲」「未決定」を付けます。発注先から提案を受けたら、提案内容を許可形式、容量、ダウンロード、隔離、保存期限、削除のどの行へ反映したかを確認します。欄に対応しない提案は、対象範囲と納品時の確認方法を追記してから合意します。

納品時は、許可・拒否、役割別の操作可否、隔離・検査の状態、期限と例外、削除後の状態を表の右欄に沿って確かめます。検査や期限処理を運用で担うなら、担当者と判断条件も引き渡し対象として確認します。画面が動くことだけで完了とせず、発注時に決めた条件が一連の流れで保たれることを確認してください。

許可形式や権限を決めても、隔離の実施条件や期限後の扱いが空欄なら、添付ファイルの入口と出口はつながっていません。未決定を見える状態にし、単純な保存、追加の検査、運用判断、自動削除を分けて見積もる。その確認表が、追加範囲を納品直前の発覚にせず、発注前の選択肢として扱うための基準になります。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る