「静的サイトジェネレーター」について網羅的に説明します

2020/04/20

2020/11/14

Jamstack SSG ウェブ用語よもやま話

今回はウェブサイト制作のためのツールである 静的サイトジェネレーター について説明します。

必ずしもプログラミングの知識を持たない方を読者と想定し、「静的サイトジェネレーターとは何ぞや」という基礎の部分から、静的サイトジェネレーターが注目を集めている背景、メリット・デメリット、使いどころ、定番の静的サイトジェネレーターライブラリまで、静的サイトジェネレーターに関するあれこれを網羅的に説明します。

記事を書くきっかけは、静的サイトジェネレーターについて説明したよい記事が Google 検索したときに上位に引っかかってこなかったことです。

世界的には静的サイトジェネレーターの利用は年々広がっており「プログラマが個人的に使うもの」から「ビジネス用途でも使われるもの」に変わってきつつある感じがします。一方、日本国内では先進諸国に比べると認知・活用ともに遅れているように感じます。

その一因は適切な知識を持った技術者がビジネスパーソンに向けて書いた静的サイトジェネレーターの説明記事があまり表に出てこないことにあるのではないかと考え、今回この記事を書こうと思いました。この記事が少しでも日本のビジネスにおける静的サイトジェネレーターの適切な活用の促進につながれば幸いです。

静的サイトジェネレーターとは

静的サイトジェネレーターとは、文字どおり静的サイトを生成するためのソフトウェアのことです。英語では Static Site Generators と書き、しばしば SSG と省略されます。今後さらに利用が広まれば CMS （コンテンツマネジメントシステム）のように略称の方が一般的になるかもしれません。

詳しくは後述しますが、静的サイトジェネレーターの有名なものとして Next.js ・ Gatsby ・ Hugo ・ NuxtJS ・ Jekyll 等があります。

正確な時期はわかりませんが、「 Static Site Generators 」という用語が使われはじめた時期は 2011 〜 2015 年頃だと考えられます。

ウェブサイト（以下「サイト」）を構築・運用するためのソフトウェアといえばいまの主流は CMS です。統計によると、世界のすべてのサイトのうちおよそ 2 つに 1 つで CMS が使われていると言われています。 CMS と静的サイトジェネレーターは何が違うのでしょうか。

細かくあげればキリが無いぐらいさまざまな違いがありますが、最も大きなのは「ウェブページを生成するタイミング」の違いです。 WordPress に代表される旧来の CMS のほとんどはウェブページの生成を「ブラウザから実際にアクセスがあったとき」に行います。一方、静的サイトジェネレーターは本番サーバーにファイルがアップロードされる前の「ビルド時」にウェブページを生成します。

「ビルド」というのは、平たく言うと「本番サーバーのファイル一式を生成する処理のこと」です（厳密にはそれだけではありませんが、ここではこの説明で十分でしょう）。このビルド処理は本番サーバー以外の環境――プログラマの開発用のマシンやビルド用のマシンで行われることが一般的です。静的サイトジェネレーターで作られたサイトは通常の静的サイトと同じく「ブラウザからアクセスがあれば該当するファイルの中身を返す」というシンプルな仕組みで動きます。

「静的サイトジェネレーター」ということばは 2011 〜 2015 年頃に生まれましたが、静的サイトジェネレーターの仕組み自体はその前から存在していました。旧来の CMS の中には「静的 CMS 」と呼ばれる部類の CMS があり、これは静的サイトジェネレーターとおおよそ同じ仕組みで動くものでした。具体的な名前をあげると、 Adobe Dreamweaver ・ Movable Type 等の CMS が一般には静的 CMS と言われています。

静的サイトジェネレーターと CMS との関係は、 CMS をどのように定義するかによって変わります。 CMS を広く「サイトを管理するためのツール全般」と定義するなら、静的サイトジェネレーターは CMS の一種です。 CMS の定義を絞って WordPress のような「リレーショナルデータベースにコンテンツを格納し動的にページを生成するもの」を指す意味で使うのであれば、静的サイトジェネレーターは CMS とは異なるツールです。どちらの定義がよい・悪いということではなく、専門家も文脈によって使い分けるものなので、「静的サイトジェネレーターは CMS なのかどうか」を明確にしようと議論してもあまり有益ではありません。

