Jeffgeerling.com、Hugoへ移行

 (jeffgeerling.com)
2 ポイント 投稿者 GN⁺ 2026-01-06 | 1件のコメント | WhatsAppで共有
  • 2009年からDrupalベースで運営されてきた JeffGeerling.com が、個人ブログの効率化のため**Hugo静的サイトジェネレーター（SSG）**へ移行
  • Drupal 6 から 10 まで続いた数多くのアップグレードと保守負担が移行の主なきっかけ
  • Hugo はMarkdownベースの執筆をサポートし、従来の複雑な投稿手順を簡素化、投稿・デプロイの工程をコマンド1行で処理可能
  • 移行作業では画像リンクの不具合、URLの欠落など一部の問題が発生する可能性があり、コメント機能と検索機能は今後の段階で復元予定
  • 個人開発者に簡潔なワークフローと保守効率を提供する事例として、静的サイト移行の実質的な利点を示している

DrupalからHugoへの移行背景

  • サイトは2009年にDrupal 6で始まり、7、8、9、10へと段階的にアップグレードしてきた
    • 10年以上にわたり職業上利用してきた CMS を個人ブログにも適用していた
  • Drupal 7 から 8 への複雑なアップグレード過程を経て、個人ブログで企業向け**Digital Experience Platform（DXP）**を維持することへの疲れが蓄積
  • ブログは個人プロジェクトと YouTube コンテンツの補助的な場として使われており、CMS の保守より執筆に集中するため移行を決定

Hugoを選んだ理由

  • 過去に趣味サイトを静的ホスティングへ移した経験があり、一部はJekyllまたはHugoへ変換していた
  • Jekyll は GitHub Pages 向きだが、Ruby の専門家ではない立場からHugo の簡単な設定と高速性を好んだ
  • Hugo はMarkdownを標準サポートしており、既存の執筆スタイルと自然に連携できる

移行作業と問題点

  • 移行作業は GitHub issue #158 で進行中
  • 約3,500件以上の投稿と20年分のデータがあるため、一部で画像破損、リンクエラー、リダイレクト漏れが起こる可能性がある
  • 可能な限り既存の URL 構造を維持するか、リダイレクトを追加するよう努めている

Markdownベースのワークフロー改善

  • 2020年からすべての投稿をMarkdownで執筆
    • 以前は Sublime Text で Markdown を書いた後、HTML に変換して Drupal に手動アップロードしていた
  • Drupal では投稿作成時に多段階の手順が必要
    • 本文の貼り付け、画像の個別アップロードと挿入、公開日の修正、キャッシュのクリアなど
    • DDoS 対応のためのCloudflare キャッシュ管理まで含まれ、手順は複雑だった
  • Hugo では Markdown ファイルを書いた後、hugo && git commit && git push コマンドで即時公開が可能
  • Composer、Drush、PHP、MariaDB、Nginx などサーバー管理の負担がなくなり、保守効率が向上

今後の計画（TODOs）

  • コメント機能は第2段階でセルフホストの静的コメントシステムとして復元予定
  • サイト検索機能は過去に Apache Solr ベースだったが、現在は停止中
    • Hugo 内での検索実装方法を issue #168 で検討中
  • 移行初期はコメントが無効化されており、移行作業には時間がかかる見込み

移行の意味

  • Drupal の複雑なコンテンツ作成・管理構造から離れ、シンプルで効率的な静的サイト運用モデルへ移行
  • 個人開発者に保守負担の軽減と創作へ集中できる環境を提供する実例
  • Hugo ベースへの移行は個人ブログ運営の持続可能性を高める方向として評価できる

関連記事

