Polymarket Bot Tutorial · 第32章中6章目

Polymarket botの認証とウォレット設定：proxy walletとEOAの違い、SDK経由のAPIキー生成、Gnosis Safe向けのsigType 2、鍵の保管ベストプラクティス、そしてMagicからPrivyへの移行。

Polymarkets.co.ilのリードライター、Harley Young著。最終レビュー：2026年5月。

この章で扱う内容

Polymarketのウォレットモデルには3つの要素があります。注文に署名する externally owned account（EOA）、資金を保有する smart-contract proxy、そしてHTTPリクエストを認証する Polymarket CLOB API key です。この3つを正しく連携させることは、新規ビルダーにとってDay 1で最もよくある失敗であり、2025年8月のMagic LabsからPrivyへの移行以降はさらに分かりにくくなりました。この章では、各要素をセットアップ順に、production codeで必要になる具体的な環境変数と signature-type フラグとともに解説します。

  • Proxy walletとEOA: botで使うのはどちらか
  • API keyの生成（SDK手順）
  • sigType 2とPOLY_FUNDER_ADDRESS（Gnosis Safe）
  • 鍵の保管：.env、vault、KMS
  • Magic LabsからPrivyへの移行
  • USDC/pUSD spendingの承認
  • Walletの復旧とバックアップ

Proxy walletとEOA: botで使うのはどちらか

Polymarketはsmart-contract proxy walletのパターンを使っています。あなたのEOA-private keyに紐づくアドレス-がtransactionsとordersに署名します。決定論的なアドレスにデプロイされたGnosis Safeが、実際のpUSDとoutcome sharesを保有します。Proxy address はPolymarket UIの「wallet」パネルに表示されるもので、署名を行うのはEOAです。

botでは、常にEOA（env内のPRIVATE_KEY）で署名し、CLOB client configではproxy addressをPOLY_FUNDER_ADDRESSとして参照します。funderとしてEOAを使ってorderを送ると、proxyに資金があっても「insufficient balance」エラーになります。

EOAだけでbot運用することはできません。Polymarketのweb flowは、signup時に必ずproxyを作成します。CLIのpolymarket wallet showで両方のアドレスを確認するか、Polymarket UIのsettingsからproxy addressを確認してください。

API keyの生成（SDK手順）

CLOB APIには3つの認証情報が必要です。key、secret、passphraseです。これらはwallet private keyではありません。walletに紐づいたHMAC形式の認証情報セットで、HTTP request authentication専用です。

SDKで一度だけ生成します。

# Python
from py_clob_client.client import ClobClient
c = ClobClient(host="https://clob.polymarket.com", chain_id=137,
               key="<PRIVATE_KEY>", signature_type=2,
               funder="<PROXY_ADDRESS>")
creds = c.create_or_derive_api_creds()
print(creds.api_key, creds.api_secret, creds.api_passphrase)

出力はJSONファイルに保存し、bot起動のたびに読み込んでください。セッションごとに再生成してはいけません。API serverは認証情報セットをキャッシュしており、頻繁なローテーションはrate-limit logicを引き起こすことがあります。認証情報は自動では期限切れになりません。漏えいの疑いがある場合にのみローテーションしてください。

sigType 2とPOLY_FUNDER_ADDRESS（Gnosis Safe）

signature_type引数は、CLOBがorder署名をどのように検証するかを制御します。値は3つありますが、実際に使うのは2つです。

  • 0 / EOA: EOAがsignerかつfunder。private keyを直接インポートした特殊なセットアップ向けです。
  • 1 / POLY_PROXY: 旧Magic Labs proxy contract。2025年以前のほとんどのアカウント。
  • 2 / POLY_GNOSIS_SAFE: 現在の標準。資金はGnosis Safeにあり、EOAが署名します。

2025年8月以降に作成されたアカウント（Privy移行後）や、Polymarket UIでGnosis Safe addressが見えるアカウントでは、必ずsignature_type=2を使ってください。POLY_FUNDER_ADDRESS環境変数には、EOAではなくSafe addressを指定する必要があります。funder typeと不一致のsignature_typeを使うと、「insufficient allowance」や「balance: 0」のような order rejection が黙って返されます。エラーメッセージは誤解を招きます。

鍵の保管：.env、vault、KMS

EOA private keyの現実的な保管方法は3段階あります。

  1. .env file（単一マシンでの開発）。ファイルはVPS上に置かれ、botは起動時にそれを読み込み、keyはホストの外に出ません。<$1kのwalletなら十分です。chmod 600 .envを実行し、repoの.gitignoreに必ず含めてください。
  2. Self-hosted vault（HashiCorp Vault、ageで暗号化したファイル、またはsystemd-creds）。bot起動時にunlock stepが追加されます。$1k-$10kのwalletなら導入する価値があります。
  3. Cloud KMS（AWS KMS、GCP KMS）。botがKMSを呼び出してmemory上でkeyを復号し、keyはdiskに触れません。運用の複雑さに見合うのは$10k超、または複数bot fleetの場合です。

絶対にやってはいけないこと：private keyをgitにcommitする、chatに貼る、local-only modeのないクラウド同期付きpassword managerに保存すること。Polymarket EOAが漏えいした場合のon-chain blast radiusは、pUSD残高とoutcome share inventoryのすべてです。

