AIでブログはほぼ無料にできる？｜CloudflareでWordPressなし運用を選ぶ前に知っておきたいこと

「ブログのサーバー代を減らしたい」

そんな人にとって、CloudflareとAIコーディングツールを組み合わせたブログ運営は魅力的に映ります。実際、シンプルな静的サイトなら、独自ドメイン以外の固定費をほとんどかけずに公開することも可能です。

ただし、ここで見落としやすいのが、Cloudflareで作るブログは、WordPressを安いサーバーへ載せ替えたものではないという点です。

WordPressでは、記事を書く管理画面、画像管理、カテゴリー、予約投稿、コメント、検索、プラグインなどがひとまとまりになっています。一方、Cloudflareを使った静的ブログでは、それらをコード、Git、外部サービス、AIなどで組み直します。

つまり、削減できるのは主にサーバー費用です。その代わり、制作・更新・保守の方法は大きく変わります。

結論から言えば、新規の小規模ブログや技術学習用サイトには有力な選択肢ですが、すべての初心者や既存WordPressブログに適した方法ではありません。

結論｜判断基準は「作れるか」ではなく「運用を続けられるか」
1. Cloudflareで作るブログの仕組み
2. 2026年時点では「Next.js＋Pages」が唯一の正解ではない
「ほぼ無料」の正確な意味と静的ブログのメリット
初心者がつまずきやすいポイントとAIの安全設計
SEOとWordPress移行で誤解しやすいこと
Cloudflare静的ブログが向く人・WordPressを選んだ方がよい人
初心者が安全に試す手順
まとめ｜安さではなく、記事を継続できる構成を選ぶ
1. 参考にした公式資料

結論｜判断基準は「作れるか」ではなく「運用を続けられるか」

AIコーディングツールを使えば、プログラミング経験が少ない人でも、ブログのひな型を作って公開するところまでは進みやすくなりました。

しかし、ブログ運営では公開後の作業の方が長く続きます。

記事を追加する
画像を差し替える
デザインを修正する
リンク切れを直す
フレームワークを更新する
ビルドエラーを解決する
検索やフォームの不具合を調べる
問題が起きたときに元へ戻す

最初の1回をAIに作ってもらえたとしても、その後の更新や復旧を毎回AI任せにする設計では、利用制限や障害、サービス変更が起きた瞬間に作業が止まります。

選ぶ基準は「数時間で公開できるか」ではなく、半年後にエラーが出たとき、自分で状況を確認し、AIへ必要な情報を渡し、直ったかどうかを判断できるかです。

ここに不安がある場合は、いきなり本番ブログを置き換えるより、練習用サイトから始めた方が安全です。

Cloudflareで作るブログの仕組み

Cloudflareを使ったブログでは、一般に次のような流れで記事が公開されます。

MarkdownやCMSで記事を書く → サイトをHTML等へ変換する → Gitへ保存する → Cloudflareへ公開する

主な役割を整理すると、次のようになります。

MarkdownやCMS、ビルド、Git、Cloudflare、AIの役割を整理した表

AIは重要な支援役ですが、ブログを動かす必須部品ではありません。AIが使えないと更新できない状態ではなく、最終的にはGitに保存されたファイルと公開手順が残る設計を目指します。

2026年時点では「Next.js＋Pages」が唯一の正解ではない

Cloudflareの現在の公式ドキュメントでは、静的書き出しを行うNext.jsサイトはPagesへ公開できます。ただしCloudflareは、Next.jsでは特定の静的書き出し用途を除き、Workersを推奨しています。サーバー側処理を使うフルスタックのNext.jsは、WorkersとOpenNextアダプターを使う案内です。

CloudflareはPagesからWorkersへの移行手順も公開しています。動的機能を追加する予定があるなら、最初からWorkersを含めて比較した方がよい状況です。

また、記事中心のサイトなら、必ずしもNext.jsを選ぶ必要はありません。たとえばAstroは、MarkdownやMDXの記事を扱え、共通の構造を持つブログ記事をコンテンツコレクションとして管理できます。

大切なのは、AIが最初に提案した構成をそのまま採用することではありません。

