Hummingbotとは、板に買い注文と売り注文を同時に置いてスプレッド（買値と売値の差）を収益にする「マーケットメイク」を自動化するための、オープンソースの取引botフレームワークである。結論から言えば、日本語の情報が少ないだけで導入自体は難しくない。取引所の接続はconnect bitgetという1行で終わり、戦略の中身はテキスト設定ファイルの数値を編集するだけで動き始める。
ただし、この道具の本質は「価格が上がるか下がるかを当てない」点にある。方向性を予想する代わりに、板の両側に注文を置いて往復の値幅を積み上げる。だからこそ利益の出方も、失敗の仕方も、順張り・逆張り系のbotとはまったく異なる。本記事では、その仕組みの理解からDocker導入、Bitget接続、設定値の意味、紙取引での検証、そして在庫リスクという最大の落とし穴までを、コピーして使える設定例つきで解説する。
なお編集部は2026年4月からClaude Codeにトレード判断を任せる自動売買を実口座で継続検証しており、その経験から「設定値そのものより、稼働後に何を監視するか」が成否を分けるという実感を持っている（検証内容は当サイトの運用実績ページで公開している）。
Hummingbotで「できること」と「限界」
導入前に、現実的な期待値を表で確認しておく。ここを誤解したまま始めると、想定と違う挙動に必ず戸惑う。
| 項目 | できること | 限界・注意点 |
|---|---|---|
| 収益の源泉 | 買値と売値のスプレッド、および取引所のメイカー手数料優遇 | 相場が一方向に動くと、片側だけ約定して不利な在庫を抱える（在庫リスク） |
| 対応取引所 | Bitgetを含む主要中央集権取引所（現物・永続先物）とDEX | 取引所ごとに接続仕様が異なり、対応銘柄も同一ではない |
| Bitget接続 | bitget（現物）とbitget_perpetual（永続先物）の2コネクタ |
APIキー・シークレット・パスフレーズの3点が必須 |
| 戦略の作り方 | V2フレームワーク（スクリプト・コントローラー・エグゼキューター）／V1レガシー戦略 | 新機能の開発はV2中心。V1も動くが今から学ぶならV2寄りが無難 |
| プログラミング | 既存戦略を設定ファイルの数値編集だけで動かせる | 独自ロジックを書くならPythonの知識が必要 |
| 検証環境 | 紙取引（ペーパートレード）モードを標準搭載 | 紙取引では自分の注文が板に与える影響を再現できない |
| 日本語対応 | 公式CLIは英語。設定項目は少数で意味を覚えれば支障は小さい | 日本語の解説記事・コミュニティが薄く、トラブル時は英語で調べる前提 |
一言でまとめると、Hummingbotは「相場観がなくても回せる」道具ではない。相場観の代わりに、板の状態と在庫の偏りを管理する別種の判断力を要求する道具である。
マーケットメイクの仕組みを先に理解する
具体的な例で考える。BTC/USDTの現在値が10万ドルだとして、Hummingbotに「両側に0.2%の幅で注文を置け」と指示すると、botは99,800ドルに買い注文、100,200ドルに売り注文を同時に出す。両方が約定すれば、1往復で400ドル分の値幅、率にして0.4%から手数料を引いた分が手元に残る。これを1日に何十回も繰り返すのがマーケットメイクである。
問題は「両方が約定するとは限らない」ことだ。価格が下落し続ける局面では、買い注文だけが次々に約定して売り注文が残る。結果として、下がり続ける資産をどんどん買い増していく状態になる。これがマーケットメイク最大のリスクである在庫リスク、あるいは逆選択リスクと呼ばれるものだ。
つまりHummingbotの運用とは、「小さな利益をコツコツ積む」ことと「片側に偏った在庫を抱えて大きく含み損を出す」ことの綱引きになる。設定項目の大半は、この綱引きをどう管理するかのパラメータだと理解すると、意味がすっと入ってくる。
準備するもの（国内取引所を先に持つ理由）
Bitgetは日本の金融庁に暗号資産交換業者として登録されていない海外取引所である。日本居住者が使う現実的な形は、まず国内の登録業者で口座を持ち、日本円から暗号資産に換え、送金してBitgetで運用し、利益確定後は国内取引所へ戻して日本円に換える、という往復の構造になる。国内取引所という出口を持たないまま海外に資金を置くと、日本円に戻す手段がない状態になりやすい。ここは省略しないでほしい。
送金の実務も押さえておく。国内取引所はUSDTを扱っていない場合が多いため、海外へはBTCやETHで送ってBitget側でUSDTに換えるのが定石である。送金ネットワーク（TRC20・ERC20・BEP20など）の選択を誤ると資産が失われるため、入金画面の表示どおりに合わせ、初回は必ず少額でテスト送金する。
技術面では次を用意する。
- Dockerが動く環境（WindowsならWSL2上のDocker Desktop）
- 24時間稼働させるサーバー。マーケットメイクは注文の出し直しが頻繁なので、取引所に近いリージョンのVPSだと有利
- Bitgetの口座とAPIキー
- ターミナル操作の基礎知識
手順1: Dockerで動かす環境を用意する
HummingbotはDockerイメージでの起動が最も安定する。作業ディレクトリを作り、次のcompose定義をdocker-compose.ymlとして保存する。そのままコピーして使ってよい。
services:
hummingbot:
image: hummingbot/hummingbot:latest
container_name: hummingbot
restart: unless-stopped
volumes:
- ./conf:/home/hummingbot/conf
- ./logs:/home/hummingbot/logs
- ./data:/home/hummingbot/data
- ./scripts:/home/hummingbot/scripts
tty: true
stdin_open: true
network_mode: host
起動と接続は次のコマンドで行う。
mkdir -p hummingbot_files && cd hummingbot_files
mkdir -p conf logs data scripts
docker compose up -d
docker attach hummingbot
docker attachでCLI画面に入る。抜けるときはコンテナを止めずにデタッチする必要があるため、Ctrl+P に続けて Ctrl+Q を押す。ここを普通にCtrl+Cで抜けるとbotごと止まるので注意したい。
初回起動時にはパスワードの設定を求められる。このパスワードはAPIキーを暗号化して保存するために使われ、忘れると設定をやり直すことになる。必ず控えておく。
手順2: Bitgetの口座を開設してAPIキーを発行する
口座がなければここで作る。本人確認（KYC）には身分証と顔写真の撮影が必要で、反映まで時間がかかる場合があるため、Docker環境の準備と並行して申し込んでおくと待ち時間を無駄にしない。
APIキーは次の方針で発行する。
- 権限は「読み取り」と「取引」のみ。出金権限は付けない。キーが漏れても資産を直接抜かれない構成にしておくことが最大の防御になる
- IP制限を有効にし、bot稼働サーバーのグローバルIPのみを許可する
- パスフレーズ（passphrase）を自分で決めて控える。Bitgetのコネクタはこれがないと認証できない
- シークレットキーは発行直後の1回しか表示されない。閉じる前にパスワードマネージャへ保存する
手順3: HummingbotにBitgetを接続する
CLI画面で次を入力する。現物ならbitget、永続先物ならbitget_perpetualである。
>>> connect bitget
Enter your Bitget API key >>> ****************
Enter your Bitget secret key >>> ****************
Enter your Bitget passphrase >>> ****************
Bitgetコネクタが3点目としてパスフレーズを要求するのが特徴で、ここで詰まる人が多い。取引所のAPI管理画面で自分が設定した文字列をそのまま入れる。接続状況はbalanceコマンドで残高が表示されれば成功と判断できる。
なおBitgetはHummingbotのFoundation Partnerであり、このコネクタ経由の取引手数料の一部がHummingbotのオープンソース開発の支援に回る仕組みになっている。利用者が追加で負担する費用ではないが、仕組みとして知っておくとよい。
手順4: マーケットメイク戦略の設定を作る
Hummingbotには2つの戦略フレームワークがある。2019年から続くV1のレガシー戦略群と、エグゼキューター・スクリプト・コントローラーの3要素で構成される新しいV2フレームワークである。V1も引き続き動作するが、新機能の開発はV2に集約されているため、これから学ぶならV2の考え方を前提にしたほうが長持ちする。
とはいえ最初の1本は、素直なマーケットメイク設定から始めるのが分かりやすい。主要な設定項目と、その意味・初期値の考え方を整理する。
取引所 : bitget
通貨ペア : BTC-USDT
買い側スプレッド : 0.20 (現在値から何%下に買い注文を置くか)
売り側スプレッド : 0.20 (現在値から何%上に売り注文を置くか)
1注文あたり数量 : 0.001 (1回の注文サイズ。板の厚みに対して小さく)
注文更新間隔 : 60 (秒。この間隔で注文を出し直す)
約定後の待機時間 : 30 (秒。約定直後の連投を防ぐ)
在庫目標比率 : 50 (%。基軸通貨と対象通貨の保有比率の目標)
在庫スキュー : 有効 (在庫が偏ったら注文サイズを自動で傾ける)
価格上限/下限 : 未設定 (この価格を超えたら片側を止める設定)
この中で意味を必ず理解しておくべきなのが下の3つである。
スプレッド幅: 狭くすると約定は増えるが1回あたりの利幅が薄くなり、手数料負けしやすい。広くすると利幅は取れるが約定機会が減る。手数料の往復分（Bitget現物なら往復0.2%、BGB払いで0.16%）を明確に上回る幅から始めるのが安全である。
注文更新間隔: 短くすると価格追従は良くなるが、注文の出し直し回数が増えてAPIのレート制限に近づく。60秒前後から始めて調整する。
在庫スキュー: これが在庫リスクへの主な防衛線になる。対象通貨を持ちすぎたら売り注文を大きく買い注文を小さく、逆なら反対に傾ける機能で、これを無効にしたまま下落相場で回すと在庫が一方的に積み上がる。有効にしておくことを強く勧める。
設定ファイルはconf/配下にYAML形式で保存される。手で編集する場合の雛形は次のとおりで、値を自分の条件に合わせて書き換えればそのまま読み込ませられる。
strategy: pure_market_making
exchange: bitget
market: BTC-USDT
bid_spread: 0.20
ask_spread: 0.20
order_amount: 0.001
order_refresh_time: 60.0
order_refresh_tolerance_pct: 0.02
filled_order_delay: 30.0
max_order_age: 1800.0
inventory_skew_enabled: true
inventory_target_base_pct: 50.0
inventory_range_multiplier: 1.0
order_levels: 1
hanging_orders_enabled: false
minimum_spread: 0.05
order_refresh_tolerance_pctは「価格が少ししか動いていないときは注文を出し直さない」ための遊びの幅で、これを0にすると毎回全注文をキャンセルして再発注するためAPIのレート制限に近づく。max_order_ageは約定しない注文を強制的に入れ替えるまでの秒数、minimum_spreadは板の状況に関わらずこれ以下の幅では注文しないという安全弁である。手数料負けを避けるため、minimum_spreadは必ず往復手数料以上に設定しておきたい。
手順5: 紙取引モードで検証してから本番へ
設定ができたら、いきなり資金を動かさずに紙取引（ペーパートレード）で回す。CLIで次を実行する。
>>> config paper_trade_enabled True
>>> start
>>> status
>>> history
statusで現在の注文と在庫状況、historyで約定履歴と損益が確認できる。ここで見るべきは損益額そのものではなく、次の4点である。
- 注文が意図した価格帯に、意図した頻度で出ているか
- 約定が片側に偏っていないか（偏るなら在庫スキューやスプレッドを見直す）
- エラーで停止していないか、レート制限の警告が出ていないか
- 相場が荒れた日にどれだけ在庫が偏ったか
最低1週間、できれば値動きの大きい日を含む2週間は紙取引で回したい。ただし紙取引には「自分の注文が板に影響を与えない」「実際には約定しなかったはずの注文が約定扱いになる」という限界がある。良い結果が出ても、本番は最小サイズから始めるべきである。
つまずきやすい箇所と対処
日本語の情報が少ないぶん、初回導入では同じ場所で止まる人が多い。頻出のものを挙げておく。
認証が通らない: 十中八九パスフレーズの入力ミスである。Bitgetのキーは読み取り・取引・パスフレーズの組み合わせで検証されるため、1文字違うだけで弾かれる。API管理画面でキーを作り直し、パスフレーズをコピーして貼り付け直すのが早い。
残高は見えるのに注文が出ない: APIキーに取引権限が付いていないか、IP制限に稼働サーバーのIPが登録されていないケースが大半である。VPSを移設したときにIP制限の更新を忘れる事故も多い。
注文がすぐキャンセルされる: 注文サイズが取引所の最小注文数量や最小注文金額を下回っている可能性がある。Bitget側の銘柄ごとの最小単位を確認し、order_amountを引き上げる。
レート制限の警告が出る: order_refresh_timeが短すぎるか、order_refresh_tolerance_pctが0になっている。前者を伸ばし、後者に0.02程度の遊びを与えると大きく改善する。
コンテナから抜けたらbotが止まった: docker attachをCtrl+Cで抜けた場合に起きる。Ctrl+P → Ctrl+Q でデタッチし直す。
やってはいけないこと・失敗しやすいパターン
Hummingbotの事故は、戦略の優劣ではなく設定と監視の甘さから起きる。特に多いものを挙げる。
1. スプレッドを手数料以下に設定する。 往復0.2%の手数料がかかる場所で両側0.05%のスプレッドを置けば、約定するたびに損失が確定する。「約定回数が多い＝儲かっている」ではない点は最も誤解されやすい。
2. 在庫スキューを無効のまま下落相場で回す。 買い注文だけが延々と約定し、値下がりする資産を買い集める。マーケットメイクで大きく損失を出す典型パターンがこれである。
3. 流動性の薄い銘柄を選ぶ。 板が薄い銘柄はスプレッドが広く一見有利に見えるが、価格が飛びやすく在庫が一方向に偏りやすい。最初は出来高の大きい主要銘柄に限定する。
4. docker attachからCtrl+Cで抜ける。 botごと停止し、板に注文を残したまま監視が止まる。デタッチはCtrl+P → Ctrl+Q。
5. 紙取引の成績をそのまま信じる。 自分の注文が板に与える影響も、約定しなかったはずの注文も再現されない。紙取引は「設定が壊れていないこと」の確認であり、収益性の証明ではない。
6. パスワードを控えずに初回設定を進める。 APIキーの暗号化に使われるため、忘れると設定のやり直しになる。
7. 稼働後にログを見ない。 マーケットメイクは静かに在庫が偏っていく。1日1回はstatusで在庫比率を確認する習慣を作る。
他の選択肢と比べてどうか
Hummingbotが常に最適とは限らない。代表的な代替と正直に比較する。
| 選択肢 | 収益の狙い方 | 必要スキル | 相場が一方向に動いたとき |
|---|---|---|---|
| Hummingbot | スプレッドの回転 | Docker・板取引の理解 | 在庫が偏り含み損を抱えやすい |
| Freqtrade | 方向性を当てる | Docker・Python基礎 | 損切りが機能すれば限定的 |
| 取引所グリッドbot | レンジ内の値幅 | ほぼ不要 | レンジを抜けると含み損 |
| コピートレード | 他人の判断に乗る | 不要 | 相手の腕次第 |
対 Freqtrade
Freqtradeはインジケーターで方向性を判断してエントリーする、いわゆる裁量トレードの自動化に向いたフレームワークである。Hummingbotが「方向を当てずに回転で稼ぐ」のに対し、Freqtradeは「方向を当てにいく」。したがって得意な相場が正反対で、Hummingbotはレンジ相場、Freqtradeはトレンド相場と相性がよい。どちらが優れているかではなく、狙う相場が違う道具だと考えるべきである。
対 取引所のグリッドbot
Bitgetにもグリッドbot機能があり、ブラウザ上で数クリック設定できる。一定間隔で買いと売りを置く点はマーケットメイクと似ているが、グリッドは「あらかじめ決めた価格帯に固定の注文網を張る」方式で、Hummingbotのように現在値へ追従して注文を出し直す設計ではない。手軽さではグリッドが勝り、価格追従や在庫管理の細かさではHummingbotが勝る。まずグリッドで感触を掴んでからHummingbotに進むのは、遠回りではなく合理的な順序だと思う。
対 コピートレードや自作スクリプト
自分では組みたくないならコピートレードという選択肢もあるが、成績が良いトレーダーを選んだつもりでも過去の成績は将来の利益を保証しない。逆にCCXTを直接叩いて自作する道もあり、学習効果は最大だが、注文管理・在庫計算・再起動時の状態復元・レート制限対応といった「戦略以外の大部分」を全部自分で作ることになる。Hummingbotを使う価値は、この土台が検証済みで用意されている点にある。
かかるコストの実額
マーケットメイクは薄い利幅を積む戦略なので、コストの把握が特に重要になる。
- 取引手数料: Bitgetの現物は0.1%（BGB払いで0.08%）、先物はメイカー0.02%・テイカー0.06%。マーケットメイクは指値を板に置くためメイカー側になりやすく、先物のメイカー0.02%は現物より有利である
- サーバー代: VPSで月5〜15ドル程度。注文更新が頻繁なため、回線品質のよいリージョンを選ぶ
- 送金手数料: 国内取引所からの送金とBitgetからの出金で、銘柄とネットワーク次第で数百円〜数千円相当
- スリッページと逆選択コスト: 数字に出にくいが実質的に最大のコスト。価格が動く直前に約定させられる分が、じわじわ効く
- 時間: 設定調整と在庫監視に相応の時間がかかる
損益分岐点は「スプレッド収益 − 手数料 − 在庫の含み損」であり、3項目目が読みにくいのがこの戦略の難しさである。
リスクと注意点
海外取引所とbotを組み合わせる以上、以下は必ず理解した上で始めてほしい。
- 在庫リスク: 一方向の相場では片側だけ約定し、不利な在庫が積み上がる。マーケットメイク固有かつ最大のリスクである
- 無登録業者リスク: Bitgetは金融庁登録の暗号資産交換業者ではない。日本の法規制や国内業者向けの補償制度の対象外であり、トラブル時に国内の枠組みで救済されることは期待できない
- 出金・サービス変更リスク: 海外取引所は方針変更により出金制限や特定地域向けサービスの停止が起こりうる。実際にBybitは日本居住者向けサービスを終了し、2026年3月23日にクローズオンリー、7月22日正午に未決済ポジションの強制決済という措置が取られた。資金を置きっぱなしにしない運用が安全である
- 税務: 日本では暗号資産の利益は原則として雑所得として課税対象になる。マーケットメイクは取引回数が極端に多くなるため損益計算が煩雑になりやすい。取引履歴を定期的に保存し、申告方法は税理士など専門家に相談してほしい
- APIキー漏洩リスク: 出金権限を外していても、取引権限があれば板の薄い銘柄で不利な売買を強制されうる。キーは定期的に再発行する
- システム障害リスク: 取引所APIの障害やVPS停止で、板に注文を残したままbotが止まる可能性がある。停止時の想定を決めておく
- レート制限リスク: 注文更新間隔を短くしすぎると制限に抵触し、注文の出し直しが失敗する
- 元本毀損リスク: 自動売買は損失も自動化する。失っても生活に影響しない金額から始める
稼働前チェックリスト
本番開始の直前に、上から順に確認してほしい。
- APIキーの権限が「読み取り+取引」のみで、出金権限が付いていないことを画面で確認した
- APIキーにIP制限をかけ、bot稼働サーバーのIPのみを許可した
- スプレッド設定が往復の取引手数料を明確に上回っていることを計算した
- 在庫スキューを有効にし、在庫目標比率を設定した
- 紙取引モードで1週間以上回し、片側偏りとエラー停止がないことを確認した
- 国内取引所の口座を開設済みで、日本円への出口が確保されている
- 少額のテスト送金で入出金が通ることを確認した
- 初回設定時のパスワードを控えた
- 1日1回
statusで在庫比率を確認する運用ルールを決めた
まとめ
Hummingbotは、日本語の情報が薄いだけで導入のハードルそのものは高くない。Dockerで起動し、connect bitgetでAPIキー・シークレット・パスフレーズの3点を入れ、スプレッドと注文サイズを設定すれば、その日のうちに紙取引まで到達できる。
難しいのは導入の後である。マーケットメイクは方向を当てない代わりに在庫の偏りという別のリスクを引き受ける戦略で、設定値を眺めているだけでは成否が分からない。スプレッドが手数料を上回っているか、在庫が片側に寄っていないか、この2点を毎日確認できるかどうかが実質的な分かれ目になる。
編集部自身、実口座での自動売買検証では、建玉サイズの設計や損切り条件を何度も組み替えてきた。最初から完成形を目指さず、紙取引と最小サイズで小さく回し、壊れた場所を一つずつ直していく進め方を勧めたい。取引所の口座開設やAPIキー設定の細かな手順、他のbotフレームワークとの使い分けについては、当サイトの手順記事でも個別に解説している。
<!-- INTERNAL_LINKS_RELATED -->
関連記事
<!-- INTERNAL_LINKS_RELATED -->