1件のコメント

 
GN⁺ 2026-01-06
Hacker Newsのコメント

  • 数年前、自分の個人サイトを自作のCommon Lispベースの静的サイトジェネレーターへ移行した。
    当初は850行程度だったが、今では1500行ほどに増え、ブログ記事、ゲストブック、コメントページ、タグ別RSSフィードなど、ほぼすべてを静的にレンダリングしている。
    すべてのコードとHTML、CSSを自分の手で書くことで美的コントロールを維持でき、新機能の追加も速い。
    たとえば「バックリンク」ページの追加も、40行ほどのCLコードと15分で十分だった。
    今では非常に安定しており、ほとんど手を入れる必要がなく、執筆だけに集中できている。

    • 自分のような性格だと、セルフホストのブログは問題だった。
      ブログエンジンをいじることに時間を使い切ってしまい、結局記事を書かなくなった。
      そのため、あえて自由度の低いホスティングソリューションに戻った。今は執筆だけに集中できている。
    • 私も単一目的の静的サイトジェネレーターの自由さと安定性が気に入っている。
      以前はTclssgという公開プロジェクトを運営していて、ユーザーからのフィードバックのおかげでドキュメント整備や機能追加もかなり進んだ。
      ただ、公開プロジェクトなので思い通りに構造を変えにくかった。
      今は自分のサイト専用のPython（900行）+ Pandoc Lua（700行）で構成したジェネレーターを使っている。
      技術的な変遷は自分のサイトにまとめてある。
    • 私も同じことをした。自分のサイトtaoofmac.comをHyへ移植し、その後Pythonで書き直した。
      今はTypeScript/Bunで再構築しているが、今でもLISPっぽい要素が残っている。
      SQLiteとHTMLパースを内蔵し、ネイティブにコンパイルされる軽量なLISP/Scheme方言を探している。
      関連情報はここにまとめている。
    • 私も同じことをしたが、Goでサイトジェネレーターを実装した。
      何年経っても1秒以内にサイト全体をビルドできる。
      RSSフィードやコードハイライト機能も自分で実装し、ChromaとBlackfridayを使っている。
      Hugoも試したが複雑すぎたので、自分で実装した。
    • 静的ブログでコメントをどう処理しているのか気になる。

  • 以前svbtleからHugoへ移行したが、正直後悔している。
    テーマをフォークしたが、Hugoが頻繁に壊れるので保守に時間がかかりすぎる。
    今ではサイトがまったくビルドできない。
    助言すると、サイトをビルドするバイナリのバージョンもソース管理に一緒に入れておいたほうがいい。

    • 一部のソフトウェアは、そもそも更新する必要がないのだと気づいた。
      静的サイトジェネレーターはセキュリティ問題がほとんどないので、必要な機能がないのでなければ古いバージョンのまま使ってよい。
      OSやCPUが大きく変わらない限り問題ない。
    • CI設定でバージョンを明示すればよい。
      私もこの設定を参考にしてバージョンを固定した。
      動くバージョンを探すときは二分探索で見つけるのが効率的だ。
    • 私はカスタムDockerイメージで解決した。
      ローカルとCIの両方で同じHugoバージョンを使うので、問題が起きようがない。
    • 既製バイナリを使う場合は${project}/bin/に入れ、.gitignoreに追加したうえで、チェックサムをSHA256SUMSファイルに記録すればよい。
      Git LFSの簡易版のようなやり方だ。
    • 私もJekyllで同じ問題を経験した。
      新しいコンピューターへ移るときにバージョン合わせが怖く、結局PHPへ移植中だがまだ未完成だ。

  • Markdownで記事を書く人なら、Hugoへの移行は合理的だ。
    私も500本を超えるJekyllの記事をHugoへ移したが、テンプレート構文がいちばん大変だった。
    それでも全体としては得るものが大きかった。
    移行プロセスと自動変換スクリプトはブログ記事にまとめている。

    • なぜJekyllからHugoへ移行したのか気になる。Jekyllでも十分満足している。

  • SSGは静的サイトには向いているが、インタラクションが必要な場合はサーバーが必要になる。
    どうせサーバーを動かすなら、Markdownを動的にレンダリングするほうが単純だ。
    結局SSGは依存関係や壊れる要素を増やすだけだ。
    Jeffは後でコメントのような機能を追加しようとして後悔しそうだ。
    個人的にはSSRベースのシンプルなサーバーのほうが現実的な解法だと思う。

    • しかし訪問者やボットが増えると、サーバーが落ちる可能性もある。
      静的ページにはそうしたリスクがなく、トラフィックの大半は読み取り専用だ。
      Jeffもコメント機能をIssueで自作しようとしているようだ。
    • 私もセルフホスト型の解析ツールとコメントシステムを自分で運用している。
      Drupal時代よりコード規模ははるかに小さく、単純だ。
    • 静的サイトジェネレーターはむしろ依存関係を減らす方向だ。
    • 私は静的ページはSSGで、コメントはCommon Lisp + Hunchentootサーバーで処理している。
    • 私もサイトをSSGへ切り替えたが、まったく後悔していない。むしろシンプルであるほどよい。

  • SSGを選ぶときの意思決定プロセスが気になる。
    Hugo、Eleventy、Jekyllなど主要ツールが多く、Hugoは特に互換性破壊が多い。
    古いプロジェクトなら、もう少し安定性が保証されるべきだと思う。

    • 実際、Hugoはv0.146でテンプレートシステムを全面刷新した。
      そのせいで自分のブログのビルドが壊れ、ドキュメントもまだ完全には更新されていない。
      変更自体は構わないが、ドキュメントが追いついていないのが問題だ。

  • 最近のPelicanはどうなのか気になる。Python界隈ではHugoとPelicanが二大勢力のように見える。
    RSSよりもActivityPub統合のほうが魅力的に見えることもある。

    • Pelicanを使っていて満足している。
      以前はNikolaを使っていたが、依存関係が多すぎて増分ビルドの不整合の問題があった。
      Pelicanはシンプルさを保っているのがよい。
    • 私もPelicanを何年も使っている。
      ドキュメントは90%ほど完成している感じで細部は不足しているが、基本機能だけ使うなら素晴らしい。
    • Pelicanに自作プラグインをいくつも付けて使っている。
      毎月コミットがあるので、プロジェクトは生きている。
    • Pythonを知っているなら、Pelicanがいちばん自然な選択だ。

  • 今、HugoからZolaへ移行しようとしている。
    Zolaの設定やテンプレートのほうがずっと直感的に感じる。

    • 私もJekyllからZolaへ移行したが、まったく後悔していない。
      GitHub Actionsでビルドとデプロイを自動化している。
    • 要件が多くないなら、Zola + gistの組み合わせはシンプルで相性がよい。

  • 3年間Hugoを使っている。
    学んだのは、テーマはフォークして自分で管理すべきだということだ。
    サブモジュールは避け、更新はゆっくり行うのがよい。
    コメント機能はいまだに難しそうだ。

    • その通り。テーマは結局サイトごとに異なる。
      私もDrupalテーマを移植しようとして諦めた。
      サブモジュールより、直接取り込んで必要な部分だけオーバーライドするほうがよいと思う。

  • 去年Hugoでブログを始めたが、18本の記事のうち3/4でビルドエラーに悩まされた。
    あまりに不安定でがっかりした。

    • 私もHugoから自作Python SSGへ移行した。
      Hugo流に慣れるより、自分が知っている言語で素早く実装するほうがずっと楽だった。

  • 以前シンプルなSSGを自作したことがあるが、最近もう少し体系だったものを探して11tyを試した。
    しかしLiquidテンプレートがあまりにも扱いづらかった。
    JSXベースのテンプレートを使いたかったが、11tyはそれを難しくしている。
    NextJSのSSGは機能は多いが複雑すぎて、やりすぎに感じる。
    Tempestのようなフレームワーク上にカスタムSSGを作ることも検討している。

    • EleventyはMustacheのような古典的テンプレート言語もサポートしている。
      私もPunchベースのサイトをEleventyへ移行し、ビルド速度さえ問題なければHugoよりよいと感じた。
      今はAstroで作り直した。
    • うちのスタートアップのマーケティングサイトをNextJSからAstroへ移行したが、とても満足している。
      静的中心だが、必要な場合はバックエンドロジックも使える。
      NextJSはシンプルなサイトに対して複雑すぎた。