ハクソク

世界を動かす技術を、日本語で。

Jeffgeerling.comがHugoに移行しました

2026年1月4日原文(jeffgeerling.com)

概要

  • Drupal から Hugo への移行理由と経緯
  • 静的サイトジェネレーター（ SSG）の選定理由
  • Markdown 中心の執筆ワークフローの利便性
  • 大規模CMSのメンテナンス負担と課題
  • 今後の課題（コメント機能・検索機能）

DrupalからHugoへの移行経緯

  • 2009年から Drupal を使用、バージョン6から10まで段階的にアップグレード
  • 本業でも同じCMSを使い続けていたため、サイトでの「 dogfooding」を実施
  • Drupal 7から8への移行が特に大変で、個人ブログに エンタープライズ向けDXP を維持するモチベーション低下
  • ブログは趣味・メモ・YouTube動画の補足用であり、複雑なCMS管理に時間を割きたくない現状

静的サイトジェネレーター（SSG）の選定理由

  • 他の趣味サイトでは 静的ホスティング を活用
    • 更新停止サイトはスクレイピングしてアーカイブ化
    • 継続運用したいサイトは Jekyll や Hugo へ移行
  • Jekyllは GitHub Pages での無料ホスティングに最適
  • Ruby非習得のため、 Hugo を自前インフラ向けに選択（Geerling Engineering等）
  • Hugoはセットアップが簡単で高速

サイト移行と運用課題

  • GitHub issueで移行作業を進行中
  • 画像参照ミスや古いURLの消失リスク
  • 20年分・3500件超の投稿データ移行の困難
  • 可能な限り既存URL維持やリダイレクト追加を試みるが、完全な移行は困難

Markdown中心のワークフロー

  • 2020年以降、全投稿を Markdown で執筆

  • それ以前も Sublime Text でMarkdown下書き→HTML化して投稿

  • HugoはMarkdownを ネイティブサポート しており、執筆体験が向上

  • Drupal 6時代は30個以上のモジュールを導入したが、アップグレードのたびに問題発生

  • Drupal 8以降は機能を最小限に絞った結果、コンテンツ作成体験が悪化

    • Markdownファイルで記事作成
    • Drupalで新規記事作成・Markdown貼り付け・タイトル追加
    • 画像を個別アップロードし、本文内に1枚ずつ挿入
    • 投稿日時フィールドを手動で調整
    • 公開設定を切り替えて保存
    • AnsibleでDrupal/Nginx/Cloudflareキャッシュを手動パージ
    • これらの作業が執筆や創造性に寄与せず、単なる手間

  • Drupalには自動化モジュールも存在するが、モジュールの安定化・パッチ管理に疲弊

  • メジャーバージョンアップごとに WYSIWYGエディタ・メディア管理・コンテンツフィールド 等の再構築が必要だった過去

Hugo運用のシンプルさ

  • 元々Markdownで執筆しているため、Hugoでは 1ステップ で公開可能
  • 投稿のfrontmatterで日付・ドラフト設定を変更するだけ
  • コマンド一発（hugo && git commit -m "Updated post." && git push）で即時公開
  • Composer・Drush・PHP・MariaDB・Nginx・Cloudflare 等の複雑な管理から解放
  • 複数ユーザー・RBAC等が必要な大規模サイトならDrupalも有効だが、個人ブログには不向き

今後の課題（TODOs）

  • 当面は コメント機能 が全サイトで未実装（後日、自前静的コメントシステム導入予定）
  • コメント欄はモデレーション負担があるものの、ブログの一体感に不可欠
  • サイト内検索 機能も未実装、過去はApache Solrと連携していたが現在は未導入
  • Hugoでの検索機能実装方法を検討中

Hackerたちの意見

ずいぶん前に、管理サービスのsvbtleからHugoに移行したんだけど、正直言って後悔してる。市販のテーマを使うことにしたんだけど、あまりニーズに合わなくて、結局フォークしちゃった。Hugoはユーザーランドが結構壊れることが多いし、私の持ってる複雑なテーマはメンテナンスがめっちゃ大変。ほんとに、めっちゃね。今は修正するための時間を正当化できなくて、投稿も全然してない。サイトすらコンパイルできないし。理論的には古いバージョンのHugoを使うこともできるけど、いつ壊れたのか全然わからないから、どこまで遡ればいいのかもわからない。だから、アドバイスとしては、サイトを生成するのに使ったバイナリをソース管理に提出しておくこと。gitはバイナリファイルにはあんまり向いてないけど、いつか感謝されると思うよ。