記事中心なのか
会員機能が必要なのか
ブラウザ上で執筆したいのか
複数人で更新するのか
将来どこまで機能を増やすのか

これらを決めてから、構成を選ぶ必要があります。

「ほぼ無料」の正確な意味と静的ブログのメリット

Cloudflare Pagesでは、Functionsを呼び出さない静的ファイルへのリクエストは無料かつ無制限と案内されています。一方、フォーム処理や認証などでPages Functionsを使った場合は、Workersの利用枠として計算されます。

無料プランには、2026年8月17日時点で、月500回のビルド、同時ビルド1件、1サイト20,000ファイル、1ファイル25MiBなどの上限があります。

そのため、「Cloudflareなら何を作っても完全無料」ではありません。

シンプルな個人ブログなら無料枠内に収まりやすい一方、画像やファイルが大量にあるサイト、頻繁に自動ビルドするサイト、動的処理が多いサイトでは、別のサービスや有料枠が必要になる可能性があります。

独自ドメイン代は残る

独自ドメインを使う場合、登録・更新費用は必要です。金額はドメインの種類や時期によって異なるため、「毎年必ず約1,600円」などと固定して考えることはできません。

Cloudflare Registrarは、レジストリとICANNが設定した費用に上乗せしない方式を採用していますが、元となる価格自体は変わる可能性があります。

サーバー代以外に発生し得る費用

構成によっては、次の費用も発生します。

AIコーディングツールの利用料
ブラウザから記事を書くためのヘッドレスCMS
問い合わせフォームやメール送信サービス
コメント機能
サイト内検索
大容量画像や動画の保存
アクセス監視やエラー通知
有料テーマやデザイン素材
技術者への相談費用

したがって、正確な表現は「サーバー代が必ず無料になる」ではなく、静的サイトの公開基盤を無料枠で運用できる場合があるです。

固定費を抑えやすい

記事と画像を中心とした静的サイトなら、サーバーの月額契約を持たずに運用できる可能性があります。

特に、複数の小規模サイトを試したい人や、アクセス数がまだ少ない検証段階のサイトでは、固定費を抑えられるメリットは大きいでしょう。

ただし、削減できた金額だけでなく、更新や保守に増えた時間も含めて判断する必要があります。

表示を速くしやすい

静的サイトは、あらかじめ作成されたHTMLや画像などを配信します。アクセスのたびにデータベースからページを組み立てる必要がないため、構成をシンプルにしやすく、表示速度も安定させやすい方式です。

もっとも、静的サイトにすれば自動的に高速になるわけではありません。大きすぎる画像、不要なJavaScript、外部広告や計測タグを大量に読み込めば、表示は遅くなります。

変更履歴とプレビューを残しやすい

GitHubとCloudflareを連携すると、変更をGitへ送るたびに自動でビルドできます。本番サイトとは別のプレビューURLを作り、公開前に変更内容を確認することもできます。

Cloudflare Pagesには、過去に正常公開されたバージョンへ戻すロールバック機能もあります。

WordPressでもバックアップやステージング環境を用意できますが、静的サイトでは変更履歴と公開物をGit中心に整理しやすい点が特徴です。

公開面の攻撃対象を減らしやすい

公開サイトにWordPress管理画面、PHP、データベース、プラグインを置かない構成なら、それらに由来する攻撃対象は減らせます。

ただし、「静的サイトだから安全」「Cloudflareだから万全」という意味ではありません。

GitHubアカウントの乗っ取り
Cloudflareアカウントの乗っ取り
DNS設定の誤変更
APIキーの流出
外部ライブラリの脆弱性
AIが生成した危険なコード
フォームや認証機能の設計ミス

こうしたリスクは残ります。

初心者がつまずきやすいポイントとAIの安全設計

記事公開が「執筆」ではなく「開発作業」になる

WordPressでは、管理画面で文章を書き、公開ボタンを押せば記事を更新できます。

MarkdownとGitを使う構成では、一般に次の工程が必要です。

記事ファイルを作る
タイトルや公開日などの情報を入力する
画像を決められた場所へ置く
ローカル環境で表示を確認する
Gitへ変更を記録する
GitHubへ送る
ビルド結果を確認する
本番サイトを確認する

