Nalyエンジニアリングノート：再現可能な市場スナップショット層としてのPolymarket Gamma

TL;DRPolymarket Gammaの取り込みにより、Nalyは予測市場のイベント、市場、結果、価格、タグ、決着メタデータを公開された構造化ビューとして把握できる。Nalyはこのレイヤーを使って記事候補を選び、ミスプライシングのまとめ記事を支え、KBO予測記事を補強し、出典引用を保存し、後日の検証に耐える市場スナップショットを作成する。エンジニアリング上の主張は単純だ。編集上の信頼は、生成された文章ではなく、再現可能な市場入力から始まる。

要旨

Polymarket Gamma APIは、取引インターフェースではなく、Nalyの市場発見とメタデータのソースとして扱うべきだ。Polymarketの公式ドキュメントはGammaをData APIおよびCLOB APIから分けている。Gammaはイベント、市場、タグ、シリーズ、スポーツメタデータ、検索、コメント、公開プロフィールを扱い、CLOBは注文板、価格、スプレッド、認証済み取引操作を扱う。Nalyの記事にとって、この境界は有用だ。多くの編集ワークフローでは、ティック単位の注文板詳細が必要になる前に、質問文、市場の識別情報、結果ラベル、表示確率、カテゴリタグ、締切、決着文脈が必要になる。

本稿のテーゼは、NalyがGammaをバージョン管理された市場スナップショット層に取り込むべきだというものだ。スナップショットは真実そのものではない。特定時点で観測された公開市場の状態であり、出典URLに結び付けられ、生のペイロードとして保存されるものだ。これによりNalyは、他者が隠すもの、すなわち市場文脈、シグナルの限界、記事生成時に使われた正確な証拠を公開できる。

Naly内での位置づけ

Gammaの取り込みは、記事生成の前、外部ソース発見の後に位置する。Nalyの公開経路では、下流の4つの用途に向けた証拠バンドルのうち、予測市場側を提供する。

ミスプライシングのまとめ記事には、現在のイベント候補と市場候補が必要であり、市場が示唆する確率を出典に裏付けられた推論と比較できるだけのメタデータも必要になる。
KBO予測記事には、スポーツ市場、チームまたはイベントのタグ、イベント締切、手入力の市場文脈なしに表示できる結果ラベルが必要になる。
出典引用には、読者が記事で特定の契約を取り上げた理由を監査できるよう、安定した市場URL、イベントスラッグ、市場識別子が必要になる。
予測検証には、後日の決着を、公開時点でNalyが実際に見た確率と照合して採点できるよう、履歴スナップショットが必要になる。

ローカル実行環境の事実は、新規性ではなく主に形を決めるうえで重要だ。TypeScript 5.9と tsx は取り込みスクリプトに妥当な組み合わせだ。 drizzle-orm と @neondatabase/serverless は正規化済みレコードと生JSONを永続化できる。Next.js 16とReact 19は生成された記事ページをレンダリングできる。 ai とClaude SDKパッケージは、取り込みによって市場状態が明示された後に限り、準備済みの証拠バンドルを利用できる。

技術的メカニズム

堅牢なGamma取り込みループには6つの段階がある。

