Bitget APIとは、Bitgetの取引機能（発注・キャンセル・残高照会・価格取得など）を自分のプログラムから直接呼び出せる公式の接続インターフェースである。結論から言うと、Bitgetで自動売買botを動かすまでの道のりは「口座開設→APIキー発行→bot環境構築→テスト→本番稼働」の5ステップに整理でき、プログラミング経験が浅い人でも公式ライブラリを使えば週末2日ほどで最初のbotを稼働させられる。本記事では、実際にAPI接続でbotを運用している編集部が、APIキーの権限設定・IP制限・レート制限といったつまずきやすいポイントを含めて、2026年7月時点の仕様に基づいて手順を解説する。
Bitget API自動売買を始める前に押さえる前提
まず前提を3つ確認しておきたい。
1つ目は、Bitgetが海外取引所であることだ。Bitgetは2018年創業のグローバル取引所で、現物手数料0.1%（BGB払いで0.08%）、先物メイカー0.02%・テイカー0.06%、レバレッジ最大125倍、REST/WebSocket API対応、日本語UIありという構成で、API自動売買に必要な機能が一通りそろっている。一方で金融庁登録の暗号資産交換業者ではないため、日本の法規制や補償の枠組みの外にある。だからこそ、日本円の入出金や資産の避難先として国内取引所（金融庁登録業者）の口座を必ず持った上で、Bitgetは「自動売買の実行環境」として使い分けるのが基本姿勢になる。国内取引所の口座がまだない人は、送金手数料無料でAPI取引にも対応しているGMOコインのような国内口座を先に用意してから読み進めてほしい。
2つ目は、自動売買botは「作って終わり」ではないことだ。APIキーの管理、レート制限への対応、エラー時の再接続、想定外の約定への対処など、運用フェーズの作業が本体と言っていい。本記事は設定手順だけでなく、運用でつまずいた実例もあわせて紹介する。
3つ目は、資金管理だ。自動売買は人間の裁量を排除できる反面、ロジックの欠陥があると機械的に損失を積み上げる。最初は失っても生活に影響しない少額（数万円相当のUSDT）から始め、ロジックの挙動を確認しながら段階的に増やすのが定石だ。
この記事でできるようになること
- BitgetのAPIキーを安全な権限設定で発行できる
- IP制限とレート制限を理解し、botが止まらない設定を組める
- Pythonの公式系ライブラリでBitgetに接続し、残高照会と発注ができる
- テストから本番稼働までの移行判断ができる
全体像:Bitget API自動売買までの5ステップ
手順の全体像は次の通り。所要時間の目安も添える。
- Bitget口座の開設と2段階認証の設定（約15分）
- 資金の入金（国内取引所からの送金、約30分〜）
- APIキーの発行と権限・IP制限の設定（約10分）
- bot環境の構築と接続テスト（半日〜2日）
- 少額テスト運用→本番稼働（1〜2週間の検証を推奨）
ステップ1〜3はBitgetの画面操作だけで完了する。ステップ4以降がプログラミングの領域だが、公式が案内するPythonライブラリ（python-bitgetなど）を使えば、認証まわりのコードを自分で書く必要はほぼない。
手順1:Bitget口座を開設し2段階認証を設定する
APIキーは口座がなければ発行できない。まずは口座開設から始める。
- Bitget公式サイト（日本語表示対応）にアクセスし、メールアドレスとパスワードを登録する
- 届いた認証コードを入力してアカウントを有効化する
- セキュリティ設定からGoogle認証（Authenticatorアプリ）による2段階認証を必ず有効にする。APIキーの発行時にこの2段階認証が要求されるため、先に済ませておくと後の手順が止まらない
- 本人確認（KYC）を完了させる。出金や一部機能の利用に必要になるため、最初にやっておくのが効率的だ
口座開設そのものは10分程度で終わる。パスワードは他サービスと使い回さず、パスワードマネージャで生成した強固なものを設定してほしい。API自動売買では口座に常時資金を置くことになるため、アカウント自体のセキュリティがbotの安全性の土台になる。
入金について
国内取引所からの送金が基本ルートだ。国内取引所はUSDT建ての取り扱いがないことが多いため、「国内でXRPやBTCを買ってBitgetへ送金し、Bitget側でUSDTに交換する」流れになる。送金ネットワーク（XRPならXRP Ledger、ETHならERC20など）を送付側と受取側で必ず一致させること。ネットワークの不一致は資産喪失に直結する。入金手順の詳細は当サイトの入金手順記事で別途解説している。
手順2:APIキーを発行し権限とIP制限を設定する
ここが本記事の核心だ。APIキーの設定を誤ると、botが動かないだけでなく、資産流出のリスクにもつながる。
- Bitgetにログインし、アカウントメニューから「API管理」（API Keys）を開く
- 「新しいAPIキーを作成」を選ぶ。キー種別はシステム生成のHMAC方式を選択する
- メモ（ラベル）にbotの用途がわかる名前を付ける（例:grid-bot-01）。キーを複数運用する場合の識別に効く
- パスフレーズ（Passphrase）を設定する。これはAPIリクエストの署名に使う第3の秘密情報で、後から確認できないため必ず控える
- 権限を選択する。「読み取り（Read）」と「取引（Trade）」のみをオンにし、「出金（Withdraw）」は必ずオフにする
- IP制限（IPホワイトリスト）に、botを動かすサーバーの固定IPアドレスを登録する
- 2段階認証コードとメール認証を入力して作成を確定する
- 表示されたAPIキー（Access Key）とシークレットキー（Secret Key）を安全な場所に保管する。シークレットキーはこの画面でしか表示されない
権限設定の考え方:出金権限は絶対に付けないのか
原則として出金権限はオフにする。botに必要なのは「相場を読むこと（読み取り）」と「注文を出すこと（取引）」だけで、出金はbotの仕事ではない。仮にAPIキーが漏洩しても、出金権限がなければ攻撃者は資産を直接抜き取れない。これは最小権限の原則と呼ばれる考え方で、API運用の基本中の基本だ。
IP制限は「必須」と考える
IP制限を設定しないキーは、キー文字列さえ漏れれば世界中どこからでも使えてしまう。VPS（仮想専用サーバー）やクラウドの固定IPからbotを動かす構成にして、そのIPだけを許可するのが実務上の必須設定だ。自宅回線は変動IPのことが多く、IPが変わるたびにbotが認証エラーで止まるため、本番運用には固定IPのVPSを推奨する。編集部の運用でも、IP制限なしのキーは検証用の読み取り専用キーに限定している。
レート制限を先に知っておく
Bitget APIには呼び出し回数の上限がある。2026年7月時点の目安として、パブリックデータ系は毎秒20リクエスト、プライベート系（残高・注文など）は毎秒10リクエスト程度、さらにIP単位で毎分6,000回の全体上限がある。超過するとエラーが返り、回復まで待たされる。相場データの取得はWebSocket（サーバーからのプッシュ配信）を使えばREST制限を消費しないため、「価格監視はWebSocket、発注はREST」という役割分担が定石になる。WebSocketは1接続あたり最大1,000チャンネル購読・毎時240購読リクエストといった上限があるが、個人botで到達することはまずない。
手順3:Pythonでbot環境を構築し接続テストする
APIキーができたら、いよいよbotの構築だ。ここではPythonを例にする。
- VPSまたは手元のPCにPython 3.10以降をインストールする
- ライブラリをインストールする。Bitget向けにはpython-bitgetのような専用ライブラリ、または多取引所対応のccxtが使える。迷ったら情報量の多いccxtが無難だ
- APIキー・シークレット・パスフレーズを環境変数に設定する。ソースコードに直接書き込むのは漏洩事故のもとなので避ける
- 最初のテストとして「残高照会」を実行する。認証情報が正しければ口座残高がJSONで返ってくる
- 次に「最小ロットでの成行注文→即キャンセル/決済」を試し、発注権限が機能することを確認する
接続テストで返ってくるエラーの大半は、(1)パスフレーズの間違い、(2)IP制限に現在のIPが入っていない、(3)権限不足、の3パターンだ。エラーコードを見れば切り分けられるので、慌てずに1つずつ確認してほしい。
つまずきやすいエラーと対処の型
実際の構築でよく遭遇するエラーパターンを整理しておく。
- 署名エラー（signature invalid系）:シークレットキーまたはパスフレーズの誤り、あるいはリクエストのタイムスタンプずれが原因。サーバーの時刻同期（NTP）を有効にすると解決することが多い。VPSの時計が数十秒ずれているだけで全リクエストが弾かれる
- 権限エラー（permission denied系）:APIキー作成時に必要な権限（現物・先物それぞれの取引権限）を付けていないケース。現物用と先物用で権限のチェック欄が分かれている点を見落としやすい
- IP拒否:bot稼働サーバーのグローバルIPがホワイトリストと一致していない。クラウド環境ではインスタンス再作成でIPが変わることがあるため、固定IP（Elastic IP相当）の割り当てを忘れない
- レート制限超過:短時間にリクエストを出しすぎている。ループ内に適切な待機を入れる、価格取得をWebSocketへ移す、複数botでキーを分ける、のいずれかで解消する
- 最小注文数量未満:Bitgetは通貨ペアごとに最小注文数量・最小注文金額が決まっている。発注前にペアの取引ルールを取得して検証するコードを挟むと、この系統のエラーはゼロにできる
エラー処理で重要なのは「エラーを握りつぶさない」ことだ。発注リクエストがエラーになったのか、成功したのに応答だけ受け取れなかったのかで、その後の正しい振る舞いは真逆になる。応答が不明なときは必ず注文一覧を照会して実際の状態を確認してから次の処理へ進む設計にする。
WebSocketで価格を監視する実装の型
REST APIだけでbotを組むと、価格取得のポーリングでレート制限を圧迫しがちだ。実務では次の分担が定石になる。
- 起動時にWebSocketへ接続し、監視したい通貨ペアのティッカーや板情報のチャンネルを購読する
- 受信した価格をメモリ上の変数に常時反映し、売買判定はその変数を参照する
- 売買条件を満たしたときだけREST APIで発注する
- WebSocketは無通信が続くと切断されるため、定期的なping送信と、切断検知時の自動再接続を実装する
この構成なら、RESTの消費は発注と約定確認だけになり、レート制限とはほぼ無縁になる。WebSocketの購読上限（1接続あたり最大1,000チャンネル）にも個人運用で触れることはない。
botロジックはどう作るか
ロジック自体はこの記事の範囲を超えるが、初心者が最初に組むなら次の3類型が現実的だ。
- 定期積立型:毎日決まった時刻に一定額を買うだけ。ロジックが単純でバグりにくく、API操作の練習に最適
- グリッド型:一定の値幅ごとに買い注文と売り注文を並べる。レンジ相場で機能し、Bitgetにはbot取引機能としてテンプレートも用意されている
- シグナル型:移動平均のクロスなど条件を満たしたら発注する。ロジックの設計自由度が高いぶん、検証に時間がかかる
いきなり複雑な戦略を組むより、まず定期積立型で「発注→約定確認→記録」のループを安定して回せるようになることが、遠回りに見えて最短ルートだ。なお、近年はClaude CodeのようなAIコーディングエージェントにbotの雛形を書かせて、人間はロジックの検証とリスク管理に集中するという分業も現実的になっている。生成されたコードをそのまま本番投入するのではなく、テストネットや少額口座で必ず動作を確かめる前提であれば、開発期間を大幅に短縮できる。API接続部分のような定型コードほどAIに任せる価値が高く、逆に資金管理のパラメータ設定は人間が責任を持つ、という線引きが実務的だ。
手順4:少額テスト運用で挙動を検証する
コードが動いたら、すぐに本番資金を投入したくなるが、ここで1〜2週間のテスト期間を挟むかどうかが生存率を分ける。
- 口座には失っても許容できる少額（例:100〜300USDT相当）だけを置く
- 最小ロットで実際に売買させ、意図した価格・数量で約定しているかログと突き合わせる
- ネットワーク断・API側メンテナンス時にbotがどう振る舞うか（再接続するか、二重発注しないか)を確認する
- 損切りロジックが本当に発動するかを、あえて不利なポジションで検証する
- 1日の発注回数・APIコール数を集計し、レート制限に対する余裕を確認する
バックテストとフォワードテストは別物
過去データでの検証（バックテスト）で好成績でも、実口座の少額運用（フォワードテスト）で同じ成績が出るとは限らない。バックテストには約定遅延・スリッページ（狙った価格とのずれ）・手数料の過小評価が入り込みやすく、特に高頻度の戦略ほど実運用との乖離が大きくなる。過去検証は「明らかにダメな戦略を捨てるふるい」と割り切り、最終判断は必ず実口座の少額フォワードテストで行う。この2段階を省略しないことが、資金を守る一番確実な方法だ。検証期間中は相場環境（上昇・下落・レンジ）が最低1回は切り替わるまで観察できると、戦略の弱点が見えやすい。
編集部はClaude Codeによる自動売買を実口座で運用しており、検証結果は運用実績ページ（/ai-trading）で公開しているが、その運用でも「ガス代・手数料に対して建玉が小さすぎて利確しても手数料負けする」「損切りが浅すぎて相場ノイズで刈られる」といった問題は、すべてテスト運用段階ではなく本番で発覚した。テスト期間はこうした授業料を最小化するための保険だと考えてほしい。
手順5:本番稼働と監視体制づくり
テストを通過したら本番稼働に移る。ここでのポイントは「無人で放置」ではなく「無人で動くが、異常は即座に人間へ通知される」状態を作ることだ。
- VPS上でbotを常駐化する（プロセス管理ツールやOSのサービス機能を使い、クラッシュ時に自動再起動させる）
- 発注・約定・エラーをログファイルに記録し、日次で確認する習慣を作る
- 残高が想定レンジを外れたら通知が飛ぶ監視を入れる（メールやチャット通知）
- APIキーは90日ごとを目安にローテーション（再発行・差し替え）する
- 月に1回、取引履歴をエクスポートして損益を確認し、確定申告用の記録として保存する
二重発注を防ぐ設計
無人運用で最も怖い事故の1つが二重発注だ。ネットワーク不調で発注応答を受け取れず、botが「失敗した」と判断して再送した結果、同じ注文が2本通ってしまうケースがこれにあたる。対策は2段構えにする。第1に、発注時にクライアント側で一意の注文ID（clientOid）を付与する。同じIDの注文は取引所側で重複として扱われるため、再送しても二重にならない。第2に、発注ループの先頭で未約定注文の一覧を照会し、既に同種の注文が生きていればスキップする。この2つを入れておくだけで、通信起因の事故はほぼ防げる。
APIキーのローテーション手順
キーの定期交換は「新キー発行→botの環境変数を差し替え→動作確認→旧キー削除」の順で行う。先に旧キーを消すとbotが止まるので、必ず新旧が両方生きている状態を経由させる。交換のタイミングは90日ごとの定期実施に加え、開発メンバーの変更時・PCの紛失や故障時・不審なアクセス通知を受けたときは即時に行う。キーの発行履歴と交換日をメモしておくと、複数botを運用し始めたときに管理が破綻しない。
運用コストの目安と損益分岐の考え方
自動売買を続けるかどうかの判断には、コスト構造の把握が欠かせない。個人でBitget API botを動かす場合の月間コストの目安は次の通りだ。
- VPS代:月500〜2,000円程度（最小構成のクラウドVPSで十分動く）
- 取引手数料:取引回数×手数料率。先物テイカー0.06%で1回1,000USDTの取引なら1回あたり0.6USDT
- 送金コスト:国内取引所とBitget間の資金移動時のネットワーク手数料
見落としがちなのは手数料負けだ。たとえば1回の取引で狙う利幅が0.1%しかない高頻度戦略だと、テイカー手数料0.06%が往復で0.12%かかり、勝っても赤字になる。編集部の実運用でも、建玉サイズが小さすぎて手数料・コストに利益が食われる問題を経験し、建玉の下限額を設ける改善を行った。自分の戦略の「1回あたり期待利幅」と「往復コスト」を必ず先に計算し、期待利幅がコストの3倍以上ない戦略は本番投入しない、といった基準を持つことを勧める。
またメイカー注文（指値で板に置く注文）を使えば先物手数料は0.02%まで下がる。約定の確実性は落ちるが、高頻度の戦略ほどメイカー中心の設計にする価値が大きい。BGBによる手数料割引も現物では有効なので、現物botを動かすなら割引設定を確認しておきたい。
対抗手段との比較:API botは誰に向くか
自動で運用する手段はAPI botだけではない。代表的な選択肢と比較する。
| 項目 | Bitget API bot | Bitgetコピートレード | 国内取引所API（GMOコイン等） |
|---|---|---|---|
| 必要スキル | プログラミング必須 | 不要 | プログラミング必須 |
| 戦略の自由度 | 完全に自由 | トレーダー任せ | 自由（ただし現物中心） |
| コスト | 取引手数料のみ | 手数料+利益分配（最大10%程度） | 取引手数料のみ |
| レバレッジ | 最大125倍（先物） | トレーダーに依存 | 国内規制の範囲（暗号資産FXは2倍） |
| 日本の規制保護 | 対象外 | 対象外 | 金融庁登録の枠内 |
対コピートレード:自由度を取るか手軽さを取るか
コピートレードは他人の取引を自動で複製する仕組みで、プログラミングが不要な代わりに、戦略の中身はブラックボックスだ。Bitgetのコピートレードは利益が出た場合のみ最大10%程度をトレーダーに分配する成果報酬型で、始めるハードルは圧倒的に低い。一方、API botは戦略・リスク管理・執行をすべて自分で設計でき、改善のPDCAを自分で回せる。「学びながら資産運用の仕組みを作りたい人」はAPI bot、「まず自動運用を体験したい人」はコピートレードという住み分けになる。
対国内取引所API:規制の保護か機能の広さか
GMOコインなど国内取引所もAPIを提供しており、金融庁登録業者の枠内で自動売買ができる安心感は大きい。ただし現物と最大2倍の暗号資産FXが中心で、Bitgetのような高レバレッジ先物・多彩なアルトコインペア・bot向け機能の広さはない。実務的には「国内APIで練習し、物足りなくなったらBitgetへ広げる」「資金の保管は国内、執行はBitget」という併用が現実的だ。
対クラウドbotサービス:手軽さの対価は手数料と柔軟性
外部のクラウドbotサービス（取引所にAPI接続して既製戦略を動かすタイプ）は、画面操作だけでグリッドbotなどを動かせる。ただし月額料金や成果報酬がかかるものが多く、戦略のカスタマイズには限界がある。またAPIキーを第三者サービスに預けることになるため、預け先の信頼性という別のリスクが増える。Bitgetは取引所自身がbot取引機能を内蔵しているため、まず内蔵botを試し、それでも足りなければ自作API botへ進むと無駄がない。
リスクと注意点
Bitget APIでの自動売買には、少なくとも次のリスクがある。順に対策とセットで押さえてほしい。
- 金融庁未登録リスク:Bitgetは日本の金融庁に登録された暗号資産交換業者ではない。日本の利用者保護制度（分別管理の監督や補償枠組み）の対象外であり、トラブル時に日本の行政が介入する前提は成り立たない。生活資金を置かず、運用資金を限定することが第一の防衛策になる。
- 出金停止・サービス変更リスク:海外取引所は規制環境の変化により、特定国ユーザーへのサービス変更・出金制限が起こり得る。利益が出たら定期的に国内取引所へ資金を戻す運用ルールを作っておきたい。
- APIキー漏洩リスク:キーが漏れると第三者がbotと同じ操作をできてしまう。出金権限オフ・IP制限・環境変数管理・定期ローテーションの4点セットで守る。GitHubなどへコードを公開する際にキーを含めてしまう事故は毎年起きている。
- ロジック欠陥による損失リスク:バグや想定外の相場でbotが損失を積み上げることがある。1回の取引の最大損失を制限するストップロスと、日次の最大損失額に達したら停止するキルスイッチを必ず実装する。
- レート制限・システム障害リスク:API制限超過や取引所側メンテナンスでbotが動けない時間が発生する。ポジションを持ったまま操作不能になる事態を想定し、取引所アプリから手動決済できる準備をしておく。
- 税務リスク:Bitgetでの利益も日本居住者には課税対象で、原則として雑所得として確定申告が必要だ。年間の取引履歴を必ず保存し、損益計算ツールの利用や税理士など専門家への相談を勧める。
- 相場急変リスク:レバレッジ取引では急変時にロスカットが間に合わず、想定以上の損失が出ることがある。レバレッジは資金に対して控えめに設定し、証拠金維持率に余裕を持たせる。
稼働前チェックリスト
本番稼働の前に、次の項目を指差し確認してほしい。
- APIキーの出金権限がオフになっている
- IPホワイトリストにbotサーバーのIPだけが登録されている
- APIキー・シークレット・パスフレーズが環境変数で管理され、コードに直書きされていない
- ストップロスと日次キルスイッチが実装され、テストで発動確認済み
- 口座に置く資金が「失っても生活に影響しない額」に収まっている
- 取引履歴の保存と損益記録の仕組みがある
- 国内取引所の口座があり、出金ルートを確保している
まとめ:小さく動かし、守りを固めてから育てる
Bitget APIでの自動売買は、「口座開設→APIキー発行（読み取り+取引のみ・IP制限必須）→Python等で接続→少額テスト→監視付き本番」という5ステップで実現できる。技術的なハードルは公式系ライブラリの充実で年々下がっており、2026年7月時点では個人が週末に始められる現実的な選択肢になっている。ただし、Bitgetが金融庁未登録の海外取引所である以上、国内取引所口座との併用・資金の限定・出金権限オフという守りの設定が大前提だ。まずは読み取り専用キーでの残高照会から、小さく始めてみてほしい。
<!-- INTERNAL_LINKS_RELATED -->
関連記事
<!-- INTERNAL_LINKS_RELATED -->