AIに一連の操作を任せることはできますが、途中でエラーが出た場合に、どの段階で失敗したのかを判断する必要があります。

記事を書く頻度が高い人にとっては、毎月のサーバー代よりも、更新手順の複雑さの方が大きな負担になることがあります。

WordPressの標準機能がそのまま使えない

静的ブログには、WordPressのような動的機能が最初からそろっているわけではありません。

たとえば次の機能は、別途実装または外部サービスとの連携が必要です。

問い合わせフォーム
コメント
サイト内検索
会員登録
ログイン
限定記事
商品の購入
人気記事ランキング
関連記事
予約投稿
複数人での編集
画像管理画面

Cloudflare Pages Functionsを使えばフォームや認証などを追加できますが、その時点でサイトは単純な静的ファイル配信だけではなくなります。動的処理にはWorkersの仕組みと利用枠が関係します。

AIへの「安全ルール」は事故防止を保証しない

AIコーディングツールへ、あらかじめセキュリティルールを渡しておくこと自体は有効です。

ただし、指示ファイルを書けば事故を完全に防げるわけではありません。

Claude Codeの公式ドキュメントでも、CLAUDE.mdはプロジェクトの進め方を伝えるガイドであり、セキュリティ境界には権限設定やフックを使うよう案内されています。公式のセキュリティ案内でも、提案されたコードやコマンドを承認前に確認する責任は利用者にあるとされています。

外部から取得した内容にはプロンプトインジェクションの可能性もあるため、重要なコマンドや設定変更は承認前に確認しなければなりません。

安全性を高めるには、次のように複数の対策を組み合わせます。

まず計画だけ作らせ、すぐ変更させない
ファイルの差分を確認する
本番へ直接変更しない
プレビュー環境で検証する
DNS、課金、削除、公開は個別承認にする
危険な自動承認モードを通常環境で使わない
戻し方を決めてから変更する

「不安ならAIに安全か聞く」だけでは不十分です。AI自身が見落としている問題は、同じAIに尋ねても発見できないことがあります。

Privateリポジトリでも秘密情報は入れない

GitHubリポジトリをPrivateにするのは、個人ブログでは妥当な初期設定です。しかし、PrivateだからAPIキーやパスワードを保存してよいわけではありません。

秘密情報はソースコードや設定ファイルへ直接書かず、CloudflareのSecretsなどへ保存します。Cloudflareも、平文の環境変数やWrangler設定に機密情報を置かず、Secretsを使うよう案内しています。

GitHubには、認証情報を含む変更を送信前に検出するPush protectionもあります。ただし、検出できる情報や利用条件には限界があるため、これだけに依存はできません。

SEOとWordPress移行で誤解しやすいこと

SEOはWordPressとCloudflareのどちらが有利なのか

静的サイトは表示を速くしやすいため、ユーザー体験の改善にはつながります。GoogleもCore Web Vitalsなどを含む良好なページ体験を推奨しています。

しかし、静的サイトだから検索順位が上がる、WordPressだから不利になる、といった公式な基準はありません。

検索で重要なのは、サイトの方式そのものよりも、次の条件です。

読者の疑問へ十分に答えている
独自の経験や情報がある
ページを検索エンジンが取得できる
内部リンクをたどれる
タイトルや見出しが内容を正しく表している
canonicalが適切である
削除・移転したURLが正しく処理されている
モバイルでも読みやすい
サイトマップが更新される
構造化データが本文と一致している

Googleは、検索エンジン向けに量産した文章ではなく、読者を中心にした有用で信頼できるコンテンツを推奨しています。

AI検索のための特別な裏技も必要ない

2026年に公開されたGoogleの生成AI検索向け公式ガイドでも、AI OverviewsやAI Modeへ表示されるために、特別なAEO・GEO対策へ切り替える必要はないと説明されています。

基本となるのは、従来のSEOと同じく、価値のある内容、クロール可能なページ、正確な技術設定です。Google検索への掲載を目的とした特別なAI用テキストファイルや専用マークアップも必要ないとされています。

