Dyno

静的サイトにお問い合わせフォームをつけたいときの選択肢まとめ

静的サイトにお問い合わせフォーム 1 を設けたいときに採りうる選択肢としてどのようなものがあるのかをかんたんにまとめました。 興味のある方は参考にしてみてください。

静的サイトにお問い合わせフォームをつけたいときの選択肢

採りうる選択肢は大きく分けて 2 つあります。

  • A. フォームを自前で用意しないアプローチ
  • B. フォームを自前で用意するアプローチ

A. フォームを自前で用意しないアプローチ

こちらは独自にフォームを実装せずにありもののクラウドサービスを利用する方法です。 具体的に利用するサービスとして世界的には Google Forms や HubSpot あたりが有名ですが、国内外にたくさんのサービスがあるので、ここでひとつひとつ名前をあげることはしません。 各サービスの特徴を見て、要件・環境に合ったサービスを選ぶとよいでしょう。 ある程度実績のあるものの中から選べば特に大きく失敗する可能性は低いと思います。

A は細かな実現方法の違いでさらに 3 つに分類できます:

  • A1. 外部のサイトにフォームを作り、静的サイトからリンクする
  • A2. 外部のサイトにフォームを作り、 iframe で静的サイトに埋め込む
  • A3. 外部のサービスで API エンドポイントを作り、そこにデータを投げ込むフォームを静的サイト上に作る

A1 は、クラウドサービスが提供する方法でフォームを作って、静的サイトにはそのページへのリンクを設けるという方法です。 静的サイト内にお問い合わせフォームを設けるわけではないので、厳密に言うとこれは「静的サイトにお問い合わせフォームを付ける方法」ではありません。 ただ、最も手軽に導入でき保守性もよいので、静的サイトにおけるお問い合わせフォームの検討の際にはこれも候補に含めるとよいと思います。

A2 は外部のサービスでフォームを用意するところは A1 と同じですが、そのフォームを iframe タグを使って静的サイト内に埋め込む点が A1 とは異なります。 こちらは A1 のデメリットである「サイト間の移動」が発生しないところがポイントです。

A3 は、クラウドサービス側ではフォームから送信されたデータを受け取る API エンドポイントだけを用意して、静的サイト側ではその API エンドポイントを叩くお問い合わせページを JavaScript で実装する方法です。 A3 には、問い合わせを行うユーザーの体感は動的なサイト内の通常のウェブフォームとほぼ同じというメリットがあります。

ちなみに、近年は A3 のパターンでも JavaScript コーディングを必要としない場合もあります。 たとえば JAMstack 2 の界隈で有名なホスティングサービス Netlify の場合は、 form タグに専用の HTML 属性をちょこっと追加するだけで( JavaScript を一行も書かずに)お問い合わせフォームを作ることができます。

B. フォームを自前で用意するアプローチ

こちらはフォーム機能を独自に実装してお問い合わせフォームを実現するアプローチです。 こちらも A と同じように

  • サーバーサイドのプログラムを静的サイトと同じサーバーに置く・置かない
  • サーバーサイドのプログラムに既存の OSS [^oss] を使う・使わない
  • 送信データをクラウドサービスに預ける・預けない

といったポイントで細かく選択肢が分かれます。

ただし、 B の場合でも、「完全スクラッチ」だと品質も費用対効果も低くなるので、「主要な部分は OSS やクラウドサービスで実装し、補助的な部分だけスクラッチ」というアプローチが近年の王道になるかと思います。

「静的サイトの一部だけ動的にしたい」というのはウェブの世界における普遍的ニーズであり、そのために使えるツールが OSS ・クラウドサービスともにたくさん用意されているので、下手にスクラッチ開発をしないことが重要です。

各選択肢の特徴

各選択肢の特徴についてかんたんにまとめます。

A の「フォームを自前で用意しないアプローチ」と B の「フォームを自前で用意するアプローチ」を比較すると、それぞれ次のような特徴があります。

選択肢 メリット デメリット
A 導入コストが低い
保守コストが低い
データをクラウドに預ける
サービスレベルをコントロールできない
カスタマイズの自由度が低い
B データを自社で保有できる
サービスレベルをコントロールできる
カスタマイズの自由度が高い
導入コストが高い
保守コストが高い

A のサブの選択肢同士を比べると次のような特徴があります。

選択肢 メリット デメリット
A1 かんたん
保守コストが低い
問い合わせの経路が長くなる
A2 かんたん
問い合わせの経路が長くならない
サイトとフォームのデザインの整合性が取れない
A3 問い合わせ経路が長くならない
サイトのデザインとの整合性が取れる
動的サイトの通常のウェブフォームと同等のユーザー体験
A1 / A2 に比べて複雑で実装難易度が高い
導入コストが高い

それぞれにメリット・デメリットがあるので、「どんな場合でも最適なベストの選択肢」はありません。 各社の要件と環境に合わせて最適なものを選ぶべきです。

ということで、静的サイト上でのお問い合わせフォームの実現方法のかんたんなまとめでした。

「動的サイトの静的サイト化」や「静的サイトでの動的機能の部分的導入」を検討している方は参考にしてみてください。


  1. 一般的にいうと「ウェブフォーム」全般

  2. JAMstack (ジャムスタック)。 JAM は JavaScript + API + Markup の頭文字で、静的サイトと動的サイトのよいとこ取りをするような手法です。興味のある方は JAMstack とは?なぜ今 JAMstack なのか? をご覧ください。

  3. Open Source Software (オープンソースソフトウェア)