Scribble at 2026-01-27 06:35:35 Last modified: unmodified
製品情報について回答する「製品お問い合わせフォーム」で、２０２１年２月２２日から２５年１２月２日までの間、不具合が放置されていた。期間中、５６２３件の問い合わせに回答できていなかった。対象者には１月２７日までに連絡して対応するとしている。
Epson の公式サイトで掲載されているリリースでは「一部のお客様からのお問い合わせにご回答できていない」としているが、５年間にわたって5,000件以上の問い合わせをスルーしていたことになるため、全てではないという意味で「一部」だとは言えるものの、それは敢えて言えば過小評価や矮小化であり、一種の「ご飯論法」だと言ってよい。まぁ大企業の PR や法務が考えそうな猿知恵だが、現実の public relation を担うマーケティング（これも本来は「マーケティング」の話題である）の立場から言えば、このような姿勢は逆に反感や不信感を引き起こすだけの悪手である。
で、原因としては「お問い合わせフォームと内部システムの連携設定に不具合」というわけなので、実際にどういうフォームなのかを見てみると、まず問題となったフォーム、つまり
https://www.epson.jp/support/info/mail/
で表示される画面のソース・コードを確認すると（言っておくが、プライバシーマークを上場企業レベルで運用していて、更にエンジニアとしても電通案件に対応する人間が検査してやろうというのだから、本来なら数百万円の案件だ）、まずコードの冒頭でいきなり驚くのは、XHTML で書かれているということだ。いまどき何の必要性があって XHTML なんていう規格でコーディングしているのか、まず疑問が起きる。どう見ても、このコードあるいはコードを出力しているシステムが10年くらい前のものであるかもしれないという疑いを引き起こすからだ。実際、DOCTYPE 宣言の次に <html> タグで "xmlns:fb="https://www.facebook.com/2008/fbml" などという弥生時代の属性が使われているが、こんなのは10年以上前の話 OGP 属性であり、寧ろ無効であって、SEO では逆にページの古さを自己証明してランクを下げるだけであろう。
次に、外部からサイトの動作環境を分析するときによくやることだが、スタイルシートや JavaScript のコードは誰でも中身を確認できるのだけれど、たいていは導入したライブラリや CMS が使う典型的な命名規則で関数名やクラス名を定義しているので推測しやすかったりする。このフォームでも、スタイルシートでは「mf_finder_searchBox」などというクラス名が使われているので、株式会社マーズフラッグという会社の検索システムを導入していると推定できる。もちろん、それがいけないと言いたいわけではない。
このページがかなり古いテクノロジーで書かれていて、しかも更新されずにいると推定できる理由は、他にもある。ソース・コードを眺めるだけで、次には "jQuery v1.9.1" という文字列が目に入る。そして、JavaScript のエンジニアであれば、多くの方が「やれやれ」という気分になることだろう。なぜなら、jQuery の1.9.1なんていうバージョンは10年以上も前の2013年にリリースされたコードの版数だからである。ふつう、JavaScript はセキュリティの攻撃に悪用される頻度が高いため、こういうライブラリの更新は（ウェブサイトのまともな運営体制であれば）本来なら最も関心をもつべきところだ。確かに、現実には大企業や上場企業の多くが何年も古いコードやシステムを放置していることは、電通案件をやっている僕は実体験として承知しているが、ひとまず弊社はリスクがあることをトップ・クライアントに伝えてはいる。こういう場合に、たいていは「予算がない」とか「大したリスクではない」とか「動かなくなると大変だ」などと素人考えで反論する人がいるものだが、どれも根拠はない。まず、この手のライブラリを更新して全く動かなくなるような JavaScript のコードを書くバカに実装を任せる初手にも問題はあると思うが、動かなくなったら修正するのが普通のエンジニアである。そして、ライブラリ本体を更新するだけでアプリケーション側の修正に途方もない工数やコストがかかるなら、もともとそんな業者に任せた方が悪いのだ。そして、フォームのコード一つで重大なセキュリティ事故が起きることは、既に十分すぎるほどの実例があり、フォームくらい放置しても構わないなどと言う人間はコンプライアンスの観点からも、寧ろ企業という組織にとっての「リスク人材」だとすら言える。これは僕の持論だが、企業は頭（経営陣）からも腐っていくが、本当に深刻なのは、財務的に安定している状況へあぐらをかいているせいで見過ごされる、企業が足の爪あるいはチンチンから腐っていくという現実だ。
そして、jQuery を前提に導入されている jQuery Easing というプラグインもヴァージョン1.3は2012年頃のものであり、しかも殆どアップデートされていない、これ自体が開発体制に疑問を覚える。実際、1.3の後にリリースされたのは jQuery 3.0 以降に対応する1.4でしかなく、その最終更新からでも７年が経過している。７年間も全く修正しなくても良い堅牢なコードなんてまずない（たった１行ですら、時間が経てば修正が必要が場合だってあり得る。特にプラグインのような他のコードへ依存して動くツールならなおさらだ）。他にも古いプラグインが幾つか使われているが、正式な受託での検査じゃあるまいし、いちいち確認しない。
では、肝心のフォームはどうか。更に導線を進むと、オプト・インのページを過ぎたあとで表示されるのは、プロセス・メーターがついたアンケート式のフォームである。ここからが問い合わせの手続きとなるのだろう。そして、この最初のページでソース・コードを確認すると・・・いやはや冒頭に現れるのは、あの昔懐かしき HTML 4.01 の文書型宣言である。もちろん、悪いとは言わないが、これは相当に古いシステムを使っていることが予想できる。このあとは、どういうシステムが裏で動いているかは分からないことが多いため、不用意な想像は避けたいところだが、URL で分かるとおり cform.epson.jp というフォーム専用のサブ・ドメインを切っているくらいだから、それなりに独立した実装環境を予想させる。また、こういう検査ではウェブ・サーバのエラー・ページをわざと出してみたりする。なぜなら、エラー・ページまでオリジナルのデザインで作っていることは少なく、エラー・ページのデザインだけでウェブ・サーバのアプリケーションを推定できる場合があるからだ。実際、このサイトでエラー・ページを出してみたら、IIS の典型的なデザインのエラー・ページが出てきた。ただ、これだけではプラットフォームまで推定できるわけではないから、cform.epson.jp というホスト名の逆引きを調べると、なんと AWS の EC2 にアクセスしていたことがわかった。つまり、AWS 上の Windows Server で動く IIS というプラットフォームが推定できる。