ある日ご機嫌にバイブコーディングをしていると、ClaudeCode君がこんな一言。
「ここは楽観的更新にすると良いかもしれませんね！」
言葉の意味が分からず、（そんなにネガティブなこと言ったかなぁ）とか思ってましたがどうやら「楽観的更新」という用語がちゃんと存在するようです。
楽観的更新とは
楽観的更新とは、サーバーへのリクエスト結果を待たずに、成功すると仮定してUIを先に更新する手法 です。
- 通常の更新フローはこんな感じです ↓
ユーザー操作 → APIリクエスト送信 → レスポンス受信 → UIを更新
ユーザーはレスポンスが返るまで待たされるため、ネットワーク遅延がそのまま体感速度に影響します。
- 一方で、楽観的更新のフローはこちら ↓
ユーザー操作 → UIを即座に更新 → APIリクエスト送信
├─ 成功 → そのまま
└─ 失敗 → UIをロールバック
サーバーの応答を"楽観的に"成功と見なして先にUIを反映し、万が一失敗した場合だけ元の状態に戻します。
メリット
体感速度の向上
なんと言ってもこれですね。
ボタンを押した瞬間に結果が反映されるため、まるでローカルアプリのような操作感を実現できます。
レスポンスが長いとそれだけでユーザーの満足度は下がり、離脱率の増加等に繋がりますので重要なポイントです。
操作の連続性を保てる
ユーザーはレスポンスの到着を待つ必要がないため、次のアクションにすぐ移れます。
例えば、チャットアプリでメッセージを連続送信するとき、1通ごとにスピナーが出ていたら会話のテンポが崩れてしまいます。楽観的更新なら送信ボタンを押した瞬間にメッセージが表示され、自然な対話の流れを維持できます。
使用例
SNSのいいねボタン
これが一番イメージしやすいと思います。
「押した瞬間に」ハートマーク等が点灯し、付随してバイブレーション機能などが反応したりしますね。
これが通常のフローだと、押してからUIに何らかの反応があるまで数秒程度ラグが発生するのでユーザー体験を大きく損ねることは間違いないでしょう。
トグルボタン
ON/OFFを切り替えるスイッチです。
これも押した瞬間に切り替わらないと違和感がありますね。
カートへの商品追加
ショッピングサイトで「カートに追加」ボタンを押した際、即カートに追加される（ように見える）と気持ちがいいです。
楽観的更新が向かないケース
速いほうがいいから全部楽観的更新でやる！！というのは問題です。
以下のようなケースでは、従来どおりサーバーのレスポンスを待ってから UI を更新する方が安全です。
決済・送金などの金銭が絡む処理
「購入完了」と表示した直後にロールバックが起きると、ユーザーに大きな混乱や不信感を与えます。お金が動く操作は、サーバーの確定応答を得てから結果を表示すべきです。
サーバー側のバリデーションに依存する操作
ユーザー名の重複チェック、在庫の確認、権限の検証など、クライアント側では成否を判断できない操作は楽観的に更新できません。「成功するだろう」という仮定が成り立たないためです。
取り消しが困難な操作
メールの送信、外部 API への通知、データの物理削除など、一度実行すると元に戻せない操作は、ロールバックという前提自体が成立しません。
失敗率が無視できない操作
ネットワークが不安定な環境での大きなファイルアップロードや、レート制限に引っかかりやすい API 呼び出しなど、失敗が頻繁に起こりうる操作では、ロールバックが連発してかえって UX を損ないます。
判断基準
迷ったときは、次の 2 つの問いで判断できます。
① この操作は高い確率で成功するか？
② 失敗してロールバックしても、ユーザーが混乱しないか？
両方「はい」なら楽観的更新の適用候補、どちらかが「いいえ」なら従来の更新フローを選ぶと良いでしょう。
おわりに
ちなみに楽観的更新に対して、従来のフローは「悲観的更新」と呼ばれるそうです。
確かに言葉の意味としては間違いないのですが、何となく後ろ向きな印象を受けます