小さな事業のIT手帖

技術メモ担当者・業者向けの記事です。社長向けの入口は トップの困りごと です。

実録

会社のサイトにサーバ代は要らない。このサイトを月0円で動かしている構成を全部見せる

公開 更新 読了13分

これから始めるサーバ

中身の図の縮小版。色が付いているのは: 看板（Webサイト・サーバ）契約の名義とログイン情報ドメインDNSサイトメールアカウントファイルバックアップ電源・機器回線端末ソフトホームページとメール・パソコンの中身の図の、ここの話です看板（Webサイト・サーバ）中身の図で位置を見る →

会社案内のサイトを作るだけなのに、レンタルサーバーの契約、WordPressの更新、プラグインの脆弱性の知らせ。年に数回しか更新しないサイトのために、保守の仕事だけが増えていく。そういう相談をよく受けます。

私の見立てははっきりしています。会社案内と記事だけのサイトに、サーバは要りません。 いま読んでいるこのサイト（it-techo.com）は、サーバの月額0円で動いています。固定費はドメイン代の年 $10.46 だけです。この記事を読み終えると、同じ構成を自分で組むための設定と手順、つまずく場所、そして「うちはこの構成をやめてWordPressにすべきだ」と判断する条件が分かります。

先に結論：このサイトの構成

部品このサイトで使っているもの
サイトの生成Astro（原稿はMarkdown。公開前に全ページをHTMLへ書き出す）
配信Cloudflare Workers の静的アセット
公開の操作手元のMacから wrangler のコマンドで直接アップロード（GitHub連携は使っていない）
ドメインCloudflare Registrar で取得した .com
連絡用メールCloudflare Email Routing（受信専用の転送）

ページには外部のスクリプトも外部のフォントも読み込ませていません。HTMLは1ページ20KB前後です。軽いのは腕がいいからではなく、載せていないからです。

目次（8）
  1. 1. なぜサーバが要らないのか
  2. 2. 実際の設定
  3. 3. つまずいた点（実際の記録）
  4. 4. この構成が向かない場面
  5. 5. WordPressを選ぶべき会社
  6. 料金の目安（取得日 2026-09-20）
  7. 6. 手順と確認表
  8. 出典（取得日: 2026-09-20）

1. なぜサーバが要らないのか

会社案内・サービス紹介・記事は「誰が見ても同じ内容」です。それなら、アクセスのたびにプログラムとデータベースでページを組み立てる理由がありません。あらかじめHTMLに書き出して、CDNに置けば済みます。

観点静的サイト＋CDNサーバで動くCMS型（WordPress等）
ページの作られ方公開前にHTMLへ書き出しておくアクセスのたびにサーバのプログラムとデータベースが組み立てる
保守するもの原稿とビルドの設定サーバ、CMS本体、プラグイン、データベースの更新
更新の方法ファイルを編集してビルドし、公開し直す管理画面から入力
向いている内容会社案内、記事、資料、手順書予約、会員機能、複数人が管理画面で更新するサイト
私の評価更新する人がファイルを触れるなら、これ一択管理画面が要る会社には正解。ただし保守の担当者を決めてから

よくあるのは、制作時に入れたWordPressとプラグインが、納品後に誰にも更新されないまま数年動いている形です。発覚の仕方はたいてい、検索結果に見覚えのないページが出る、あるいはサーバ会社から警告のメールが来る、です。静的サイトには、攻撃される管理画面もデータベースもありません。私がこの構成を選んだいちばんの理由は費用ではなく、保守するものが減ることです。

Astroの公式ドキュメントは、自らをブログ・マーケティングサイトなど「コンテンツ中心のウェブサイト」のためのフレームワークと説明しています。できる限りサーバー側でHTMLにする（Server-first）、既定ではブラウザに送るJavaScriptをゼロにする（Zero JS, by default）、動きが必要な部分だけを「アイランド」として個別に組み込める、が特徴です。

2. 実際の設定

配信：Workersの静的アセット

Cloudflareには静的サイトを置く方法が2つあります（Workersの静的アセットと、Pages）。Astro公式のデプロイガイドに「Cloudflareは新しいプロジェクトにはCloudflare Workersの利用を勧めている」との記載があるため、私はWorkersにしました。これから始める人にもWorkersを勧めます。

静的サイトだけならAstro側のアダプターは不要です（アダプターが要るのはオンデマンドレンダリングを使う場合）。このサイトの設定ファイル（wrangler）の要点はこれだけです。

