なぜ公式サイトをWordPressからAstroへ移行したのか｜生成AI時代のCMS運用術
こんにちは。 株式会社ライジングサン・システムコンサルティングの岩佐です。
この記事では、弊社の公式サイトをWordPressからAstroへ移行した背景と、移行によって得られた手応えについて書いてみたいと思います。
なお、この記事自体も、Cursor上で生成AIとの対話を重ねながら、構成を相談し、表現を整えつつ書いています。タイトルにある「生成AI時代のCMS運用術」を、執筆のやり方から体現している、という話になります。
さて、あなたの会社では、公式サイトをどのような基盤で運用されているでしょうか。
WordPressで運用している、という企業様は非常に多いと思います。私たちも長年、WordPressで公式サイトを運用してきました。しかし、その運用には思った以上の負荷がのしかかっていました。そして、あるときから、プラグインの更新が止まったことによりページが壊れて表示されてしまうといった問題にも直面するようになりました。
こうした経験を経て、私たちは公式サイトの運用基盤をAstroへ乗り換えることを決め、今まさに「公開できるレベル」まで仕上がってきています。そして、Astroへの移行結果は、思った以上に大きなものでした。
この記事では、なぜWordPressからAstroへ移行することにしたのか、移行によって何が変わったのか、そして生成AI時代におけるCMSやコンテンツ運用のあり方について、私たちの実体験をもとにお伝えしていきます。
1. WordPress運用で直面していた課題
弊社では、これまで公式サイトをWordPressで運用してきました。多くの企業様と同様、コンテンツの更新やデザインの調整を、WordPressの管理画面から行う形でした。
しかし、その運用には、いくつかの課題が重なっていました。
1-1. LAMPという動作環境が、現代のサーバーレス主流時代には重すぎる
WordPressは、Linux、Apache、MySQL、PHPという、いわゆるLAMP環境の上で動作します。この構成は、長年Webサイトの標準的な選択肢として使われてきました。
しかし、現代ではサーバーレスや静的サイトホスティングが主流になりつつあります。常時サーバーを動かし続け、データベースと連携し、PHPでページをその場で生成する……という仕組みは、運用コストや心理的な負荷の面で、今の時代には重く感じられるようになってきました。
もちろん、WordPressそのものを否定するつもりはありません。多くのサイトでうまく使われていることは事実です。しかし、弊社のように小規模で、公式サイトの更新頻度がそれほど高くない場合、LAMP環境を維持し続けることの負担が、相対的に大きくなってきていると感じていました。
1-2. プラグインの更新が止まり、サイトの表示が壊れてしまう問題
もう一つの大きな課題は、プラグインに依存した構成そのものでした。
WordPressでは、デザインや機能の拡張に多くのプラグインを利用します。ところが、プラグインの開発が止まってしまうことがあります。作者の都合や、WordPress本体のバージョンアップに追従できなくなるなど、理由は様々です。
その結果、ある日を境に、それまで問題なく動いていたプラグインが動作しなくなり、ページのレイアウトが崩れたり、一部の機能が表示されなくなったりする……といった事態に直面しました。サイトを運用する側としては、原因の切り分けや代替手段の検討に時間を取られ、本質的には「コンテンツを届ける」という目的から外れた作業が増えていきました。
つまり、運用負荷の軽減が第一の目的でしたが、それに加えて、プラグイン依存による「いつ壊れるかわからない」という不安も、移行を検討する大きな理由のひとつになりました。
1-3. 運用負荷の最大のリスク——セキュリティ
WordPress運用における負荷のなかで、私たちが最も重く受け止めていたのは、セキュリティリスクです。
WordPressは、本体・テーマ・プラグインのいずれにも脆弱性が報告されることがあります。特にプラグインは第三者製のものが多く、開発が止まれば修正が届かず、既知の脆弱性を放置したまま運用し続けることになりかねません。また、ログイン画面や管理画面、データベースといった攻撃面が常に露出しており、パッチの適用やバージョン管理を怠れば、改ざんや情報漏洩のリスクに直結します。小規模であっても、公式サイトが攻撃の入口にされる可能性はゼロではありません。
運用負荷というと、工数や手間を思い浮かべがちですが、こうしたセキュリティリスクを「常に気にしておかなければならない」という心理的負荷も、決して軽くはありませんでした。その意味で、WordPress運用の最大のリスクはセキュリティにある、と感じていました。
1-4. 運用負荷の増大と、本質的な仕事からの乖離
上記のように、LAMP環境の維持と、プラグインやテーマの更新・障害対応に、思った以上のリソースが割かれるようになってきました。
公式サイトの役割は、お客様や社会に対して、自社の考え方やサービスを伝えることです。そのためには、安定して表示され、必要な情報が届くことが前提になります。にもかかわらず、基盤の保守や不具合対応に手を取られ、本来やりたい「コンテンツの充実」や「伝え方の改善」に集中しづらくなっている……そんな状態を変えたいという思いが、移行の背景にありました。
2. 解決策としてのAstroへの移行
こうした課題を解消するために、私たちは公式サイトの運用基盤をAstroへ乗り換えることを検討し、実際にプロジェクトを進めることにしました。
Astroは、静的サイトを生成するためのモダンなフレームワークです。ビルド時にHTMLを生成し、必要に応じてJavaScriptを部分的に使うことで、軽量で高速なサイトを構築できます。サーバー側で常時PHPやデータベースを動かす必要がなく、静的ファイルとして配信できるため、ホスティングの選択肢も広がります。サーバーレスやCDNとの相性も良く、現代のインフラの流れに沿った形でサイトを運用できる、という判断でした。
また、プラグインに依存した「ある日壊れるかもしれない」というリスクを減らすためにも、必要な機能をコードとして明示的に持ち、ビルド結果が静的であることで挙動が予測しやすい構成に移行することに意義があると考えました。
加えて、セキュリティ面でも静的なサイト構成には利点があります。ビルド済みのHTMLやアセットを配信するだけなので、WordPressのように常時データベースやPHPを動かす必要がなく、ログイン画面や管理画面といった攻撃面が存在しません。プラグインの脆弱性に晒されることもなく、攻撃対象が格段に小さくなります。運用負荷の最大のリスクであったセキュリティを、移行によって低減できることも、Astroを選んだ理由のひとつでした。
つまり、移行の目的は、
- 運用負荷の軽減（LAMP環境からの脱却）
- プラグイン依存による表示崩れや動作不良のリスク低減
- セキュリティリスクの低減（攻撃面の縮小とパッチ運用からの解放）
- コンテンツや伝え方に集中できる土台の整備
の四点に集約されていました。
3. 移行の結果——思った以上に大きかった変化
実際にAstroベースでサイトを組み直し、公開できるレベルまで仕上げてみると、移行前には想像していた以上の変化がありました。
まず、環境が軽くなったことで、ビルドやデプロイのサイクルがシンプルになり、心理的な負担が減りました。プラグインの更新に振り回されることもなく、「表示が崩れた」という事態に備えておく必要も、少なくなりました。
そして、WordPress運用で最も重く感じていたセキュリティリスクも、静的サイトとして配信する構成に移行したことで、大きく低減されました。ログイン画面や管理画面、データベースやPHPの脆弱性を気にしながら運用する必要がなくなり、パッチ適用の負荷からも解放されたことは、移行の大きな成果のひとつです。
さらに、思った以上に大きかったのは、Astroがいわゆるヘッドレスな構成であることの意味が、生成AIの存在によってまったく違うものになった、という点です。これについて、次節で詳しく書きます。
4. ヘッドレスだからこそ、生成AIが「GUIの代わり」を担う
ヘッドレスとは、管理画面（GUI）を持たず、コンテンツをファイルやAPIで管理し、表示用の画面とは分離した構成のことを指します。Astroで構築した当サイトも、そのようなヘッドレスな形で運用しています。
4-1. GUIが無いというデメリットを、生成AIがカバーしてくれた
Astroで構築したサイトには、WordPressのような管理画面（GUI）はありません。コンテンツを、JSONやMarkdownなどのプレーンテキストなファイルで管理し、ビルドによって、静的なHTMLが生成される形です。つまり、リッチな操作性の画面からポチポチと操作して記事を書くのではなく、テキストファイルを編集し、ビルド・デプロイする……という流れになります。
一見すると、これは「GUIが無いから不便では？」と思われるかもしれません。私自身、移行前はそのように感じる部分もありました。
しかし、実際にサイトを構築していく過程で、その「GUIが無い」というデメリットを、生成AIが十分にカバーしてくれることを体験しました。
私は、CursorというAIエディタを使い、その中で生成AIと対話しながら、このAstroサイトのコードを書いたり、機能を追加したりしてきました。やりたいことを自然言語で伝えると、適切なコードの修正案や追加案を提示してくれる。それを採用・調整しながら、テーマに実装されていない機能も、一つずつ形にしていきました。
4-2. nagiテーマをベースに、生成AIと対話で実装した機能
このAstroサイトは、nagiという、日本の企業サイト向けに作られた商用Astroテーマをベースにしています。
nagiは、yohakuさんの公式サイトやデモサイトでも確認できるとおり、企業サイト・コーポレートサイト向けのAstroテンプレートです。会社概要・サービス・お問い合わせなど、一般的なコーポレートサイトに必要な機能があらかじめ実装されており、日本語に最適化されたデザインとタイポグラフィで、本番運用にそのまま対応できるよう設計されています。
さらに、日本語に公式対応しているという点は、私たちのような日本企業にとって非常にありがたいポイントでした。
テーマ単体でも十分に使えますが、弊社のニーズに合わせてカスタマイズしたい部分は多々ありました。そこで私たちは、購入したnagiには実装されていなかった様々な機能を、生成AIと対話をしながら実装していきました。
例えば、YouTubeの埋め込み、ブログ記事一覧のタイル表示、事例ページのMarkdown対応、パートごとの表示・非表示をJSONで制御できる機能……など、挙げればきりがないほど、機能の修正や追加を実施しました。
もしご興味があれば、yohakuさんが公開されているデモサイトと、こちらのサイトを比較してみて下さい。どのような機能が追加・修正されているのか、確認いただけると思います。
しかも、この機能修正や追加において、私は一切コードを書いていません。要件を言葉にし、生成AIと対話しながら擦り合わせ、コードは全て生成AIに書いてもらいました。
4-3. コンテンツ執筆も対話で——この記事も生成AIと一緒に
そして、これはサイトの「構築」や「機能追加」に留まりません。
このブログ記事そのものも、管理画面のリッチエディタで書いているのではなく、Cursorを通して、生成AIとのダイアログを繰り返しながら書いています。
構成を相談し、表現を整え、読みやすくする。GUIが無くても、自然言語で依頼し、対話を重ねれば、コンテンツが形になっていく。その体験を、記事の執筆という行為においても、身をもって実践しているのです。
つまり、生成AI時代においては、「管理画面があるかどうか」よりも、「何を伝えたいかを言語化し、適切な相手（人であれAIであれ）と対話できるか」のほうが重要になってきている、と感じています。
5. 「SaaSの死」と、GUIがなくても成立する運用
最近、しばしば「SaaSの死」といった話題を耳にすることがあります。ここでいう「死」は、SaaSという形態そのものが消えるという意味ではなく、あらゆる機能がSaaSとして細分化され、契約や操作のGUIが増えすぎた結果、運用が複雑になり、あるいは生成AIのような存在によって「専用GUIがなくても用が足りる」ケースが増えてくる……といった文脈で語られることが多いようです。
私たちの体験は、まさにその一端を実感したものだと思います。
Astroには、WordPressのような管理画面はありません。だからといって、コンテンツが書けないかというと、そうではない。自然言語で生成AIに「こういう構成で記事を書きたい」「この部分をもう少し分かりやすくしてほしい」と依頼すれば、適切に案を出してくれる。サイトのコードについても、「この部分をこう変更したい」と伝えれば、修正案や追加案を提示してくれる。
GUIが無くても、対話さえできれば、必要な作業は進められる。その経験は、最近よく言われる「SaaSの死」や、ツールのあり方の変化を、身をもって体験したと言えるでしょう。
もちろん、すべての作業が生成AIだけで完結するわけではありません。最終的な判断や、ブランドやトーンに合わせた調整は、人が行う必要があります。それでも、「GUIが無いからできない」という制約が、生成AIとの対話によってかなりの部分で解消されていく……という手応えは、移行前には想像以上でした。
まとめ
この記事では、弊社が公式サイトをWordPressからAstroへ移行した背景と、移行によって得られた手応えについて書いてきました。
移行の理由は、主に次の四点でした。
- LAMP環境が、現代のサーバーレス主流の時代には重く、運用負荷を軽減したかったこと。
- プラグインの更新が止まったことにより、サイトの表示が壊れてしまうなどの問題に直面していたこと。
- WordPress運用の最大のリスクと感じていたセキュリティリスク（脆弱性対応や攻撃面の存在）を低減したかったこと。
- こうした基盤の保守に振り回されず、コンテンツや伝え方といった本質的な仕事に集中できる土台に乗り換えたかったこと。
そして、Astroへ移行した結果、思った以上に大きな変化がありました。環境が軽くなり、プラグイン依存のリスクが減り、セキュリティリスクも大きく低減しました。
さらに、Astroがヘッドレスであることが、生成AIとの対話によって十分にカバーされることを体験しました。
サイトの構築や機能追加は、Cursorを通して、生成AIと対話しながら進めました。nagiという商用Astroテーマをベースに、テーマに無い機能は生成AIとともにコードを更新し、様々な機能を追加してきました。さらに、この記事そのものも、管理画面のエディタではなく、生成AIとのダイアログを繰り返しながら執筆しています。
最近よく耳にする「SaaSの死」という話題と照らし合わせると、GUIが無くても、自然言語で生成AIに依頼すれば適切に仕事を進められる……という体験は、まさにそのことを身をもって経験したと言えるでしょう。生成AI時代のCMS運用の一つの形として、Astroと生成AIの組み合わせは、私たちにとって、極めて有効な選択でした。
公式サイトの運用基盤の見直しを検討されている方や、生成AIを活用したコンテンツ制作・サイト運用に興味をお持ちの方がいらっしゃいましたら、この記事が少しでも参考になれば幸いです。