未だにiPhone11Proでがんばってるけど、容量不足でPC経由のアップデートしか出来なくてストレスが溜まってるmmochiです。
ここまでEmDashについて2本書きました。
1本目は、CloudflareのEmDashって何なのか。
2本目は、実際にWordPressから移行して、3,853行あった functions.php をどうしたのか。
今回は、そもそもの話。
なぜ、EmDashを選んだのか。
Jamstackを自社サイトで正式採用するのは初めてじゃないんですよ。じつは。
今回で三度目です。
過去に2回、Jamstackを採用しています。
2回目のあとにはWordPress単独の構成に戻しています。
1回目。Astroで作ってみた
最初は、社内のエンジニアからの提案だったんですよ。「インターン募集サイトをAstroで作ってみたい」と。
「どうぞ」とｗ
当時はAstro単体で、SSG（Static Site Generation）によってサイトを生成していました。
インターン募集サイトなので、CMSも不要。
静的に生成して配信するだけの構成でした。
特に困ることもありませんでしたねー
「Astroなんだー」
くらいの感覚です。
2回目。コーポレートサイトもJamstackにしてみた
コーポレートサイトのリニューアルのタイミング。情報設計をきちんと行い、日々の更新（制作実績に重点を置いてました）を速やかに行えるものとして、更新側はWordPressにしようと。
スピードも重視したのでGatsbyでヘッドレスにしよう。その時の記事「新コーポレートサイトはなぜ超高速？【Gatsby + WordPress ヘッドレス】」はこちら
これもエンジニアがやってみたいと言っていたので、「いいよ」と。
新しい技術に取り組んで、本人が習熟して、その知見が社内にも広がっていくってことを期待してたんですよね。
ただ、あんどぷらすのコーポレートサイト、速ければいいってわけでもないんです。
ビルドに1時間
リニューアル直後はまだマシだったんですけど、最終的にはビルドに1時間以上かかるようになっちゃったんですよね。ちょっとした修正をして確認したいだけでも、ビルドを待つ。
修正して、ビルドして、確認して、また修正する。
これは、なかなかつらい。
プレビューは作り込まなかった
WordPressなら、記事を書いてプレビューすれば公開前の状態を確認できますよね。Gatsbyでもプレビューの仕組みは作れるんですが、当時は時間とリソースの関係でそこまで作り込まなかったんですよねー。
やっぱりあったほうがいいです。
Worksの複合フィルター
コーポレートサイトには、制作実績を紹介するWorksコンテンツがあります。EC、Webサイト、システム、業種など、いろいろな条件で実績を絞り込めるようにしたい。
SSGでも、フロントエンドで絞り込む仕組みは作れるんですよ。
でも、これも当時の構成と実装コストを考えて、そこまではやらなかったんですよね。
サイトを育てていく
コーポレートサイトに限らないのだけど、Webサイトは、公開して終わりじゃないです。- コンテンツを更新する。
- デザインを変える。
- 情報の整理の仕方を見直す。
運用していると、いろいろやりたいことが出てきます。
結果、Gatsbyを習熟するよりも先にやりたいことが山積みに。
WordPressに戻して、やりたかったこと
一番やりたかったのは、構造化データの整備だったんですよね。個々のコンテンツについて、何が書かれていてどんな情報を持っているのか。
ほかのコンテンツと、どういう関係にあるのか。
そうした意味的な関連付けを、情報設計し正しく意図通りに表現したかったんですよ。
構造化データだけではなく、AI向けに、自社の情報を整理し、伝える文書もきちんと設計していきたかったんです。
そのためには、日々サイトを運用しながら、思いついたことを繰り返し試すことが出来たほうがいいんですよね。
で、試行錯誤がしやすいWordPress単独の構成に戻すことに。こちらも記事化「コーポレートサイトリニューアルしました。再び。」してあります。
Gatsbyを維持することよりも、改修しつづけることを優先したってことです。
そして2026年
今度はEmDash！過去2本の記事を読んでもらえば分かる通り、JamstackにしたかったからとかEmDashにしたかったからっていうわけじゃないんですよ？
CMSとサイト構築
今回の構成では、Astroをベースにサイトを構築し、その中でEmDashのCMS機能を使っています。コンテンツを管理する仕組みと、サイトそのものを構築する仕組み。
それぞれの役割を分けながら、自分たちが扱いやすい形に組み合わせています。
WordPress＋Gatsbyでも、それぞれの役割を分けることはできたんですけどね。
Cloudflareという基盤
今回のサイトは、DNS、WAF、CDNなどをCloudflareに集約しています。EmDashもCloudflareの基盤上で動かしています。
そのおかげで、メディアの配信やセキュリティも含めて、全体の構成を考えられるんですよ。
必要に応じてWorkersやD1、R2、KVなども使えますしね。
セキュリティも、構成から考える
WordPressでは、CMS本体やプラグインの脆弱性、PHPのバージョン、アップデートへの対応など、継続的に考えなければならないですよね。もちろん、EmDashにすればすべて勝手に解決するわけじゃないですよ？
どんな構成でも、アプリケーションの脆弱性や設定ミスへの対策は必要ですしね。
ただ、今回のようにフロントエンドとCMSの役割を分け、CloudflareのWAFやCDNなども含めて構成を考えられるのは、選択するうえで大きなポイントでした。
管理画面へのアクセス制御にも、Cloudflare Accessなどを活用できますしね。
CMSを何にするかっていう判断だけでなく、サイト全体をどう守り、どう運用していくのかっていうところまで自分たちで設計できる構成にしたかったんですよね。
そして、AI
以前と大きく違うのは開発の仕方ですね。今は、設計を考えるときも、実装するときも、調査や検証をするときも、AI（エージェント）をかなり活用しています。
以前なら、知らない技術の構成を理解して、実装方法を調べて、ひとつずつ試していく必要があったんですよね。
もちろん今も、「何も知らなくても大丈夫」ではないですよね。
AIが書いたコードを、そのまま信用していいわけでもありません。
とはいえ、AIのおかげで「まずは試す」っていうことのハードルは相当下がりましたね。
- 「こういう情報の持たせ方はできないか」
- 「コンテンツ同士の関係を、もっと明確に表現できないか」
- 「構造化データをこう整理したらどうだろう」
なんていうアイデアを、検証して、設計して、実装して、確認する。
っていうサイクルを回しやすくなったんですよね。AIエージェントのおかげ。
これはとてつもなく大きな変化です。
技術を選ぶことと、育て続けること
あんどぷらすのスタンスではあるのだけど、1回目も2回目も、新しい技術に取り組むきっかけは社内のエンジニアからの提案なんですよね。やってみたいという人がいるなら、やってみればいいんですよ。（もちろん合理性がぼくに伝わらなければ却下ですけどね？）
実際に使ってみて、習熟して、その知見が社内に広がっていけば、会社にとってもプラスになります。
一方で、自社サイトを運用していると、やりたいことは変わっていきます。
最初はサイトを作ることが目的でも、次第にコンテンツの管理や情報設計、構造化データ、AI向けの情報整備など、やってみたいことが増えていく。
そのときに、今の自分たちが何を優先したいのか。
どんな構成なら、日々の運用と改善を無理なく続けられるのか。
そこを考えて、技術を選び直すことも必要です。
以前WordPressに戻したのも、今回EmDashを選んだのも、判断基準は同じなんですよ。
技術を採用することと、その技術を使ってサイトを育て続けることは、別の話です。
自社のビジネスをWebサイトで体現していくためには、後者のほうがだいじだと考えてるんですよね。
以前の課題は、今回どう変わるのか
過去2回のJamstackで課題になったことは、今回どう変わるのか。解決されるのか。ビルドに時間がかかる問題については、今回の構成では、SSR（Server Side Rendering）を採用してます。
本番へのデプロイ時にはビルドが必要ですけど、変更を確認するために毎回、本番向けビルドが終わるのを待つ必要はないです。
SSGのほうが構造的には速いんですけどね。
※念のため言及しておくね。今はフルSSRですけど、落ち着いたら随時SSGページを混在させていきます。従来のJamstackの定義からは外れるかもしれないけど、そのあたりのツッコミはぐっとこらえてくださいｗ
プレビューも今回実装済みです。
なんて。標準機能のはずですｗ「Frontend-based editing」
やっぱり楽ですねー
Worksの複合フィルターや構造化データについては、Astro側の実装も含めて、自分たちで設計・改修しやすい構成にしてEmDashのネイティブプラグイン化してるんです。
AIを活用しながら、アイデアを検証して実装するサイクルも回しやすくなってると思いますね。
EmDashはコンテンツ管理、Astroはサイト構築、Cloudflareは配信やセキュリティを含む基盤。
自分たちがやりたいことをより実現しやすい構成を組めるようになったと思っています。
Jamstack、三度目。
前回の締めで「Jamstack再び」とか書いてたと思うけど「みたび」だったねｗ1回目は、Astro単体。
2回目は、WordPress＋Gatsby。
そして3回目が、Cloudflare基盤でのEmDashです。
一度やめた構成にまた戻る。同じじゃないけどね。
- 技術が進化する。
- 開発の仕方も進化する。
- サイトで実現したいことも変わる。
だから、もう一回やるんですよ。何度でもやるの。
今回も運用しながら、必要なところに手を入れ、育てていこうと思っています。
まだリプレースしたばかりなので、これからどうなるかは分からないですし、以前とは違う新たな課題が出てくるかもしれないですね。
まーそのときは、また考えますよ。
昔うまくいかなかったからといって、今も同じとは限らない。
逆に、今うまくいっているからといって、ずっと最適とも限らない。
Webサイトを作ることも、技術を選ぶことも、結局はその繰り返しなのかもしれないですね。
ということで。
Jamstack、三度目。ちゃんと運用していきましょうかね。
関連記事
CloudflareのCMS「EmDash」を触ってみた。01WordPressからEmDashへ。3,853行のfunctions.phpをどうしたか。02
Jamstack三度。今回のEmDashは何が違うのか 03
速くて、セキュアで、自由なWebサイトをつくる。EmDash 04