発見。Nalyが幅広いアクティブ市場を発見する必要がある場合はGammaイベントを使い、既知のPolymarket URLに記事を結び付ける場合は市場またはイベントのスラッグを使う。Polymarketの市場データガイドは、イベントには関連市場が含まれるためAPI呼び出しを減らせるとして、アクティブ市場の完全な発見にはイベントを推奨している。スポーツのようなカテゴリ作業では、候補をランク付けする前に、タグとスポーツメタデータでクロール範囲を絞るべきだ。
ページネーション。Gammaはオフセット型エンドポイントとキーセット型エンドポイントの両方をサポートしている。大規模または反復的なクロールでは、キーセットページネーションの方が安全だ。なぜなら next_cursor が継続トークンになり、 offset はキーセット市場エンドポイントで明示的に拒否されるからだ。小規模で対象を絞った記事ジョブでは、クエリ範囲が狭く、出力が即座にスナップショット化される場合、オフセットページネーションもなお許容できる。
正規化。重要な正規化ルールは、結果ラベルと結果価格を位置で対応付けることだ。Polymarketの市場データ概要は outcomes と outcomePrices 配列を1対1の配列として記載しているため、インデックスの規律が重要になる。入れ替わった配列は見た目だけのバグではない。記事の市場解釈を反転させてしまう。
スナップショット化。正規化済みカラムと生JSONの両方を保存する。正規化済みカラムには、プロバイダー、取得タイムスタンプ、イベントIDまたはスラッグ、市場IDまたはスラッグ、質問文、存在する場合はcondition id、存在する場合はトークン識別子、結果ラベル、結果価格、アクティブおよびクローズ済みフラグ、終了時刻、タグ、ソースURL、ペイロードハッシュを含めるべきだ。生JSONはNalyをスキーマ変更から守り、検証時に正確な取り込み成果物を再現できるようにする。
候補スコアリング。記事ジョブは、取引執行基準ではなく編集基準で市場をランク付けすべきだ。具体的には、新しさ、利用可能な場合の出来高または流動性、決着の近さ、出典の入手可能性、カテゴリ適合性、読者に明確な対比を示せるかどうかである。候補スコアリングは、市場価格が自動的に間違っていることを示唆してはならない。調査に値する市場として印を付けるべきだ。
公開時の紐付け。生成記事が市場を引用する場合、その記事は保存済みスナップショットID、PolymarketのソースURL、執筆者が使った外部証拠セットにリンクすべきだ。これは、市場が62 percentだったと述べるだけのページと、その値がいつ、どこで、どのペイロードから来たのかを証明できるページとの差である。

レート制限もメカニズムの一部だ。PolymarketはCloudflareで強制されるスロットリングと、 /events、 /markets、 /tags、および /public-searchに対する具体的なGamma制限を文書化している。Nalyは日次公開でそれらの上限に近づく必要はないため、正しい姿勢は保守的である。すなわち、制限付き並行処理、ジッター付きリトライ、冪等性と再現のためのペイロードハッシュ、そしてジョブがスロットリング、空、または構造的に予期しないレスポンスを受け取ったときのアラートである。

文献が示すこと

近年のarXiv研究は、スナップショット優先の設計を支持している。Jiaらは、分散型予測市場のデータがオフチェーンメタデータ、約定レベルの取引記録、オラクル決着イベントに分断されていると述べたうえで、識別子解決、増分更新、整合性メカニズムを備えた統一的なリレーショナルシステムを主張している。Nalyのより小規模な公開システムにも同じ種類の問題がある。市場メタデータだけでは、後で価格、記事の主張、決着結果に結合できなければ不十分だ。

Leのキャリブレーション研究は、記事の言葉遣いに直接関係する。大規模なKalshiおよびPolymarketデータセットを用いた同論文は、キャリブレーションがドメイン、時間軸、取引サイズ効果に依存すると論じている。価格を額面どおりの確率として扱う消費者は、それを体系的に誤解しうる。Nalyにとってこれは、記事が真実ではなく、市場が示唆する確率、観測価格、または公開市場シグナルと表現すべきことを意味する。記事は、生の市場観測をNalyのモデルまたは出典に裏付けられた推論から切り分けた後にのみ、潜在的なミスプライシングを論じられる。

DubachのPolymarketマイクロストラクチャー論文は主に注文板データを扱っているが、取り込み設計に有用な警告を与えている。高頻度の市場証拠には、ソース固有のエラーモード、取り込み遅延、重要な結合がある。Gammaは注文板フィードほど細粒度ではないが、同じ原則が当てはまる。数値の出所は可視化されなければならない。Gammaスナップショット、CLOBミッドポイント、オンチェーン取引記録は関連しているが、相互に置き換えられるものではない。

Madrigal-Cianci、Monsalve Maya、Breakeyは、予測市場をベイズ逆問題として捉え、観測された確率と出来高の履歴はノイズを含み、内生的で、異質なトレーダー類型によって形づくられると位置付けている。これはNalyの編集姿勢を補強する。取り込まれた市場状態は証拠であり、評決ではない。優れたエンジニアリングは、その不確実性を生成過程で洗い流すのではなく、検査可能にする。

設計上のトレードオフ

Gamma対CLOBが最初のトレードオフだ。GammaはNalyに発見可能性、記事文脈、メタデータを与える。CLOBはより鋭い価格付けと注文板の仕組みを与える。日次のエンジニアリング記事や予測市場のまとめ記事では、Gammaをデフォルト入力にすべきだ。なぜなら市場が何についてのものかに答えるからである。記事にスプレッド、ミッドポイント、価格履歴の精度が必要な場合には、CLOBを追加できる。