ちなみに、英語の略称である「 SSG 」はツールとしての静的サイトジェネレーターを指すこともありますが、文脈によっては Static Site Generation ――静的サイトを生成する仕組みや処理のことを指す場合もあります。

（余談ですが、筆者は「コンテンツ管理システム」「 Web サイト」のように英語と日本語が中途半端に混ざった表記より「コンテンツマネジメントシステム」「ウェブサイト」のようにカタカナで揃えられた表記を好むので、本来であれば SSG も「スタティックサイトジェネレーター」とするかそのまま「 SSG 」と書きたいところです。しかし、現状日本では「静的サイトジェネレーター」という表記が主流になっているので、本記事では「静的サイトジェネレーター」という表記で通しています。）

なぜいま静的サイトジェネレーターが注目されているのか

なぜいま静的サイトジェネレーターが注目されているのでしょうか。さまざまな理由が考えられますが、大きな理由のひとつに現在主流の CMS （＝「動的 CMS 」と呼ばれる CMS ）を利用する上での課題があげられます。

CMS を利用する際にはしばしば以下の面で課題が生じます。

セキュリティ
パフォーマンス
メンテナンス
本番サーバー

セキュリティ : CMS を使ったサイトの構築・運用には細心のセキュリティ対応が不可欠です。一度サイトを公開したら終わりではなく、構築後もセキュリティアップデートに適時対応していかなくてはなりません。セキュリティ対応に不備があると、サイトの上書きや乗っ取り、機密情報の漏洩や消失、サイト訪問者や他サイトに対する犯罪行為のための悪用等のリスクが増大します。セキュリティインシデントが発生したときには迅速な対応が必要です。アクセス数がどれだけ少ないサイトでも基本的な対策は不可欠で、 CMS を使う場合は 365 日のセキュリティ対応が基本です。

パフォーマンス : CMS で作られたサイトには静的サイトに比べて「ページ読み込みのスピードが遅い」「さばけるアクセス数が少ない」といった面でデメリットがあります。これは CMS が動的にページを生成するという性質上避けようがありません。実際にはほとんどのサイトでは CMS 導入によるパフォーマンス低下が大きな問題にはなることはありませんが、パフォーマンスはブランディングにおいても SEO においても重要になっており、特にサイトの流入数や離脱率がほんの少し変わると収益が大きく変わるようなビジネスにおいては最優先課題になることもあります。

メンテナンス : CMS で作られたサイトは公開後に継続してメンテナンスし続ける必要があります。 CMS やプラグインのセキュリティアップデートへの対応はもちろんのこと、 CMS のアップデートに伴って行う互換性チェックやバグ対応、定期バックアップ、プログラミング言語やミドルウェアのアップデート対応等も必要になります。

本番サーバー : 本番サイトを運用するためのサーバーの環境構築や入れ替えには相応の手間がかかります。 WordPress のようにメジャーな CMS の場合はデフォルトで対応しているホスティングサービスもたくさんありますが、マイナーな CMS の場合はそもそも利用できるホスティングサービスの選択肢が少ないこともあります。

CMS に伴うこれらの課題を解消したり緩和したりする方法のひとつとして近年静的サイトジェネレーターが注目を集めています。

ただし、詳しくは後述しますが、静的サイトジェネレーターは CMS の課題をすべて解決する万能ツールではありません。すべての道具がそうであるように、 CMS にも静的サイトジェネレーターにもそれぞれ「ならでは」の特長と使いどころがあります。そのため、「静的サイトジェネレーターが注目を集めている＝ CMS の未来は静的サイトジェネレーターにある」と考えるのは短絡的です。企業とチームが置かれた環境とサイトの性質によって、 CMS と静的サイトジェネレーターのどちらがよいかは変わってきます。

