はじめに

2016年にJamstack（ジャムスタック）という言葉が登場してから、すでに7年が経過しました。日本でも、ヘッドレスCMSとともに今もモダンなWeb開発手法として多くの会社で採用されています。

しかし、Jamstackという言葉を作ったNetlifyが運営していたJamstack Community Discordは2023年7月に閉鎖、Jamstack Confも2023は開催されず、2022で終了しました。英語圏のインターネットに目を向けるとJamstackという用語は衰退し、消滅しつつあります。

本記事では、Jamstackが流行った背景と環境の変化を紹介し、今後どのようにJamstackと付き合っていくべきか、Web開発におけるJamstackの位置づけを考察します。

あらためてJamstackとは？

現在のjamstack.orgのトップページでのJamstackの定義については曖昧な説明となっています。過去にはもう少し明確に説明されていましたが、それでもJamstackとはなにか、多くの人により議論されてきました。ピクセルグリッドでも会社サイトに「Jamstackについて解説するページ」を設け、解説しています。

公式サイトが曖昧な説明となっているので、何をJamstackと呼ぶのかという問題はありますが、この記事では昔からの定義である「静的サイトジェネレーター（SSG）を利用して静的サイトを生成し、Netlifyのようなホスティングサービスにデプロイする手法」のことをJamstackと呼びます。

補足：ピクセルグリッドサイトの説明と違う？

会社サイトのJamstackの定義を読むと、記事での定義と微妙に違うと思われた方もいるかもしれません。現在はSSGやホスティングサービスを使ったことある人が多いため、より直感的に理解しやすいよう、この記事ではJamstackを本文にある定義で説明しました。

会社のサイトで説明しているとおり、正確には「SSGを使わなければいけない」「ホスティングサービスを使わなければいけない」という定義はありません。しかし、SSGやホスティングサービスの利用により得られるメリットがそのままJamstackのメリットとされていることもあり、jamstack.orgでもSSGやホスティングサービスの利用をベストプラクティスとして推奨しているので、この説明でも概ね正しいといえるでしょう。

用語の由来と目的

Jamstackという用語を作ったのは、NetlifyのCEO、Matt Biilmannです。そのため、Jamstackという用語はNetlifyのマーケティング用語ではないかとも言われていました。

WordPressに代表されるCMSを使ったサイトでのアーキテクチャ、LAMP Stack（Linux、Apache、MySQL、PHP）に対して、SSGと静的コンテンツ（と少しのJavaScript）で構成されるサイトをJAMstack（JavaScript、API、Markup）と呼んだのが始まりです。

この静的サイト中心のJamstackのアプローチは、Core Web Vitalsがサーチエンジンに評価されるようになったこともあり、サイトの高速化を目指したエンジニアや、Webサイトのセキュリティのための手法として多くの会社が採用しました。

その後、Jamstackでも従来型のCMSのように管理画面で更新できるようにするヘッドレスCMSが普及する中で、Jamstackの言葉を使って宣伝され、広まったように思います。

また、Netlifyだけでなく、競合するホスティングサービスでもこの言葉は使われました。以下のリンクは、Cloudflare Pagesが登場時のブログエントリです。

• Cloudflare Pagesの紹介：JAMstack Webサイトを構築するための最良の方法

JAMstackという表記 JAMstackのJAMが大文字なのは以前の公式表記です。変更された経緯は過去の記事のコラムでも書いていますので気になるようなら参照してください。

Cloudflare Pagesの登場時は静的コンテンツしか公開できず、JAMstackプラットフォームを名乗っていました。現在はPages functionsが追加され、AstroのSSRモードやRemixのようなフルスタックフレームワークのサポートも行われるようになりました。

現在（2023年12月中旬）でも公式サイトでは「JAMstack platform」の記述で紹介されています。

ピクセルグリッドでもNetlifyによる用語と認識しつつも、WordPressのような従来型のCMSではない作り方の説明として、Jamstackという言葉を、会社のコピーなど多くの場面で使ってきました。

Netlifyも「Netlify = Jamstack」ではなく、アーキテクチャを説明する独立した用語として認知されるよう、努力していたように思います。

Jamstackと世の中のツールへの影響

Jamstackが流行ったことも関係してか、多くのツールで静的サイトとして書き出す機能が追加されました。SSRのツールであったNext.jsでも静的サイトが書き出せるようになりました。

• Rendering: Static Site Generation (SSG) | Next.js

よりWebサイトらしいコンテンツ中心のWebサイトが作れる新しいツールのAstroはSSGとして始まりました。

これらのフレームワークがJamstackのためと公式に謳っていたわけではありませんが、Jamstackでサイトを開発・Web制作していた人たちに響くものであったといえます。

Jamstackの問題

Jamstackは基本的には静的なコンテンツで構成できる、コーポレートサイト、ドキュメントサイトなどのWebサイトに向いた手法です。

Webアプリケーションを作ることもできますが、動的で事前に出力することが難しいコンテンツが多いのであれば、静的サイトとして構成するJamstackは向いていないといえます。

ただ、Webサイト制作に向いているといっても、SSGを使って静的にサイトのすべてを生成するという関係上、数万ページあるような、大規模なサイトにも向きません。基本的には1000ページ以下、多くても数千ページ程度のWebサイトが適切でしょう。

また、ビルドプロセスに時間がかかるため、1時間程度の短時間に何回も更新されるページを複数持つような、更新頻度が高いサイトもJamstackに向いていません。

