認知負荷と環境の経年劣化（Bit Rot）を排除する
Posted on

HugoToZola

個人開発コーポレートサイトをHugoからZolaへ移行した理由

エンジニアとして、私たちはよく「技術の適材適所（Right tool for the job）」を説きます。しかし、その技術選定がもたらす隠れた、かつ複利的に膨らむコストを見落としがちです。それが「認知負荷（Cognitive Friction）」と「環境の経年劣化（Bit Rot）」です。

先日、私は自社のコーポレートサイト（会社ホームページ）をHugoから、Rust製のモダンな静的サイトジェネレーターであるZolaへと完全に移行しました。既存のHugoサイトも正常に動作していましたし、そもそも会社のホームページというものは、毎日あるいは毎週更新するような性質のものではありません。

ではなぜ、何の問題もなく動いていたシステムをわざわざ貴重な時間を割いてリプレイスしたのか。

理由は、「コンテキストスイッチ（文脈の切り替え）の完全な排除」と「避けて通れない依存関係の破壊的変更トラップの解消」にありました。

課題：たまにしか更新しないシステムが抱える「高い保守コスト」

半年に1回程度しか触らないシステムを運用する場合、予測可能な2つの問題が発生します。

  1. エコシステムの経年劣化（Bit Rot） Hugoは非常に強力で高速ですが、そのエコシステムの進化スピードは非常にアグレッシブです。数ヶ月のブランクを経て、ちょっとしたテキスト修正のためにリポジトリを開くと、ローカルのHugoランタイムとテーマのテンプレートがバージョンズレを起こしてビルドが通らなくなっている、という事象がほぼ毎回のように発生していました。結果として、わずか2分のテキスト修正のはずが、「ローカルバイナリのダウングレードやバージョン固定、あるいはサードパーティのテーマメンテナーが修正パッチを当てるのを待つ」という、不毛なインフラのトラブルシューティングへと化してしまっていたのです。

  2. コンテキストスイッチとテンプレート構文の摩擦 私の普段のメインスタックは、Rustによる高性能なバックエンド、およびSaaS開発です。そこではサーバーサイドのレンダリングテンプレートとしてTeraを日常的に使用しています。そのような開発サイクルの合間にHugoのリポジトリに切り替えるということは、脳のギアをGoのテンプレート構文や、Hugo特有の設計ルール（Shortcodes、Page Bundlesなど）へと強制的にシフトさせることを意味していました。

大規模な開発組織において、このような「マイクロエコシステムの断片化」は開発速度をサイレントに低下させる最大の要因となります。そして、独立して動くエンジニアにとっても、これは限られたメンタル帯域を無駄に消費するノイズでしかありませんでした。

解決策：Zola + Tera がもたらすパラダイムのシナジー

Zolaへの移行は、以下の2つの構造的な優位性によって、これらの摩擦を完全にゼロにしました。

  1. 徹底された後方互換性（Backwards Compatibility） Zolaは外部依存のない、単一のRustバイナリとして配布されています。さらに重要なのは、プロジェクト自体が安定性と後方互換性に極めて強いこだわりを持っている点です。一度Zolaでサイトを構築してコミットしてしまえば、半年後や1年後にビルドを実行しても、非推奨エラーの嵐に遭遇することなく、全く同じアウトプットが得られるという高い確信が持てます。環境マネージャーも、複雑なバージョン固定も不要です。ただ一発でビルドが通る、その安定性が担保されています。

  2. 思考のギアチェンジからの解放 Zolaが採用しているテンプレートエンジン Tera は、Jinja2やTwigに強くインスパイアされた仕様です。そのため、構文、ループ処理、マクロ、制御構造にいたるまで、私が現在進行形で構築しているRust製SaaSサービスのユーザー画面やサーバーサイドレンダリング（SSR）ビューの実装コードと完全に同一のパラダイムで書くことができます。

フロントエンドのマーケティングスタックと、本業であるバックエンド・SaaSの開発スタックを共通化（Unify）したことで、認知負荷は文字通りゼロになりました。コーポレートサイトの修正が、メインプロダクトの機能実装と全く同じマッスルメモリー（身体感覚）のまま行えるようになったのです。

運用コスト「月額0円」のモダンなデプロイ構成

この極限まで無駄を削ぎ落としたアーキテクチャに合わせて、インフラ側の運用オーバーヘッドも徹底的に自動化しています。

  • ソース管理・パイプライン： シンプルなGitHubリポジトリに、git push をトリガーとするカスタムの GitHub Actions ワークフローを結合。

  • コンパイル・配信： ワークフローが起動すると、Rust製のZolaが爆速で静的アセットをコンパイルし、そのまま GitHub Pages へとダイレクトにプッシュ。

  • ルーティング： GoDaddyで管理しているカスタムドメインから、GitHub Pagesのエッジインフラへ直接マッピング。

結果として、サーバーのパッチ当てやセキュリティ管理の手間は一切なく、ホスティング費用も完全に「月額0円」という、堅牢かつメンテナンスフリーなパイプラインが完成しました。

まとめ

技術スタックを統一することの本質は、単なる特定言語へのこだわりではなく、「自身のフォーカス（集中力）を守るため」にあります。

後方互換性を尊重するツールを選び、メインの開発言語とテンプレートのパラダイムを同期させたことで、手のかかる「定常メンテナンス作業」を、極めて低摩擦で安全な資産へと変えることができました。

その大半の期間を「待機状態」として過ごすようなプロジェクトにおいて、「壊れない安定性」と「思考の同期性」こそが、究極の機能（Feature）であると言えます。