ドキュメントLLM Optimizer

Azure正面玄関（BYOCDN）

最終更新日： 2026年6月16日

作成対象：

  • {"id":"c66ffd68-0f65-42bb-aa23-b4020f12e0bd"}

この設定では、エージェントトラフィック（AI ボットおよび LLM ユーザーエージェントからのリクエスト）を Edge での最適化バックエンドサービス（live.edgeoptimize.net）にルーティングします。 人間の訪問者と SEO ボットは、通常どおりオリジンから引き続き提供されます。 設定をテストするには、設定が完了したら、応答のヘッダー x-edgeoptimize-request-id を探します。

Azure Front Doorでは、エッジでカスタムコードを実行しません。 ルーティングは、ルールセット​と専用の​ オリジングループ ​を使用してEdge Optimize用に設定されます。 フェールオーバーは、Azure Front Doorの優先度ベースのオリジングループ ヘルスプローブによって処理されます。

前提条件

Azure フロントドアのルーティングルールを設定する前に、次のことを確認してください。

  • Azure Front Doorのプロフィールにアクセスします。
  • LLM Optimizer UI から取得された Edge Optimize API キー。 手順について詳しくは、API キーの取得を参照してください。
  • （オプション）ステージングルーティングをテストするには、Staging API キーを参照してください。

手順1:Edge Optimizeのオリジンのグループを作成する

Azure Front Door プロファイルには、既に、オリジンを指すデフォルトのオリジン グループがあります。 Edge Optimize用に​new オリジン グループを作成します。

  • 名前： edge-optimize-origin-group

  • 発信元（優先ベースのフェールオーバー）:

    • 優先度1 — live.edgeoptimize.net （オリジン ホスト ヘッダー：live.edgeoptimize.net）
    • 優先度2 — ドメイン エンドポイント （例：www.example.com）。 これはフェールオーバー用です。Edge Optimizeが正常でない場合、リクエストはドメインにルーティングされ、Azure フロントドアに再エントリし、デフォルトのオリジンから提供されます。

  • 正常性プローブ： 有効

    • パス：/health/<your-domain> （例：/health/www.example.com）
    • プロトコル：HTTPS
    • 間隔：225秒

  • セッションの親和性： 無効

  • 証明書の件名の検証： 有効

Edge Optimize origin groupと2つの優先度ベースのオリジンとヘルスプローブ ​

NOTE
edge-optimize-origin-groupの発信元グループに、ポータルに​**「関連付けられていません」**​の警告が表示されます。 これは想定されています。ルートから直接ではなく、ルールセットのルートオーバーライドを使用して参照されます。

手順2：ルートの設定

デフォルトのルートは、通常、Azureのフロントドアのプロファイルで作成されます。 ルールセット（ステップ 3）は、エージェント型トラフィックのオリジングループを上書きするため、Edge Optimizeに個別のルートは必要ありません。

手順3：ルールセットの作成

ルールセット > ルールセット​に移動し、EORoutingという名前を付けます。 この順序で3つのルールを追加します。

ヘッダーストリッピングとボットルーティングのルールを示す EORouting ルールセット ​

ルール 1: StripIncomingEOHeaders01

Edge Optimizeの受信ヘッダーを削除して、スプーフィングを防止します。 条件なし – すべてのリクエストに適用されます。 評価を停止：オフ。

アクション – 各件のリクエストヘッダーを削除：

  • x-edgeoptimize-url
  • x-edgeoptimize-config
  • x-edgeoptimize-api-key
  • x-edgeoptimize-fetcher-key

ルール 2: EOGPTBotRootGET03

HTML ページパスのボットリクエストをEdge Optimizeにルーティングします。 評価を停止：上。

条件 （すべて一致する必要があります）:

  • リクエストメソッド：次と等しい GET
  • リクエストパス：RegEx (^$|^.*/$|(^|.*/)[^./]+$|^.*\.html$) （サイトルート、/で終わるパス、拡張機能のないページパス、.html個のパスに一致）
  • User-Agent: いずれかの chatgpt-user、gptbot、oai-searchbot、adobeedgeoptimize-ai、perplexitybot、perplexity-user、claudebot、claude-user、claude-searchbotが含まれます。 文字列変換を​ 小文字 ​に設定します。
  • x-edgeoptimize-monitor: 含まれていません 1
  • x-edgeoptimize-request: ​​failover、1のいずれも含まれていません

