予測市場（Prediction Market）は、現実世界の出来事の結果を取引可能な契約に変換するものです。「2026年の米国大統領選挙で民主党候補が勝利する」、「BTCの月末終値が12万ドルを超える」、「ある選手がこの試合で2.5ゴール以上を決める」といったものです。 ユーザーは「Yes/No」または複数の結果に対応するシェアを売買して事象の確率に価格をつけ、結果が正しく確定した際に1単位の担保（通常はUSDC、USDB、またはプラットフォームのステーブルコイン）を受け取ります。

予測市場の取引メカニズムは、スポットDEXのそれとは根本的に異なります。 スポットDEXでは、それぞれ「独立した価値」を持つ2つの資産が取引されるのに対し、予測市場では、すべての結果シェアの合計が正確に1単位の担保に等しくなります。これは、マーケットメーカーが2つの資産クラス間の相対価格ではなく、総和が保存される確率分布を扱っていることを意味します。 この根本的な違いから、LMSR（対数市場スコアリングルール）やその派生形であるLS-LMSR、定積／定平均の多結果型AMM、そしてハイブリッドなオーダーブック＋AMMモデルといった、専用の価格設定関数のファミリーが生まれました。

予測市場を構築しようとするチームにとって、AMMの選択と実装は、以下の3つの要素を直接決定づける。

1. 価格発見の質：価格が、少数の大口注文によって操作されることなく、真の確率に迅速かつ安定して収束できるかどうか；
2. 流動性とスリッページ：少額の賭けが低コストで行えるか、大口注文が執行可能か、そしてマーケットメイキング資本がどれほど効率的に活用されるか；
3. プラットフォームおよびLP（流動性提供者）のリスク：イベントの結果が確定した際、マーケットメイカーは損失を被るのか？無効な市場や結果に対する異議申し立てはどのように処理されるのか？

本記事では、予測市場の基礎となる数学から出発し、LMSRとその変種、多結果イベントの統一モデル、株式分割・合併、流動性供給、手数料、オラクルによる解決、リスク管理、および裁定取引の限界について体系的に検討します。 さらに、Polymarket、Augur、Manifoldといった主流プロトコルの実践例と組み合わせることで、予測市場向けAMMソリューションを実現するためのSoonTechの包括的な設計を提示します。 予測市場を構築しているプロダクトマネージャー、スマートコントラクトエンジニア、マーケットメーカー、リスク管理責任者の方、あるいは自社のアプリケーションに予測市場機能を組み込もうとしているチームの方であっても、この記事を読むことで、設計やレビューに直接活用できる包括的なフレームワークを手にすることができるでしょう。

1. 予測市場の財務構造

1.1 1つの契約＝1つの完全な結果セット

予測市場の金融構造の中核をなすのは「完全な結果セット」です。 N通りの結果が考えられるイベントにおいて、ユーザーは1 USDCの担保を預け入れ、N株を発行できます。各結果につき1株ずつ発行されるため、1 USDCは outcome_0(1) + outcome_1(1) + … + outcome_{N-1}(1) に割り当てられます。 イベントが「解決」されると、正確に1つの結果（あるいは何らかの重み付けに基づく複数の結果）が「勝者」と判定されます。各勝者シェアは1 USDCと引き換え可能であり、敗者シェアの価値は0となります。これは、以下のことを意味します：

• いかなる時点においても、すべての結果シェアの価格の合計は常に1 USDCに等しくなります。
• 各アウトカムの価格は、市場が示唆する確率として解釈できます；
• 「Yes」の契約を1つ購入することは、p USDCを支払い、勝った場合に1 USDCを受け取ることに相当し、純利益は(1−p) USDCとなる。

この仕組みは、パリミュチュエル（競馬で用いられるプール式賭けシステム）とは異なります。パリミュチュエルではオッズは最後の瞬間にのみ決定されますが、予測市場では価格は継続的に変動し、保有者はいつでも市場価格で決済して損益を確定させることができます。

1.2 バイナリー市場と多結果市場

• 二者択一市場：「はい／いいえ」の2つの結果があり、価格は[0,1]の範囲にあり、合計が1となる。これは最も一般的な形式であり、「起こるかどうか」というタイプの事象に適している。
• 多結果／カテゴリカル市場：N個の相互に排他的な結果。例：「米国大統領選挙で誰が勝利するか」（民主党、共和党、第三政党、…）。すべての結果の価格の合計は1となる。
• スカラー市場：結果は連続値（例：「BTCの月末終値」）であり、通常は一連のトランシェ結果に分解されるか、連続価格に対してLMSRを用いて価格付けされる。
• 複数勝者型市場：複数の結果が同時に成立する可能性がある市場。例：「特定の政党が連邦議会の両院を制するか」というイベントでは、2つの結果が同時に成立する可能性がある。これには特別な設計が必要であり、もはや「勝者は正確に1つ」と単純に仮定することはできない。

異なる形式は数学的に統一できます。イベントを「結果ベクトル」と見なし、決済時に各結果に償還重み w_i ∈ [0,1] を割り当て、Σ w_i = 1 となるようにします。 二者択一の市場では w_i = 1 が1つだけですが、複数勝者市場では、w_i が分数として複数存在する場合があります。

1.3 予測市場とスポットDEXの比較

マーケットメーカー・リスク

損失の上限なし（一方的な価格変動）

損失の上限あり（最悪の損失＝流動性パラメータ b）

オラクル

スポット価格（評価用）

イベントの結果（最終的な償還を決定する）

最も重要な違いは最後の行にあります。予測市場のマーケットメーカーの最悪の損失には上限があります。なぜなら、完全なセットの発行と償還という2つのリスクフリーな操作が存在し、これらがマーケットメイキングと裁定取引のための自然なアンカーとなるからです。

2. LMSR：予測市場の標準価格関数

2.1 関数の定義

