AEM ヘッドレスの概要

AEM ヘッドレスデベロッパージャーニーのこの部分では、独自のプロジェクトを AEM ヘッドレスで開始するために必要な操作について説明します。

これまでの説明内容

以前の AEM ヘッドレスジャーニーのドキュメント「CMS ヘッドレス開発について」では、ヘッドレス CMS の基本理論を説明しました。ここでは、次のことについて説明します。

  • ヘッドレスコンテンツ配信の基本概念と用語を理解する
  • ヘッドレスがなぜ必要なのか、また、いつ必要なのかを理解する
  • ヘッドレスの概念の用途とその相互関係の概要を理解する

この記事は、AEM を使用してヘッドレスソリューションを実装する方法を理解できるように、これらの基本的な項目で構成されています。

目的

このドキュメントは、独自のプロジェクトのコンテキストで AEM ヘッドレスを理解するのに役立ちます。ドキュメントを読めば、以下が可能です。

  • AEM のヘッドレス機能の基本を理解する。
  • AEM ヘッドレス機能を使用するための前提条件を理解する。
  • AEM ヘッドレスの統合レベルを把握する。
  • プロジェクトの範囲を定義する。

AEM の基本

AEM 内でヘッドレスプロジェクトを定義する前に、AEM の基本的な概念を理解しておくことが重要です。

オーサーインスタンス

簡単に言えば、AEM は、コンテンツの作成、管理、公開を連携して行うオーサーインスタンスとパブリッシュインスタンスで構成されています。

コンテンツはオーサーインスタンスで開始されます。これは、コンテンツ作成者がコンテンツを作成する場所です。オーサー環境には、コンテンツを作成、整理、再利用するための様々なツールが用意されています。

パブリッシュインスタンス

オーサーインスタンスでコンテンツを作成したら、他のサービスで利用できるように、コンテンツを公開する必要があります。パブリッシュインスタンスには、パブリッシュされたすべてのコンテンツが含まれます。

レプリケーション

レプリケーションとは、オーサーインスタンスからパブリッシュインスタンスにコンテンツを転送することです。これは、作成者または適切な権限を持つ他のユーザーがコンテンツを公開すると、AEM によって自動的に実行されます。

AEM の基本概要

AEM で最もシンプルにデジタルエクスペリエンスを作成するには、次の手順に従います。

  1. コンテンツ作成者が、オーサーインスタンスにヘッドレスコンテンツを作成します。
  2. このコンテンツは、準備ができるとパブリッシュインスタンスにレプリケートされます。
  3. その後、API を呼び出して、このコンテンツを取得できます。

AEM ヘッドレスは、この技術基盤の上に、次の節で説明するヘッドレスコンテンツを管理する強力なツールを提供しています。

AEM ヘッドレスの基本

AEM のヘッドレス機能は、いくつかの主要機能に基づいています。これらについては、このジャーニーの後半で詳しく説明します。今は、それらが何を行い、何と呼ばれているかという基本的なことを学びます。

コンテンツフラグメントモデル

コンテンツフラグメントモデルは、AEM で作成および管理するデータとコンテンツの構造を定義するもので、コンテンツの一種の基礎として機能します。コンテンツの作成を選択すると、作成者はあなたが定義したコンテンツフラグメントモデルから選択します。これが、コンテンツの作成のガイドとなります。

コンテンツフラグメント

コンテンツフラグメントを使用すると、ページに依存しないコンテンツの設計、作成、キュレーションおよび使用が可能になります。複数の場所や複数のチャネルで使用可能なコンテンツを用意できるようになります。

コンテンツフラグメントには構造化されたコンテンツが含まれ、JSON 形式で配信できます。

GraphQL および REST API

コンテンツをヘッドレスに変更するために、AEM には 2 つの堅牢な API が用意されています。

  • GraphQL API を使用すると、コンテンツフラグメントにアクセスして配信するリクエストを作成できます。
  • アセット REST API を使用すると、コンテンツフラグメント（およびその他のアセット）を作成および変更できます。

これらの API とその使用方法については、AEM ヘッドレスジャーニーの後半で説明します。または、以下の「追加のリソース」の節で、追加のドキュメントを参照してください。

ヘッドレス統合レベル

AEM は、完全なヘッドレスと、CMS の従来のフルスタックまたはヘッドフルモデルの両方をサポートします。ただし、AEM は、これら 2 つの排他的な選択肢だけでなく、両方の利点を組み合わせたハイブリッドモデルをサポートしており、ヘッドレスプロジェクトに独自の柔軟性を提供します。

ヘッドレスの概念を確実に理解できるように、この AEM ヘッドレスデベロッパージャーニーでは、純粋なヘッドレスモデルに焦点を当て、AEM でのコーディングなしで、できるだけ早く稼働できるようにします。

