---
title: "Experience Edgeへの公開"
slug: "publishing-to-experience-edge"
abstract: "Sitecore XMやSitecoreAIからExperience Edgeに公開する際の公開パイプライン、コンテンツ選択、依存関係の計算を理解しましょう。"
---
# Experience Edgeへの公開

Sitecoreでウェブサイトを作成する際、コンテンツ管理システム(CMS)でさまざまな種類のコンテンツ項目を作成します。これらの項目はウェブページ、サイトレイアウト、ナビゲーション、その他の要素として公開されSitecore Experience Edge;Experience Edgeからコンテンツを消費するヘッドアプリケーションを使ってウェブサイトをレンダリングします。

以下の図は出版パイプラインを示しています:

![A diagram showing the publishing pipeline in Sitecore XM and XM Cloud.](https://doc.sitecore.com/api/markdown-image/sai/ja/developers/sitecoreai/images/Publishing_to_Edge_diagram.png)

## ベストプラクティス:ワークフロー

公開を制御するための [ワークフロー](https://doc.sitecore.com/sai/ja/developers/sitecoreai/content-modeling-and-presentation/workflow.html "Workflow") の導入を強くお勧めします。手動公開に頼ると、未完成のコンテンツを誤って公開してしまう可能性があります。以下のセクションでは、依存関係が意図せずにアイテムを公開させる方法について説明しますが、ワークフローを実装することでそれを防ぐことができます。

ワークフローを使えば、以下のようなことができます:

-   どのコンテンツをEdgeに公開するかを管理し、準備ができた時だけ公開するようにしましょう。
-   コンテンツレビューのプロセスを管理します。

## コンテンツの選択

Sitecoreは公開するコンテンツを選択するための複数のオプションを提供しています。それぞれのオプションは、出版パイプラインやそのパフォーマンスに異なる影響を与えます。

### 単一項目出版

単一アイテムの公開には **スマート** と **再出版**の2種類があります。

-   **スマートパブリッシュ** - 各アイテムにはリビジョンIDがあり、そのアイテムの変更が保存されるたびにデフォルトで更新されます。 **スマート** パブリッシュでは、Sitecoreがコンテンツ管理インスタンスのリビジョンIDとEdge内の同じアイテムのリビジョンIDを比較します。両方のリビジョンIDが同じなら、そのアイテムは公開されません。
-   **再公開** - アイテムとその依存関係は常に公開されます。

> !注公開時には必ず関連項目のチェックボックスを選択し、関連項目が適切に更新されていることを確認してください。これをオフにすると関連コンテンツがスキップされ、矛盾や部分的な公開が発生する可能性があります。

さらに、すべてのサブアイテム(子項目)を公開することも選択できます。

### すべての項目の公開

コンテンツエディターの **「公開サイト** 」オプションを選択することで、すべてのアイテムを公開できます。その場合、利用可能な公開の種類は3つあります:

-   **インクリメンタルパブリッシュ** - 変更履歴に基づいて変更されたアイテムを公開します。これはすべての変更されたアイテムを公開する最も効率的な方法であり、コンテンツエディタのリボンの **公開** メニューからサイト全体を公開する場合のみ利用可能です。
-   **スマートパブリッシュ** - 各アイテムのリビジョンIDに基づいて変更されたアイテムを公開します。このタイプのパブリッシングは、保存された変更リストではなくアイテムツリー全体をスキャンするため、時間がかかることがあります。
-   **再公開** - コンテンツツリー内のすべての項目を再公開します。この操作は他の公開タイプよりもコストが高く時間もかかります。

## 出版パイプライン

[パブリッシングパイプライン](https://doc.sitecore.com/sai/ja/developers/sitecoreai/experience-edge/publishing-to-experience-edge/the-publishing-process.html "The publishing process")は、パブリッシング操作を完了する複雑で多段階のプロセスです。Experience Edgeの文脈では、パイプラインは主に3つのコンポーネントと相互作用します。

-   **Sitecore パブリッシング** – 公開対象のルートアイテムと適用された公開方法に基づいて、公開対象アイテムの初期キューを設定します。
-   **Experience Edgeコネクタ** ー – Sitecore CMのアイテムをExperience Edgeエンティティに変換します。Experience Edgeからメタデータを受け取り、エンティティを送信し、確認応答を受け取ります。
-   **レイアウトサービス** – レイアウトのあるアイテムのJSONを生成します。これは選ばれた公開の種類によって異なります:
    -   スナップショット公開 - JSONをExperience Edge上で単一のエンティティとして保存します。
    -   Edge Runtime publishing - メイン構造のレイアウトを保存し、各データソースへの別々の参照を保持します。

### 公開する追加のエンティティの計算

単一のSitecoreアイテムは複数のExperience Edgeエンティティに変換可能です。例えば、アイテムにレイアウトがある場合、[Experience Edge](https://doc.sitecore.com/sai/ja/developers/sitecoreai/experience-edge/experience-edge-apis/the-experience-edge-schema.html "The Experience Edge schema")でitemエンティティとlayoutエンティティの両方を生成します。

### 依存関係の定義

アイテムがEdgeに公開されると、その依存関係が計算されます。公開されるアイテムによっては、多数の依存関係が存在する場合があります。例えば、単純なページアイテムは含まれるすべてのデータソースに依存しています。もう一つの例はテンプレート項目です。テンプレートから継承したサイト内のすべてのアイテムはテンプレートに依存しています。テンプレートが変更された場合、その依存するすべての項目は再公開される必要があります。

ページレイアウトで使用すると依存関係を生み出すコンポーネントもあります:

-   **部分的なデザイン** - 部分的なデザインを使うページはその依存関係です。
-   **出版グループ** - 出版グループ内のすべての項目は互いに依存しています。

### 依存関係の計算と解決

アイテムを公開すると、システムはEdgeやマスターデータベースにクエリし、そのアイテムに依存する他のアイテムをすべて検索し、公開パイプラインに追加します。これらのアイテムが公開されているため、新しいアイテムに依存するすべてのアイテムも公開されます。依存関係として特定されたアイテムは、変更されていなくても出版に含まれます。このプロセスは、新しい公開可能なアイテムが見つからなくなるまで繰り返されます。

依存関係はアイテムレベルで計算されるため、どの変更がアイテムの公開を引き起こしているかを特定することはできません。例えば、ナビゲーションのページのデータソース項目を変更するとします。そのページはデータソースの項目に依存し、ナビゲーションコンポーネントによってレンダリングされるため、ナビゲーションコンポーネントを含むページは再公開されます。

ExperienceEdge.ComputeContentDependencies設定は、公開プロセス中にサポートされているリンクおよびリストフィールドタイプで参照されるアイテムの依存関係が計算されるかどうかを制御します。この設定はデフォルトで無効化されています。有効化すると、参照されたアイテムは依存関係として保存されるため、変更された参照項目を公開すると依存項目も再公開できます。この設定を有効または無効にした後は、サイトを再公開し、Experience Edge内のすべてのアイテムの依存関係データを再計算する必要があります。この設定は環境変数(Sitecore\_ExperienceEdge\_dot\_ComputeContentDependencies)を使って設定することも可能です。

> !注依存関係解決プロセスはワークフローを実装する主な理由の一つです。あるユーザーが変更を加えることで、別のユーザーが作業中のページが公開される可能性があります。ドラフト状態と公開ステータスからなる単純な2ステップワークフローでも、ウェブサイトが完成したコンテンツのみを表示することを確実にするのに十分です。

### エッジランタイムパブリッシングの利点

[SitecoreAI](https://doc.sitecore.com/sai/en/users/sitecoreai/sitecoreai.html)の顧客はEdgeランタイム公開を選択できます。 [この公開方法を選択する](https://doc.sitecore.com/sai/ja/developers/sitecoreai/experience-edge/publishing-to-experience-edge/enable-edge-runtime-publishing.html "Enable Edge runtime publishing")と、データソースのアイテムが公開された際にそれに依存しているアイテムの公開がトリガーされません。これにより、膨大な数のアイテムの連鎖公開がなくなります。レイアウトは公開時ではなく配信時(ランタイム)に組み立てられ、公開速度は向上しますが、初期配信は遅くなります。

スマートパブリッシュは依存関係を計算する前にどのアイテムを公開するかを決めます。エッジのランタイムパブリッシングとスマートパブリッシュを組み合わせることで、変更されていないアイテムや依存関係をスキップできます。

> !注[コンテンツリゾルバ](https://doc.sitecore.com/sai/ja/developers/sitecoreai/content-modeling-and-presentation/content-resolvers.html) はEdgeのランタイムパブリッシングではサポートされていません。

以下は、どの公開メカニズムがあなたの実装に最適かを判断するための比較表です:

機能

スナップショット

エッジランタイムパブリッシング

コメント

出版時期

基準速度。

より速く、通常は公開される項目数が少なくなります。

エッジランタイムの公開は、公開アイテムの数を減らすことで公開を最適化します。

発行された団体

すべての依存関係です。

レイアウトのみ、またはデータソースのみ。

エッジランタイムはより選択的で、オーバーヘッドを削減できますが、コンテンツの欠落を防ぐために慎重な依存管理が必要になる場合があります。

統合GraphQL

公開時に計算。再掲載後のみ更新。

Edgeは実行時に動的にフェッチされ、使用されるすべての場所でリアルタイムで正しくレンダリングされます。ただし、統合されたGraphQLを含む多数のコンポーネントや、複数または入れ子状のクエリを含む統合GraphQLクエリは、実行時にページパフォーマンスの問題を引き起こす可能性があるため避けることを推奨します。

動的フェッチは統合GraphQLクエリを正しくレンダリングするのに非常に適していますが、統合GraphQLを重度または複雑な使用を行う場合、実行時のパフォーマンスリスクが生じます。監視と最適化が鍵となります。

キャッシュクリア後の最初の応答

もっと速く。

遅くなります。Vercelのようなフロントエンドホスティングアプリケーションでは、静的サイト生成(SSG)を使用している場合、ビルドタイムアウトがより頻繁に発生することがあります。Edgeランタイムパブリッシングと組み合わせたオンデマンドのインクリメンタル静的再生(ISR)を推奨しており、これによりコンテンツが常に提供されます。

エッジの実行時間は、特に静的ホスティング環境では初期に遅くなることがあります。ISRを使うことで、特に頻繁にコンテンツ更新が行われるウェブサイトではこの問題を緩和できます。

コンテンツリゾルバ

サポートされています。

サポートされていません。

### 削除

親項目の子項目(サブアイテム)を公開する際、公開パイプラインはEdge上の子項目とCMSバックエンドの子項目を比較します。Edgeに存在する項目がCMSに欠落しているか、制限により公開対象でない場合、その項目とその子項目はEdgeから削除されます。

また、CMSからの削除記録を含む変更履歴に依存するため、インクリメンタル公開を実行する際に自動削除がトリガーされることがあります。インクリメンタル公開はコンテンツエディターのリボンにある **「公開** 」メニューで利用可能です。

## ベストプラクティス:パフォーマンス向上のためのバッチ公開

単一のアイテムに対して多数の小規模なパブリッシングジョブをトリガーするのは、複数のアイテムを一括でまとめて公開するよりも効率が悪く、パブリッシュ時間が大幅に長くなる可能性があります。各パブリッシュジョブには、どれだけのアイテムが入っていても、パブリッシュパイプラインの準備やキャッシュの更新・クリアなど、固定されたオーバーヘッドが発生します。したがって、多くの小さなパブリッシュジョブを作成するには、そのオーバーヘッドを何度も繰り返すことになります。アイテムを1つのパブリッシュジョブにまとめることで、セットアップとキャッシュのクリアが一度だけ行われるため、このオーバーヘッドが軽減されます。

以下の図は、1つのジョブで6つのアイテムを公開した場合と、それぞれ1つのアイテムをそれぞれ6つの別々の出版ジョブで公開した場合の比較時間を示しています。

![A diagram contrasting publish time for single-item versus batch publishing.](https://doc.sitecore.com/api/markdown-image/sai/ja/developers/sitecoreai/images/BatchVSingle.png)

サイト全体を公開せずに複数のアイテムを公開するには、コンテンツエディターで親項目を選択し、「 **サブアイテムを公開** 」オプションを使うか、自動化を使ってアイテムを単一の公開操作にまとめることができます。

ページビルダーで複数のアイテムを公開する際の公開性能を向上させるために、サイト全体を公開するのではなく、選択されたページと参照項目のみを公開してください。