取引所のAPIキーとは、API Key と API Secret の組み合わせです。このキーを使うと、プログラムやサービスはWeb管理画面にログインせず、API経由でアカウントを操作できます。残高の読み取り、取引の開始と終了、そのキーに許可されたその他の操作を実行します。
この記事の目的: 取引所がAPIリクエストに適用する制限を説明します。API Secret による署名検証、キーの権限（permissions）、リクエスト送信元の IP whitelist への紐付け、出金先アドレスの whitelist による出金制限、sub-accounts による残高の分離です。これらの制限は、API Key + API Secret の組み合わせが漏えいした場合に、資産の出金や損失取引につながるリスクを下げます。
🧭 暗号資産取引所でAPIアクセス制御がどのように機能するか
APIキーは、取引ボット、取引端末、レポートサービス、社内連携で使われます。取引所は、署名（API Secret）、操作権限（permissions）、送信元IPアドレス（IP whitelist）、リクエスト時刻（timestamp と recvWindow）を確認した後でのみ、APIリクエストを実行します。時刻チェックは、リクエストが傍受された場合でも、後から同じリクエストを再実行されることを防ぎます。
APIのリスクはキー設定で下げます。IP whitelist は指定されたIPアドレスからのリクエストだけを受け付けます。Permissions は、そのキーで取引所が実行する操作の範囲を制限します。出金先アドレスの whitelist は受取人の一覧を制限します。Sub-accounts は残高とキーをサブアカウント間で分離し、1つのキーがアカウント内のすべての資産へアクセスできないようにします。
🎯 APIで起こり得る損失: 出金、振替、取引損失
APIによる損害は、有効化されている permissions と、そのキーからアクセスできる残高に依存します。Trade-only キーは、小さな運用残高のサブアカウントではリスクが低く、主要資本を置いたサブアカウントではリスクが高くなります。
取引所がAPI経由で実行する3つのシナリオ
APIによる損失は、出金、内部振替、または約定価格によって損失を生む取引を通じて発生します。
- 直接出金: withdraw permission を持つキーは、取引所の確認と whitelist ルールを通過したアドレスへの出金を開始します。
- 内部振替: transfer permission を持つキーは、取引所がAPI経由でその操作を許可している場合、プロダクト内ウォレット間またはサブアカウント間で資産を移動します。
- 出金を伴わない取引損失: trade permission を持つキーは、流動性の低いペアに注文を出し、不利な価格で約定させ、スリッページ、スプレッド、手数料による損失を作ります。
withdraw permission を無効にすると直接出金は取り除かれます。取引ウォレットに大きな残高があり、キーがIPや取引銘柄で制限されていない場合、trade permission はなお損失の原因になります。
API確認が必要になるシグナル
- 取引システムのロジックや稼働スケジュールに合わない注文が出現した。
- 運用上の理由がないのに、ウォレット間またはサブアカウント間の振替が発生した。
- キー設定に新しい permissions が追加された、または IP whitelist が削除された。
- 取引システムのログに署名エラーが出始め、コードが変わっていないのにリクエスト頻度が増えた。
🔍 取引所がAPIリクエストを検証する仕組み: 署名、権限、IP、時刻
APIキーは、API Key（キー識別子）と API Secret（署名用の秘密情報）で構成されます。署名は、そのリクエストが API Secret を使って作成され、途中で改ざんされていないことを取引所に確認させます。
- 取引所のAPIエンドポイント（特定の操作を受け付けるAPIアドレス）へ送るリクエストパラメータを作成する
- リクエストは、注文を出す、注文をキャンセルする、残高を取得する、振替を実行する、出金を開始するなどの操作を指定します。
- リクエストには timestamp と、場合によっては許容時間幅である recvWindow が含まれます。取引所はこれらの値を自社の時刻と比較し、許容範囲を外れている場合はリクエストを拒否します。
- HMAC によってリクエストパラメータに署名する
- HMAC は秘密鍵を使うハッシュ署名です。パラメータ文字列は API Secret で署名されます。
- 取引所は同じパラメータから HMAC を再計算し、署名を比較します。一致しなければ、送信者が API Secret を持っていない、またはパラメータが変更されたことを意味します。
- キーの制限を確認し、実行可否を判断する
- Permissions は、そのキーに許可される操作を指定します（多くの中央集権型取引所、CEXでは read/trade/transfer/withdraw）。
- IP whitelist はリクエストの送信元を制限します。送信者のIPがキーのホワイトリストに含まれていない場合、取引所はリクエストを拒否します。
- 操作を実行し、結果を返す
- 権限が不足している場合、署名が正しくても、取引所は拒否を返して操作を実行しません。
- IPが一致しない場合、取引所は認可段階で拒否を返し、取引操作や出金操作へ進みません。
取引所が制御するAPIアクセスの構成要素
取引所は各リクエストで3つの確認を行い、APIリスクを下げます。API Secret による署名、操作の permissions、リクエスト送信元の IP whitelist です。
- API Secret は、シークレット保管領域と、リクエストに署名するプロセスのメモリ内だけに保持します。
- Permissions はキーの用途に合わせて有効にします。レポート用の読み取り、ボット用の取引、運用上の支払いに限った出金などです。
- IP whitelist には実際にリクエストを送信するサーバーのIPだけを入れ、リストが攻撃対象領域を広げないようにします。
攻撃者が API Secret なしで API Key だけを得た場合、取引所は署名不正としてリクエストを拒否します。攻撃者が API Key と API Secret の両方を得た場合でも、permissions が操作を許可していない、またはIPが whitelist に入っていなければ、取引所はリクエストを拒否します。
🌐 IP whitelist: キーをリクエスト送信元サーバーに紐付ける
IP whitelist は、事前に指定したIPアドレスからのリクエストだけを取引所に受け付けさせます。API Secret がコード、ログ、バックアップ、外部サービスに入り込んだとしても、攻撃者は whitelist にないIPからリクエストを送れません。
安定したAPIリクエスト送信元の選択
- 固定の公開IPを持つVPS（仮想サーバー）は、IP whitelist と取引システムの継続稼働に適しています。
- 動的IPの家庭用インターネットは適しません。IPが変わると、whitelist を更新するまでAPIリクエストが拒否されるためです。
APIキーの IP whitelist 設定
- IP whitelist には、取引システムのサーバーIPと、実際に使う場合だけ予備サーバーのIPを含めます。
- 取引所が CIDR（例: 203.0.113.10/32 のようなサブネット表記）に対応している場合、送信元リストを広げないよう最小範囲を指定します。
APIアクセスの耐障害性確認
- インフラ移行やサーバーアドレス変更時には、別IP用の予備APIキーを使います。
- IP変更が注文制御の喪失と重ならないよう、IP whitelist の更新手順を事前に固定しておきます。
クラウドインフラでは、リクエストが NAT（ネットワーク境界でのアドレス変換）を通ってインターネットへ出る場合があります。この場合、取引所が見る外部IPは、コンテナや仮想マシンのIPと異なることがあります。IP whitelist には egress IP（外向き通信の外部IP）を指定します。そうしないと取引所はリクエストを拒否します。
IP whitelist はVPSの侵害からは保護しません。サーバーが乗っ取られると、攻撃者は同じIPからリクエストを送れるため、VPSへのアクセス保護と更新管理もAPI保護の一部です。
IP whitelist は、取引所が送信元IPを whitelist と比較し、取引操作や出金操作の実行前にリクエストを拒否するため、外部サーバーからのリクエストをブロックします。
🔑 Permissions: 具体的な用途に合わせてキーへ付与する権限
Permissions は、そのキーで取引所が呼び出しを許可するAPIエンドポイントを決めます。権限名は取引所によって異なりますが、通常の構成は共通しています。読み取りの read、注文の trade、内部振替の transfer、ブロックチェーン出金の withdraw です。
| 用途 | 許可する | 禁止する | ブロックされる操作 |
|---|---|---|---|
| スクリーナー/分析 | Read | Trade; Transfer; Withdraw | 注文発注と資産移動 |
| 取引ボット | Read; Trade | Withdraw | APIによる直接出金 |
| レポート | Read | Trade; Transfer; Withdraw | レポートサービス侵害時の操作 |
| 運用上の振替 | Read; Transfer | Trade; Withdraw | 取引操作とブロックチェーン出金 |
監視とレポート用の read-only キー
Read-only キーは、システムが残高、取引履歴、ポジション状態を読む必要はあるが、アカウント状態を変更してはいけない場合に使います。
- Read-only キーは注文の発注とキャンセルをブロックします。取引所がこのキーによる取引エンドポイントを拒否するためです。
- IP whitelist はデータへのアクセスを特定のサーバーに限定し、API Secret 漏えい時に他のIPからのリクエストをブロックします。
- レポート用に別の read-only キーを使うと、レポートサービスのリスクを取引キーのリスクから分離できます。
Read-only キーは残高と履歴を見せますが、出金や取引は許可しません。取引所が trade/transfer/withdraw エンドポイントを拒否するためです。
出金なしで取引システムに使う trade キー
Trade キーは注文の発注とキャンセルに使います。取引操作に withdraw permission は不要です。
- Trade permission は、アカウントの市場範囲内で注文とポジションを管理するアクセスを与えます。
- withdraw permission を無効にすると、取引所がこのキーによる出金エンドポイントを拒否するため、出金がブロックされます。
- IP whitelist はキーを取引システムのサーバーに紐付け、API Secret 漏えい時に他のマシンからのリクエストをブロックします。
Trade-only キーは取引ウォレット上の資金にリスクを作るため、取引用 sub-account には通常、主要資本ではなく運用残高だけを置きます。
内部移動用の transfer キー
Transfer キーは、取引所内の振替に使います。取引所がAPI経由で許可している場合、プロダクト内ウォレット間または sub-accounts 間の移動です。
- Transfer permission は、ブロックチェーンへ出ない内部振替を実行できるようにします。
- trade permission を無効にすると、振替キーは注文を作成できないため、取引を除外できます。
- withdraw permission を無効にすると、振替キーが侵害されてもブロックチェーン出金を除外できます。
transfer と trade を別々のキーに分けると、1つのキーで取引と資産移動の両方に同時アクセスできなくなるため、漏えい時の損害を減らせます。
Permissions は、そのキーで取引所がどの操作を許可するかを決めます。不要な permissions は、侵害されたキーで取引所が実行する行動の範囲を広げるため、権限は具体的なプロセスに必要なものだけを有効にします。
🏷️ 出金保護: アドレス whitelist、確認、上限
Withdraw permission は、APIキーに取引所残高からブロックチェーンへの出金開始を許可します。出金保護は、受取アドレスの whitelist、whitelist 変更の管理、出金上限に基づきます。
取引連携では通常、withdraw permission を無効にします。注文、キャンセル、残高読み取りは取引所内部で実行され、ネットワークへの出金を必要としません。監視とレポートには read 権限で十分です。アルゴリズム取引には trade 権限で十分です。
例: 取引ボットは trade permission を持ち、withdraw permission を持たないキーで動きます。キーが侵害された場合、攻撃者は取引エンドポイント経由でポジションを開閉できます。しかし出金リクエストは、キーに withdraw permission がないため取引所に拒否されます。
アドレス whitelist は出金先を制限します。取引所は事前に追加されたアドレスにだけ資金を送ります。多くの取引所では、アドレスを whitelist に追加する際に2FA（二要素認証）と、email、アプリ、ハードウェアキーなど別チャネルでの確認が必要です。この場合、新しいアドレスへの出金はAPIキーだけでなく、これら確認チャネルの管理にも依存します。
whitelist 変更の遅延（security lock、ホールド）は、追加されたアドレスをすぐには有効化しません。遅延が有効な場合、新しいアドレスへの出金はホールド期間中ブロックされるため、最初の出金前にアドレス追加に気づけます。
取引ボットのAPI接続、trade-only キー、IP whitelist については、暗号資産の取引ロボットで収益を得る方法で説明しています。
出金上限は、攻撃者が whitelist と確認を通過するキーを得た場合の損失額を制限します。1回の出金サイクルで入金全体を引き出せないよう、日次上限はアカウント総残高ではなく、通常の運用支払い額に合わせて設定します。
メールの侵害はリスクを高めます。多くの取引所では、アドレス追加の確認やセキュリティ設定のリセットが、確認リンクや whitelist 変更通知を含めて email に紐付いているためです。
アドレス whitelist なしの withdraw permission は、APIキー漏えいをブロックチェーン出金への直接経路にします。アドレス whitelist と whitelist 変更遅延を伴う withdraw permission は、重大なリスクを確認チャネルの侵害へ移します。出金上限は、他の制限を回避された場合の損失額を制限します。
🛡️ Sub-accounts: 残高、キー、プロセスの分離
Sub-accounts は、1つの取引所内で残高とAPIキーを分離します。キーが漏えいした場合、操作は特定の sub-account の資産に制限されます。
- 保管と取引を別々の sub-accounts に分ける
- 保管用 sub-account は主要資本を保持し、常設の取引用APIキーを使いません。
- 取引用 sub-accounts は、特定のボットや戦略のための運用残高を保持します。
- APIによる内部振替を管理する
- 取引キーで transfer permission を無効にすると、取引キー漏えい時に資産を移動される可能性を下げられます。
- 内部振替が運用プロセスに含まれる場合は、専用の transfer キーを使います。
- 取引ペア whitelist に対応している場合はキーの銘柄を制限する
- 取引ペアの whitelist は、取引システムに関係しない銘柄での取引をブロックします。
- ペア制限は、流動性の低い市場での損失リスクを下げます。
複数の取引システム向けの分離構成
分離構成では、sub-accounts で残高を分け、APIキー、permissions、IP whitelist でアクセスを分けます。
- 1つの取引所上の1つの取引システムは、専用 sub-account と、VPSのIPに紐付けた trade-only キーで動かします。
- レポートは別サーバーの read-only キーで接続し、レポート側の漏えいが取引キーを露出させないようにします。
- 運用上の振替は、trade と withdraw permissions を持たない transfer キーで実行します。
取引システムのキーが漏えいしても、取引所はその sub-account の残高範囲内でのみ操作を実行するため、損失は運用残高に限定されます。
🗄️ シークレット保管とローテーション: API Secret がインフラから漏れる仕組み
API Secret は取引所からではなく、取引システムのインフラから漏れることが多いです。コードリポジトリ、CI/CDパイプライン（ビルドとデプロイの自動化プロセス）、アプリケーションログ、データベースダンプ、スクリーンショット、バックアップなどです。シークレット管理は、API Secret の保管場所と、それにアクセスできるロールを固定します。
API Secret はアプリケーションコードに保存しません。サービス起動時に保護された保管領域からシークレット値を注入し、プロジェクトファイルやリポジトリには保存しません。コードと設定には、シークレットの値ではなく参照だけを残します。
例: 取引ボットをCI/CDでデプロイします。リポジトリにはシークレット名だけを保存し、API Secret の値はデプロイ段階で保護された保管領域から注入します。コードやコミット履歴が漏れても、そこに API Secret は含まれません。
Production では、API Secret を secret manager に保存します。これはシークレットを暗号化して保持し、IAM（ロールによるアクセス管理）で許可されたプロセスにだけ渡すサービスです。この構成は、production のシークレットを dev 環境やテストサービスから分離します。
リスクと取引計画を扱う際の行動面の失敗は、トレーダー心理の記事で解説しています。
APIキーのローテーションは、長期間残る漏えいのリスクを下げます。ローテーションには、取引所で新しいキーを作成すること、システムを新しい API Secret に切り替えること、取引所が古いシークレットによる署名を受け付けなくなるよう古いキーを取り消すことが含まれます。
切り替えは、未決済ポジションや有効な指値注文がない時間帯に計画します。API Secret の変更で注文管理やリスク管理の流れが途切れないようにするためです。
API Secret 保管の最小ルール
- API Secret は secret manager またはアクセス制御付きの暗号化保管領域に保存する。
- API Secret は Git、Docker image、CI artifacts、バックアップに平文で入れない。
- Production シークレットは dev 環境からアクセスできず、取引システムを起動しないロールからもアクセスできない。
- ローテーションでは、切り替え後に古いキーを取り消し、古い secret が取引所側で機能しないようにする。
Permissions、IP whitelist、アドレス whitelist は取引所側で保護し、secret management はインフラ側のコードやログから API Secret が漏れるリスクを下げます。
🧩 外部端末とボット: 接続がリスクに与える影響
外部サービスは、アカウント名義でリクエストに署名するために API Key と API Secret を受け取ります。サービスがWeb管理画面でキーを受け取る場合、API Secret はプロバイダーのインフラに保存されます。プロバイダーでインシデントが起きると、攻撃者はリクエストに署名し、取引所側の署名チェックを通過できます。
✅ 管理されたリスクの兆候
- サービスが read-only と trade-only キーで動作し、取引やレポートに withdraw permission を要求しない。
- サービスがAPI操作ログを表示する。作成された注文や呼び出されたエンドポイントを確認できる。
- サービスが、限定された運用残高を持つ専用 sub-account での接続に対応している。
❌ リスク上昇の兆候
- 運用上の支払いと関係ない機能に withdraw permission を要求する。
- IP whitelist の無効化を求め、ユーザー側エージェントと固定IPを使うモデルを提示しない。
- API操作履歴を提供しないため、調査が間接的な兆候に依存する。
構成例: シグナルとレポートには read-only キーを使い、取引操作には運用残高を持つ sub-account の trade-only キーを使い、APIによる出金は無効にします。
外部サービスを使っても、取引所側の制限は無効になりません。Sub-account、IP whitelist、最小 permissions、無効化された withdraw permission は、リスクを運用残高に限定します。
🧯 キー漏えいへの対応: 実行停止と痕跡の保全
API Key + API Secret の組み合わせが漏えいした疑いがある場合、リスクは急速に進行します。取引所は署名、権限、IP、リクエスト時刻を確認した直後に操作を実行するためです。対応は、キーによる認可を止め、操作の痕跡を保全するところから始めます。
- 取引所側でキーを取り消す
- キーを無効化または削除すると、その API Key による署名付きリクエストの受け付けが停止します。
- 漏えい元が特定できない場合は、sub-account のすべてのキーを無効化します。
- 操作の痕跡を保全する
- 異常期間の未約定注文一覧と取引履歴は、どの操作が実行済みかを示します。
- 出金履歴とアドレス whitelist の変更履歴は、出金の試行とアドレス準備を示します。
- アカウントへの追加アクセス経路を閉じる
- パスワード変更と2FA確認は、Webインターフェースへのログインリスクを下げます。
- 出金確認や whitelist 変更が email に紐付くことが多いため、メールのセキュリティ確認が必要です。
- 業務アクセスを復旧する
- 新しいキーは、最小 permissions と現在のサーバー向け IP whitelist で作成します。
- 古いシークレットが使われ続けないよう、API Secret を secret manager で更新します。
キーの取り消しは、その API Key による署名を取引所が受け付けなくなるため、リクエストが送られ続けても操作の実行を止めます。
✅ キー漏えい時の出金リスクを下げる構成
API Key + API Secret の組み合わせが漏えいした後の出金リスクは、trade キーが withdraw permission を持たず、リクエストが IP whitelist で制限され、主要資本が取引用 sub-account から分離されている場合に下がります。
取引システムの trade キーに必要な最小設定
- 取引システムは固定IPのVPSで稼働し、そのIPがキーの IP whitelist に追加されている。
- キーは read + trade の permissions を持ち、withdraw permission を持たない。
- 取引用 sub-account には運用残高を置き、主要資本は常設の取引キーなしで別に保管する。
- API Secret は secret manager または暗号化保管領域に保存し、リポジトリやログに入れない。
IP whitelist、最小 permissions、まれな出金のためのアドレス whitelist、sub-accounts による分離は、損害を運用残高に限定し、侵害されたキーによるブロックチェーン出金リスクを下げます。
❓ APIキーのセキュリティFAQ
API Secret が漏れても IP whitelist が保護になるのはなぜですか?
取引所はリクエスト送信元のIPをキーの IP whitelist と比較し、IPが一致しない場合はリクエストを拒否します。HMAC署名が正しくても、IP確認は取引所側で行われるため、操作は実行されません。
withdraw permission が本当に必要なのはいつですか?
Withdraw permission は、ブロックチェーンへの自動的な運用支払いに必要です。取引、監視、レポートには withdraw permission は不要です。これらのプロセスは取引所内部の取引エンドポイントと読み取りエンドポイントを使うためです。
trade-only キーが出金なしで損失につながるのはなぜですか?
Trade-only キーは注文を出せます。攻撃者が trade-only キーにアクセスすると、流動性の低いペアで不利な価格の取引を実行し、取引ウォレットに大きな残高がある場合、スリッページ、スプレッド、手数料による損失を作れます。
各取引システムに別の sub-account が必要なのはなぜですか?
Sub-account は、キーがアクセスできる残高を制限します。取引システムのキーが漏えいした場合、取引所は特定の sub-account の残高内で操作を実行するため、損害はその sub-account の資産に限定されます。
注文の制御を失わずにキーをローテーションするにはどうすればよいですか?
ローテーションには、新しいキーの作成、取引システムの新しい API Secret への切り替え、古いキーの取り消しが含まれます。キー変更で注文管理が途切れないよう、切り替えは未決済ポジションや有効な指値注文がない期間に計画します。
外部端末の接続リスクはどのように制限しますか?
リスクは、運用残高を持つ sub-account 上の trade-only キー、IP whitelist（リクエストがユーザー側エージェント経由で送られる場合）、端末が運用上の出金に関与しない場合の withdraw permission 無効化によって制限します。
🧷 API制限が出金リスクと取引損害を下げる仕組み
APIリスクは、許可された操作と、取引所が各リクエストに適用する確認に依存します。署名（API Secret）、permissions、IP whitelist、リクエスト時刻のパラメータです。
- withdraw permission を無効にすると、APIによるブロックチェーン出金がブロックされます。取引所が、この権限を持たないキーの出金エンドポイントを拒否するためです。
- 出金先アドレスの whitelist は受取人を制限します。取引所は事前に追加されたアドレスにだけ資金を送るためです。
- IP whitelist はリクエスト送信元を制限します。署名が正しくても、取引所はキーのリストにないIPからのリクエストを拒否するためです。
- Sub-accounts は損失規模を制限します。キーはアカウント内のすべての資産ではなく、特定の sub-account の残高にアクセスするためです。