レンタルサーバーのHTMLサイトでも動く!inqboxで実現するセキュア&スマートなお問い合わせ管理

#INQBOX#Web開発#SaaS#受託開発#PHP
レンタルサーバーのHTMLサイトでも動く!inqboxで実現するセキュア&スマートなお問い合わせ管理

inqboxは、Webサイトに設置された問い合わせフォームからの送信内容を受け付け、営業目的の連絡と本来対応すべき問い合わせを自動で判別・分離して管理できるサービスです。

一般的なスパムブロックツールは、ボットによる自動送信の遮断を主眼に置いています。しかし、営業メールの多くは人間が手動で送信しているか、正規のフォーム入力手順を踏んでいるため、CAPTCHAなどのボット対策を通過してしまいます。これに対してinqboxは、送信文面を解析して営業や売り込みであるかを推定し、管理画面上で通常の問い合わせとは別の領域に振り分けます。その結果、担当者が不要な売り込み連絡を一件ずつ開封して確認する負担が減り、顧客からの連絡へ速やかに対応できるようになります。

同時に、フォームのバックエンド処理をサービス側が引き受けるため、開発者がデータベースやメール送信用のAPIを自前で構築する必要もありません。ページへ指定のスクリプトタグを埋め込むだけで設置が完了します。送信されたデータはサービスの管理画面に集約され、メールやSlack、Webhookなどを通じた通知も利用できます(利用できる通知先は契約プランによって異なります)。

静的HTML・レンタルサーバー運用のコーポレートサイト

HTMLとCSSだけで構築され、レンタルサーバーで運用されているコーポレートサイトは、inqboxの利点が現れやすい環境です。

こうしたサイトにお問い合わせ窓口を設ける場合、従来はサーバーへ配置したPHPスクリプトからメールを送信する実装が広く用いられてきました。しかし、この方式を維持するには次のような保守作業が継続して発生します。

  • フォーム送信時の文字化けやメール未達を回避するための文字コード・エンコーディング設定
  • メール送信スクリプトへのヘッダインジェクション対策やCSRF対策の実装
  • レンタルサーバー側のPHPバージョン更新に伴う関数の非推奨化や動作検証

共用レンタルサーバー上のPHPから mb_send_mail 関数などで送信する従来の構成では、サーバー会社によるPHPランタイムの強制更新に伴う関数の挙動変更や、同一サーバー上の他ユーザーの送信行動によるIPアドレスのレピュテーション低下から、Gmailなどの宛先で迷惑メール判定を受けるリスクを抱え続けます。フォームの送信先をinqboxへ切り替えると、ブラウザからサービスのインフラへ直接HTTPS通信でデータが送られるため、自社のWebサーバー上でPHPスクリプトを稼働させる必要自体がなくなります。結果として、PHPランタイムのバージョン検証やサーバーごとのSPF・DKIMの設定調整から解放され、サイトの運用を純粋な静的ファイル配信のみに絞り込めます。

期間限定のランディングページ(LP)やイベントサイト

期間限定で公開するプロモーション用のランディングページやイベント特設サイトでも、inqboxの仕組みが役立ちます。

こうしたページは公開までの期日が短く設定されることが多く、バックエンドの実装に多くの時間を割けない事情があります。フロントエンドをNextjsやVueで構築して静的ホスティング環境へデプロイする構成では、問い合わせの受信処理をどこで担うかが問題になります。サーバーレス関数を使ってメール送信処理を組む手法もありますが、エラー時のリトライ処理や通知連携まで含めると、相応の実装・検証工数が必要です。

inqboxを利用すれば、NextjsやVueのコンポーネントからAPIを呼び出すか、指定タグを埋め込むだけで問い合わせ窓口を開設できます。開催期間中に集中しやすい営業連絡も自動で分離されるため、運営担当者は限られた会期の中で参加希望者や取材依頼への対応に専念できます。イベント終了後も埋め込みタグを取り外すだけで撤収できるため、残存したサーバーレス関数の管理コストも発生しません。

受託開発やWeb制作におけるクライアントワーク

Web制作やシステム開発を受託する現場にとっても、inqboxのような外部サービスの活用は実用的な選択肢です。

発注元から「サイト宛てに届く問い合わせの半数以上が売り込み営業で、通常業務に支障が出ている」という相談を受ける場面は珍しくありません。開発側が独自の判定処理を都度実装したり、送信フォームに入力項目を増やして営業送信を防ごうとしたりすると、開発コストが膨らむだけでなく、見込み顧客の途中離脱を招くおそれがあります。

設計にinqboxを組み込むことで、制作側と運用側の双方に次のような利点が生まれます。

  1. バックエンドの開発工数を抑え、短納期で公開できる
  2. 送信一覧や検索機能を備えた管理画面を、追加開発なしで初期状態から提供できる
  3. 納品後に発生しがちなメール不達やスパム混入への調査・修正負担を抑えられる

パーティーハード株式会社(ptyhard)が受託開発を行う際も、フォーム単体のためにサーバーサイドの保守契約を維持する構成は発注者側の運用負担を増やしやすいと捉えています。クライアントの関心は「送信スクリプトを自前で保有すること」ではなく「確実な問い合わせの受信と営業メールの排除」にあるためです。もしコードの保有自体が目的でないなら、静的な構成で完結するサイトではinqboxのようなサービスを組み込み、初期構築費と公開後の運用費の双方を抑える提案を行います。

Webアプリケーションと静的サイトにおける構成の使い分け

社内基幹システムと連動するトランザクション処理や、厳密な承認フロー、細やかな権限管理が求められるWebアプリケーションでは、LaravelやSymfonyを用いて独自にバックエンドを設計・実装する構成が適しています。データの整合性担保や外部システムとの密な連携が必要になるためです。しかし、会社案内のコーポレートサイトや単一のLP、イベントの参加受付といった用途では、専用のAPIやデータベースを構築して維持し続ける技術的必然性は高くありません。

PHPスクリプトの保守やサーバー移転時のメール設定に工数を割けない環境や、日々の営業メール選別に追われている現場では、フォーム受付をinqboxへ委ねる構成が現実的な解決策となります。要件に応じて独自開発と外部SaaSの境界線を引き分けることで、基幹システムとの連携機能や複雑なビジネスロジックの開発といった固有の領域に開発リソースを集中させることができます。

望月 涼太 / polidog

望月 涼太 / polidog

Co-Founder / Web Engineer