イベント優先か市場優先かが2つ目のトレードオフだ。イベント優先は、1つのイベントが複数の市場と共有メタデータを含みうるため、広範なスキャンでは低コストだ。市場優先は、最終的なスコアが特定の二値結果に結び付くため、検証にはより明快だ。Nalyは両方の形を取り込むべきだが、単一の結果を評価する場合は、記事リンクが市場レベルの主張を指すようにすべきだ。

生JSON対型付きスキーマが3つ目のトレードオフだ。生JSONだけなら保存は簡単だが、安全にクエリするのは難しい。型付きカラムだけならクエリは簡単だが、プロバイダーのフィールドが進化すると脆い。持続的なパターンは両方を持つことだ。ランキング、レンダリング、結合には型付きフィールドを使い、監査、再現、移行には生ペイロードを使う。

ライブレンダリング対凍結レンダリングが4つ目のトレードオフだ。ライブ市場ウィジェットは有用な場合があるが、記事の主張は公開時点のスナップショットに結び付けなければならない。そうしなければ、Polymarketが市場を動かし、閉じ、または決着させたときに、古い記事の意味が静かに変わってしまう。Nalyの信頼戦略では、日付付きの主張を行うページにおいて、鮮度より凍結された証拠が勝る。

失敗モード

最も危険な失敗は、結果と価格の不整合だ。もし Yes と No ラベルが価格とは別々にパースされると、記事はもっともらしく見えたままシグナルを反転させてしまう可能性がある。

2つ目の失敗は、古い市場の再利用だ。市場は発見時にはアクティブでも、公開時にはクローズしている可能性がある。各記事ジョブは、スナップショットを紐付ける直前に、アクティブ、クローズ済み、アーカイブ済み、終了時刻の各フィールドを再検証すべきだ。

3つ目の失敗は、複数市場の曖昧さだ。Polymarketのイベントには複数の取引可能市場が含まれうる。まとめ記事はイベントを引用できるが、検証記録はNalyが評価した特定の市場と結果を引用しなければならない。

4つ目の失敗は、スキーマドリフトだ。公開APIはフィールド名、デフォルト、ネストされた関係を変更する。スナップショット保存には、ドリフトを観測可能にするため、ペイロードハッシュ、パーサーバージョン、プロバイダーURL、検証エラーを含めるべきだ。

5つ目の失敗は、キャリブレーションを過剰に主張することだ。市場価格は有用な公開シグナルだが、文献は、あらゆるドメインと時間軸にわたってそれをきれいな確率として扱うことに警鐘を鳴らしている。Nalyのコピーは、市場が示唆する確率、Nalyの推定、実現結果の違いを保つべきだ。

6つ目の失敗は、引用の喪失だ。記事がレンダリング済みMarkdownだけを保存している場合、後日の検証では、どの市場ページとペイロードが主張を支えたのかを証明できない。記事と市場の結合は、埋め込まれた文章ではなく、第一級のレコードであるべきだ。

実装メモ

実用的なNaly実装では、取り込み契約を小さく保てる。

provider： polymarket-gamma。
provider_url：発見に使った正確なGammaエンドポイントまたは公開市場URL。
fetched_at：UTCのサーバータイムスタンプ。
event_key と market_key：安定したプロバイダー識別子またはスラッグ。
question：標準化された市場質問文。
outcomes：順序付きラベル。
outcome_prices：順序付き10進文字列。検証後にのみ数値へ正規化する。
status：アクティブ、クローズ済み、アーカイブ済み、公開可能性の各フラグ。
raw_payload：プロバイダーの完全なレスポンス。
payload_hash：冪等性と再現のための決定論的ハッシュ。
parser_version：ペイロードを解釈したコード契約。

記事生成器は、これを緩いプロンプト文ではなく、構造化された証拠として受け取るべきだ。そのうえで既存のAIスタックを通じてMarkdownを生成し、サイトパイプラインでレンダリングし、引用をソースレコードに紐付けたままにできる。検証ワーカーは後で、記事の市場スナップショットを決着データに結合し、公開された主張が時間の経過に耐えたかどうかを採点できる。

エンジニアリング原則は意図的に保守的だ。取り込み、正規化、スナップショット化、引用、それから執筆。この順序は、モデルに市場ページを閲覧して要約させるより遅いが、Nalyが獲得とリテンションのために実際に必要とする成果物を作る。すなわち、結果が判明した後でも市場証拠を再現できる公開記事である。