Jamstackと、その先のWeb

私たちが扱う技術はどこから来て、どこへ向かうのか

社内勉強会 / 2026

株式会社giniは、〇〇特化の制作会社

○○に入る言葉は何でしょう？

前提：Webの仕組み

WordPress や Jamstack の話の前に、Webサイトとは何でできているか を確認します。

Webサイトの中身は、たった3種類のファイル

  • HTML — 文章・構造（中身そのもの）
  • CSS — 見た目（色・レイアウト）
  • JavaScript — 動き（クリックすると反応する、など）

「サーバー」は、ただのパソコン

24時間電源を入れっぱなしにしてファイルを置いておくだけの機械。
例えば gini.co.jp/about にアクセスすると、サーバー内の about フォルダにある HTML を返す、ただそれだけ。

Webは本当は これだけ でできている。
でも、「いつ・誰が HTML を用意するか」 が時代とともに変わってきた。

WordPress時代のWeb

2000年代〜2010年代のWeb制作標準。今も全Webサイトの約43%が WordPress（W3Techs）。

土台は LAMPスタック（Linux / Apache / MySQL / PHP）。

非エンジニアでも管理画面から更新できる仕組みで Webを民主化 した功績は大きい。
プラグインで機能を拡張でき、世界中のWeb制作の標準になった。

WordPressの限界

毎回サーバーで HTML を組み立てる方式は、Webが大きくなるほど無理が出てきた。

  • 遅い — アクセスのたびに PHP + DB処理が走る
  • 狙われやすい — Webサイト改ざん被害の 多くが CMS/プラグイン経由
  • 運用が重い — プラグイン更新、サーバー保守、SSL対応、バックアップ
  • スケールしにくい — アクセス急増でサーバーが落ちる

このまま「動的サーバーに頼り続ける」発想で良いのか？

Jamstackの誕生

2015年、Netlify社共同創業者 Matt Biilmann が提唱。
当時の追い風：Node.js 普及、Static Site Generator の成熟、CDN の汎用化。

当初は 「JAMstack」 — JavaScript / API / Markup の頭文字。
2020年に小文字の 「Jamstack」 へ。「頭文字に縛られず、思想として広げよう」という意図。

サーバーに頼らず、事前に用意しておく。もっと速く、安全で、シンプルに。

Jamstackとは？

「事前に完成品を用意しておく」Webの作り方

「ビルド」 = ソースコードと CMS のデータを 事前に料理して、HTML一式を作る工程。

コンテンツ管理は ヘッドレスCMS（管理画面と表示を分離、例：Contentful, microCMS）。
動的処理は 必要なときだけ外部APIに任せる — サーバーは持たない。

Jamstackの強み

  • 速い — 事前生成 + CDN配信。Core Web Vitals（Googleの速度指標）で優位
  • 安全 — DB攻撃・PHP脆弱性が 構造的に発生しない。攻撃面そのものが消える
  • 落ちにくい — そもそも サーバーレス。サーバーが落ちる概念がない
  • 安い — CDN配信のみ。アクセス急増でもコストはほぼ線形
  • 開発体験が良い — Gitベースのワークフロー、コード管理と同じ流儀でサイトが動く

速さ・安全・コスト・運用 — 「面倒だったWeb」が全部ラクになる発想。

なぜJamstackが流行ったのか

技術が良いだけでは流行しない。時代の追い風が同時に揃った。

  • CDNの進化 — Akamai → Cloudflare → Vercel Edge と高機能化
  • APIエコノミー — Stripe（決済）/ Algolia（検索）/ Auth0（認証）/ Contentful（CMS）等
  • スマホ時代 — Google調査で 「3秒以上で53%が離脱」、速さが死活問題に

SSGだけでは解けない

初期 Jamstack = SSG（事前に全ページ生成）。シンプルだが、すぐ限界が見えた。

  • ビルド時間が爆発する — ページが数万を超えると、毎回数十分のビルド
  • 更新が反映されない — ビルドし直すまで古いまま、ニュースや在庫に不向き
  • ユーザーごとに違うコンテンツが出せない — 全員に同じHTMLしか配れない