ただし、AEM ヘッドレス機能を理解する一方で、ハイブリッドの可能性もあることも覚えておいてください。これらのケースについて認識しておくため、以下で説明します。プロジェクトに柔軟性が必要な場合に備えて、ジャーニーの最後にこれらの概念を詳しく紹介します。

単一ページアプリケーション（SPA）などのヘッドレスコンテンツが既に存在する。

基本的な要件として、AEM から既存の外部サービスにコンテンツを配信する場合を考えてみましょう。

レベル 1：コンテンツフラグメントの統合 - 従来のヘッドレスモデル

このレベルの統合は、従来のヘッドレスモデルです。コンテンツ作成者は AEM でコンテンツを作成し、GraphQL を使用して任意の数の外部サービスにヘッドレスで配信したり、Assets API を使用して外部サービスから編集したりできます。AEM でのコーディングは不要です。

このモデルでは、AEM は、AEM コンテンツフラグメントを使用してコンテンツを作成および提供する目的でのみ使用されます。コンテンツのレンダリングとインタラクションは、それを使用する外部アプリケーションに委ねられます。多くの場合、これは単一ページアプリケーション（SPA）です。

レベル 2：SPA を AEM に組み込む - ハイブリッドモデル

このレベルの統合は、第 1 レベルに基づいて構築されますが、外部アプリケーション（SPA）を AEM に組み込むことができるため、コンテンツ作成者は、AEM 内の外部アプリケーションのコンテキストでコンテンツ表示することができます。また、AEM 内での外部アプリケーションの編集（制限付き）もサポートされます。

このレベルの利点は、コンテンツ作成者が、組み込みの外部 SPA でコンテンツをコンテキスト内で表示しながら、ヘッドフルな方法で AEM でコンテンツを柔軟に作成し、ヘッドレスでコンテンツを配信できることです。

レベル 3：SPA を AEM に組み込んで完全に有効にする - ハイブリッドモデル

このレベルの統合は、レベル 2 に基づいて構築され、外部 SPA のほとんどのコンテンツを AEM 内で編集できるようにします。

まだ、単一ページアプリケーション（SPA）などのヘッドレスコンテンツのコンシューマーはありません。

AEM のコンテンツをヘッドレスで使用する新しい SPA を作成することが目的である場合は、コンテンツフラグメントなどの機能を使用してヘッドレスコンテンツを管理し、AEM SPA エディターフレームワークを使用して SPA を構築できます。

SPA エディターを使用すると、SPA で AEM のコンテンツを使用するだけでなく、コンテンツ作成者が AEM 内で完全に編集することができるので、ヘッドレス配信の柔軟性と AEM 内でのコンテキスト内編集の両方を実現できます。

要件と前提条件

ヘッドレス AEM プロジェクトを開始するには、いくつかの要件があります。

知識

  • GraphQL
  • React または Angular フレームワークを使用した SPA の開発経験
  • AEM の基本的なスキル - コンテンツフラグメントの作成とエディターの使用

ツール

  • プロジェクトの導入をテストするためのサンドボックスへのアクセス
  • ローカル開発モデリングとテスト用のデータインスタンス
  • ヘッドレス AEM コンテンツの既存の外部 SPA またはその他のコンシューマー

プロジェクトの定義

プロジェクトの成功のためには、プロジェクトの要件だけでなく、役割と責務を明確に定義することも重要です。

対象範囲

プロジェクトの対象範囲を明確に定義することが重要です。対象範囲は、受け入れ基準を定めるので、完了の定義を確定できます。

最初に問うべき質問は、「AEM ヘッドレスで何を達成しようとしているか」です。一般的な答えは、AEM ではなく独自の開発ツールを使用して構築したエクスペリエンスアプリケーションを保有する、または将来保有するということです。このエクスペリエンスアプリケーションは、モバイルアプリや Web サイトなどのエンドユーザー顧客向けのエクスペリエンスアプリケーションである可能性があります。AEM ヘッドレスを使用する目的は、AEM ヘッドレスを呼び出してコンテンツを取得したり、エクスペリエンスアプリケーションから直接CRUD操作を実行できる最先端の API を使用して、AEM で作成、保存、管理できるコンテンツをエクスペリエンスアプリケーションに提供することです。これが目的でない場合は、AEM のドキュメントに戻り、目的により適したセクションを探してください。

役割と責務

個々のプロジェクトの役割は様々ですが、AEM ヘッドレス開発の内容で考慮すべき重要な役割は次のとおりです。

管理者

