一括操作のUIパターン：プレビュー、権限、元に戻す

なぜ一括操作は失敗するのか（「安全」とは何か）

一括操作は「これを多くの項目に対して行う」ためのコントロールで、素早く処理したいときによく使われます。実際のプロダクトでは、フィールドの一括編集、削除、別フォルダやステージへの移動、担当者やチームへの割当、タグ付け、ワークフローのトリガーなどが該当します。

失敗の理由は単純です：慎重にレコードごとに考える代わりに、スピードを選んでしまうから。範囲が明確ならそれで構いませんが、多くの場合、範囲が曖昧で影響が見えにくく、権限ルールが一貫していないことがあります。操作は平気に見えても、間違った200件が更新されたと気づくまで誰も気づきません。

よく起きる問題は繰り返し現れます：

• 選択が不明瞭（フィルタとチェック済み項目、ページ横断、"全て選択" の驚き）
• 影響がプレビューできない（実際に何が変わるか見えない）
• 権限チェックが遅すぎる、またはUIだけで行われる
• 「元に戻す」がない、信頼できない、誤解を招く
• 監査ログがなく、何が起きたか説明できない

被害は小さくないことが多いです。顧客に誤ったメールが送られたり、請求書のステータスが変わったり、営業パイプラインの所有者が誤って再割当されることがあります。データを復旧できても、回復には何時間もかかり「このシステムは信頼できるか？」という疑念を生みます。

「安全」とは「遅い」や「警告だらけ」を意味しません。確定前にユーザーが次の3つの質問に答えられることです：

1. 正確にどのレコードが影響を受けるか？
2. 正確に何が変わり、何は変わらないか？
3. 間違っていた場合、最速で誠実に戻る方法は何か？

例として、サポートリードが障害後にチケットを一括クローズする場面を想像してください。UIが密かにアーカイブ済みチケットを含め、最終件数を表示せず、元に戻す方法もない場合、30秒のクリーンアップが本当のインシデントになります。

安全な一括操作の基本原則

良い一括操作はユーザーが間違うリスクとシステムが間違うリスクの両方を減らします。人を遅らせるのが目的ではなく、操作を明確に、意図的に、検証しやすくすることが目的です。

選択とアクションを分離してください。まず項目を選択（またはフィルタで範囲を確定）してからアクションを選べるようにします。選択とアクションが混ざると、決めかねているうちに変更がトリガーされてしまいます。

コミット前に範囲を表示しましょう。正確な件数、適用されたフィルタ、除外（編集不可の項目、既に対象の状態にある項目など）を示します。「Status = Open, Assignee = Me でフィルタ、128選択；6は権限不足で除外」 のような一行で多くの驚きを防げます。

破壊的な操作は見た目を変えるべきです。明確なラベル（「128件を削除」）、強い視覚的合図、安全な操作から離すレイアウト、専用ボタンなどで誤操作を防ぎます。

フローは短く予測可能に：選択、範囲確認、確定、結果表示。余計なステップウィザードは避け、真に選択肢が必要な場合にのみ使ってください。

簡単なチェックとしては、選択が明示的であること、範囲がアクションのそばに見えること、破壊的操作は誤って押しにくいこと、確認文が何が起きるかを明確に述べていること、結果が明白に示されること（成功、部分成功、失敗）です。

プレビュー優先のUI：適用前に影響を示す

良い一括操作は飛躍に感じさせてはいけません。ユーザーが「適用」をクリックする前に「正確に何が変わるか」を答えるプレビューを表示します。

まず信頼できるサマリを出します。選択が大きい場合、長い表より件数が有効です。ステータス変更なら各現在ステータスから新ステータスへ何件移るかを表示します。担当者変更なら現担当別と新担当の件数を示します。サマリは主要な操作ボタンの近くに置き、見落とされないようにします。

次に驚きを検出できるだけの詳細を与えます。単純な変更（例：「優先度をHighに設定」）なら数行のサンプルで十分です。例外が予想される場合や、フィルタの記憶が曖昧な場合は影響対象の全リストやエクスポート可能なセットが望ましいです。