{
  "name": "it-techo",
  "assets": { "directory": "./dist", "not_found_handling": "404-page" },
  "workers_dev": false,
  "routes": [{ "pattern": "it-techo.com", "custom_domain": true }]
}

公開は2つのコマンドです。

npx astro build
npx wrangler deploy

Cloudflareのドキュメントに記載されている静的アセットの主な条件は次のとおりです（取得日時点）。

項目内容
静的アセットへのリクエスト無料で無制限（Workerのスクリプトを呼ぶリクエストはWorkersの料金体系に従う）
1バージョンあたりのファイル数無料プランで20,000
1ファイルの大きさ25 MiB

会社案内のサイトでこの上限に当たるのは、動画や大きなPDFを大量に置く場合くらいです。無料枠の条件は変わるので、始める前に出典の制限ページを見てください。

公開の操作：GitHub連携を使わなかった理由

リポジトリを接続して、pushのたびに自動でビルド・公開させることもできます（Workers Builds）。私は使わず、手元のMacから直接 wrangler deploy しています。1人で運営するサイトなら、私はこちらを勧めます。理由は、外部サービスのアカウントと連携の設定が1つ減り、「いつ公開されたか」が自分のコマンド1回と必ず一致するからです。複数人で原稿を書くなら話は逆で、Git連携にして公開の経路を1本にしてください。

どちらにしても、原稿のバックアップは別に取ります。 CDNにあるのは書き出した結果だけで、原稿ではありません。

独自ドメイン：DNSの手作業はなかった

Workersで独自ドメイン（Custom Domain）を割り当てる条件は、そのドメインがCloudflare上で有効なゾーンになっている（ネームサーバーをCloudflareに向けている）ことです。割り当てると、DNSレコードの作成と証明書の発行はCloudflareが行います。

このサイトではドメインをCloudflare Registrarで取ったので、最初からこの条件を満たしていました。上の設定ファイルの routes に1行書いてデプロイしただけで、DNSの画面は一度も開いていません。

すでに別の会社でドメインとメールを使っている場合は事情が違います。ネームサーバーをCloudflareへ移すなら、MXレコードとSPF・DKIM・DMARCのTXTレコードを移行先に漏れなく登録してからです。ここを飛ばすとメールが止まります。DNSにCAAレコードを設定している場合は、Cloudflareによる証明書の発行が許可されていないと、割り当てに失敗します。

→ サーバを乗り換えたらメールが止まった、を防ぐ。引っ越しはこの順番で動かす

連絡用メール：Email Routing

連絡先のアドレスは Cloudflare Email Routing で作りました。無償で、受信専用の転送です。届いたメールを普段の受信箱へ回します。有効にすると、MX・SPF・DKIMのレコードは自動で入りました。

受信専用という点は割り切りが要ります。このアドレスを差出人にして送る機能はありません。取引先と日常的にやり取りするアドレスが要る会社は、グループウェアのメールを契約してください。問い合わせの受け口としてなら、これで足ります。

3. つまずいた点（実際の記録）

① 「常にHTTPSを使用」は既定でOFFだった。 公開直後、http:// で始まるURLを開くと、httpsへ転送されずにそのまま200が返っていました。証明書は自動で入るので、httpsで開けば鍵マークは出ます。だから気づきにくい。Cloudflareの管理画面で「常にHTTPSを使用」をONにして、httpが301でhttpsへ転送されることを確認しました。公開したら、次の1行を必ず打ってください。

curl -I http://自分のドメイン/

1行目が 301、location: が https:// で始まっていれば正常です。200 が返ったら設定がOFFのままです。

ONにした後の当サイトの出力です（2026-09-20。見たい3行だけを grep で抜き出しています）。

lab$ curl -sI http://it-techo.com/ | grep -i -E "^(HTTP|location|server)"
HTTP/1.1 301 Moved Permanently
Location: https://it-techo.com/
Server: cloudflare

② 特定のドメイン名だけ、購入画面で空き確認のエラーが続いた。 最初に決めていた名前は、Cloudflareの購入画面で「空き確認ができない」という表示が続き、買えませんでした。登録管理元（レジストリ）の情報では未登録のままだったので、名前が取られていたわけではありません。時間をおいても変わらず、別の名前にしたら一度で通りました。原因は分かっていません。私の判断は「待たずに名前を変える」でした。名刺や印刷物にドメインを刷る前なら、名前にこだわって数日止まるより先へ進むほうが得です。逆に言えば、印刷物より先にドメインを買ってください。

