AEM ヘッドレス機能を使用した初めてのエクスペリエンスへの道筋 path-to-first-experience

AEM ヘッドレスデベロッパージャーニーのこの部分では、計画に関する考慮事項なども含め、AEM で初めてのヘッドレスエクスペリエンスを実装するための手順を示します。また、できるだけスムーズに作業を進めるためのベストプラクティスについても説明します。

これまでの説明内容 story-so-far

AEM ヘッドレスジャーニーの前のドキュメント AEM Headless as a Cloud Service - はじめにでは、ヘッドレス CMS の基本事項を説明し、以下を達成できました。

この記事は、独自の AEM ヘッドレスプロジェクトを準備する方法を理解できるよう、これらの基本事項に基づいて構成されています。

目的 objective

このドキュメントは、初めてのプロジェクトの実装に必要な手順を理解するのに役立ちます。 読み終えると、以下を達成できます。

要件 requirements

このドキュメントに進む前に、AEM ヘッドレスデベロッパージャーニーの前のドキュメント AEM Headless as a Cloud Service - はじめにの内容に再度目を通し、以下を確認してください。

成功に向けた計画 planning-for-success

最初の AEM ヘッドレスプロジェクトを開始するには、すべてのチャネルで行うパーソナライゼーションと更新をサポートするコンテンツモデルが必要です。

また、クライアント側アプリケーションを作成する場合は、AEM とは別に、適切な開発環境をセットアップして、AEM as a Cloud Service への API 呼び出しに関してクライアントをテストできるようにする必要もあります。

コンテンツモデルと API の定義 defining-models

あらゆるチャネルにわたって一貫したエクスペリエンスを推進し、パーソナライズされたキャンペーンを管理するために、個々のチャネルとサーフェスを、配信時に準拠すべき独自のコンテンツ構造としてとらえることができます。 ただし、チャネルごとに独自のコンテンツモデルにすることは、メンテナンスが難しくなります。

代わりに、編成の原則（ブランドと製品の階層、商品やサーフェスのカテゴリ、カスタマージャーニーのステップなど）に基づいて、異なるサーフェス上のコンテンツがどのように関連しているかを検討する必要があります。 例えば、製造している自動車の特定ブランドをサポートする一連のサーフェスがある場合、自動車全体に当てはまる一般情報のコンテンツモデルから始め、次に、より特化した要素（自動車が市場に投入されサービスの問題が発生するまでになったときに必要なコンテンツなど）を用意することができます。 このようなモデルでは、一般的な自動車ブランドコンテンツを継承せざるを得ない反面、必要に応じて特定のコンテキストに基づいた転換も可能です。 また、自動車ブランド全体の総合的なマーケターやプロダクトマネージャーまたは「初期自動車」エクスペリエンスを担当する作成者などの役割に基づいた管理を実施できるので、このコンテンツに対する更新の今後の管理にも役立ちます。

コンテンツモデルを用意し、コンテンツを表示する必要がある様々なクライアントについての見通しが明確になったら、様々なコンテンツモデルへのアクセスに関連する GraphQL API を、このコンテンツを必要とするすべてのクライアントに公開する必要があります。 特定のコンテンツにアクセスする方法には、様々なオプションがあります。 特定の静的コンテンツを要求する場合は、コンテンツのキャッシュとパフォーマンスの向上が可能です。 また、動的に生成されるコンテンツを要求することもできますが、その場合は、より多くの処理が必要になります。 ビジネスニーズに最も効率的な API をクライアントで利用するようにしてください。

環境について understanding-environments

AEM 内には、開発、ステージング、実稼動の 3 つのタイプの環境があります。

開発環境（複数の環境を持つことが可能）は、アイデアを安全に試してみることができる場所です。 プロジェクトの初期フェーズでは、開発環境を使用してコンテンツモデルのバリエーションを試し、サーフェスに対して意図した出力を提供するコンテンツモデルを確認することをお勧めします。

