Kalshi のスクレイピング方法(2026年版、API & Python)

Kalshi はすでにマーケットデータ向けにオープンでキー不要の REST API を公開しています — 価格、板情報、取引履歴、イベント、シリーズはすべて external-api.kalshi.com で公開読み取りできます。したがって、2026 年の「Kalshi をどうスクレイピングするか」への率直な答えは、ほとんどの読み取りユースケースでは Kalshi 自身の API を直接呼び出すことです。アカウントがなお必要になるのは取引だけです — 発注には KYC 済みの署名付きリクエストのセッションが要ります。本ガイドでは Kalshi の公式 API、その上に手動でウェブサイトをスクレイピングする必要がない理由、そして構造化 API がその代わりに価値を発揮する場面を扱います。

Kalshi のデータをスクレイピングする理由

• イベント確率のトラッキング — Kalshi の「yes」価格は、実世界の出来事(選挙、FRB の決定、天候、スポーツ)に対するライブでマーケットが織り込んだ確率であり、予測シグナルとして有用です。
• 従来の世論調査に対するマーケットセンチメントのリサーチ — Kalshi が織り込んだオッズを世論調査や専門家の予測と比較し、群衆と調査機関がどこで見解を異にするかを見る。
• トレーディングとクオンツリサーチ — 戦略の構築やバックテストのための板情報、取引記録、ヒストリカルなローソク足。
• ニュースと予測プロダクト — あるイベントに関するニュース報道の傍らに「マーケットは何が起こると考えているか」というウィジェットを表示する。
• AI パイプライン — 不確実な結果に対する数値の読みを必要とするリサーチエージェントやダッシュボードに、ライブのイベント確率を供給する。

Kalshi のスクレイピングは合法か

選択肢 1: Kalshi 自身の公式 API(とその限界)

Kalshi に関しては、公式 API がまず手を伸ばすべきものです — 公開されており、ドキュメントも整っており、スクレイピングで得られるのと同じデータを返します。

curl "https://external-api.kalshi.com/trade-api/v2/markets?limit=10"

x-api-key も OAuth もアカウントも読み取りには不要です。カバーする範囲となお存在する限界は次のとおりです。

• 読み取りはオープン、書き込みはゲートされている。 マーケット、イベント、シリーズ、取引、板情報は公開です。発注には承認済みのアカウントが必要です — RSA 署名付きリクエスト(KALSHI-ACCESS-KEY、-TIMESTAMP、-SIGNATURE)に加えて KYC が必要で、Kalshi は米国の一部の州でのみ利用できます。
• レート制限はアカウントのティアに応じてスケールする。 公開/ベーシックアクセスはトークンバケット式のリミッター(エントリーティアでおおよそ 20 読み取り/秒)を使っており、上位のトレーディングティアではより高い上限が得られます。ポーリングの頻度が高い場合でも 429 に対してバックオフすべきです。
• 規約が制限するのはダウンストリームの利用であり、アクセスではない。 API 自体は大量のデータを取得することを止めません — 商業的に何を構築できるかを制限するのは Data Terms of Service です(上記参照)。
• それでも独自のスキーマを組み立てる必要がある。 マーケット、イベント、シリーズ、板情報、ヒストリカルなローソク足はそれぞれ別のエンドポイント群で、それぞれ固有のパラメータ(event_ticker、series_ticker、カーソル、period_interval)を学び、ページングする必要があります。

選択肢 2: ウェブサイトに対して Python で DIY(そしてなぜそれが不要か)

Kalshi 自身の JSON API がオープンであるため、kalshi.com のレンダリング済みページをスクレイピングする理由はほとんどありません — API がすでに構造化されたフィールドとして提供している数値のために React アプリをパースすることになり、API にはないマークアップの変化を引き継ぐことにもなります。最小限の DIY プルは次のようになります。

import requests

r = requests.get(
    "https://external-api.kalshi.com/trade-api/v2/markets",
    params={"limit": 10, "status": "active"},
).json()
markets = r["markets"]

これは 1 本のスクリプトとしてはうまく機能します。トレードオフは複数のプラットフォームをまたいで取得し始めたときに現れます。

• Kalshi のスキーマは Kalshi 独自のもの。 フィールド名、ティッカーの形式、ページングカーソルはこの API 固有のもので、Kalshi が追跡する複数マーケットの 1 つに過ぎない場合、維持すべき独立した統合になります。
• ソース間で統一された認証や正規化がない。 Polymarket や Metaculus、あるいは従来のマーケットデータも取得しているなら、それぞれに独自のクライアント、スキーマ、レート制限の挙動があり、これらを調整する必要があります。
• ポーリングとストレージは自分で持つことになる。 Kalshi はプルのリトライも重複排除もタイムスタンプ付けもしてくれません — いずれにせよそれはあなたのコードの責任です。

選択肢 3: 構造化された Kalshi API

Kalshi スクレイピング APIの価値は、Kalshi が隠しているデータを解放することではなく、Kalshi とカタログ内の他のすべてのプラットフォームにまたがる 1 つの正規化されたスキーマと 1 つの x-api-key を提供することです。これにより、ソースごとに別々のクライアントを維持する必要がなくなります。アクティブなマーケットを一覧するには次のようにします。

curl "https://api.crawlora.net/api/v1/kalshi/markets?limit=10&status=active" \
  -H "x-api-key: $CRAWLORA_API_KEY"