「事前に作るだけ」では、現代のWebは足りない。

Jamstackの定義の拡張

転換点は Next.js（2016年〜、Vercel社）。事前生成と動的処理を 使い分ける 発想へ。

方式 内容 例え 得意な用途
SSG 事前に全ページを生成 全ページを印刷して棚に並べる ブログ、ドキュメント
SSR 必要なときにサーバーで生成 注文を受けてから印刷する ECサイトの商品ページ
ISR 必要な部分だけ後から再生成 棚のものを必要に応じて刷り直す ニュースサイト
PPR 1ページ内で静的と動的を混ぜる 印刷物の一部だけその場で書き込む ダッシュボード、パーソナライズ

2022〜2023年に 「Jamstack is dead?」 議論が起きたが、実態は 「思想として吸収・拡張された」。
今は 「最適な配信方法を選ぶ思想」 へ進化している。

それでも残る課題 — Next.jsとAI時代の影

JavaScriptエコシステムに依存し続けたことの ツケ が、いま噴出している。

Next.js 自体の脆弱性

2025年、Next.js に CVSS最大スコア（10.0）の重大脆弱性 が発覚。認証バイパスや任意コード実行が可能、766ホストが侵害された事案 も発生。フレームワークが大きく複雑になるほど、攻撃面も広がる。

ベンダーロックイン（Vercel税）

ISR・画像最適化・エッジミドルウェアなどの高度な機能は Vercel のインフラ前提 で最適化されている。AWS / Google Cloud でのセルフホストは難易度が高く、Vercel の価格改定や仕様変更に依存 せざるを得ない構造に。

サプライチェーン攻撃の爆発

2025年、npm/PyPI 等で 454,600個の新規悪意パッケージ（前年比 +75%）。AI（LLM）が攻撃コードを量産 する時代へ。1つの依存パッケージ汚染が世界中のサイトに波及する。


JavaScriptとVercelに依存し続ける限り、この戦いは終わらない。

試み① — JS世界での闘争（4つの挑戦）

Next.js一強に対し、2020年代、数々の天才たちが 異なる哲学 で挑んだ。

試み コア概念 何が革命的だったか 普及しきれなかった理由
Remix Web標準回帰 Loader/Action でブラウザ標準の <form> 完結、状態管理ライブラリ不要 Vercelの物量と資金力に敗北、React Router v7 へ合流
Svelte / SvelteKit コンパイラ化（Zero-Runtime） 仮想DOMを排除し劇的に軽量・高速、学習コスト低 React巨大エコシステムの壁、Svelte 5 Runes での揺らぎ
Qwik Resumability Hydration 物理ゼロ、初期 JS ロード ~0KB $ 記号の独特さ、React資産との断絶
SolidJS React風JSX + Signals 細粒度更新、仮想DOM不要、React 開発者ほぼゼロ学習 「Reactとそっくりなのに動きが真逆」 のメンタルモデル罠

JS世界では数々の答えが出たが、根本のJS依存とエコシステム問題は超えられなかった。

試み② — Astro と TanStack（現代の賢利な解）

闘争の中で 生き残った2つの戦略。だが、どちらも「JS依存」自体は超えていない。

Astro — 「敵を作らず吸い込む」（BYOF）

  • Bring Your Own Framework — React / Vue / Svelte をそのまま部品として埋め込める
  • Islands Architecture — ページは静的HTML、動かす部分だけ JS の島を読み込む
  • 「Reactエコシステムを敵に回したら勝てない」歴史の教訓を踏まえた賢い戦略
  • ※ Sol もこのアーキテクチャを採用（後述）

TanStack — 「コントロール権の奪還」

  • TanStack Query / Router / Table / Start
  • 完璧な型安全 + 明示的なコントロール、ブラックボックス化への反逆
  • Vite ベース、Vercel非依存 — ベンダーロックインなし
  • Next.js の複雑さに疲れた層を吸収

どちらも優秀。だが、JSランタイム / npm エコシステム自体への依存は残ったまま。

答え① — WebAssembly + WASI（セキュア・バイ・デザイン）

