一括更新機能を発注する。対象確認と失敗時の扱いを先に決める

一括更新の開発要件では、「複数件をまとめて変更できる」という説明を具体化します。誰がどの範囲を選び、実行直前に何を確認し、失敗や競合が起きたときにどの状態を正とするかまで決めて、初めて見積もりと受入確認に使える仕様になります。

先に固定したいのは、対象範囲、プレビュー、部分失敗、同時更新、復元可能性の五点です。特に、全件を一体として扱うのか、成功した分だけ確定するのかで、結果画面や再実行の設計が変わります。判断を後回しにすると、同じ「一括更新」という言葉のまま納品範囲だけが食い違います。

全件不成立が適するかは業務によって変わり、成功分を残す必要がある場合もあります。方式の名前よりも、途中で問題が起きた後に担当者が迷わず次の操作を選べる状態を基準にします。

一括更新の開発要件は実行後から逆算する

まず、更新ボタンから考えるのをやめます。実行後に必要な情報を決め、その情報を得るために実行前に何を記録し、何を表示するかを逆算します。

たとえば、検索結果から対象を選ぶ画面があっても、実行前の画面に検索条件が残らなければ、担当者は「いま表示されている行」だけで判断することになります。対象を識別する情報、変更する項目、変更後の値も同じです。確認画面で省かれていれば、操作できることと、意図どおりに操作できることは一致しません。

運用上の提案として、実行前画面には次を表示し、確認を経た場合だけ実行できることを受入条件にします。

• 対象を決めた検索条件または選択条件
• 対象レコードを担当者が識別できる情報
• 変更する項目と変更後の値
• 実行後の扱いを判断できる失敗方針

この並びによって、「何を選んだか」「何に変えるか」「失敗時にどうなるか」を同じ確認の流れに置けます。表示項目がそろっていても別々の画面で対応関係を追えないなら、誤操作の確認には使いにくいままです。

2026年9月21日時点で、OWASPのTransaction Authorization Cheat Sheetは、取引承認について、利用者が重要な取引データを識別して承認でき、そのデータが承認過程で検証されることを求めています。資料にある送金先口座と金額は例示であり、あらゆる表示項目の網羅一覧ではありません。また、データ確認、承認情報の検証、取引実行という順序を示し、手順の飛ばしや順序変更を許さないことを必須としています。

これは取引承認を対象とした指針で、一括更新画面の直接の仕様ではありません。そこから、重要な変更内容を利用者が識別でき、確認後にだけ実行できる、という考え方を一括更新の受入条件へ導いています。

五つの判断を一枚でそろえる確認表

次の表は、小規模な既存システム改修を発注するときの運用上の提案です。公式資料の必須仕様を転記した表ではありません。「未定」を見つけ、見積もりに含める範囲と追加対応になる範囲を分けるために使います。

表を埋める順序は、部分失敗の方針から始めても構いません。そこから必要なプレビューと結果表示へ戻ると、納品物を具体化しやすくなります。

全件不成立と部分成功を先に選ぶ

失敗時の仕様には、エラーメッセージの文言に加えて、処理後に残す状態を含めます。運用上の提案として、見積依頼書には次のどちらを希望するかを書きます。

• どれか一つでも更新できなければ、対象全体を不成立にする
• 更新できた対象は確定し、更新できなかった対象を結果として残す

前者では処理後の状態を一まとまりとして扱えます。後者では、成功分と失敗分が混在するため、各対象の成否と失敗理由を元の対象へ対応づける結果表示までを納品範囲に含めます。失敗分だけを選び直せるか、同じ条件で再実行するかも、その結果表示と一緒に決めます。

2026年9月21日時点で、Google AIP-233は、直接にはバッチ作成APIを対象に、全件成功または全件不成立となるアトミック方式と、部分成功方式の両方を認めています。選択要因として処理の複雑さと利用者体験を挙げ、同期処理にはアトミック方式を必須とし、非同期処理では両方式を選択可能としています。部分成功の場合は、失敗した各要求を元の要求内の位置と個別エラーへ対応づけて通知することを必須とする一方、サーバー側の再試行で成功し得る一時的エラーはその失敗一覧に含めません。

