表示・CMS・メール送信を分けて、WEBサイトの運用を見直した話

従来の自社サイトでは、WordPressとレンタルサーバーを中心に、ページ表示、コンテンツ管理、お問い合わせフォーム、メール送信などを一つの環境で管理していました。

一つの環境で多くの機能を扱えることはWordPressの大きな利点です。一方で、表示、CMS、フォーム、メール、サーバーが密接に関係するため、問題が起きた際の影響範囲や確認箇所が広くなることがあります。

今回のリニューアルでは、公開ページの生成をAstro、コンテンツ管理をmicroCMS、公開サイトの実行・配信をCloudflare Workers、メール送信をResendに分けました。目的は技術を増やすことではありません。ページを素早く表示し、問い合わせを確認しやすくし、保守や障害対応の範囲を整理するためです。

公開ページの表示を、WordPressの実行環境から切り離す

今回の自社サイトでは、Astroでページを組み立て、Cloudflare Workersの実行環境から公開しています。ユーザーがアクセスするたびにWordPress、PHP、データベースでページを生成する構成ではありません。

Journalの一覧などCMSの情報を取得して表示するページや、お問い合わせフォームの送信ではサーバー側の処理が必要です。ただし、公開ページの表示にWordPressの実行環境を常時必要としないことで、公開環境で動かす仕組みを必要な範囲に絞り、表示と保守を改善しやすくしています。

不具合が起きたときの影響範囲を整理する

役割を分けても、どのような障害でも影響を受けなくなるわけではありません。たとえばメール送信サービスに問題が起きても、公開サイトやJournalの閲覧がすべて停止するわけではありません。一方で、CMSのAPIや外部サービスから直接配信している画像・ファイルに問題が起きた場合は、記事一覧などの表示に影響する可能性があります。

重要なのは、すべての影響をなくすことではなく、どこに問題があるのかを切り分け、対応の優先順位を判断しやすくすることです。

問い合わせメールを専用サービスで管理する

フォームから送信された内容はサーバー側で受け取り、Resendを通して管理者宛てとユーザー宛てのメールを送信します。フォームの実装やDNS設定、送信元の認証は必要ですが、送信処理を専門のサービスへ分けることで、送信要求を受け付けたか、エラーが発生していないかを確認しやすくなります。配信状況はResend側の管理画面とあわせて確認します。

お問い合わせフォームは、設置して終わりではありません。送信内容を正常に受け取れているか、問題が起きた際に調査できるかまで含めて設計する必要があります。

技術ではなく、サイトの目的から選ぶ

複数のサービスを組み合わせる場合、各サービスの契約、権限、料金、障害情報、連携設定などを個別に管理する必要があります。管理画面からページ構成を自由に変更したい場合や、既存のWordPress機能を活用したい場合には、WordPressのほうが効率的なこともあります。

大切なのは特定の技術を使うことではなく、どの程度の表示速度を求めるか、問い合わせをどのように管理するか、公開後に誰が保守するかを整理し、サイトの目的に合う構成を選ぶことです。