スキャナーと提出資料を置いた書類受付台
スキャナーと提出資料を置いた書類受付台
この記事の内容
  1. 提出する資料と受付単位を決める
  2. 画面の確認は早い案内として使う
  3. 保存名と利用者が付けた名前を分離する
  4. 検証が済むまで提出を確定しない
  5. 容量の境界と同名ファイルを試す
  6. 再送と差し替えを別の操作にする
  7. 費用は保存とダウンロードも含める
  8. 利用者が提出を説明できる結果画面にする

提出する資料と受付単位を決める

例では申込書のPDFか画像を、一件の受付につき一ファイル提出します。最初から動画、圧縮ファイル、複数フォルダーを扱わず、PDF、PNG、JPEGだけを対象にします。これはこの試作で選ぶ受付条件で、各サービスが共通して保証する形式や上限を表すものではありません。

AIへは提出する利用者と受け取る担当者を明示し、利用者が自分の提出状況を確認できる画面を依頼します。未選択、送信中、確認待ち、受付完了、差し戻しの表示を分け、選択した瞬間に受付完了と表示しないようにします。差し戻し理由はファイル自体と別の記録にします。

画面の確認は早い案内として使う

ブラウザーではFileの名前、サイズ、種類を読み、選択ミスに早く気付けるようにします。例の上限を5MiBと決めたら、その単位と許可形式を選択欄の近くへ表示します。上限の値は設定から参照し、画面ごとに違う数値を直接書き込まない構成にします。

ただしブラウザー側の値や拡張子だけで受理を決めません。送信内容は利用者が変えられるため、保存側でも同じ容量条件と許可形式を確認します。選択欄のaccept属性は選びやすくするための案内であり、サーバー側の検証に置き換わるものではありません。

保存名と利用者が付けた名前を分離する

保存用の名前には推測しにくい識別子を使い、元のファイル名は表示用の情報として別に保存します。同じ名前の申込書が届いても上書きせず、提出IDと版番号で追えるようにします。ファイル名に含まれる区切り文字をそのまま保存先のパスとして扱わない設計にします。

保存先は原則非公開にし、取得時にはログイン状態だけでなく、その提出物を閲覧できる利用者か確認します。担当者一覧の表示でも必要な範囲に絞り、別の受付IDをURLへ入れたときに資料が開かないことを確認します。共有リンクを使う場合は対象と有効期間を決めます。

スキャナーと提出資料を置いた書類受付台
スキャナーと提出資料を置いた書類受付台

検証が済むまで提出を確定しない

受付側では許可した拡張子、実際の内容の特徴、容量を組み合わせて確認します。ファイルの種類は一つの申告値だけに頼りません。必要に応じて、検査を待つ一時保管と担当者が使う保管場所を分け、検査に失敗した資料を通常の閲覧先へ公開しない流れを設計します。

提出データには送信キー、保存先ID、検証状態、受付日時を記録します。ファイルの転送が終わっても台帳の保存に失敗した場合があるため、ファイルの存在と提出の確定を照合します。使われない一時ファイルは期限と削除手順を設け、成功した提出まで誤って消さない条件にします。

容量の境界と同名ファイルを試す

練習用には上限未満、上限と同じ、上限超過の三種類を用意します。5MiBを選んだ例なら5×1,024×1,024バイトを基準にし、同じ5という表示でもMBとMiBを混同しないようにします。PDFの拡張子を付けただけの別形式や、容量ゼロの資料も確認対象にします。

次に二人の利用者が同名ファイルを提出し、それぞれの提出IDから正しい資料が開くかを照合します。通信を途中で切った場合は完了扱いにせず、再開か再送の案内を出します。これらは実装後に行う受入確認の例であり、特定の製品で得た測定結果ではありません。

提出ファイルの受入確認
提出ファイルの受入確認
練習条件期待する結果確認する記録
設定した容量上限と同じ容量条件を満たすサーバーで測ったバイト数
許可形式と内容が合わない受付完了にしない形式検証の結果
別利用者が同名で提出別の保存先として扱う提出IDと保存用識別子
転送中に通信が切れる未完了として案内する転送状態と台帳の保存状態

5MiBは本文で選んだ試作条件です。形式・容量・権限はそれぞれ確認します。

再送と差し替えを別の操作にする

同じ送信を繰り返した場合は送信キーを使って保存済みか確認し、重複する受付を作らないようにします。内容を直した新しいファイルの提出は差し替えとして別の版を作り、以前の受付結果や担当者コメントと対応を保ちます。単に最新のファイル名だけを更新すると確認の経緯が失われます。

担当者が前の版を確認している間に新しい版が届いた場合は、どの版に対する承認かを記録します。古い版の承認で最新の提出が自動的に完了しないようにします。削除を受け付ける運用では、履歴に必要な情報と実ファイルの保持方針を分けて決めます。

費用は保存とダウンロードも含める

Cursorでコードを修正する利用枠と、公開アプリのストレージ、通信、検査処理、通知にかかる費用は別です。月の提出件数だけでなく平均容量、差し替え回数、担当者が開く回数、保存期間を見積もります。同じ資料を長期間何度も配信する運用では、アップロード件数だけでは必要量を判断できません。

まず小さい架空ファイルで処理を固め、実際に必要な容量と形式へ広げます。無制限の保存を初期値にせず、業務上必要な期間と削除の確認担当を設定します。現行の保存・転送枠と超過時の扱いは選択した保管サービスの公式案内で確認し、上限は受信経路全体とそろえます。

利用者が提出を説明できる結果画面にする

受付完了画面には提出ID、表示用ファイル名、受け付けた版、日時、次の連絡方法を表示します。エラーは形式、容量、通信、権限、検証待ちを分け、利用者が同じ失敗を繰り返さずに次の操作を選べるようにします。担当者へ問い合わせる際にも、資料の内容そのものを再送しなくて済む識別情報を残します。

公開後にファイルを開けない場合は、台帳の参照先、実ファイルの存在、閲覧権限の順に確認します。権限の問題を直すために保管場所を全体公開へ変えない運用にします。受付を止めても既存の提出状況を確認できる方法を残し、復旧後に一時保管の残件を照合します。

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について