（余談ですが、 CMS から静的サイトジェネレーターへの乗り換え経験を語る記事の中には、「 WordPress は表示が遅すぎる」「 CMS はコスパが悪い」「 CMS は SEO 上のデメリットが多い」などと、その人がそれまで使っていた CMS をやたらと貶めるものがありますが、そのような記事を真に受けてはいけません。それらの記事は、ヒートテックを初めて着た子どもがその良さに感動して「ヒートテック以外の下着はゴミ」「すべての人類はすべての下着を捨ててヒートテックに変えるべき」などとうそぶくのと似ていて、客観性に欠けるからです。）

静的サイトジェネレーターのメリット

続いて静的サイトジェネレーターのメリットについて説明します。ただし、静的サイトジェネレーターにもいろんなタイプがあり、以下に紹介するメリットが必ずしもすべての静的サイトジェネレーターにあてはまるわけではありませんので、その点はご留意ください。

セキュリティ
パフォーマンス
メンテナンス
本番サーバー
コンテンツソース
Markdown
バックアップ
SPA

セキュリティ

静的サイトジェネレーターで作られたサイトはビルド時にすべてのページを生成するため、ブラウザからのアクセス時には動的な処理は行いません。そのため、サイト上での各種インジェクションや不正ログインの被害を受けるリスクが低いです。静的サイトジェネレーターで作られたサイトのセキュリティレベルは CMS で作られたサイトよりも静的サイトに近いものになります。

パフォーマンス

事前にページが生成されるという仕組みは、ページ読み込みスピードや大量のアクセスへの対応といったパフォーマンス面でもメリットがあります。「プログラムが動いてページを生成する」というプロセスが無い分 CMS よりも高速です。パフォーマンス上のデメリットを補うために CMS の場合はさまざまな手法を駆使する必要がありますが、静的サイトジェネレーターは CMS であらゆる対策を施した後のレベルが最初から実現できるようなものです。ちなみに、必要なサーバーリソースが少ないということから「静的サイトジェネレーターは地球にもやさしいです」と主張されることもあります（私はわずかな違いだと思います）。

メンテナンス

静的サイトジェネレータを使えばメンテナンスが必要なくなるわけではありませんが、旧来の CMS に比べるとそのメンテナンスコストは低くなる傾向が高いです。特にセキュリティに関するメンテナンスにおいて CMS の場合だと深刻度の高い脆弱性に関係するリリースがあれば数時間〜数日のうちに速やかに対応する必要がありますが、サイドジェネレーターの場合は脆弱性が重大なリスクにつながる可能性が CMS よりも低く、メンテナンスに CMS の場合ほど気を張る必要はありません。

本番サーバー

CMS の場合は、 CMS 動かすためのプログラミング言語、リレーショナルデータベース、その他関連ツールを本番サーバー上に用意する必要がありますが、静的サイトジェネレーターの場合はそれが必要ありません。代わりに静的サイトジェネレーターの場合はビルドを行うための環境が必要なのですが、本番サーバーに選べるホスティングサービスの選択肢が増えることは間違いありません。静的サイトジェネレーターは、安価なレンタルサーバーや静的ファイルのみ設置できるクラウドサービスでも利用することができます。

コンテンツソース

CMS では多くの場合コンテンツの管理にリレーショナルデータベースを使用するため、本番環境・開発環境の構築にはデータベースについての最低限の知識が必要になります。静的サイトジェネレーターの場合はリレーショナルデータベースは必ずしも必要なく、シンプルなテキストファイルでコンテンツを管理することができます。中には他サイトのウェブ API 等をコンテンツソースとして利用できるものもあります。

Markdown

CMS では WYSIWYG エディタやブロックエディタでコンテンツを編集する形が一般的ですが、静的サイトジェネレーターの場合は一般に Markdown （マークダウン）と呼ばれるかんたんな記法を使ってページを作成することができます。 Markdown は現役の職業プログラマであればおそらく 80% 以上の人が使えるプログラマにはおなじみの記法で、もし知らなくてもルールがかんたんなので少し学べばすぐに使い始められます。ただし表現力は WYSIWYG エディタやブロックエディタには及びません。

バックアップ

