Undo Redo（Undo/Redo）とは、操作を「元に戻す」Undoと、取り消した操作を「やり直す」Redoを組み合わせたUIの回復機能です。日本語ではアンドゥ / リドゥとも呼ばれ、Undoの逆はRedoです。
「あ、間違えた。Ctrl+Zで戻ろう……あれ、効かない？」——テキストエディタやデザインツールでは当たり前のUndoが、Webアプリやモバイルアプリでは機能しないことがよくあります。その瞬間、ユーザーは「慎重に操作しなければ」という緊張状態に入ります。
よくある失敗は「削除は確認ダイアログで防ぐ」という設計です。確認ダイアログは操作のたびにフローを中断させます。一方、Undoがあれば「削除してしまっても戻せる」という安心感があるため、確認ダイアログなしでも快適に操作できます。GmailやFigmaが確認なしで削除できるのは、強力なUndoがあるからです。
Undoがないシステムでは、ユーザーは「試してみる」ことを恐れます。新機能を試さない、設定を変えない、思い切った編集をしない——それはサービスの活用度の低下に直結します。
Undo/Redoの意味
Undo/Redoとは、ユーザーが行った操作を取り消して元の状態に戻す（Undo）ことと、取り消した操作をもう一度実行する（Redo）ことです。 日本語では、Undoは「元に戻す」「取り消す」、Redoは「やり直す」「再実行する」と表現されます。
検索で「undo redo」「undo/redo」「undo redo 意味」「アンドゥ リドゥ」と調べている場合、まず押さえるべき違いは向きです。Undoは履歴を1つ前へ戻し、RedoはUndoで戻した履歴をもう一度前へ進めます。つまり、Undoの逆がRedoです。
| 用語 | 日本語での意味 | 例 | よく使うショートカット |
|---|---|---|---|
| Undo | 元に戻す / 取り消す | 削除した項目を復元する、入力前の状態に戻す | Cmd+Z / Ctrl+Z |
| Redo | やり直す / 再実行する | Undoで戻した操作をもう一度適用する | Cmd+Shift+Z / Ctrl+Y |
| Undo stack | 操作履歴 | 複数回前の編集まで戻れる履歴 | アプリごとに異なる |
UI設計では、Undo/Redoを単なる便利機能ではなく「操作の心理的安全性」を作る仕組みとして扱います。戻せることが分かっていると、ユーザーは編集、削除、並び替え、設定変更を試しやすくなります。
1. 原則の定義
やり直し可能性（Undo/Redo）とは、ユーザーが行った操作を取り消して元の状態に戻す（Undo）機能と、取り消した操作をやり直す（Redo）機能を設計する原則。「間違えても戻せる」という保証がユーザーの心理的安全性を高め、探索的な学習を促進する。
本質は「操作の可逆性を保証すること」です。Undoは単なる「元に戻す」機能ではなく、ユーザーが安心してシステムを探索できる環境を作るための設計思想です。ドナルド・ノーマンの「許容力のあるデザイン（Forgiving Design）」の中核をなします。
2. いつ使うか（適用場面）
特に重要になるケース
- コンテンツ編集ツール: テキスト編集・画像編集・ドラッグ&ドロップなど、ユーザーが試行錯誤しながら作業するツールでは必須。
- 設定・カスタマイズ画面: 設定を変更した後「元に戻したい」と思うことは多い。「デフォルトに戻す」ボタンもUndoの一形態。
- データ削除操作: 削除後に「やっぱり戻したい」というケースは頻繁に起きる。トースト通知＋Undoが確認ダイアログより優れたUX。
- 複数ステップのフォーム: 前のステップに戻れる設計はUndoの概念の応用。
トレードオフが起きる場面
- 不可逆な操作: メール送信・決済確定・外部APIへの書き込みなど、システム的に取り消せない操作にはUndoを提供できない。この場合は確認ダイアログまたは「送信取り消し（遅延送信）」で対応する。
- 実装コスト: Undoスタックの管理は実装が複雑になる場合がある。特に複数ユーザーが同時編集するシステムでは設計が難しい。
3. なぜ重要か（設計判断の核）
Undoは「元に戻す機能」ではなく、「ユーザーが大胆になれる環境」を作る設計である。
設計判断の基準
- 「この操作を間違えたとき、ユーザーは自力で元に戻せるか？」→ 戻せなければUndoまたは確認ダイアログを実装する。
- 「確認ダイアログを追加しようとしているなら、代わりにUndoを実装できないか？」→ Undoの方がフローを妨げない。
優先順位の考え方
- 1. 主要な破壊的操作のUndo（最優先）: 削除・アーカイブ・大量変更など、影響が大きい操作から優先的にUndoを実装する。
- 2. Undoの発見可能性: Undoが存在することをユーザーが知らなければ意味がない。トースト通知・ツールバーボタン・ショートカットキーで発見可能にする。
- 3. Redoの提供: Undoしすぎた場合に戻れるRedoも合わせて提供する。
例外条件
- メール送信・決済など不可逆な操作は、Undoの代わりに「送信取り消し（数秒間のキャンセル猶予）」で対応する。
4. 具体の設計ルール（チェックリスト）
最低ライン（Must - これ守らないと危険）
これがないと、ユーザーは操作を恐れるようになります。
理想ライン（Better - できると強い/プロの品質）
「安心して試せる」「何度でもやり直せる」状態です。
5. UI例
削除操作のUndo設計で、ユーザーの安心感と操作の快適さが大きく変わります。
改善プロセス
- 確認ダイアログをUndoに置き換える: 「本当に削除しますか？」ダイアログを削除し、代わりに削除後のトースト通知＋「元に戻す」ボタンを実装する。操作フローがスムーズになる。
- Undoの発見可能性を高める: 削除後に必ずトースト通知を表示し、「元に戻す」の存在をユーザーに知らせる。知られていないUndoは存在しないのと同じ。
- 不可逆操作の特定: システム内の全操作を「可逆」「不可逆」に分類し、不可逆操作には確認ダイアログまたは遅延実行を設計する。
6. 関連リンク
- 関連リファレンス（理論）: 防衛的デザイン
- 用語集（定義）: アンドゥ・リドゥ, フェイルセーフ, 確認ダイアログ
- 関連するUI原則（横）: ユーザーコントロール (User Control), 誤操作を防ぐ (Error Prevention), エラーから回復できる (Error Recovery), フィードバック (Feedback)
- 関連するUIコンポーネント: Toast, Alert Dialog
7. まとめ
今日から直せる一手 担当しているサービスの「削除」操作を確認してください。「本当に削除しますか？」ダイアログがあるなら、それをトースト通知＋「元に戻す」ボタンに置き換えてみてください。ユーザーの操作がスムーズになり、誤削除の不安も解消されます。
チームに共有するなら一言 「確認ダイアログはUndoの代わりにならない。Undoこそが、ユーザーを大胆にする。」
