AEM Headless as a Cloud Service - はじめに getting-started

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

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

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

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

目的 objective

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

AEM の基本 aem-basics

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

オーサーインスタンス author

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

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

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

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

プレビューサービス preview

パブリッシュインスタンスに公開する前に、コンテンツフラグメントを​ プレビューサービス ​に公開して、テストとレビューに使用することもできます。これを行うには、コンテンツフラグメント ​コンソールを使用します。

レプリケーション replication

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

AEM の基本概要 aem-basics-summary

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

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

AEM ヘッドレスの基本 aem-headless-basics

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

コンテンツフラグメントモデル content-fragment-models

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

コンテンツフラグメント content-fragments

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

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

GraphQL および REST API apis

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

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

ヘッドレス統合レベル integration-levels

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

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

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

シングルページアプリケーション (SPA) などのヘッドレスコンテンツを既に外部で使用しています。 already-have-a-spa

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

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

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

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

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

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

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

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

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

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

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

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

要件と前提条件 requirements-prerequisites

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

知識 knowledge

ツール tools

プロジェクトの定義 defining-your-project

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

対象範囲 scope

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

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

役割と責務 roles-responsibilities

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

管理者 administrator

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

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

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

コンテンツ作成者 content-author

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

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

翻訳の計画 translation

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

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

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

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

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

コンテンツ階層の活用 content-hierarchy

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

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

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

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

適切な命名規則の確立 naming-conventions

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

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

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

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

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

コンテンツアーキテクト content-architect

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

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

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

デベロッパー developer

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

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

開発者は、クエリを計画する際に、次の基本的なレコメンデーションに留意する必要があります。

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

パフォーマンス要件 performance-requirements

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

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

トラフィックパターン traffic-patterns

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

アップデート頻度 update-frequency

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

次の手順 what-is-next

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

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

その他のリソース additional-resources

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