LMSRは2000年代初頭にロビン・ハンソンによって提案され、今日の予測市場において最も広く使用されているマーケットメイキングの計算式である。 N個の結果を持つ事象について、各結果iのシェア数をq_iとする。マーケットメーカーが価格設定に用いるコスト関数は C(q) = b · ln( Σ exp(q_i / b) ) であり、ここでbは「流動性パラメータ」と呼ばれる正の数である。 結果 i の株式を Δq_i 株購入する際のコストは cost = C(q + Δq_i) − C(q) であり、(負の Δq_i) 株を売却すると、それに対応する収益が得られる。 各結果の瞬間（限界）価格は p_i = ∂C/∂q_i = exp(q_i/b) / Σ_j exp(q_j/b) となる。 Σ p_i = 1 かつ p_i ∈ (0,1) であることが確認でき、これは当然ながら確率的な解釈を満たしている。

2.2 パラメータ b の意味

b は LMSR において最も重要なパラメータである。b は以下の 2 つの要素を同時に決定する：

• 価格感応度：b が大きいほど、価格曲線は平坦になり、同じ買い注文に対する価格への影響は小さくなり、スリッページも低くなる；
• マーケットメイカーの最大損失：すべての株式が極端な水準（他の値よりはるかに大きい q_i）まで買い付けられた場合、マーケットメイカーの最大損失はおおよそ b·ln(N) となる。

言い換えれば、より深い流動性を提供するには、より大きな最悪ケースの損失を負担する必要があります。これは根本的なトレードオフであり、bを恣意的に大きくすることはできず、マーケットメーカーが拠出を承諾する担保の上限と一致させなければなりません。

標準的なバイナリー市場において、0.01～0.99の価格帯をサポートするために必要な担保は、おおよそb·ln(2)となる。したがって、bはしばしば「資金」や「初期流動性」とも直接呼ばれる。

2.3 LMSRの直感的な挙動

• すべての q_i が等しい場合、すべての p_i も等しくなる（一様事前分布 1/N）；
• ある結果を買い付けると、その価格は上昇し、他の結果の価格は抑制される。ソフトマックスの指数関数的な性質により、価格は決して真に0や1には達しない；
• 買い付けコストは、すでに買い付けられた数量に応じて指数関数的に上昇するため、これにより「無限の買い付け」が自然に抑制され、価格が極端な水準まで容易に押し上げられるのを防ぐ；
• LPが資本を投入してbを設定すると、マーケットメーカーは式に基づいて自動的に価格を提示するため、オーダーブックは不要となる。

2.4 LMSRの利点と課題

利点：

• 価格は常にΣ p_i = 1を満たし、確率として直接解釈できる；
• 最大損失には上限があり、リスク管理に適している；
• 無限の流動性を提供する（どの規模の注文でも約定可能で、価格への影響が増加するのみである）；
• 式は単純であり、オンチェーンでの実装も可能である（expおよびlnが必要だが、ルックアップテーブルやABDKなどの数学ライブラリを用いて実装できる）。

問題点：

• 流動性の不均一な分布：確率0.5付近と0.01付近では、「資本に対する価格の感度」が大きく異なるにもかかわらず、bは単一のパラメータである。これにより、極端な確率では市場が浅くなりすぎたり、資本が無駄になったりしてしまう。
• 0および1付近でのスリッページ：結果がすでに極めて確実である場合（p = 0.99）、わずかな買い注文であっても価格を0.995まで押し上げることがあり、非対称的な限界コストが生じる；
• 手数料およびLPインセンティブの設計：LPは資本を供給するが、その収入は手数料とスプレッドに依存しており、ロングテールで取引量の少ない市場では、マーケットメイキングによる損失を賄いきれない可能性がある；
• 多結果拡張における計算コスト：すべての取引において、N個の結果すべてについてexpを計算する必要があり、ガス代はNに比例して増加する。

これらの問題から、数多くのバリエーションが生まれた。

3. LMSRのバリエーションと多結果イベントのための統一モデル

3.1 LS-LMSR（流動性感応型LMSR）

LS-LMSRの核心となる考え方は、bを投入された資本に応じて動的に変化させることである。より多くのLPが参加すると、bは自動的に増加し、価格曲線は平坦化する。資本が引き出されると、bは減少する。 これにより、b が固定されている場合に生じる「極端な価格での資本の浪費」という問題を回避でき、Augur などのプロトコルで採用されている解決策である。

実装にあたっては、通常、「スワップ手数料」と「流動性スコア」が導入される：

• LPが資金を預け入れると、現在のbに基づいて追加のシェアが発行されます；
• 総資本が変化するにつれて、bは特定のルールに従って更新されます（例：b = k · total_funds）；
• LPが引き出しを行う際、比例配分に基づいて償還が行われます。

LS-LMSRの数学的な詳細はLMSRよりも複雑であり、特にLPが「預け入れ–引き出し」によって裁定取引を行えないようにする必要がある点が挙げられます。しかし、これにより流動性配分の効率が大幅に向上します。

3.2 定積多結果AMM（CPMMスタイル）

別のアプローチとして、Uniswapスタイルの x*y=k を N つの結果に一般化し、「シェア積」を Π_i q_i = k と定義する方法がある。しかし、この式を単純に適用すると、Σ p_i = 1 という保存則が破れてしまう。 実際のエンジニアリングでは、通常「仮想残高＋シェアの再正規化」というアプローチが採用されます。これは、すべてのアウトカムの価格を確率シンプレックス上の点として捉え、価格設定には幾何平均または調和関数を用い、価格をアンカーに固定するために、完全セットの鋳造／償還による裁定取引操作を行うというものです。

このスキームは、一部の多結果シナリオにおいてガス代が安くなる（エクスペリエンツ不要）が、数学的性質はLMSRほど明確ではなく、アービトラージの抜け穴が生じやすく、厳密な不変条件の検証が必要となる。

3.3 Maniswap / 負の流動性パラメータ