4. この構成が向かない場面

正直に書きます。次のどれかに当たるなら、この構成だけでは足りません。

  • 問い合わせフォームの送信先が要る。 静的サイトにはフォームの内容を受け取るプログラムがありません。このサイトはメールアドレスの掲載で済ませています。フォームが必須なら、外部のフォームサービスを埋め込むか、Workerのスクリプトを書くことになり、「保守するものが無い」という利点が削れます。
  • 予約・会員ログイン・決済を自分のサイト内に持ちたい。 静的では無理です。専用のサービスを別に契約して、サイトからはリンクで送るのが現実的です。
  • 更新する人がMarkdownを書けない。 これがいちばん多い脱落理由です。社長や事務の方が管理画面からお知らせを書きたい会社に、この構成を入れるのは勧めません。作った人が辞めた日から、誰も更新できないサイトになります。

5. WordPressを選ぶべき会社

次の条件に2つ以上当たるなら、私はWordPressとレンタルサーバーを勧めます。

  1. 更新の担当者が複数いて、管理画面から入力したい
  2. 週に何度も更新する（お知らせ、入荷、ブログ）
  3. 近くに頼める制作会社があり、その会社がWordPressで作る
  4. 本体とプラグインの更新を毎月やる担当者を、社内か外注で決められる

4が決められないなら、WordPressもやめたほうがいい。更新されないWordPressは、サーバ代よりずっと高くつきます。その場合はサイト作成サービス（管理画面つきで、保守は事業者側が行うもの）のほうが安全です。

サーバを借りると決めた会社は、選ぶ条件をこちらに書きました。

→ 事業用のレンタルサーバ、結局どれにする？ 元インフラエンジニアが見る5つの点と、私の選び方

料金の目安（取得日 2026-09-20）

このサイトで実際にかかっている費用です。

部品このサイトで使っているもの費用
サイトの生成Astro（原稿はMarkdown。公開前に全ページをHTMLへ書き出す）0円
配信Cloudflare Workers の静的アセット0円
公開の操作手元のMacから wrangler のコマンドで直接アップロード（GitHub連携は使っていない）0円
ドメインCloudflare Registrar で取得した .com年 $10.46（2026-09-20 の実際の購入額）
連絡用メールCloudflare Email Routing（受信専用の転送）0円
  • 配信が0円なのは、Cloudflareのドキュメントが静的アセットへのリクエストを無料・無制限としているためです（Static Assets: Billing and Limitations）。無料プランの上限は2節の表のとおりです。
  • ドメイン代は購入時の実額で、ドル建てです。更新時の額は変わることがあります。
  • 無料枠の条件は事業者の判断で変わります。私がこの構成を勧めるのは「いま無料だから」ではなく、6節の表の8のとおり、条件が変わっても書き出したHTMLをそのまま別の場所へ移せるからです。

6. 手順と確認表

  1. 下の表の1〜3で「静的で足りるか」を判定する
  2. ドメインを取る（これだけが継続費用になる）
  3. 手元でサイトを作り、npx astro build で dist が出ることを確認する
  4. 設定ファイルに assets.directory と routes を書き、npx wrangler deploy で公開する
  5. 独自ドメインで表示を確認し、curl -I http://… で301を確認する
  6. 問い合わせ手段を決める（メールアドレスの掲載、外部のフォームサービス等）
#確認すること判定
1全員に同じ内容を見せるページが中心かはい→静的で可
2予約・会員ログイン・決済を自分のサイト内に持つ必要があるかはい→静的だけでは不足
3更新する人はファイル編集とコマンドの操作ができるか（または覚える意思があるか）いいえ→管理画面のあるCMS型
4ファイル数・1ファイルの大きさは上限に収まるか（動画や大きなPDF）公式の制限ページで確認
5同じドメインのメールのDNSレコードを控えたかネームサーバー移行前に必須
6「常にHTTPSを使用」をONにし、httpが301で転送されるのを確認したか公開当日
7原稿のバックアップがあるかホスティングを替えても再公開できる状態か
8無料枠の条件が変わったときの移行先を想定しているかdist は他の静的ホスティングにもそのまま置ける

8は気休めではありません。書き出したHTMLはどこにでも置けます。特定の事業者に縛られないことが、無料枠に乗るときの保険です。

出典（取得日: 2026-09-20）

この記事は特定の製品の使用レビューではありません。公式仕様と公的情報をもとに整理しています。 ・仕様の取得日