ブログ一覧へ戻る

Web制作・運用

WordPressではなく「GitHub+JSON+Cloudflare」でサイトを作る理由|速度・費用・安全性と、問い合わせフォームの作り方

GitHub+JSON+Cloudflareでサイトを作る理由(速さと費用・安全性・フォームの作り方)

合同会社SENTICの会社サイト(sentic.co.jp)は、WordPressのようなCMSを使っていません。記事やお知らせを1件ずつ「JSON」という形式のファイルにしてGitHubで管理し、Cloudflare Pagesで公開する構成で動いています。

AIと一緒にサイトを作り、更新していく中で、CMSの管理画面や、本体・プラグインの更新に手間をかけるより、「ファイルを書いて、確認して、公開する」という形のほうが合っていると感じ、この構成にしました。

この記事では、この構成のよいところと注意点、そして静的なサイトで必ず課題になる「問い合わせフォーム」をどう作るかを紹介します。

※CloudflareのCMS「EmDash」やWordPressとの比較は、こちらのコラムでまとめています。

この記事でわかること

  • GitHub+JSON+Cloudflareという構成の仕組み
  • 表示速度・費用・検索対策の面でのよいところ
  • 安全性の面でのよいところと、残る注意点
  • 静的なサイトで、問い合わせフォームをどう作るか
  • フォームを自分たちで作るときに欠かせない対策と、SENTIC FORMの対策

どんな構成なのか

役割使うものやること
記事・データJSON記事、お知らせ、制作実績を1件ずつファイルにする
保管と変更の記録GitHubファイルを保管し、変更を記録する。公開前の確認(プルリクエスト)もここで行う
ページの書き出しと公開Cloudflare Pagesファイルから全ページを書き出し、世界中の配信拠点から届ける

GitHub+JSON+Cloudflareの仕組み:JSONで記事を1件ずつファイルにし、GitHubで保管・記録・確認、Cloudflare Pagesでページを書き出して配信、見る人に近い拠点から届く

記事を書いて承認すると、Cloudflareが自動でページを書き出して公開します。サーバーに管理画面やデータベースは置いていません。

このように、ページをあらかじめ書き出して配信し、変更をGitHubで管理するやり方は、「Jamstack(ジャムスタック)」や「GitOps(ギットオプス)」とも呼ばれ、Web制作の現場で広く使われている考え方です。

この構成のよいところ

表示を速くしやすい

ページはあらかじめ書き出してあり、Cloudflareの配信網(CDN)から、見る人に近い拠点で届けられます。サーバーでページを組み立てる処理を待たないので、表示を速くしやすい構成です。

ただし、動画や動きのある演出を多く入れると、そのぶん重くなります。「静的だから必ず速い」わけではなく、速さはサイトの作り方次第です。

サーバー代がかからない

GitHubとCloudflare Pagesには無料のプランがあり、一般的な会社サイトなら、無料の範囲で公開できることも多いです。レンタルサーバーの月額費用はかかりません。

ドメインの費用は別にかかります。また、フォームのメール送信や、規模が大きくなったときの有料プランなど、使い方によって費用が出る部分もあります。

検索エンジンが読み取りやすい

ページの中身は、書き出し済みのHTMLとして届けられるので、検索エンジンが内容を読み取りやすくなります。表示の速さも、検索で評価される要素の1つです。

ただ、検索で上位に出るかどうかは、何より記事の中身や、サイト全体の作りで決まります。構成を変えるだけで検索順位が上がる、というものではありません。

安全性の面でのよいところ

公開しているサイトの側には、データベースも、PHPのようにサーバーで動くプログラムもありません。そのため、

  • データベースを狙う攻撃(SQLインジェクションなど)を受ける入口がない
  • PHPやCMS本体の脆弱性を突いて、サーバーを乗っ取られる心配がない
  • WordPressの本体やプラグインの更新漏れから、改ざんされる心配がない

といった点で、攻撃を受ける場所を大きく減らせます。2026年10月に話題になったPHPの重大な脆弱性も、この構成のサイトには関係ありませんでした(こちらのコラムで解説しています)。

一方で、まったく危険がなくなるわけではありません。

  • GitHubのアカウントを守る:書き込める人のアカウントが乗っ取られると、サイトを書き換えられてしまいます。2段階認証は必須です
  • ページを作るソフトの点検:ページを書き出すときに使うソフトの部品(ライブラリ)にも、ときどき弱点が見つかります。定期的な点検と更新が必要です
  • フォームは別に守る:問い合わせフォームのように、送信を受け取る部分には、別の対策が必要です(後述)

よいところと残る注意点:表示を速くしやすい、サーバー代がかからない、攻撃を受ける場所が少ない。注意点は、GitHubのアカウントを守る、作るソフトの点検と更新、フォームは別に守る

静的なサイトの課題:問い合わせフォーム

静的なサイトでは、サーバーでプログラムが動かないので、問い合わせフォームの送信を受け取る仕組みを別に用意する必要があります。

会社のサイトでは、送ってくれた人への自動返信メールと、担当者への通知メールの2通を送れることも欠かせません。

方法は大きく2つです。

1.外部のフォームサービスを使う

Googleフォームや、静的サイト向けのフォームサービス(SSGformなど)を埋め込む方法です。手軽に始められますが、見た目や自動返信、計測の細かさは、サービスに合わせることになります。

