--- type: explanation title: ゲームの不正対策 summary: ゲームがチャレンジ以上である方法。すべてのラウンドをサーバーで用意し、ブラウザでサンドボックス化して走らせ、決定論的なリプレイで再検証する、層をなした不正対策システム。 --- 訪問者が数秒間遊ぶゲームは、あなたが見る部分です。その下にあるのが、ゲームを人間の証拠として数えさせる不正対策システムです。Caputchin は、競技マルチプレイヤーゲームがチーターに対して使う戦術書を借ります。サーバーがすべてのラウンドに権威を持ち、ゲームはロックダウンされたサンドボックスで走り、結果はプレイヤーの入力をリプレイして再導出されます。ゲームは遊べますが、偽れません。 これは [proof of work](/docs/understanding-caputchin/proof-of-work) と [計測](/docs/understanding-caputchin/instrumentation) と積み重なった、3 つ目の検証ゲートです。[セキュリティ](/docs/site-keys/security) ページでキーごとに設定されます。 ## ライフサイクル ラウンドは 3 つのフェーズを通って動きます。プレイの前にサーバーで用意され、プレイ中にブラウザでサンドボックス化されて走り、プレイの後にサーバーで再検証されます。 ```mermaid sequenceDiagram participant V as Visitor browser participant S as Caputchin server participant G as Sandboxed game iframe participant R as Replay isolate V->>S: Request a challenge S->>V: Signed single-use ticket (server picks the game and seed) V->>G: Mount the game in an isolated iframe Note over G: No network, no reach into your page G->>V: Record the player's inputs as a trace V->>S: Submit the ticket and the trace S->>R: Re-run the trace under the same seed Note over R: Sealed, no network, time-bounded R->>S: Verdict and score S->>V: Signed token, only if the replay confirms the play ``` ## ラウンドの前：サーバー権威の用意 ラウンドが *何である* かを決めるすべては、ブラウザでは決してなく、サーバーで起きます。これがマルチプレイヤーの不正対策の「クライアントを決して信頼するな」の原則です。クライアントは意図を送り、サーバーが現実を決めます。 - **署名付きの一度きりのチケット** がラウンドを発行します。それは短命で、一度しか使えません。捕らえられたチケットは、2 回目の合格にリプレイできません。 - **ゲームとそのランダムシードはサーバー側で選ばれ**、チケットに運ばれます。ブラウザはより簡単なゲームやより優しいシードを選べません。その選択を決してしないからです。 - **毎回、資格あるプールから違うゲーム。** ソルバーはどのゲームに直面するか決して分からないので、単一の静的なターゲットで事前訓練できません。運用者はローテーションを絞れますが、サーバーは常に許可されたセットから選びます。プール自身は、インデックス時の適合チェックを通ったゲームだけを含みます。[マーケットプレイスゲームを作る](/docs/marketplace-game-development/build-a-marketplace-game) を参照してください。 ## ラウンドの間：サンドボックス化されたゲーム ゲームは訪問者のブラウザで走りますが、訪問者のサイトとラウンドの完全性の両方を守る境界の中ででです。 `` は、各ゲームを、同一オリジンへのアクセスのない隔離された iframe にマウントするので、ゲームは不透明なオリジンを持ち、ホストページのクッキー、ストレージ、DOM、同一オリジンのネットワークに到達できません。そのインラインの content-security-policy はスクリプトをゲームのバンドルちょうどに固定し、外向きのネットワーク呼び出しをブロックし、バンドルは走る前に既知のハッシュに照合されます（不一致はフェイルクローズします）。ホストページ自身のセキュリティポリシーは触れられません。正確なサンドボックスとポリシーの形は [Caputchin がゲームをどうサンドボックス化するか](/docs/understanding-caputchin/game-sandboxing) に文書化されています。 要点：ゲームは既定で信頼されず、封じ込められます。何も持ち出せず、それが埋め込まれているページを改ざんできません。 ## ラウンドの後：決定論的なリプレイ 訪問者が終えると、ブラウザは記録された入力のトレースを送信します。サーバーはその結果についてブラウザの言葉を取りません。トレースを再実行します。 - **ラウンドは、同じサーバー由来のシードのもとで、ネットワークアクセスのない封じられたアイソレートと厳格な時間予算で、サーバーで再シミュレートされます。** これは戦略ゲームで決定論的なロックステップが頼るのと同じ性質です。同一のシードに同一の入力で、同一のプレイが再現されます。本当にゲームをクリアしなかったトレースは、合格の結果を再現しません。 - **合格か不合格かはそのリプレイから取られ**、ブラウザが報告した数からは決して取られません。クライアントは、稼いでいないスコアを主張できません。 - **署名付きのトークンは、リプレイがプレイを確認した場合だけ発行されます。** そのトークン自体が、後であなたのバックエンドが検証時にそれを確認するとき、一度きりです。 ## Caputchin がしないこと ほとんどのゲームやインタラクティブな CAPTCHA は、行動のシグナルに頼ります。マウスのパスのエントロピー、タップのタイミング、ボット対人間を推測する分類器に与えられるデバイスのテレメトリです。Caputchin は意図的にそうしません。プレイヤーの行動のプロファイルを集めません。入力が *どう* 生まれたかを推測する代わりに、それらが実際にゲームをクリアするかを第一原理から再導出します。これはプライバシーの姿勢でもありセキュリティの姿勢でもあります。だます行動モデルはなく、再現する物理だけがあります。 ## 正直な限界 **ゲートはゲームと同じだけしか強くありません。** 不正対策の仕組みは、ラウンドが本当に遊ばれて偽られなかったことを証明しますが、簡単なゲームを難しくはできません。些末なゲーム（静的なボード、DOM で読める勝ち手、「通るには赤い点をクリック」）は、スクリプトが解くのが安く、決定論的なリプレイは、それらのスクリプト化された入力が勝つことを忠実に確認します。実際に勝つからです。ボットへの耐性は、ゲーム自身がプログラム的に解きにくいことから来ます。速く、感覚的で、一瞬の反応で、DOM に解が座っていないことです。不正対策の層はプレイが本物だったことを保証し、ゲームの設計が、本物のプレイが自動化しにくかったかを決めます。それを念頭にゲームを選び、作ってください。[マーケットプレイスゲームを作る](/docs/marketplace-game-development/build-a-marketplace-game) を参照してください。 合格か不合格かは、各ゲーム自身のロジックが決めます。サーバーはそのロジックを忠実に再実行しますが、あるゲームが勝ちと見なすものを後から疑いません。ゲームの不正対策は、[proof of work](/docs/understanding-caputchin/proof-of-work)、[計測](/docs/understanding-caputchin/instrumentation)、そしてキーの残りの [セキュリティ設定](/docs/site-keys/security) と組み合わさったときに最も強くなります。