「何が適用されないか」も明示します。小さな「スキップされる項目」領域で、権限不足、既に目標状態、承認ワークフローでロックされている、必須データが欠けている等の理由を平易に示してください。

重要なのは、プレビューが実際のルールを反映していることです。バックエンドが更新を拒否するなら、プレビュー時にそれを示し、確定後ではなく事前に知らせます。

ユーザーが本当に理解する確認ダイアログ

確認ダイアログは通過点ではなく、「これをクリックしたら何が起きるか完全に理解できるか」を答えさせるものであるべきです。二読で理解できないなら人は無視します。

アクション名と最終状態を先に示します。一般的なラベル（「Update status」）は避け、「Set status to Closed」や「Delete 24 customers」のように具体的にします。

危険な選択をデフォルトにしないでください。ボタンが二つあるなら、安全な方をデフォルトフォーカスにします。オプションがある場合（例：「Close tickets and notify customers」）は最も破壊的なものを事前チェックしないで、明示的な選択を求めます。

ダイアログ文には実際のリスクを書きます。何が変わるか、何が変わらないか、どこが恒久的か、何が含まれるかを述べ、曖昧な「Are you sure?」は避けます。

すべての一括アクションに同じ摩擦は不要です。低リスクで可逆な変更（タグ追加など）には簡単な確認で十分です。一方、取り消し不可能な削除、権限変更、大量の支払いなど影響が大きいものにはタイプ確認（type DELETE や type CLOSE 24 のように範囲を目で確認させる）が妥当です。

一括操作における権限とアクセス制御

一括操作は権限ルールが最も試される場面です。ユーザーが一部のレコードは編集できるが削除はできない、あるフィールドだけ変更できる、など複雑になることが多いです。権限をワークフローの一部として扱い、適用後に驚かせないでください。

「許可されている」が何を意味するかを明確にします。単に「アイテムを開けるか」ではなく、閲覧権限、編集権限、削除権限、フィールドレベルのルール（ステータスは変えられるがオーナーや価格は変えられない）、範囲ルール（チーム、地域、プロジェクト内のみ）など複合的です。

選択に混在した権限が含まれるのは普通です。安全なシステムは誠実な方針を一つ選び、明確に伝えます：

• 許可された項目だけに適用し、スキップされた件数を要約する
• 選択が許可された項目のみになるまでアクションをブロックする

高ボリューム作業には前者が滑らかですが、削除や権限変更など高リスクな操作では後者が適切なことが多いです。

アクセス不可の項目でデータ漏洩を避けてください。ブロックされたレコードの名前やタイトル、機微なフィールドを表示しないでください。「アクセスルールで更新できない項目が12件あります」のように示す方が安全です。

良いUIはユーザーが罰を受けていると感じさせないフィードバックを出します。例：事前チェックバナー（"50選択中38件を更新可能"）、短い理由コード（"Blocked: not in your team"）、編集不可の項目を非表示にするフィルタなどです。

バックエンドでは、すべての項目について再度同じルールを強制してください。UIで事前チェックしていても、サーバーはレコードごと・フィールドごとの検証を必ず行うべきです。

信頼できる元に戻すパターン

本当に実行できる元に戻す手段が最も安全です。多くの場合、それは最後にボタンを付けるのではなく、復旧を最初から設計することを意味します。

強いデフォルトはソフトデリート＋時間制限の復元窓です。レコードを即時削除する代わりに削除済みとしてマークし、通常ビューから隠しておき、後で完全削除します。これで誤クリックや間違ったフィルタ、含めるべきでなかった項目のミスを取り返せます。

短時間の操作には Undo トーストが有効です。変更内容を具体的に示し、Undo ボタンと時間制限、いくつかがスキップされた場合はその旨を表示してください。

危険度に応じたウィンドウを選びます。小さなミス向けには10〜30秒が一般的で、時間が必要な復元は数時間〜数日をソフトデリートと復元画面で扱います。

長時間かかるバルクジョブでは「undo」は通常キャンセルを意味します。既にメールや支払いなど外部に影響を与えた処理を巻き戻すのは誤解を招くため、残りの作業をキャンセルし、既に処理済みの内容を示すのが現実的です。

