どうもカッツプロダクション代表のカッツです、最近久しぶりに静的サイトジェネレーターを触らざるを得ない案件がありまして、改めて確信したことを書きます！！
結論から言うと、素のPHP+HTML構成（PHP includeでヘッダー・フッターを共通化するシンプルな組み方）の方が良いです。
実は2020年頃にNuxt.jsを使った静的サイトジェネレーター（以下、SSG）で痛い目を見てまして、そこから「やっぱり原始的HTMLサイトいいよね〜」と回帰してたんですよ。で、AIエージェント時代になった今、この選択がさらに正解になったと感じてます。その理由をつらつらと書きます。
先に前提を明確にしておくと、これはWebサイト制作（コーポレートサイト・LP・店舗サイトなど）における話で複雑な状態管理や認証が絡むWebアプリケーション開発は対象外なので、そこは分けて読んでください。
目次
SSG運用あるある？！引き継ぎの謎な折衝コスト
2020年頃の経験もあるんですが、最近また久しぶりに触る機会があって改めて確信しました。SSG運用のリアルな辛みを共有します。
前任者がばっくれて詰みやすい！複製が一筋縄でいかない
「同じようなサイトもう1個」が気軽にできない。SSGはビルド前のソース一式がないと結構大変なんですが、前任者がばっくれて音信不通になるケースがあり、えらい目にあいました、、、PHPの生HTMLならファイルさえあればコピペで済む話なんですよね、、、今ならAIエージェントにリバースエンジニアリングさせることができるとも言えますが。
複雑なコンポーネント構造+minifyされててどうしよう？！前任者に聞く謎コスト
先ほどの話とつながりますが、ソースが圧縮されて人間が読めない状態にされてたり無駄に複雑に切り分けられたコンポーネントだったりで、それを前任者にいろいろ聞く謎コストが発生したり。フォームのバックエンドにformrunなどのSaaS系サービス使っててアカウントの付け替え再調整したり、、、これも一部はAIエージェントにリバースエンジニアリングさせることで解決できますが、、、
Node特有のバージョンアップで3年で動かなくなる問題？！
実際に久しぶりに触ろうとしたらNodeのバージョンが合わなくてビルドが通らない、なんてことがザラにあります。「え、このプロジェクトNode 16系じゃないと動かないの、、、？」ってなって、nvmでバージョン切り替えて、それでも依存パッケージが古すぎてエラーの山、、、更新作業する前にまず環境構築で半日溶けるの、経験ある人ならわかりますよね？(笑)
PHP+includeが「楽で速い」技術的な理由
「結局、素のHTMLとPHP includeが一番小回りが利いて楽で速い」これ、一周回って立ち戻る真理のひとつだと思ってます。
- そもそも「ビルド（npm run build等）」という概念がない！ SSGはファイルの変更・追加のたびに再ビルドが必要ですが、PHP+HTML構成ならコードを保存してブラウザをリロードするだけで即座に結果が反映されます。中間生成物のエラーに悩まされることもありません。
- ローカル環境の構築も低スキルな人に優しい。DockerやXAMPPを使えば、専門知識がなくても環境が整います
「たかが数ページのサイトに、複雑なSSGと数百のnpmパッケージが必要か？」ぶっちゃけ、言葉に詰まる案件が9割じゃないですかね（なんでもwordPress脳にも通じますが笑）。「モダンだから」「流行ってるから」で技術を選んで、数年後に依存関係の更新で詰むのは結局お客様。シンプルなHTML/CSSで十分なWebサイトがもっと評価されていいはずです。
【インフラ好きな人向けの補足】
ステマじゃないですが(笑)、自分がよく採用するエックスサーバーはPHPの高速化にかなり熱心で、FastCGI＋OPcache・APCが全プランで標準有効になってます。なので「PHPって遅くない？」は実は今の時代ほぼ誤差レベルです。万が一アクセスが爆発する案件なら前段にCloudflareを1枚挟めば済む話で、そもそもそんなサイトならSSGやCDN前提で設計しますしね（笑）。
ホスティングもよく考えたら、数ページのサイトならAWSのS3使うより、さくらやロリポップの格安プラン（月数百円）の方がよくないですか？ PHPも使えるし、ワンランク上のプランならMySQLもついてくる。フォームだってPHP工房さんのフォームライブラリとか使えば楽に組めます。わざわざクラウドのバケット設定やCDN構成を考えなくても、月数百円のレンタルサーバーで全部完結するんですよ。
AIエージェント時代、原始的HTMLサイトはトークンコストでも有利
で、ここからが2026年的な話です。AIエージェント（Claude CodeやGemini）にコードを書かせる時代になって、原始的HTMLサイトの優位性がさらに上がりました。
シンプルなHTML/PHP構造は、AIにとっても構造を把握しやすいんですよ〜。中間で挟まる変換や設定が薄いのでコード生成のミスが劇的に減ります。
さらにトークンコスト的にも有利です。SSGのプロジェクトをAIに触らせると、設定ファイル・依存関係・テンプレートエンジンの構文まで読み込ませる必要があって、トークンをモリモリ消費します。原始的HTMLサイトなら、対象ファイルだけ読ませればすみます。AIと爆速でプロトタイプを作るなら、間に挟まるものが少ないほうが絶対に有利です。
なぜみんなSSGを使うのか？
もちろんSSGに流れる理由もわかります。
- デプロイが簡単・自動化されている。VercelやNetlifyにGitHubを繋ぐだけで、あとはpushするだけで公開まで完結する体験は確かに楽ですね
- エコシステムの誘惑。「Reactのこのコンポーネントライブラリ使いたい」と思った瞬間、HTML/PHPの世界から引きずり出される
- セキュリティの安心感。「サーバーでCGIやPHPを動かさない」状態が一番安全という信仰（これは一理あります）
これは自分の体感ですが、2018年頃以降にフロントエンドを学んだ人って、スクールやドキュメントがReactかVueを最初に教えるケースが多いんですよね。なので「保存したらそのまま動く」という感覚よりも「ビルドして確認する」が当たり前になってる人が一定数いる気がします。ちょうど私がjQueryで業務用タッチパネルのフロントを作ってて限界を感じてた頃に、世界はReact・Vue前提に切り替わっていった感じ、、、
それと、SSGでゴリゴリやってると「フロントエンジニアやってる俺かっこいい〜」という自己陶酔はできそうですよね(笑)。でもですよ、キャリアアップじゃなくて現場を考慮しろ！運用のことを考えろ〜！ と言いたいです。作って終わりじゃなくて、その後何年も誰かが運用するんですから(汗)
【実例】あえて「枯れた構成」で構築したSHAVEL様のサイト
「原始的HTMLサイトが良い」は理屈だけじゃなくて、実務でも実証済みです。
堀江貴文氏プロデュースのトークライブ＆バー「SHAVEL（シャベル）」様の公式サイトを構築した際、当初はNuxt.jsなどのSSG導入も検討したんですが、運用担当者のスキルや更新体制を考慮して、あえて「枯れた構成」を採用しました。
- HTML＋CSS＋最小限のJavaScriptで軽量化
- PHPのincludeを利用した再利用可能なコンポーネント構造
- FTPを排除して、mainブランチへのpushで自動デプロイが走るGITベースの運用
結果、導入・運用コストを大幅に抑えつつ保守しやすい環境になりました。「枯れた技術×モダンな運用（Gitデプロイ）」のいいとこ取りです(多分)。詳細は実績ページに書いてるのでよければ見てください。
念のため補足しておくと、これはCMS不可の大規模サイト案件だと話が別です。数千ページ規模でビルド時の一括最適化が必要なケースなどはSSGに分があります。あくまで数ページ〜中規模のWebサイト制作における話としてお読みください。
まとめると「原始的 HTMLサイト構成」は「古い」ではない？！
「原始的HTMLサイト」は決して「古い」ではなくて、無駄を削ぎ落とした結果の選択だと思ってます。
保存したら動く、ファイルを開けばそこに全部ある、低スキルな人でも環境が作れる、AIに渡してもトークンが少なくて済む、これ全部「シンプルだから」の一言で説明できるんですよね。複雑にする理由がないなら、複雑にしなくていい。
みなさんの現場ではどうですか？ SSGで消耗してる人、一度素のPHP+HTMLに戻ってみるのもアリですよ。なんだか愚痴っぽくなりましたが(笑)
原始的が最先端になる時代みたいな。今回はこの辺で失礼します！