PolymatchやManifoldなどのプロトコルでは、価格帯ごとに異なる流動性密度を得るために、bを負の値または区分関数に設定することを提案しています。 このようなバリエーションは、「0/1に近い範囲ではスリッページを低減しつつ、中間範囲ではスリッページを小さく抑える」ことが可能であり、高頻度のオッズ市場（スポーツ、eスポーツ）に適していますが、数学的な証明やコントラクトの実装はより複雑になります。

3.4 負の価格と負の流動性

一部の高度な設計では、特定の価格帯で「負の流動性」が現れることが許容されています。つまり、マーケットメーカーが大幅にアウト・オブ・ザ・マネーのシェアを積極的に売却するもので、これは本質的にオプションの売却に類似しています。これには、マーケットメーカーが十分な担保とリスク管理能力を有していることが必要であり、通常はプロのマーケットメーカーにのみ開放されています。

3.5 統一された「結果ベクトル＋解決重み」モデル

どの価格設定関数が使用されるかにかかわらず、技術的な推奨事項として、統一されたデータモデルを使用することが推奨される：

• 各イベントには outcomes[]、各アウトカムには q (現在の株式数)を持ちます；
• 解決時に、 resolution_weights[] が記述され、Σ w_i = 1 となる；
• 各 outcome_i は w_i 分の USDC と引き換えになります；
• AMMは、解決前にはqに基づいて価格を算出することのみを担当し、解決後はwに基づいて決済を行います。

この抽象化により、バイナリー市場、マルチアウトカム市場、マルチウィナー市場、およびスカラー市場が同一のコントラクト内に統合されます：

• バイナリー：w = [0,1] または [1,0]；
• マルチアウトカム：w_i = 1となるものが正確に1つ；
• 複数勝者型：複数の w_i = 1/k（比例配分）；
• スカラー型：結果の値に応じて重みが線形に配分される。

4. シェアの発行、分割、統合、および償還

4.1 完全セットのアービトラージ・アンカー

予測市場が安定した価格形成を行える根本的な理由は、以下の2つのリスクフリーな操作が存在することにある：

1. ミント（完全セットの鋳造）：1 USDCを支払って、各結果のシェアを1つずつ鋳造する；
2. マージ／決済（統合および償還）：各結果のシェアを1つずつ返却し、1 USDCを償還する。

市場価格の合計が1より大きい場合、アービトラージャーは完全セットを発行し、各結果を個別に市場で売却して利益を確定させる。価格の合計が1より小さい場合、アービトラージャーは市場で各結果の株式を1株ずつ購入し、その後「Merge」を行って1 USDCを償還する。 これにより、Σ p_i ≈ 1 が保証されます（手数料控除後のアービトラージ不可帯域を含む）。

これら2つの操作は、コントラクト内で第一級オブジェクトとして提供され、AMMと同一のシェア台帳を共有する必要があります。

4.2 分割と統合

複数の結果が想定されるシナリオでは、ユーザーはセット全体を購入するのではなく、「民主党の勝利」をより詳細なサブ結果（例：「特定の候補者が勝利する」「他の民主党候補者が勝利する」など）に分割したいと考える場合があります。イベントの階層構造は以下の通りです：

• 親イベント：民主党対共和党対その他；
• 子イベント：民主党が勝利するという前提で、具体的に誰が勝利するのか？

親イベントと子イベントのシェアは、条件付き確率に基づいて分割・統合することができます。これにより、プラットフォームは、1つのマーケットに数十や数百もの結果を列挙することなく（後者の場合、LMSRのガス代が爆発的に増加してしまうため）、一連の小さな多結果マーケットから、どのような複雑なイベントツリーでも構成することが可能になります。

4.3 流通市場での譲渡

シェアはERC-1155またはERC-20（結果ごとに1つのトークン）であり、どのマーケットでも譲渡可能です。 AMMは流動性の主な供給源に過ぎず、店頭取引や指値注文を妨げるものではありません。これにより、将来的にOpenSea、Blur、およびオーダーブック型DEXとの統合の余地が残されています。

4.4 結果確定と償還

イベントの期限が切れた後、オラクルが resolution_weights を書き込み、シェア保有者はその重みに応じて担保を償還します。主な設計上のポイント：

• 償還は常に可能でなければならない。オラクルの配信が遅延した場合でも、保有者は最終的に資金を受け取ることができる。
• 「部分的な決済」をサポートしなければならない（複数の勝者が存在するシナリオにおける比例配分による償還）；
• 異議申し立て期間中は償還を一時停止し、異議が解決された後に再開すること；
• 無効な市場（Invalid Market）については、「すべての結果に対して均等に償還する」または「すべてのポジションを返金する」という方法で処理される。詳細については第8節を参照のこと。

5. 流動性供給およびマーケットメーカーモデル

5.1 初期流動性を提供する主体

予測市場の流動性の供給源は、おおむね以下の3つのカテゴリーに分類される：

1. プラットフォーム／プロトコル・マーケットメーカー：プラットフォーム自体が資本を投入し、bを設定し、ベースラインの流動性を保証します；
2. サードパーティのLP：AMMプールに資本を預け入れ、手数料を獲得し、マーケットメイキングによる損失を負担する；
3. プロのマーケットメーカー：独自の在庫とモデルを用いてオーダーブックに気配値を提示するか、専用のマーケットメーカー用インターフェースを通じて流動性を注入する。

これら3つのモデルは共存可能です。ただし、LMSRの下では、LPのPnL＝手数料収入 ± 価格変動による在庫のPnLとなる点に留意してください。 新たな情報が現れて価格が急変した場合、先に参入したLPは損失を被る可能性があります。これはUniswap V2の「一時的な損失（impermanent loss）」に似ていますが、有効期限があり、損失の上限が定められているため、リスク構造を定量化しやすいという特徴があります。

5.2 LPシェアとリターン

LPはUSDCを預け入れ、LPトークン（ERC-20）を受け取ります。これにより、以下の権利が与えられます：

• すべての取引から発生する手数料の一部；
• マーケットメイカーの在庫の総損益（保有割合に応じて）；
• イベント解決時の担保の償還（持分比率に応じて）。

