Freqtradeとは、Pythonで書かれたオープンソースの暗号資産自動売買botフレームワークである。結論を先に書くと、FreqtradeとBitgetの接続で本当に必要な作業は「config.jsonのexchangeブロックにname・key・secret・passwordの4項目を書く」ことだけで、残りはDocker環境の用意とストラテジーの準備に尽きる。BitgetはFreqtradeの公式ドキュメントで正式サポート対象として明記されている取引所であり、有志が動作報告しているだけの非公式接続ではない。そのため現物取引と分離マージン(isolated)先物のどちらも素直に動く。
本記事は、Docker環境の構築からAPIキー発行、config.jsonの記述、バックテスト、ドライラン、本番稼働、監視までを、そのままコピーして使える設定ファイル例つきで通しで解説する。なお編集部は2026年4月からClaude Codeにトレード判断を任せる自動売買を実口座で継続検証しており、その運用で踏んだ設定上の落とし穴を本記事の手順に反映している(検証内容は当サイトの運用実績ページで公開している)。
Freqtrade×Bitgetで「できること」と「限界」
導入作業に入る前に、この組み合わせで何ができて何ができないかを表で確認しておく。ここを読まずに始めると、後半の設定で必ずつまずく。
| 項目 | できること | 限界・注意点 |
|---|---|---|
| 取引種別 | Bitgetの現物取引と分離マージン(isolated)先物 | クロスマージン先物は対象外。先物ではFreqtradeが起動時にポジションモードを片方向(One-way)モードへ自動設定するため、ヘッジモード前提の運用はできない |
| 注文の有効期限 | GTC・FOK・IOC・PO(ポストオンリー)の指定 | POは板に置けない場合キャンセルされるため、約定機会を落とす前提で設計する |
| 損切り | 取引所側に置くstoploss(stop-loss-marketとstop-loss-limitの両方) | 取引所側stoplossはbot停止中も生きる代わり、価格が飛ぶと想定より不利な価格で約定する |
| 認証情報 | APIキー・シークレット・パスフレーズの3点 | Bitgetはキーごとにパスフレーズが必須。config.jsonではpasswordというキー名に入れる(passphraseではない) |
| 動作環境 | Docker / Linux / macOS / Windows(WSL2推奨) | 24時間稼働させるならVPSかミニPC。ノートPCのスリープで停止する事故が非常に多い |
| バックテスト | 過去データでの戦略検証、パラメータ最適化(hyperopt) | 過去成績は将来の利益を保証しない。バックテストはドライランの代わりにならない |
| 資金管理 | 最大同時ポジション数・1回あたり建玉額・利確/損切り率をconfigで一元管理 | 設定ミスで想定の何倍もの建玉を持つ事故が起きうる。必ずドライランで検証する |
要するに、Freqtradeは「戦略のロジック」と「注文執行・資金管理・監視」を分離してくれるフレームワークである。売買ルールの発想そのものを代わりに考えてくれる道具ではない、という点だけは最初に理解しておきたい。
準備するもの(国内取引所を先に持つ理由)
Bitgetは日本の金融庁に暗号資産交換業者として登録されていない海外取引所である。日本居住者が使う場合の現実的な形は、まず国内の登録業者で口座を持ち、そこで日本円から暗号資産に換え、送金してBitgetで運用し、利益確定後は再び国内取引所に戻して日本円に換える、という往復の構造になる。国内取引所という「出口」を持たないまま海外取引所に資金を置くと、いざ日本円に戻したいときに手段がない状態になりやすい。この前提を飛ばさないでほしい。
送金時の実務ポイントも押さえておく。国内取引所はUSDTを扱っていないことが多いため、海外へはBTCやETHで送ってBitget側でUSDTに換える、あるいはUSDT/USDCを扱う国内業者を使う、という選択になる。送金ネットワーク(TRC20・ERC20・BEP20など)の選択を間違えると資産が失われる。送金先アドレスとネットワークは必ず取引所の入金画面の表示どおりに合わせ、初回は少額でテスト送金する。
技術面の準備は次の4点である。
- Docker と Docker Compose が動く環境(Windowsの場合はWSL2上のDocker Desktop)
- 24時間稼働させるサーバー(月数ドル〜十数ドルのVPSで十分。国内自宅のミニPCでも可)
- Bitgetの口座とAPIキー
- テキストエディタとターミナル操作の基礎知識
Pythonの読み書きは、既存のサンプル戦略を使うだけなら必須ではない。ただし自分の戦略を書くなら、pandasのデータフレーム操作に最低限慣れておく必要がある。
手順1: Docker環境にFreqtradeを用意する
Freqtradeの導入方法はソースからのインストールとDockerの2通りがあるが、環境依存のトラブルを避けたいならDockerを選ぶ。公式のdocker-compose.ymlを取得して初期化する流れは次のとおりで、ここは丸ごとコピーして使ってよい。
まず作業ディレクトリを作り、そこにdocker-compose.ymlを置く。公式リポジトリのstableブランチにあるものと同等の内容は次のとおりで、これをそのままファイルに保存すればよい。
services:
freqtrade:
image: freqtradeorg/freqtrade:stable
restart: unless-stopped
container_name: freqtrade
volumes:
- "./user_data:/freqtrade/user_data"
ports:
- "127.0.0.1:8080:8080"
command: >
trade
--logfile /freqtrade/user_data/logs/freqtrade.log
--db-url sqlite:////freqtrade/user_data/tradesv3.sqlite
--config /freqtrade/user_data/config.json
--strategy SampleStrategy
保存したら初期化を行う。以下をターミナルにそのまま貼り付ける。
mkdir -p ft_userdata && cd ft_userdata/
# ここに上記の docker-compose.yml を保存しておく
docker compose pull
docker compose run --rm freqtrade create-userdir --userdir user_data
docker compose run --rm freqtrade new-config --config user_data/config.json
使われるイメージはfreqtradeorg/freqtrade:stableである。最後のnew-configは対話形式で、取引所名・ステーク通貨・1回あたりの建玉額などを聞かれる。ここで取引所を聞かれたらbitgetを選んでおくと、後の編集が楽になる。
生成されるディレクトリ構成は次のようになる。この構造を把握しておくと、後でファイルの置き場所に迷わない。
ft_userdata/
├── docker-compose.yml
└── user_data/
├── config.json # 取引所・資金管理の設定
├── strategies/ # 自作ストラテジーの置き場
├── data/ # ダウンロードした過去データ
├── logs/ # 稼働ログ
└── tradesv3.sqlite # 取引履歴のデータベース
手順2: Bitgetの口座を開設してAPIキーを発行する
口座を持っていない場合はここで作る。本人確認(KYC)には身分証と顔写真の撮影が必要で、混雑状況によっては反映まで数時間かかることがある。ここで詰まると先に進めないため、Dockerの準備と並行して申し込んでおくと時間を無駄にしない。
口座ができたらAPI管理画面でキーを発行する。自動売買用のキーは次の方針で作る。
- 権限は「読み取り」と「取引」のみを付与する。出金権限は絶対に付けない。キーが漏れても資産を抜かれない構成にしておくことが最大の防御になる
- IP制限を有効にし、botを動かすサーバーのグローバルIPアドレスのみを許可する。VPSなら固定IPが割り当てられているのでここは必ず設定する
- パスフレーズ(passphrase)を自分で決めて控える。Bitgetのキーはこれがないと認証が通らず、後から確認する手段もない
- シークレットキーは発行直後の1回しか表示されない。パスワードマネージャに保存してからブラウザを閉じる
キーは平文でGitリポジトリに置かないこと。バックテスト用の設定と本番用の設定はファイルを分け、本番用は.gitignoreに入れる運用が安全である。
手順3: config.jsonにBitget接続情報を書く
ここが本記事の核心である。Bitget接続で他の取引所と決定的に違うのは、passwordにパスフレーズを入れる必要がある点だ。公式ドキュメントも「Bitgetはapiキーごとにパスフレーズを要求するため、この項目を設定に追加する必要がある」と明記している。ここを空にしたまま起動して認証エラーに悩む人が非常に多い。
現物取引用の最小構成は次のとおり。そのままuser_data/config.jsonに貼り付けて、キー類だけ差し替えれば動く。
{
"max_open_trades": 3,
"stake_currency": "USDT",
"stake_amount": 50,
"tradable_balance_ratio": 0.99,
"dry_run": true,
"dry_run_wallet": 1000,
"timeframe": "5m",
"minimal_roi": {
"0": 0.035
},
"stoploss": -0.045,
"trailing_stop": true,
"trailing_stop_positive": 0.01,
"trailing_stop_positive_offset": 0.02,
"trailing_only_offset_is_reached": true,
"unfilledtimeout": {
"entry": 10,
"exit": 10,
"unit": "minutes"
},
"entry_pricing": {
"price_side": "same",
"use_order_book": true,
"order_book_top": 1
},
"exit_pricing": {
"price_side": "same",
"use_order_book": true,
"order_book_top": 1
},
"exchange": {
"name": "bitget",
"key": "あなたのAPIキー",
"secret": "あなたのシークレット",
"password": "あなたのパスフレーズ",
"ccxt_config": {},
"ccxt_async_config": {},
"pair_whitelist": [
"BTC/USDT",
"ETH/USDT",
"SOL/USDT"
],
"pair_blacklist": []
},
"pairlists": [
{
"method": "StaticPairList"
}
],
"strategy": "SampleStrategy",
"db_url": "sqlite:////freqtrade/user_data/tradesv3.sqlite",
"initial_state": "running"
}
利確+3.5%・損切り-4.5%・トレーリング併用という数値は、編集部が実口座の検証運用で使っている設定値をそのまま持ってきたものである。万能の正解値ではないが、「早すぎる損切りはノイズで刈られる」という実運用の教訓から、損切り幅を利確幅よりやや広く取り、伸びたときはトレーリングで利を伸ばす思想になっている。自分のバックテスト結果に合わせて調整してほしい。
先物(分離マージン)で動かす場合は、上記に次のブロックを足す。ペア表記がBTC/USDT:USDTという永続契約形式になる点に注意する。
{
"trading_mode": "futures",
"margin_mode": "isolated",
"exchange": {
"name": "bitget",
"pair_whitelist": [
"BTC/USDT:USDT",
"ETH/USDT:USDT"
]
}
}
手順4: 過去データを取得してバックテストする
接続設定ができたら、いきなり資金を入れずに過去データで検証する。データのダウンロードとバックテストのコマンドは次のとおり。
# 過去データのダウンロード(例: 直近1年分の5分足)
docker compose run --rm freqtrade download-data \
--config user_data/config.json \
--timerange 20250701-20260701 -t 5m 1h
# バックテスト実行
docker compose run --rm freqtrade backtesting \
--config user_data/config.json \
--strategy SampleStrategy \
--timerange 20250701-20260701 -i 5m \
--timeframe-detail 1m
--timeframe-detailを付けている理由は重要である。バックテストはローソク足の4本値しか見ないため、1本の足の中で高値と安値のどちらが先に来たかを知らない。利確と損切りが同じ足に同居した場合の判定が現実とずれる。より細かい足を同時に読み込ませることで、この曖昧さをかなり減らせる。公式ドキュメントも、詳細足を使うと結果が大きく変わりうると明記している。
さらに、戦略が未来のデータを覗いていないか(ルックアヘッドバイアス)を自動検査するコマンドが用意されている。自作戦略を書いたら必ず通す。
docker compose run --rm freqtrade lookahead-analysis \
--config user_data/config.json \
-s MyStrategy -i 5m \
--minimum-trade-amount 10 --targeted-trade-amount 50
手順5: ドライラン(模擬売買)で1〜2週間回す
バックテストが通っても、それは過去データ上の話でしかない。"dry_run": trueのまま実際の相場に接続して、注文が想定どおり出るか、APIのレート制限に引っかからないか、深夜に落ちないかを確認する。
docker compose up -d
docker compose logs -f
ここで見るべきは損益ではなく「壊れないこと」である。具体的には、①エラーで停止していないか ②注文が意図した価格帯に出ているか ③想定より取引回数が極端に多くないか ④サーバー再起動後に自動復帰するか、の4点。最低でも1週間、できれば相場が荒れた日を含む2週間は回したい。
やってはいけないこと・実際にあった失敗例
ここは記事の中で最も実用的な部分かもしれない。自動売買の事故は、戦略の良し悪しではなく運用の雑さから起きる。
1. 出金権限つきAPIキーを使う。 これが最悪の事故につながる。キーが漏れた瞬間に資産が消える。読み取りと取引だけで自動売買は成立する。
2. ドライランを飛ばして本番投入する。 config.jsonのdry_runをfalseにした直後は、最小額から始める。編集部の検証運用では、建玉が小さすぎて手数料とガス代を回収できず利確条件に届かない、という逆方向の失敗も起きた。小さすぎても大きすぎてもいけない、というのが実感である。
3. ノートPCで動かしてスリープさせる。 ポジションを持ったままbotが止まると、損切りが機能しない。取引所側stoplossを併用するか、VPSで動かす。
4. hyperoptで数字を磨きすぎる。 パラメータ最適化を繰り返すと、過去データにだけ都合のよい設定に収束する。最適化した期間と別の期間で検証して初めて意味を持つ。
5. 通貨ペアを増やしすぎる。 max_open_tradesを上げてペアを20も30も入れると、資金が薄く分散し、同時に全ポジションが逆行したときのドローダウンが読めなくなる。最初は3ペア・同時3ポジションで十分である。
6. 送金ネットワークを確認せずに入金する。 ERC20のアドレスにTRC20で送るなど、ネットワーク不一致は資産喪失に直結する。初回は必ず少額テスト。
7. ログを見ない。 稼働開始後にログを一度も読まない運用は、静かに壊れたbotを放置することになる。1日1回でよいので目を通す。
他の選択肢と比べてどうか
Freqtradeが常に最適とは限らない。代表的な代替と正直に比較する。
| 選択肢 | 初期コスト | 自由度 | 必要スキル | 向いている人 |
|---|---|---|---|---|
| Freqtrade + Bitget | サーバー代のみ(月数ドル〜) | 高い(Pythonで何でも書ける) | Docker・Python基礎 | 自分のルールを検証しながら育てたい人 |
| 取引所ネイティブbot(グリッド・DCA) | 無料 | 低い(用意された型のみ) | ほぼ不要 | まず自動売買の感触を掴みたい人 |
| Hummingbot | サーバー代のみ | 中〜高(マーケットメイク特化) | Docker・板取引の知識 | スプレッド収益を狙いたい人 |
| コピートレード | 無料(利益分配あり) | なし | 不要 | 自分では組みたくない人 |
対 取引所ネイティブbot
Bitgetにはグリッドやスマート積立などのbot機能が用意されており、ブラウザ上で数クリックで動く。手軽さでは圧倒的に有利だ。一方で「どういう条件でエントリーするか」を自由に定義できず、バックテストも限定的である。既製の型で満足できるならネイティブbotのほうが合理的で、型を超えたいときにFreqtradeへ移る、という順序が現実的だと思う。
対 Hummingbot
Hummingbotはマーケットメイク(板に買い注文と売り注文を同時に置いてスプレッドを取る)に特化したフレームワークである。Freqtradeが「方向性を当てにいく」道具なのに対し、Hummingbotは「方向性を当てずに回転で稼ぐ」道具で、思想がそもそも違う。トレンド系・オシレータ系の戦略を書きたいならFreqtrade、板に張り付く戦略ならHummingbotという住み分けになる。
対 自作Pythonスクリプト
CCXTを直接叩いて自分で全部書く選択肢もある。学習効果は最も高いが、注文管理・再起動時の状態復元・レート制限対応・データベース・通知といった「戦略以外の8割」を自分で作ることになる。Freqtradeを使う最大の価値は、この8割が既に検証済みで用意されている点にある。
かかるコストの実額
自動売買は無料ではない。目に見えにくいコストを具体的に出しておく。
- 取引手数料: Bitgetの現物は0.1%(BGB払いで0.08%)、先物はメイカー0.02%・テイカー0.06%。5分足で1日10往復すると、先物テイカーでも往復0.12%×10回で1日1.2%相当のコストが発生する。高頻度戦略ほど手数料が損益を支配する
- サーバー代: VPSで月5〜15ドル程度。メモリ2GBあればFreqtrade単体は動く
- 送金手数料: 国内取引所からの送金手数料と、Bitgetからの出金手数料。銘柄とネットワークで数百円〜数千円相当
- スリッページ: バックテストには現れないが、板が薄い銘柄では実際の約定価格が想定から乖離する。これは実質的なコストである
- 時間: 最も見落とされるコスト。バックテスト、ドライラン、ログ確認に相応の時間がかかる
つまり損益分岐点は「戦略の期待値 > 手数料 + スリッページ + 固定費」であり、期待値の薄い戦略を高頻度で回すと、確実にコスト負けする。
リスクと注意点
海外取引所とbotを組み合わせる以上、以下は必ず理解した上で始めてほしい。
- 無登録業者リスク: Bitgetは金融庁登録の暗号資産交換業者ではない。日本の法規制や国内業者向けの補償制度の対象外であり、トラブル時に国内の枠組みで救済されることは期待できない
- 出金・サービス変更リスク: 海外取引所は方針変更やメンテナンスにより、出金の制限や特定地域向けサービスの停止が起こりうる。実際にBybitは日本居住者向けサービスを終了し、2026年3月23日にクローズオンリー、7月22日正午に未決済ポジションの強制決済という措置が取られた。資金を長期間置きっぱなしにしない運用が安全である
- 税務: 暗号資産の利益は日本では原則として雑所得として課税対象になる。botで取引回数が増えるほど計算は煩雑になるため、取引履歴のCSVを定期的に保存しておく。申告方法の判断は税理士など専門家に相談してほしい
- APIキー漏洩リスク: 出金権限なし・IP制限ありでも、取引権限があれば板の薄い銘柄で不利な売買を強制されうる。キーは定期的に再発行する
- システム障害リスク: 取引所側のAPI障害、VPSの停止、ネットワーク断のいずれでもbotは止まる。ポジションを持ったまま止まる前提で、取引所側stoplossを併用する
- 戦略の陳腐化リスク: 過去データで機能した戦略が将来も機能する保証はない。相場のレジームが変わればロジックの前提も崩れる
- レバレッジリスク: 先物では最大125倍まで設定できるが、倍率を上げるほど清算価格が現在値に近づく。少しの逆行で強制決済される
- 元本毀損リスク: 自動売買は損失を自動化する可能性も等しく持っている。失っても生活に影響しない金額から始める
稼働前チェックリスト
本番稼働の直前に、この項目を上から順に確認してほしい。
- APIキーの権限が「読み取り+取引」のみで、出金権限が付いていないことを画面で確認した
- APIキーにIP制限をかけ、bot稼働サーバーのIPのみを許可した
dry_run: trueのまま最低1週間ドライランを回し、エラー停止がないことを確認した- バックテストを実施し、
lookahead-analysisで未来データの参照がないことを確認した max_open_tradesとstake_amountの掛け算が、口座残高に対して過大でないことを計算した- 国内取引所の口座を開設済みで、出金経路が確保されている
- 少額のテスト送金を行い、入出金が問題なく通ることを確認した
- サーバー再起動時にbotが自動復帰する設定(
restart: unless-stopped)になっている - 取引履歴を保存する運用を決め、確定申告の準備を想定している
まとめ
FreqtradeとBitgetの接続そのものは、config.jsonのexchangeブロックにname・key・secret・passwordを書くだけで完了する。難所は接続ではなく、その前後にある。前は「国内取引所を出口として確保し、権限を絞ったAPIキーを用意すること」、後ろは「バックテストとドライランで壊れないことを確かめ、コストを上回る期待値があるかを見極めること」である。
そして最も重要なのは、自動売買は利益を自動化する道具であると同時に、損失も自動化する道具だという認識だ。編集部自身、実口座での検証運用では建玉サイズの設計ミスや早すぎる損切り設定でつまずき、その都度ロジックを組み替えてきた。最初から完成形を目指さず、小さく回して壊れた場所を直していく進め方を勧めたい。
<!-- INTERNAL_LINKS_RELATED -->
関連記事
<!-- INTERNAL_LINKS_RELATED -->
