Webサイトの歴史③——Jamstack・ヘッドレス・生成AI（2020年代）

2020年代のWebサイトの歴史は、ページを「いつ・どこで組み立てるか」を案件ごとに選ぶ時代になり、そこに生成AIが作り手と読み手の両方として入ってきた流れだと私は捉えています。歴史①の軸は「誰が更新するのか」、歴史②の軸は「どの画面で見られるのか」でした。今回の軸は「どこで作られ、誰が読むのか」です。

「先に作って配る」Jamstackという考え方

CMSが普及した2000年代以降、多くのサイトはアクセスのたびにサーバーでページを組み立てていました。これに対して、公開前にページを作り終えておき、CDN（世界各地に置かれた配信サーバー）から配るという考え方に名前を付けたのがJamstackです。

jamstack.orgでは、Jamstackはフロントエンド全体を事前に静的ページとして生成してCDNから配信し、動的な機能はJavaScriptとAPIで補うアーキテクチャと説明されています。名前は、Netlifyの Matt Biilmann と Chris Bach が、このやり方を会話で呼ぶ言葉がなかったために作ったとされています。

私の実感として大きかったのは、速度よりも「壊れにくさ」でした。配っているのは出来上がったファイルなので、アクセスが急に増えてもサーバーが落ちる心配が小さくなります。一方で、記事を1本直すたびにビルド（ページの再生成）が走るため、更新頻度が高いサイトでは待ち時間が気になる場面もありました。

ヘッドレス：CMSから「見た目」を切り離す

同じ時期に広がったのが、ヘッドレスCMSです。CMSには文章や画像の管理だけを任せ、表示は別のフロントエンドが担当します。CMSはAPIでデータを渡すだけなので、同じ記事をWebサイトにもアプリにも出せます。WordPressをこの形で使う話はPHPとWordPressの現在地で書いたので、ここでは制作体制への影響だけ触れます。

ヘッドレスにすると、編集する人・CMSを管理する人・表示を作る人の役割がはっきり分かれます。私が担当した案件でも、更新担当の方にとっては管理画面が使いやすくなった反面、「プレビューで見た表示と公開後の表示が違う」という問い合わせの窓口が増えました。仕組みが分かれる分、どこで何が起きているかを説明できる人が必要になります。

整理すると、2020年代の選択肢は次のようになります。

組み立てるタイミング	向いているもの	気をつけること
公開前（静的生成）	更新頻度が低いコーポレート・LP	更新のたびのビルド時間
アクセス時（サーバーレンダリング）	会員ページ・在庫など変化する情報	サーバーの負荷と運用
組み合わせ	大半のページは静的、一部だけ動的	構成の説明コスト

生成AIが「作る側」と「読む側」に入ってきた

2020年代のもう1つの変化が生成AIです。OpenAIは2022年11月30日にChatGPTを公開しました。制作の現場では、文言の下書き、コードの雛形、要件の抜け漏れ確認などに使われるようになり、私も日常的に使っています。ただ、出てきたものの正しさを確かめる工程は人に残ります。

読む側にも変化がありました。Googleは2024年5月14日の公式ブログで、検索結果にAIによる要約を表示するAI Overviewsを米国の全ユーザーに展開し始めると発表しています。サイトの文章は、人が直接読むだけでなく、AIに要約されて届くこともある、という前提が加わったわけです。

では特別な対策が必要かというと、Googleのドキュメントでは、AI OverviewsやAI Modeに表示されるための追加要件や特別な最適化は必要ないとされています。インデックスされ、スニペットとして表示できるページであることが条件で、これまでのSEOの基本がそのまま有効だという立場です。私はこれを「見出しで内容が分かり、1段落目で答えが書いてある文章」を地道に書くことだと理解しています。

明日から試せる一手

担当しているサイトについて、「このページは公開前に作れるか、アクセス時に作る必要があるか」をページの種類ごとに1行ずつ書き出してみてください。お知らせ・会社概要・問い合わせ・会員ページなど、5〜6種類で十分です。あわせて主要ページの1段落目を読み返し、そこだけ読めば何のページか分かるかを確認します。構成を選ぶ理由と、AIに要約されても伝わる文章の両方を、同じ作業で点検できます。