WASM は ブラウザやエッジで動く高速なバイナリ形式（asm.js 2013 → Wasm 1.0 2017 → 普及）。
JavaScript 比 3〜10倍速、しかも セキュリティが構造的に違う。

  • 鉄壁のサンドボックス — デフォルトで ファイル/ネットワーク/メモリ外アクセス権「0」
  • WASIによるケーパビリティセキュリティ — 「このバイナリには、この一フォルダだけ読込許可」のような 明示的な最小特権管理
  • 真のポータビリティ — Wasmtime 等のランタイムがあれば Cloudflare Workers / Fastly / 自前 / AWS どこでも同じ動作

ベンダーロックインも、サプライチェーン汚染も、構造的に蓋ができる土台。

答え② — 言語比較とMoonBit

WASM 開発はずっと C++ / Rust / Go が主流。だが Web で使うには バイナリが重すぎた。
（Hello world で Rust ~74KB、TinyGo ~37KB、ランタイム込み）

MoonBit（2022年、IDEA社） は Wasm/WasmGC のためにゼロから設計 された新言語：

  • Rust 並みの型安全 + TypeScript 並みの書き味 — 所有権・ライフタイムの難解さを排除
  • Rust より小さい WASM バイナリ を生成（The New Stack 検証済）、コンパイルもミリ秒級
  • マルチターゲット — Wasm だけでなく JS・Native へもコンパイル可能

答え③ — Sol とマルチランタイム・アイランド

MoonBit エコシステムから、すでに本格的なフレームワークが立ち上がっている。

Sol（Luna UI + MoonBit）

mizchi 氏が開発中 の実験的フルスタックフレームワーク。
Next.js でできることが揃う — SSG / SSR / ISR / Islands Architecture。
デフォルトで JavaScript 0KB、必要な部分だけハイドレート。Wasmネイティブ駆動。

周辺：Rabbita（旧 Rabbit-TEA）

Elm Architecture ベースの軽量UIフレームワーク。バンドル ~15KB（VDOM + 標準ライブラリ込み）。
すでに MoonBit 公式サイト・mooncakes.io で本番稼働中。

マルチランタイム・アイランド（次のパラダイム）

コアとレイアウトは MoonBit/Wasm、既存の React/JS 資産は JavaScriptの島 として埋め込む。
Astro の戦略を Wasm 上に移植 したもの。既存資産を捨てず、段階的に Wasm へ移行 できる現実解。

まとめ

WordPress の限界 → Jamstack という答え
SSG の限界 → 定義の拡張（SSR/ISR/PPR）
JS と Vercel への依存の限界 → Wasm と MoonBit/Sol という次の答え


Webは「課題 → 答え」の繰り返しで進化してきた。

技術は道具、選び方こそが私たちの仕事。
giniもまた、その先を見据えて学び続けていく。

WebAssembly のセキュリティが「構造的に」強い理由

WASM のセキュリティは、ライブラリやランタイムの「努力」ではなく、仕様レベルで担保された構造的なもの。

1. メモリ隔離（Linear Memory）

各 WASM モジュールは 自分専用の独立メモリ空間 しか触れない。ホスト OS やブラウザのメモリには 物理的にアクセス不可。バッファオーバーフローが起きても、被害はそのモジュール内に閉じる。

2. 構造化制御フロー

関数の戻り先・ジャンプ先は コンパイル時に検証済み。マルウェアの常套手段（ROP / 関数ポインタ書き換え）が そもそも実行できない構造。

3. ケーパビリティセキュリティ（WASI）

POSIX = 「自分の権限で何でもできる」モデル。
WASI = 「明示的に渡されたケーパビリティしか持てない」モデル。
例：ファイル読込は「ホストが事前に開いて渡したハンドル」経由でのみ可能。

4. デフォルト Deny

何も渡さなければ、何もできない。npm の悪意あるパッケージのような「インストールした瞬間に環境変数を盗む」攻撃が 構造的に成立しない。


Node.js は「全権限を持つコードに、後から制限をかける」。
WASM は 「最初から無権限。必要な権限だけ渡す」 — 発想が逆転している。

答え：Jamstack。では、その Jamstack って本当に説明できますか？