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

エレヴェンティの終わり

2026年4月12日原文(brennan.day)

概要

  • Font AwesomeBuild Awesome という新プロジェクトをKickstarterで発表し、資金調達目標を即達成
  • Build Awesome11ty/Eleventy のリブランディングであり、Eleventyの終焉を意味
  • 静的サイトジェネレーター(SSG)の歴史と現状、商業化の難しさを解説
  • オープンソースと収益化の矛盾、開発者コミュニティの不安や反発
  • 他開発者の声や、筆者自身の立場・代替案も紹介

Build Awesomeと11tyのリブランディング問題

  • Font Awesome が新プロジェクト Build Awesome をKickstarterで発表、目標額を1日で達成
  • Build Awesome は実質的に 11ty/Eleventy のリブランディング、Eleventyの終焉を示唆
  • 筆者自身 も11ty利用者・支援者として強い関心と不安を抱く現状

静的サイトジェネレーター(SSG)の歴史と意義

  • ウェブ黎明期は 静的HTML が主流、後にCGIやPHP等で動的化
  • WordPress などCMSが普及し、インターネットの43%を支配
  • 近年は Jekyll (2008)、 Hugo (2013)、 Gatsby (2015)、 Eleventy (2017)などSSGが再評価
  • SSGのメリット: 高速性・セキュリティ・シンプルな運用
  • テンプレート言語やMarkdownで構成されるフォルダをビルドし、完全な静的サイトを生成

11ty/Eleventyの特徴と開発経緯

  • Zach Leatherman がJekyllに触発されて開発、Node.jsエコシステムを活用
  • 柔軟性JavaScript活用クライアントサイドフレームワーク非依存 が特徴
  • 複数テンプレートエンジン(Liquid, Nunjucks, Markdown, Handlebars, EJS)をサポート
  • NASA, CERN, W3C, Google, Microsoft, Mozilla など著名組織も利用
  • LeathermanはNetlifyからFont Awesomeに移籍、2026年にBuild Awesomeへ移行

SSGの商業化とJamstackブーム

  • Jamstack (JavaScript, APIs, Markup)という概念でSSG商業化の波
  • GatsbyNext.js はVC資金で急成長、クラウドサービスで収益化を狙う
  • Gatsby CloudやStackbitなどは最終的に Netlifyに吸収・終了
  • Netlify/Vercel の戦略は「SSGを餌に有料インフラへ誘導」、SSG自体の収益化は困難

オープンソース開発の持続可能性問題

  • Leathermanは オープンソースの持続可能性 をポッドキャストで語る
  • 広く使われるプロジェクトの維持は 個人負担が大きく、燃え尽きやすい
  • VC的な急成長志向はオープンソース文化と相性が悪い
  • Font Awesomeは「堅実な技術と持続可能性」を共有する企業として選択

Build Awesomeの課題と懸念

  • Build Awesomeは「 ノーコード編集」「 ビジュアル編集」「 有料テンプレート」などを売りに
  • これは過去に StackbitNetlifyCMS が試みて失敗したモデル
  • 静的サイトを作る層は 無料のIDEやターミナル を好み、商用CMSには興味が薄い
  • 本来のユーザー層 を無視し、誰のためのプロダクトか不明瞭

オルタナティブなアプローチと筆者の体験

  • Build Awesomeが本当にSSGユーザー層(NeoCities等)にリーチしていない現状
  • IndieWebや愛好家コミュニティとの断絶
  • Build Awesomeの方向性は「コーポレート感・商業主義」が強く、創作的趣味の領域を侵食
  • 筆者自身も「 Berry House」という非営利・低価格モデルでSSG活用を推進
  • 既存の商用Webは SquarespaceやWordPress で十分、SSGは本質的に別の哲学を持つ

収益化の矛盾と今後への提言

  • SSGやオープンソースの収益化は 過去何度も失敗、根本的に矛盾を含む
  • 高品質ツール開発よりも「 なぜSSGが必要か」「どう伝えるか」という 哲学的アプローチ が必要
  • 非技術者層への本質的な魅力訴求・教育が課題

開発者コミュニティの声

  • 11tyだけに興味がある。Build Awesomeは自分のターゲットではない」(Michael Harley)
  • 資源豊富な企業がリブランディングのためにKickstarter?違和感がある」(Ben Overmyer)
  • この世に良いものは残らない」(Grigør)
  • 最初はワクワクしたが、今は不安の方が大きい。もし方向性が合わなくなったら、今あるバージョンを使い続ける」等、複雑な心境