管理者は、システムの基本セットアップと設定を担当します。例えば、管理者は、Identity Management System（IMS）と呼ばれるアドビのユーザー管理システム内に組織をセットアップします。管理者は、アドビにより IMS 内に組織が作成された後、最初にアドビから招待メールを受け取るユーザーです。管理者は、IMS にログインして、他のペルソナのユーザーを追加できます。

管理者がユーザーを設定すると、AEM ヘッドレスを使用してエクスペリエンスアプリケーションを配信する際の寄稿者としての作業を行うために、すべての AEM リソースにアクセスする権限が付与されます。

管理者は、コンテンツ作成者がコンテンツを作成および更新できるように、また開発者がエクスペリエンスアプリケーションのコンテンツを取得または変更する API を使用できるように、AEM を設定してランタイム環境を準備するユーザーです。

コンテンツ作成者

コンテンツ作成者は、AEM によってヘッドレスで配信されるコンテンツを作成および管理します。コンテンツ作成者は、コンテンツフラグメントやアセットコンソールなどの AEM 機能を使用して、コンテンツを管理します。

コンテンツ作成者は、次のベストプラクティスに留意する必要があります。

翻訳の計画

プロジェクトの一番最初に、翻訳の計画を立案します。「翻訳担当者」は、翻訳するコンテンツと翻訳しないコンテンツ、および地域やローカルのコンテンツプロデューサーが変更する翻訳コンテンツを定義する責任を負うペルソナです。

翻訳が必要なコンテンツに関するプランを作成します。

  • 必要なのは別の言語ですか？それとも、地域の特性を言語に適用する必要がありますか？
  • 画像やビデオなどのリッチメディアコンテンツをロケールごとに異なるコンテンツにする必要がありますか？

コンテンツ更新ワークフローを明確にしてください。システムがサポートする必要がある承認プロセスは何ですか？AEM ワークフローを活用してこのプロセスを自動化できますか？

コンテンツ階層を活用すると、翻訳が容易になります。

その他のリソースの節を参照して、AEM ヘッドレス翻訳ジャーニーへのリンクなど、AEM ワークフローと翻訳ツールに関する追加ドキュメントを確認してください。

コンテンツ階層の活用

フォルダー階層は、コンテンツ管理に関する次の 2 つの主な問題に対処できます。

  • 翻訳 - AEM は、ロケール固有のフォルダー内にコンテンツのコピーを保持することで、コンテンツの翻訳を管理します。
  • 組織 - フォルダーは、翻訳のニーズをサポートするために必要なコンテンツ階層を定義し、コンテンツフラグメントを論理的に管理するために使用されます。

AEM では、柔軟なコンテンツ構造を実現でき、階層は任意に拡大できます。ただし、フォルダー構造を変更すると、コンテンツパスに依存する既存のクエリに対して意図しない結果が生じる可能性があることを認識しておくことが重要です。したがって、事前に明確に設定され階層は、コンテンツ作成者にとって役に立ちます。

フォルダーは、（コンテンツフラグメントモデルに基づいて）特定のタイプのコンテンツのみを許可するように制限することもできます。階層内のすべてのフォルダーに対して、どのモデルを許可するか明示的に指定することをお勧めします。許可するコンテンツをフォルダーに指定することで、次のことができます。

  • コンテンツ作成者がフォルダーに属さないコンテンツを作成することを防ぐ。
  • コンテンツ作成時に、フォルダーで許可されるコンテンツの種類をフィルタリングし、有効な種類のコンテンツのみを表示することで、コンテンツ作成プロセスを最適化する。

適切なコンテンツ構造を構築することで、チャネルをまたいでヘッドレスコンテンツの作成を調整でき、コンテンツを最大限に再利用できる。複数のチャネルにわたるコンテンツの活用により、コンテンツの作成効率と変更管理が大幅に向上する。

適切な命名規則の確立

コンテンツフラグメント名は、コンテンツ作成者にとってわかりやすい名前にする必要があります。AEM は、リポジトリーレベルで、使用される ID の名前のエスケープやトランケートを透過的に処理します。したがって、コンテンツ作成者が提供する論理名は、常に読みやすく、コンテンツを表すものでなけれがなりません。

  • 悪い名前：cta_btn_1
  • 良い名前：Call To Action Button

AEM ページの命名規則に関する追加のドキュメントについては、「追加のリソース」の節を参照してください。

コンテンツのネストを過度に拡張しない

コンテンツフラグメントは、ヘッドレスなコンテンツを作成するために AEM で使用されます。AEM は、コンテンツフラグメントに対して最大 10 レベルのネストをサポートします。ただし、AEM は、親コンテンツフラグメントで定義された各参照を反復的に解決し、すべての兄弟に子参照があるかどうかを確認する必要があることに注意してください。この操作はあっという間に増加し、パフォーマンス上の問題になります。