アクション:

  • リクエストヘッダーの上書きx-edgeoptimize-url = /{url_path}?{query_string}
  • リクエストヘッダーの上書きx-edgeoptimize-config = LLMCLIENT=TRUE;
  • リクエストヘッダーの上書きx-edgeoptimize-api-key = YOUR_API_KEY
  • リクエストヘッダーの上書きx-edgeoptimize-monitor = 1
  • ルート設定の上書き：発信元グループ → edge-optimize-origin-group、転送プロトコル →着信要求の一致、キャッシュ → 無効

ルール 3: HealthProbeRewrite03

Azure Front Door ヘルスプローブのリクエストを書き換えて、/health/<domain>ではなく/としてオリジンに到達させます。 これにより、Azure Front Doorは、オリジンに専用のヘルスエンドポイントを必要とせずに、Edge Optimizeの可用性を監視できます。 評価を停止：上。

​ ヘルスプローブの書き換えルール ​

条件 （すべて一致する必要があります）:

  • リクエスト URL パス：が /health/で始まります
  • x-fd-healthprobe: 次を含む 1

アクション:

  • URL書き換え – Source パターン：/health/、宛先：/
  • 応答ヘッダーの上書きcustom-origin-health = routed （診断 – 検証後に削除できます）
  • Request header append user-agent = AdobeEdgeOptimize/1.0 （先頭のスペースを追加 – Azure Front Doorは値をそのまま追加します）
  • ルート設定の上書き：発信元グループ → default-origin-group、転送プロトコル →着信要求の一致、キャッシュ → 無効

手順4：ルールセットをルートに関連付ける

ルートを開き、下部の「ルール」セクションまでスクロールし、ドロップダウンから「EORouting」ルールセットを選択します。 既存のルールセットがある場合は、上に移動​を使用して、EORoutingを​ #1 ​に配置します。 Edgeでの最適化ルールでは、エージェント型トラフィックとEdge Optimizeのループバックリクエストのみが処理されます。他のトラフィックは、他のルールに影響を与えずに通過します。 保存して反映を待ちます（約20分）。

ファイアウォールルールによるEdgeでの最適化を許可する（オプション）

CDNでWAFまたはBot Managerを使用している場合：

  • WAFまたはBot Managerで*AdobeEdgeOptimize/1.0* ユーザーエージェントを許可リストに加えるして、Optimize at Edge サービスがオリジンコンテンツを取得できるようにします。

  • ファイアウォールでユーザーエージェント以外の追加の検証が必要な場合は、秘密鍵（例：openssl rand -hex 32）を生成し、次の操作を行います。

    • ルーティングルールのシークレットを他のx-edgeoptimize-* ヘッダーと共にx-edgeoptimize-fetcher-keyを追加します。
    • WAFまたはBot Manager ルールを追加して、x-edgeoptimize-fetcher-keyが同じシークレットと一致するリクエストを許可します。

  • Edgeで最適化すれば、このヘッダーをそのまま転送できます。ユーザーは鍵のライフサイクル全体を所有しています。

設定の検証

設定が完了したら、ボットトラフィックが Edge での最適化にルーティングされていることと、人間のトラフィックに影響がないことを確認します。

1. ボットトラフィックをテスト（最適化する必要があります）

エージェント型ユーザーエージェントを使用して、AI ボットリクエストをシミュレートします。

curl -svo /dev/null https://www.example.com/page.html \
  --header "user-agent: chatgpt-user"

正常な応答には、リクエストが Edge での最適化を経由してルーティングされたことを確認する x-edgeoptimize-request-id ヘッダーが含まれます。

< HTTP/2 200
< x-edgeoptimize-request-id: 50fce12d-0519-4fc6-af78-d928785c1b85

2. 人間のトラフィックをテスト（影響を受けません）

通常の人間によるブラウザーリクエストをシミュレートします。

curl -svo /dev/null https://www.example.com/page.html \
  --header "user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36"

応答には、x-edgeoptimize-request-id ヘッダーを含め​ ない ​でください。 ページのコンテンツと応答時間は、Edge での最適化を有効にする前と同じ状態を維持する必要があります。

3. 2 つのシナリオを区別する方法

ヘッダー
ボットトラフィック（最適化）
人間のトラフィック（影響を受けない）
x-edgeoptimize-request-id
存在 - 一意のリクエスト ID が含まれます
不在

トラフィックルーティングのステータスは、LLM Optimizer UIでも確認できます。 顧客設定​に移動し、CDN設定 タブを選択します。

AI エージェントへの最適化のデプロイ – 完了

利用可能なオポチュニティ、自動最適化ワークフロー、FAQなど、Edgeでの最適化について詳しくは、Edgeでの最適化の概要に戻ります。

recommendation-more-help
llm-optimizer-help-main-toc