正しいアーキテクチャの選択を行う

今年の初めに、私はヘッドレス アーキテクチャに関する一連の記事を開始しました。

今日の投稿はそのシリーズの続きです。ヘッドレス アーキテクチャで構築された新しい Web サイトの立ち上げが完了したので、ヘッドレス モデルの長所と課題について、重要な所見、戦略的考慮事項、および私自身の見解を共有したいと思います。私の目標は、皆さんが自信を持って、情報に基づいて将来のプロジェクト アーキテクチャを選択できるよう支援することです。

今日の投稿では、基本的なことから始めます。

• Optimizely の文脈における「ヘッドレス」が実際に意味するもの
• なぜそれを選ぶ人がいるのか（そして、選ばない人もいるのはなぜなのか）
• ヘッドレス Optimizely セットアップに適切なアーキテクチャの選択
• 今後の議論の基礎となる高レベルのアーキテクチャの概要

ヘッドレス Optimizely セットアップでは、CMS はコンテンツの保存と構造化、および API 経由での公開に重点を置きます。を使用するかどうか コンテンツ配信 API または Optimizely Graph、「ヘッド」(UI) は、コンテンツを取得してレンダリングする別のアプリです。

ヘッドレス分離により、フロントエンド チームは CMS に触れることなく出荷できるようになり、単一のコンテンツ ソースから複数のチャネルを提供できるようになります。この柔軟性は魅力的ですが、ヘッドレスが常にあらゆるシナリオに適しているわけではありません。

ヘッドレスが必要ない場合:

• シンプルなサイトのニーズ: 基本的なサイトのみが必要な場合、ヘッドレスによって不必要な複雑さが生じる可能性があります。
• 限られた開発能力: ヘッドレス アーキテクチャには、API 主導の開発に精通した熟練したフロントエンド チームが必要です。
• 予算の制約: 2 つのアプリケーションがあるということは、2 つのアプリケーションをホストする必要があることを意味します。これにより、インフラストラクチャに影響が生じたり、追加のライセンスが必要になったり、コストが高くなる可能性があります。

ヘッドレス化の主な課題:

• ルーティングとURLの管理: ルートの生成と解決 (スラッグ、動的ルート、正規 URL、リダイレクト、ローカリゼーション対応パス) はユーザーが責任を負います。 Optimizely Graph には URL リゾルバーが組み込まれていないため、フロントエンドでこのロジックを設計して維持する必要があります。
• ページ上の編集とプレビュー: MVC からの従来のページ上編集は、デフォルトでは利用できません。ドラフトのプレビュー レンダリング、署名されたプレビュー トークン、ライブ更新フックを実装する必要があります。編集者が視覚的なページ プレビューを必要とする場合は、そのエクスペリエンスを構築または統合する必要があります。出発点として、私のガイドに従ってください – ヘッドレス化: Optimizely Graph と Next.js によるオンページ編集
• CI/CD の複雑さ: ヘッドレスとは、通常、CMS とフロントエンドに個別のパイプラインを意味するため、デプロイメントを調整し、すべてを同期させる必要があります。さらに、Optimizely Graph でスキーマ変更を管理すると、両方のアプリケーションにわたって更新を反映してテストする必要があるため、さらなる課題が生じます。
• 認証と認可: ユーザーのログイン、エディターのプレビューを処理し、API を保護する必要があります。これは、シークレットの管理とセキュリティの見直しを意味します。

ご覧のとおり、ヘッドレス アプローチの採用にはトレードオフが伴い、複雑さが増します。単に業界のトレンドに従うのではなく、真のビジネス要件に基づいて決定を下すようにしてください。

ヘッドレス アーキテクチャの選択は、俊敏性、オムニチャネル配信、最新の開発ワークフローを必要とする組織にとって大きな変革となる可能性があります。 Web サイト、モバイル アプリ、IoT デバイス、デジタル キオスクなどの複数のフロント エンド間でコンテンツを再利用する必要がある場合、ヘッドレスによってプロセスが合理化され、重複が削減されます。これにより、フロントエンドとバックエンドの独立した開発と展開が可能になり、チームが迅速に反復して各レイヤーにクラス最高のテクノロジーを選択できるようになります。厳しい編集ワークロードを抱える企業にとって、ヘッドレスは、CDN を利用した静的サイトや API ファースト配信を活用することで、柔軟性の向上、カスタマイズ可能なオーサリング エクスペリエンス、およびグローバルに拡張する機能を提供できます。強力な統合、高度なパーソナライゼーション、または最新のフロントエンド パフォーマンス ツールが必要な場合、ヘッドレスは従来のアプローチよりも多くの扉を開きます。結局のところ、ヘッドレスは、プロジェクトで将来性、構成可能性、フロントエンドとバックエンドの両方を独自のペースで進化させる自由が必要な場合に特に価値があります。

セットアップを選択するときは、短期的な納品と長期的な柔軟性のバランスを考慮してください。誰のために構築しているのか、サポートする必要があるチャネル、チームのスキル、レイテンシ/スケールのニーズ、セキュリティ/コンプライアンス、総所有コストを考慮してください。これらを前もって書き留めておいてください。そうすることで、トレードオフを誠実に保つことができます。

最近では、さまざまなツールやアーキテクチャのオプションが膨大に感じられるため、ここですべてのシナリオをカバーすることは不可能です。その代わりに、私が最近直面した重要な決定をいくつか取り上げ、それぞれについて簡単に説明します。これらの洞察がお役に立てば幸いです。

