タグ: 入力フォーム

小型業務ツールの同時編集で上書きを防ぐには、「画面を開いたときの版」と「保存時の最新版」を照合し、途中で変更されていたら保存を止める仕組みが基本です。 その際、利用者の入力を残し、最新の内容と比べて保存し直せる画面まで用意します。

顧客管理や案件管理を二人で使い始めたとき、「直した納期が元に戻った」「担当者を変更したのに反映されていない」といった問題が起こることがあります。

入力ミスが原因とは限りません。別の人が古い画面を開いたまま保存すると、変更済みの値を古い値で上書きする場合があります。同じ人が複数のタブを開いている場合も同様です。

この記事では、少人数向けの管理ツールを作る・改修する担当者に向けて、更新競合を防ぐ考え方、利用者向けの表示、依頼時の確認事項を整理します。以下の人物・案件・時刻は説明用の架空例です。

二人が違う項目を直しても、変更が消えることがある

案件Aの「担当者」と「納期」を別々の人が編集する場面を考えます。

鈴木さんは納期を触っていません。しかし、画面にある全項目をまとめて保存する作りでは、古い納期も送られることがあります。

これが更新の消失、いわゆる「lost update」の一例です。すべてのツールで同じことが起きるわけではなく、更新方法やデータの保存方式によって動作は変わります。

「担当者同士で声を掛ける」だけでは、別タブ、休憩前から開いていた画面、自動処理による更新まで追い切れません。利用者が気づかなくても、保存先で検出できることが大切です。

対策の基本は、保存するときの版確認

一つの設計例は、案件ごとに更新用の版番号を持たせる方法です。

1. 案件を開いたとき、内容と一緒に「版番号7」を受け取る。
2. 編集後、入力内容と「版番号7」を保存先へ送る。
3. 保存先で、現在も版番号7の案件に限って更新する。
4. 更新できたら版番号を8へ進める。すでに8なら、競合として保存を止める。

このように、編集の間は占有せず、保存時に変更の有無を確かめる考え方を「楽観ロック」と呼びます。

重要なのは、版の照合と実際の更新を、ほかの更新が割り込めない形で行うことです。先に版を調べ、時間を置いて無条件で保存するだけでは、その間に別の人が更新できます。画面側の警告だけでなく、サーバーやデータベース側で一貫して判定する必要があります。

HTTP APIには、取得した内容の識別子であるETagを、更新時のIf-Matchで照合する方法もあります。HTTPの仕様では、複数の利用者による意図しない上書きを防ぐ用途が説明されています。RFC 9110：If-Match

ETagを使う設計では、条件不一致を412 Precondition Failedとして返す方法があります。独自の版番号方式とは実装が異なるため、API仕様に合わせて選びます。MDN：If-Match

依頼する側は方式名を指定するより、「古い画面から保存しても、他の人の変更を黙って消さないこと」と伝える方が、目的を共有しやすくなります。

保存を止めるだけでは、利用者が困る

競合を検出できても、「保存できません」とだけ表示し、再読み込みで入力が消える画面では、作業のやり直しになります。

競合時には、少なくとも次の三つを伝えます。

• 別の更新があったため、今回の変更はまだ保存していないこと。
• 入力中の内容を画面内に残していること。
• 最新の内容と比べて、必要な変更を反映し直せること。

表示例は次のようになります。

この案件は、編集中に更新されました。今回の入力はまだ保存されていません。入力内容を残したまま、最新の内容との差分を確認できます。

操作は「最新の内容と比較する」「入力内容をコピーする」など、次に何が起こるか分かる文言にします。比較を開いただけで入力を破棄しないことも確認します。

画面内の保持と、ブラウザを閉じても復元できる下書き保存は別機能です。まずは競合画面を開いても入力が消えない範囲から検討できます。端末に下書きを保存する場合は、顧客情報をどこに・いつまで残すかも決めます。

一般的な入力ミスの表示方法は、小型業務ツールのエラー文言設計で整理しています。