留意すべき設計上のポイント：

• イベント開催中にLPが参加する場合、現在のqおよびbに基づいて公正な預入価値を計算する必要があります。そうしないと、初期のLPの持分が希薄化されてしまいます；
• LPが撤退する際、イベントの解決までロックするべきか、それとも即時引き出しを許可すべきか？即時引き出しを許可する場合、契約内のbを調整するために「リバースミント／バーン」が必要となり、処理が複雑になる；
• 複数のLP間の手数料分配は、資本持分×プールへの参加期間に基づいて配分する必要があります。そうしないと、後から参加したLPがフリーライドすることになります。

5.3 ハイブリッド・オーダーブック＋AMM

純粋なAMM型予測市場では、大口注文において依然として明らかなスリッページが発生します。 プロのトレーダーやマーケットメーカーはオーダーブックに慣れているため、AMM手数料を支払うよりも、指値注文を出し、スプレッドで利益を得ることを好む。そのため、CEXスタイルの予測市場（およびPolymarketのCLOBのような一部のDEXスタイルの市場）は、ハイブリッドなアーキテクチャを採用している：

• AMMは「最終的な流動性のセーフティネット」として機能し、常に価格を提示します。
• 注文帳は、プロのマーケットメーカーによる指値注文のマッチングにおいて優先的に処理される；
• ユーザーの注文はまずオーダーブックから執行され、未約定分の残りはAMMを経由する；
• 裁定取引により、AMM価格とオーダーブックのミッドポイントが一致した状態が維持されます。

このハイブリッドアーキテクチャは、大口注文の処理体験を大幅に向上させますが、エンジニアリングの複雑さは一段と高まります。マッチングエンジン、リスク管理、証拠金、損失処理が必要となるためです。SoonTechがクライアント向けに予測市場を構築する際は、通常、両方のモードを提供し、ユーザープロファイルに基づいて段階的に運用を開始します。

5.4 動的なbと適応型流動性

より高度な仕組みでは、以下の要因に基づいてbを動的に調整します：

• 満期が近づくイベント：解決が近づくと情報はより完全になり、価格のボラティリティは小さくなるはずであり、bを狭めてLPリスクを低減できます；
• 取引高：取引高の多い市場では、スリッページを抑えるためにbを引き上げます；
• オラクルの信頼度：ニュースの不確実性が高い場合、流動性を段階的に引き下げることができます；
• LP資本：LPの預入額に応じて自動的に調整されます（LS-LMSR）。

ただし、動的な調整は明示的なオンチェーンのルールに従わなければならず、運用側によって恣意的に変更することはできません。そうしないと、「クジラがbを調整している」という信頼性の問題が生じます。

6. 手数料モデルとインセンティブ

6.1 手数料の課金方法

予測市場における一般的な手数料の種類：

• 取引手数料：取引額のベーシス・ポイント（bps）単位で課金される（例：0％～2％）；
• 償還手数料：オラクルコストを賄うため、決済時に課される少額の手数料；
• 利益手数料／マーケットメイカー手数料：勝者シェアの償還時に1％～5％が徴収され、マーケットメイカー／プロトコルに支払われる；
• 流動性追加／引き出し手数料：短期的なLPの出し入れを抑制するため；
• 無効市場保護手数料：すべての取引の一部が「無効市場保険プール」に充当され、市場が無効と判断された際にLPに補償されます。

この手数料体系では、ある問題を回避する必要があります。すなわち、取引手数料と利益手数料の両方を課すと、アービトラージ業者のノーアーブ帯域が広がり、価格の合計（Σp_i）が1から持続的に乖離し、ユーザー体験を損なう恐れがあります。設計段階において、Σp_iの許容範囲を数式を用いて明示的に定義する必要があります。

6.2 クリエイターへのインセンティブ（マーケットクリエイター）

UGC型予測市場プラットフォーム（例：Polymarket、Augur）では、誰でもイベントを作成することができます。代表的なインセンティブの仕組みは以下の通りです。

• 作成者は、その市場の手数料の一部（例：10％～50％）を受け取る；
• 作成者は保証金をステークしなければなりません。市場が曖昧または無効と判断された場合、その保証金は没収されます；
• 質が高く、取引量の多い市場は、追加のプロトコル報酬を獲得できる。

この仕組みは、「オープンな作成の促進」と「スパムや操作された市場の防止」とのバランスをとらなければなりません。ボンドのパラメータと異議申し立て手続きが鍵となります。

6.3 流動性マイニングとプロトコルインセンティブ

プロトコルは、初期の流動性プロバイダー（LP）やアクティブなトレーダーに対してトークン報酬を付与することで、流動性と取引高を立ち上げる（ブートストラップ）ことができます。ただし、以下の点に留意してください：

• 「ファーム・アンド・ダンプ」を防ぐため、報酬は単純な預入額ではなく、「実際の取引高」と「LPのプール滞在期間」に基づいて設定すべきです；
• イベント終了直後にリワードが一斉に解放され、LPが流出する事態を避けるため、リワードの解放はイベントのサイクルに合わせて調整すべきである。

7. オラクル解決：予測市場の真の競争優位性

7.1 決済フロー

予測市場資産の最終的な価値は、解決結果によって完全に決定されます。オラクルは、信頼の連鎖において最も脆弱なリンクです。完全な解決フローには通常、以下の要素が含まれます：

1. 市場のクローズ：あらかじめ設定された時刻に取引が停止する；
2. 提案フェーズ：誰でも、通常はボンドを担保として、結果を提案できる；
3. 異議申し立てフェーズ：提案された結果に異議がある場合、追加のトークンをステークして異議を申し立てることができる；
4. エスカレーション：紛争は、より上位の解決メカニズム（例：AugurのUMAフォーク、PolymarketのUMAオプティミスティック・オラクルとマルチシグ評議会）へとエスカレートする；
5. 最終的な解決：結果がオンチェーンに記録され、シェアを償還できるようになります。