業務画面の発注では、この規定の適用範囲を踏まえたうえで、「どちらの失敗方針かを選ぶ」「部分成功なら個別結果を照合可能にする」という判断へ応用します。実装方式は開発側と確認し、業務上どちらの処理後状態を許容するかは発注者が示します。

要件全体の抜けを見直すときは、システム要件定義のチェックリストと照合し、一括更新に固有の条件だけが孤立しないようにします。見積書では「一括更新一式」にまとめず、システム開発の見積もりで確認する項目も使いながら、確認画面、競合検知、結果表示、復元対応を分けて記載してもらうと、追加範囲の境界を確認しやすくなります。

プレビュー後の変更を上書きさせない

プレビューが正しくても、確認している間に別の担当者が対象を更新することがあります。そのまま実行すると、確認時点より新しい変更を古い内容で上書きする可能性が残ります。

運用上の提案として、プレビュー後に対象データが別操作で更新されていた場合は、その対象を更新せず、競合として結果に示すことを受入条件にします。そして、競合が一つでもあれば全件停止するのか、競合分だけ除外してほかを確定するのかを、先に選んだ部分失敗の方針とそろえます。

2026年9月21日時点で、IETFのRFC 9110は、状態を変更する要求に条件を付けると、並行する別利用者の変更を誤って上書きするロストアップデートを防げると説明しています。If-Matchの条件が偽なら、サーバーは要求された処理を実行してはならず、412を返せます。同等の変更がすでに成功したと判断できる場合などの例外も規定されています。

発注者が指定する範囲は、「確認後に変わった対象を黙って上書きしない」「どの対象が競合したか分かる」という業務上の結果です。HTTPの実装手順は開発側と確認します。全件停止か競合分の除外かが未定なら、見積もりの前提欄へ未決事項として残し、開発側へ判断を預けた状態にしません。

復元は一括更新本体と分けて合意する

「元に戻せること」は意味が広いため、一括更新の付随機能として曖昧に含めません。運用上の提案として、次のどこまでを納品範囲にするか、独立した確認欄で合意します。

• 失敗時に全件を不成立にして、更新前の状態を保つ
• 更新前データを使って、確定後の変更を戻せるようにする
• 管理者が対象を確認し、再更新によって戻せるようにする

この三つは同じ「復元」ではありません。とくに部分成功を採用した場合、失敗分をもう一度実行することと、成功分を更新前の状態へ戻すことを分けます。必要な画面や保持情報が異なるため、契約前に含まれていなければ追加範囲として扱う、という境界も記載します。

復元を依頼する場合は、次の発注表を見積依頼に添えます。これは後述するMicrosoftの考え方を参考にした自社の運用要件案であり、特定製品の復元機能や保証を示すものではありません。

2026年9月21日時点で、MicrosoftのCompensating Transaction patternは、結果整合性を採る複数ステップ処理について、完了済み処理を打ち消すための情報を記録する必要があると説明しています。単純に元の状態へ戻すと並行処理による変更を上書きする可能性があり、復旧に手動介入が必要な場合もあります。また、処理開始時点への完全な復帰を必ず保証する考え方ではありません。

この資料が扱うのは複数ステップ処理の補償であり、一括更新一般に補償トランザクションを必須とするものではありません。発注時には実装方式を指定するのではなく、どの情報を残し、どこまで戻せれば受入可能かを開発側と合意します。復元を範囲外にする判断も、その場で記録します。

納品時は正常系に加え、選択条件がプレビューに残ること、確認後の変更を上書きしないこと、採用した失敗方針どおりに結果を識別できることを確認します。復元を依頼している場合は、合意した戻し方まで確かめます。

見積依頼には記入済みの確認表を添え、開発側の回答と見積項目を対応づけます。納品時は同じ表に確認結果を残します。復元画面や競合分の再実行など、表で合意していない対応が後から必要になった場合は、「一括更新に含むはずだった」という解釈ではなく、追加範囲として見積もる基準が残ります。

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

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