まとめ

  • Build Awesomeのリブランディングは、既存ユーザーや開発者コミュニティから不安と反発を招いている現状
  • SSGの収益化は過去にもうまくいっておらず、根本的な哲学の再考が必要
  • オープンソースの持続可能性と、ユーザー本位の開発姿勢への回帰が求められる

Hackerたちの意見

SSGとWordPressの戦いは意外と続いてるね…ネット上にWordPressを使ってるサイトがこんなにあるなんて、びっくりだよ。PHPで毎回ページビューごとに動的にマークアップを組み立てて、ハッキングのリスクを抱えてるのに、ページ数がたったの7ページとか100ページとか。そんなの、ゴミみたいなノートパソコンや小さなEC2インスタンスでも、8秒くらいでHTMLファイルにプリレンダリングできるのに。本当に大丈夫だよ。定期的に更新する人たちには、サイト全体を静的にエクスポートできる安くていいWPプラグインもあるし、実際のWPをIP制限でファイアウォールして、S3とかから公開サイトをホストすればいいんだ。

WordPressには以下の機能があるよ:

  • 投稿のスケジュール設定
  • たくさんのプラグイン
  • 使い方を知ってる人が多い
  • 使いやすいWYSIWYGインターフェース 俺の知る限り、ほとんどのSSGはこれらのどれかでつまずいてる。

アイロニックなことに、WordPressが人気になった大きな理由の一つはそのダイナミックな性質だったんだよね。Movable Typeを打倒したんだけど、あれは非常に強力で拡張性のある静的サイトジェネレーターだった。この記事のタイムラインにはMovable Typeのことが全く触れられてないのが信じられないし、ある時点で「静的の完全な歴史:WordPressヘッドレスへの始まり」という別の著者の投稿にリンクしてるけど、そこでもMovable Typeには触れてない。なんか年を感じるわ :/

最近、WordPressから全部のウェブサイトを移行したんだ。ここ数年、いくつかのサイトがプラグインの脆弱性でハッキングされたこともあったし。あれ以降は「セキュリティ」プラグインを使ったら問題はなくなったけど、やっぱり... 自分のウェブサイトをクローリングして、各ページをダウンロードしてマークダウンに変換して、静的サイトジェネレーター(JavaScriptでカスタム)を使ってCloudflare Pagesで無料で運営してる。ダウンタイムも「料金」もなし。結果を見たいなら: https://aretecodex.pages.dev/guides/recomposition いくつかの問題があって、コンテンツを編集するために「画像ペースト」プラグインを使わなきゃいけなくて、.vscodeのプロジェクト設定でそのベースディレクトリや画像パスを設定しなきゃいけない。コメントやアップボート機能がなくなっちゃったし、「検索」機能も失った。

僕にとって、WordPressのインストールが提供するのはGUIなんだ。何人かの人のWordPressインストールを手伝ったことがあって、プライベートなWordPressインストールを設定した後、ウェブサイトを静的にミラーリングするスクリプトを実行してる。これはちょっとハッキーだけど、プライベートなWordPressインストールを隠しておけば、アップデートを気にしなくて済む。WordPressほど素敵なWYSIWYGインターフェースを持ってる静的ジェネレーターは見つけられなかったな。

マーケティング部門がWordPressの代わりにSSGを使うための実行可能なワークフローってあるのかな? - WYSIWYGエディタは必須だよね。マーケティングの人たちは、一度僕が反応しないMacbookでps -eafを実行してた時、ハッキングしてると思ったみたい。 - 彼らは投稿に画像を「入れる」んだ。画像を「アップロードしてCSSで位置を調整する」わけじゃない。 - マーケティング部門だから、いろんな機能が必要なんだよね。少なくともトラッキングは必須で、最大限の機能はエンジニアとしてはあまり良いことを言えないようなマイナーな統合プラグイン。ソーシャル統合や「あなたにもおすすめ」セクションも思い浮かぶ。 > 安いWPプラグインが、サイト全体を静的にFTPやS3にエクスポートするから、実際のWPをIP制限の後ろにファイアウォールで守って、実際の公開サイトをS3などからホストできるんだ。WPの経験はあまりないけど、実際に野良で使われてる信頼できるプラグインを挙げられない限り、これがそんなに簡単だとは思えない。まず、あなたが説明したのは非常に基本的なデータパイプラインで、誰かがサポートしてメンテナンスしなきゃいけない。経験から言うと、プラグインは他のプラグインとうまく連携しないこともあるし。昔、非常にシンプルな個人サイトをWPからエクスポートしようとしたら、脚注が全部めちゃくちゃになってた(今はわからないけど、その時はプラグインで脚注を管理してた)。