Magic LabsからPrivyへの移行

2025年8月、Polymarketは埋め込みウォレットの主要プロバイダをMagic LabsからPrivyへ移行しました。botから見た影響は小さいですが、具体的です。

移行前のアカウント（Magic経由で作成）は通常signature_type=1（POLY_PROXY）を使います。移行後のアカウントはsignature_type=2（POLY_GNOSIS_SAFE）を使います。古いアカウントを移行したユーザーもいれば、元のまま使い続けたユーザーもいます。public APIだけで、アカウントがどちらのタイプを使っているかを見分ける方法はありません。orderへの署名を試し、rejectionを確認して判定します。

この移行では、UIでfunder addressの見え方も変わりました。以前のPolymarket UI flowではdashboardにproxy addressが表示されていましたが、現在のflowではaccount settingsの中に隠れています。CLIのpolymarket wallet showを使うのが、アカウント作成時期に関係なく両方の値を確認する最も確実な方法です。

USDC/pUSD spendingの承認

CLOBがorder match時にあなたのpUSDを動かすには、proxyがPolymarket exchange contractsをspenderとして承認している必要があります。Polymarket UIは最初のdeposit時にこれらのapprovalを設定します。proxyへ直接fundするbotでは、手動で設定する必要があります。

walletごとに一度だけ設定する3つのapproval:

  1. pUSD (ERC-20) → exchange contract
  2. Conditional Tokens (ERC-1155) → exchange contract（sharesを売る場合）
  3. Conditional Tokens (ERC-1155) → NegRisk exchange contract（NegRisk sharesを売る場合）

初回セットアップ時にCLIからpolymarket approveを実行してください。transactionのgas代は数セント程度のMATICです。polymarket approve checkで確認すると、3つすべてが「approved」を返すはずです。新規ビルダーで最も多い無言のバグはNegRisk approvalの不足で、multi-outcome marketのsharesを売るときにだけ失敗し、balance errorのように見えます。

Walletの復旧とバックアップ

botのwalletには、復旧可能な要素が2つあります。EOA private keyと、Polymarket account passwordです。後者はweb UIからのアクセスを制御しますが、SDKからのアクセスは制御しません。

botにとって重要なのはEOA private keyだけです。失えばproxy内のすべてを失います。Cold backup: 紙に書き、封筒に封入し、オフサイトで保管する。Hot backup: 暗号化したUSB stick。自分宛てにメールしてはいけません。暗号化されていないままクラウドストレージに保存してもいけません。

Polymarket account passwordは、元のsignup emailをまだ管理している限り、Magic Labs / Privyのemail recoveryで復旧できます。bot accessを左右するものではありません。botはEOA private keyを直接使うからです。

key漏えいが疑われる場合は、すぐにpUSDとoutcome tokensを新しいwalletへwithdrawし、新しいEOAを生成して、新しいkeyでbotを再デプロイしてください。漏えいしたkeyはrevokeできません。できるのは資金を抜き取ることだけです。

よくある質問

bot用に別のwalletは必要ですか？
強く推奨します。botに割り当てた資本だけを保有する、新しいEOAまたは新しいemail-account由来のproxy walletを使ってください。bot keyが漏えいしても、危険にさらされるのはbot資金だけで、メインの保有資産は安全です。
Polymarkets APIのsigType 2とは何ですか？
sigType 2はGnosis Safe（proxy wallet）の署名を示します。email/Googleでログインし、Polymarketがproxyを作成する場合に使われます。sigType 2では、POLY_FUNDER_ADDRESS環境変数はEOAではなくPROXY address（Polymarket UIに表示されるもの）である必要があります。これはよくある設定ミスです。
Polymarket API keyはどうやって生成しますか？
SDKを使います。Pythonでは、wallet認証後にclient.create_api_key()から返されるApiCredsを使います。Node.jsでは、@polymarket/clob-client-v2 の client.createApiKey() から同様に生成します。返されたkey/secret/passphraseは .env に保存してください（絶対にgitへcommitしないでください）。
Polymarket API keyはrevokeできますか？
はい。SDK経由でいつでも新しいkeyをderivationできます。古いkeyは、client.deleteApiKey(creds)で明示的にrevokeされるまで有効です。ベストプラクティスは、keyを定期的にrotateし、compromised machineに触れたkeyはすべてrevokeすることです。
PolymarketがMagic LabsからPrivyへ移行したとき、何が変わりましたか？
login OTP codeが3桁（brute forceに弱く、2025年12月のhackで悪用された）から、より長いcodeとPrivyによるdevice bindingへ変わりました。botにとって実務上の変更はauth ceremonyです。SDKがほとんどを抽象化します。もしあなたのbotがMagic Labs API endpointにハードコードされていたなら（まれです）、Privy flowへ更新してください。
鍵は .env file に保存すべきですか？
単一VPSのbotなら、適切なfile permissions（chmod 600 .env、bot user所有）付きで、はい。複数machineのセットアップやproduction-gradeの運用なら、secrets manager（AWS Secrets Manager、Vault、doppler.com）へ移行してください。.envをgitにcommitするのは、絶対にやめてください。