> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryprofound.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Vercel のセットアップ
> アプリケーションコードを変更せずに、vercel.json の 1 つのルーティングルールで AI アシスタントのトラフィックを Profound Dynamic Bot Rendering にルーティングします。
このガイドでは、Vercel プロジェクトにルーティングルールを 1 つ追加します。このルールは `User-Agent` でリクエストを照合し、ループ防止が施された Profound 自身のフェッチを除外したうえで、一致するリクエストを、API キーと公開ホストをリクエストヘッダーとして付与して Profound にリライトします。
アプリケーション側の変更は一切ありません。Vercel のエッジネットワークは関数の実行前にルールを評価し、サポート対象のアシスタント以外からのリクエストがこのルールに一致することはありません。
リクエストは `https://concierge.tryprofound.com/v1/concierge/vercel/{path}` にリライトされます。Profound はリライトされた URL から元のパスとクエリを復元するため、`x-concierge-url` ヘッダーを管理する必要はありません。どのパスをレンダリングするかは、ルールではなく Profound の[ポリシー](/ja-jp/dynamic-bot-rendering/overview#how-rendering-and-serving-are-controlled)によって決まります。オプトインしていないパスに対するアシスタントのリクエストは、そのままデプロイメントに渡されます。
**ルールはダッシュボードではなく、`vercel.json` または `vercel.config.ts` で定義してください。** デプロイされた transform が、`$PROFOUND_CONCIERGE_KEY` をリテラルテキストとして送信するのではなく、環境変数を展開していることを確認してください。リテラル値は `401` と `x-concierge-auth: unknown-key` で拒否されます。
本番環境に適用する前に、機密ではないテスト用の変数と、管理下にある診断用エンドポイントを使用して、分離されたデプロイメントで環境変数の展開とルートの優先順位を検証してください。API キーを診断用エンドポイントに送信したり、ログに記録したりしないでください。既存のダッシュボードやフレームワークのルートが、テストしたルールを上書きしないことを確認してください。
**Vercel のルーティング統合には、CDN レベルのフェイルオーバーはありません。** Profound がオリジンにフォールバックするのは、リクエストが認証され有効であった場合のみです。この外部リライトには再試行先となるセカンダリオリジンがないため、Profound の障害やハードリジェクトがエラーとしてアシスタントに届く場合があります。
## 前提条件
* デプロイ可能な Vercel プロジェクト
* Dynamic Bot Rendering の API キー、登録済みのドメイン、公開ページをオプトインするポリシー、および既知の公開済みテストページ。[始める前に](/ja-jp/dynamic-bot-rendering/overview#before-you-start)を参照してください。
* デプロイ保護、ファイアウォールのルール、ボットチャレンジが、アクセス制御を弱めることなく、アシスタントのトラフィックと Profound のオリジンフェッチを許可していることを確認してください。
## セットアップ
Vercel ダッシュボードで **Project → Settings → Environment Variables** を開き、以下を追加します。
| 名前 | 値 | 環境 |
| - | - | - |
| `PROFOUND_CONCIERGE_KEY` | Dynamic Bot Rendering の API キー | Production のみ |
キーはルールファイルではなく、必ず環境変数に保存してください。ルールファイルはリポジトリにコミットされます。
プロジェクトの設定に次のルートを追加し、`www.example.com` を登録済みの公開ホストに置き換えます。プロジェクトですでに使用しているファイルを使ってください。
```json vercel.json theme={null}
{
"routes": [
{
"src": "^/(.*)$",
"has": [
{
"type": "header",
"key": "User-Agent",
"value": "(?i).*(?:duckassistbot|chatgpt-user|gemini-deep-research|perplexity-user|amzn-user|mistralai-user|claude-user|claude-code|codex).*"
}
],
"missing": [
{
"type": "header",
"key": "x-concierge-request",
"value": "^1$"
}
],
"dest": "https://concierge.tryprofound.com/v1/concierge/vercel/$1",
"transforms": [
{
"type": "request.headers",
"op": "set",
"target": {
"key": "x-concierge-api-key"
},
"args": "$PROFOUND_CONCIERGE_KEY",
"env": [
"PROFOUND_CONCIERGE_KEY"
]
},
{
"type": "request.headers",
"op": "set",
"target": {
"key": "x-concierge-host"
},
"args": "www.example.com"
}
]
}
]
}
```
```ts vercel.config.ts theme={null}
import type { VercelConfig } from '@vercel/config/v1';
export const config: VercelConfig = {
routes: [
// Route recognized assistants to Profound unless x-concierge-request is set to 1
{
src: '^/(.*)$',
has: [
{
type: 'header',
key: 'User-Agent',
value:
'(?i).*(?:duckassistbot|chatgpt-user|gemini-deep-research|perplexity-user|amzn-user|mistralai-user|claude-user|claude-code|codex).*',
},
],
missing: [
{
type: 'header',
key: 'x-concierge-request',
value: '^1$',
},
],
dest: 'https://concierge.tryprofound.com/v1/concierge/vercel/$1',
transforms: [
{
type: 'request.headers',
op: 'set',
target: {
key: 'x-concierge-api-key',
},
args: '$PROFOUND_CONCIERGE_KEY',
env: ['PROFOUND_CONCIERGE_KEY'],
},
{
type: 'request.headers',
op: 'set',
target: {
key: 'x-concierge-host',
},
args: 'www.example.com',
},
],
},
],
};
```
既存のルーティング、リダイレクト、認証、フレームワークの動作は維持してください。設定の検証結果と生成されたビルド出力を確認し、ルートの順序と既存のプロパティとの互換性をチェックしてください。現在の [Vercel のルーティングに関するドキュメント](https://vercel.com/docs/project-configuration/vercel-json#routes-vs-higher-level-properties)では、上位レベルのプロパティとの共存について説明しています。ルーティング設定を自動的に変換しないでください。統合のためにルーティングの再設計が必要な場合は、作業を中止し、別途レビューしてください。
プロジェクトをデプロイしてから、次を実行します。
```bash theme={null}
curl -sD - -o /dev/null https://www.example.com/pricing -A 'chatgpt-user'
```
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` を使用します。すべてのチェック項目については、[検証とトラブルシューティング](/ja-jp/dynamic-bot-rendering/verify-and-troubleshoot)を参照してください。
## ルールの各部分の役割
| 部分 | 目的 |
| - | - |
| `src` + `dest` | パス全体を `$1` としてキャプチャし、クエリ文字列を保持したまま Profound の Vercel エンドポイントにリライトします。レンダリングを配信するか、リクエストをデプロイメントにそのまま渡すかは、Profound がパスごとに判断します。 |
| `User-Agent` に対する `has` | [サポート対象のアシスタント](/ja-jp/dynamic-bot-rendering/overview#supported-ai-assistants)を大文字と小文字を区別せずに照合します。ブラウザーや検索クローラーは一致しないため、既存のルートから外れることはありません。 |
| `x-concierge-request` に対する `missing` | ループ防止。Profound は自身のオリジンフェッチに `x-concierge-request: 1` を付与します。この値を除外することで、それらのフェッチはルールをバイパスし、デプロイメントに直接到達します。 |
| `x-concierge-api-key` の transform | リクエスト時にプロジェクトの環境変数からキーを挿入します。 |
| `x-concierge-host` の transform | ルートごとにハードコードされた公開ホスト。Profound に登録されたドメインと一致している必要があります。 |
`missing` 条件の `value` は正確に `^1$` のままにするか、ヘッダーが存在しないことを確認するために `value` を省略してください。付与される値に一致しない他の正規表現を使用すると、除外が何の警告もなく機能しなくなります。その場合、Profound 自身のフェイルオープンのフェッチが Profound にリライトし直され、`400` で拒否されます。
一致する `User-Agent` からの `GET` 以外のリクエストもリライトされ、Profound から `405` が返されます。サポート対象のアシスタントは `GET` でページを取得するため、通常のトラフィックには影響しません。その他のメソッドをデプロイメントに留めたい場合は、ルートに `"methods": ["GET"]` を追加してください。
## 複数のドメイン
`x-concierge-host` の transform は固定の文字列であるため、1 つのルールで配信できる公開ホストは 1 つです。1 つの Vercel プロジェクトで複数の登録済みドメインを配信する場合は、ホストごとにルートを 1 つ追加し、それぞれを `host` ヘッダーに対する `has` 条件で絞り込んでください。
```json theme={null}
{
"type": "header",
"key": "host",
"value": "^www\\.example\\.com$"
}
```
これらのルートは、キャッチオールルートよりも前に配置してください。
## プレビューデプロイメント
上記のルールは、プレビューデプロイメントを含め、プロジェクトが配信するすべてのホスト名で実行されます。`x-concierge-host` は固定されているため、プレビューのリクエストは Profound には本番環境として識別されます。ステップ 1 のように `PROFOUND_CONCIERGE_KEY` のスコープを Production のみに設定すると、プレビューのリクエストには展開されていないリテラルのキーが含まれ、Profound が `401` で拒否するため、本番環境のコンテンツが配信されたりレンダリングされたりすることはありません。
プレビューホストに対するアシスタントのリクエストを、代わりに通常どおりプレビューデプロイメントに到達させたい場合は、[複数のドメイン](#multiple-domains)の `host` 条件を追加して、ルールが本番環境のホスト名にのみ一致するようにしてください。未設定の変数がどのように処理されるかについては、[ルートでの環境変数の使用](https://vercel.com/docs/project-configuration/vercel-json#using-environment-variables-in-routes)を参照してください。
## キャッシュとコンテンツのチェック
トラフィックを有効にする前に、デプロイされたリライトのキャッシュ動作を確認してください。2026 年 4 月 6 日以降に作成されたプロジェクトでは、[Vercel はデフォルトでアップストリームのキャッシュヘッダーに従います](https://vercel.com/docs/routing/rewrites#caching-rewrites-to-external-origins)。それより前のプロジェクトは、プロジェクト設定または `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 と認可ヘッダーを削除し、オプトインした公開ページのみをレンダリングします。