「証明可能な公平性（provably fair）」という言葉は、実際にはその仕組みが実装されていないカジノでは単なる宣伝文句として使われ、一方で適切に実装しているカジノでは、真剣な技術的取り組みとして位置づけられています。 この違いを見極めることは重要です。なぜなら、Plinkoはベットごとの真正な検証が可能な数少ないカジノゲームの一つであり、適切に実装されているカジノでは、その暗号学的証明が真に強力だからです。このページでは、その仕組みを解説し、実際のドロップの検証手順を順を追って説明するとともに、これを適切に実施しているカジノをリストアップし、「証明可能な公平性」が実際に証明できることの限界についても正直に明らかにします。
「カジノが大きな賭け金での支払いを避けるために、チップの経路を意図的に操作したのではないか」と疑問に思ったことがあるなら、暗号学的な答えは「いいえ、カジノが『証明可能な公平性（provably fair）』を適切に実装していれば、そのようなことはあり得ません。なぜなら、経路は賭けが行われる前に確定しているからです」となります。また、「それでもカジノが出金を遅らせる可能性はないか」と疑問に思ったことがあるなら、暗号学的な答えは「それは別の問題であり、『証明可能な公平性』はそれについて何も言及していません」となります。どちらの答えも重要です。
「証明可能な公平性」とは
「証明可能な公平性（Provably Fair）」とは、プレイヤーがカジノを信頼することなく、各賭けの結果を独自に検証できる暗号プロトコルです。この仕組みが機能するのは、カジノが賭けが行われる前にランダムソースをコミットしなければならないためであり、そのコミットメントは、事後にカジノがソースを変更しても検出されないよう設計されています。
主要なクリプト・プリンコ・プロバイダーがすべて採用している標準的な実装には、3つの入力があります：
- サーバーシード。 カジノによって生成されるランダムな文字列。カジノはこのシードのハッシュ（通常はSHA-256）を計算し、ベットが行われる前にそのハッシュをプレイヤーに表示します。プレイヤーはハッシュからシードを導き出すことはできませんが、そのハッシュによって、カジノはその特定のシード値を使用することが一意に確定されます。
- クライアントシード。 プレイヤーが管理するランダムな文字列。プレイヤーが設定しない場合、ほとんどのカジノではこれが自動生成されます。プレイヤーはいつでもクライアントシードを変更できます。
- ノンセ。 ベットが行われるたびにインクリメントされる整数のカウンター。特定のサーバーシード下での最初のベットはノンセ0、2番目のベットはノンセ1となり、以下同様です。
特定のベットに対するドロップ結果は、HMAC-SHA256 を使用して、これら 3 つの入力から決定論的に計算されます：
outcome = HMAC_SHA256(serverSeed, clientSeed + ":" + nonce)その後、カジノの文書化されたアルゴリズムは、256ビットのHMAC出力をチップの左右偏向シーケンスに変換します。具体的には、通常、出力の各バイト（またはビット群）を偏向の決定として扱い、経路を特定するのに十分な数の偏向が抽出されるまでこの処理を繰り返します。
プレイヤーが新しいサーバーシードへの切り替えを希望した場合、カジノは元のサーバーシードを公開します。これにより、プレイヤーは以下の点を確認できます。
- 公開されたシードが、以前に表示されたハッシュ値と一致すること。これにより、カジノがベット後にシードを変更していないことが証明されます。
- プレイヤーの各ベットに対するHMAC計算の結果が、プレイ中にカジノが表示したチップの移動経路と一致すること。これにより、カジノが個々の結果を意図的に操作していないことが証明されます。
どちらかのチェックに失敗した場合、カジノは機能しなくなります。主要な実装において、実環境ではどちらのチェックも失敗したことはありません。
シード・アンド・ノンス・モデルの実用例
プレイヤー視点での操作手順について解説します。
Stakeで「証明可能な公平性」を備えたPlinkoゲームを開きます。最初のボールが落ちる前に、ゲーム画面には現在のサーバーシードのSHA-256ハッシュ（4d3a7c1e9b2f...のような64文字の16進数文字列）が表示されます。このハッシュからシードを導き出すことはできませんが、Stakeは、あなたがそのゲームを使い続ける限り、その特定のシードを使用することを保証します。
クライアントシード（例えば、自分のイニシャルや覚えやすい文字列、あるいはStakeが自動生成した値など）を設定するか、受け入れます。ノンセは0から始まります。
チップを落とします。StakeはHMAC-SHA256(serverSeed, clientSeed + “:0”)を計算し、その結果をデフレクションシーケンスに変換します。このシーケンスによって、チップの軌道と着地するスロットが決まります。チップが落ちていくのが見えます。ノンセが1増加します。
さらにチップを1枚賭けます。StakeはHMAC-SHA256(serverSeed, clientSeed + “:1”)などを計算します。各ベットには一意のノンセが割り当てられており、これら3つの入力が与えられれば、結果はすべて決定論的に導き出されます。
確認したい場合は、Stakeの「証明可能な公平性」設定に移動し、サーバーシードのローテーションを実行します。Stakeは元のサーバーシードを表示します。これで、そのシードの下で行われたすべてのベットの結果を再計算するために必要な情報がすべて揃いました。
公開されたサーバーシードを取得し、そのSHA-256ハッシュを計算します。その結果は、プレイ開始前に表示されたハッシュと完全に一致する必要があります。一致する場合、Stakeはその正確なシードを使用しており、変更することはできませんでした。一致しない場合、Stakeは不正な状態です。
次に、各ベットについて HMAC-SHA256(revealedServerSeed, clientSeed + ”:” + nonce) を再計算し、記載されている変換アルゴリズムを適用してチップの経路を算出します。算出された経路が、プレイ中に画面上で確認した内容と一致する場合、カジノは個々のチップの落下経路を操作していません。もし算出された経路に相違がある場合、その特定のチップの落下経路は改ざんされています。
Stakeは、この検証を行うアルゴリズムとサンプルコードの両方を公開しています。その他の主要な「証明可能な公平性」を掲げるカジノ（BC.Game、TrustDice、BGamingの統合サービスなど）も同様の対応を行っています。この検証は、PythonやJavaScript、あるいは標準的なHMAC-SHA256実装を備えた任意の言語で、わずか数行のコードで実行可能です。
1回のPlinko落下を段階的に検証する
具体的には、Plinkoの1回のドロップを検証する手順は以下の通りです。実運用ではStakeの仕様書に記載された形式が最も広く使用されているため、ここではそれを前提とします。
ステップ1：入力情報を収集する。 サーバーシードのローテーションと公開が完了すると、以下の情報が得られます：
- 公開されたサーバーシード（長い16進数文字列）
- 以前表示されたサーバーシードのハッシュ（64文字の16進数）
- クライアントシード（文字列）
- 検証したいドロップのノンセ（数値）
- ドロップのPlinko構成の行数（8～16行）
- ドロップ構成のリスクモード（Low、Medium、High）
ステップ2：ハッシュコミットメントの検証。 公開されたサーバーシードのSHA-256ハッシュを算出します。それを先ほど示されたハッシュと比較してください。両者は完全に一致している必要があります。一致しない場合、そのカジノは不正なものです。
ステップ3：HMACの出力を計算する。 公開されたサーバーシードを鍵として、${clientSeed}:${nonce}をメッセージとして、HMAC-SHA256を計算します。結果は、32バイトを表す64文字の16進数文字列となります。
ステップ4：HMACの出力を偏向値に変換する。 この変換方法はプロバイダーごとに異なります。Stake Originals Plinkoの場合、文書化されている方法は、HMACの出力を4バイトずつ読み取り、各4バイトのチャンクを0から1の間の浮動小数点数（具体的には：int(chunk) / 2^32）として解釈し、その浮動小数点数を使用して各行の偏向値を決定するというものです。 浮動小数点数が0.5未満の場合、チップは左へ移動し、それ以外の場合は右へ移動します。構成内のすべての行をカバーするのに十分な数のチャンクを読み取ります。
ステップ5：右折の数を着地スロットに変換する。 着地スロットは、全行にわたる右折の合計数によって決まります。16行のドロップで右折が8回ある場合、スロット8（中央）に着地します。16行のドロップで右折が0回の場合、スロット0（最左端）に着地します。右折の数を数えてスロットを特定してください。
ステップ6：乗数を確認する。 着地したスロットを、プロバイダーが公表している乗数表の「列数」および「リスクモード」の項目と照らし合わせます。乗数は、ゲーム画面に表示された数値と一致しているはずです。
ステップ7：比較する。 計算したスロットと乗数は、プレイ中にカジノに表示された数値と一致しているはずです。一致していれば、ドロップは操作されていません。もし異なる場合は、何か問題があります。
検証スクリプトさえ用意できれば、一連の手順は数分で完了します。Stake、BC.Game、BGaming向けには、いくつかのオープンソースのコミュニティ製検証ツールが存在します。また、カジノ運営会社自身も、リファレンス実装を公開していることがよくあります。
証明可能な公平性を備えたPlinkoを提供するカジノ
「証明可能な公平性」を備えたPlinkoを本格的に提供しているカジノのカテゴリーは、明確に定義されています。以下のリストは、2026年半ば時点のものです。
Stake — Stake OriginalsのPlinkoおよび対応しているサードパーティプロバイダーにおいて、証明可能な公平性を確保しています。その実装は業界で最も詳細なドキュメントが整備されており、リファレンスコードも公開されています。証明可能な公平性を示すUIはユーザーアカウント設定に組み込まれており、シードのローテーションはいつでも手動で実行可能です。
BC.Game — 自社開発の「Plinko Originals」において、証明可能な公平性を確保しています。その実装はStakeのアプローチを踏襲していますが、変換アルゴリズムに若干の違いがあります。ドキュメントは詳細に記述されています。
TrustDice — 証明可能な公平性を採用した初期のオペレーターの一つ（2018年創業）。自社開発の「Plinko」は証明可能な公平性を備えており、その実装はシンプルかつ信頼性が高い。
Roobet — カタログ掲載のほとんどのPlinkoゲーム（BGaming統合版）で「証明可能な公平性」が確保されています。RoobetのUIでは、この「証明可能な公平性」に関する設定が明確に表示されています。
BetPanda — 連携しているサードパーティプロバイダー（主にBGaming）を通じて、公平性が証明されています。実装自体はBetPandaではなくプロバイダー側によるものですが、検証プロセスは確実に機能しています。
Cryptogames — 自社開発のゲームにおいて、公平性が証明されています。インターフェースは古めかしく見えますが、計算式は正確です。
プロバイダーであるBGamingは、同ゲームを導入するすべての事業者に「証明可能な公平性」を備えたPlinkoを提供していますが、一部の事業者はプレイヤーに対して検証用UIを表示していません。本来「証明可能な公平性」を備えているゲームにおいて、事業者がそのUIを表示しない場合は、それを事業者の品質に関する重要な指標と見なすべきです。
証明可能な公平性を備えたPlinkoを提供していない事業者には、法定通貨を主軸とするカジノの大半、独立した「Plinkoマネーゲーム」モバイルアプリ全般、そしてマーケティングの勢いに実装が追いついていない小規模な事業者が多数含まれます。事業者の規制当局や監査実績が明確でない限り（英国賭博委員会、マルタ賭博局、およびeCOGRAまたはiTech Labsの認証を取得している場合を除く）、証明可能な公平性を備えていないPlinkoの利用はお勧めしません。
「証明可能な公平性」が証明しないこと
これは、多くのマーケティング資料で省略されがちな部分です。「証明可能な公平性」は特定の暗号学的特性であり、それには明確な限界があります。
これは、乗数が公正であることを証明するものではありません。 RTPが90％の乗数表を持つ「証明可能な公正性（Provably Fair）」を備えたPlinkoは、確かに証明可能な公正性を備えていますが、ゲームとしては劣っています。乗数表は公開されており、確率からRTPを計算することができますが、その計算は「証明可能な公正性」の仕組みとは無関係です。RTPは別途評価する必要があります。
これは、カジノが確実に支払いを行うことを証明するものではありません。 プロバブル・フェアは、チップの軌跡が公正に決定されたことを確認するものです。これは、出金リクエストが処理されるかどうかについては何も示していません。カジノは、プロバブル・フェアなプリンコを提供しながらも、出金リクエストを拒否することが可能です。この2つは無関係です。
これは、カジノが規約を変更しないことを証明するものではありません。 ボーナス規約、最大ベット額に関するルール、高額当選後の本人確認要件など、これらはいずれも「証明可能な公平性（Provably Fair）」の仕組みには含まれていません。これらは運営側の対応であり、別途検証が必要です。
ソフトウェアのバグに対しては保護されません。 バグのある「証明可能な公平性」の実装は、暗号学的検証（数学的な計算が正しいこと）を満たしていても、誤った乗数を出力したり、間違ったスロットに支払いを行ったりする可能性があります。主要な実装は徹底的に監査されていますが、新しいものやあまり知られていないものは、監査を受けていない可能性があります。
クライアント側での改ざんを防ぐことはできません。 計算自体は正しいのですが、カジノ側がUI上で誤った結果を表示しつつ、バックエンドでは正しい結果を反映している場合（あるいはその逆の場合）、この不一致はクライアントとサーバーの間で生じるものであり、暗号技術そのものによるものではありません。別のツールを使って検証を行えば、この不一致を検出できます。
ハウスエッジが変わるわけではありません。 証明可能な公平性（Provably Fair）を備えたプリンコであっても、依然として期待値がマイナスとなるゲームです。1～3％のハウスエッジは、乗数表に組み込まれています。証明可能な公平性により、そのハウスエッジは検証可能になりますが、それがなくなるわけではありません。
率直に言えば、「証明可能な公平性（provably fair）」は、運営者が個々の結果を事後的に操作できる余地を大幅に制限するものです。しかし、運営者に対する信頼性の問題を全般的に解決するものではありません。全体像を把握するには、「証明可能な公平性」の検証と、カジノレビューの柱で論じられている運営者の質に関する側面とを併せて検討してください。
証明可能な公平性の実装における一般的な課題
私たちが監査した実装において、3つの問題が繰り返し見受けられます。
サーバーのシードが適時に更新されていません。 サーバーのシードは、そのシードに基づくベットが過剰に蓄積する前に更新される必要があります（カジノによっては、1つのシードにつき1000ベットといった区切りで更新する場合もあれば、ユーザーの要求に応じて更新する場合もあります）。カジノがシードを一切更新しない場合、検証を行うことはできません。暗号技術上、シードが公開されて初めて証明が完了するからです。
変換アルゴリズムが公開されていない。 HMACの出力は256ビットですが、それらのビットがどのようにチップパスに変換されるかは、プロバイダー固有のアルゴリズムによるものです。アルゴリズムが公開されていない場合、その変換を再現することはできません。主要なプロバイダーはアルゴリズムを公開していますが、公開されていないアルゴリズムに遭遇した場合は、証明可能な公平性がないものとして扱う必要があります。
UIによって「証明可能な公平性」の設定が隠蔽されている。 一部の運営会社は「証明可能な公平性」を備えたゲームを導入しているものの、シード回転のUIをプレイヤーに公開しておらず、事実上、ユーザー側からの検証を不可能にしている。マーケティングを鵜呑みにする前に、この点に留意しておくべきだ。
これら3つのケースすべてにおいて、暗号技術自体は妥当である可能性がありますが、プレイヤーは検証プロセスにアクセスすることができません。その結果、実質的には「証明可能な公平性」が全く存在しないのと同じことになります。
検証ツール
検証計算を自動化するコミュニティツールがいくつか存在します。
Stakeの公式検証ツールは、ユーザーアカウントの設定内に組み込まれており、シードとノンセを貼り付けることで結果を検証できます。これは便利ですが、Stakeを信頼していない場合、これは自己矛盾に陥ります。なぜなら、Stakeの検証ツールは、原理的には自身の計算結果について虚偽の報告をする可能性があるからです。厳密なアプローチとしては、サードパーティ製のツールで再検証を行うことが挙げられます。
BC.Gameの検証機能も同様にアカウントUIに組み込まれていますが、同様の注意点があります。
主要なカジノ向けのコミュニティ主導のオープンソース検証ツールがGitHub上に公開されています。その利点は、ソースコードを確認し、公開されているアルゴリズムが正しく実装されているかを確認できることです。一方、欠点は、そのオープンソースリポジトリを信頼する必要がある（あるいは自ら監査を行う必要がある）という点です。
自作スクリプトは、最も厳密な選択肢です。その仕組みは単純明快です。HMAC-SHA256に、公開されている変換式を適用するだけです。主要な証明可能な公平性（Provably Fair）カジノであれば、どのPlinkoの落下結果でも、わずか30行のPythonスクリプトで検証可能です。
多くのプレイヤーにとっては、公式の検証ツールで十分です。ハイステークスのプレイヤーにとっては、少なくともドロップのランダムなサンプルについて、サードパーティの検証ツールと照合することは妥当な措置と言えます。
「証明可能な公平性」の文化的意義
「証明可能な公平性（Provably Fair）」を備えたゲームは、2013年頃の初期のビットコインギャンブルシーンから登場しました。最初に広く導入されたのはSatoshiDice（最も初期の暗号資産カジノ）であり、これらは特定の信頼性の問題を解決することを目的としていました。具体的には、プレイヤーが匿名の運営者にビットコインを送金した後、結果に異議を唱える手段がないため、独自に結果を検証するか、あるいは甚大なカウンターパーティ・リスクを受け入れるしかなかったという問題です。
「証明可能な公平性」という概念は、サイコロゲームやクラッシュゲームを先駆けとして、他のゲームへと急速に広がっていった。 2019年から2020年にかけて「Plinko」がカジノのカテゴリーとして登場した頃には、証明可能な公平性は暗号資産ネイティブの事業者にとって当然の機能となっていた。主流のカジノ業界ではこの仕組みの導入が遅れており、ライセンスを取得した法定通貨系事業者のスロットやテーブルゲームの多くは、証明可能な公平性ではなく監査済みのRNGに依存している。しかし、暗号資産のPlinkoエコシステムにおいては、証明可能な公平性が必須条件として定着している。
その結果、現代のギャンブルにおいて特に興味深い事例の一つが生まれました。それは、従来のカジノゲームには類を見ない形で、プレイヤーが各ベットが公正に行われたかどうかを独自に確認できるというカテゴリーです。プレイヤーが実際に確認を行うかどうかは別問題ですが（大半は行いません）、その選択肢は存在しています。
ドロップを確認すべきですか？
一般的なカジュアルなプレイにおいては、そうではありません。検証には1回のドロップごとに数分（複数のドロップの場合はスクリプトの実行）かかります。費用対効果を考えると、定評のある事業者での少額の賭けにおいて、その時間を割く価値があることはほとんどありません。
検証に時間を割く価値があるのは、以下の3つの具体的なケースです：
- 初めて利用する運営会社の場合。 証明可能な公平性（Provably Fair）を掲げる新しいカジノで初めてプレイする際は、数回のドロップ結果を確認してください。多額の資金を預ける前に、計算結果に誤りがないことを確認しましょう。
- 大勝ちした後。 特に出金を申請する前には、勝ち分のドロップ結果を確認してください。計算に問題がないにもかかわらず出金が遅延する場合は、問題は暗号技術ではなく、運営会社の対応にあります。
- 不審な点がある場合。 ドロップの結果に違和感がある場合は、確認してください。多くの「違和感」は単なる変動であることが判明しますが、稀に「間違い」である場合は、バグや運営側の不正であることが判明します。いずれにせよ、検証を行うことで疑問を完全に解消できます。
検証機能があること自体が、それを常に利用することよりも重要です。「証明可能な公平性」は運営者のインセンティブを変えます。どのプレイヤーもドロップを検証できることを知っている運営者にとって、ドロップを操作しようとする動機は大幅に弱まります。この抑止効果は、プレイヤーが実際に検証を行うかどうかに関わらず機能します。
反証可能性に関する補足
証明可能な公平性を持つPlinkoの暗号的強度は、SHA-256とHMACの強度に依存しています。これらはいずれも確立されたプリミティブであり、2026年現在、実用的な攻撃手法は知られていません。もし誰かが、出力からHMACの入力を効率的に導き出す方法を発見したとしても、システム全体は崩壊しますが、それは同時にインターネットセキュリティの大部分も崩壊させることになるでしょう。その数学的強度はTLSと同程度であり、想定しうるあらゆる規模の賭け事において十分な安全性を確保しています。
「証明可能な公平性」における暗号技術以外の限界こそが、真の攻撃対象領域である。偽のシードをハッシュ化し、数回の賭けを実行した後、公開前に密かに別のシードとすり替え、そのすり替えたシードを公に開示するオペレーターであれば、SHA-256のコミットメントチェックを通過してしまうだろう（開示されたシードは正しくハッシュ化されるため）。 これに対する防御策は運用面での対応である。シードを頻繁にローテーションし、単一のドロップだけでなく多数のドロップで検証を行い、証明可能な公平性と運営者の評判を組み合わせる必要がある。
「証明可能な公平性」を超えた、運営者レベルの品質に関する詳細な解説については、カジノレビュー特集および信頼性特集をご覧ください。なぜ「証明可能な公平性」がPlinkoの「1ベットごとの構造」と自然に組み合わさるのかという数学的な根拠については、PlinkoのRTP解説およびPlinkoの物理学をご覧ください。