注文フォームで登録してもメール返信が無い時、何が起こっているのか

いきなりピンポイントな話でアレなんですが、『**「蒼穹のファフナーEXODUS」 2017年オリジナルカレンダー**』の予約が先日始まったらしいんですけど、超限定生産らしくて注文が殺到しているようですね。

ファフナー カレンダー - Twitter検索
https://twitter.com/search?vertical=default&q=%E3%83%95%E3%82%A1%E3%83%95%E3%83%8A%E3%83%BC%20%E3%82%AB%E3%83%AC%E3%83%B3%E3%83%80%E3%83%BC

しかも**ちゃんと入力して登録したつもりが、メール返信が無い**らしいんですよ。

* 👩 「ファフナーカレンダーの予約確認メールが来ない」
* 👩 「ファフナーのカレンダー、昨日予約したはずなんだけど自動送信メールが届いていない。メルアド間違えた？」
* 👩 「ファフナーカレンダーの予約確認メールがまだ届かない件、『10日経っても確認メールが届かない場合』という文言があった。10日って昨夜あった？ とりあえず様子を見ます」

この件に関して「**何が起こっていると考えられるのか**」聞かれたので、一般的な『注文フォーム』の話から、実際にXEBECzweiのサイトを確認した上で推測できることをまとめました。

# いわゆる『注文フォーム』ってなんだっけ

Amazon・楽天のような今や当たり前にある、ショッピングカートやお気に入りなどの概念が入った『一般的なECサイト』よりも前に普及していた注文方法です。
『**メールフォーム**』あるいは『**注文（用）メールフォーム**』とも言われています。

サンプル）
<img width="655" alt="スクリーンショット 2016-07-10 0.26.29.png" src="https://qiita-image-store.s3.amazonaws.com/0/7574/eb5239b4-2ff6-4249-8618-bcb6f7758342.png">

ご注文フォーム
http://www.kent-web.com/cart/cartform/cartform.html

👆ある世代のWebプログラマーはみんなお世話になった KENT WEB さんにもありました。
「懐かしい！」と思う人もいるかと思います。『**お問い合わせフォーム**』もこの形式ですね。

それまでは「**メール（E-メール）に注文内容を注文者自身が打ち込んで送信していた（！）**」ものが、「**商品の選択や連絡先などをWebフォームで制限する**」ことで入力しやすくなり、ショップ側も注文内容の確認が圧倒的に楽になりました。

『メールフォーム』と言われるゆえんは、**送信した際に注文内容を受け付けた確認・証拠としてメールが送信される**ところにあります。メールの送信先は注文者だけではなく、注文を受け付けたり商品を発送するショップ側を含むこともあります。

『「懐かしい！」と思う人もいるかと思います』と書きましたが、今でもこういったシステムは色々なサイトで利用されています。
食事処の通信販売とか、旅館の宿泊とか、同人誌の自家通販とか…。

# 注文フォームは「重い」（ことがある）

注文フォーム自体懐かしい仕組みであることもさることながら、そもそもシステムの作成時期が古かったりすることもあり、**現代のアクセス状況に耐えられない**ケースが殆どです。

## 理由：CGIでできている

<img width="337" alt="スクリーンショット 2016-07-10 0.47.09.png" src="https://qiita-image-store.s3.amazonaws.com/0/7574/3d8f4c9d-1f5f-ccd6-90dd-4cb3bf2eb440.png">

HTMLソースを確認してみると、
＼ああああ！！！ postmail.cgi にsubmitしてるぞ！！！！／

そうです。CGI（Common Gateway Interface）で動作していることがままあります。
CGIはWebサーバがリクエストの度に外部のプログラム（プロセス）を起動するので、**負荷が物凄く高い**です。サーバ構築時期が古い場合はスペックも期待できないため、秒間2桁回も処理出来ないケースもあると思います。