以下の図は、Jamstackの強みと弱みを表しています。縦軸にページ数、横軸に更新頻度があります。それぞれ、中程度までがJamstackが最適解となる範囲（Jamstack Sweet Spot）、それ以上になると、ビルド時間の問題が生ずること（Build time friction）が示されています。

（画像出典：Edgio Blog Jamstack for eCommerce at Scale）

大規模サイトに対応するホスティングサービスの変化

デプロイ先となるホスティングサービスでは、Jamstackのこれらの問題を解決するためにさまざまな機能が提唱され、実装されました。アクセス頻度の低いページのビルドをアクセスされるまで遅らせるDPR（Netlify）、アクセスされたタイミングでページを最新の状態に更新するISR（Vercel）などです。しかし、どのプラットフォームでも使えてシンプルなのはアクセスされた際に動的にレンダリングするSSRでしょう。

こういったホスティングサービス側が進化するにつれて、Jamstackの当初のコンセプトである、事前に生成された静的サイトではなくなってきました。

Next.jsはVercelの機能を活かした開発がしやすいなど、ホスティングサービスごとに相性の良いフレームワークがあります。フレームワークとホスティングサービスの結びつきが強くなることで、静的サイトゆえロックインされにくいというJamstackの持つポータビリティ、セキュリティ面の強さは失われていきました。

Jamstackのセキュリティリスク

静的サイトでなくなれば、サーバー側でエラーが起こればページがダウンします（可用性）。ユーザー入力など、外部のデータを動的に扱えば、その分XSSやSQLインジェクションなどの脆弱性の恐れがあります。詳しくは、次の記事を参照してください。

• Jamstackのセキュリティリスク 特徴から考えるセキュリティリスクとその対策

ホスティングサービスとしても競合と比べて独自の強みを作るために、静的サイトだけでなく、動的なサイトへの対応に注力していくことになったのでしょう。

Netlifyとしてもホスティングサービスの機能が追加されるにつれ、静的サイトを作るJamstackという言葉は意味がなくなってきたのではないかと思います。

Webフレームワークとホスティングサービス

静的サイトでなくなったとしても、Jamstackに取り組んでいたエンジニアにとって嬉しいのは、多くのWebフレームワークで静的サイトを作るのとSSRで開発することの両方に対応していることです。

同じツールを使いつつ、作るものによって使い分けていくことができますし、静的に作っていたAstroベースのサイトをビルドの問題が発生してから、SSRに切り替えていくこともできなくはありません。

また、ホスティングサービスごとの違いもWebフレームワーク側で差分を吸収することで、ホスティングサービスに依存しないコードで書けるようになってきました。Jamstackの特徴のひとつ、「静的サイトなのでインフラにロックインされないポータビリティ」というほど簡単ではないかもしれませんが、ホスティングサービスを乗り換えるというのも難しくありません。

ピクセルグリッドの方針

ピクセルグリッドはいまも「Jamstackとエッジサーバーレスの会社」と名乗っています。

Jamstackという言葉が消滅したとしても、Webサイトやアプリケーションのデプロイ先として、ホスティングサービスを使っていく方針は変わりありません。その上で、静的サイトが最適なプロジェクトでは、今後も積極的に静的サイトで構築します。つまり今後も必要に応じてJamstackで作っていく場合があるということです。

もともと流行っているからJamstackをやっていたわけではなく、Jamstackの優れた面を説明するためにJamstackという言葉を利用していたので、作りたいサイトに最適な手法を取り入れ、よりよいWebを作っていくことには変わりがありません。

また、現在はSSRのためや、もしくはJamstackのAPIとして、エッジサーバーレスも積極的に利用しています。これらはAstroやSvelteKit、Next.jsといったJamstackでも使われてきた慣れたツールでフルスタック開発ができます。

SSRにしたとしても、できるところは事前にビルドしておく、また、配信に必要なデータと、管理するデータを分離するというようなJamstackのコアコンセプトの考え方は有用です。

まとめ

Jamstackという言葉が流行ったことで、SSGやヘッドレスCMSなど多くのサービスに影響を与えました。Jamstackの名の下にホスティングサービスやツールを超えて、多くのコミュニティで情報交換されたのは有意義だったといえるでしょう。

しかし、Discordやカンファレンスがなくなったことを考えると、来年以降はJamstackという言葉を聞くことは減っていくかもしれません。それはJamstackという手法が廃れているのではなく、アーキテクチャや開発の方法が進化しながら、この言葉が必要なくなっていくだけなのです。

Jamstackという言葉がなくても、ホスティングサービスで公開する知見をはじめ、ビルドプロセスでできるだけ事前生成しておくテクニックや、ユーザーへのコンテンツ配信とコンテンツを管理するシステムを分離しておく方法など、Jamstackで提唱されていた手法は、今後も使われていくでしょう。JamstackはWebに溶けて染みていくのです。

参考：Jamstackの先駆者であるBrian Rinaldi氏によるブログ記事

• Remote Synthesis | Is Jamstack Officially Finished?

参考：Jamstackが終了ということに対する多くの反応

• JavaScript Jamというポットキャストのホストによる記事: Is the Jamstack Dead? 🪦🤔 JavaScript Jam
• Daily Developer Tipsというニュースレターの運営者による記事: Is JAMstack dead (and was it ever alive)? | Go Make Things
• The New Stackというメディアの記事：Is Jamstack Toast? Some Developers Say Yes, Netlify Says No
• The Spicy Webのブログ記事：My Journey Away from the JAMstack
• 元Netlifyの社員による記事：How to Blow Up a Category - Netlify's New Era and The JAMstack Endgame
• Eleventy作者のZachによる記事：THE TENSION AND FUTURE OF JAMSTACK