> ## 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.

# Dynamic Bot Rendering

> AI アシスタントにはエッジから完全にレンダリングされたページを配信し、その他のトラフィックは既存のルートのまま維持します。

多くの AI アシスタントは、JavaScript エンジンを使わずに単純な HTTP リクエストでページを取得します。クライアントサイドでレンダリングされるサイトでは、コンテンツの代わりに空のシェルしか見えない場合があります。

Dynamic Bot Rendering は、この問題をコンテンツデリバリーネットワーク(CDN)で解決します。すでに運用している CDN に、小さなルーティングルールを 1 つ追加するだけです。このルールは `User-Agent` によって AI アシスタントのトラフィックを識別し、Profound に転送します。オプトインした公開ページについては、公開済みの事前レンダリング版が存在する場合、Profound がそれを返します。それ以外の場合は、オリジンからのライブレスポンスをそのまま返します。人間の訪問者、検索クローラー、API 呼び出し、アセットは、既存のルートから外れることはありません。

<Note>
  Dynamic Bot Rendering は Profound の Concierge サービスによって提供されるため、リクエストヘッダーとレスポンスヘッダーには `x-concierge-` というプレフィックスが使用されます。
</Note>

## リクエストの流れ

<Steps>
  <Step title="CDN がリクエストを分類する">
    ルーティングルールが `User-Agent` を[サポート対象のアシスタント一覧](#supported-ai-assistants)と照合します。一致したリクエストのみが Profound に送られます。Cloudflare と CloudFront の例では、ルーティングをパスの許可リストにも制限しています。Vercel のルールはすべてのアシスタントトラフィックを転送し、判断を Profound のポリシーに委ねます。
  </Step>

  <Step title="CDN がリクエストを Profound に転送する">
    ルールは、API キー、公開ホスト、元のパスとクエリを信頼済みヘッダーとして付与します。これらの値は、クライアントが送信したヘッダーからではなく、ルール自身の設定と解析済みのリクエストから設定されます。Profound は、クライアントが指定した `x-concierge-*` の識別ヘッダーを無視します。
  </Step>

  <Step title="Profound が公開済みレンダリングを配信するか、オリジンにフォールバックする">
    Profound は API キーを確認し、ホストが貴社の組織に登録されていることを確認したうえで、そのパスの[ポリシー](#how-rendering-and-serving-are-controlled)を解決します。パスに公開済みレンダリングがあり、ポリシーで配信が許可されている場合、Profound はそのレンダリングを返します。それ以外の場合は、オリジンからページを取得し、ライブレスポンスを変更せずに返します。ポリシーによっては、このミスをきっかけに、新しい候補としてページのバックグラウンドレンダリングがスケジュールされることもあります。
  </Step>

  <Step title="アシスタントがページを受け取る">
    公開済みレンダリングは完全にレンダリングされた HTML であり、ブラウザーで JavaScript を実行した後に生成されるページと同じものです。レンダリングによってコンテンツはアシスタントにとって読み取り可能になりますが、回答への掲載や引用を保証するものではありません。
  </Step>
</Steps>

## サポート対象の AI アシスタント

Profound は、すべてのリクエストで元の `User-Agent` からアシスタントを識別します。その際、CDN ルールで照合するものと同じトークンを使用します。照合は大文字と小文字を区別しない部分一致で行われます。

| トークン | アシスタント |
| - | - |
| `chatgpt-user` | ChatGPT ブラウジング |
| `codex` | OpenAI Codex |
| `claude-user` | Claude |
| `claude-code` | Claude Code |
| `perplexity-user` | Perplexity |
| `gemini-deep-research` | Gemini Deep Research |
| `duckassistbot` | DuckDuckGo DuckAssist |
| `amzn-user` | Amazon |
| `mistralai-user` | Mistral |

<Warning>
  CDN ルールの一覧は、この表と常に同期させてください。Profound はトラフィックを独自に分類するため、ルールが転送しても Profound が認識しない `User-Agent` は、不明なエージェントとして扱われます。その場合はオリジンにフェイルオープンし、レンダリングの配信やスケジュールを行わないまま往復が 1 回増えるだけになります。
</Warning>

## 検索クローラーのルーティング

通常の Googlebot や Bingbot のリクエストは上記の一覧に含まれないため、既存のルートのまま処理されます。ロールアウト前に、サイトのキャッシュルールとエッジルールをテストしてこれを確認してください。Dynamic Bot Rendering はクローキングを行いません。レンダリングされたページは、ブラウザーで JavaScript を実行した後に生成されるページと同じものです。

## レンダリングと配信の制御方法

特定の URL に対してアシスタントが何を受け取るかは、2 つの独立した設定によって決まります。

* **ポリシー** は、「Profound はこのパスに対して保存済みコンテンツを配信してよいか、またどのアシスタントに配信するか」を決定します。
* **公開** は、「このパスでどのレンダリングがライブになっているか」を決定します。

保存済みレンダリングが配信されるには、この両方の条件が揃う必要があります。`off` ポリシーの下にある公開済みページは何も配信しません。公開されていないパスに `serve` ポリシーを設定した場合は、オリジンにフォールバックします。どちらも Profound のダッシュボードでご自身で管理します。

### ポリシーモード

| モード | アシスタントが受け取るもの | バックグラウンドで新しい候補をレンダリングするか |
| - | - | - |
| `off` | オリジンのライブレスポンス | いいえ |
| `warm` | 公開済みのものが存在する場合でも、オリジンのライブレスポンス | はい(リクエストが対象となる場合) |
| `serve` | 利用可能な公開済みレンダリングがあればそれ、なければオリジン | はい(ミス時、リクエストが対象となる場合) |

`off` は、どのルールにも該当しないパスのデフォルトです。新しく登録したドメインは、ルールでパスをオプトインするまで何も行わないため、何をレンダリングするかを決めるまでオンボーディングによる影響はありません。配信を開始する前にレビュー用の候補を蓄積するには `warm` を使用します。`serve` がそれ自体で何かを公開することはなく、既存の公開済みレンダリングの配信を許可するだけです。

### ルールと優先順位

すべてのルールは、登録済みのドメイン 1 つに属します。**ドメインデフォルト** はホスト全体のベースラインを設定し、**ページルール** は特定のパスについてそれを上書きします。ページルールは、完全一致のパス(任意でクエリ文字列に固定可能)、パスのプレフィックス、または `/blog/*` のような glob に一致します。プレフィックスルールと glob ルールは、クエリ文字列を除いたパスで照合されます。

Profound はリクエストごとに、適用するルールを 1 つ選択します。

1. パスとクエリ文字列に完全一致するルール。
2. それがなければ、パスに完全一致するルール。
3. それもなければ、最も一致するプレフィックスまたは glob ルール。優先度の高いものが優先され、次により具体的なパターンが優先されます。
4. それもなければ、ドメインデフォルト。
5. ルールがまったくない場合、有効なモードは `off` です。

適用されるのは選ばれたルールのみです。そのルールで未設定の項目はドメインデフォルトから継承され、同じく一致したより広いページルールから継承されることはありません。たとえば、ドメインデフォルトが `serve`、`/docs/*` ルールが `warm`、そして許可するアシスタントのみを変更する `/docs/start` の完全一致ルールがある場合、`/docs/start` は `serve` に解決されます。`/docs/*` ルールは影響しません。

ルールは無効化することもできます。無効なルールは完全にスキップされるため、そのパスにはドメインデフォルトまたは一致する別のルールが適用されます。したがって、パスを除外していた `off` ルールを無効化すると、配信が再びオンになる場合があります。パスをオリジンのままにしておくには、モード `off` の有効なルールを使用してください。

### ルールごとの設定

各ルールでは、以下の任意の項目を設定し、残りを継承できます。

* **モード。** 前述の `off`、`warm`、`serve` のいずれか。
* **許可するアシスタント。** 一致したパスで処理対象となるサポート対象アシスタントを制限します。未設定の場合はドメインの一覧を継承し、どこにも一覧が設定されていない場合は、サポート対象のすべてのアシスタントが対象になります。一覧は継承した一覧と交差するのではなく置き換わり、空の一覧はすべてのアシスタントを除外します。除外されたアシスタントは、有効なポリシーが `off` としてオリジンのレスポンスを受け取ります。公開済みレンダリング自体は共有されるため、アシスタントごとに異なるバージョンを公開することはできません。
* **自動レンダリング。** モードとは独立して、バックグラウンドでの候補レンダリングを許可またはブロックします。自動レンダリングをオフにした `serve` は、手動で公開したものだけを配信します。`off` は、この設定にかかわらず自動でレンダリングすることはありません。

### ドメインの一時停止

ドメインを一時停止すると、登録、ルール、レンダリング、公開済みのものはそのまま維持しつつ、そのホストに対するすべてのアシスタントリクエストがオリジンに送られます。再開すると、保存されていた動作が復元されます。CDN やルールに手を加えずに、すばやく配信を停止したい場合に一時停止を使用してください。一時停止中でも、ページのレンダリング、レビュー、公開は引き続き行えます。

## レンダリングからライブページまで

すべてのレンダリングは **候補** として始まります。候補とは 1 つの URL の保存済みスナップショットで、対象となるリクエストによってバックグラウンドで作成されるか、オンデマンドで作成されます。1 つの URL に複数の候補が蓄積されることがあります。いずれかを公開するまで、どの候補も配信されません。

<Steps>
  <Step title="レビュー">
    その URL で現在公開されているページと大きく異なる候補は、**pending** として保留されます。これは、表示テキストがライブページのごく一部にまで減少した場合や、タイトルと最初の見出しの両方が変更された場合に発生します。候補をプレビューしてから、承認または却下してください。承認は公開の対象としてマークするだけで、それ以外の処理は行いません。URL にまだ公開済みページがない場合は比較対象がないため、候補は承認済みとして保存されます。
  </Step>

  <Step title="公開">
    公開では、特定のレンダリングを 1 つ選択し、その URL のライブページにします。pending の候補を公開すると、同じステップで承認も行われます。却下された候補は公開できません。
  </Step>

  <Step title="ロールバック、公開取り消し、置き換え">
    ロールバックとは、同じ URL の以前のレンダリングを公開することです。公開を取り消すとライブページが削除され、アシスタントはオリジンに戻りますが、レンダリング履歴は保持されます。現在公開中のページを却下した場合も、公開が取り消されます。コンテンツを更新するには、新しい候補をレンダリングしてレビューし、公開してください。
  </Step>
</Steps>

公開済みレンダリングは、置き換えを公開するか公開を取り消すまでライブのままです。Profound が公開済みのものを自動的に置き換えることはなく、古くなったという理由でレンダリングの配信が停止されることもありません。保存済みレンダリングを読み取れなくなった場合、Profound は別のレンダリングを配信するのではなく、そのリクエストについてオリジンにフォールバックします。

ページの識別は、公開ホストと、完全なパスおよびクエリ文字列の組み合わせで行われます。`/pricing` を公開しても `/pricing?plan=pro` は公開されず、各バリアントはそれぞれ個別にレンダリング、レビュー、公開されます。

## 設計によるフェイルオープン

フェイルオープンは 2 つのレイヤーで行われ、どちらか一方だけですべての障害をカバーできるわけではありません。

<CardGroup cols={2}>
  <Card title="CDN レベルのフェイルオーバー" icon="shield">
    Cloudflare Worker は、フェッチの失敗、レスポンスヘッダーの期限超過、設定したステータスの一覧に該当する場合に、オリジンへ再試行します。CloudFront は、障害条件とタイムアウトを設定したオリジングループを使用します。Vercel のルーティングルールには CDN レベルのフェイルオーバーはありません。
  </Card>

  <Card title="サービスレベルのフェイルオープン" icon="rotate">
    リクエストが認証され有効であれば、Profound は保存済みレンダリングを配信できないときは常にオリジンから取得します。たとえば、公開済みのものがない場合、ポリシーが `off` または `warm` の場合、不明なアシスタントの場合、レンダリングを読み取れない場合、内部の検索に失敗した場合などです。この場合でも、オリジンに到達できる必要があります。
  </Card>
</CardGroup>

<Warning>
  Vercel では、外部リライトに再試行先となるセカンダリオリジンがないため、Profound の障害やハードリジェクトがエラーとしてアシスタントに届く場合があります。Cloudflare と CloudFront をご利用のお客様は、CDN のフェイルオーバーによって追加の保護レイヤーを得られます。
</Warning>

不正な API キー、未登録のホスト、または不正な形式のパスは、プロキシされずに Profound によって拒否されます。そのため、設定を誤ったルールによって、Profound の名前でリクエストがオリジンに漏れることはありません。Cloudflare と CloudFront では、CDN のフェイルオーバーによってこうした拒否の一部が隠れてしまう場合があります。つまり、ブラウザーでページが正常に表示されても、統合が正しいことの証明にはなりません。[検証とトラブルシューティング](/ja-jp/dynamic-bot-rendering/verify-and-troubleshoot)の説明に従って、`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 サポートにお問い合わせください。

<Steps>
  <Step title="ドメインを登録する">
    Profound のダッシュボードで **Dynamic Bot Rendering** を開き、配信している正確な公開ホスト(`www.example.com` など)を追加します。ホストは公開 DNS で名前解決でき、HTTPS で応答する必要があります。訪問者が実際にアクセスするホストを登録してください。apex ドメインが `www` にリダイレクトする場合は、apex ではなく `www` ホストを登録し、内部のオリジンホスト名は登録しないでください。ホスト名は登録後に変更できません。
  </Step>

  <Step title="API キーを作成する">
    Dynamic Bot Rendering の API キーを作成してコピーします。生の値は一度しか表示されないため、すぐに CDN のシークレットストアに保存してください。

    1 つのキーで、後から追加するドメインを含め、組織に登録されたすべてのドメインをカバーできるため、ほとんどのお客様に必要なキーは 1 つだけです。ダウンタイムなしでローテーションしたい場合や、プロパティごとにローテーションと失効を個別に管理したい場合は、追加のキーを作成してください。追加のキーも組織全体で有効であり、1 つのプロパティに限定されるわけではありません。
  </Step>

  <Step title="ポリシーを設定し、テストページを公開する">
    少なくとも 1 つの公開ページをモード `serve` でオプトインするポリシーをドメインに設定し、そのページの候補をレンダリングしてレビューし、公開します。検証のために、公開した URL と想定される HTML を控えておいてください。

    CDN の設定後、その URL に対するアシスタントのリクエストは、`x-concierge-cache: HIT` とレンダリング済みの HTML を返すはずです。リクエストを繰り返しても公開の代わりにはなりません。レンダリングが公開されるまで、`MISS` は `MISS` のままです。
  </Step>
</Steps>

<Warning>
  キーを失効させると、そのキーを使用しているすべてのサイトに影響します。複数のプロパティで 1 つのキーを共有している場合は、慎重にローテーションしてください。まず置き換え用のキーを作成し、各 CDN に展開してから、古いキーを失効させます。
</Warning>

## CDN を選択する

<CardGroup cols={3}>
  <Card title="Cloudflare" icon="cloudflare" href="/ja-jp/dynamic-bot-rendering/cloudflare">
    ゾーンに Worker を 1 つ追加します。
  </Card>

  <Card title="Amazon CloudFront" icon="aws" href="/ja-jp/dynamic-bot-rendering/cloudfront">
    Lambda\@Edge を使わずに、CloudFront Function を 1 つ追加します。
  </Card>

  <Card title="Vercel" icon="triangle" href="/ja-jp/dynamic-bot-rendering/vercel">
    `vercel.json` にルーティングルールを 1 つ追加します。
  </Card>
</CardGroup>

Akamai、Fastly、カスタムプロキシなど、その他のものをお使いですか?基盤となる仕様は、`GET` リクエストに付与する 3 つのリクエストヘッダーです。Profound サポートにお問い合わせいただければ、対応付けをお手伝いします。