クライアントのサイトをHugoで始めたんだけど、2日以内に30分ごとに何かを編集してた(ちょっと誇張だけど)。彼らは編集できるものが欲しかったんだ。Markdownは使わないし、URLを手動で書くこともしない。画像を投稿やページにドラッグ&ドロップしたいんだ。だから、さようならHugo。

WYSIWYG付きのSSGを探している人には、Publiiをおすすめしたいな。ユーザーとしての立場しかないけど、もっと多くの人に知ってほしい。

WordPressから静的サイトジェネレーターに切り替えたら、自動投稿の習慣が崩れちゃった。WordPressはメンテしなくてよかったし、使うのも考えなくて済んだ。でも、切り替えたのは事実だよ。

WordpressはSSGのセットアップの一部になれるよ - 対立するものじゃない。

本当にネット上でWordpressを使ってるサイトの多さに驚いてる。PHPで毎ページビューごとに動的にマークアップを組み立ててるのが不思議だ。静的サイトについて不思議に思うのは、たった1つのファイルを更新するだけなのに、どうしてすべてを再生成する必要があるのかってこと。今、もし自分の書き方がTwitterやMastodon、Blueskyのような小さなメモだと想像してみて。そういうパターンでいくつもメモが溜まっていくと、最終的には何千ものメモになる。各メモにページが必要なの?理想的にはそうだよね。リンクできるべきだし。でも、メモを追加するたびに何千ページも再生成するのは意味があるのかな?わからない。それから、すべての集約ページも考えてみて。例えば、すべてのメモのページネーションリストとか、異なるカテゴリやタグで分けたメモのページネーションリストとか。これでどれだけページが増えるの?それに、すべての静的アセットが毎回ビルド時にソースから出力ディレクトリにコピーされるし。もちろん、コメントもね。静的サイトにはコメントがない。わからないな。自分のサイトエンジンを作ることに投資した人、例えばJeremy Keith(https://adactio.com/)は一番いい状況だと思う。

SSGのことなんだけど、実際に必要な機能ってほんの一部なんだよね。だから、HTMLのリンク用のシンプルな構文を覚える代わりに、Markdownのマニュアルを毎回調べないといけないような、変で不規則なものがある。個人サイトをSSGで始めようとするたびに、醜いテーマが何百もあって気が滅入るし、謎のクソみたいなクラウド側のビルドシステムにもイライラするし、カスタマイズすることを考えるだけで気が重くなる。だから、実験を始めても終わらず、6ヶ月後にまた挑戦して失敗するって感じ。UFOから落ちてきたみたいなランディングページが本当に必要だったときは、Vite-Reactで作ったよ。セマンティックコンポーネントを使うのが楽しくて、「Earth Day Parade Ithaca Commons」って書くだけで、distファイルをS3にアップロードするシンプルなPythonスクリプトができたし(「GitHubアクションで何が間違ったの?」ってこともない)、Cloudfrontを無効化して、メタデータを抽出して、メタデータデータベースを維持することもできた。将来的にやりたいことを正確に実現するための明確な道筋があって、SSGのように6ヶ月後に大きな変更をしようとしたときにゼロから学び直さなきゃいけないわけじゃないし、週末に立ち上げてユーザーの前に出せたんだ。つまり、SSGには商業的な可能性がないんだよ。SSGを維持・カスタマイズできる個人や組織は、必要なことを正確に実現するものをゼロから作れるから、コストや労力も少なくて済むし、成功するためには人を洗脳してそう思わせるしかないって感じ。ソフトウェアの多くの分野でこういうことは毎日起きてるけど、SSGではそうはならないと思う。あの人たちはずっと眠ったままで、DrupalやWordPressの夢を見てるんだろうね。[1] ... それに、似たようなプラットフォームに移りたいなら、"プラグイン"や"モジュール"、その他の複雑な拡張メカニズムに苦しむ代わりに、実装すればいいだけなんだ。

Hacker Newsで議論の続きを見る