【ITニュース解説】現地速報！ Kaigi on Rails 2025 Day2

Kaigi on Rails 2025 Day2 の速報記事では、Ruby on RailsというWebアプリケーションフレームワークの技術カンファレンスで注目されたセッションの一つ、「2重リクエスト完全攻略HANDBOOK」について紹介されている。システムエンジニアを目指す皆さんにとって、この「2重リクエスト」という概念と、それへの対策は、Webアプリケーション開発において非常に重要なので、詳しく解説する。

まず、Kaigi on Railsとは何か。これは、多くのWebサービスで利用されている「Ruby on Rails」という人気のフレームワークに関する技術イベントである。Ruby on Railsは、Webアプリケーションを効率的に開発するための強力なツールで、データベースとの連携、Webページの表示、ユーザーからの入力処理など、Webサービスに必要な多くの機能を備えている。このようなイベントでは、開発者が日々の開発で直面する課題や、それを解決するための最新技術、ベストプラクティスなどが共有される。今回の速報記事で取り上げられている「2重リクエスト」も、そうした開発現場で頻繁に遭遇する、かつ非常に重要な課題の一つだ。

「2重リクエスト」とは、一言で言えば、Webアプリケーションに対して、同じ内容のリクエスト（要求）が短時間のうちに複数回送信されてしまう現象のことである。例えば、ユーザーがWebサイト上で「購入ボタン」や「送信ボタン」をクリックしたとする。通常、このクリックによって一度だけサーバーにリクエストが送られ、処理が実行される。しかし、何らかの原因で、ユーザーが意図せず同じボタンを連続してクリックしてしまったり、通信環境が悪くてブラウザがタイムアウトと判断し、再度リクエストを自動的に送ってしまったり、あるいはページの読み込み中に誤って更新ボタンを押してしまったりするなど、さまざまな状況で同じリクエストが複数回送られてしまうことがある。これが2重リクエストである。

この2重リクエストは、一見すると些細な問題のように思えるかもしれないが、実はWebアプリケーション、特に金銭取引や重要な情報処理を伴うサービスにおいては、致命的な問題を引き起こす可能性がある。記事でも指摘されているように、「特にお金が関わるようなサービスは二重に同じ処理を行ってしまうと致命的なことになりかねない」のである。具体的に考えてみよう。

例えば、オンラインストアで商品を一つ購入する際、ユーザーが誤って購入ボタンを二度クリックしてしまい、それが2重リクエストとしてサーバーに届いたとする。もしサーバー側で適切な2重リクエスト対策が講じられていなければ、システムは同じ商品を二つ購入しようとする処理を二度実行してしまう可能性がある。結果として、ユーザーは意図せず同じ商品を二つ購入し、代金も二重に請求されてしまうかもしれない。また、銀行のオンライン送金サービスで、送金ボタンが二重に押されてしまった場合を想像してみてほしい。もし対策がなければ、本来一度しか送金されるべきではない金額が、二重に送金されてしまう、といった深刻な事態に発展する恐れがある。これはユーザーにとって金銭的な損害となるだけでなく、サービス提供者にとっても信用を失う大きな問題となる。

システムエンジニアは、このような事態を防ぎ、ユーザーに安全で信頼性の高いサービスを提供するために、2重リクエスト対策を徹底する必要がある。このセッションでは、具体的な対策方法が「クライアント側」と「バックエンド側」に分けて9つ紹介されたとのことだ。

「クライアント側」とは、ユーザーが直接操作するWebブラウザやスマートフォンのアプリケーション画面を指す。ここでの対策は、ユーザーが意図せず2重リクエストを発生させてしまうのを未然に防ぐことが主な目的となる。例えば、ボタンをクリックしたら即座にそのボタンを無効化したり、クリック後にはローディング表示を出して、ユーザーが再度操作できないようにしたりする方法が考えられる。これにより、ユーザーの連続クリックや焦りによる重複操作を防ぐことができる。また、送信フォームの二重送信を防ぐために、一度送信したらページを遷移させるなどの工夫もクライアント側の対策の一つである。

一方、「バックエンド側」とは、Webサーバーやアプリケーションサーバー、データベースなど、ユーザーからは直接見えない部分、つまりシステムの裏側で動いている部分を指す。クライアント側で対策を講じても、悪意のあるユーザーが意図的に2重リクエストを送ったり、ネットワークの不具合などでどうしても重複したリクエストがサーバーに到達したりする可能性はゼロではない。そのため、バックエンド側での強固な対策が不可欠となる。

バックエンド側での対策の例としては、以下のようなものが考えられる。一つは、リクエストごとにユニークな識別子（トークンなど）を付与し、サーバー側でこの識別子を記録・管理する方法だ。同じ識別子を持つリクエストが短時間のうちに複数回届いた場合、二度目以降のリクエストは「すでに処理済みである」と判断して拒否する、という仕組みである。もう一つは、データベースの特性を利用した対策だ。例えば、重要な取引を記録するテーブルに「トランザクションID」のようなユニークな制約を持つカラムを追加し、同じトランザクションIDが既に存在する場合は、データベースが自動的に重複処理を拒否するように設定する方法がある。これにより、アプリケーション層でのミスや漏れがあっても、データベースレベルでデータの整合性を保つことができる。また、処理のロック機構を導入することも有効である。あるリクエストが特定の処理を開始したら、その処理が完了するまで他の同じ処理を待機させる、あるいは拒否するという仕組みだ。

記事では9つの対策が紹介されたとのことなので、これら以外にも多様なアプローチがあると考えられる。重要なのは、システムエンジニアとして、クライアント側とバックエンド側の両面から多層的に対策を講じ、あらゆる可能性を考慮してシステムを設計・実装することである。特に金融システムなど、金銭や重要な情報が関わるサービスでは、たった一度の2重リクエストが取り返しのつかない事態を引き起こしかねないため、設計段階からこの問題に対する意識を高く持ち、堅牢なシステムを構築する責任がある。

今回のKaigi on Railsでの発表は、Ruby on Railsを用いた開発現場で実際に役立つ知見が共有された良い機会であっただろう。システムエンジニアを目指す皆さんにとって、このような具体的な課題とその解決策を知ることは、将来のキャリアにおいて非常に役立つはずだ。2重リクエスト対策は、Webアプリケーションの安定性、信頼性、そしてユーザーからの信用を確保するための基礎となる重要な知識である。この機会に、ぜひその重要性を理解し、さらに深く学ぶきっかけとしてほしい。