一般的な経験則として、コンテンツフラグメント参照を 5 レベルを超えてネストしないでください。

コンテンツアーキテクト

コンテンツアーキテクトは、ヘッドレスで配信する必要があるデータの要件を分析し、そのデータの構造を定義します。この構造は、AEM ではコンテンツフラグメントモデルと呼ばれます。コンテンツフラグメントモデルは、コンテンツ作成者が作成するコンテンツフラグメントの基礎として使用されます。

コンテンツフラグメントモデルを定義する際に便利な方法は、コンテンツを消費するアプリケーションの UX コンポーネントにマッピングされるモデルを作成することです。

コンテンツ作成者は、新しいコンテンツを作成するたびにモデルとやり取りするので、モデルを UX に合わせることで、結果として得られるデジタルエクスペリエンスを視覚化できます。この調整をさらに 1 段階進め、UX 要素を表すコンテンツフラグメントモデルにアイコンを割り当てると、作成者が視覚的な手がかりに基づいて適切なモデルを直感的に選択できるようになります。

デベロッパー

デベロッパーは、AEM でヘッドレスに作成されたコンテンツを、そのコンテンツの利用者と結び付ける責任を負います。これは、多くの場合、単一ページアプリケーション（SPA）、プログレッシブ Web アプリ（PWA）、Web ショップ、AEM 外部のその他のサービスです。

GraphQL は、AEM とヘッドレスコンテンツのコンシューマーの「接着剤」として機能します。GraphQL は、必要なコンテンツを AEM に問い合わせる言語です。

デベロッパーは、クエリを計画する際に、次の基本的な推奨事項に留意する必要があります。

  • クエリによるコンテンツフラグメントの取得は固定パス（ByPath）に依存してはいけません。
  • 最高のクエリパフォーマンスを得るには、常に AEM で永続的なクエリを使用します。これらについては、ジャーニーの後半で説明します。
  • GraphQL は、「何が必要かを正確に尋ね、それを正確に得る」というモットーに従って、宣言的な仕様になっています。つまり、GraphQL クエリを作成する場合、リレーショナルデータベースで作成するような select * タイプのクエリは常に避けてください。

AEM を使用した一般的なヘッドレス実装の場合、デベロッパーは AEM のコーディングに関する知識を必要としません。

パフォーマンス要件

プロジェクトを成功させるには、コンテンツを作成する前にパフォーマンスを考慮する必要があります。

ユーザー／訪問者の期待を理解し、そのために設計する必要があります。SLO（サービスレベル目標）を設定して測定し、ユーザーの期待に応えているかどうかを確認します。

トラフィックパターン

トラフィックとそのパターンを理解するには、まず過去の情報を収集し、それを今後数年間に予想される成長に投影します。最も重要な変数の一部を次に示します。

  • 1 時間／1 日／1 月あたりの API 呼び出し数はどれくらいですか？スパイクや季節性の可能性はありますか？
  • コンテンツ作成者は何人いますか？
  • 同時に作業するコンテンツ作成者は何人くらいを想定していますか？
  • コンテンツのアップデート頻度はどれくらいですか？
  • コンテンツモデルはいくつ必要ですか？
  • モデルのインスタンスはいくつ必要ですか？

アップデート頻度

多くの場合、エクスペリエンスのセクションが異なれば、コンテンツのアップデート頻度は異なります。CDN とキャッシュ設定を微調整するには、これを理解することが重要です。これは、コンテンツを表現するモデルをコンテンツアーキテクトが設計する際の重要な入力でもあります。次の点を考慮してください。

  • 一部のタイプのコンテンツは、一定の期間が過ぎると期限切れになりますか？
  • ユーザー固有の要素があり、そのためキャッシュできない要素はありますか？

次のステップ

これで、ここでの AEM ヘッドレスデベロッパージャーニーは完了です。次ができるようになったはずです。

  • AEM のヘッドレス機能の基本を理解する。
  • AEM ヘッドレス機能を使用するための前提条件を理解する。
  • AEM ヘッドレスの統合レベルを把握する。
  • プロジェクトの範囲を定義する。

次に、必要なツールを設定する方法と AEM でのデータのモデリングに関する考え方を説明する「AEM ヘッドレス機能を使用した初めてのエクスペリエンスへの道筋」のドキュメンテーションを確認して、AEM ヘッドレスジャーニーを続けてください。

その他のリソース

「AEM ヘッドレス機能を使用した初めてのエクスペリエンスへの道筋」のドキュメントを確認して、ヘッドレス開発の次のステップに進むことをお勧めします。以下は、このドキュメントで取り上げたいくつかの概念をより深く掘り下げる追加のオプションリソースですが、ヘッドレスジャーニーの継続には必要ありません。

このページ