7.2 オプティミスティック・オラクルと「デフォルトでの真実」

UMAのようなオプティミスティック・オラクルは、「まず提案し、1～2時間の異議申し立て期間を待ち、異議がなければ可決とみなす」というモデルを採用しています。これは大多数の市場において十分に効率的であり、毎回投票を行う必要はありません。紛争が発生した場合にのみ、真にコストのかかる紛争解決プロセスに入ることになります。

7.3 マルチソースによる解決と冗長性

単一のデータソースの障害を回避するため、高価値市場では以下を推奨します：

• 複数のデータプロバイダーを同時に接続する（AP通信、ロイター、公式発表、Chainlink、UMA）；
• 定量化可能な事象（スポーツの試合結果、暗号資産価格）については、複数のAPIを直接集約し、あらかじめ定義されたルールに基づいて中央値を採用する；
• 主観的な事象（政治、エンターテインメント）については、複数人による投票と紛争解決メカニズムを併用する。

7.4 解決データソースの検証可能性

より先進的なアプローチでは、結果に検証可能な証拠（API署名、公式ウェブページの検証可能な証明、報道機関からのデジタル署名など）を添付することが求められます。これにより、「誰が決定するか」という紛争は減少しますが、インフラのハードルは高くなります。

8. 無効な市場と紛争処理

8.1 無効な市場とは

市場は、以下の理由により無効（Invalid）と判断される場合がある：

• イベントの説明が曖昧で、複数の妥当な解釈が可能である場合；
• データソース間に矛盾があり、結果を確定できない場合；
• イベント自体が実際には発生しなかった場合（例：予定されていた試合が中止された場合）；
• 操作、インサイダー取引、または規則違反があった場合；
• マーケットクリエイターによる設計上の誤りがあり、結果を客観的に判断することが不可能な場合。

8.2 無効な市場における資本の取り扱い

一般的な対応策：

• すべての結果に対して均等比例で償還する：各結果_iのシェアは1/N USDCで償還される。これはすべての保有者にとって「中立」である――何を購入したかに関わらず、最終的には1シェア分のコストが返ってくる。しかし、これにより安値で購入した者は潜在的な利益を失い、高値で購入した者が利益を得る結果となる；
• すべての取引を返金し、ポジションをロールバックする：多くの取引が行われた後では、イベント開始前の状態へオンチェーンでロールバックすることはほぼ不可能です；
• 紛争発生前の市場価格での補償：紛争解決プールを利用して、紛争発生直前の最終価格でポジションを買い戻す。これはより洗練されているが、複雑さも増す。

デフォルトでは「均等比例償還」を採用し、特別なケースでは、すべての取引から少額を拠出する「無効市場保険プール」を利用して追加補償を行うことを推奨する。

8.3 紛争保証金と攻撃コスト

紛争メカニズムは、「誤った提案」と「悪意のある異議申し立て」の両方にコストを課さなければならない：

• 提案者は保証金を預託する。提案が正しければ返還＋報酬が支払われ、間違っていればスラッシュされる。
• 挑戦者も保証金を預託する。成功すれば報酬を受け取り、失敗すればスラッシュされる；
• より高いレベルへエスカレートする場合、保証金は乗数に応じて増加し、攻撃コストを指数関数的に引き上げる。

Augurの「フォークメカニズム」は究極のツールである。紛争が解決できない場合、プロトコル全体が複数のバージョンに分岐し、市場が行動によって投票を行う。これは負担が大きいものの、究極の正確性を保証する。

9. リスク管理、コンプライアンス、および相場操作対策

9.1 一般的な市場操作の手法

• 大規模な「ポンプ・アンド・ダンプ」：イベントが間近に迫り、流動性が低い状況下で、大口注文を用いて価格を極端な水準まで押し上げ、世論や他のトレーダーを誤った方向に誘導すること。
• インサイダー取引：参加者が結果（例：政治家の辞任決定、企業の決算など）を事前に把握し、情報が公表される前にポジションを構築すること；
• 結果の操作：オラクルやデータソースに対する賄賂や攻撃；
• マルチアカウントによる自己取引：流動性報酬を獲得するために、取引量や価格を偽装すること；
• 51%攻撃／ガバナンス攻撃：分散型決議メカニズムにおいて、大量のトークンを用いて投票を行い、結果を操作すること。

9.2 リスク管理ツール

• ポジション上限：単一市場におけるアドレスごとの最大ポジション、単一市場の総ポジション上限；
• 価格変動幅制限：短期的な価格変動が閾値を超えた場合に取引を一時停止／サーキットブレーカーを発動；
• KYC／地域制限：証券法や賭博法上の問題を回避するため、特定の法域（例：米国、英国）でのアクセスを制限する；
• 取引監視：オンチェーンとオフチェーンを組み合わせた異常検知により、複数アカウントの利用、ウォッシュトレード、インサイダー取引を特定する；
• 大口ポジションの開示：13Fと同様に、一定割合を超えるポジションを保有するアドレスを公開；
• ボンド／損失上限：LPおよびマーケットメーカーに対して、許容可能な最大損失額を設定する；
• クーリングオフ期間：重大なニュースの発表前後に一時的な取引停止を設け、瞬時の相場操作を防止する。

9.3 法務およびコンプライアンス

多くの法域における予測市場は、以下の点に関わります：

• 賭博法：それが「運」に基づくか、賭け金があるか、および「娯楽目的」の免除が適用されるかどうかに依存する；
• 証券法／デリバティブ規制：一部のイベント契約はスワップやバイナリーオプションとみなされる可能性がある；
• イベント契約の規制：米国商品先物取引委員会（CFTC）は、政治選挙などのイベント契約に対して明確な制限を設けている；
• AML（マネーロンダリング対策）：KYC（本人確認）、取引モニタリング、不審取引の報告が義務付けられています。

