不動産ブログはHugoとWordPressのどちらで作るべきか？3サイト自動運用の実データで比較

不動産ブログを始めるとき、多くの人が最初に迷うのが「HugoとWordPressのどちらを使うか」です。

一般的な比較では、次のように説明されます。

• 初心者でも更新しやすいWordPress
• 表示が速く、セキュリティ面で有利なHugo

しかし、記事を継続的に収益化したいなら、管理画面の使いやすさや表示速度だけでは判断できません。実務で重要になるのは、記事の生成から品質確認、公開、修正までを無理なく運用できるかどうかです。

私は現在、HugoとPaperModを使った3サイトの共通運用を行っています。そのうち不動産サイトはCloudflare Pagesで配信しています。

本記事では、この運用で実際に発生した次のデータを基に、HugoとWordPressを比較します。

• 2026年7月16日、記事生成には成功したが、品質評価が2/8となり公開を停止
• 別の処理では、記事生成が240秒でタイムアウト
• 同じテーマを約15分間隔で再試行し、4回目に生成成功
• Hugo＋PaperModで3サイトを共通運用
• 不動産サイトはCloudflare Pagesで配信

結論を先に言うと、判断基準は次のとおりです。

編集者が管理画面から頻繁に記事を修正するならWordPress、検証済みの記事を機械的に積み上げるならHugoが向いています。

ただし、Hugoを使えば完全放置できるわけではありません。物件情報の鮮度、法令や広告表示、誤情報、問い合わせ対応には、人間による監視が必要です。

HugoとWordPressの違いは「記事の作り方」より「運用構造」にある

WordPressは、サーバー上のプログラムとデータベースを使ってページを生成するCMSです。管理画面にログインし、ブラウザ上で記事を書いたり、画像を登録したり、プラグインを追加したりできます。

一方、Hugoは静的サイトジェネレーターです。Markdownなどで書いた原稿から、公開用のHTMLファイルを事前に生成します。生成されたファイルをCloudflare Pagesなどへ配置して配信します。

両者の違いを、運用面から整理すると次のようになります。

重要なのは、Hugoが常に優れているわけでも、WordPressが時代遅れなわけでもないことです。

「誰が、どのように、何本の記事を、どこまで自動化して運用するか」によって最適解は変わります。

実運用で分かったこと：生成成功と公開成功は別物

AIを使った記事運用では、「文章を生成できた」というだけでは公開できません。

実際に2026年7月16日の運用では、記事生成処理そのものには成功したものの、品質評価が2/8となり、公開を停止しました。

この結果は、システム障害ではありません。品質ゲートが意図どおり機能し、基準を満たさない記事を止めた結果です。

自動公開の処理は、少なくとも次の段階に分けて考える必要があります。

テーマ選定
  ↓
情報収集
  ↓
記事生成
  ↓
構文・品質・事実確認
  ↓
公開可否の判定
  ↓
Hugoビルド
  ↓
デプロイ
  ↓
公開後の表示確認

この工程を一つの「記事作成処理」として扱うと、失敗時の原因が分からなくなります。

たとえば、次の三つは別の問題です。

1. AIが記事を生成できなかった
2. 記事は生成できたが品質基準を満たさなかった
3. 記事は合格したがビルドやデプロイに失敗した

今回確認できた2/8という結果は、2番目に当たります。

Hugoは、合格したMarkdownだけをリポジトリへ追加し、ビルドと公開へ進める構成を作りやすいのが強みです。一方、WordPressでもAPIや下書き状態を使えば同様の品質ゲートを構築できますが、公開状態、認証、プラグイン、APIエラーなど、管理する対象は増えます。

240秒のタイムアウトと4回目の成功から見える運用課題

同じ日の別処理では、記事生成が240秒でタイムアウトしました。

さらに、同じテーマを約15分間隔で再試行した結果、4回目に生成へ成功しています。

ここで注意したいのは、「4回目に成功したから問題ない」と判断しないことです。生成AIや外部APIを使う処理では、一時的な混雑や通信状況によって再試行が必要になることがあります。しかし、無制限の再試行はコスト増加や重複公開につながります。

実務では、次の制御が必要です。

1. 再試行回数に上限を設ける

たとえば、最大3回または4回までと決めます。上限を超えた場合は自動公開を諦め、運営者へ通知します。

2. 再試行の間隔を空ける

直後に連続実行すると、同じ障害に再び当たる可能性があります。待機時間を段階的に延ばす方法もあります。

1回目の失敗 → 5分待つ
2回目の失敗 → 15分待つ
3回目の失敗 → 30分待つ

