---
title: "Experience Edgeのベストプラクティス"
slug: "experience-edge-best-practices"
abstract: "Experience Edgeをより効率的に活用するためのおすすめ。"
---
# Experience Edgeのベストプラクティス

このトピックで推奨される実践に従い、Experience Edgeをより効率的に活用してください。

## Context IDをブラウザに公開するのは避けてください

プレビュー GraphQL APIと配信GraphQL API、フロントエンドアプリからのSitecoreリクエストを認証するための [コンテキストIDが必要です](https://doc.sitecore.com/sai/ja/developers/sitecoreai/experience-edge/experience-edge-apis/authorization-and-api-access.html "Authorization and API access") 。もしアプリがブラウザから直接GraphQLリクエストを行う場合(クライアントサイドJavaScript)、Context IDはネットワークトラフィックやブラウザ開発者ツールで確認され、誰でも閲覧してSitecoreコンテンツのクエリに再利用できます。

クライアント側のクエリは、例えば「入力しながら検索する」ユーザーインターフェースや、パーソナライズされたコンテンツを遅く読み込む際に発生することがあります。

コンテキストIDを守るために、サーバー上に保管し、絶対にブラウザに届かせないようにしてください。これを実現する最も簡単な方法は、[スコープ付きのコンテキストID](https://doc.sitecore.com/portal/en/developers/sitecore-cloud-portal/manage-context-ids.html#create-a-scoped-context-id)を作成し、サーバー側のAPIアクセスを制限することです。あるいは、クエリをサーバーレス関数やAPIルート、または類似のサーバーサイドプロキシ経由でルーティングすることもできます。こうしてブラウザはプロキシ(例えば /api/searchのAPIルート)を呼び出し、プロキシはコンテキストIDを使ってGraphQLリクエストを行います。これにより、ブラウザはContext IDを一度もサーバーから離れないため、IDを認識しません。

静的またはサーバーレンダリングのコンテンツでは、GraphQLリクエストはそもそもサーバーから離れないため、明示的なプロキシは必要ありません。

## プレビューとデリバリーの両方で大きなクエリをテストしてください

クエリの複雑度はプレビュー GraphQL APIとデリバリー GraphQL API[で計算方法が異なる](https://doc.sitecore.com/sai/ja/developers/sitecoreai/experience-edge/experience-edge-apis/differences-between-the-preview-and-the-delivery-graphql-apis.html "Differences between the Preview and the Delivery GraphQL APIs") ため、特にクエリ複雑度の上限に近い場合は、重要なクエリを両エンドポイントに対して検証することをお勧めします。

## ページクエリにグローバルデータを含まないでください

プレビュー GraphQL APIとデリバリー GraphQL APIから返されるレイアウトデータでは、レンダリングデータが特定のページとまとめられています。ナビゲーションメニューやフッターリンクなどのグローバルデータをページレベルの出力に埋め込むと、ナビゲーションアイテムの名前変更などグローバルデータの変更は、それを含むすべてのページを再公開しなければなりません。これは各ページのキャッシュを無効化し再生成する必要があるためです。

代わりに、[専用のGraphQLクエリ](https://doc.sitecore.com/sai/ja/developers/sitecoreai/experience-edge/experience-edge-apis/query-examples-for-the-delivery-graphql-api.html "Query examples for the Delivery GraphQL API")を使って、そのグローバルデータを別途取得してください。この方法なら、ナビゲーションの変更はその1回のクエリの結果を更新するだけで済み、サイト全体の再公開をトリガーしません。

ページのレイアウトサービス出力にグローバルデータを入力すると、データ変更には再公開が必要です。例えば、ページヘッダーやフッターで使われるナビゲーションデータなどです。代わりにレンダリングホストからのGraphQL呼び出しを使ってこのデータを取得することを検討してください。

## GraphQLクエリで変数を使う

動的値をクエリ文字列に直接埋め込むのではなく [、変数](https://doc.sitecore.com/sai/ja/developers/sitecoreai/experience-edge/experience-edge-apis/set-up-the-graphql-ides.html#use-query-variables) として渡してください。変数はクエリ構造をデータから分離し、文字列連結のリスクを減らし、クライアントやサーバーの動作をより安全かつ予測可能にします。変数を使うクエリはリクエスト間で安定した文字列を持つため、GraphQLサーバーは新しい文字列を再度解析する代わりに解析・検証済みのクエリドキュメントを再利用できます。その再利用は、解析や検証のオーバーヘッドを削減するパフォーマンス最適化です。

各クエリに一貫した記述的な操作名を付けます。同じクエリ形状でも名前は固定しておき、キャッシュヒットを最大化しましょう。意図的に別々のキャッシュ動作が必要な場合を除いて。 LayoutQueryのような安定した名前は、サーバーログやトレースツール、分析ツールで遅いクエリや失敗しているクエリを特定しやすくします。

## Experience Edgeから内部サイトを除外する

SitecoreAIには内部の非生産サイトがあるかもしれません。これらのサイトやそのコンテンツが配信GraphQL APIで利用できないようにするには、[内部サイトとしてマーク](https://doc.sitecore.com/xp/en/developers/sxa/104/sitecore-experience-accelerator/exclude-non-content-sites-from-experience-edge-1188168.html)することができます。