したがって、Cloudflareへ移行するだけでAI検索に強くなるわけでも、WordPressを使っているからAI検索に弱くなるわけでもありません。

WordPressからの移行は「サーバー移転」ではなく「サイトの再構築」

既存のWordPressをCloudflareの静的サイトへ移す場合、単に記事ファイルをコピーするだけでは終わりません。

WordPressのREST APIから、投稿、固定ページ、カテゴリー、タグ、画像などの情報を取得することは可能です。ただし、公開記事以外のデータには認証が必要な場合があり、カスタム投稿や独自項目はREST APIへ公開されているかを個別に確認する必要があります。

実際のサイトで引き継ぐ対象は、次のように広がります。

WordPress移行で引き継ぐ記事、分類、画像、URL、SEO、動的機能などの確認表

WordPressのREST APIは、標準状態では取得件数がページ分割され、1回の取得は最大100件です。完成画面をクロールしてHTMLとして保存する方法もありますが、それは現在の見た目を複製する方法です。WordPressの編集データ、下書き、管理情報、プラグインの動作まで移行できるわけではありません。

そのため、既存WordPressの静的化は「移行」というより、記事データとURLを引き継いだ新サイトの再構築と考えた方が実態に近いでしょう。

DNS変更ではメール設定にも注意する

独自ドメインのネームサーバーをCloudflareへ変更するときは、Webサイト以外のDNSレコードも確認しなければなりません。

独自ドメインのメールを使っている場合、MX、SPF、DKIM、DMARCなどのレコードを正しく引き継がないと、メールを送受信できなくなったり、なりすまし対策が崩れたりする可能性があります。Cloudflareも、メール用の接続先をDNS onlyで扱うよう案内しています。

また、Cloudflare Pagesでルートドメインを使う場合は、そのドメインをCloudflareのゾーンとして追加し、ネームサーバーをCloudflareへ向ける必要があります。一方、blog.example.comのようなサブドメインなら、現在のDNS事業者にCNAMEを追加する方法もあります。

既存サイトを移行するなら、最初は次のいずれかで試すと安全です。

Cloudflareが発行する仮URL
新しいサブドメイン
本番とは別の練習用ドメイン

表示や機能を確認する前に、本番ドメインのDNSを切り替える必要はありません。

Cloudflare静的ブログが向く人・WordPressを選んだ方がよい人

Cloudflare静的ブログが向いている人

次の条件が多く当てはまるなら、Cloudflareを使った静的ブログは有力です。

更新する人が1人または少人数
記事と画像が中心
コメントや会員機能が不要
Markdownでの執筆に抵抗がない
Gitの最低限の仕組みを覚える意思がある
表示やリンクを自分で確認できる
デザインを細かく作り込みたい
固定費を抑えて複数サイトを試したい
技術を学ぶこと自体も目的に含まれる
問題発生時に前の状態へ戻せる

特に、ポートフォリオ、技術メモ、ドキュメント、更新頻度の低い情報サイト、キャンペーン用サイトなどとは相性がよいでしょう。

WordPressを選んだ方がよい人

次の条件が多いなら、レンタルサーバーとWordPressを使う方が、総合的には負担を抑えやすくなります。

初めてブログを運営する
記事を書くことを最優先したい
ブラウザの管理画面で更新したい
複数人で執筆する
コメントや問い合わせを簡単に管理したい
プラグインを使って機能を追加したい
技術的なエラー対応に時間を使いたくない
日本語の解説や相談先が多い方が安心
収益化や記事更新を早く軌道に乗せたい

レンタルサーバー代は、単にファイルを置く費用ではありません。

管理画面から記事を書ける環境、データベース、WordPressを動かす仕組み、サポート、設定の簡略化などに対して支払っている面があります。サーバー代を削減した結果、記事を書く時間が減るなら、事業としては逆効果です。

WordPressとCloudflareの中間案もある

「Cloudflareの速さや低コストは魅力だが、Markdownだけで記事を書くのは難しい」という場合は、中間的な構成も考えられます。

ヘッドレスCMSを使う

記事はブラウザ上のCMSで作成し、その内容をAstroやNext.jsで読み込み、Cloudflareへ公開する方法です。