3. 同じ記事を重複公開しない

テーマ名だけでなく、記事IDや実行IDを保存し、すでに公開済みかを確認します。タイムアウト後も外部側では処理が完了している可能性があるためです。

4. 失敗理由を工程別に記録する

最低限、次の項目をログへ残します。

{
  "article_id": "example-property-tax-20260716",
  "started_at": "2026-07-16T09:00:00+09:00",
  "stage": "generation",
  "attempt": 3,
  "timeout_seconds": 240,
  "generation_succeeded": false,
  "quality_score": null,
  "published": false,
  "error_type": "timeout"
}

品質評価で停止した場合は、同じログ形式でstageをquality_checkにし、評価点と不合格理由を残します。

この記録がなければ、「AIが失敗した」「Hugoが止まった」といった曖昧な説明しかできません。工程を分けて記録することで、プロンプトを直すべきか、タイムアウト設定を見直すべきか、配信環境を調べるべきかを判断できます。

不動産ブログでHugoが向いているケース

Hugoは、次の条件に当てはまる運営者に向いています。

• 定型化した記事を継続的に公開する
• 複数サイトでテーマや部品を共通化したい
• MarkdownやGitを扱える
• 問い合わせや会員機能を外部サービスで補える
• 公開前に機械的な品質確認を行いたい
• 公開済みページを頻繁には書き換えない

私の環境では、HugoとPaperModを使って3サイトを共通運用しています。

この構成の利点は、サイトごとに同じ修正を繰り返さず、テーマや設定をコードとして管理しやすいことです。たとえば、記事下の注意書き、計測タグ、構造化データ、共通ナビゲーションなどをテンプレート側で統一できます。

不動産サイトをCloudflare Pagesで配信しているため、記事の公開処理も次のように分離できます。

合格したMarkdownを保存
  ↓
Gitリポジトリへ反映
  ↓
HugoでHTMLを生成
  ↓
Cloudflare Pagesへデプロイ
  ↓
公開URLを確認

この構造では、原稿、テンプレート、公開履歴をGit上で追跡できます。問題のある変更が入ったときに、どの差分が原因だったかを調べやすい点も実務上の利点です。

WordPressを選んだほうがよいケース

次の条件に当てはまるなら、WordPressのほうが現実的です。

• ブラウザの管理画面から記事を編集したい
• 複数の編集者や外部ライターが参加する
• 公開後も頻繁に文章や画像を修正する
• 問い合わせ、会員、予約などの機能が必要
• Gitやコマンド操作を運営者に求められない
• プラグインを使って短期間で機能を追加したい

不動産ブログでは、公開後の修正頻度を過小評価できません。

価格、募集状況、金利、補助制度、税制、交通情報などは変わる可能性があります。編集担当者が管理画面からすぐに直す必要があるなら、WordPressの操作性は大きな強みです。

また、外部ライターに記事作成を依頼する場合も、MarkdownファイルとGit操作を教えるより、権限を制限したWordPressアカウントを発行するほうが運用しやすいケースがあります。

ただし、プラグインを増やせば増やすほど安全になるわけではありません。本体、テーマ、プラグインの更新確認、バックアップ、脆弱性対応、互換性確認などの保守が必要です。

収益化ではCMSより「更新責任の設計」が重要

HugoとWordPressのどちらを選んでも、CMSだけで収益は発生しません。

不動産ブログの主な収益導線には、次のようなものがあります。

• 不動産会社への送客
• 査定サービスや住宅ローンの紹介
• 投資用不動産や管理会社の比較
• 有料レポートや地域分析の販売
• 自社サービスへの問い合わせ
• 広告掲載

このとき重要なのは、記事ごとに「誰が、いつ、何を更新するか」を決めることです。

たとえば、記事に次の管理情報を持たせます。

reviewed_at: 2026-07-16
review_due: 2026-10-16
risk_level: high
source_owner: editorial
requires_human_review: true

法令、税金、金利、補助制度、物件価格などを扱う記事は、更新リスクを高く設定します。一方、用語解説など比較的変化しにくい記事は、確認間隔を長くできます。

CMS選定よりも、この更新責任を設計できているかどうかのほうが、長期的な信頼性と収益性に影響します。

「完全自動化」を勧めない理由

Hugoと生成AIを組み合わせれば、記事作成から公開までの多くを自動化できます。しかし、不動産分野での完全放置は推奨できません。

少なくとも、次の項目は監視対象にすべきです。

物件情報の鮮度

掲載時には正しかった価格や募集状況が、公開後に変わる可能性があります。更新日と確認日を明記し、古い情報を検出できる仕組みが必要です。

