EN
JP
KRSwipe to Deleteとは？スワイプ削除の設計・実装・誤操作対策を解説
Swipe to Deleteは、一覧に表示された項目を横方向へ動かし、削除操作を実行する画面操作です。メール、メモ、タスク、通知、チャット履歴、保存済みコンテンツなど、多数の項目を扱うモバイルアプリで広く利用されています。画面上に削除ボタンを常時表示しなくても操作できるため、限られた表示領域を有効に使える点が大きな特徴です。
しかし、スワイプ削除を追加するだけでは、使いやすい画面になるとは限りません。削除が即時に確定するのか、途中で削除ボタンを表示するのか、どの程度動かしたときに処理を確定するのかによって、利用者の安心感と操作速度は大きく変わります。取り消し手段や通信失敗時の復元処理が不足していると、便利な機能が重大な誤操作の原因になります。
本記事では、Swipe to Deleteの意味から、適切な操作ルール、視覚表現、誤削除対策、状態管理、アクセシビリティ、テスト方法までを詳しく解説します。SwiftUI、Jetpack Compose、Web技術を使ったコード例も取り上げ、実際の開発へ落とし込める形で説明します。
1. Swipe to Deleteとは
Swipe to Deleteとは、一覧項目を指やポインターで横方向へ動かし、その項目に対する削除処理を呼び出す操作方式です。日本語では「スワイプ削除」と呼ばれます。項目を動かした距離や方向に応じて削除ボタンを表示したり、一定距離を超えた時点で削除を確定したりします。
1.1. スワイプ削除の仕組み
スワイプ削除では、利用者が一覧項目へ触れた位置を起点として、横方向の移動量を計測します。移動量が設定された判定値を超えると、削除候補の状態へ切り替えます。指を離した時点で判定値を超えていれば削除し、超えていなければ元の位置へ戻す処理が一般的です。
実際の画面では、項目の背面に赤い背景、削除アイコン、削除という文字を配置します。項目が移動するにつれて背面の操作領域が見えるため、利用者は何が起こるかを確認しながら操作できます。単純な座標移動ではなく、状態変化を視覚的に伝える仕組みとして設計する必要があります。
1.2. 利用される代表的な画面
スワイプ削除は、メール一覧、通知一覧、買い物リスト、タスク管理、メモ一覧など、同じ形式の項目が縦方向に並ぶ画面と相性が良い操作です。個々の項目に対する削除頻度が高く、利用者が内容を見ながら素早く整理したい場面で効果を発揮します。
一方で、銀行取引、注文履歴、契約情報、医療記録など、削除による影響が大きいデータには慎重な設計が必要です。操作頻度だけで採用を決めるのではなく、削除後に復元できるか、法的な保存義務がないか、ほかの利用者へ影響しないかまで確認しなければなりません。
1.3. 利用者が期待する動作
利用者は項目を少し動かした段階で、削除操作が可能であることを理解します。そのため、指の動きに対して項目が遅れずに追従し、削除領域が自然に表示されることが重要です。反応が遅い場合や途中で動きが止まる場合は、操作できない画面だと誤解される可能性があります。
また、途中まで動かして指を離した場合には、元の位置へ戻ることが期待されます。小さな横ぶれだけで削除される設計は危険です。スクロール中に指が斜めへ動くことも考慮し、縦移動と横移動を正確に区別する必要があります。
1.4. 削除ボタン表示型と即時削除型
削除ボタン表示型は、項目を途中まで動かしたときに削除ボタンを見せ、利用者がそのボタンを押すことで削除を確定する方式です。操作が二段階になるため、即時削除型よりも時間はかかりますが、誤削除を抑えやすくなります。
即時削除型は、項目を一定距離以上動かすだけで削除を実行します。大量の項目を連続して整理するときには効率的ですが、取り消し機能が事実上必須です。削除対象の重要度や復元可能性に応じて、どちらを採用するかを決める必要があります。
| 方式 | 削除確定までの操作 | 操作速度 | 誤削除リスク | 適した用途 |
|---|---|---|---|---|
| 削除ボタン表示型 | スワイプ後にボタンを押す | 中程度 | 低い | メール、保存データ |
| 即時削除型 | 一定距離までスワイプする | 速い | 高い | 通知、一時項目 |
| 確認画面併用型 | スワイプ後に確認する | 遅い | 非常に低い | 重要データ |
1.5. スワイプ削除に適したデータ
スワイプ削除に適しているのは、利用者が頻繁に整理し、削除後も一定期間復元できるデータです。例えば、既読通知、一時的な検索履歴、完了済みタスク、端末内の下書きなどが該当します。削除処理が日常的に発生するほど、操作回数を減らす効果が大きくなります。
反対に、削除によって料金、権限、共有状態、契約状態が変わるデータには適していません。このようなデータでは、「削除」という表現自体が正確でない場合もあります。解約、退会、共有解除、記録破棄など、実際に発生する処理を明示する必要があります。
2. スワイプ削除を採用するメリット
スワイプ削除は、単に新しい操作方法を追加する機能ではありません。適切に導入すると、一覧の視認性を保ちながら操作回数を減らし、項目整理にかかる時間を短縮できます。
2.1. 一覧画面をすっきり見せられる
各項目へ削除ボタンを常時配置すると、文字、画像、状態表示に使える横幅が少なくなります。特にスマートフォンでは、削除アイコンが並ぶことで情報量が多く見え、利用者が本来確認したい内容へ集中しにくくなります。
スワイプ削除では、操作が必要なときだけ削除領域を表示できます。通常時には件名、日時、送信者、進捗などの情報へ画面領域を使えるため、一覧の読みやすさを維持できます。ただし、削除手段が隠れるため、別の操作経路も用意することが重要です。
2.2. 項目整理の操作回数を減らせる
メニューを開き、削除を選び、確認する方式では、一件を削除するために複数回の操作が必要です。不要な通知や完了済みタスクを何件も処理する場合、操作回数の差が大きな負担になります。
スワイプ削除では、項目を動かす一連の動作だけで削除できます。取り消し通知を組み合わせれば、事前確認画面を毎回表示せずに安全性を確保できます。頻度の高い操作ほど、事前確認よりも事後取り消しが有効になる場合があります。
2.3. 片手で操作しやすくなる
スマートフォンを片手で持っている利用者にとって、画面端や上部にある小さな削除ボタンは押しにくいことがあります。項目全体を操作対象にできるスワイプ削除は、比較的広い範囲から動作を開始できます。
ただし、片手操作のしやすさは、左右どちらの手を使うかによって変わります。削除方向を固定する場合は、表示言語、文字方向、端末の持ち方を考慮する必要があります。両方向に異なる操作を割り当てるときは、学習負担が増えないように役割を統一します。
2.4. 操作対象と結果を結び付けやすい
削除ボタンが画面上部にある場合、どの項目が削除されるのか分かりにくくなることがあります。スワイプ削除では、利用者自身が対象項目を直接動かすため、操作対象と結果の関係を理解しやすくなります。
項目が画面外へ移動し、その下の項目が詰まる動きによって、削除が完了したことも視覚的に伝えられます。ただし、通信処理が終わる前に完全に消す場合は、失敗時の復元方法を設計しなければなりません。
2.5. 複数の補助操作を配置できる
横方向の操作領域には、削除だけでなく、アーカイブ、未読化、固定、完了、保存などを配置できます。利用頻度の高い操作を一覧上から呼び出せるため、詳細画面へ移動する回数を減らせます。
一方で、表示する操作が多すぎるとボタンの幅が狭くなり、押し間違いが増えます。重要度の高い一つから三つ程度に絞り、残りは詳細画面やその他メニューへ配置する設計が適しています。
| 操作数 | 視認性 | 押しやすさ | 推奨される使い方 |
|---|---|---|---|
| 1個 | 高い | 高い | 削除のみ |
| 2個 | 高い | 高い | 削除と保存 |
| 3個 | 中程度 | 中程度 | 削除、保存、固定 |
| 4個以上 | 低い | 低い | その他メニューへ移す |
3. 導入前に決める操作ルール
スワイプ削除の品質は、実装コードよりも先に決める操作ルールによって左右されます。方向、移動距離、確定条件、対象データ、取り消し時間を明文化し、画面ごとの動作差を減らすことが重要です。
3.1. スワイプ方向を決める
日本語のように左から右へ読む画面では、項目を左へ動かして右端から削除操作を表示する構成がよく使われます。ただし、方向そのものに絶対的な正解があるわけではありません。既存画面や対象端末の操作慣習と一致させる必要があります。
同じアプリ内で、ある画面では左方向が削除、別の画面では右方向が削除になる設計は避けます。異なる動作を割り当てる場合も、左方向は破棄系、右方向は完了系など、意味を統一すると学習しやすくなります。
3.2. 削除を確定する距離を決める
判定距離が短すぎると、縦スクロール中のわずかな横ずれで削除される可能性があります。反対に長すぎると、指を大きく動かさなければならず、片手操作の負担が増えます。固定ピクセルだけでなく、項目幅に対する割合で設計すると端末差へ対応しやすくなります。
例えば、項目幅の25％で削除ボタンを完全表示し、60％を超えた場合に完全スワイプとして削除する方法があります。実際の値は、項目の高さ、利用者層、データの重要度を踏まえて実機で調整します。
| 移動量の目安 | 画面状態 | 推奨処理 |
|---|---|---|
| 0～10％ | 小さな横ぶれ | 操作を開始しない |
| 10～25％ | 操作開始 | 背景を表示する |
| 25～60％ | 操作候補 | 削除ボタンを表示する |
| 60％以上 | 完全スワイプ | 条件に応じて削除する |
3.3. 指を離した後の動きを決める
判定距離に達していない場合は、項目を滑らかに元の位置へ戻します。急に位置を戻すと画面が不自然に見えるため、短い戻り動作を入れます。動作時間が長すぎると次の操作を妨げるため、速度と自然さの両方を確認します。
削除が確定した場合は、項目を横方向へ退場させた後、高さを縮めて一覧を詰める方法があります。横移動と高さ変更を同時に行うと表示が崩れやすいため、順番や時間差を調整することが大切です。
3.4. 同時に開ける項目数を決める
複数の項目で削除ボタンを開いたままにすると、どの項目を操作しているのか分かりにくくなります。通常は、新しい項目をスワイプした時点で、以前に開いていた項目を閉じる設計が分かりやすいでしょう。
画面をスクロールした場合や、一覧外を押した場合にも、開いている操作領域を閉じます。操作状態を項目ごとに独立して管理するのではなく、現在開いている項目識別子を一覧全体で一つだけ持つと制御しやすくなります。
3.5. 削除後の扱いを決める
削除後のデータを完全に消去するのか、一定期間ごみ箱へ移すのかを事前に決定します。画面上では同じ「削除」でも、内部処理が異なると利用者が期待する復元可能性も変わります。
重要なデータでは、画面上から非表示にする論理削除を採用し、一定期間後に完全削除する方法があります。軽量な一時データでは即時削除でも問題ありません。すべてのデータへ同じ削除方式を適用するのではなく、データ分類ごとに方針を設定します。
4. 誤削除を防ぐ画面設計
スワイプ削除では、操作速度を保ちながら誤削除を防ぐ必要があります。毎回確認画面を表示すると安全性は高まりますが、一覧整理の効率が失われるため、削除対象に応じて対策を使い分けます。
4.1. 削除領域を段階的に表示する
指が少し動いただけで削除背景を全面表示すると、画面変化が急になり、利用者を驚かせることがあります。移動量に応じて背景、アイコン、文字を段階的に表示すると、操作の進行状態を把握しやすくなります。
削除アイコンの大きさや不透明度を変化させる方法も有効です。ただし、複雑な動きを追加しすぎると処理が重くなり、項目の追従性が低下します。装飾よりも、指の動きに遅れず反応することを優先します。
4.2. 完全スワイプの可否を使い分ける
完全スワイプとは、項目を大きく動かしたとき、削除ボタンを押さずに処理を確定する動作です。SwiftUIのswipeActionsでは、完全スワイプを許可するかどうかを指定できます。 や一時項目では完全スワイプを許可し、保存情報や共有データでは無効にするといった使い分けが必要です。完全スワイプを有効にする場合は、取り消し通知を必ず検討します。
4.3. 重要データには確認画面を追加する
アカウント、プロジェクト、共有ファイルなど、削除の影響が大きい対象では確認画面が必要です。確認文には「削除しますか」だけでなく、何が削除され、どの範囲へ影響するのかを記載します。
確認画面を追加する場合でも、すべての操作へ同じ文章を使い回さないことが重要です。「このプロジェクトと関連タスクを削除します」のように対象を明確にし、削除ボタンには破壊的操作であることが分かる表現を使用します。
4.4. 取り消し可能な時間を設ける
削除直後に短時間だけ取り消せる通知を表示すると、確認画面を省略しながら安全性を確保できます。利用者は誤操作に気付いた時点で元へ戻せるため、項目整理の流れを中断する必要がありません。
通知の表示時間が短すぎると、内容を理解する前に消えてしまいます。長すぎると画面を占有し、別の通知と競合します。対象データの重要度と利用状況を踏まえ、実機テストで適切な時間を決定します。
4.5. 削除できない項目を明確にする
管理者が作成した固定項目や、処理中のデータなど、削除できない項目が一覧へ含まれる場合があります。このような項目がスワイプに反応すると、利用者は削除できると誤解します。
削除不可の項目では横移動自体を無効にするか、操作を開始した際に理由を表示します。ただし、移動後にエラーを出すよりも、最初から操作できないことを視覚的に示す方が分かりやすい場合があります。
| 対象データ | 完全スワイプ | 確認画面 | 取り消し |
|---|---|---|---|
| 一時通知 | 許可しやすい | 原則不要 | 推奨 |
| 完了タスク | 条件付きで許可 | 原則不要 | 推奨 |
| 保存済みメモ | 慎重に判断 | 状況により必要 | 必須に近い |
| 共有ファイル | 非推奨 | 必要 | 必要 |
| アカウント | 使用しない | 必須 | 削除猶予を設ける |
5. 削除動作を伝える視覚表現
利用者はスワイプ中に表示される色、文字、アイコン、動きから、操作結果を予測します。見た目を整えるだけでなく、現在の状態と次に起こる処理を正確に伝えることが重要です。
5.1. 削除背景の色を選ぶ
破壊的操作には赤系の色がよく用いられますが、色だけに意味を持たせてはいけません。色覚特性や画面設定によって、色の違いを判別しにくい利用者がいるためです。
赤い背景には、ごみ箱アイコンや「削除」という文字を組み合わせます。また、背景色と文字色の明度差を確保し、屋外や低輝度設定でも内容を読めるようにします。
5.2. 削除アイコンを配置する
ごみ箱アイコンは削除を示す表現として理解されやすい一方、アーカイブや非表示とは意味が異なります。実際の処理が保存場所の移動である場合は、ごみ箱以外のアイコンを使用します。
アイコンはスワイプ量に応じて不自然に移動しないよう、削除領域内で位置を固定するか、限定された範囲だけ動かします。項目に追従させすぎると、操作対象と操作ボタンの境界が分かりにくくなります。
5.3. 文字ラベルを併用する
アイコンだけでは、完全削除、ごみ箱への移動、一覧からの非表示を区別できない場合があります。「削除」「ごみ箱へ移動」「履歴から消去」など、実際の処理に合った文字を表示します。
表示領域が狭い場合は、アイコンだけを見せる段階と、文字まで表示する段階を分けられます。十分な距離まで動かしたときに文字を表示すると、画面を圧迫せずに結果を説明できます。
5.4. 判定到達を動きで知らせる
完全スワイプの判定距離へ到達したとき、アイコンの大きさを少し変える、背景を広げるなどの反応を加えると、指を離せば削除されることを伝えられます。
端末が対応している場合は、軽い触覚反応を組み合わせる方法もあります。ただし、繰り返し操作する画面で強い反応を毎回発生させると不快感につながります。判定到達時に一度だけ反応させます。
5.5. 削除後の空白を自然に埋める
項目が消えた直後に一覧全体が瞬間的に移動すると、利用者が視線を置いていた位置を見失うことがあります。削除項目の高さを短時間で縮め、下の項目を滑らかに移動させると変化を追いやすくなります。
一方で、長い動きは連続削除を妨げます。視覚的な理解に必要な時間だけを確保し、次の項目をすぐ操作できる状態へ戻す必要があります。低性能端末でも滑らかに動作するか確認します。
6. iOSでスワイプ削除を実装する方法
SwiftUIでは、一覧行へswipeActionsを設定することでスワイプ操作を追加できます。UIKitでは、表形式の一覧に対してUISwipeActionsConfigurationを使用できます。Appleの公式資料でも、これらは一覧行へスワイプ操作を設定するための仕組みとして提供されています。 SwiftUIで一覧を作成する
SwiftUIでは、配列データをListやForEachへ渡して一覧を構成します。各データには一意の識別子を持たせ、削除時に対象を正確に特定できるようにします。
配列の位置だけで対象を管理すると、並び替えや通信更新によって異なる項目を削除する危険があります。削除処理では、位置ではなく識別子を基準にデータを更新する設計が安全です。
SwiftUIの一覧コード例
struct TaskItem: Identifiable {
let id: UUID
var title: String
}
struct TaskListView: View {
@State private var tasks: [TaskItem] = [
TaskItem(id: UUID(), title: "資料を確認する"),
TaskItem(id: UUID(), title: "メールを返信する")
]
var body: some View {
List(tasks) { task in
Text(task.title)
}
}
}
6.2. swipeActionsで削除ボタンを表示する
各行へswipeActionsを追加し、その内部に削除用のButtonを配置します。破壊的操作として設定すると、利用者が削除操作であることを認識しやすい表示になります。
allowsFullSwipeをfalseに設定すると、完全スワイプによる即時実行を防げます。重要なデータでは削除ボタンを明示的に押させ、軽量なデータでは完全スワイプを許可するなど、用途に応じて変更します。
swipeActionsのコード例
List(tasks) { task in
Text(task.title)
.swipeActions(
edge: .trailing,
allowsFullSwipe: false
) {
Button(role: .destructive) {
deleteTask(id: task.id)
} label: {
Label("削除", systemImage: "trash")
}
}
}
private func deleteTask(id: UUID) {
tasks.removeAll { $0.id == id }
}
6.3. 完全スワイプを制御する
完全スワイプを有効にすると、削除ボタンが表示された後も項目を動かし続けることで、ボタンを押さずに処理を実行できます。大量の通知を整理する画面では効率的です。
ただし、完全スワイプは誤操作の可能性も高めます。削除後に取り消しできないデータや、ほかの利用者へ影響するデータでは、allowsFullSwipeを無効にする方が安全です。
完全スワイプを許可するコード例
.swipeActions(
edge: .trailing,
allowsFullSwipe: true
) {
Button(role: .destructive) {
pendingDeletion = task
removeFromList(task)
} label: {
Label("削除", systemImage: "trash")
}
}
6.4. 削除前に確認画面を表示する
確認が必要な場合は、スワイプ操作の時点で直接削除せず、削除候補のデータを状態として保存します。その状態を使って確認画面を表示し、確定ボタンが押されたときに削除します。
削除対象を単なる真偽値で管理すると、どの項目を削除するのか分からなくなることがあります。確認対象の識別子またはデータ本体を保持し、確認画面内でも項目名を表示します。
確認画面を表示するコード例
@State private var deleteTarget: TaskItem?
.swipeActions {
Button(role: .destructive) {
deleteTarget = task
} label: {
Label("削除", systemImage: "trash")
}
}
.confirmationDialog(
"この項目を削除しますか",
isPresented: Binding(
get: { deleteTarget != nil },
set: { if !$0 { deleteTarget = nil } }
)
) {
Button("削除", role: .destructive) {
if let target = deleteTarget {
deleteTask(id: target.id)
}
deleteTarget = nil
}
Button("キャンセル", role: .cancel) {
deleteTarget = nil
}
}
6.5. 通信処理と画面状態を連携する
サーバー上のデータを削除する場合は、画面から消す処理と通信処理を分けて管理します。通信完了まで項目を残すと安全ですが、反応が遅く見えることがあります。
先に項目を非表示にする場合は、通信失敗時に元の位置へ戻せる情報を保存します。識別子だけでなく、元の並び順や項目データも保持しておくと、正確に復元できます。
非同期削除のコード例
private func deleteTask(_ task: TaskItem) async {
guard let index = tasks.firstIndex(where: { $0.id == task.id }) else {
return
}
tasks.remove(at: index)
do {
try await repository.deleteTask(id: task.id)
} catch {
tasks.insert(task, at: min(index, tasks.count))
errorMessage = "削除できませんでした"
}
}
7. Androidでスワイプ削除を実装する方法
Jetpack Composeでは、SwipeToDismissBoxを使って左右へのスワイプによる削除や状態変更を実装できます。背景部分と前面の項目を分けて定義できるため、移動方向に応じた操作表示も作成できます。 LazyColumnで一覧を表示する
Jetpack Composeで縦方向の一覧を作成する場合は、LazyColumnを使用します。表示項目へ安定したキーを設定すると、削除や並び替えが発生した場合でも、各項目の状態を正しく追跡しやすくなります。
配列の位置をキーにすると、項目が削除された際に別項目へ状態が引き継がれることがあります。データベースの識別子など、内容が更新されても変わらない値を使用します。
LazyColumnのコード例
@Composable
fun TaskList(
tasks: List<Task>,
onDelete: (Task) -> Unit
) {
LazyColumn {
items(
items = tasks,
key = { task -> task.id }
) { task ->
TaskRow(
task = task,
onDelete = onDelete
)
}
}
}
7.2. SwipeToDismissBoxを設定する
SwipeToDismissBoxでは、操作状態、背面表示、前面内容を定義します。状態が削除方向へ到達したときに処理を実行し、対象項目を一覧から取り除きます。
削除処理を画面再構成のたびに繰り返さないよう、状態変化を確認して一度だけ処理する必要があります。画面の状態管理層へ削除要求を送り、一覧データを更新する構成が適しています。
SwipeToDismissBoxのコード例
@Composable
fun TaskRow(
task: Task,
onDelete: (Task) -> Unit
) {
val dismissState = rememberSwipeToDismissBoxState(
confirmValueChange = { value ->
if (value == SwipeToDismissBoxValue.EndToStart) {
onDelete(task)
true
} else {
false
}
}
)
SwipeToDismissBox(
state = dismissState,
enableDismissFromStartToEnd = false,
enableDismissFromEndToStart = true,
backgroundContent = {
DeleteBackground()
}
) {
TaskContent(task)
}
}
7.3. 背景へ削除表示を追加する
backgroundContentには、項目の背面に表示する色、文字、アイコンを配置します。削除方向に合わせて内容を右端または左端へ寄せることで、操作結果を理解しやすくできます。
背景全体を押せるボタンとして扱う場合は、押せる範囲とスワイプ範囲が競合しないようにします。スワイプ操作だけで削除する設計では、背景表示を案内として使用します。
削除背景のコード例
@Composable
fun DeleteBackground() {
Box(
modifier = Modifier
.fillMaxSize()
.background(MaterialTheme.colorScheme.errorContainer)
.padding(horizontal = 24.dp),
contentAlignment = Alignment.CenterEnd
) {
Row(
verticalAlignment = Alignment.CenterVertically
) {
Icon(
imageVector = Icons.Default.Delete,
contentDescription = null
)
Spacer(modifier = Modifier.width(8.dp))
Text("削除")
}
}
}
7.4. Snackbarで取り消しを提供する
Jetpack ComposeのSnackbarは、処理結果を短時間通知し、操作ボタンを表示する用途に利用できます。公式資料でも、一定時間後に消える通知と、利用者が実行できる操作を組み合わせる部品として説明されています。 す」を表示する場合は、削除した項目と元の位置を一時保存します。別の削除が続いた場合に通知を上書きするのか、削除履歴をまとめて保持するのかも決めておきます。
取り消し処理のコード例
scope.launch {
val result = snackbarHostState.showSnackbar(
message = "項目を削除しました",
actionLabel = "取り消す",
withDismissAction = true
)
if (result == SnackbarResult.ActionPerformed) {
viewModel.restoreTask(
task = deletedTask,
index = originalIndex
)
} else {
viewModel.commitDeletion(deletedTask.id)
}
}
7.5. 状態管理層へ削除処理を移す
画面内で直接配列を書き換えるだけでは、画面回転、再読み込み、通信更新が発生したときに状態が失われる可能性があります。削除対象や通信状態を状態管理層で保持すると、画面の再構成に耐えやすくなります。
画面は削除要求を通知し、状態管理層が一覧更新、通信、失敗時の復元を担当する構成が分かりやすいでしょう。処理の責任を分離することで、単体テストも行いやすくなります。
状態管理のコード例
class TaskViewModel(
private val repository: TaskRepository
) : ViewModel() {
private val _tasks = MutableStateFlow<List<Task>>(emptyList())
val tasks: StateFlow<List<Task>> = _tasks
fun removeTemporarily(task: Task) {
_tasks.update { list ->
list.filterNot { item -> item.id == task.id }
}
}
fun deletePermanently(taskId: String) {
viewModelScope.launch {
repository.delete(taskId)
}
}
}
8. Webアプリでスワイプ削除を実装する方法
Webアプリでは、ポインター操作を取得し、項目の横方向移動を画面へ反映します。タッチ操作だけでなく、マウス、タッチパッド、ペン入力も考慮すると、より多くの環境へ対応できます。
8.1. ポインター操作を取得する
項目を押した時点で開始位置を記録し、移動中に現在位置との差を計算します。横方向の移動量が一定値を超えた場合にのみ、スワイプ操作として扱います。
移動開始直後に横操作と判定すると、縦スクロールが妨げられます。最初の移動方向を確認し、縦方向の変化が大きい場合はスワイプ処理を中止する必要があります。
ポインター操作のコード例
const row = document.querySelector(".swipe-row");
let startX = 0;
let startY = 0;
let currentX = 0;
let dragging = false;
let horizontalGesture = false;
row.addEventListener("pointerdown", (event) => {
startX = event.clientX;
startY = event.clientY;
dragging = true;
horizontalGesture = false;
row.setPointerCapture(event.pointerId);
});
row.addEventListener("pointermove", (event) => {
if (!dragging) return;
const deltaX = event.clientX - startX;
const deltaY = event.clientY - startY;
if (!horizontalGesture) {
if (Math.abs(deltaY) > Math.abs(deltaX)) return;
horizontalGesture = true;
}
currentX = Math.min(0, deltaX);
row.style.transform = `translateX(${currentX}px)`;
});
8.2. 移動可能な方向を制限する
削除操作を左方向だけに割り当てる場合、正方向の移動量をゼロへ制限します。これにより、反対側へ項目が不自然に動くことを防げます。
ただし、右から左へ読む言語に対応する場合は、固定された左右ではなく、開始側と終了側を基準に設計します。文字方向に応じて削除領域の位置と移動方向を切り替えます。
移動方向を制御するコード例
function getSwipeOffset(deltaX, direction) {
const maximum = 120;
if (direction === "end-to-start") {
return Math.max(-maximum, Math.min(0, deltaX));
}
return Math.min(maximum, Math.max(0, deltaX));
}
8.3. 指を離したときに判定する
ポインターを離した時点で、移動距離が判定値を超えているか確認します。超えていない場合は元の位置へ戻し、超えている場合は削除ボタンを開くか、削除処理を実行します。
移動速度も判定に含める方法がありますが、速度だけで削除を確定すると意図しない操作が増える可能性があります。最初は距離を中心に判定し、実機テストの結果を見て速度条件を追加します。
削除判定のコード例
const DELETE_THRESHOLD = 96;
row.addEventListener("pointerup", () => {
dragging = false;
if (Math.abs(currentX) >= DELETE_THRESHOLD) {
openDeleteAction(row);
} else {
resetPosition(row);
}
});
function resetPosition(element) {
element.style.transition = "transform 180ms ease";
element.style.transform = "translateX(0)";
window.setTimeout(() => {
element.style.transition = "";
}, 180);
}
8.4. CSSで削除背景を作る
削除背景は一覧項目の背面に配置し、前面の項目だけを移動させます。親要素の外側へ内容が表示されないよう、必要に応じてはみ出しを隠します。
前面項目に背景色が設定されていないと、移動中に背面と内容が重なって見えることがあります。通常状態の背景色を明示し、重なり順も設定します。
CSSのコード例
.swipe-container {
position: relative;
overflow: hidden;
}
.delete-background {
position: absolute;
inset: 0;
display: flex;
align-items: center;
justify-content: flex-end;
padding-inline: 24px;
background: #b3261e;
color: #ffffff;
}
.swipe-row {
position: relative;
background: #ffffff;
touch-action: pan-y;
will-change: transform;
}
8.5. キーボード操作を用意する
Webアプリでは、すべての利用者がタッチ操作を使うわけではありません。項目へフォーカスした状態で削除ボタンを押せるようにし、スワイプだけに依存しない設計が必要です。
削除ボタンを視覚的に隠す場合でも、フォーカス時には表示する、その他メニューから選べるようにするなど、代替経路を提供します。キーボードのDeleteキーへ直接割り当てる場合は、入力欄との競合にも注意します。
キーボード対応のコード例
row.addEventListener("keydown", (event) => {
if (event.key !== "Delete") return;
event.preventDefault();
showDeleteConfirmation({
id: row.dataset.itemId,
title: row.dataset.itemTitle
});
});
9. スワイプ削除と他の削除操作の違い
削除操作には、スワイプ以外にも、常設ボタン、長押し、その他メニュー、複数選択、ドラッグ操作などがあります。それぞれ操作速度、発見しやすさ、安全性が異なるため、画面の目的に合わせて選びます。
9.1. 常設削除ボタンとの違い
常設削除ボタンは、削除手段が最初から見えているため、利用者が機能を発見しやすい方法です。初めて使う画面や、タッチ操作に慣れていない利用者が多いサービスでは有効です。
スワイプ削除は表示領域を節約できますが、操作方法を知らない利用者には気付かれない可能性があります。そのため、初回案内やその他メニューなど、別の削除方法を組み合わせます。
| 比較項目 | スワイプ削除 | 常設削除ボタン |
|---|---|---|
| 発見しやすさ | 低い場合がある | 高い |
| 表示領域 | 節約できる | ボタン分を使用する |
| 連続操作 | 速い | 押す位置によって変わる |
| 誤操作 | 判定距離に左右される | 小さいボタンでは起こりやすい |
| 適した画面 | 情報量の多い一覧 | 操作数の少ない一覧 |
9.2. 長押し操作との違い
長押しは、項目へ触れ続けることで操作メニューを表示する方式です。削除だけでなく、共有、複製、移動など、多数の操作をまとめて提示できます。
一方で、長押しに必要な時間があるため、連続削除には向きません。長押しできることも画面上から分かりにくいため、主要操作として単独採用するより、補助操作として使用する方が適しています。
| 比較項目 | スワイプ削除 | 長押し操作 |
|---|---|---|
| 操作速度 | 速い | 待ち時間がある |
| 表示できる操作数 | 少ない | 多い |
| 発見しやすさ | 低い場合がある | さらに低い場合がある |
| 片手操作 | しやすい | 押し続ける必要がある |
| 適した用途 | 頻繁な削除 | 複数操作のメニュー |
9.3. その他メニューとの違い
その他メニューは、三点アイコンなどを押して操作一覧を開く方法です。削除以外の操作も同じ場所へ集約できるため、項目ごとの操作体系を統一できます。
ただし、削除までに必要な操作回数は増えます。削除頻度が低い画面では問題ありませんが、通知整理やタスク整理のように繰り返し削除する画面では負担になります。
| 比較項目 | スワイプ削除 | その他メニュー |
|---|---|---|
| 削除までの操作 | 少ない | 多い |
| 操作の発見 | 慣れが必要 | アイコンから推測できる |
| 操作数 | 少数向け | 多数向け |
| 一覧の見た目 | すっきりする | メニューアイコンが必要 |
| 適した用途 | 高頻度操作 | 低頻度の補助操作 |
9.4. 複数選択削除との違い
複数選択削除は、複数の項目を選択してからまとめて削除する方式です。大量の項目を一度に整理する場合は、一件ずつスワイプするよりも効率的です。
一方で、数件だけを素早く削除する場合は、選択状態への切り替えが負担になります。少数処理にはスワイプ削除、大量処理には複数選択というように、両方を提供すると柔軟性が高まります。
| 比較項目 | スワイプ削除 | 複数選択削除 |
|---|---|---|
| 少数項目の削除 | 得意 | 操作が多い |
| 大量項目の削除 | 時間がかかる | 得意 |
| 対象確認 | 一件ずつ確認できる | 選択漏れに注意が必要 |
| 実装負荷 | 中程度 | 選択状態の管理が必要 |
| 適した用途 | 日常的な整理 | 一括整理 |
9.5. ドラッグして削除する方式との違い
ドラッグ削除は、項目を画面内のごみ箱領域まで移動して削除する方法です。対象を移動させる感覚が強く、編集画面や配置画面では理解しやすい場合があります。
しかし、一覧画面で毎回ごみ箱まで動かすと移動距離が長くなります。スワイプ削除は項目の近くで操作が完結するため、縦長の一覧では効率的です。
| 比較項目 | スワイプ削除 | ドラッグ削除 |
|---|---|---|
| 指の移動距離 | 短い | 長くなりやすい |
| 操作結果の理解 | 背景表示が必要 | ごみ箱への移動で理解しやすい |
| 一覧との相性 | 高い | 低い場合がある |
| 配置編集との相性 | 中程度 | 高い |
| 誤操作対策 | 判定距離と取り消し | 削除領域の大きさと確認 |
10. データ更新と状態管理の設計
画面上の項目を消す処理と、保存先からデータを削除する処理は分けて考える必要があります。特にサーバー通信を伴う場合は、通信中、成功、失敗、取り消し待ちの状態を明確に管理します。
10.1. 削除状態を段階に分ける
削除処理を一つの真偽値だけで管理すると、通信中なのか、取り消し待ちなのかを区別できません。状態を段階に分けることで、画面表示と内部処理を正確に連携できます。
例えば、通常、削除候補、取り消し待ち、送信中、削除完了、復元中、失敗という状態を設定します。すべてを画面へ表示する必要はありませんが、内部では処理の進行を追跡できるようにします。
| 状態 | 画面表示 | 実行する処理 |
|---|---|---|
| 通常 | 項目を表示 | 操作待ち |
| 削除候補 | 背景を表示 | 指の移動を追跡 |
| 取り消し待ち | 項目を非表示 | 一時保存 |
| 送信中 | 非表示または処理中表示 | 削除要求を送信 |
| 失敗 | 項目を復元 | エラーを通知 |
| 完了 | 一覧から除外 | 一時情報を破棄 |
10.2. 識別子を使って対象を管理する
一覧の何番目にあるかを示す位置情報は、削除や並び替えによって変化します。通信開始時の位置をそのまま使用すると、処理完了時に別の項目を操作する危険があります。
削除要求には一意の識別子を使用します。画面へ復元する場合に備えて、識別子と一緒に元の位置や親項目の識別子も保存すると、正しい場所へ戻しやすくなります。
10.3. 先行更新を採用する
先行更新では、サーバーから成功応答を受け取る前に、画面上の項目を削除します。利用者には処理がすぐ完了したように見えるため、操作感を高められます。
ただし、通信に失敗した場合は画面状態を戻す必要があります。復元対象のデータを保持せずに項目を消すと、再取得するまで元へ戻せません。失敗処理まで含めて一つの機能として実装します。
先行更新のコード例
async function removeItem(itemId) {
const index = items.findIndex((item) => item.id === itemId);
if (index < 0) return;
const removedItem = items[index];
items.splice(index, 1);
renderItems();
try {
await api.deleteItem(itemId);
} catch (error) {
items.splice(index, 0, removedItem);
renderItems();
showMessage("削除に失敗したため項目を戻しました");
}
}
10.4. 複数削除の競合を防ぐ
利用者が短時間に複数項目を削除すると、複数の通信処理が同時に進みます。応答順序が操作順序と異なる場合もあるため、一つの共有変数だけで削除対象を管理してはいけません。
削除要求ごとに識別子、元の位置、通信状態を持たせます。ある項目の通信失敗によって、別の項目まで復元されないよう、処理単位を分離します。
10.5. 一覧再取得との競合を処理する
削除処理中に一覧の再読み込みが行われると、削除した項目が一時的に再表示される場合があります。サーバー側の更新反映に時間がかかる環境では、特に発生しやすい問題です。
取り消し待ちまたは削除送信中の識別子を保持し、再取得結果から一時的に除外する方法があります。削除が失敗した場合のみ除外状態を解除し、項目を再表示します。
11. 取り消し機能を組み込む方法
取り消し機能は、スワイプ削除の速度と安全性を両立させるための重要な仕組みです。削除前の確認を減らせるだけでなく、利用者が自分で誤操作を修正できるようになります。
11.1. 削除直後に通知を表示する
項目が消えた直後に、「項目を削除しました」という通知と「取り消す」ボタンを表示します。どの項目を削除したか分かるように、可能であれば項目名も含めます。
ただし、個人情報や機密情報を通知へそのまま表示することが適切でない場合があります。その場合は、「メッセージを削除しました」など、対象の種類だけを表示します。
11.2. 完全削除を遅らせる
取り消し時間中は、サーバーへ完全削除要求を送らず、画面上だけから項目を取り除く方法があります。通知が消えた後に完全削除を実行すれば、取り消し処理を単純化できます。
一方で、アプリが途中で終了した場合の扱いを決める必要があります。削除待ち情報を保存し、次回起動時に送信するのか、削除を取り消すのかを明確にします。
遅延削除のコード例
function scheduleDeletion(item, delay = 5000) {
const timerId = window.setTimeout(async () => {
await api.deleteItem(item.id);
pendingDeletions.delete(item.id);
}, delay);
pendingDeletions.set(item.id, {
item,
timerId
});
}
function undoDeletion(itemId) {
const pending = pendingDeletions.get(itemId);
if (!pending) return;
window.clearTimeout(pending.timerId);
restoreItem(pending.item);
pendingDeletions.delete(itemId);
}
11.3. 元の位置へ復元する
取り消し時に項目を一覧末尾へ追加すると、利用者が元の項目を見失います。削除前の位置を保存し、可能な限り同じ場所へ復元します。
ただし、取り消し待ちの間に並び順が変わった場合、古い位置へ戻すと不自然になることがあります。日時順など明確な並び規則がある場合は、位置情報ではなく並び規則に従って再挿入します。
11.4. 連続削除へ対応する
複数の項目を連続して削除した場合、最後の一件だけを取り消せる設計と、一定時間内の削除をまとめて取り消せる設計があります。どちらが適切かは利用場面によって異なります。
通知を一件ごとに積み重ねると画面を占有します。最後の削除だけを表示する、件数をまとめて表示する、削除履歴画面を用意するなど、連続操作を想定した設計が必要です。
| 方式 | 長所 | 注意点 |
|---|---|---|
| 最後の一件だけ取り消す | 実装と表示が簡単 | 以前の削除を戻せない |
| 削除ごとに通知する | 個別に戻せる | 通知が増える |
| 複数件をまとめる | 画面を占有しにくい | 対象確認が難しい |
| ごみ箱へ移動する | 後から復元できる | 保存期間の管理が必要 |
11.5. 取り消し期限を明確にする
取り消し通知が消える時点で完全削除される場合は、利用者が操作可能な時間を理解できるようにします。通知を突然消すだけでは、いつまで戻せるのか判断できません。
時間表示を必ず付ける必要はありませんが、通知の表示時間と処理確定時点を一致させます。通知が消えた後も内部では取り消せる、または通知が残っているのに削除が確定しているといった不一致は避けます。
12. アクセシビリティを高める方法
スワイプ操作は、画面を見ながら指を正確に動かせることを前提にしやすい操作です。すべての利用者が同じ方法で操作できるとは限らないため、ボタン、読み上げ、キーボードなどの代替経路を提供します。
12.1. スワイプ以外の削除方法を用意する
削除機能をスワイプだけにすると、操作方法を知らない利用者や、細かな指の動きが難しい利用者が機能へ到達できません。詳細画面やその他メニューにも削除ボタンを配置します。
同じ処理を複数箇所に実装するのではなく、共通の削除処理を呼び出すようにします。操作経路が異なっても、確認、取り消し、通信失敗時の挙動を統一できます。
12.2. 読み上げ用の説明を付ける
削除アイコンには、読み上げ機能が理解できる説明を設定します。単に「ボタン」と読み上げられるのではなく、「タスクを削除」のように、対象と操作内容を伝えます。
装飾目的のアイコンと、操作内容を示す文字が同時に存在する場合は、同じ内容を二重に読み上げないよう注意します。どの要素が操作名を担当するかを明確にします。
12.3. アクセシビリティ操作を追加する
Jetpack Composeでは、スワイプ削除に対応する独自操作を意味情報へ追加できます。公式資料でも、スワイプ操作の代わりに実行できる操作名と処理を設定する例が示されています。 項目へ移動した際に、「削除」という操作を選択できるようにします。表示上のスワイプ処理と同じ削除関数を呼び出し、挙動の違いを防ぎます。
Composeのアクセシビリティコード例
Modifier.semantics {
customActions = listOf(
CustomAccessibilityAction(
label = "タスクを削除",
action = {
onDelete(task)
true
}
)
)
}
12.4. 色だけで状態を表現しない
削除領域を赤くするだけでは、色を識別しにくい利用者へ意味が伝わりません。アイコン、文字、位置、形状を組み合わせて削除操作を示します。
通信失敗や取り消し状態についても、色だけに依存しないようにします。「削除できませんでした」などの文章を表示し、必要に応じて再試行ボタンを提供します。
12.5. 動きを減らす設定へ対応する
大きな横移動や縮小動作は、一部の利用者に不快感を与える場合があります。端末やブラウザーの動きを減らす設定を確認し、設定が有効な場合は動作時間を短くするか、移動効果を簡略化します。
動きを完全に消す場合でも、削除されたことが分からなくならないよう、通知や状態文を表示します。動きは操作結果を伝える手段の一つであり、唯一の手段にしてはいけません。
CSSの動き軽減コード例
@media (prefers-reduced-motion: reduce) {
.swipe-row {
transition-duration: 1ms;
}
.removing {
animation: none;
}
}
13. 通信失敗と例外処理への備え
スワイプ削除の操作自体が正常でも、通信切断、権限変更、データ競合によって削除に失敗することがあります。失敗時に項目が消えたままになると、利用者は削除が完了したと誤解します。
13.1. 通信失敗時に項目を復元する
先行更新で項目を消した場合は、通信失敗時に元へ戻します。復元するときは、突然表示するのではなく、失敗通知と同時に戻すことで理由を理解しやすくします。
復元処理自体が失敗する可能性も考慮します。データを再取得する、一覧を更新する、詳細画面への移動を案内するなど、段階的な復旧手段を用意します。
13.2. 削除済みデータへの再操作を防ぐ
通信中の項目を再び操作できる状態にすると、同じ削除要求が複数回送信される可能性があります。削除処理を開始した項目では、スワイプや削除ボタンを一時的に無効にします。
ただし、画面を完全に操作不能にする必要はありません。処理中の項目だけを無効にし、ほかの項目は引き続き操作できるようにすると、利用者の作業を妨げにくくなります。
13.3. 権限不足を説明する
一覧を表示した後に権限が変更されると、利用者が削除操作を実行した時点で拒否される場合があります。このとき、単なる通信エラーとして表示すると原因が分かりません。
「削除権限がありません」「管理者により操作が制限されています」など、利用者が次に取るべき行動を判断できる文章を表示します。再試行しても成功しないエラーには、再試行ボタンを表示しないようにします。
13.4. 既に削除された項目を処理する
複数端末や複数利用者が同じデータを扱う場合、操作時点ですでに対象が削除されていることがあります。この場合は、画面上から項目を取り除けば状態が一致します。
ただし、別の処理によって非表示になっただけなのか、完全に削除されたのかを区別する必要があります。サーバーから返される状態を確認し、適切な通知を表示します。
13.5. エラー別に復旧方法を変える
すべての失敗へ「もう一度お試しください」と表示すると、権限不足や対象不存在のように再試行で解決しない問題にも同じ案内を出してしまいます。エラーの種類に応じて処理を変えます。
一時的な通信失敗では再試行、権限不足では問い合わせ先の案内、対象不存在では一覧更新というように、利用者が実行できる対応を提示します。
| エラー | 項目の扱い | 利用者への案内 |
|---|---|---|
| 一時的な通信失敗 | 復元する | 再試行を表示する |
| 権限不足 | 復元する | 権限がないことを説明する |
| 対象が存在しない | 一覧から除外する | 既に削除済みと伝える |
| 入力不正 | 復元する | 操作をやり直すよう案内する |
| サーバー障害 | 復元または保留 | 時間を置くよう案内する |
14. テストと効果測定の進め方
スワイプ削除は、コードが正しく動くだけでは品質を保証できません。端末サイズ、操作速度、入力方法、通信状態、利用者特性を変えて確認し、誤操作率や取り消し率も測定します。
14.1. 判定距離を実機で確認する
開発用画面上で適切に感じる判定距離でも、小型端末や大型端末では操作感が異なります。画面幅、項目高さ、指の届く範囲を変えて確認します。
素早い操作、ゆっくりした操作、短い移動、斜め移動を試し、意図しない削除が起こらないかを確認します。開発担当者だけでなく、機能を初めて使う人にも試してもらうことが重要です。
14.2. 縦スクロールとの競合を確認する
一覧を縦に動かす途中で、指がわずかに横へずれることは珍しくありません。その動きをスワイプ削除として認識すると、一覧操作中に削除領域が頻繁に表示されます。
横移動が縦移動より明確に大きい場合のみ、スワイプ処理へ切り替える設計を確認します。速い縦スクロール、ゆっくりした縦スクロール、斜め方向の操作をそれぞれ試します。
14.3. 連続操作を確認する
複数項目を続けて削除すると、動作、通信、通知が重なります。一件だけを操作したテストでは見つからない状態競合や表示崩れが発生する可能性があります。
削除中に別項目を削除する、取り消し通知が出ている間に次を削除する、通信失敗と成功が異なる順序で返るなど、実際に起こり得る組み合わせを確認します。
14.4. 取り消し率を測定する
削除直後の取り消し率が高い場合は、誤削除が多い可能性があります。ただし、利用者が試しに削除して戻している場合もあるため、数値だけで判断してはいけません。
削除方向、項目の種類、端末、操作距離などと組み合わせて分析します。特定の画面だけ取り消し率が高い場合は、判定距離、表示文、操作方向を見直します。
14.5. 操作完了時間を測定する
導入効果を確認するには、項目を削除しようとしてから処理完了を認識するまでの時間を測定します。単純な通信時間だけでなく、削除手段を探す時間や確認画面を操作する時間も含めます。
スワイプ削除によって操作時間が短くなっても、誤削除や問い合わせが増えれば改善とはいえません。速度、安全性、成功率を組み合わせて評価します。
| 測定項目 | 確認できる内容 | 注意点 |
|---|---|---|
| 削除成功率 | 操作が完了した割合 | 通信失敗を分けて確認する |
| 取り消し率 | 誤操作の可能性 | 意図的な取り消しも含まれる |
| 操作完了時間 | 整理速度 | 通信時間だけで判断しない |
| 削除エラー率 | 技術的な問題 | エラー種類を分類する |
| 代替操作利用率 | スワイプの発見性 | 利用者層別に確認する |
15. 実装品質を高める運用チェック
スワイプ削除は、公開後も利用状況や端末環境に合わせて改善する必要があります。設計時の想定と実際の使われ方が一致しているかを確認し、操作ルールを継続的に見直します。
15.1. 画面間で動作を統一する
同じアプリ内でスワイプ方向、削除色、確認方法が異なると、利用者は画面ごとに操作を覚えなければなりません。共通の操作規則を作り、新しい画面でも同じルールを使用します。
ただし、データの重要度が異なる場合は、安全対策まで完全に統一する必要はありません。方向や見た目は揃えつつ、重要データだけ確認画面を追加するなど、理由のある差に限定します。
15.2. 初回利用者へ操作を伝える
スワイプ操作は画面上に常時表示されないため、初めて利用する人が気付かないことがあります。初回だけ短い案内を表示する、項目をわずかに動かす表示を行うなど、存在を伝える方法を検討します。
案内を何度も表示すると作業の妨げになります。一度理解した利用者には繰り返し表示せず、ヘルプや設定画面から再確認できるようにします。
15.3. 利用者の問い合わせを分析する
「項目が消えた」「削除方法が分からない」「取り消せない」といった問い合わせは、画面設計の問題を示している可能性があります。個別対応だけで終わらせず、発生画面や操作手順を記録します。
問い合わせ件数が少なくても、削除対象が重要なデータであれば優先して改善します。発生頻度と影響度を分けて評価し、重大な誤削除を放置しないことが重要です。
15.4. 端末とOS更新後に再確認する
入力処理や画面部品の動作は、OSや開発環境の更新によって変化する場合があります。主要な更新後には、スワイプ判定、動作、読み上げ、取り消し通知を再確認します。
独自の座標処理を多く実装するほど、更新時の確認範囲が広がります。利用している環境に標準部品がある場合は、それを優先すると、操作慣習やアクセシビリティへの対応を取り込みやすくなります。Android公式資料でも、必要な機能を満たす範囲で、より上位の既存操作部品を優先する考え方が示されています。 . 削除方針を定期的に見直す
サービスの成長によって、以前は一時データだった情報が、共有や課金に関係する重要データへ変わることがあります。初期設計のまま即時削除を続けると、影響範囲に安全対策が追い付かなくなります。
データ分類、復元期間、権限、監査要件を定期的に確認します。画面上の操作だけでなく、保存先、履歴、利用規約、問い合わせ対応まで含めて削除方針を更新することが必要です。
| 確認対象 | 主な確認内容 | 見直す時期 |
|---|---|---|
| 操作方向 | 画面間で統一されているか | 新画面追加時 |
| 判定距離 | 誤操作が増えていないか | 利用分析時 |
| 取り消し | 正しく復元できるか | 更新ごと |
| 権限 | 削除可能者が適切か | 権限変更時 |
| 保存期間 | 法令や規約に合っているか | 定期監査時 |
| アクセシビリティ | 代替操作が使えるか | OS更新時 |
おわりに
Swipe to Deleteは、限られた一覧画面を有効活用しながら、項目整理に必要な操作回数を減らせる機能です。特に通知、メール、タスク、メモなど、日常的に不要項目を整理する画面では、高い効果を期待できます。
一方で、操作を速くするだけでは十分ではありません。削除方向、判定距離、完全スワイプ、確認画面、取り消し、通信失敗時の復元を一つの流れとして設計する必要があります。重要なデータほど、即時削除よりも削除ボタン表示、確認、論理削除を優先すべきです。
iOS、Android、Webのいずれでも、スワイプ以外の削除方法を残し、キーボードや読み上げ機能からも操作できる状態を整えることが重要です。利用状況を公開後も測定し、取り消し率やエラー率を確認しながら調整することで、速度と安全性を両立したスワイプ削除を実現できます。