ブロックチェーンや展開形態が異なれば、対象となる規制当局も異なります。Polymarketは以前、米国の規制に対応して一部の市場を上場廃止にし、地域制限（ジオブロッキング）を導入しました。製品を設計する前に、現地の法律顧問から法的見解を得るとともに、プロトコルは地域制限および監査可能なコンプライアンスツールをサポートしている必要があります。

10. フロントエンド、ユーザー体験、およびコンポーザビリティ

10.1 体験の中に確率を隠す

一般ユーザーは「0.63」が何を意味するかは理解できませんが、「63％の確率」や「1 USDCを賭けて1.59 USDCを取り戻す」という表現なら理解できます。フロントエンドでは、以下の情報を同時に表示する必要があります：

• 暗黙の確率（パーセンテージ）；
• オッズ（1/p または小数オッズ）；
• 期待リターン（Xを賭けてYを獲得）；
• 他のユーザーや他プラットフォームのオッズとの比較。

スポーツ市場については、ユーザーの意思決定コストを低減するため、スケジュール、データ、対戦成績も表示すること。

10.2 取引体験

• クイックベット：あらかじめ設定された金額ボタン（1/10/100 USDC）、スライダー；
• 指値注文：プロユーザーは「0.42未満で『Yes』を購入」といった注文を希望します；
• ポジションの売却：ユーザーが決済前に利益を確定したり、ストップアウトを行ったりできるようにする；
• マルチポートフォリオ：「中間の結果で勝利」や「いずれかの結果が発生すれば勝利」といった戦略を構築するため、複数の結果を一度に購入可能にする；
• モバイルファースト：予測市場のユーザーの多くはソーシャルメディアから流入しているため、モバイル体験が極めて重要。

10.3 コンポーザビリティ

• シェアはERC-1155／ERC-20に準拠しており、DeFiエコシステムに組み込むことが可能：
• （主要イベント向けの）貸付担保として；
• 他のAMMやオーダーブックに組み込まれる；
• 構造化商品（例：「政治イベント・バスケットETF」）に組み込まれる；
• 他のチェーンへブリッジされる。

契約設計段階でシェアを標準トークン化することが、エコシステムの恩恵を享受するための鍵となります。

11. 実装における基本事項

11.1 数学ライブラリ

Solidityにはネイティブの浮動小数点型がありません。LMSRに必要なexp / lnは通常、次のように実装されます：

• ABDK Math 64.64（固定小数点）；
• PRBMath（固定小数点、SD59 / UD60対応）；
• プリコンパイルされたルックアップテーブル（バイナリー市場にはシグモイドテーブルが有効）；
• L2（Arbitrum Stylus、Optimism、Base）上では、ガスコストを大幅に削減するためにRust / C++で実装します。

いずれの方法を選択する場合でも、完全なファズテストが必須です。極端な q 値の下で、不変条件 Σ p_i = 1（誤差範囲内）が満たされていること、最大損失が b·ln(N) を超えないこと、および Mint/Merge が常に無裁定であることを検証してください。

11.2 コントラクトの構造

推奨されるモジュール構成：

• EventFactory：イベントの生成およびパラメータの設定；
• Market / Condition：状態、q、b、および単一イベントの解決処理；
• AMM / MarketMaker：価格設定および取引ロジック（LMSRまたはその変種）；
• CompleteSets：コンプリートセットの鋳造／統合；
• LPVault：流動性の提供、LPトークン、手数料の分配；
• OracleAdapter：UMA、Chainlink、APIの統合；
• 紛争／ガバナンス：紛争およびエスカレーション；
• ShareToken (ERC-1155)：シェアトークン。

AMMロジックをシェアおよび解決処理から分離することで、ダウンタイムなしでマーケットメイキングアルゴリズムをアップグレードできます。

11.3 ガス消費の最適化

• 多値型の場合、Nが大きいとexpの計算コストが高くなる。そのため、Σ expを事前に計算してキャッシュし、毎回、購入された結果に対応する項のみを更新し、新しい価格を段階的に計算する。
• 二値市場（N = 2）の場合、LMSRはシグモイド関数に簡略化でき、ループは不要となる；
• ガス代を節約するために、ERC-1155のバッチ転送を使用する；
• L2展開においては、ガスは主なボトルネックではありませんが、calldataのコストには依然として注意を払う必要があります。

11.4 インデックス化とデータ

予測市場のオンチェーンデータ構造は複雑である（条件、シェア、ポジション、解決）ため、Subgraph / Ponder / Envio を使用して独自のインデクサーを構築し、以下を提供する必要がある：

• 市場リストとフィルタリング；
• ユーザーのポジションと履歴；
• 価格のK線チャート；
• LP APY；
• 出来高および流動性ダッシュボード。

12. 主要プロトコルの実践事例の比較

マニホールド

社内版LMSRのバリエーション

その他

スポーツ／時事問題

Gnosis条件付きトークン

条件付きトークンフレームワーク、あらゆるAMMと組み合わせ可能

プラグイン可能

インフラとしての適性

Drift / Predict

ハイブリッドAMM＋オーダーブック

内部＋マルチソース

L1／アプリチェーン方式

いくつかの考察：

• 純粋なLMSRはオーダーブックに比べてユーザー体験（UX）が劣るが、より分散化されており、マーケットメーカーを必要としない。
• 大規模で注目度の高い市場（米国大統領選挙、ワールドカップなど）では、ほぼ常にプロのマーケットメーカーがオーダーブックの流動性を提供している；
• 決済メカニズムの選択は、マーケットメイキングの計算式よりも重要である。たとえ最も洗練されたAMMであっても、誤った決済を救うことはできない。

13. SoonTechの予測市場向けAMMランディングソリューション

13.1 モジュールの概要

SoonTechの予測市場スイートには以下が含まれます：