法令・広告表示

不動産広告には表示上のルールがあります。AIが生成した表現をそのまま使うのではなく、誇大表現、断定表現、根拠のない優位性などを確認する必要があります。

誤情報と出典

地域情報、相場、税制、交通所要時間などは、出典と確認日を記録します。根拠が確認できない数値は、削除するか、推定であることを明示します。

問い合わせ管理

記事が自動公開されても、読者からの問い合わせは自動的に解決しません。個人情報の取り扱い、返信期限、営業担当への引き継ぎを別途設計する必要があります。

公開後の表示確認

ビルド成功と、読者が正常に閲覧できることは同じではありません。公開URLのHTTPステータス、タイトル、画像、内部リンク、問い合わせ導線などを確認します。

初心者向け：迷ったときの選び方

初めて不動産ブログを作るなら、次の順番で判断してください。

ステップ1：記事を更新する人を決める

自分だけが更新し、GitやMarkdownを学べるならHugoを候補にできます。

営業担当者、外部ライター、事務担当者など複数人が更新するなら、WordPressから始めるほうが無理がありません。

ステップ2：必要な機能を書き出す

次の機能が本当に必要かを確認します。

• 問い合わせフォーム
• 物件検索
• 会員登録
• メール配信
• 予約
• 複数人での承認
• 公開予約
• 記事の自動生成
• 公開前の品質評価

管理画面中心の機能が多ければWordPress、記事生成と配信の自動化が中心ならHugoが有力です。

ステップ3：まず10記事で試す

最初から数百記事の自動公開を目指さず、10記事程度で運用を試します。

確認する項目は次のとおりです。

• 1記事の作成にかかった時間
• 修正にかかった時間
• 公開失敗の回数
• 品質基準で停止した回数
• 更新期限を守れたか
• 問い合わせ導線が機能したか
• 運営者以外でも修正できたか

ステップ4：公開前の停止条件を決める

自動化する場合は、「何点なら公開するか」だけでなく、次の停止条件を決めます。

• 出典がない数値を含む
• 対象地域や制度の確認日がない
• タイトルと本文の内容が一致しない
• Markdownのリンクや見出しが壊れている
• 禁止表現を含む
• 生成処理が規定時間を超えた
• 同じテーマの記事がすでに存在する

ステップ5：失敗通知を設定する

自動化は、成功通知より失敗通知の設計が重要です。

通知には、最低でも次の情報を含めます。

• 記事ID
• 失敗した工程
• 試行回数
• エラー内容
• 品質評価
• 公開の有無
• 次に人間が行う作業

現時点で断定できないこと

今回確認できたのは、Hugo＋PaperModによる3サイトの共通運用、Cloudflare Pagesでの配信、品質評価による公開停止、240秒のタイムアウト、約15分間隔の再試行と4回目の生成成功です。

一方、次の点は統一条件で計測していません。

• Hugo版とWordPress版のLCP
• Hugo版とWordPress版のINP
• 同一記事・同一画像・同一アクセス条件での表示速度
• 月間保守時間の差
• 障害率や復旧時間の差
• CMSの違いによる成約率の差

したがって、「Hugoに変えれば表示速度が何秒改善する」「収益が何％増える」といった数値は断定できません。

比較するなら、同じ記事、同じ画像、同じ計測地域、同じ端末条件を用意し、PageSpeed Insightsや実ユーザーデータなどで継続的に測る必要があります。今回の判断は速度の優劣ではなく、運用工程と障害点の違いに基づいています。

結論：CMSではなく、運用する人と公開工程で選ぶ

HugoとWordPressの選択は、単純な性能比較では決められません。

• 編集者が管理画面から頻繁に更新するならWordPress
• 検証済み記事をGit経由で機械的に積み上げるならHugo
• 会員、予約、複雑な検索などを短期間で導入するならWordPress
• 複数サイトの構成をコードとして統一するならHugo

実運用では、記事生成に成功しても、品質評価2/8で公開を止めることがあります。生成が240秒でタイムアウトし、約15分間隔で再試行して4回目に成功することもあります。

つまり、自動化で本当に設計すべきなのは「成功したときの公開手順」だけではありません。

失敗を検出し、危険な記事を止め、原因を記録し、人間が復旧できる仕組みまで含めて自動化する必要があります。

これから始める人は、まず更新担当者と必要機能を決め、10記事で小さく検証してください。そのうえで、管理画面中心ならWordPress、品質ゲートと自動配信中心ならHugoを選ぶのが、最も失敗の少ない進め方です。