CMS でサイトのアーカイブ・バックアップを行うには「 CMS のコード」「アップロードファイル」「データベース」の 3 つを保存する必要があります。これらはタイミングを変えて保存すると不整合が起こることもあるので、原則同じタイミングで保存する必要があります。バックアップの中身を確認したり特定のバックアップの状態に戻したりするのには一般に手間とコストがかかります。静的サイトジェネレーターだと、コンテンツをシンプルなテキストファイルで管理できるので、 Git / GitHub 等の高機能なバージョン管理システムでコンテンツを管理することができます。これらを使えば、過去の状態の確認、特定のタイミングのスナップショットへの復元等も比較的かんたんです。

SPA

SPA とは Single Page Application の略で、単一ページで動くアプリケーションのことです。一般の方向けに平たくいえば「サイト内のページ遷移が高速なサイト」のことです。ブラウザでページ内のリンクをクリックしたときに、ページ全体のリフレッシュが起こらずに必要な部分だけが切り替わる動作をします。これはすべての静的サイトジェネレーターにあてはまる特徴ではありませんが、最近特に人気の静的サイトジェネレーターではこの SPA の機能がデフォルトで備わっているものもあります。これを旧来の CMS で実現しようとすると、相応の技術力と工数が必要になります。

静的サイトジェネレーターのデメリット・課題

次に静的サイトジェネレーターのデメリットと利用する上での課題について説明します。

プログラミング知識
動的・インタラクティブ機能
ビルド時間
後方互換性

プログラミング知識

静的サイトジェネレーターを利用するには「ターミナルが扱える」「開発環境が用意できる」等の基礎的なプログラミング知識が必要です。 CMS でも少し凝ったことをしようとするとプログラミングの知識が必要になってきますが、 CMS の場合はプログラミング知識が無い方でもサイト公開が可能です。今後静的サイトジェネレーターが広まれば状況が変わる可能性はありますが、現時点では少なくとも静的サイトジェネレーターは「プログラミングの基礎的な知識を持つ人」がいないと利用できません。

動的・インタラクティブ機能

CMS で一般的な機能に「コンタクトフォーム」「訪問者によるコメント」「アクセス制限」等の動的・インタラクティブな機能があります。静的サイトジェネレーターは静的サイトを生成するものなので、原則そのような動的機能は実現できません。サイトに動的な機能を付けたい場合は、クラウドサービスを利用したり別サイトでその機能を用意したり等といった対応が必要になります。

ビルド時間

CMS の場合は管理者が記事を投稿したらすぐにサイトに反映されることが一般的ですが、静的サイトジェネレーターの場合はビルド処理が必要な関係で、コンテンツの編集からサイトへの反映までにタイムラグが生じます。数千〜数万のコンテンツがあるサイトの場合、ビルドに数十分〜数時間もの時間がかかることもあります（これはビルド環境によるのであくまでも例です）。そのため、コンテンツが多い場合はビルド環境やワークフローに工夫が必要です。

後方互換性

これは今特に注目を集めている JavaScript の静的サイトジェネレーターに限定された特徴ですが、バージョンアップを行うと後方互換性が失われその対応に少なくない手間がかかることがあります。正確にはこれは静的サイトジェネレーターではなく JavaScript のパッケージの問題ですが、静的サイトジェネレーターを使えば対応に追われるリスクが大きいのは事実です。旧来の CMS の場合でも同様のことは起こりえますが、例えば最もよく使われる CMS である WordPress の場合後方互換性をできるかぎり保つポリシーで開発されており後方互換性の問題で利用者が悩む状況になることは比較的稀です。

メリット・デメリットについては以上です。細かいところもあげると他にもありますが、大きなところはおおよそ押さえられているのではないでしょうか。

静的サイトジェネレーターの使いどころ

メリット・デメリットに続いて「使いどころ」もご紹介します。これがすべてというわけではありませんので、あくまでも一例として参考にしてください。

プログラマの個人ブログ
技術チームのブログ
更新頻度の低いサイト
高いパフォーマンスが求められるサイト

1. プログラマの個人ブログ

