User-Agent によって AI アシスタントのトラフィックを識別し、Profound に転送します。オプトインした公開ページについては、公開済みの事前レンダリング版が存在する場合、Profound がそれを返します。それ以外の場合は、オリジンからのライブレスポンスをそのまま返します。人間の訪問者、検索クローラー、API 呼び出し、アセットは、既存のルートから外れることはありません。
Dynamic Bot Rendering は Profound の Concierge サービスによって提供されるため、リクエストヘッダーとレスポンスヘッダーには
x-concierge- というプレフィックスが使用されます。リクエストの流れ
1
CDN がリクエストを分類する
ルーティングルールが
User-Agent をサポート対象のアシスタント一覧と照合します。一致したリクエストのみが Profound に送られます。Cloudflare と CloudFront の例では、ルーティングをパスの許可リストにも制限しています。Vercel のルールはすべてのアシスタントトラフィックを転送し、判断を Profound のポリシーに委ねます。2
CDN がリクエストを Profound に転送する
ルールは、API キー、公開ホスト、元のパスとクエリを信頼済みヘッダーとして付与します。これらの値は、クライアントが送信したヘッダーからではなく、ルール自身の設定と解析済みのリクエストから設定されます。Profound は、クライアントが指定した
x-concierge-* の識別ヘッダーを無視します。3
Profound が公開済みレンダリングを配信するか、オリジンにフォールバックする
Profound は API キーを確認し、ホストが貴社の組織に登録されていることを確認したうえで、そのパスのポリシーを解決します。パスに公開済みレンダリングがあり、ポリシーで配信が許可されている場合、Profound はそのレンダリングを返します。それ以外の場合は、オリジンからページを取得し、ライブレスポンスを変更せずに返します。ポリシーによっては、このミスをきっかけに、新しい候補としてページのバックグラウンドレンダリングがスケジュールされることもあります。
4
アシスタントがページを受け取る
公開済みレンダリングは完全にレンダリングされた HTML であり、ブラウザーで JavaScript を実行した後に生成されるページと同じものです。レンダリングによってコンテンツはアシスタントにとって読み取り可能になりますが、回答への掲載や引用を保証するものではありません。
サポート対象の AI アシスタント
Profound は、すべてのリクエストで元のUser-Agent からアシスタントを識別します。その際、CDN ルールで照合するものと同じトークンを使用します。照合は大文字と小文字を区別しない部分一致で行われます。
検索クローラーのルーティング
通常の Googlebot や Bingbot のリクエストは上記の一覧に含まれないため、既存のルートのまま処理されます。ロールアウト前に、サイトのキャッシュルールとエッジルールをテストしてこれを確認してください。Dynamic Bot Rendering はクローキングを行いません。レンダリングされたページは、ブラウザーで JavaScript を実行した後に生成されるページと同じものです。レンダリングと配信の制御方法
特定の URL に対してアシスタントが何を受け取るかは、2 つの独立した設定によって決まります。- ポリシー は、「Profound はこのパスに対して保存済みコンテンツを配信してよいか、またどのアシスタントに配信するか」を決定します。
- 公開 は、「このパスでどのレンダリングがライブになっているか」を決定します。
off ポリシーの下にある公開済みページは何も配信しません。公開されていないパスに serve ポリシーを設定した場合は、オリジンにフォールバックします。どちらも Profound のダッシュボードでご自身で管理します。
ポリシーモード
off は、どのルールにも該当しないパスのデフォルトです。新しく登録したドメインは、ルールでパスをオプトインするまで何も行わないため、何をレンダリングするかを決めるまでオンボーディングによる影響はありません。配信を開始する前にレビュー用の候補を蓄積するには warm を使用します。serve がそれ自体で何かを公開することはなく、既存の公開済みレンダリングの配信を許可するだけです。
ルールと優先順位
すべてのルールは、登録済みのドメイン 1 つに属します。ドメインデフォルト はホスト全体のベースラインを設定し、ページルール は特定のパスについてそれを上書きします。ページルールは、完全一致のパス(任意でクエリ文字列に固定可能)、パスのプレフィックス、または/blog/* のような glob に一致します。プレフィックスルールと glob ルールは、クエリ文字列を除いたパスで照合されます。
Profound はリクエストごとに、適用するルールを 1 つ選択します。
- パスとクエリ文字列に完全一致するルール。
- それがなければ、パスに完全一致するルール。
- それもなければ、最も一致するプレフィックスまたは glob ルール。優先度の高いものが優先され、次により具体的なパターンが優先されます。
- それもなければ、ドメインデフォルト。
- ルールがまったくない場合、有効なモードは
offです。
serve、/docs/* ルールが warm、そして許可するアシスタントのみを変更する /docs/start の完全一致ルールがある場合、/docs/start は serve に解決されます。/docs/* ルールは影響しません。
ルールは無効化することもできます。無効なルールは完全にスキップされるため、そのパスにはドメインデフォルトまたは一致する別のルールが適用されます。したがって、パスを除外していた off ルールを無効化すると、配信が再びオンになる場合があります。パスをオリジンのままにしておくには、モード off の有効なルールを使用してください。
ルールごとの設定
各ルールでは、以下の任意の項目を設定し、残りを継承できます。- モード。 前述の
off、warm、serveのいずれか。 - 許可するアシスタント。 一致したパスで処理対象となるサポート対象アシスタントを制限します。未設定の場合はドメインの一覧を継承し、どこにも一覧が設定されていない場合は、サポート対象のすべてのアシスタントが対象になります。一覧は継承した一覧と交差するのではなく置き換わり、空の一覧はすべてのアシスタントを除外します。除外されたアシスタントは、有効なポリシーが
offとしてオリジンのレスポンスを受け取ります。公開済みレンダリング自体は共有されるため、アシスタントごとに異なるバージョンを公開することはできません。 - 自動レンダリング。 モードとは独立して、バックグラウンドでの候補レンダリングを許可またはブロックします。自動レンダリングをオフにした
serveは、手動で公開したものだけを配信します。offは、この設定にかかわらず自動でレンダリングすることはありません。
ドメインの一時停止
ドメインを一時停止すると、登録、ルール、レンダリング、公開済みのものはそのまま維持しつつ、そのホストに対するすべてのアシスタントリクエストがオリジンに送られます。再開すると、保存されていた動作が復元されます。CDN やルールに手を加えずに、すばやく配信を停止したい場合に一時停止を使用してください。一時停止中でも、ページのレンダリング、レビュー、公開は引き続き行えます。レンダリングからライブページまで
すべてのレンダリングは 候補 として始まります。候補とは 1 つの URL の保存済みスナップショットで、対象となるリクエストによってバックグラウンドで作成されるか、オンデマンドで作成されます。1 つの URL に複数の候補が蓄積されることがあります。いずれかを公開するまで、どの候補も配信されません。1
レビュー
その URL で現在公開されているページと大きく異なる候補は、pending として保留されます。これは、表示テキストがライブページのごく一部にまで減少した場合や、タイトルと最初の見出しの両方が変更された場合に発生します。候補をプレビューしてから、承認または却下してください。承認は公開の対象としてマークするだけで、それ以外の処理は行いません。URL にまだ公開済みページがない場合は比較対象がないため、候補は承認済みとして保存されます。
2
公開
公開では、特定のレンダリングを 1 つ選択し、その URL のライブページにします。pending の候補を公開すると、同じステップで承認も行われます。却下された候補は公開できません。
3
ロールバック、公開取り消し、置き換え
ロールバックとは、同じ URL の以前のレンダリングを公開することです。公開を取り消すとライブページが削除され、アシスタントはオリジンに戻りますが、レンダリング履歴は保持されます。現在公開中のページを却下した場合も、公開が取り消されます。コンテンツを更新するには、新しい候補をレンダリングしてレビューし、公開してください。
/pricing を公開しても /pricing?plan=pro は公開されず、各バリアントはそれぞれ個別にレンダリング、レビュー、公開されます。
設計によるフェイルオープン
フェイルオープンは 2 つのレイヤーで行われ、どちらか一方だけですべての障害をカバーできるわけではありません。CDN レベルのフェイルオーバー
Cloudflare Worker は、フェッチの失敗、レスポンスヘッダーの期限超過、設定したステータスの一覧に該当する場合に、オリジンへ再試行します。CloudFront は、障害条件とタイムアウトを設定したオリジングループを使用します。Vercel のルーティングルールには CDN レベルのフェイルオーバーはありません。
サービスレベルのフェイルオープン
リクエストが認証され有効であれば、Profound は保存済みレンダリングを配信できないときは常にオリジンから取得します。たとえば、公開済みのものがない場合、ポリシーが
off または warm の場合、不明なアシスタントの場合、レンダリングを読み取れない場合、内部の検索に失敗した場合などです。この場合でも、オリジンに到達できる必要があります。x-concierge-* レスポンスヘッダーを確認してください。
対象範囲と制限事項
GETのみ。HEADを含むその他のメソッドは対象外です。テストの際は、curl -Iではなくcurl -sD - -o /dev/nullを使用してください。- パーソナライズされていない公開ページのみ。 Profound のポリシールールでも、CDN ルールのパス許可リストでも、レビュー済みの公開ページのみをオプトインしてください。拡張子のないパスだからといってページであるとは限りません。API、GraphQL、認証、管理、フレームワークのリソース、セッションに依存するルートは除外してください。Cloudflare と CloudFront の例では
/、/pricing、/docs、/docs/getting-startedのみを許可しています。これらはご自身のパスに置き換えてください。 - クエリ文字列はページ識別の一部です。
/products?id=aと/products?id=bは別々のページとして、個別に保存およびレンダリングされます。 - ルールごとに 1 つのホスト。 ルールが送信する公開ホストは、Profound に登録されたドメインと一致している必要があります。複数のホストを配信するには、ホストごとに 1 つのルールを使用します。
- Profound を経由してオリジンに認証情報が届くことはありません。 Profound はオリジンから取得する際に、閲覧者の Cookie や認可ヘッダーを転送しません。また、サンプルのルールでは、認証情報を含むリクエストは既存のルートのまま処理されます。保護されたページはログインページや公開コンテンツとしてレンダリングされる場合がありますが、これは漏洩ではなく互換性上の境界です。
- 訪問者ごとではなく URL ごとに 1 つのレンダリング。 保存済みレンダリングは、セッション、言語、地域、その他のリクエストヘッダーによって変わることはありません。同じ URL がこれらのシグナルによって異なるコンテンツを配信する場合は、許可リストに追加する前にレンダリングをプレビューし、1 つのバージョンがすべてのアシスタントにとって許容できることを確認してください。
始める前に
CDN を設定する前に、Profound のダッシュボードで以下の手順を完了してください。CDN が呼び出す Dynamic Bot Rendering のエンドポイントはhttps://concierge.tryprofound.com です。
また、何かを変更する前に、既存の CDN のルート、関数、キャッシュポリシー、ロールバック設定を記録しておいてください。さらに、Web アプリケーションファイアウォール(WAF)のルール、ボットチャレンジ、デプロイ保護、オリジンの許可リストが、アシスタントのリクエストと Profound によるオリジンからの取得の両方を通過させることを確認してください。オリジン側で Profound による取得を識別する方法が必要な場合は、Profound サポートにお問い合わせください。
1
ドメインを登録する
Profound のダッシュボードで Dynamic Bot Rendering を開き、配信している正確な公開ホスト(
www.example.com など)を追加します。ホストは公開 DNS で名前解決でき、HTTPS で応答する必要があります。訪問者が実際にアクセスするホストを登録してください。apex ドメインが www にリダイレクトする場合は、apex ではなく www ホストを登録し、内部のオリジンホスト名は登録しないでください。ホスト名は登録後に変更できません。2
API キーを作成する
Dynamic Bot Rendering の API キーを作成してコピーします。生の値は一度しか表示されないため、すぐに CDN のシークレットストアに保存してください。1 つのキーで、後から追加するドメインを含め、組織に登録されたすべてのドメインをカバーできるため、ほとんどのお客様に必要なキーは 1 つだけです。ダウンタイムなしでローテーションしたい場合や、プロパティごとにローテーションと失効を個別に管理したい場合は、追加のキーを作成してください。追加のキーも組織全体で有効であり、1 つのプロパティに限定されるわけではありません。
3
ポリシーを設定し、テストページを公開する
少なくとも 1 つの公開ページをモード
serve でオプトインするポリシーをドメインに設定し、そのページの候補をレンダリングしてレビューし、公開します。検証のために、公開した URL と想定される HTML を控えておいてください。CDN の設定後、その URL に対するアシスタントのリクエストは、x-concierge-cache: HIT とレンダリング済みの HTML を返すはずです。リクエストを繰り返しても公開の代わりにはなりません。レンダリングが公開されるまで、MISS は MISS のままです。CDN を選択する
Cloudflare
ゾーンに Worker を 1 つ追加します。
Amazon CloudFront
Lambda@Edge を使わずに、CloudFront Function を 1 つ追加します。
Vercel
vercel.json にルーティングルールを 1 つ追加します。GET リクエストに付与する 3 つのリクエストヘッダーです。Profound サポートにお問い合わせいただければ、対応付けをお手伝いします。