1. イベント＆コンディション・エンジン：バイナリ／多結果／複数勝者／スカラーに対応した統一モデル。親子イベントの分割機能を備える；
2. AMMコア：LMSR＋LS-LMSR＋CPMMのバリエーション。イベントタイプに応じて切り替え可能；
3. CLOBブリッジ：オプションのオーダーブックモジュール。プロフェッショナルなマーケットメーカーへのアクセス、AMMとの流動性共有が可能；
4. CompleteSets および ERC-1155 シェア：鋳造／統合／譲渡、標準トークンインターフェース；
5. LP Vault：LPの預入・引出し、動的b、手数料配分、一時的損失のモニタリング；
6. Oracle Hub：UMA、Chainlink、独自APIの集約、複数ソースによる検証；
7. 紛争処理フレームワーク：提案–異議申し立て–エスカレーション、ボンドおよびスラッシング機能付き；
8. リスクエンジン：ポジション上限、価格サーキットブレーカー、地域制限、不審な取引の検出；
9. フロントエンド／モバイルSDK：確率／オッズ／配当表示、ワンクリックベット、指値注文、マルチポートフォリオ；
10. 分析・インデクサー：市場、K線、LP APY、オンチェーンダッシュボード。

13.2 代表的な導入シナリオ

シナリオ 1：東南アジア向けのスポーツおよびeスポーツ予測市場

クライアントは、インドネシア、ベトナム、フィリピンでサッカー、バスケットボール、eスポーツの予測市場を立ち上げたいと考えています。 当社は、ベースの流動性としてLMSRを導入し、人気イベントについてはサードパーティのマーケットメーカーのオーダーブックを組み込み、解決にはマルチソースのスポーツデータAPIの集約と手動レビューを活用し、モバイルでの現地決済およびステーブルコインによる入金をサポートします。ローンチから3ヶ月後、月間取引高は8,000万ドルを超え、紛争発生率は0.3%未満となりました。

シナリオ2：CEXに組み込まれた政治・マクロ経済イベント市場

クライアントは中規模のCEXであり、既存のアプリに「BTC月末価格」や「FRBの利下げ」といったイベント契約を追加したいと考えています。 CLOBとAMMを組み合わせたハイブリッドアーキテクチャを採用しています。オラクルにはChainlinkと公式発表を優先的に利用し、イベント契約はCEXの統合マージンシステムに連携されているため、ユーザーは既存の契約ポジションを担保として利用できます。

シナリオ3：UGC型予測市場プラットフォーム

クライアントは、「誰でも市場を作成できる」プラットフォームを求めています。当社は、Event Factory、Creatorボンド、UMAオプティミスティック・オラクルをフルに導入し、市場の審査、レポート作成、異議申し立てのワークフローを実装します。マッチング用フロントエンドでは、テンプレートによる作成（スポーツ、政治、暗号資産、エンターテインメント）をサポートし、市場作成のハードルを下げます。

13.3 納品スケジュール

• 第1～2週：ビジネス調査、対象市場の種類、ユーザープロファイル、コンプライアンス上の制約の明確化；
• 第3～6週：コントラクト開発（LMSR + CompleteSets + LPVault + Oracle Adapter）、テスト；
• 第7～8週：監査、テストネット＋シャドウメインネット、オラクル統合；
• 第9週：フロントエンドとアプリの統合、リスクルールの設定；
• 第10週：メインネットのローンチ、制限設定＋マルチシグの監視、24時間365日のオンコール対応；
• その後：オーダーブック、親子イベント、クロスチェーン展開、マーケットメイカーのオンボーディング。

14. エンタープライズ導入に関する推奨事項

14.1 どの種類のイベントから始めるべきか

• データソースが明確で定量化可能なイベント（仮想通貨価格、スポーツの試合結果、マクロ経済データなど）から始めることを推奨します。主観的な政治イベントからは始めないでください；
• イベントサイクルを短く設定し（1～7日が最適）、ユーザーが繰り返し参加でき、製品を反復改善できるようにすること；
• 初期段階では、同時運営市場を5～10市場に限定し、流動性を集中させ、「すべての市場で流動性が薄い」状態を避けること。

14.2 チーム構成

最小構成チーム：プロダクトマネージャー（PM）1名、スマートコントラクトエンジニア2名、バックエンド／インデクサー1名、フロントエンド／モバイル1名、リスク／データ担当1名、運用／市場レビュー担当1名。オーダーブックの導入には、マッチングエンジニアがさらに1～2名必要となります。UGC（ユーザー生成コンテンツ）や紛争解決メカニズムには、コンテンツレビューと法務サポートが必要です。

14.3 主要指標

• 取引高およびユーザー数：DAU、1日あたりの取引高、単一市場のピーク値；
• 流動性指標：ビッド・アスクスプレッド、スリッページカーブ、LP資本；
• 解決の質：紛争発生率、誤った解決率、平均解決時間；
• リスク指標：相場操作の試み、ブロックされた異常取引、管轄区域ごとのコンプライアンス遵守率；
• LPの経済性：LP純利回り、リテンション率、マーケットメイキング損失／手数料比率；
• 事業指標：手数料収益、プラットフォーム手数料率、ユーザー1人あたりの価値。

15. 今後の動向

15.1 予測市場とAI情報市場

AIエージェントは予測市場において重要な参加者となるでしょう。これらはニュース、ソーシャルメディア、オンチェーンデータをリアルタイムで収集し、イベントの結果が明らかになる前に迅速に取引を行います。 これにより市場の効率性は向上するが、「ボットによる個人投資家の締め出し」への懸念も高まる。これに対処するため、開示の遅延、段階的な手数料設定、エージェント専用の市場といった仕組みが活用できる。

15.2 実世界資産（RWA）とイベント化

金利、為替、コモディティ、保険金請求といったRWAイベントを、価格決定のための予測市場へと転換する動きが拡大している。これは、伝統的な金融の先物・オプションと予測市場を融合させるものであり、コンプライアンスや決済のハードルをさらに引き上げるものである。

15.3 解決インフラの専門化

予測市場が拡大するにつれ、オラクルの解決は「楽観的な主張」から「検証可能な事実」へと進化する。報道機関によるデジタル署名、公式APIからの暗号学的証明、複雑なデータを処理するZKコプロセッサなどが、すべてインフラの一部となるだろう。