Python でのマーケット、イベント、履歴は次のとおりです。

import requests
h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/kalshi"

markets = requests.get(f"{base}/markets", headers=h,
                        params={"limit": 10, "status": "active"}).json()["data"]
market = requests.get(f"{base}/market/KXELONMARS-99", headers=h).json()["data"]
events = requests.get(f"{base}/events", headers=h, params={"limit": 10}).json()["data"]

マーケット詳細のレスポンスは、そのまま保存できる正規化された JSON です(実際のフィールド)。

{
  "code": 200,
  "msg": "OK",
  "data": {
    "market": {
      "ticker": "KXELONMARS-99",
      "event_ticker": "KXELONMARS-99",
      "title": "Will Elon Musk visit Mars before Aug 1, 2099?",
      "status": "active",
      "last_price": 0.08,
      "yes_bid": 0.08,
      "yes_ask": 0.1,
      "volume": 94840.88
    },
    "source_url": "https://external-api.kalshi.com/trade-api/v2/markets/KXELONMARS-99",
    "fetched_at": "2026-06-07T14:00:00Z"
  }
}

板情報と価格履歴も同じキーの背後にあります。

book = requests.get(f"{base}/market/KXELONMARS-99/orderbook", headers=h).json()["data"]
history = requests.get(f"{base}/market/KXELONMARS-99/history", headers=h,
                        params={"period_interval": 1440}).json()["data"]
trades = requests.get(f"{base}/trades", headers=h, params={"ticker": "KXELONMARS-99"}).json()["data"]
event = requests.get(f"{base}/event/KXELONMARS-99", headers=h).json()["data"]
series = requests.get(f"{base}/series/KXELONMARS", headers=h).json()["data"]

マーケットは ticker(例: KXELONMARS-99)、イベントは event_ticker、シリーズは series_ticker で識別されます — シリーズは繰り返し発生するトピック(週次の経済指標発表のような)、イベントはその下にある具体的なインスタンス、マーケットはあるイベント内の個々の yes/no コントラクトです。すべてのレスポンスには source_url と fetched_at が含まれるので、各行にタイムスタンプを添えて保存し、スケジュールに沿って再取得しましょう。

何を収集できるか

• マーケット — ティッカー、ステータス、直近価格、yes/no のビッド・アスク、出来高を、一覧またはティッカー指定で。
• 板情報 — マーケットのライブな yes/no 価格レベルとサイズ。
• 価格履歴 — マーケットごと、または複数ティッカーをまたいだ OHLC ローソク足と建玉。
• 取引 — マーケットごと、または取引所全体の、価格・サイド・数量を伴う個々の約定。
• イベントとシリーズ — イベントのメタデータ、決済ソース、グループ化されたマーケット、シリーズレベルのカテゴリ・頻度。
• 取引所のステータスとスケジュール — 取引がアクティブかどうかと取引所の営業時間。
• ヒストリカル/決済済みデータ — Kalshi のライブカットオフを過ぎた確定済みマーケットと取引。

制約

• 本当のゲートは API ではなく Data Terms of Service。 読み取りはオープンですが、Kalshi のデータの再配布、他者のためのアーカイブ、ML/AI の学習への利用には事前の書面での同意が必要です — 商業プロダクトを構築する前に規約を確認してください。
• 予測マーケットの価格であり、確実性ではない。 「yes」価格はマーケットが織り込んだ確率であり、結果の保証ではありません — シグナルとして扱い、予測そのものとして扱わないでください。
• 米国規制下の、米国中心のマーケット。 Kalshi は CFTC が規制する DCM(指定契約市場)で、取引は米国の一部の州で利用可能です。マーケットデータもその範囲を反映しています。
• ヒストリカルデータにはカットオフがある。 Kalshi はライブ/アクティブなデータを、独自の cutoff エンドポイントを持つ historical/ のセットと分けています — どちらの期間を照会しているか確認してください。
• 投資助言ではない。 すべてのプルに fetched_at を保存し、値をトレーディングシグナルではなくリサーチの入力として扱ってください。

どこで使われるか

• 予測と確率ダッシュボード — あるイベントについて Kalshi が織り込んだオッズが時間とともにどう動くかを追跡。
• センチメント比較 — 同じイベントに関する世論調査、専門家の予測、ニュース報道の傍らに Kalshi の価格を並べる。
• クオンツとリサーチパイプライン — 戦略リサーチのための板情報と取引履歴(Kalshi の規約に従う)。
• AI エージェントとリサーチツール — 下流の推論のための、実世界の出来事に関する数値の確率の読み。

ソース

データ収集を始める

まずは無料で試す: 任意の公開 URL を無料ウェブスクレイパーで実行するか、アンチボットチェッカーでサイトがボットをブロックしているか確認しましょう。サインアップは不要です。

markets エンドポイントをプレイグラウンドで試し、API ドキュメントでスキーマを確認し、料金を確認してください。Kalshi はマーケットが織り込んだ確率の 1 つの読みです。従来型マーケットの側については、株式を扱うYahoo Finance のスクレイピング方法と、暗号資産を扱うCoinGecko のスクレイピング方法が、イベント駆動型の値動きと比較するのに役立ちます。この分野全般の法的な基礎についてはウェブスクレイピングは合法かを参照してください。