概要
だいぶ過去の記事ですが、2024年2月に 「microCMS + Astro + Cloudflare Pages で高速・完全無料なブログを構築したら最高すぎた件」 という記事を Qiita に投稿したところ結構反響をいただき、個別相談で DM やメッセージをいただいたり、個人的に構築依頼をされることも増えるようになり、同構成でHPやブログサイトを構築された事例を観測するようになりました。
ただ、HPに関しては「お問い合わせ」が一般的には構成に含まれますが、本番運用レベルで問い合わせフォームの対応を含めた内容で紹介していなかったのと、情報も陳腐化していたので、改めて最新版としてより充実した内容で記事を投稿してみました。
HP(ホームページ)、「完全無料」でどこまでできるか?
Webサイトを持ちたいと思ったとき、真っ先に出てくるのが「お金がかかる」という心理的ハードルです。
特に、スタートアップや個人事業主、あるいはクライアントの小規模なHP案件では、初期コストを極力抑えながらも「チープに見えない」サイトを作りたいという需要は根強いです。
本記事では、筆者が個人的に感じた "できるだけ無料(維持費0円)で、かつ、シンプルに構築でき、本番運用にも耐えるHPを作るための構成" を、各採用技術の選定理由も含めて解説します。
独自ドメイン だけは有償で購入が必要です。あくまでも 「維持費」 が無料になる内容です。
注意:執筆時点の情報です
本記事で紹介するサービスの無料枠・料金プランは、各社の事情によって予告なく変更される場合があります。最新情報は各サービスの公式サイトでご確認ください。本記事はあくまで「執筆時点のベストプラクティス」として読んでいただければ幸いです。
尚、一部コードのスニペットを記載しますが、説明上最低限のサンプルのため、実際に利用可能なスニペットは提示しません 🙏
想定するHPの要件
まず、本記事で想定するHPの要件を明確にしておきます。
| 要件 | 内容 |
|---|---|
| サイト種別 | 企業・個人事業のコーポレートHP (認証機能等が無い、完全静的な Web ページ) |
| パフォーマンス | Core Web Vitals を意識した高速表示を維持する |
| コンテンツ管理 | ニュース・お知らせ、事業紹介などをノンエンジニアが更新できる |
| 問い合わせフォーム | Google フォーム等を使わず、ページ内に自然に埋め込む 問い合わせユーザーへの「自動返信メール」にも対応 |
特に、「あ、お問い合わせフォームが Google フォームだ…」という チープ感 を出さないことを考慮した構成なのが個人的なポイントです。
上記の様な HP を ランニングコスト(維持費)0円 で通常運転できる構成を目指します。
アーキテクチャ全体像
以下が、「維持費0円ホームページ」 の構成に採用した技術スタックです。
-
Cloudflare Workers(ホスティング = Webページの置き場所 + 自動返信メールの動的処理発火)
- 自動返信メールを実装しなければ、完全静的サイトとして実装可能
- Google スプレッドシート + GAS(問い合わせフォーム用)
- Resend(自動返信メール用、任意で外しても良い機能)
- microCMS(コンテンツ管理)
- Astro(フロントエンドフレームワーク = Webページを作る)
フロントエンドは Astro で構築し、ビルド時に microCMS からコンテンツを取得してSSG(静的サイト生成)して、それを Cloudflare に配置します。
フォーム送信のバックエンドは完全にサーバーレスで、Google Apps Script(GAS) と Resend の組み合わせで完結します。
なぜこうなったのかを1つずつ解説します。
採用技術の解説
1. Cloudflare Workers ― 無制限帯域幅のホスティング
静的サイトのホスティングとして Cloudflare Workers を採用します。
最初の選定根拠は Cloudflare Pages
そもそも、技術採用の根拠にあったのは Cloudflare Pages というサービスです。Pages の無料プランの主なスペックは以下の通りです。
| 項目 | 無料プランの制限 |
|---|---|
| 帯域幅 | 無制限 |
| リクエスト数 | 無制限(静的コンテンツ) |
| ビルド回数 | 500回/月、同時1ビルド |
| カスタムドメイン | 100個/プロジェクト |
| ファイル数 | 20,000ファイル/サイト |
Pages の最大のポイントは、帯域幅が無制限 であることです。Netlify や Vercel の無料プランには帯域幅の制限があり、無料プランでは商用利用が禁止 だったり、バズった際に突然課金が発生するリスクがあります。Firebase Hosting も今や Firebase AppHosting が推奨されるようになり、Spark プラン(無料プラン)から Blaze プラン(従量課金プラン)に移行しないと、商用で必要な他機能が使えなかったりと囲い込みが発生しています。
Cloudflare Pages は商用利用も可能で、完全静的コンテンツであれば、どれだけアクセスが来ても追加費用は発生しません。
また、Cloudflare のグローバルCDNネットワークで配信されるため、パフォーマンス面も申し分ありません。静的ファイルを世界中のエッジから配信するため、日本国内向けサイトでも十分高速です。
Git ホスティングサービスのリポジトリを連携接続しておけば、ソースコードの変更が main ブランチにマージされたら自動でビルドが走って更新・反映されるので、CI/CD も非常に楽です。
Pages は Workers に要件が統合された
2025年4月8日、Cloudflare がとある公式発表をしました。
「今後、CloudflareはWorkersの開発に注力していくため、新規プロジェクトではCloudflare Pagesではなく Cloudflare Workersのご利用を推奨いたします。Pagesは引き続きサポートしますが、今後の投資・最適化・機能開発はすべてWorkersの改善に向けられます。」
つまり、「特別な理由がなければ、今後は Pages ではなく Workers で構築してね。Pages で可能だったことは全て Workers でも可能になったよ」 という旨の内容を公式に発表しました。
今後は新機能の実装は Workers のみに実装され、Pages はメンテナンスのみになります(そのうちサ終する可能性もゼロじゃないかも)。静的サイトとしての無制限帯域幅の強みは Workers にも適用されるので、Cloudflare Workers でサイト構築するのがデファクトとなります。
尚、「10万リクエストまで無料」 という Workers の無料枠は、静的ページへのアクセスを指しているのではなく、サーバーサイド関数の実行リクエスト を指しているので、理解に注意が必要です。また、動的な関数実行を組み込む場合、Pages + Pages Functions という組み合わせもありますが、最初から Workers のみで構築した方がシンプルで最適です。
そのため、今回の選定も "Cloudflare Workers" になりました。
2. Google スプレッドシート + GAS ― 問い合わせデータの受け口
問い合わせフォームのバックエンドに、Google スプレッドシート + Google Apps Script(GAS) を採用します。
仕組みはシンプルです。
- フロントエンドの問い合わせフォームが送信されると、GASのWebアプリエンドポイント(
doPost)にデータを POST - GAS がスプレッドシートの末尾に問い合わせ内容を追記
- GAS が Gmail で管理者(自分)に通知メールを送信
これにより、問い合わせ履歴がスプレッドシートに蓄積されつつ、管理者にもリアルタイムで通知が届く仕組みを、完全無料で実現できます。
// GAS の doPost 関数(簡略例)
function doPost(e) {
const params = JSON.parse(e.postData.contents);
const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
// スプレッドシートに記録
sheet.appendRow([
new Date(),
params.name,
params.email,
params.message
]);
// 管理者へ通知メール
GmailApp.sendEmail(
"your@email.com",
`【問い合わせ】${params.name} 様より`,
`名前: ${params.name}\nメール: ${params.email}\n内容: ${params.message}`
);
return ContentService
.createTextOutput(JSON.stringify({ status: "ok" }))
.setMimeType(ContentService.MimeType.JSON);
}
なぜ Google フォームを使わないのか?
Google フォームは UI の自由度が低く、どうしても "Google フォーム感" が出てしまいます。問い合わせユーザーから見ると「明らかに Google フォームを使っているサイト」として映りやすく、プロフェッショナルな印象が薄れる場合があります。
そのため、UIはページ内でちゃんと実装して、裏側の仕組みだけGoogleサービスで補うのがスマートです。
3. Resend ― 自動返信メールの送信
問い合わせユーザーへの自動返信メールの送信に Resend を採用します。
Resendの無料プランは以下の通りです。
| 項目 | 無料プランの制限 |
|---|---|
| 月間送信数 | 3,000通 |
| 1日あたり上限 | 100通 |
| ドメイン数 | 1個 |
"月間3000通" は、「これからHPを用意する」という状況の事業者であれば、問い合わせの自動返信用途でこの無料枠を超えることは現実的にほぼ無いと思われます。
HPへの月間問い合わせが3000件を超えるようなフェーズになっていれば、その時点で有料プランに移行する余力も十分あるはずです。
Cloudflare のメール機能ではダメなのか?
CloudflareにもEmail RoutingとEmail Sendingという機能があります。それぞれの特徴は以下の通りです。
| 機能 | 料金 | 用途 | 課題 |
|---|---|---|---|
| Email Routing | 無料 | 受信メールを別アドレスへ転送 | 仲介転送のためスパム判定リスクが高い |
| Email Sending | Workers Paid(月$5〜)が必要 | 安全なメール送信API | Workers Paid が必須で追加コストが発生 |
Email Routing は受信したメールを別のメールアドレスに転送する機能であり、自分でメールを生成・送信するためのものではありません。また、転送経路が挟まることでスパム判定されやすくなるリスクもあります。
Email Sending は安全に送信できますが、Workers Paid プラン(月$5)の契約が必要です。本記事の「完全無料」という主旨には沿わないため、採用しません。
GAS の Gmail ではなく Resend を使う理由
自動返信(ユーザーへの返信)にGASのGmailを使うこともできます。ただし、GmailはB2Cメールサービスであり、サービス通知・トランザクションメールとして送信するには独自ドメインのメールアドレスから送れないという問題があります。@gmail.comからの自動返信は、サービスとしての信頼感を損ないます。
Resendはカスタムドメインを設定して独自ドメインから送信できるため、「info@example.com からの自動返信」 という形を取れます。これにより、サービスとしての信頼性が格段に上がります。
整理すると
- 管理者への通知メール(自分への転送) → GAS + Gmail(無料)
- ユーザーへの自動返信メール → Resend(無料枠内)
この役割分担が、コストゼロで実現できる最適解です。
4. microCMS ― 国産ヘッドレスCMS
HPの更新可能なコンテンツ(ニュース・お知らせ、事業紹介、製品ページなど)の管理に microCMS を採用します。
microCMSの無料プラン(Hobbyプラン)の主なスペックは以下の通りです(2025年6月の改定後)。
| 項目 | Hobbyプラン(無料)の制限 |
|---|---|
| API数 | 5個 |
| コンテンツ数 | 1万件 |
| メンバー数 | 1名 |
| 料金 | 無料 |
以前は3APIまでの制限でしたが、2025年6月の改定で5API に拡充されました。ニュース、製品情報、メンバー紹介、FAQ、会社概要…くらいの API を持つ HP であれば 5API で十分に収まります。記事コンテンツ数も「1万件」の無料枠は十分すぎるくらい余裕が持てます。
microCMS を採用する理由
以下のメリットがあります。
-
非エンジニアでもブラウザからコンテンツを管理できる
クライアントに「このURLからログインして記事を追加・更新してください」と伝えるだけで、保守対応の工数を大幅に削減できる。クライアントからしても、いちいちエンジニアに頼む手間やタイムラグが減るので Win-Win な関係になれる -
ヘッドレスCMS
フロントエンドの技術スタックに縛られないので、Astro でも Next.js でも、API を叩くだけで同じコンテンツを取得できる -
Webhook 連携で自動ビルドが可能
microCMS でコンテンツを更新すると、Webhook が Cloudflare Workers のデプロイフックを叩き、自動的に再ビルド&デプロイされる -
国産ヘッドレスCMS
日本人のクライアントへの説明・提案がしやすいというメリットがある。「日本語対応・日本語サポート・日本企業が提供」という部分で "謎の安心感" を持たれやすい。日本語ドキュメントも充実しており、エンジニアとしてもキャッチアップのコストが低い
5. Astro ― ゼロJSから始まるSSGフレームワーク
フロントエンドフレームワークとして Astro(アストロ)を採用します。
アイランドアーキテクチャ
AstroはUIを「アイランド(島)」という概念で捉えています。ページの大部分は静的HTMLとして生成し、インタラクティブなコンポーネント(問い合わせフォーム、アコーディオン等)だけを「アイランド」として個別にハイドレーションします。
---
// src/pages/index.astro
import ContactForm from '../components/ContactForm.jsx';
---
<html>
<body>
<h1>会社概要</h1>
<p>ここは静的HTML。JavaScriptはゼロ。</p>
<!-- このコンポーネントだけJSが動く -->
<ContactForm client:load />
</body>
</html>
client:load、client:visible、client:idleなどのディレクティブで、JSをいつロードするかを宣言的にコントロールできます。
デフォルトでJSゼロ
Astroの哲学は「デフォルトでJavaScriptゼロ」です。npm run buildで生成された静的HTMLを見ると、コンポーネントを使っているにも関わらず、クライアント側のJSが一切含まれていないことがわかります。これにより、LCPやTBTなどのCore Web Vitalsで優秀なスコアを出しやすくなります。
AIコーディングとの相性
AstroのコンポーネントはReact/Vue/Svelteなど既存のUIライブラリをそのまま使えるため、ClaudeやGitHub CopilotなどのAIコーディングツールとの相性が抜群です。「このデザインのセクションを作って」と指示すれば、既存のコンポーネントを流用しながらUI構築のほとんどをAIに任せることができます。
Wrangler CLI でプロジェクト構築を完結させる
Cloudflare Worker へのデプロイだけであれば、Wrangler CLI を使えばコマンドラインだけで完結します。ダッシュボードをポチポチ操作する必要はありません。
# Cloudflare アダプターを追加(未導入なら)
npx astro add cloudflare
# Wrangler のインストール
npm install wrangler --save-dev
# Cloudflare にログイン
npx wrangler login
# ビルド & デプロイ
npm run build
npx wrangler deploy
また、package.jsonのスクリプトに組み込んでおけば、npm run deploy一発でビルドからデプロイまで完了するようにできます。
{
"scripts": {
"build": "astro build",
"deploy": "npm run build && wrangler deploy"
}
}
尚、main ブランチへのプッシュを契機に自動デプロイする CI パイプライン は、現状ダッシュボード UI からしか設定できなさそうですが、GitHub Actions と組み合わせれば構築の自動化も可能です。
コスト一覧まとめ
契約する利用サービスとコストをまとめると、以下の通りです。
| サービス | 用途 | 無料枠の条件 | 月額コスト |
|---|---|---|---|
| Cloudflare Workers | 静的ファイルホスティング・自動返信メール処理発火 | 帯域幅・リクエスト無制限・関数実行10万リクエストまで | ¥0 |
| microCMS | ヘッドレスCMS | 5 API・1万コンテンツまで | ¥0 |
| Google スプレッドシート + GAS | フォームデータ記録・管理者通知 | フリーの Googleアカウントのみ(十分な無料枠) | ¥0 |
| Resend | 自動返信メール送信 | 月3,000通・1日100通まで | ¥0 |
| 合計 | ¥0/月 |
これで、構築・運用のシンプルさを両立しながら、一定以上品質の HP をほぼ完全無料で商用として運用することが可能になります。
おまけ:お問い合わせフォームへのスパム対策は?
お問い合わせフォームへの bot によるスパムやイタズラの申請を防ぐには、例えば以下のような機能を組み込むことが選択肢で選びやすいと思います。
-
CAPTCHA(キャプチャ)認証の導入
- Google reCAPTCHA: ユーザーの行動を解析して bot かどうかを判定
- Cloudflare Turnstile: プライバシーを重視した reCAPTCHA の代替ツールで、無料で利用可能
-
ハニーポット(Honeypot)の設置
- 人間には見えず、botだけが読み取って入力してしまう「ダミーの入力欄」をフォームに埋め込む。ここに文字が入力された場合は、bot と判定して送信をブロックする
- URLの入力拒否や入力内容の制限
- スパムの多くは悪意のあるリンクを送信するため、フォームの入力内容に「http」や「https」が含まれている場合は、送信エラーになるように設定するなど
おわりに
「無料でもそれなりのものができる」という時代から、今や「無料でも本格的なものができる」時代になっています。
本記事で紹介したアーキテクチャは、ちゃんとしたコーポレートHPとして通用するレベルのものを、月0円で実現できます。
一方で冒頭にも書いた通り、各サービスの無料プランは変わりえます。事業が成長してアクセスが増えたり、チームが拡大してメンバーを追加したいタイミングで、適切なプランへの移行を検討しましょう。
今回のアーキテクチャが、これからHPを作ろうとしている方の参考になれば幸いです。
