機会損失を減らすために抑えておきたい「決済処理まわりのキャパシティ」について。決済集中時のリスクと対策を解説。

私は金融機関にて営業を経験した後、GMO-PGへ転職しました 。入社以来、主にエンターテインメント領域（音楽、スポーツ、レジャー等）を担当し、近年では大規模リテールのお客様も担当しています 。ユーザーの熱量が高く、アクセスが集中しやすい領域をずっと見てきました。

そうですね。その他にも、人気アーティストのファンクラブ入会なども「少しでも若い会員番号（入会順）を取りたい」というファン心理が働くため、オープン直後の負荷は凄まじいです 。推し活の熱量からくる特有の挙動ですね。

直接的な実害としては高負荷による決済機能の停止、売上の棄損が考えられます。決済が滞ることでフロントサイト全体が落ちてしまうこともあります 。また、 今の時代に怖いのはSNSでの拡散ですね。「買えない」、「サイトが落ちた」という不満が瞬時に広がり、ブランドイメージの毀損や炎上に繋がります 。

また、申込・購入完了画面が出たのに裏側では決済が失敗している、といった「決済の不整合」が起きるとエンドユーザーからの問い合わせに対応するコストも膨らみがちですね 。

「カートに入れてカード情報を入力しようとした瞬間にエラーで最初に戻される」といったパターンですね 。「あと一歩で買えたのに」という心理的なショックが大きいのかと思われます 。

また、「クレジットカード決済手段が使用不可になり、コンビニ決済や〇〇Pay系の決済手段などでしか決済できない」といった事象による不公平感も火種になりやすいです。

エンタメ領域で言うと、コンサートやライブのチケットの「先行受付開始」や「抽選申し込み開始」のタイミングが一番殺到します。先着順の場合は開始直後がピークで、そこから山が下がっていくような動きです。ファンクラブも新規オープンのタイミングですね。

EC等の物販系だと、セールや新商品、数量限定商品の発売開始タイミングです。ただ最近は、SNSでのバズ（インフルエンサーの紹介など）で予期せぬタイミングで急にピークが来ることもあります。

そうですね。ふるさと納税や公共料金の支払いなど「締め切り」があるものでも負荷がかかりがちです。ふるさと納税はポイント付与などの条件が変わるタイミングや、年末の駆け込み時に発生します。

他に、意外なところだと、「サブスク」でしょうか。月額課金をバッチ処理で夜間に走らせるとして、何万件、何十万件を一気に処理しようとすると決済キャパシティの考慮が必要になるというケースがあります。必ずしも、エンドユーザーの急増だけが負荷の原因とは限らないのです。

EC事業者様側での事前の対策としては、まず決済代行会社との連携が挙げられます。負荷が走るタイミングを予期できた際、あらかじめ決済のボリュームを予測し、決済代行会社に伝えたうえで協議することが非常に重要です。

予想される決済の量に対して現状のキャパシティ設定が問題ないかを、予想の確からしさも含めて協議します。そのうえで、問題がある場合は決済代行会社側での追加設定や仮想待合室（オンライン上の待合室にユーザーを誘導、順次サイトへ案内するシステム）等のツール導入で手当をするような進め方になります。

GMO-PGでよく行う追加設定としては、事前に定められた「決済処理における同時接続数（セッション数）」の上限を引き上げる対応があります。

それでもキャパシティ不足のリスクが拭えきれないときは、キャンペーンの時期を分散させたり、サービス設計自体を見直したりすることを決断される事業者様もおられますね。中には時間の都合で特に対策せずぶっつけ本番で乗り切ろうとされるケースもあり、決済代行会社側からも事前に繁閑を把握したうえで支援できるような関係づくりが重要だなと感じます。

いえ、そうとも限りません。そもそも決済におけるキャパシティの概念自体が希薄な会社もあると聞きます。トラブルが起きてから「仕様なので仕方ない」で済まされたり、「自分たちの決済システムは万全だ」というスタンスで、加盟店ごとの個別調整に応じなかったりすることがあるようです。

一時的にサイトを停止し日を改めて再開されるケースや、フロント起因の場合はサーバー増強の反映を待って再開されるケースがあります。ただ残念ながらキャパシティ不足に直面してしまうと、すぐに解消するための打ち手はなかなか無いのが実情だと思います。そういった際にはどうしても機会損失が生まれてしまうので、やはり事前準備が非常に重要ですね。

①事前ヒアリングの徹底、②決済処理量の予測と振り返り、③社内体制づくりの3つです。

①事前ヒアリングについて、弊社の場合は契約前から想定される決済処理量を細かく伺いますし、既存の加盟店様であれば日々ミーティングで会話する中で、イベント情報を収集しています。

処理量の見立ての際、見落としがちなポイントとして、決済手段ごとに1件あたりの処理時間（負荷）が違う、という点があります。例えばクレジットカードは通信ステップが多いため、処理時間が他の手段より長くかかります。したがって、エンドユーザーの属性を踏まえ、どの決済手段がどれくらい利用されるかを予測し、必要なキャパシティを試算する必要があります。

②決済処理量の予測と振り返りについては、弊社が保有する膨大な過去実績のなかから類似のイベントや他社実績データと照らし合わせて予測値を算出しています。イベントが終了した後は秒単位の決済処理データを分析し、次回以降の予測精度向上に活かす目的で加盟店様にフィードバックをしています。

そうですね、なので③社内体制づくりがとても重要で。弊社では営業とシステム担当が二人三脚で動いていて、大規模ECの重要イベントでは数ヶ月前から社内でスケジュールを共有し、当日はシステム担当者とピーク時に備えた監視体制を敷き、リアルタイムでモニタリングします。
私も当日は自分のスマホでお客さんのサイトに入れるか確認したり、SNSを常にチェックし「買えない」という声があれば即座に社内共有したりして、緊急対応（同時接続数の増強など）をスピーディに反映できるよう体制を整えています 。プライベートは浸食されますが、トランザクションが無事に流れればうれしい瞬間でもありますね。

加盟店様が売上を棄損してしまうと、決済代行会社である我々の売上にもダイレクトに響きます。そのため、弊社のメンバーは皆、決済の安定稼動を「自分事」として捉えていることが一番の理由です。 あとは、業種・業態ごとに営業部隊を組成しているので、同業他社の事例を見ながらプランニングできるノウハウが既に蓄積されていることも大きな要因です。

あります。大きなトランザクションが見込まれる案件で、加盟店様と協議のうえキャパシティを最大限に増強して臨みました。決済処理自体は問題なかったのですが、その処理結果を加盟店様のシステムへ通知し応答を返していただく部分がボトルネックになり、結果として決済処理全体が滞ってしまったことがありました。
この経験から得た教訓は、決済処理の入口だけでなく出口、つまり結果通知や応答処理のキャパシティまで含めた設計が不可欠だということです。どれだけ弊社の決済システム側を増強しても、その先の運用まで見通せていなければ、思わぬところで詰まってしまうのだと痛感しました。

世間的にも大きな注目を集め、過去に例のない規模のトランザクションが見込まれた案件がありました。決済手段ごとの利用割合を細かく予測したうえで、社内のシステム部門に無理を言ってキャパシティを大幅に引き上げ、さらにクレジットカード会社などの決済サービス提供会社とも事前にすり合わせを行い、万全の体制で当日を迎えました。
結果として、決済処理におけるキャパシティ上の問題は一切起きず、無事にサービスをリリースいただくことができました。