バイナンス（Binance）APIのIPホワイトリストは、最も重要なセキュリティ対策のひとつです。これを設定すると、指定されたIPアドレスからのリクエストのみがアカウントの操作を許可されるようになり、万が一APIキーが漏洩しても、第三者が不正に注文を出すことを防げます。この記事では、クラウドサーバーの固定IP、家庭用回線の動的IP、マルチ出口IP、VPNプロキシ、IPv6の5つのシナリオにおける完全な構成案を紹介します。現在の出口IPを確認するスクリプトや、10のよくある誤解についても解説します。バイナンスアカウントをお持ちでない方は、まず バイナンス公式サイト で登録を完了させてください。新規ユーザーの方は 無料登録 も可能です。
一、IPホワイトリストのコア規則
| 規則 | 説明 |
|---|---|
| 1キーあたりの最大IP数 | 30個 |
| IPタイプ | IPv4 のみサポート（IPv6は現在未対応） |
| CIDRセグメント | サポート対象外（1つずつ個別に入力が必要） |
| 反映時間 | 保存後、即座に有効化（通常30秒以内） |
| 出金権限 | IPホワイトリストの設定が必須（制限なしの場合、出金権限は強制無効） |
| 変更頻度 | 制限なし、いつでも調整可能 |
重要：IPホワイトリストが設定されていないAPIキーでは、出金権限を有効にすることはできません。これはバイナンスの強制的なセキュリティルールです。
二、シナリオ1：クラウドサーバー（静的IP）
最も理想的なシナリオです。API作成時に、クラウドサーバーのパブリックIPを直接入力します。
1. クラウドサーバーのパブリックIPを確認する
# 方法1：外部サービスに問い合わせる
curl -4 ifconfig.me
curl -4 ipv4.icanhazip.com
curl -4 api.ipify.org
# 方法2：Alibaba Cloud（アリババクラウド）のメタデータ
curl http://100.100.100.200/latest/meta-data/eipv4
# 方法3：AWS のメタデータ
curl http://169.254.169.254/latest/meta-data/public-ipv4
2. バイナンスでの設定手順
バイナンスAPI管理ページ → キーの編集 → 「信頼できるIPのみにアクセスを制限する (推奨)」を選択 → IPアドレスを入力 → 保存。
複数のIPを指定する場合は、カンマ（,）で区切ります：
1.2.3.4,5.6.7.8,9.10.11.12
3. クラウドサーバー利用時の注意点
- エラスティックIP（EIP）を解放するとIPが保持されないため、必ずバイナンス側のホワイトリストからも削除してください。
- オートスケーリンググループのインスタンスはパブリックIPが変動するため、ホワイトリストには不向きです。NATゲートウェイを使用して出口IPを固定することをお勧めします。
- CDNリバースプロキシは適していません。バイナンス側にはプロキシ業者のIPが見えるため、バックエンドサーバーのIPが直接届きません。
三、シナリオ2：家庭用ブロードバンド（動的IP）
家庭用回線のIPは24時間ごとに変わる可能性があります。いくつかの対応策があります：
案A：IP制限なし（最も簡単だがリスクが高い）
バイナンスAPI管理ページで 「制限なし（セキュリティが低い）」 を選択します。デメリット：
- 出金権限が自動的に無効になります。
- キーが漏洩した場合の防御策がありません。
データの読み取り専用（Enable Readingのみチェック）の場合に適しています。
案B：IPホワイトリストを動的に更新（中間案）
バイナンスはホワイトリストを更新するためのAPIを提供していないため、ウェブページから手動で変更する必要があります。したがって、完全な自動化は不可能です。
半自動化の方法：
- 現在の出口IPを1時間ごとにチェックします。
- 設定済みのホワイトリストIPと比較します。
- 一致しない場合、Telegramなどの通知サービスでアラートを送信します。
- 手動でバイナンスにログインし、更新します。
スクリプト例：
import requests
import time
CURRENT_WHITELIST = {"1.2.3.4"} # バイナンスに設定しているIP
TG_BOT = "TELEGRAM_BOT_TOKEN"
TG_CHAT = "YOUR_CHAT_ID"
def get_current_ip():
return requests.get("https://api.ipify.org").text.strip()
def notify(msg):
requests.get(
f"https://api.telegram.org/bot{TG_BOT}/sendMessage",
params={"chat_id": TG_CHAT, "text": msg}
)
last_ip = None
while True:
ip = get_current_ip()
if ip != last_ip:
if ip not in CURRENT_WHITELIST:
notify(f"IPが {ip} に変更されました。バイナンスのホワイトリストを更新してください。")
last_ip = ip
time.sleep(3600)
案C：DDNS + 固定入口（推奨）
固定IPを持つクラウドサーバーをリバースプロキシ/踏み台として使用します：
自宅PC → SSHトンネル → クラウドサーバー → バイナンスAPI
クラウドサーバー側で以下を実行（例：低スペックのVPSで十分です）：
# 自宅PCでSSHトンネルを確立
ssh -N -L 8443:api.binance.com:443 [email protected]
コード内の BASE_URL を https://localhost:8443 に変更します（TLS証明書の検証処理が必要です）。あとは、クラウドサーバーの固定IPをホワイトリストに追加すれば完了です。
よりスマートな方法は、WireGuard VPNを構築し、自宅PCの全トラフィックをVPS経由にすることです。
四、シナリオ3：マルチサーバー負荷分散
本番環境の取引戦略では、冗長化のために複数のサーバーにデプロイされることが一般的です：
メイン戦略: アリババクラウド 東京リージョンA (IP: 47.1.2.3)
バックアップ戦略: AWS 東京リージョンB (IP: 54.4.5.6)
監視サービス: テンセントクラウド 香港 (IP: 150.7.8.9)
バイナンス側でこれら3つのIPをすべてカンマ区切りで入力します：
47.1.2.3,54.4.5.6,150.7.8.9
セキュリティ強化：各サーバーに1つの共通キーを共有するのではなく、サーバーごとに独立したキーを作成してください。これにより、万が一1台のサーバーが侵害されても、そのキーを無効化するだけで済み、他のサーバーは継続して動作可能です。
五、シナリオ4：VPN / プロキシの出口IP
1. 最終的な出口IPを確認する
VPNやプロキシを使用すると、トラフィックはあなたの実際のIPではなく、プロキシの出口から送信されます：
# プロキシ経由で確認
curl -x http://proxy.example.com:8080 ifconfig.me
# または VPN 接続後に確認
curl ifconfig.me
プロキシの出口IPをホワイトリストに追加してください。
2. 共有出口のリスクに注意
商用プロキシの出口IPは、何千人ものユーザーと共有されている可能性があります。このようなIPにはリスクがあります：
- 誰かがそのIPで規約違反をした場合、そのIP全体がブロックされ、他の共有者も影響を受けます。
- バイナンスのKYC要件に適合せず、アカウントの調査を誘発する可能性があります。
商用プロキシは取引APIにはお勧めできません。自前のVPSと専有IP（固定IP）を使用するのが最も安全な解決策です。
六、シナリオ5：Docker / Kubernetes コンテナ
コンテナの出口IPは、ホストマシンのネットワーク構成によって決まります：
1. ホストネットワークモード
# Docker Compose の例
services:
bot:
image: mybot
network_mode: "host" # コンテナはホストのIPを使用
この場合、コンテナの出口IP = ホストマシンのパブリックIPとなります。
2. ブリッジネットワーク + NAT
services:
bot:
image: mybot
networks:
- default
DockerはデフォルトでNATを介して転送するため、出口は依然としてホストマシンのパブリックIPになります。
3. Kubernetes
NATゲートウェイまたはEgress Gatewayを介して出口IPを統一します。主要なクラウドベンダー（GKE、EKS、ACKなど）は、固定出口IP機能をサポートしています。
七、IPホワイトリストが機能しない主な原因
| 症状 | 原因 | 解決策 |
|---|---|---|
| 新しいIPがホワイトリストにない (-2015) | IPが変更されたが更新されていない | バイナンスで更新する |
| IPは正しいが呼び出しに失敗する | VPCルートやファイアウォールによる遮断 | アウトバウンド規則を確認 |
| curlは成功するが、プログラム実行で失敗する | プログラムが別途プロキシを経由している | http_proxy 環境変数を確認 |
| ifconfig.me ではAだがバイナンスはBと報告する | 複数のNICがあり、出口ルートが異なる | route -n で確認 |
| 追加直後のテストで失敗する | キャッシュが更新されていない | 30秒待ってから再試行 |
| VPN切断後に自宅IPが露出する | VPNにキルスイッチがない | iptablesでVPN外の通信を遮断 |
八、二重の保険：アプリケーション層でのIP検証
バイナンス側で制限をかけていても、プログラム側でも起動時に自己診断を行うべきです：
import requests
EXPECTED_IP = "1.2.3.4"
def verify_ip():
current = requests.get("https://api.ipify.org").text.strip()
if current != EXPECTED_IP:
raise SystemExit(f"出口IPが異常です: {current} ≠ {EXPECTED_IP}。起動を中止します。")
print(f"IP検証に成功しました: {current}")
verify_ip()
# その後にバイナンスクライアントを初期化
九、よくある質問 FAQ
Q1: 1つのキーに最大いくつまでIPを設定できますか？
A: 最大30個です。すべてカンマで区切って同じ入力ボックスに入力してください。30台以上のサーバーがある場合は、サーバーグループごとに複数のキーを作成することをお勧めします。
Q2: 日本国外のIPもホワイトリストに追加できますか？
A: はい、有効なIPv4アドレスであれば、バイナンスのサーバーが特定の地域のIPを拒否することはありません。
Q3: IPホワイトリストとファイアウォールの違いは何ですか？
A: IPホワイトリストはバイナンス側のアクセス制御（リクエストの送信元を制限）です。ファイアウォールはあなたのサーバー側のアクセス制御（トラフィックの流入を制限）です。両者は補完関係にあり、両方設定するべきです。
Q4: VPSがIPv6のみをサポートし、バイナンスが対応していない場合は？
A: バイナンスは現在IPv6ホワイトリストをサポートしていません。解決策として、curl -4 で強制的にIPv4を使用するか、OSレベルでIPv6を無効にしてください。
Q5: ホワイトリスト設定後、相場の取得もそのIPから行う必要がありますか？
A: はい、その通りです。IPホワイトリストは、署名が必要なインターフェースだけでなく、X-MBX-APIKEY を含むすべてのリクエストを制限します。Headerを含まない公開相場（/ticker/price など）は制限されません。
IPホワイトリストの構成案を確認したら、カテゴリナビ に戻って「API連携」カテゴリの他のセキュリティ強化ガイドをチェックしましょう。