現場写真を受け取ったものの型番が読めない、追加の図面がメールに届いて案件と結び付かない、差し替え前の資料を取引先が見ている。添付欄を設けるときは、こうした提出後の確認や再提出までを考える必要があります。
本記事では、写真・PDF・図面を受け取る業務を対象に、必要な品質、スマホでの再送、内容確認、閲覧権限、版管理、保存期限を順に検討します。容量や保存期間の数値、画面内のファイルは説明用の例です。実際の設定値は、利用するファイルと確認担当者の作業に合わせて決めます。
ファイル添付は、何でも受け取れるようにすると管理が難しくなります。 最初に、添付ファイルの役割を明確にしておくと、必要な形式・容量・分類も決めやすくなります。
建設・工務店の見積や現地調査では、図面や現場写真が判断材料になります。 この場合は、図面アップロード設計 と合わせて考えると、必要な項目を決めやすくなります。
製造業の不具合受付であれば、現象写真、使用条件、ログ、型式ラベルなどを一緒に受け取る必要があります。 この考え方は、不具合受付フォーム の設計にも近い内容です。
図面がなければ正式な積算ができない場合でも、概算の相談受付まで止める必要があるかは別の判断です。初回に必要な理由と、資料がない場合に受付できる範囲を決めます。後日提出できるものは、案件にひも付いた追加提出欄から受け取ります。
写真を圧縮する場合は、寸法・細い線・型番を読み取れるかを実際の資料で確認します。証跡として原本が必要なら、閲覧用の縮小画像と原本を分けて管理し、原本の保存理由と閲覧者も決めます。必要な資料の案内は現地調査前の情報回収も参照できます。
ファイル添付の画面では、ユーザーに「何を添付すればよいか」「どの形式なら送れるか」を分かるようにしておく必要があります。 制限を送信後のエラーで伝えるより、アップロード前に表示した方が、やり直しを減らせます。
画面例 添付アップロード画面
この例ではjpg/png/pdfを受け付けます。CADや圧縮ファイルは、対応方法を確認してから案内します。
現場写真、図面、仕様書、証跡、その他から選択。その他の場合は説明を入力。
社内限定、取引先共有可、顧客共有可を分ける。既定値は社内限定にする。
添付欄は、ファイルを受け取るだけでなく、分類・公開範囲・制限を同時に扱える設計にしておくと管理しやすくなります。
スマホではファイル選択と撮影の両方を確認し、写真の向き、プレビュー、取り消し・再選択を試します。HEICなどを受け付けるなら、表示・変換できる環境も確認します。対応しない形式は選択前に案内し、送信後に初めて制限を知らせないようにします。
フォームを戻ったときに入力内容を復元できても、選択したファイルまで復元できるとは限りません。添付を保持する仕様にするなら、受信済みファイルのIDと所有者をサーバー側で管理し、再開時に再確認します。保持できない場合は再選択が必要と明示します。関連する考え方は入力内容の保持とエラー文言と表示位置で扱っています。
ファイル形式と容量を無制限にすると、送信エラーや保管コストだけでなく、セキュリティ上の不安も増えます。 まずは、写真・PDF・図面の3系統に分けて考えるのが現実的です。
| 種類 | 主な用途 | 許可形式の例 | 設計上の注意点 |
|---|---|---|---|
| 写真 | 現場状況、損傷箇所、型式ラベル、施工前後の確認 | jpg / jpeg / png | スマホ写真は容量が大きくなりやすいため、枚数上限・合計容量を決める。 |
| 仕様書、見積書、説明資料、申請書、保証書 | 社外共有しやすい一方、個人情報や社内メモが含まれていないか確認が必要。 | ||
| 図面 | 平面図、立面図、設備図、施工図 | 原則PDF。CADは必要時のみ。 | CADファイルは閲覧環境や容量の問題が出やすいため、基本はPDF化して受ける。 |
| 圧縮ファイル | 複数ファイルの一括送付 | 原則は避ける。必要時のみ個別対応。 | 中身の確認やスキャンが必要になり、管理負荷が高くなる。 |
アプリの設定と、Webサーバーや中継サービスの受信上限・タイムアウトが一致しているかも確認します。分割送信を採用する場合も、結合後の容量・形式の検査と、一時ファイルの削除条件が必要です。通信が途中で終わったファイルを正式な添付にしないようにします。
容量制限は、ユーザーを制限するためだけのものではありません。 アップロード処理が重くなると、フォーム送信の失敗や離脱につながります。 イベント申込や見積依頼の離脱対策は、イベント申込フォームの改善ポイント とも共通するテーマです。
添付ファイルが増えてくると、「どれが何の資料か分からない」という問題が必ず出てきます。 ファイル名だけに頼ると、担当者ごとの付け方に差が出ます。 そのため、添付ファイルには分類を持たせる設計が必要です。
分類 添付カテゴリの例
全景、損傷箇所、型式ラベル、設置環境など。写真の種類まで選べると後から確認しやすくなります。
平面図、立面図、設備図、施工図など。版や対象箇所を補足できるようにします。
製品仕様、施工要領、保証書、説明資料など。社外共有可否を必ず確認します。
この分類は、管理画面の一覧にも関係します。 添付ありの案件だけを抽出したい、図面が未提出の案件を確認したい、写真の種類ごとに絞り込みたい、といった要望が後から出るためです。 一覧画面での見せ方は、一覧カラム設計 と合わせて考えると整理しやすくなります。
「ラベル部分を撮り直してください」と依頼する場合は、対象ファイルと不足内容、提出期限、確認担当を指定します。新しい写真を補う追加提出か、既存の図面を置き換える差し替えかも分けます。再提出ファイルは元の案件と依頼にひも付け、担当者が確認した時点で修正依頼を完了にします。
修正依頼の状態はステータス管理、提出・確認の連絡は通知・リマインドと対応させます。誤添付で旧版を公開してはいけない場合は、差し替え完了を待たず閲覧を停止する扱いにします。
添付ファイルを公開ディレクトリに置き、URLを知っていれば誰でも見られる状態にすると、情報漏えいの原因になります。 特に、図面・見積・現場写真・本人確認書類・医療介護系の資料などは、直リンクで閲覧できる構成にすべきではありません。
ファイルを非公開領域に保存する考え方はOWASPのFile Upload Cheat Sheet、取得時の権限確認はAuthorization Cheat Sheetでも説明されています。画面のリンクを隠すだけでなく、ファイルを返す処理でアクセスを制御します。
社内だけで見る添付と、顧客・取引先に共有する添付は、同じ扱いにしない方が安全です。 権限設計の基本は 権限・ログ の考え方と共通します。
添付ファイルは、誰が見るかによって扱いが変わります。 社内判断用のメモが入った資料、顧客へ渡す正式資料、取引先に確認してもらう図面では、公開範囲を分ける必要があります。
権限 添付ファイルの閲覧範囲
初期の公開範囲を決めたうえで、外部共有を許可できる担当者と、共有相手を指定します。「社内限定」も全社員を意味するのか、案件担当者だけなのかを明記します。資料の分類を変更しただけで公開範囲が広がらないようにします。
期限付きの共有リンクには、受け手がログインする方式と、URLを持つ人が利用できる方式があります。例えばAmazon S3の署名付きURLは、URLの保持者にアクセスを許可する方式です。期限を付けるだけで、指定した本人だけに限定できるわけではありません。
本人や所属を確認して共有する要件なら、取得時の認証・権限確認を設計します。共有期限のほか、期限前の停止、退職・担当変更、誤送付時の無効化がどの時点で反映されるかも確認します。すでに相手の端末へ保存されたコピーは、サーバー上の公開停止だけでは回収できません。
現場写真の顔・表札・車両番号、資料の社内メモなど、業務に不要な情報が含まれないかを提出前に案内します。位置情報などの画像メタ情報を削除するかも用途に応じて決めます。自動変換を行う場合は、画像の向きや必要な証跡を失わないかを確認します。本人確認書類などは必要な場面だけで受け取り、利用目的、閲覧者、保存期間を定義します。
拡張子がPDFや画像であることだけでは、安全性は判断できません。許可形式を限定し、内容の検証やウイルススキャン、必要な形式では無害化処理を組み合わせます。OWASPのアップロード対策も、複数の検査を併用する方針を示しています。
検査前のファイルは隔離し、通常の閲覧・共有対象にしない設計にします。検査が終了し条件を満たしたら利用可能へ移し、不正な形式などは拒否理由を記録します。検査サービスの停止やタイムアウトは「問題なし」に置き換えず、検査待ち・要確認として管理者に知らせます。
スキャンを外部サービスへ委託する場合は、資料がどこへ送信・保存されるかを確認します。機密図面や本人確認資料を、確認なしに公開型の検査サービスへ送らない運用にします。検査済みであることと、担当者が業務内容を確認したことも別々に記録します。
添付ファイルは、残せば残すほど便利に見えますが、保管コストと情報管理上のリスクも増えます。 案件完了後もずっと残すのか、一定期間で削除するのか、アーカイブに移すのかを決めておく必要があります。
運用 添付ファイルのライフサイクル
分類・公開範囲・案件IDを付けて保存する。
担当者が内容を確認し、必要なら差し替えを依頼する。
社内、取引先、顧客の範囲に応じて閲覧権限を分ける。
案件完了時点で保管期限のカウントを開始する。
期限後に削除、またはアーカイブへ移動する。
一覧から非表示にしても、保存領域から消したことにはなりません。復元できる状態で一定期間保管するのか、実データを削除するのかを区別します。削除の対象には原本のほか、縮小画像、プレビュー、旧版、一時保存ファイルを含め、残すものがあれば理由と期限を記録します。
保存期間はファイル種別と保存目的から決め、契約や適用される保存要件も確認します。旧版も無期限には残さず、延長の承認者・理由・新しい期限を持たせます。バックアップの保管期限と、復旧時に削除済みデータを再公開しない手順も必要です。ここで挙げる月数は一律の保存要件を示すものではありません。
削除処理が失敗した場合は削除済みにせず、対象と失敗理由を確認できる状態にします。監査ログには登録・差し替え・公開範囲変更・削除の日時、実行者、対象ID、結果を残します。ログ自体の閲覧範囲と保管期間も決め、資料の内容や共有URLの秘密情報をそのまま記録しないようにします。
ステータス運用と連動させると、管理しやすくなります。 たとえば「案件完了」になった時点で保管期限のカウントを始める、といった設計です。 ステータス設計は ステータス管理の運用ルール と合わせて確認できます。
以下は設計を検討するための例です。提出する資料と、受け取った後の確認作業を具体化します。
建設・工務店では、図面と現場写真が見積や現地調査の前提になります。 平面図、立面図、設備図、現場写真、施工前写真などを受け取る場合は、分類と公開範囲を分けて管理することが重要です。
業務像は 建設・工務店向けWebシステム活用アイデア を前提にすると考えやすくなります。 現地調査や見積依頼では、図面・写真の事前回収 と合わせて、添付資料が後続の確認作業を減らす役割を持ちます。
自動車販売・整備・タイヤショップでは、車両状態、損傷箇所、装着状態、タイヤサイズ表記、持込部品の写真などが確認材料になります。 写真の種類を選択できるようにしておくと、受付後に必要な情報がそろっているか確認しやすくなります。
業務像は 自動車販売・整備・タイヤショップ向けWebシステム活用アイデア を前提にすると整理しやすくなります。 入庫予約は 入庫設計、持込取付や適合確認は 持込取付の予約 と合わせて考えると、添付ファイルの役割が明確になります。
製造業の技術問い合わせや不具合受付では、現象写真、型式ラベル、使用環境、測定ログ、仕様書などが重要です。 どのファイルが原因調査用で、どのファイルが顧客提出用かを分けておかないと、後から確認に時間がかかります。
不具合受付では、不具合受付フォーム と同じく、添付ファイルも「現象確認」「仕様確認」「証跡」のどれにあたるかを分類しておくと、技術部門や品質保証部門で扱いやすくなります。
ファイル添付は、フォームや管理画面にとって便利な機能ですが、同時に情報管理の責任も増えます。 形式・容量を絞り、添付の分類を持たせ、公開領域に直接置かず、閲覧権限と保管期限を決める。 この流れで設計すれば、写真・PDF・図面を業務の中で安全に扱いやすくなります。
まずは、自社のフォームや管理画面で受け取っている添付ファイルを洗い出し、「何のために必要か」「誰が見るか」「いつまで残すか」を確認してみてください。 そこが整理できると、添付欄の追加だけでなく、案件管理・見積・現地調査・技術問い合わせまで含めた運用設計につなげられます。