--- type: how-to title: チャレンジをカスタマイズする summary: ゲームかワンタップのチェックボックスかを選び、言語とテーマを固定し、ゲートがオリジンで使う Cookie 名とコールバックのパスを変えます。 --- ゲートが見せる検証ページは、サイトキーごとに、ダッシュボードのその **プロキシゲート** ページで設定します。他の設定と同じく、[管理 API](/docs/automation/management-api)、MCP、Terraform からも設定できます。下の各オプションは既定で今の挙動のままなので、触らないサイトキーはこれまでどおり動きます。 ## ゲームかチェックボックスかを選ぶ **チャレンジの種類** が、訪問者が実際に何をするかを決めます： | 種類 | 訪問者がすること | 向いている場面 | |---|---|---| | **ゲームをプレイ** | ページ内で短い検証ゲームを遊ぶ | ボットに対してより強い信号。既定です。訪問者に数秒かかります。 | | **チェックボックスで確認** | プルーフオブワークの検査が走る間に一度タップする | より速く、より軽く、入れるゲームも要りません。信号は弱めです。 | 選択を縛る規則が二つあります： - **ゲーム必須のサイトキーは常にゲームを表示します。** サイトキー自身の **検証にゲームを必須にする** 設定がオンの場合、またはチームがすべてのキーでゲームを必須にしている場合、チェックボックスの選択肢は使えず、どの設定が固定しているかをダッシュボードが示します。API から設定すると `409 gate-forces-game-mode` が返ります。 - **ゲームを選ぶにはゲームのインストールが要ります。** サイトキーには、リプレイ可能なアーティファクトを持つインストール済みのゲームが、自分のものかチームから継承したものか、最低一つ必要です。一つもないとき、`409 no-games` が返るのは種類をゲームに選んだときです。ゲートを有効にするだけでは返りません。ゲームを必須にしていないサイトキーはチェックボックスに切り替わるので、ゲームを整えるあいだもゲートは動き続けます。 最後のインストール済みゲームが後で外されると、ゲーム必須のサイトキーは、黙って別のものに切り替わるのではなく、検証の配信を止めます。ゲーム必須のキーでは、チェックボックスは検証にならないからです。ゲームを必須に *していない* キーはチェックボックスに切り替わり、サイトは届く状態のままになります。 この最後のケースは見分け方を知っておく価値があります。ゲートを掛けたサイトを停止させるからです。ゲートは、再びゲームが使えるようになるまで、すべての訪問者に「確認を利用できません」のページを返します。誰も設定を変えていないのに起きることもあります。ゲームは、固定バージョンが当社の決定論チェックを通って初めて数に入るからです。プロキシゲートのページは、サイトキーがその状態になるたびに警告し、ゲームの一覧と、ゲームを必須にしている設定の両方へリンクします。ゲームをインストールするか、必須を解いてチェックボックスに任せるか、どちらも選べます。 ## 言語やテーマを固定する **言語** も **テーマ** も既定は *訪問者に合わせる* で、たいていはそれが望みどおりです： - **言語** は訪問者自身のブラウザの言語に従います。ウィジェットが対応するのと同じ十一言語です。 - **テーマ** は訪問者のシステムの明るい・暗いの好みに従い、それに合わせて切り替わります。 代わりに固定するのは、ゲートをかけるサイトが一言語のときや、一つのテーマで通していて、訪問者の端末に従うより検証をそのテーマに揃えたいときです。 どちらにしても、検証ページは **このサイトキーのブランド** をまといます。ウィジェットが使うのと同じブランド名、ロゴ、色、リンクを、同じサイトキーから解決します。設定するのは一度、ウィジェットの外観設定で、ゲートはそれを引き継ぎます。独自のブランドプリセットはウィジェットと同じく Apex プランが必要です。言語とテーマのオプション自体は、ゲートが使えるどのプランでも動きます。 検証ページ自体の文言は変更できません。 ## Cookie 名とコールバックのパスを変える 既定値がアプリとぶつかるときだけ、これらを変えてください。 **Cookie 名**（既定 `cpt_gate`）は、プロキシがパスからセットするファーストパーティ Cookie です。アプリがすでにその名前を使っているとき、または一つのドメインでゲート付きのアプリを複数動かしていて、別々に通過許可を出したいときに変えます。 **独自の名前から別の独自の名前へ変えると、サイトキーのプロキシゲートページからリバースプロキシのスニペットをコピーし直してプロキシをリロードするまで、ゲートをかけたサイトは止まります。** ゲートは新しい名前を探すのにプロキシは古い名前を書き続けるので、訪問者は検証へ送られ、それを通過し、すぐまた検証へ送り返されます。レート制限に当たるまで続くループです。既定の `cpt_gate` から変える場合は、先に変えて後から配線しても安全です。ゲートは既定の名前を引き続き認識するからです。 **コールバックへ POST されるフィールドは、Cookie をどう名づけても常に `cpt_gate` です**。つまりコールバックのボディの読み取りは変わりません。変わるのは `Set-Cookie` に書く名前だけです。ゲートの応答には `cookie_name` フィールドが入り、どの名前を使うかをコールバックに伝えます。 **コールバックパス**（既定 `/__cpt/callback`）は、パスを受け取って Cookie をセットする、あなた自身のオリジン上のルートです。アプリのルーターがすでにそのパスを持っているなら移してください。オリジン上の素のパスである必要があります。スキームも、ホストも、クエリ文字列も、フラグメントもなしです。 ## ゲートを一部のパスに絞る **これらのパスだけをゲートする** と **これらのパスは決してゲートしない** は一行につき一つのパターンを取り、生成されるリバースプロキシの設定を形づくります。両方を空にすれば、すべてのパスにゲートがかかります。 これらは助言です。変わるのはコピーするスニペットで、強制するのはあなたのプロキシです。オーソライザーのサブリクエストと、あなたのコールバックのパスは常にゲートなしのままにしてください。生成される設定はすでにそうしています。 よくあるログインポータルなら： ``` これらのパスだけをゲートする： / /api/firstfactor これらのパスは決してゲートしない： /api/verify /healthz ``` ## あわせて読む - [プロキシのページゲートを設定する](/docs/proxy-page-gate/set-up)：nginx の手順。 - [リバースプロキシのレシピ](/docs/proxy-page-gate/reverse-proxy-recipes)：コールバックの契約と、ほかのプロキシ。 - [概要](/docs/proxy-page-gate/overview)：概念と通過許可 Cookie。