プログラマが個人的なブログを作るのに使います。 CMS に比べるとセキュリティ上の心配が少なく気軽に利用することができます。多くのプログラマに馴染みの Markdown がデフォルトで使えるものが多いため、導入のコストや更新の手間も少なめです。ホスティングには安価なレンタルサーバーやクラウドサービスのフリープラン等も使えるため、出費を少しでも抑えたい人にもよいでしょう（ CMS のホスティングでもふつうは月に数百円程度ですが）。もともと静的サイトジェネレーターの多くはプログラマが使うためのものだったので、これは長々と説明するまでもありませんね。

2. 技術チームのブログ

会社のサイト全体ではなく、技術チームのブログだけに部分的に利用します。個人ブログと同じように、チームメンバーの多くが Markdown に馴染みがあればかんたんに導入できますし、ある程度放置になってもセキュリティ上のリスクが少なく安心して利用できます。 Git や GitHub に不慣れな初級プログラマがこれらの技術に慣れるためのトレーニングとしてもよいでしょう。

3. 更新頻度の低いサイト

更新頻度の低いサイトで利用します。これは特に中小企業と個人事業主にとってよい使い方だと思います。従来はサイト構築・運用といえば「静的サイトか CMS か」の二択で、少しでも更新をしたいなら静的サイトでは余計なコストがかかるということで消極的に CMS が選ばれていました。その結果として、更新がほとんど無いのに CMS が使われていてパフォーマンスの低いサイトや、保守の手間や費用を惜しまれてセキュリティホールが放置されたサイトが大量に生まれました。静的サイトジェネレーターであれば、セキュリティを CMS ほどには心配する必要なく「ときどき更新して後は放置」というスタイルで運用できます。ただし、サイトを更新したいときは都度ビルドができるプログラマに依頼する必要がありますし、コンタクトフォーム等の動的な機能を別に用意しなくてはなりません（更新はプログラマを介さなくてもよいように自動化することもできます）。静的サイトジェネレーターは静的サイトと CMS の中間の第 3 の選択肢を与えてくれます。

4. 高いパフォーマンスが求められるサイト

ページの読み込み速度等において高いパフォーマンスが求められるサイトで利用します。これは主に大企業で静的サイトジェネレーターを採用する理由になると思います。「既存の CMS でできることはやり尽くしたが、もっと高速にしたい」「 CMS で高速化を試みたが費用対効果が悪い」というときに、静的サイトジェネレーターは有望な選択肢になります。ただし、静的サイトジェネレーターにはビルド処理が必要で、コンテンツ編集からサイトへの反映までにタイムラグがあります。そのため、ラグをどこまで許容するのか、許容できない場合はどのように対策をし緩和するのかを事前に考えておかなくてはなりません。

静的サイトジェネレーターと CMS の使い分け

静的サイトジェネレーターと CMS をどのように使い分ければよいのかというポイントについて述べます。

静的サイトジェネレーターと CMS の使い分けはおおよそ次の感じで考えるとよいと思います。

メインは CMS を利用する
1 〜数ページだけのサイトや更新がほとんど発生しないサイトでは静的サイトを検討する
CMS のメリットがあまり活きないケースや CMS の保守が難しいほど予算がかぎられたケース、 CMS では実現したいことが難しいケース等で静的サイトジェネレーターを選択する

ビジネス用途のサイトに限定すると、静的サイトジェネレーターより CMS の方が利用範囲が広くなると思います。

CMS に並ぶ定番のサイト構築・運用ツールであるウェブアプリケーションフレームワークと静的サイトジェネレーターの使い分け問題もありますが、これは迷うほどのものではなくほとんどのケースで答えが明らかだと思いますので、ここでは説明しません。

尚、前提として、これはビジネスにおけるサイトの構築・運用を想定しています。個人の趣味や勉強での利用は対象にしていません（趣味や勉強の場合は単純に本人がやりたい方を選べばよいと思います）。

有名な静的サイトジェネレーターライブラリ

静的サイトジェネレーターを実際に試してみたいという方のために、記事執筆時点で有名な静的サイトジェネレーターをいくつかご紹介します。私の偏見による偏るのを防ぐため、 GitHub のスター数や Google Trends のボリュームに基づいて最も人気の高いものだけを選びました。尚利用には原則プログラミングの基礎知識が必要になるのでご注意ください。