2.Cloudflareの上で、フォームを作る

Cloudflare Workers(またはPages Functions)の上に、送信を受け取る仕組みを作り、メール送信サービスとつなぐ方法です。自動返信と担当者への通知、見た目、計測まで、思いどおりに作れます。

SENTICの場合:フォームビルダー「SENTIC FORM」

合同会社SENTICでは、2の方法で、フォームビルダー「SENTIC FORM」を自社で開発しました。会社サイトの問い合わせフォームも、SENTIC FORMで作ったフォームを埋め込んで使っています。

SENTIC FORMでできること:

  • 管理画面でドラッグ&ドロップしてフォームを作れる。コーディングは不要
  • 複数ページのフォームや、回答に応じて質問を切り替える条件分岐
  • 送った人への自動返信メールと、担当者への通知
  • 回答の一覧確認と、CSVでの書き出し
  • 送信元のメールアドレスを、サイトごとに設定できる
  • 埋め込みコードを貼るだけで、WordPressやHTMLのサイトにも設置できる

一度作ってしまえば、新しいフォームが必要になるたびに、管理画面で作って貼るだけになります。

WordPressのフォームと比べて

WordPressでよく使われるContact Form 7は、WordPressのプラグインとして、サイト本体と同じ場所で動きます。そのため、WordPressやプラグイン、PHPに弱点があると、フォームを含めたサイト全体が影響を受けることがあります。

SENTIC FORMは、サイト本体とは別の場所(Cloudflareの上)で動き、サイトには埋め込むだけです。フォームとサイト本体が切り離されているので、攻撃を受ける範囲を小さくでき、より安全な形にしやすいと考えています。

計測もしやすい

広告やサイトの成果を測るには、「フォームが送信された」ことを正しく計測できることが大切です。

SENTIC FORMは、Googleタグマネージャー(GTM)と連携し、フォームの送信をコンバージョン(成果)として計測できるようにしています。Contact Form 7でも計測はできますが、送信完了を拾うための設定を追加で行う必要があることが多いので、最初から計測できる形にしておくと、運用がぐっと楽になります。

また、SENTIC FORMは、送信が本当に成功したときだけ完了画面を出し、成果として計測します。通信の失敗などで届いていないお問い合わせを、成果として数えてしまうことはありません。

フォームを自分たちで作るときに欠かせない対策

フォームは、サイトの中で外から送信を受け取る、数少ない入口です。自分たちで作るなら、次の対策は欠かせません。

  • ボットによる大量送信を防ぐ:Cloudflare Turnstileのような、人が送信しているかを確かめる仕組みを組み込む
  • 送信回数を制限する:同じ送信元から短時間に何度も送られないよう、受け取る側(Workers)で回数を制限する
  • 入力内容をチェックする:ブラウザ側だけでなく、受け取る側でも、必須項目や文字数、形式を確かめる
  • 管理画面で安全に表示する:送られてきた内容に、悪意のあるコードが含まれていても実行されないように表示する
  • メールが確実に届く設定をする:送信元のドメインの認証(SPF・DKIM・DMARC)を設定し、迷惑メールに入らないようにする

作ったあとも、迷惑な送信が増えていないかを見ながら、定期的に見直すことが大切です。

SENTIC FORMの対策

SENTIC FORMは、こうした対策を組み込んだ形で動いています。

対策内容
Cloudflare Turnstile送信のたびに、人が送っているかをCloudflareが裏側で確かめる。普通に使っている人には、チェック画面はほとんど出ない
見えない入力欄(ハニーポット)人には見えず、ボットだけが入力してしまう欄を置き、機械的な送信をはじく
送信回数の制限同じ送信元から短い時間に何度も送られたら、しばらく受け付けを止める
受け取る側での入力チェックフォームにない項目や、長すぎる文章、形式の合わないメールアドレスを、受け取る側ではじく

SENTIC FORMの守り:会社のサイトとは切り離したCloudflareの上で、Turnstile、見えない入力欄、送信回数の制限、受け取る側での入力チェックを行い、自動返信と担当者への通知を送る

対策はフォームを受け取る側(SENTIC FORM)にまとめてあるので、管理画面で作って埋め込んだフォームは、どれも同じ対策で守られます。フォームごとに設定し直す必要はありません。

なお、Turnstileが防ぐのは、ボットによる機械的な送信です。人が手で入力して送ってくる営業のメッセージまでは止められません。そうした送信は、受け取ったあとで振り分ける必要があります。

まとめ

  • GitHub+JSON+Cloudflareは、表示を速くしやすく、サーバー代がかからず、攻撃を受ける場所を大きく減らせる構成
  • ただし、GitHubのアカウントの守り方や、作るソフトの点検など、別の形の手間はある
  • 静的なサイトでは、問い合わせフォームをどうするかが最初の課題になる
  • フォームは、外部サービスを使うか、Cloudflareの上で作るか。作る場合は、スパム対策や送信回数の制限が欠かせない
  • 一度作ってしまえば、フォームの追加も計測も楽になる。対策を強めるときも、フォームの側を直すだけで、すべてのフォームに行き渡る

AIと一緒にサイトを作り、更新していきたい方や、WordPressの保守の手間を減らしたい方にとって、検討する価値のある構成だと思います。

合同会社SENTICは、奈良を拠点に、Web制作・運用から動画制作、AI導入支援までを行っています。

ブログ一覧へ戻る