【ITニュース解説】Connecting Headless WordPress RSS to Next.js: Building a Scalable Newsletter System

現代のウェブ開発では、コンテンツ管理と表示部分を切り離す「Headless CMS」というアプローチが、その柔軟性と高いパフォーマンスから広く採用されている。コンテンツの管理だけを専門とするシステム（バックエンド）と、実際にユーザーが見るウェブサイト（フロントエンド）を別々に構築し、コンテンツはAPI（アプリケーションプログラミングインターフェース）を通じてフロントエンドに提供される仕組みだ。今回のプロジェクトでは、Headless CMSとしてWordPressを使用し、ユーザーインターフェースとなるフロントエンドにはNext.jsという技術を採用した。さらに、ニュースレター配信サービスであるMailchimpを連携させ、WordPressで作成された記事の更新情報を自動的にニュースレターとして購読者に配信するシステムを構築した。

このシステムは、まずWordPressで作成された記事がRSSフィードという形式で情報を提供する。MailchimpはそのRSSフィードを定期的に読み込み、新しい記事があれば、あらかじめ用意されたテンプレートに従ってニュースレターを作成し、購読者にメールで送信する。購読者がそのニュースレター内の記事へのリンクをクリックすると、最終的にNext.jsで構築されたウェブサイトの該当記事ページへ移動するという一連の流れで動作する。

しかし、この自動化されたシステムを構築するにあたり、いくつかの技術的な課題に直面した。最初の大きな課題は「RSSフィードのURL不一致」だった。WordPressはコンテンツ管理専用のサブドメイン、例えばcms.example.comで運用されており、記事のURLはhttps://cms.example.com/sample-article-slug/のような形式で生成される。一方、ユーザーに公開するNext.jsのウェブサイトはメインドメイン、例えばexample.comで運用されており、記事のURLはhttps://example.com/news/sample-article-slug/という、ドメインもパスも異なる形式を使用していた。このURLの不一致が原因で、ニュースレターの読者が記事のリンクをクリックすると、Next.jsで構築された本来のウェブサイトではなく、WordPressの管理用サイトに直接リダイレクトされてしまうという問題が発生したのだ。

このURLの不一致という課題を解決するため、私たちはNext.jsの「APIルート」という機能を利用した。APIルートは、Next.jsアプリケーションのサーバー側で特定の処理を実行するための仕組みだ。具体的には、/api/redirectというAPIルートを作成した。ニュースレター内の記事リンクは、このAPIルートを経由するように設定され、例えばhttps://example.com/api/redirect?url=https://cms.example.com/sample-article-slug/といった形式になる。このAPIルートは、パラメーターとして渡された元のWordPressのURLから、記事の識別子である「スラッグ」（URLの一部として使われる短い文字列、例えばsample-article-slugの部分）を動的に抽出する。そして、抽出したスラッグを使ってNext.jsサイトの正しい記事URL、例えばhttps://example.com/news/sample-article-slug/を生成し、その正しいURLへ「301リダイレクト」という方法でユーザーを自動的に転送する。301リダイレクトは、ウェブページが恒久的に新しい場所へ移動したことを示すHTTPステータスコードであり、検索エンジン最適化（SEO）の観点からも推奨される転送方法だ。この仕組みにより、読者はニュースレターのリンクをクリックするだけで、WordPressのドメインを経由することなく、Next.jsサイトの正しい記事ページにシームレスにアクセスできるようになった。

次に発生した課題は「ニュースレターのデザイン一貫性」の維持だった。Mailchimpにはニュースレター作成のためのテンプレート機能があるが、デフォルトのデザインは私たちのウェブサイトのデザインシステムとは大きくかけ離れていた。ウェブサイトは特定のカラーパレット（黒を基調とした背景、特定のアクセントカラー）、フォント、角丸のコンポーネントデザインなど、一貫したブランドイメージで構築されていたため、ニュースレターもウェブサイトの一部として同じデザイン哲学を反映させる必要があった。

このデザインの一貫性を確保するため、私たちはMailchimpの「カスタムHTMLテンプレート」機能を活用し、ゼロからHTMLとCSSを記述してテンプレートを作成した。ウェブサイトのカラーパレット、使用しているフォント（Interフォントなど）、フォントサイズ、画像やカード要素の角丸の度合い、コンポーネント間の余白などを忠実に再現した。特に、GmailやOutlookといったメールクライアントは、ウェブブラウザと比較してCSSの解釈に多くの制限があるため、意図したスタイルが確実に適用されるように、CSSのプロパティには!importantというキーワードを多用した。これにより、メールクライアントによる表示の差異を最小限に抑え、どの環境でも一貫したブランド体験を提供できるように工夫した。また、様々なデバイスで適切に表示されるよう、モバイルファーストのアプローチでレスポンシブデザインも考慮して作成した。