差分確認は「今の値」と「自分の入力」を比べる

競合の解消では、案件全体をただ読み直すより、変更された箇所が分かる画面が役立ちます。

この例なら、「最新の納期11月12日を残し、担当者だけ鈴木へ変更する」という判断ができます。

ただし、比較中に第三者が保存する可能性もあります。確認後の保存でも、最新の版に対する条件付き更新が必要です。一度比較画面を見たからといって、無条件の上書きを許可しないようにします。

長い備考欄は、変更箇所だけを強調する、全文を開いて比較できるようにするなど、情報量に合わせます。金額や承認状態など重要な項目は、誰が最終判断するかも決めておきます。

対策は、業務への影響と編集頻度で選ぶ

小型ツールでは、まず重要な編集画面へ版確認と入力保持を入れ、頻繁に競合する部分だけ対策を厚くする案が考えられます。これは本稿の設計提案であり、すべての業務に共通する最適解ではありません。

項目が違えば自動統合してよいとも限りません。数量と単価、割引と合計、開始日と終了日は、別々の変更でも組み合わせた結果が不整合になる場合があります。金額・在庫・予約枠などは、競合対策に加え、業務上の条件をまとめて検証する設計が必要です。

編集権限の分け方は、小型業務ツールのログイン・権限設計も参考にしてください。

変更履歴や二重送信対策とは、役割を分ける

変更履歴は、保存された後に経緯を確認するためのものです。履歴が残っていても、保存前に競合を判定しなければ、古い内容での上書きは起こり得ます。変更履歴設計の記事と組み合わせて、予防と事後確認を支えます。

二重送信対策は、同じ依頼を繰り返し実行しないためのものです。一方、更新競合対策は、異なる利用者・画面による変更が食い違う問題を扱います。同じフォームでも両方が必要になる場合があります。業務自動化の二重送信対策とは、対象となる失敗を分けて考えましょう。

また、保存要求の途中で通信が切れた場合は、「保存していない」と断言できません。実際には保存済みで、画面が結果を受け取れなかった可能性があります。明確な競合の応答と、結果不明の通信エラーを区別し、後者は保存先を確認してから再実行する流れにします。

依頼時は、二つの画面を使った確認まで含める

「同時編集に対応してください」だけでは、警告を出すだけなのか、入力を残すところまで含むのかが曖昧です。次のように確認条件を具体化します。

1. 同じ案件を二つの画面で開き、先の保存後に古い画面から保存する。
2. 古い内容で黙って上書きされず、競合が表示される。
3. 二つ目の画面の入力が残り、最新の内容と比較できる。
4. 比較後に必要な変更だけを反映し、再保存できる。
5. 比較中にさらに更新された場合も、再び検出できる。
6. 別の案件同士の編集は、不必要に止めない。
7. 同じ人の別タブ、自動処理、CSV更新も競合検出の対象にする。
8. 編集中に削除・権限変更された場合は、入力が残っていても保存を許可しない。

最後に、保存先の実データと履歴を見て、意図した値が残っていることを確かめます。画面に「保存しました」と出るだけでは確認が足りません。

相談メモには、同時に使う人数、対象画面、困った操作の順番、守りたい項目、既存ツールの保存方式が分かる資料を用意します。実データを渡す前に、ダミーの顧客・案件で問題を再現すると説明しやすくなります。

小型ツールの上書き問題を相談するには

「二人で使うと値が戻る」「古いタブから保存できてしまう」「競合時に入力を失う」といった困りごとは、画面と保存処理を一緒に見直すきっかけです。

YOSHIO.devでは、業務自動化・小型ツールの相談を受け付けています。まずは、対象の画面一つと、起きている操作の順番から整理できます。既存環境の制約によって対応方法・範囲は異なります。

相談時は「何人で使うか」「どの項目が戻るか」「保存前後にどんな操作をしたか」を、分かる範囲でお知らせください。お問い合わせフォームから、現在の運用に合う改修範囲をご相談いただけます。

よくある質問