執筆しやすくなる一方、CMSとの接続、ビルド通知、画像管理、プレビューなどの設定が増えます。無料枠を超えればCMSの料金も発生します。

WordPressを記事管理だけに使う

WordPressを管理画面として残し、REST APIから記事を取得してCloudflare側へ表示する「ヘッドレスWordPress」も可能です。

ただし、この方法ではWordPressのサーバー自体が必要です。構成も複雑になるため、サーバー代削減だけを目的に選ぶ方法ではありません。

初心者が安全に試す手順

まず必要な機能を決める

AIへ「ブログを作って」とだけ伝えるのではなく、先に次を決めます。

誰が記事を書くか
どのくらいの頻度で更新するか
ブラウザ上の編集画面が必要か
コメント、検索、フォームが必要か
広告やアクセス解析を使うか
将来、会員機能や商品販売を追加するか
既存サイトのURLを引き継ぐか

ここを曖昧にしたまま作り始めると、あとから構成を変更する負担が大きくなります。

本番とは別に小さな練習サイトを作る

最初から数百記事のブログを移行するのではなく、次の程度で試します。

トップページ
記事3本
カテゴリーページ
運営者情報
プライバシーポリシー
404ページ
問い合わせ導線

これだけでも、記事追加、画像配置、Git操作、ビルド、公開確認まで一通り経験できます。

実際にCodex、GitHub、Cloudflare Pagesを使って小規模サイトを公開した流れは、関連記事「プログラミング未経験でもCodexでホームページを公開できた｜副業サイト制作の全記録」でも紹介しています。

プレビューを通してから公開する

本番ブランチへ直接変更を送るのではなく、作業用ブランチやプレビュー環境で確認します。

少なくとも次を確認します。

トップページが表示される
記事とカテゴリーページが開く
画像が欠けていない
スマートフォンで横にはみ出さない
内部リンクと外部リンクが正しい
存在しないURLが適切な404になる
titleとdescriptionが設定されている
canonicalが正しい
OGP画像が表示される
サイトマップが生成される
アクセス解析が重複していない
フォームを使う場合は実際に届く

外部変更は個別に承認する

AIには、少なくとも次の操作を勝手に進めないよう指示します。

ドメイン購入
有料プランへの変更
DNS変更
本番公開
リポジトリの公開設定変更
APIキーの作成
ファイルの大量削除
旧サイトの停止
本番データの変更

指示文だけでなく、ツール側の権限設定でも制限します。

戻せる状態を残してからドメインを切り替える

既存WordPressから移行する場合は、Cloudflare側の表示確認が終わっても、旧サーバーをすぐ解約しない方が安全です。

旧サイトのバックアップを残す
現在のDNSレコードを保存する
旧URLと新URLの対応表を作る
不具合時の切り戻し手順を決める
Search Consoleで404やインデックス状況を確認する
問い合わせやメール受信を確認する

移行直後に問題が見つかった場合、一度WordPressへ戻す判断も失敗ではありません。記事制作やサイト運営を止めないことの方が重要です。

AIへ最初に渡す依頼文の例

単に「Cloudflareでブログを作って」と依頼するより、次のように条件と停止境界を伝えた方が安全です。

個人向けの情報ブログを新規設計してください。

実装を始める前に、次の3案を比較してください。
・WordPress
・Markdown中心の静的サイト
・ブラウザで編集できるCMSと静的サイトの組み合わせ

前提：
・編集者は1人
・記事と画像が中心
・週1〜2回更新
・コメントと会員機能は不要
・独自ドメインを使う
・問い合わせは外部フォームでもよい
・検索流入を想定する
・公開前プレビューとロールバックを必須にする

それぞれについて、費用、更新方法、必要な知識、
保守、セキュリティ、移行しやすさを比較してください。

構成を決めるまではコード作成、アカウント操作、
購入、DNS変更、本番公開を行わないでください。

秘密情報はコードやGitへ保存せず、
環境側のSecretsを使う設計にしてください。

この段階では、AIに作らせるのではなく、選択肢と欠点を出させることが目的です。