※ 秒間1回程度のアクセスでシステムに問題が起き、**偽計業務妨害容疑で逮捕される事態にまで至るような図書館の蔵書検索システム**も2010年に存在していたくらいなので何があっても不思議ではないです。（[岡崎市立中央図書館事件 - Wikipedia](https://ja.wikipedia.org/wiki/%E5%B2%A1%E5%B4%8E%E5%B8%82%E7%AB%8B%E4%B8%AD%E5%A4%AE%E5%9B%B3%E6%9B%B8%E9%A4%A8%E4%BA%8B%E4%BB%B6)）

## 理由：メール送信処理を同期的に行っている

注文したことにより発生する**『メールを送信する処理』は意外に重い**ものです。
これを注文したタイミングと同じタイミングで行うと、メールの送信が完了するまで次の注文を受け付けられない状態になります。

これらの要素が重なると、多くの注文が同じ時間に発生した際に**予約待ちの行列のような状態**になり、最悪の場合すべての注文を受け付ける前にシステムがストップしてしまうことがあります。

<img width="300" alt="スクリーンショット 2016-07-10 0.26.29.png" src="https://qiita-image-store.s3.amazonaws.com/0/7574/c50c29c5-f9ff-2c6a-1d6e-15f8ef5f4feb.png">

# システム運用者側は大量の注文に対してどう対策すればいいの？

注文者にとってはどうすることもできませんが、システムを運用している側にとってできることを挙げてみます。

## 【システムをある程度触れる人向け】 CGIをやめよう & 同期的処理をやめよう

👆で指摘した内容を踏まえるなら、**そもそもCGIをやめるべき**だという結論にもなります。これからも一定の注文が見込めるのであればやめましょう。

仮に使用しているスクリプトが```Perl/CGI```なのであれば、Perlのコードを流用したままCGIをやめることもできるかもしれません。
ApacheでPerlを動作させるときによく使われるモジュール```mod_perl```に乗り換えるだけでも数百倍速くなるケースもあります。最近であれば、更に```Plack```で動かすという方法もあるにはありますが、そこまで行くと余程元のスクリプトが難解でなければ新規で作りなおしたほうが良さそうです。

また、**メール送信に限らず、同期的処理をやめたほうが高負荷を避けられる**ということ。例えば、「『注文を受け付けたこと』と『メールを送信する』ことは同時に行わなくても構わない」ということを理解する必要があります。
注文内容がデータベースあるいはログファイルに記録されていればメールを送信するチャンスはいつでもありますし、順番に送信する処理を注文を受け付ける処理とは別に実行すれば、注文受付が混雑しにくくなります。

## 【システムを少し触れる人向け】 注文フォームを出さない（！）

たまたま注文が殺到している。すぐにシステムを改修できる見込みが無い！ という場合には、そもそも**「注文フォームを出さない」**のが賢明です。

バカバカしいと思うかもしれませんが、**受け付けられない状況にあるシステムを稼働する方が注文者に対して不誠実**です。注文者がわざわざ時間を掛けて入力した内容が受け付けられないという状況は絶対に避けるためにも、まず出さないことです。**代わりに旧来のメール注文の案内を行いましょう**。

また、どうしても注文フォームで受け付けたい、他に手段が用意できないということであれば、奥の手ですが**「一定の確立で注文フォームを出す」**という手段も考えられます。ある種の抽選方式です。

例えば10分の1の確立で注文フォームを表示する処理を入れる。注文しようと思ってページを訪れた10人の内9人には「ただいま大変混雑しております。時間を置いてもう一度お試しください。」などといったメッセージが表示される。
これによって注文の集中を抑えられる可能性があります。注文したいユーザは当然ページをリロードしまくると思いますが、それでもある程度の抑止にはなります。注文を諦めてしまう可能性もありますけどね…。

## 【仕組みをよく知らない人向け】 自前でシステムを持つのをやめよう

売上が見込めるのであれば、負荷に弱いシステムを自前で持ち続けるのも良くありませんので、システムを借りてしまいましょう。

よくある注文フォームのフォーマットをそのまま借りることができるサービスも色々あるようです。ただし、どの程度までの負荷に耐えられるのかはそれぞれのサービスの仕組みによりますので、実際に使ってみるか確認する必要があります。

SSL・スマートフォン対応のメールフォームを簡単に作れる「フォームメーラー」
http://www.form-mailer.jp/

お問い合わせフォーム・アンケートフォームが無料で作れる ｢セキュアフォーム｣
https://www.secure-cloud.jp/sf/

また、この手のWebフォームで最近王道なのが Googleフォーム です。

Google フォーム - アンケートを作成、分析できる無料サービス
https://www.google.com/intl/ja_jp/forms/about/

モダンなデザインのフォーマットをかなり柔軟に作成できるほか、注文・回答結果がスプレッドシートに記録されることでデータの確認・分析が非常に容易になっています。しかも完全に無料です。Googleアカウントを持っているのであれば使わない手はありません。

# XEBECzweiのショップはGoogleフォームを使っていた（！）

と、ここでようやく本題といいますか『「蒼穹のファフナーEXODUS」 2017年オリジナルカレンダー』の話に戻るんですが、実際に確認してみたところ Googleフォーム を使っていました。

<img width="665" alt="スクリーンショット 2016-07-10 2.21.02.png" src="https://qiita-image-store.s3.amazonaws.com/0/7574/3642765f-3461-bcb5-c553-729c186dfa9c.png">

XEBECzwei_2017年オリジナルカレンダー
http://www.xebec-inc.co.jp/xebeczwei/shop/shop_goods_1231.html#2017calendar

**Googleフォームを利用している以上は、従来の注文フォームのような高負荷による停止・注文の失敗は無いと見ていい**と思います。

また、Googleフォームには自動返信を行うためのアドオン（拡張機能）が用意されています。

Googleフォームで自動返信（スクリプト不要） | toyoshiの日記
https://www.misoca.jp/toyoshi/517

こちらを利用すれば注文された内容を自動返信することも可能です。

つまり、自動返信メールが無いということは以下の様なことが考えられるということになります。

## 理由：入力したメールアドレスを間違えている

ベタですがありうることです。メールアドレスの形式的に正しいものであれば、フォームの入力チェック機能でもミスは発見できません。特に@の前のアカウント名に誤りがありそうです。念のため確認してみましょう。

## 理由：送信は行われているが、注文者の設定都合で受信できていない

これもベタですが、確認すべきことです。
「迷惑メールフォルダに入ってる」「ドメイン指定で受信設定している」「PCからのメールを受け付けていない」など、実は自動返信が行われているのに受け取れていない可能性があります。

※ このあたりは「予約上の注意」にも載っています。

## 理由：XEBECzwei側が（意図して？）自動返信設定を行っていない

これもありうることです。自動返信設定がアドオンということは、利用しないこともできます。設定する手段を知らない、あるいは意図して自動返信を行わず入力内容を精査した上でメールを送信している可能性があります。

そうなると、「ご予約後10日経っても確認メールが届かない場合は、以下の対処方法をお試し下さい」という注意書きが気になるところです。自動返信であれば、10日も待つ必要はありませんので。

## 返信が来なくても、同じ内容を何度も注文する必要は（おそらく）ない

「返信が無いので何度も注文した」とか、「様子を見てもう一度注文しよう」と言ったツイートも見られましたが、おそらく何度も注文する必要はありません。

Googleフォームであれば注文内容はスプレッドシートに記録されています。
つまりメールが届いていなくても注文内容は既に登録されているはずなので、あとは返信を待つだけなのです。意図的に削除したりしないかぎり、注文内容が破棄されることもないはずです。

**やるべきことは、同じ注文を行うことではなく「入力したメールアドレスが正しいものなのか」あるいは「メールの受信設定」を見直すことだけ**です。

むしろ**何度も同じ注文を行うことでショップの作業の手間が増え、更に混みあう**可能性があるだけでなく、最悪**転売ヤーと見分けが付かなくなってしまう**可能性もあります。

焦る気持ちもあるとは思いますが、ここは運営の方を信じて返信を待ちましょう。どうしても気になることがあれば、注文フォームではなく問い合わせ用のメールアドレスに連絡をしましょう。

---

しかし…、注文フォームでの受付はともかく、確認や決済までをメールで直接やり取りして行うとは、かなりのコストだな…。
決済方法も銀行振り込みや代引きに限定されているし、この手の人気商品をこのような手段で提供することはショップ的にも注文者的にも勿体無い気がするんだけど…。