CMS PaaS と SaaS

PaaS を使用すると、コードベースとインフラストラクチャをより詳細に制御できますが、運用上の責任も増大します。 SaaS はメンテナンスを最小限に抑え、アップグレードを加速しますが、サーバー側のカスタマイズとホスティングの柔軟性は制限されます。どちらを選択するかは、カスタム サーバー ロジックと地域展開制御の必要性に応じてください。私たちのプロジェクトでは、ソース コードの完全な制御を維持し、将来の統合をサポートするために PaaS を選択しました。

Optimizely DXP とセルフホスト型の比較

DXP では、マネージド ホスティング、グローバル CDN、組み込みセキュリティ、保証された SLA が最初から提供されます。そのため、面倒な作業の多くはあなたに代わって行われます。一方、厳格なデータ常駐要件や独自のネットワーク ニーズがある場合は、セルフホスティングが適している可能性がありますが、監視、スケーリング、パッチ適用、およびインシデントの処理は自分で行う責任があることに注意してください。選択する前に、各オプションの運用コストを現実的に比較検討してください。

グラフ (GraphQL) と CDA (コンテンツ配信 API)

Optimizely Graph は、コンテンツ配信をマネージド サービスに移行し、深くネストされたコンテンツや特定のコンテンツを取得するのに最適な正確な GraphQL クエリを可能にし、高度な検索機能を提供します。対照的に、Content Delivery API (CDA) はよりシンプルで REST ベースであり、組み込みの URL 解決を提供しますが、複雑なコンテンツ構造やスケーリングのニーズには追加の作業が必要になる場合があります。詳細な比較については、私の記事を参照してください。 ヘッドレス化: グラフとコンテンツ配信 API の最適化。

私たちのプロジェクトでは、データの常駐性が要件を満たし、コンテンツ配信の柔軟性が向上したため、Optimizely Graph を選択しました。

Next.js と他のフロントエンド フレームワークの比較

Next.js は SSR、SSG、ISR をそのまま提供しているため、コンテンツが豊富なサイトにとって強力な選択肢となります。 React with Vite や Angular などの代替手段も強力です。チームが最も使いやすく、ホスティング環境 (ノード、エッジ、またはサーバーレス) に適合するフレームワークを選択してください。

私たちのプロジェクトでは、市場投入までの時間を短縮することが不可欠でした。 SSR/SSG/ISR のシームレスなサポート、統合された Turbo モノリポ ツール、および迅速な反復、フィードバックの収集、効率的な起動を可能にするデプロイメント ワークフローのために、Vercel とともに Next.js を選択しました。

Optimizely CMS の SaaS バージョンを使用している場合は、フロントエンド アプリケーション用に新しく導入された DXP ホスティングを検討してみるとよいでしょう。詳細については、公式ドキュメントをご覧ください。 https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/host-a-front-end-with-optimizely

GitHub と Azure DevOps の比較

チームが知っており、クラウドのターゲットに適合するプラットフォームを選択してください。 GitHub は Actions および Vercel とうまく連携します。 Azure DevOps は、Azure およびエンタープライズ ガバナンスと緊密に統合されます。どちらもトランクベースの開発、保護されたブランチ、優れた CI/CD をサポートしています。

GitHub を選択したのは、Azure DevOps が提供する追加機能が必要なかったことと、アプリを DXP でホストすることで Azure の統合が最小限で済むことを意味したためです。 GitHub と Vercel のシームレスな統合も、私たちのワークフローにとって大きな利点でした。

Opti ID と他の SSO プロバイダーの比較

Optimizely エコシステム内で意味がある場合は、Opti ID を使用します。サイト/アプリのユーザーと内部編集者にとっては、標準の OpenID Connect/SAML プロバイダー (Azure AD、Okta、Auth0 など) が適切に機能します。 MFA、プロビジョニング、クレーム マッピングを早期に確認します。

Opti ID を選択したのは、すべての要件を満たしており、認証を迅速かつ効率的に実装できるためです。詳細については、公式ドキュメントを参照してください。 https://support.optimizely.com/hc/en-us/articles/12613241464461-Get-started-with-Opti-ID

共通リポジトリと個別リポジトリ

ヘッドレス設定では、フロントエンドと CMS/バックエンドは独立しています。これらを 1 つのリポジトリ (モノリポジトリ) に保持することも、別のリポジトリに分割することもできます。

チームが緊密に連携したり、コードを共有したり、フロントエンドとバックエンド全体で変更を調整したりする必要がある場合は、単一のリポジトリを選択します。独立したデプロイメントと分離された責任が優先される場合は、個別のリポジトリが推奨されます。

私たちがモノリポジトリのアプローチを選択した理由は、チームの規模により緊密なコラボレーションが容易になり、CI/CD プロセス全体の制御と可視性が向上するためです。

要約すると、最新の Web アーキテクチャを成功させるには、チーム、ビジネス ニーズ、長期的な保守性にとって適切な選択を行うことが重要です。 PaaS と SaaS、マネージド サービスとカスタム ホスティング、またはフロントエンド フレームワークの選択など、アーキテクチャ上の各決定は、パフォーマンス、スケーラビリティ、柔軟性、コラボレーションにおける独自の要件を反映する必要があります。各レベルでのトレードオフを評価し、シームレスな統合を優先することで、堅牢で適応性があり、将来性のあるソリューションを構築できます。

2025 年 10 月 17 日