三つ目の課題は「RSSからの画像抽出」の難しさだった。記事に含まれる画像をニュースレター内に適切に表示させることは、見た目の魅力に大きく貢献するが、実装は容易ではなかった。MailchimpにはRSSフィードから画像を取り込むための複数のマージタグ（*|RSSITEM:IMAGE|*、*|RSSITEM:IMAGE_FULL|*など）が用意されているものの、これらが常に期待通りに動作するとは限らず、またメールクライアントによっては表示が不安定になることもあった。様々な試行錯誤の結果、*|RSSITEM:IMAGE|*というマージタグをHTMLのdiv要素で囲み、そのdiv要素と画像自体に対して、width: 100% !important;やmax-width: 100% !important;といったメールクライアント互換のCSSを適用する方法が最も安定して画像を表示できることが判明した。これにより、記事のコンテンツと共に、関連する画像をニュースレターに効果的に組み込むことが可能になった。

これらの解決策は、単に目の前の技術的な問題を解決するだけでなく、「スケーラビリティ」（将来的な規模の拡大に対応できる能力）という側面も強く意識して設計された。初期段階では、ウェブサイトの設定ファイル（next.config.js）に各記事のURLごとに手動でリダイレクトルールを記述することも検討されたが、これは新しい記事が公開されるたびに手作業で設定を追加する必要があり、コンテンツ量が増えれば増えるほど管理が複雑になり、非効率だ。しかし、今回採用したNext.jsのAPIルートによる動的なURL処理は、WordPressに新しい記事が追加された際にも、その記事のスラッグを自動的に抽出し、適切なリダイレクトを生成するため、手動での設定変更は一切不要だ。このアプローチにより、システムはコンテンツの増加に自動的に対応できる、非常に効率的でスケーラブルなものとして機能する。

最終的なシステムアーキテクチャは、WordPressのRSSフィードが記事の更新情報をMailchimpに提供し、Mailchimpがその情報をもとにカスタムデザインのニュースレターを作成して購読者に配信する。購読者がニュースレター内の記事リンク（例: https://example.com/api/redirect?url=https://cms.example.com/sample-article-title/）をクリックすると、リクエストはまずNext.jsの/api/redirectルートに到達する。このAPIルートは、元のWordPressのURLから記事のスラッグを抽出し、それを基にNext.jsサイトの正しい記事ページ（例: https://example.com/news/sample-article-title/）へ301リダイレクトを行う、という一連の流れで動作する。

このシステム構築の過程で、いくつかの重要な教訓を得た。一つは、メールクライアントのHTMLとCSSのサポート状況はウェブブラウザとは大きく異なるため、デザインを正確に再現するには!important宣言やインラインスタイルを積極的に使用する必要があることだ。二つ目は、MailchimpのRSS関連マージタグの動作は必ずしも明確に文書化されておらず、期待通りの結果を得るためには様々なパターンを試して検証することが不可欠であること。三つ目は、Headless CMSを利用するプロジェクトでは、コンテンツが管理されている場所（WordPressのドメイン）とそれが表示される場所（Next.jsのドメイン）でURL構造が異なるため、プロジェクトの初期段階からURLの管理と変換の戦略をしっかりと計画しておくことが極めて重要であること。そして最後に、Next.jsのAPIルートは、今回のような複雑なURL変換や、外部サービスとの連携における動的なロジック処理を行う際に非常に強力で柔軟なツールとして活用できることだ。

この解決策は、パフォーマンス面でもいくつかの利点をもたらす。ユーザーが記事リンクをクリックした際に発生するリダイレクトは一度（301リダイレクト）だけで済むため、ページの読み込み時間が最小限に抑えられる。また、Next.jsアプリケーションがデプロイされるVercelのようなプラットフォームは、APIルートのレスポンスを効率的にキャッシュするため、同一のAPIルートへの繰り返しアクセスがあった際のパフォーマンスも向上する。301リダイレクトはSEOの観点からも有効であり、リンクの評価が適切に新しいページに引き継がれる。さらに、動的な処理によって、コンテンツの量が増加してもシステム全体の性能が低下することはない。セキュリティ面では、悪意のあるユーザーがAPIルートを利用して不正なサイトへ誘導する「オープンリダイレクト」を防ぐためのURL検証機能や、APIへの過度なアクセスを制限する「レート制限」といった対策を講じることで、より堅牢なシステムを構築できる。

今回のシステム構築は、Headless CMS、静的サイトジェネレーター（Next.js）、そしてAPIという、現代のウェブ開発における強力な組み合わせが、いかに洗練されたスケーラブルなウェブ体験を生み出せるかを示す好例だ。ニュースレターを単なる独立したメール配信としてではなく、ウェブサイトの延長線上にあるものとして捉え、デザインと機能の一貫性を保つことで、ユーザーはより統合された高品質な体験を得られる。適切なアーキテクチャに初期段階で投資することで、長期的なメンテナンスの手間を大幅に削減し、同時にユーザー体験を向上させるという大きな利益が得られるのだ。