SSG

各SSGでのfrontmatterのまとめ はじめに 最近、HugoからAstroへブログを移行しようとしたところ、frontmatterの互換性のなさに苦しんだ。特に、Hugoでは一般的なdateフィールドが、Astroのブログテンプレートでは認識されず、代わりにpubDateを使う必要があるという仕様は、公式にも明示されておらず罠のようだった。 将来的にSSGを乗り換える人が増えてくる中で、こうした違いは深刻な移行障壁となるだろうと思い、この記事を記すことにした。 共通部分 Markdownのfrontmatterは公式仕様ではなく、SSGやCMSが独自に解釈して使っている。 通常、YAML形式（--- で囲む）で記述されるが、HugoではTOMLやJSONにも対応。 よく使われる共通フィールド：title, description, tags, draft, slug Hugo 使用できるフォーマット：TOML, YAML, JSON, org 主なフィールド： title: ページのタイトル date: 作成日（公開日） tags: タグ description: ページの説明文 draft: 下書きフラグ（trueにするとビルド対象外） aliases: 追加のURL。ここに記載したURLからもアクセス可能になる。 lastmod: 最終更新日 slug: URLパスの最後のセグメントを上書きする。 参考： hugoで使えるFront Matterについてまとめ Astro 使用できる形式：YAML（.md / .mdx の先頭に記述） 主なフィールド： title: ページのタイトル description: ページの説明文 pubDate: 公開日（※dateではなくpubDateにしないとテンプレートで無視されることがある） tags: タグ（例：["astro", "blog"]） draft: 下書きフラグ（trueで非公開、ただし自動除外にはフィルターが必要） slug: 任意のスラッグ（ファイル名とは別にURLパスを指定可能） layout: 使用するレイアウトファイルのパス（例：../layouts/BlogLayout.astro） heroImage: 記事のトップに表示される画像（任意） author: 著者名（任意） pubDateの罠について Astroではブログテンプレート（例：astro-blog, AstroPaperなど）で記事を日付順に並べる処理や日付の表示が行われているが、そこで参照されているのはdateではなくpubDateだ。 そのため、Hugoから移行してきたMarkdown資産でdateしか指定していない場合、Astroでは日付が表示されなかったり、並び順に影響が出たりする。 この仕様はAstro公式ドキュメントには明記されておらず、テンプレートの実装依存しだいだ。 移行時には必ずdateをpubDateに変換するスクリプトまたは手動対応が必要になる。 ちなみにAstroでは、公式サイトを見ても、どのようなfrontmatterが使えるかは明記されていない。せいぜい、まともに解説があったのはstarlightというテーマでの解説のみ。今後、各SSG間の移行性や互換性が問題になりそうだ。 ...

静的サイトはSDGsに貢献する｜環境と知識と技術の三方良し はじめに：Web技術と持続可能性の交差点 近年、Webサイトの構築方法として「静的サイト生成（SSG）」が注目を集めている。これは、ページを事前に生成し、サーバーへの負荷を軽減する手法だ。一方で、持続可能な開発目標（SDGs）への関心も高まっており、環境への配慮が求められている。本記事では、静的サイトがどのようにSDGsに貢献し、環境、知識、技術の三方良しを実現するかを探る。 静的サイトの環境への利点 サーバー負荷の軽減 静的サイトは、ページをビルド済みで配信するため、アクセスのたびに処理を走らせる必要がない。これは、動的生成型のPHPサイトなどと対照的であり、サーバーの消費電力や負荷を大幅に軽減できる。サーバー台数の削減にもつながるため、結果的にCO₂排出の削減に貢献する。 CDNとの相性の良さ SSGはCDNとの親和性が高く、ユーザーの地理的位置に応じた効率的な配信が可能になる。データ転送の効率化により、ネットワーク全体の負荷とエネルギー消費を抑えられる。 知識の持続可能な共有 長期的なアクセス性の確保 動的CMSやデータベースベースのWikiは、サービス終了やデータベース障害に弱い。一方、静的サイトはMarkdownなどのプレーンファイルとして手元に保管でき、WebページもHTMLとしてそのまま保管できる。これにより、知識資産の長期保存が可能となる。 検索性とリンク性の向上 静的サイトでは、意味のあるURL（例：/dictionary/torque）を付けることができ、検索エンジンや人間にとっても扱いやすい。これは知識を引用・展開するうえで非常に重要であり、学術・教育サイトにとっては死活問題である。 技術的な利点と持続可能性 セキュリティの向上 動的サイトはサーバーサイドで処理が発生するため、XSSやSQLインジェクションなどの攻撃リスクがある。SSGは基本的にHTML配信のみなので、攻撃面が極端に少ない。これは保守性にも直結する。 メンテナンスと運用コスト 構成がシンプルなため、開発者・編集者にとっても扱いやすい。更新もローカルで行い、Gitで管理するようにすれば、チームでの共同編集も安全かつ再現性の高いものになる。 世の中的な動きとエビデンス Google：Core Web Vitalsの導入 Googleは検索ランキングにおいて「Core Web Vitals（LCP, FID, CLS）」といったWeb表示性能指標を導入しており、軽量かつ高速なサイトは明確に優遇されている。 参考：Google Search Central Blog – Core Web Vitals 将来への展望：Webサービスとエネルギー効率の評価へ 現時点では、Webサイトのエネルギー効率やCO₂排出量を評価する制度が浸透していないように思える。しかし、現在の社会ではすでに、サプライチェーン全体でのCO₂排出量算出や削減の取り組みが物質分野・エネルギー分野で加速している。 その中で、Webサービスにおける無駄なサーバー稼働による電力消費が評価の対象外であることは、いずれ問題視されるだろう。静的サイトへの移行は、この点でも社会的に評価される流れが生まれる可能性がある。 いまはまだ広く認知されていないが、将来的には「エネルギー効率の良いWeb設計」が、調達基準や社会的評価の対象になるかもしれない。 静的サイト運用の必要性を、実際の公共系サイトの構成から問題提起した例として、以下の記事も参照してほしい。というか、この記事のアイディアは、以下記事を書いている際に思い付くに至った。 日本機械学会の機械工学事典と「PHPの残念さ」について 結論：静的にしていくことは“正しさ”である 静的サイトは、単に「高速で安全」なだけでなく、環境負荷を減らし、知識の流通と保存を支える技術である。将来的に社会がこの方向に進まざるを得ないのは、「大衆が馬鹿じゃなければ」必然の流れだ。 技術者として、情報発信者として、静的にすることは正義である。