User-Agent でリクエストを照合し、ループ防止が施された Profound 自身のフェッチを除外したうえで、一致するリクエストを、API キーと公開ホストをリクエストヘッダーとして付与して Profound にリライトします。
アプリケーション側の変更は一切ありません。Vercel のエッジネットワークは関数の実行前にルールを評価し、サポート対象のアシスタント以外からのリクエストがこのルールに一致することはありません。
リクエストは https://concierge.tryprofound.com/v1/concierge/vercel/{path} にリライトされます。Profound はリライトされた URL から元のパスとクエリを復元するため、x-concierge-url ヘッダーを管理する必要はありません。どのパスをレンダリングするかは、ルールではなく Profound のポリシーによって決まります。オプトインしていないパスに対するアシスタントのリクエストは、そのままデプロイメントに渡されます。
前提条件
- デプロイ可能な Vercel プロジェクト
- Dynamic Bot Rendering の API キー、登録済みのドメイン、公開ページをオプトインするポリシー、および既知の公開済みテストページ。始める前にを参照してください。
- デプロイ保護、ファイアウォールのルール、ボットチャレンジが、アクセス制御を弱めることなく、アシスタントのトラフィックと Profound のオリジンフェッチを許可していることを確認してください。
セットアップ
1
API キーをプロジェクトの環境変数に追加する
Vercel ダッシュボードで Project → Settings → Environment Variables を開き、以下を追加します。
キーはルールファイルではなく、必ず環境変数に保存してください。ルールファイルはリポジトリにコミットされます。
2
ルーティングルールを追加する
プロジェクトの設定に次のルートを追加し、
www.example.com を登録済みの公開ホストに置き換えます。プロジェクトですでに使用しているファイルを使ってください。3
デプロイして検証する
プロジェクトをデプロイしてから、次を実行します。HTTP ステータス、有効な
x-concierge-request-id、想定どおりの x-concierge-bot-kind を確認します。既知の公開済みページでは、x-concierge-cache: HIT と想定どおりのレンダリング済みボディも必須です。ブラウザーのリクエストと検索クローラーが既存の動作を維持していること、および x-concierge-request: 1 を含むリクエストがデプロイメントに直接到達することを確認してください。GET リクエストを送信してください。Profound の仕様は GET のみを対象としているため、curl -I ではなく curl -sD - -o /dev/null を使用します。すべてのチェック項目については、検証とトラブルシューティングを参照してください。ルールの各部分の役割
一致する
User-Agent からの GET 以外のリクエストもリライトされ、Profound から 405 が返されます。サポート対象のアシスタントは GET でページを取得するため、通常のトラフィックには影響しません。その他のメソッドをデプロイメントに留めたい場合は、ルートに "methods": ["GET"] を追加してください。
複数のドメイン
x-concierge-host の transform は固定の文字列であるため、1 つのルールで配信できる公開ホストは 1 つです。1 つの Vercel プロジェクトで複数の登録済みドメインを配信する場合は、ホストごとにルートを 1 つ追加し、それぞれを host ヘッダーに対する has 条件で絞り込んでください。
プレビューデプロイメント
上記のルールは、プレビューデプロイメントを含め、プロジェクトが配信するすべてのホスト名で実行されます。x-concierge-host は固定されているため、プレビューのリクエストは Profound には本番環境として識別されます。ステップ 1 のように PROFOUND_CONCIERGE_KEY のスコープを Production のみに設定すると、プレビューのリクエストには展開されていないリテラルのキーが含まれ、Profound が 401 で拒否するため、本番環境のコンテンツが配信されたりレンダリングされたりすることはありません。
プレビューホストに対するアシスタントのリクエストを、代わりに通常どおりプレビューデプロイメントに到達させたい場合は、複数のドメインの host 条件を追加して、ルールが本番環境のホスト名にのみ一致するようにしてください。未設定の変数がどのように処理されるかについては、ルートでの環境変数の使用を参照してください。
キャッシュとコンテンツのチェック
トラフィックを有効にする前に、デプロイされたリライトのキャッシュ動作を確認してください。2026 年 4 月 6 日以降に作成されたプロジェクトでは、Vercel はデフォルトでアップストリームのキャッシュヘッダーに従います。それより前のプロジェクトは、プロジェクト設定またはx-vercel-enable-rewrite-caching でオプトインできます。このヘッダーを 0 に設定するとオプトアウトになります。デフォルトを前提とせず、プロジェクトの作成時期、現在の設定、ルートのオーバーライドを確認してください。レンダリング済みのレスポンスに Cache-Control: no-store が付いていると想定しないでください。Vercel アダプターはそれを保証しません。キャッシュルールによってこれらのレスポンスがキャッシュ可能になる場合は、アシスタントと人間のレスポンス間、およびホスト、パス、クエリのバリアント間で分離されていることを確認してください。キャッシュが有効な場合は、置き換えの公開、公開の取り消し、配信の一時停止を行った後の有効期限と無効化を確認してください。CDN のエントリーは、Profound での変更後も残る可能性があります。
Profound は閲覧者の Cookie や認可情報をオリジンに転送せず、保存されたページはセッション、言語、地域によってパーソナライズされません。ページをオプトインする前に、同一 URL のロケールやヘッダーによるバリアントをレビューしてください。
セキュリティに関する注意事項
- ループマーカーは、仕様上クライアントが偽装できます。
x-concierge-request: 1を送信すれば誰でもリライトをスキップし、オリジンのライブページを取得できます。これは、アシスタント以外のUser-Agentが受け取るものと同じコンテンツです。そのリクエストについては、レンダリングとテレメトリーがスキップされます。このマーカーを認証やファイアウォールのチェックのバイパスに使用しないでください。 - キーはリポジトリに含まれません。 キーはプロジェクトの環境変数から参照され、ルールファイルに書き込まれることはありません。
- Profound はアシスタントを独自に判定します。 呼び出し元が指定した識別ヘッダーは信頼せず、転送された
User-Agentのみを使用します。 - Profound を経由してオリジンに認証情報が届くことはありません。 ルールはアシスタントが送信したヘッダーをそのまま転送しますが、Profound はオリジンからの取得時に Cookie と認可ヘッダーを削除し、オプトインした公開ページのみをレンダリングします。