15.4 L2およびアプリチェーンの普及

予測市場では、1取引あたりの金額は小さく、取引頻度が高いため、高スループットかつガス代が安いL2やアプリチェーンに自然に適している。今後1～2年の間に、専用の予測チェーンがさらに登場するか、既存のL2上に予測市場向けのアプリチェーンが登場するだろう。

15.5 規制の明確化

米国、英国、EU、シンガポール、ドバイなどの管轄区域では、イベント契約の規制上の境界が徐々に明確化されつつある。明確なコンプライアンスの枠組みが整えば、機関投資家や従来のマーケットメーカーが参入できるようになり、予測市場の総規模は桁違いに拡大すると予想される。

FAQ

Q1: LMSRとUniswap式のAMMとの根本的な違いは何ですか？

A: LMSRは一連の確率に価格を付けます（価格の合計は常に1になります）。一方、ユニスワップは2つの独立した資産の相対的な価値に価格を付けます。 LMSRのマーケットメーカーの最大損失には上限（b·lnN）がありますが、ユニスワップのLPには上限のない一時的な損失（impermanent loss）があります。どちらもAMMの概念を採用していますが、その数学的モデルとリスクプロファイルは大きく異なります。

Q2: 価格がすでに非常に確実（例：0.99）であるにもかかわらず、購入時にスリッページが発生するのはなぜですか？

A: LMSRのソフトマックス関数には、p = 0.99付近でもまだ傾きが残っているためです。 価格を0.99から0.995に押し上げるコストは、0.5から0.6に押し上げるコストよりも高くなる可能性があります。この「極端な価格帯では流動性のコストが高くなる」という現象は、LMSRに対する一般的な批判点であり、LS-LMSRや類似のバリエーションはこれを改善するために設計されています。

Q3: マーケットメーカー／LPは損失を被る可能性がありますか？

A: はい。新たな情報によって市場価格が急激に再評価された場合、事前に在庫を構築していたマーケットメーカーは損失を被る可能性があります。最大損失は (b·lnN) に制限されますが、実際の損失は価格の推移によって異なります。LPは、手数料収入でこうした損失を補填する計画を立て、ボラティリティの高いイベント時には流動性の提供に慎重になるべきです。

Q4：結果について確信がある場合、どの価格で買うべきですか？

A: 主観的な確率が市場価格よりも高い場合（p_market < p_you）に「Yes」を購入してください。その場合、期待リターンはプラスになります。ただし、解決リスク、流動性、手数料、時間的コストも考慮に入れてください。0.99の価格で1％の利益を得るためだけに、誤った解決で1％のリスクを負うようなことはしないでください。

Q5: 市場が無効と判定された場合はどうなりますか？

A: 一般的な対応としては、すべてのシェアが1/Nで均等に償還され、さらに「市場無効保険プール」からの追加補償が支払われます。取引を行う前にプラットフォームの市場無効ポリシーをよく読み、説明が曖昧な市場への賭けは避けてください。

Q6: 予測市場をゼロから構築するにはどれくらい時間がかかりますか？

A: 基本的なLMSR＋バイナリー市場＋シンプルなオラクルであれば、3～4週間でテストネットに展開可能です。多結果対応、LPヴォールト、ハイブリッドオーダーブック、紛争解決メカニズム、完全なフロントエンド、リスク管理を含めると、通常3～4ヶ月かかります。 ゼロから開発するよりも、成熟したスイート（SoonTechのソリューションなど）をカスタマイズすることをお勧めします。

結論

予測市場のAMMは、一見すると単なる価格算出式のように見えますが、実際には金融工学、分散型紛争解決、オラクル、リスク管理、コンプライアンス、ユーザー体験が交差する地点に位置しています。 LMSR が業界標準となったのは、その洗練された数学的構造だけでなく、最大損失が有限であること、価格が確率論的な解釈に自然に合致すること、そして「完全セット・アービトラージ」と完全に互換性があることによるものです。 しかし、予測市場製品の成否を真に決定づけるのは、価格設定関数そのものではなく、解決メカニズムの信頼性、流動性の深さ、リスク管理の厳格さ、そしてユーザー体験の円滑さである。

本記事では、金融構造、LMSRとそのバリエーション、シェアシステム、流動性供給、手数料インセンティブ、オラクルによる決済、無効な市場、リスクとコンプライアンス、フロントエンド体験、エンジニアリング実装から、主要プロトコルの比較に至るまで、予測市場向けAMMの設計空間全体を体系的に解説した。 2026年の米国大統領選挙、ワールドカップ、暗号資産ETF、マクロ的な金利変動といったイベントが予測市場を主流へと押し上げ続ける中、この分野は製品とインフラの新たな爆発的成長の波を迎えようとしています。

SoonTechチームは、予測市場、CEX、DEXなど、複数の製品ラインにわたる豊富な経験を有しています。予測市場AMMは、当社の最も差別化されたモジュールの一つであり、すでに東南アジアのスポーツ、CEXのイベント契約、UGCプラットフォームなどで稼働しています。 貴チームが予測市場を構築中である場合、既存の取引プラットフォームにイベント契約を追加する場合、あるいは自社のアプリケーションに予測機能を組み込みたいと考えている場合、ぜひご相談ください。ターゲット市場、ユーザープロファイル、コンプライアンス要件に基づき、契約開発、オラクル統合、リスク設計からフロントエンドやアプリに至るまで、エンドツーエンドのソリューションを提供いたします。

「群衆の知恵」に価格をつけ、情報の発見をより効率的にし、見解を持つ誰もが参加できるようにすること――これこそが予測市場の長期的な価値であり、私たちがインフラの改良を続けている理由です。

🌐 SoonTechと共に、安全でスケーラブルなWeb3プラットフォームを構築しましょう。

ホワイトラベル型暗号資産取引所、予測市場、MPCウォレット、マッチングエンジン、流動性統合、コンプライアンスに関する当社のソリューションをご覧ください。