> ## 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 が正しくルーティングされていることを確認し、x-concierge-* 診断ヘッダーを読み解いて、よくあるセットアップの失敗を解決します。
## セットアップをテストする
以下のチェックはすべて `GET` リクエストを送信します。Profound の仕様は `GET` のみを対象としているため、`HEAD` を送信する `curl -I` ではなく `curl -sD - -o /dev/null` を使用してください。`HEAD` のレスポンスは、オリジンから返される場合もあれば、ボディを省略するハンドラーから返される場合もあり、ルーティングについては何もわかりません。
```bash theme={null}
curl -sD - -o /dev/null https://www.example.com/pricing -A 'chatgpt-user'
```
`x-concierge-request-id` に UUID が含まれていること、および `x-concierge-bot-kind: chatgpt-user` を確認します。この 2 つが揃っていれば、CDN がリクエストを Profound にルーティングし、Profound がアシスタントを認識したことが証明されます。ただし、レンダリング済みのページが配信されたことの証明にはなりません。`MISS` と `x-concierge-failopen: 1` の組み合わせは、Profound がオリジンのライブコンテンツを返したことを意味します。
[セットアップ](/ja-jp/dynamic-bot-rendering/overview#before-you-start)時に公開したページでは、`x-concierge-cache: HIT` とレンダリング済みの HTML も必須です。比較のためにボディを保存し、Profound が gzip エンコードで配信した場合に備えて curl に展開させます。
```bash theme={null}
curl -sS --compressed -D /tmp/dbr-headers.txt -o /tmp/dbr-page.html \
https://www.example.com/pricing -A 'chatgpt-user'
```
このリクエストが `MISS` の場合は、[結果の読み方](#reading-the-result)の説明に従って `x-concierge-policy` ヘッダーを確認してください。リクエストを繰り返しても `MISS` が `HIT` になることはありません。`HIT` になるのは、レンダリングを公開した場合のみです。
```bash theme={null}
curl -sD - -o /dev/null https://www.example.com/pricing \
-A 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36'
```
`x-concierge-*` ヘッダーがなく、ページの内容が以前と同じであることを確認します。レイテンシーとキャッシュヒット率もベースラインと比較してください。ルーティングが変わっていなくても、Worker や共有キャッシュポリシーの変更がそれらに影響する場合があります。
```bash theme={null}
curl -sD - -o /dev/null https://www.example.com/pricing -A 'Googlebot/2.1'
```
こちらも `x-concierge-*` ヘッダーがないことを確認します。このリクエストがルーティングされる場合は、[よくある問題](#common-problems)を参照してください。
ステージング環境で、`GET` 以外のメソッド、`/api/users`、`/graphql`、認証、管理、フレームワークのリソース、アセット(拡張子のないエンドポイントを含む)へのリクエストを送信します。データを変更する可能性のあるメソッドには無害なテスト用エンドポイントを使用し、Cookie や認可ヘッダーには機密ではないテスト値を使用してください。これらはすべて既存のルートのまま処理される必要があります。Vercel では、プレビューホストや代替ホストもテストしてください。
ステージング環境または分離された構成を使用し、元の設定を記録して、各テストの後に復元してください。
* **Cloudflare:** 到達不能なアップストリーム、レスポンスヘッダーのタイムアウト、設定したフォールバックステータスのいずれかをテストします。`x-concierge-cdn-failover: 1` が付いたオリジンのコンテンツが返されることを確認します。リダイレクト、`404`、`429` はそのまま返され、すでにストリーミングが開始されたレスポンスは置き換えられません。
* **CloudFront:** 設定した上限内でのプライマリの接続タイムアウトとレスポンスタイムアウト、および選択したステータス条件をテストします。設定した障害ではフォールバックオリジンが使用されますが、`401` では使用されないことを確認します。キャッシュされていないリクエストを送信し、プライマリを復元した後も、キャッシュされたフォールバックレスポンスが TTL が切れるまで残ることを想定してください。
* **Vercel:** CDN レベルのフェイルオーバーはありません。Profound の障害中やハードリジェクトの後は、アシスタントがエラーを受け取る場合があります。透過的なオリジンへのフォールバックは期待しないでください。
設定を復元した後、反映されるのを待ってから、ルーティングと公開済みページのチェックを繰り返してください。
## ダッシュボードからセットアップの検証を実行する
Profound のダッシュボードでは、ルーティングのテストを代わりに実行できます。ネットワークの外部から、登録済みホスト上の URL に対して、サポート対象の 9 つのアシスタントの `User-Agent` 値をそれぞれ使ってリクエストを送信し、CDN がどのアシスタントを Profound にルーティングしたかを報告します。
これらのプローブには認証情報もループマーカーも含まれないため、CDN からは実際のアシスタントのトラフィックのように見えます。アシスタントがルーティングされたと見なされるのは、レスポンスに有効なリクエスト ID と一致するボットの種類が含まれている場合のみです。`MISS`、一時停止中のドメイン、リダイレクト、`200` 以外のステータスでも、ルーティングが確認できる場合があります。ページの状態は別途報告されます。テストする URL が公開ページの許可リストに含まれていることを確認してください。含まれていない場合、すべてのアシスタントが(正しく)ルーティングされていないと表示されます。
セットアップの検証は、ある時点における 1 つの URL のライブ観測です。各アシスタントに対して CDN のルールが実行されることは確認できますが、ドメインの所有権を検証するものではなく、公開済みのテストページを手動で確認する作業の代わりにもなりません。
## レスポンスヘッダーのリファレンス
| ヘッダー | 意味 |
| - | - |
| `x-concierge-request-id` | Profound が処理するすべてのリクエストに割り当てる UUID。これがない場合、Profound はリクエストを受け取っていません。ルールが一致しなかった、CDN がフェイルオーバーした、またはプロキシがヘッダーを削除したことが考えられます。 |
| `x-concierge-cache` | 公開済みレンダリングが配信された場合は `HIT`、Profound がオリジンにフォールバックした場合は `MISS`。 |
| `x-concierge-bot-kind` | Profound が認識したアシスタント、または `unknown`。 |
| `x-concierge-failopen` | 保存済みレンダリングの代わりにオリジンのライブコンテンツが返された場合は `1`。 |
| `x-concierge-origin-status` | オリジンから取得した場合の、オリジンの HTTP ステータス。 |
| `x-concierge-policy` | このリクエストに対する有効なモード: `serve`、`warm`、`off`。[ポリシーモード](/ja-jp/dynamic-bot-rendering/overview#policy-modes)を参照してください。 |
| `x-concierge-policy-source` | そのモードを決定したレベル: ページルールの場合は `page`、ドメインデフォルトまたは一時停止中のドメインの場合は `domain`、ルールが適用されなかった場合は `default`。 |
| `x-concierge-policy-rule` | 適用されたルールの ID(存在する場合)。 |
| `x-concierge-auth` | `401` の場合のみ: `missing-key`、`unknown-key`、`inactive-key`。 |
| `x-concierge-cdn-failover` | アップストリーム呼び出しの失敗後にオリジンを配信した場合に、Profound ではなく、これらのガイドの Cloudflare Worker によって設定されます。 |
## 結果の読み方
| 表示内容 | 意味 |
| - | - |
| `cache: HIT` | 公開済みレンダリングが配信されました。ステータスとボディも確認してください。 |
| `MISS` + `failopen: 1` + `policy: serve` | ポリシーでは配信が許可されていますが、URL に利用可能な公開済みのものがありません。この正確なパスとクエリについて、候補をレンダリング、レビュー、公開してください。 |
| `MISS` + `failopen: 1` + `policy: warm` | `warm` は、公開済みのものが存在してもオリジンのコンテンツを配信します。準備ができたら、適用されているルールを `serve` に変更してください。 |
| `MISS` + `policy: off` + `policy-source: default` | このパスに該当するルールがないため、オプトインされていません。ドメインデフォルトまたはページルールを追加してください。 |
| `MISS` + `policy: off` + `policy-source: domain` + ルール ID なし | ドメインが一時停止しています。ダッシュボードで再開してください。 |
| `MISS` + `policy: off` + ルール ID あり | 適用されたルールが `off` であるか、許可リストからこのアシスタントを除外しています。`policy-source: domain` の場合、そのルールはドメインデフォルトです。モードと許可するアシスタントを確認してください。 |
| `bot-kind: unknown` | Profound が認識しない `User-Agent` を CDN がルーティングしました。このリクエストは往復が 1 回増え、オリジンのコンテンツを受け取りました。ルールを[サポート対象の一覧](/ja-jp/dynamic-bot-rendering/overview#supported-ai-assistants)と一致させてください。 |
| アシスタントのリクエストに `x-concierge-*` ヘッダーがない | Profound はリクエストを受け取っていません。ルールの一致条件を確認し、Cloudflare と CloudFront の場合は CDN のフェイルオーバーが発生したかどうかを確認してください。 |
## エラーレスポンス
Profound がオリジンにフォールバックするのは、リクエストが認証され有効であった場合のみです。設定エラーはプロキシされずに拒否されます。Cloudflare の Worker は、設定された拒否ステータスをオリジンの配信によって隠します。CloudFront は `400` と `403` を隠しますが、`401` は隠しません。Vercel には再試行がありません。拒否されるはずの場面でオリジンのページが表示された場合は、CDN の診断情報を確認してください。
| ステータス | 原因 | 対処法 |
| - | - | - |
| `401` + `x-concierge-auth: missing-key` | `x-concierge-api-key` ヘッダーが届いていません。 | ルールがキーを付与していることを確認してください。診断中に実際のキーをログに記録したり出力したりしないでください。 |
| `401` + `unknown-key` | 値は届いていますが、どのキーとも一致しません。 | 切り詰め、空白、または展開されていないリテラルの `$PROFOUND_CONCIERGE_KEY` がないか確認してください。Vercel では、実際のキーを使用する前に、機密ではないテスト値で変数の展開を検証してください。 |
| `401` + `inactive-key` | キーが失効しています。 | 新しいキーを作成して展開してください。 |
| `403` | ホストが登録されていないか、別の組織に属しています。 | ダッシュボードで正確な公開ホストを登録してください。正規化(小文字、末尾のドットなし、ポートなし)後に一致している必要があります。 |
| `400` | 不正な形式のホストまたはパス、パスが想定される場所での絶対 URL、`#` フラグメント、または受信リクエストのループマーカー。 | 多くの場合、ルールがパスではなく完全な URL を送信しているか、ループ防止の条件が壊れています。 |
| `405` | `GET` 以外のメソッドが Profound に到達しました。 | `GET` のみを Profound にルーティングし、`curl -I` ではなく `curl -sD - -o /dev/null` でテストしてください。 |
| `502` | Profound がオリジンに到達できず、配信できる公開済みのものもなかったか、バックエンドの検索に失敗しました。 | オリジンが公開インターネットから到達可能で、Profound のフェッチをブロックしていないことを確認してください。CDN 自体が `502` を生成する場合もあるため、CDN の診断情報も確認してください。 |
## よくある問題
`User-Agent` のパターンが、サポート対象のトークン一覧以外のものに一致しています。セットアップガイドのパターンおよび[サポート対象のアシスタント](/ja-jp/dynamic-bot-rendering/overview#supported-ai-assistants)と比較してください。`Googlebot` などの検索クローラーは、引き続きオリジンに到達する必要があります。
CloudFront は、オリジンリクエストポリシーで転送しない限り、オリジンリクエストのビューワー `User-Agent` を `Amazon CloudFront` に置き換えます。その場合、Profound には分類する情報がありません。[CloudFront ガイド](/ja-jp/dynamic-bot-rendering/cloudfront)の、対象を絞ったカスタムオリジンリクエストポリシーを使用してください。**AllViewer** はビューワーの `Host` も転送し、Profound への接続を壊す可能性があるため、使用しないでください。`User-Agent` はキャッシュキーではなく、オリジンリクエストポリシーに追加してください。
適用されたルールの許可するアシスタントの一覧から、そのアシスタントが除外されています。レスポンスには、ルール ID とともに `x-concierge-policy: off` が表示されます。アシスタントを一覧に追加するか、一覧をクリアしてルールがドメインデフォルトを継承するようにしてください。
いずれかのキャッシュレイヤーが、アシスタントと人間のレスポンスを分離せずに、またはホスト、パス、クエリ文字列を分離せずに HTML を保存しています。
CloudFront では、`x-concierge-route` をキャッシュキーに含め、Minimum TTL を `0` のままにし、ホストとクエリのバリアントを確認してください。Cloudflare では、Worker のアップストリーム呼び出しがキャッシュをバイパスしていることを確認してください。すべてのページが同じアップストリーム URL を使用するため、`User-Agent` をキーにするだけではページの識別を分離できません。Vercel では、プロジェクトの外部リライトのキャッシュ設定を確認してください。どのプロバイダーでも、置き換えの公開、公開の取り消し、一時停止を行った後にキャッシュエントリーがどうなるかを確認してください。CDN のエントリーは、Profound での変更後も残る可能性があります。
ループ防止が機能していません。ルールでは、`x-concierge-request` を含むリクエストをそのままオリジンに通過させる必要があります。Profound は自身のオリジンフェッチにこのヘッダーを付与し、このヘッダーを含む受信リクエストをすべて `400` で拒否するため、除外が壊れていても、ループではなく 1 回のリクエストの失敗で済みます。
Vercel では、これは `x-concierge-request` に対する、値 `^1$`(Profound が付与するマーカー)の `missing` 条件です。値を指定した `missing` 条件は、ヘッダーがその値に一致するリクエストのみを除外するため、他の正規表現を使用すると何の警告もなく除外が無効になります。
クエリ文字列はページ識別の一部です。CDN がオリジンリクエストの前にクエリ文字列を削除すると、`/product?id=a` と `/product?id=b` が `/product` にまとめられ、誤ったバリアントがレンダリングおよび配信されます。
CloudFront では、ページの内容が変わるクエリ文字列(または「All」)をキャッシュポリシーに含めてください。オリジンリクエストポリシーでは、キーに含めずに追加のクエリ文字列を転送できるため、転送とキャッシュの識別は個別に確認してください。
レスポンスの `x-concierge-policy` と `x-concierge-policy-source` を確認してください。一致するルールがない場合は `off` となり、`warm` は公開済みのものが存在してもオリジンのライブコンテンツを配信します。適用されているルールを `serve` に設定してください。
次に、この正確なパスとクエリの候補がレビューされ、公開されていることを確認してください。承認だけでは公開されず、リクエストを繰り返しても公開されません。pending として保留された候補は、誰かが承認、却下、または公開するまで pending のままです。ページが公開され、ポリシーが `serve` であるにもかかわらず `MISS` が表示される場合は、CDN のキャッシュとオリジンへの到達性を確認してください。
受信するアシスタントのトラフィックと Profound のオリジンフェッチの両方について、WAF のルール、ボットチャレンジ、デプロイ保護、オリジンの許可リストを確認してください。Profound は閲覧者の Cookie や認可ヘッダーを転送しないため、保護されたページやセッションに依存するページは、このセットアップの対象外とすべきです。ループマーカーは偽装可能であり、ファイアウォールや認証のバイパスに使用してはいけません。オリジン側で Profound のフェッチを識別する方法が必要な場合は、Profound サポートにお問い合わせください。
## 無効にする
CDN に手を加えずにレンダリングの配信を停止するには、Profound のダッシュボードでドメインを一時停止します。ルール、レンダリング、公開済みのものは保持されたまま、すべてのアシスタントのリクエストがオリジンに送られ、再開すると元に戻ります。一時停止は Profound では即座に反映されますが、CDN がすでにキャッシュしたレスポンスは有効期限が切れるまで残ります。リクエストは引き続き Profound に到達する必要があるため、一時停止は障害時の CDN レベルのフェイルオーバーの代わりにはなりません。
統合を削除するには、セットアップ前に記録しておいた CDN の設定を復元します。
* **Cloudflare:** 追加した Worker ルートを削除するか、他の Worker ロジックを削除せずに以前のバインディングを復元します。
* **CloudFront:** 以前のビューワーリクエストの関連付けとポリシーを復元します。**No association** は、以前に関連付けがなかった場合にのみ使用してください。
* **Vercel:** `vercel.json` から追加したルートのみを削除し、その他のルーティングは維持したうえで再デプロイします。
ルーティングの変更は、設定またはデプロイメントが反映された後に有効になります。以前にキャッシュされたフォールバックレスポンスは、有効期限が切れるか、通常の無効化手順を行うまで残る場合があります。ロールバック後に、元のルーティングとコンテンツを確認してください。登録済みのドメイン、キー、公開済みのものは、削除するまで Profound に残ります。