ヘッドレスプロジェクトのステージング環境は、実稼動環境へのロールアウトに先立って新しい AEM 製品リリースを検証するために使用します。 実稼動コンテンツモデルの最新リストとコンテンツのサブセットを保持することで、変更を加えたり、AEM リリースで変更が導入されたりした場合でも、レンダリングされる JSON ファイルが同じ出力を提供するようにできます。

実稼動環境は、コンテンツ作成者が実際のコンテンツを作成および管理する場所です。 実稼動環境でのモデルの変更は、下位互換性を念頭に置いて慎重に行う必要があります。

開発ステージでは、開発環境とステージング環境を使用することをお勧めします。 パフォーマンステストに進む際は、本番環境に移行する必要があります。

開発者とコンテンツ作成者の協力 cooperation

開発者は、情報が入力されたコンテンツモデルを使用して AEM 開発環境をセットアップする必要があります。 コンテンツ作成者がコンテンツを引き続き作成するので、開発者は、AEM ヘッドレスのコンテンツを消費するクライアントを開発します。 API の定義が非常に重要なのはそのためです。 開発者は AEM SDK を利用してテストフックを作成できるので、クライアントテストとユニットテストを作成して、クライアントがコンテンツを適切にレンダリングできることを確認できます。

コンテンツ作成者は、ステージング環境で定義されたコンテンツモデルに基づいてコンテンツを作成します。 作成者は、コンテンツフラグメントオーサリングツールを使用して、新しいコンテンツフラグメントを作成するか、既存のコンテンツフラグメントを編集します。 そのコンテンツフラグメントを公開する前に、作成者は開発者と協力してコンテンツモデルを開発環境にプッシュするか、作成者側でプレビューできるように開発環境をセットアップすることで、クライアントでの表示をプレビューできます。

セットアップ setup

AEM でのヘッドレス開発に取りかかる前に、必要な機能がすべて有効になっていることを確認する必要があります。 この節では、必要なものを大まかに説明します。 実際の手順について詳しくは、後述の AEM ヘッドレスデベロッパージャーニーで説明します。

また、個々のトピックについて詳しくは、その他のリソースを参照することもできます。

設定 configuration

初めての AEM ヘッドレスアプリの実装

ここでは、AEM を使用してコンテンツを配信する初めてのヘッドレスアプリを実装するために必要な事項の概要を説明します。 これらの手順の実行方法については、AEM ヘッドレス開発者ジャーニーの後のパートで詳しく説明します。

ベストプラクティス best-practices

ヘッドレスプロジェクトが成功する理由は、実装された技術ばかりでなく、適切な計画とプロジェクトガバナンスのおかげでもあります。 以下では、プロジェクトを計画する際にコンテンツ作成者と開発者の両方が留意すべきベストプラクティスをいくつか示します。

コンテンツの整理 organizing-content

コンテンツのオーサリング authoring

グローバルコンテンツのオーサリング localization

次のステップ what-is-next

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

この基礎知識に基づいて AEM ヘッドレス機能の威力と柔軟性を十分理解し、独自のプロジェクトに活用できるようにしていただきたいと考えています。

これを行うには、How to Model Your Content as AEM Content ModelsでAEM ヘッドレスジャーニーを続け、AEMでコンテンツ構造をモデル化する方法を学びます。

その他のリソース additional-resources

コンテンツを AEM コンテンツモデルとしてモデル化する方法のドキュメントを確認して、ヘッドレス開発のジャーニーの次のパートに進むことをお勧めします。以下のリソースでは、このドキュメントで取り上げた概念についてより詳しく説明しています。なお、これらは追加のオプションリソースであり、ジャーニーを続けるうえで必須ではありません。

実践によって学びたい​場合は、AEM ヘッドレス実践チュートリアルで、AEM ヘッドレスコンテンツを公開する簡単なプロジェクトを実装して AEM ヘッドレス開発に直接進む方法を説明します。

関連トピックス：