└

CI設定でバージョンを指定するのはどう？ [0] あと、動作するバージョンをバイナリサーチで探せること知ってる？ 0.154.0、0.77.0、0.115.0…（自分も一度やったことある） [0]: https://github.com/oslc-op/website/blob/9b63c72dbb28c2d3733c...

└

徐々に気づいてきたんだけど、更新しなくてもいいソフトウェアってあるよね。静的サイトジェネレーターは、入力をコントロールして、出力が静的ファイルの塊なら、セキュリティの問題はほぼないと思う。新しいバージョンに必要な機能が含まれてない限り、古いバージョンを永遠に使っても全然大丈夫。サイトがビルドするSSGのバージョンをメモしておくか（ソース管理にコミットしてもいいし）、そのまま人生を進めればいいんだ。OSやCPUアーキテクチャがあまり変わらなければ動くし（最悪の場合、必要な条件をエミュレートする技術はあると思うし）、すでに「完成」してるソフトウェアもあるから、更新する必要はないんだよね。

└

理論的には古いバージョンのHugoを使うこともできるけど、いつ壊れたのか全然わからないから、どこまで遡ればいいのかもわからない。 同じ問題を抱えてた。バイナリサーチが最近のトリックだね。SSGの場合、すべてがうまくいってるならアップグレードする意味はあまりないし、計画的な移行がこの場合はいいと思う。HugoのバージョンをHTMLコメントに印刷して、gitで追跡することもできるよ。

└

最近、Hugoのブログテーマを更新したら壊れちゃって、全く新しいテーマに移行しなきゃいけなかったんだ。めっちゃ面倒だった。これからは多分、更新しないと思う。

└

市販のバイナリを使うなら、${project}/bin/にそのバイナリを置いて、.gitignoreに追加して、README.mdやインストールスクリプトにダウンロードURLを記載して、プロジェクト全体のSHA256SUMSファイル（またはB3SUMSなど）にチェックサムをコミットすればいいよ。Git LFSのローファイ版みたいな感じ。

└

AIが管理するカスタムサイトジェネレーターに移行したんだけど、これが自分の使い方にはぴったり。全てを完全にコントロールできるし、何も壊れないから安心。

└

私も似たような問題があったけど、Jekyllでね。カスタマイズしたテーマがあって、途中のアップデートで全てが壊れちゃった。だから、静的サイトジェネレーターを更新する必要がないっていう兄弟コメントにはすごく同意するよ。これはHugoだけの話じゃないしね。残念ながら、私のサイトはGitHubでホスティングされてたから、アップデートに関しては本当に選択肢がなかったんだ。（ピン留めが助けになったかは分からないけど。）

└

これ、何回か痛い目にあったから、今はHugoのバイナリをソース管理してる。壊れないバージョンを見つけるために、リリースをちょっと掘り下げる必要があったよ。

└

だから、アドバイスとしては、サイトを生成するのに使ったバイナリをソース管理に提出しておくことだね。gitはバイナリファイルに最適じゃないけど、いつか感謝することになると思うよ。全バイナリは必要ないから、go run github.com/gohugoio/hugo@vX.Y.Z "$@"をhugo.shみたいなスクリプトに入れてソース管理に置いて、それをHugoのバイナリの代わりに実行すればいい。Goをインストールする必要があるけど、すごく後方互換性があるから、新しいGoバージョンにアップデートしても古いHugoバージョンが壊れることはまずないよ。

└

同じ問題があって、今はHugoのテーマシステムと戦うより、自分が必要な機能を持った静的サイトジェネレーターをVibe Engineerで作った方が簡単かなって考えてる。サイトに必要なものは結構シンプルだから、正直言ってカスタムビルドの方がいいかもしれない。もし壊れたら、鏡を見て犯人を探せばいいしね =)

面白いね。今、HugoからZolaに移行しようとしてるんだ。個人的には、Zolaの設定やテンプレートオプションの方がHugoより理解しやすい気がする。

Hacker Newsで議論の続きを見る