元に戻せない場合は率直に伝え、回復経路を用意します：影響を受けたIDをエクスポートする、監査ログを残す、可能なら復元ワークフローを提供する、などです。

バックエンドの安全策：検証、冪等性、監査可能性

安全な一括操作はUIだけの問題ではありません。強力なプレビューがあっても、ユーザーがダブルクリックしたり、ブラウザがリトライしたり、バックグラウンドジョブが二度走ったりします。バックエンドはすべてのバルクリクエストを潜在的に危険と仮定し、安全に適用できることを証明する必要があります。

まず厳密な検証を行います。最初の1件だけでなく、すべての項目を検証してください。200件中3件が失敗するなら（必須フィールド欠損、状態不正、権限不足など）、バッチ全体を拒否するか、部分成功を許して項目ごとのエラーを明確にするかを事前に決めます。

冪等性は誤って二重適用されるのを防ぎます。各バルクリクエストに一意の idempotency key（またはリクエストID）を与え、結果を保存します。同じキーが再送されたら、更新を二度行わずに同じ結果を返します。

同時編集には楽観ロックを使います。レコードごとにバージョンや updated_at を保存し、更新時に一致する場合のみ書き換えるようにします。変化していたら競合を返し、他人の作業を上書きしないようにします。

有効なAPIパターンは2つあります：

• Dry-run：検証と権限チェックを実行し、件数とサンプル変更を返す。書き込みは行わない。
• Apply：確認用トークンや同じ選択を要求してから実際に書き込む。

システム保護のための実用的な制限も加えます：1リクエストあたりの最大件数の上限、削除にはより厳しいレート制限、バッチのタイムアウトなど。これで依存関係で詰まってジョブ全体が凍結するのを防ぎます。

最後に、すべての一括変更を監査可能にします。誰が行ったか、何が変わったか、範囲（フィルタ、件数）、前後データや差分、バッチ／ジョブIDをログに残すと、何が起きたかを説明しやすくなります。

信頼性を損なわずに一括処理をスケールする

一括操作が50件から50,000件に増えると、リスクはユーザーのミスだけでなく、処理途中でシステム負荷がかかり中途半端な状態が残ることです。

作業をチャンクに分けます。すべてのレコードを一つの長いトランザクションで更新するのではなく、バッチ（例：500〜2000件）ごとに処理し、各バッチ後に進捗を記録します。失敗したときにきれいに中断でき、テーブルロックを長時間維持することを避けられます。

大きなジョブはバックグラウンドで実行し、状態を明確に表示します：queued、running（"X of Y" 付き）、completed with issues、failed、canceled（対応する場合）など。

部分成功は正直に扱ってください。20%が失敗しているのに「完了」と表示してはいけません。成功したもの、失敗したものを表示し、失敗した項目だけを再試行する、失敗IDをエクスポートする、フィルタされたビューを開くなどの対処が容易であるべきです。

単純なルール：ジョブの現在状態を一文で説明できなければ、ユーザーはそれを信頼しません。

避けるべき一般的なミスと罠

多くの一括操作失敗は「ユーザーのミス」ではなく、UIが「選択」が何を意味するかを密かに変えたり、システムがユーザーの意図を最大に推定したりすることに起因します。

典型的な罠は「表示中の行すべて」と「検索結果すべて」を混同することです。画面上で20件選択してからそれが20,000件に拡張される場合、select all results をサポートするなら別の明示的なステップにして、アクションのそばに最終的な件数を常に表示してください。

別の問題は選択と適用の間にフィルタが静かに変わることです。ユーザーがある注文を選択してから共有ビューが変わりリストが更新されると、レビューしたものとは別のセットに適用される可能性があります。選択をスナップショット（選択ID）にバインドし、選択が変わったら警告してください。

項目の多いメニューも問題です。「Delete」が「Export」や「Tag」の隣にあると誤操作が起きます。破壊的操作を分離し、より明確な確認を要求してください。

また、UIでボタンを隠すことを権限管理の代わりにしてはいけません。バックエンドは必ず各項目を検証する必要があります。

