【ITニュース解説】Server-Authoritative Pricing: The Browser Can Preview a Bill, Not Decide It

システムエンジニアを目指す皆さんがウェブサービスやアプリケーションを開発する上で、お金や重要な情報を取り扱う際には、特に注意すべき設計原則がある。それが「Server-Authoritative Pricing」（サーバーが最終決定権を持つ価格決定）という考え方だ。これは、ユーザーが画面上で見る情報と、実際にシステムが処理する情報の間には明確な役割分担が必要である、ということを意味している。

具体的に、皆さんが普段利用するオンラインショッピングサイトや、お店のレジで使われるPOS（販売時点情報管理）システムを想像してみてほしい。レジ担当者が商品をスキャンすると、すぐに画面に合計金額が表示される。この「すぐに表示される」という即時性は、システムの使いやすさにとって非常に重要だ。だからこそ、ブラウザ（ウェブページを表示しているソフトウェア）などのクライアント側で、あらかじめ価格の計算を行い、合計金額をプレビュー（仮表示）する仕組みが一般的に採用されている。これは、レジ担当者の作業をスムーズにし、顧客を待たせることなく会計を進めるために役立つ。

しかし、このブラウザがプレビューする合計金額が、最終的に顧客が支払うべき金額として「決定」されてしまうのは非常に危険である。なぜなら、ブラウザで表示される情報は、ユーザー側で簡単に改ざんできてしまう可能性があるからだ。例えば、悪意のあるユーザーがブラウザのデベロッパーツールなどを使って、表示されている合計金額を意図的に低い金額に変更し、その改ざんされた金額で注文を確定しようと試みることができてしまう。もしサーバー側が、ブラウザから送られてきた合計金額をそのまま信用してしまえば、システムは不正な金額で取引を成立させてしまい、会社に損害を与えたり、深刻なセキュリティ問題を引き起こしたりする可能性がある。

このような問題を防ぐために、この原則では「ブラウザは価格のプレビューはできるが、最終的な決定権は持たない」という明確な境界線を設ける。具体的な例として、「OrderRestro」というシステムが挙げられている。このシステムでは、クライアント（ブラウザ）側で価格計算のロジックをミラーリングしている。つまり、サーバー側で行われる計算と全く同じ計算をクライアント側でも行い、レジ担当者がリアルタイムで商品の合計金額を確認できるようにしているのだ。これにより、即時性を確保しつつ、ユーザー体験を損なわないように工夫されている。

しかし、ここで肝心なのは、注文が最終的にサーバーに送信されるタイミングだ。注文が送信されると、サーバーはクライアントから送られてきた注文データを受け取るが、クライアントが計算した合計金額をそのまま信用することはない。代わりに、サーバー自身が持つ、完全に信頼できるメニューデータや、現在の割引情報などを使って、独自の計算を再度行うのだ。この再計算のプロセスの中で、税金の計算、割引の適用、そして通貨の端数処理といった、お金に関わる重要な処理がすべてサーバー側で厳密に実行される。この「サーバーが最終決定するパス（処理経路）」こそが、最も信頼できる情報源となる。

この「クライアントでのプレビュー」と「サーバーでの最終決定」という設計思想は、POSシステムだけに限定されるものではない。お金の取引だけでなく、ユーザーの権限管理など、セキュリティや信頼性が求められるあらゆる場面で非常に有効なアプローチだ。インターフェース、つまりユーザーが直接操作する画面は、ユーザーが何をするのか、その結果どうなるのかを理解させるための「案内役」としての役割を担う。しかし、最終的にシステムのデータが変更されたり、お金が動いたりするような「境界（システム間の重要な接点）」においては、必ずサーバー側で再度検証を行い、不正な操作や誤った情報がシステムに永続化されるのを防ぐ必要がある。

システム開発においては、このような設計がきちんと機能しているかを確認するためのテストが欠かせない。例えば、テスト用のリクエストで、意図的に合計金額のデータを改ざんしてサーバーに送信してみるという簡単な検証を行うことができる。このとき、サーバーはクライアントから送られてきた改ざんされた合計金額を無視して、自らが計算した正しい金額を適用するか、あるいは、クライアントから送られてきた金額と自らが計算した金額が一致しないことを検知して、そのリクエストを拒否するべきだ。これにより、不正なリクエストを未然に防ぐことができる。

さらに、システムは現実世界で発生する様々な複雑なケースにも対応できる必要がある。例えば、税金が商品価格に含まれる「内税」の計算、定額割引と割合割引の異なる適用方法、商品の返品時の返金処理、そして異なる通貨間での端数処理など、これらすべての場合において、システム内のすべての処理経路が最終的に「同じ金額」で一致することを確認しなければならない。一つでも計算がずれてしまうと、顧客との信頼関係を損ねたり、会計上の問題を引き起こしたりする可能性があるからだ。

最終的に、クライアント側のプレビュー機能は、その即時性によってスタッフの負担を軽減し、ユーザーインターフェースを高速でスムーズに感じさせるという点で、非常に価値があることは変わらない。ショッピングカートに商品を追加した際に、瞬時に合計金額が更新されるのは、利用者にとって快適な体験だ。しかし、この便利なプレビュー機能はあくまで「見込み」であり、最終的な「決定権」は常に、改ざんが困難で信頼性の高いサーバー側にあるべきだ。この原則を理解し、システム設計に反映させることは、システムエンジニアを目指す皆さんにとって、安全で信頼性の高いシステムを構築するための重要な第一歩となる。