レビューの文脈を失わずにアップロード済みファイルを置き換える方法

公開日：2026年11月06日　更新日：2026年11月06日

PixsoのUIデザインメーカーで旧ファイル、確認、完了、失敗状態を一つのプロトタイプにし、レビューの文脈を保つ置換フローを検証します。再アップロードは単なるリトライではありません。新しいファイルが正しくても、コメント、承認、修正理由を失えばレビューは壊れます。

受理済みレコードから始める

例としてレビュー中のProject_Plan_v1.pdfに、6章の予算表修正を依頼された作者がProject_Plan_v1_corrected.pdfを選ぶ場面を考えます。空のアップロード欄ではなく、現在のファイル名、状態、レビュアーの依頼を先に表示します。

本当に置き換えるなら「現在のファイルを置換」とし、複数添付を残す仕様なら「別のファイルを追加」と書きます。旧版のコメントがどこへ移るかを操作前に示します。

確認画面は、今アクティブなファイル、アクティブになるファイル、旧版とレビュー threadの扱いを答えます。2つの名前、サイズ、アップロード時刻を並べます。

安全な既定値は、置換が成功するまで受理済みの旧版をアクティブにすることです。ダイアログを閉じたり通信が切れたりしても元の提出物を見つけられます。

「6章」というコメントは最初のPDFのバイト列ではなく、レビュー対象の提出物に付いています。提出ID、リンクされたthread、「この依頼への対応で置換した」という短い証拠を新しい版からたどれるようにします。

ページ順やレイアウトが変わっている可能性があるため、旧PDFの座標に同じピンを置くのは危険です。旧版へのコメントだと明示し、レビュアーに修正箇所を再確認してもらいます。

レビュアーが旧版を読んでいる間に作者が置換を始めることがあります。開いたレビューを黙って新文書へ切り替えず、旧版で読み終えるか、新版が利用可能になったことを通知します。

旧PDFを10:02に開き、作者が10:04に置換を完了し、レビュアーが10:05に承認を押す例では、承認がどの版に対するものかを明記します。

転送前に形式、空ファイル、サイズを検査します。転送中の進捗は転送量を示すだけで、置換が処理され添付された証拠ではありません。

78%で通信が切れたら旧版がアクティブなままだと示し、安全な再試行を提供します。サーバーが新PDFを拒否した場合は理由を示し、レビュアーの依頼を失わず別ファイルを選べるようにします。

GOV.UKのアップロードガイダンスの具体的なエラー例や、セキュリティとプライバシーを条件に旅程内で既存ファイルを再利用する原則を参考にできます。ただしレビュー後の置換仕様は製品固有です。

「レビュー中」から「置換完了」への変化は重要です。色だけでなく文字で状態を示し、進捗や成功を予期せずフォーカスを移動させずに通知します。

キーボード利用者が置換を開き、2つのファイル名を確認し、キャンセル、確定、提出物へ戻れるようにします。狭い画面では2つの版を縦に並べます。

Pixsoワークスペースに、レビュー依頼付きの受理済みファイル、2版の置換確認、修正ファイルと議論が結び付いた完了状態、失敗状態を並べます。

レビュアーには「以前のコメントはどこですか」、作者には「転送に失敗したらレビュアーはどの版を見ますか」と尋ねます。答えが推測に頼るなら、影やモーションより先に状態ラベルを直します。

ファイル置換は新しいバイト列を送る機能ではなく、アクティブ版、レビュー文脈、承認、失敗復旧を保つ状態設計です。旧版を安全に残し、版の関係と次の行動を明示してから確定させます。