一括操作のための簡単な安全チェックリスト

リリース前に、"意図しないことをしてしまった" という瞬間を防ぎ、サポート調査を格段に簡単にする基本を確認してください。

まず範囲の明確化から。ユーザーはアクションラベルだけでなく、実際に何が影響を受けるかを見られるべきです。件数とその件数を生んだ正確なフィルタや選択（例：「Status = Open, Assigned to = Me にマッチする132チケット」）を表示します。

次に高リスクな3点が隠れていないことを確認します：影響、権限、結果。

• 範囲が明示的：件数＋そのセットを作ったフィルタ/選択
• 危険な操作にはプレビュー：変更例や差分スタイルの要約
• サーバー側での権限強制：UIだけに頼らない
• 本当に戻れる手段：可能なら元に戻す／復元、不可逆なら事前に明確に表記
• 結果が記録される：監査ログと結果サマリ（成功、スキップ、失敗と理由）

現実的な例：サポートチケットを安全に一括クローズする

サポートリードがキャンペーン後のクリーンアップを行います。何百ものチケットが "promo-2026" とタグ付けされており、多くはセルフサービスで既に解決済みです。残りを一括でクローズしたいが、VIPケースや別チームが担当するチケットを誤って閉じたくありません。

フィルタしたリストからチケットを選択して「Close selected」を押す前に、プレビューで影響が具体化されます：

• 件数サマリ：183件がクローズされ、12件はスキップ、4件は要注意
• スキップ項目の平易な理由（例：「既にクローズ済み」や「VIPアカウントのため一括クローズ不可」）
• サンプルリスト（10件）と影響セットをエクスポートするオプション
• 正確な変更内容：status が "Closed" に、reason が "Campaign cleanup" に変わる
• 明確なプライマリボタン：「Close 183 tickets」

確定後、システムはバックグラウンドジョブを実行し進捗を表示します。完了すると、何件成功し何件失敗したか、失敗理由（例：実行中にエージェントがチケットを更新した）を示す結果画面が出ます。

バックエンドでは防御的に動きます：実行時に再度チケットごとの権限を確認し、許可された状態を検証し、監査レコードにバッチIDを記録し、小さなチャンクで更新して結果レポートを返します。

元に戻す処理は誠実に扱われます。UIは「このバッチを元に戻す」オプションを30分間表示します。クリックすると、そのバッチで変更されたチケットのみを対象に、かつその後編集されていない場合に元のステータスと理由を復元する新しいジョブを開始します。

次の一手：今週、1つの安全改善を実装する

一度に全面的な再設計は不要です。事故やサポート件数を減らす小さな変更を一つ選んでリリースし、そこから積み上げていきましょう。

まずは明確化から：ボタンのそばに「37 selected invoices」のような範囲ラベルを追加し、アクション実行後に成功／失敗の簡単な結果サマリを表示するだけで、多くの「1件だと思っていたのに…」というミスを防げます。

その後、高リスクな操作に着手します。大量削除、ステータス変更、権限に関わる更新には、保存前に影響を示すプレビューを追加してください。最初の10件の before -> after 表でも誤ったフィルタは検出できます。

多くのチームにとって実用的な順序：

• ボタンのそばに選択件数＋明確な範囲テキストを追加
• 結果画面に失敗と理由を表示（権限、検証）
• 最も危険な操作に対してプレビュー／ドライラン検証を追加
• 削除に対しては復元を追加（ソフトデリート＋復元ビュー）し、回復オプションをすぐ見せる
• 大きなバッチはバックグラウンドで実行し、完了時に通知

内部ツールや管理パネルを AppMaster 上で構築する場合、別システムを繋ぐことなく実装できます：Data Designer で PostgreSQL に監査とジョブのモデルを作り、Business Process Editor でレコードごとのルールを強制し、Web やモバイルの UI ビルダーでプレビュー・確認・結果画面を構築できます。評価目的のチームは appmaster.io を使ってワンアクションのプロトタイプを素早く作り、安全チェックが日常使いで違和感ないか試せます。