- Python製の自作ビットコインFX自動売買botツールで儲ける。実際に使ってみて仮想通貨取引所APIのメリットデメリットを比較してみた。
- 最初に結論。今からBTCFX自動売買botを作るなら「bitFlyer」か「FTXJapan」がオススメ。
- 【サービス終了】Zaif ビットコインAirFX：APIはPythonならラッパーもあり使い方は簡単だが、糞取引仕様＋糞サーバ＋糞EPSに泣くことになる。
- bitFlyer Lightning FX：APIも便利で使いやすく、サーバ強度も良い。Pythonライブラリもあるので、最初に自動売買に着手すべき取引所。
- FTXJapan：APIからの注文の柔軟性とセキュリティは最高。しかし、ドキュメントが日本語未対応。
- bybit：APIはクセあるがサーバ強度も良い。海外取引所なので要注意。
Python製の自作ビットコインFX自動売買botツールで儲ける。実際に使ってみて仮想通貨取引所APIのメリットデメリットを比較してみた。
仮想通貨取引所の多くは標準でAPIを公開しているところも多く、APIを活用することで簡単にビットコインの自作自動売買プログラムが作れるというのが仮想通貨投資(投機)の利点の１つです。
PythonなどでAPIをいじくり回せば、トラリピやループイフダンによる簡単な自動売買から、複雑なパターンインデックス・データ統計を用いた自動売買まで、自分の好きなトレードルールで好きなように自動売買を始めることができます。
感情任せのトレードで大損することも避けられますし、何より会社に行ったり他の事をしていても、ロボットが24時間365日全自動システムトレードでジャンジャン稼いでくれるのは有難いです＾＾。
ところが・・・。
仮想通貨取引所APIを実践レベルで使って検証しているようなサイト・ブログが検索してもなかなか見つけることができず、少ないネット情報を元に、独力で色々試さないと作れなかったりするのが現状です。結構、取引所毎にクセがあって苦戦するんですよねｗ。
実際にガチで作って、定常的に自動売買で運用している人は少ないのかもしれません。
というわけで、本記事では、私が実際にガチでビットコイン自動売買ツールをPythonで作って、実際に運用していて困った点などをふまえて、各社仮想通貨取引所APIを徹底比較したいと思います。
なお、システムトレード共通の注意事項（資金・リスク管理、フェールセーフ、取引所リスク等）はまた別途記事にしようと思います。今回は仮想通貨取引所APIの細かい特徴などの比較になります。
あと、Pythonで作る前提で書くので、他のプログラム言語の場合は知りませんよｗ。
最初に結論。今からBTCFX自動売買botを作るなら「bitFlyer」か「FTXJapan」がオススメ。
最初に結論だけ書いてしまいます（詳細・細かい話は後述を読んでくださいね）。本記事は年に何回か見直して最新情報にリライトしていますけど、今、自動売買プログラムを書くならば「FTXJapan
」「bitFlyer」が一番なのではないかと私は思ってます。
| 1位：bitFlyer | 人が多く混雑時は注文の遅延があるが、プログラムを作りやすいAPIが用意されている。取引履歴のダウンロードに若干難点があることが判明。 |
|---|---|
| 2位：FTXJapan | やや上級者向けだが一番botを作りこめる取引所。人が少ないためかbitFlyerに比べて遅延などが軽微。取引履歴も参照可能。手数料も改善したし、現状一番使えると思う。⇒FTXJapanにリニューアルされてからまだ未検証。ただワールド版に準じているようなので悪くないと思われる |
| 3位：bybit | 海外取引所なので注意が必要（後述）。bot動かす上で取引所自体は最高に良い。ただし、API仕様にややクセがあり上級者向け。 |
| 4位：Zaif | とにかく使いにくい上にサーバがヒドイ。その上、仮想通貨の不正流出事件まで起こしてしまうとは・・・。AirFXはサービス終了になりました。 |
本記事はあくまでビットコインFX自動売買をする前提での評価です。ビットコインFXや自動売買とかでなくて、普通に仮想通貨投資したい人はコチラの記事を参考にしてください。
「自動売買したいけど、検証用の過去データがないよ・・・」って人はコチラ。
「自動売買したいけど、Pythonとかプログラム書けないよ・・・」って人は、TechAcademyのPythonコース
やUdemyホームページを活用しましょう。
余談ですが、もうプログラミングに対する苦手意識とか払拭して、ちゃんと勉強した方がいいです。システムトレードやビットコインに限った話ではなく、これからは自動化・人工知能の時代なので、出来るのと出来ないのじゃ、見える世界が全然違ってきますよ。
【サービス終了】Zaif ビットコインAirFX：APIはPythonならラッパーもあり使い方は簡単だが、糞取引仕様＋糞サーバ＋糞EPSに泣くことになる。
| 取引所 |  引用元：Zaif https://zaif.jp/ |
|---|---|
| 総合評価 | 取引所比較の記事の方では、以前は高評価とさせていただいたZaifですが、「ビットコインFX」「自動売買」に限るならZaifは最低評価とせざるを得ないです。普通に仮想通貨投資するだけなら、まあ使える取引所ですが・・・。しかも、仮想通貨の流出事件まで起こしてしまったし、Zaif事業譲渡とかもありましたし、基本的に人が離れている取引所なので、コインチェックと同様しばらく様子見がいいのではないかと・・・。 |
| レバレッジ | 最大2倍 |
| APIドキュメント | 日本語 |
| Pythonライブラリ | あり(zaifapi) |
| IPホワイトリスト | あり |
| ハッシュアルゴリズム | HMAC-SHA512 |
| メッセージ | 文字列 |
| サーバ強度 | 最弱うんちサーバ。仮想通貨取引所はどこも相場がヒートアップしてくると重くなってくるが、Zaifはその中でも最低レベルです。 |
| 注文方式 | Zaif特有の注文方式。成り行き注文ができず、約定後にAPIから決済する方法も不明。 |
| 取引履歴CSV | 一応、確定申告用に取引履歴CSVを出力できる機能はあるようだが動いてない？。まあ「get_positions」でAPIから取れるようなので、最悪作るからいいっす。 |
| その他、実装上の注意点 | EPS（Early Profit Settlement)により、勝手に自動決済・ロスカットされるので、その場合のリバランスが必要（しかし、サーバエラーにより、できないことが多い）。各トレードにて、スワップ手数料を収支期待値に加味する必要あり。 |
Zaifのサーバは弱すぎて繋がらない！エラーや取引失敗はプログラムでカバーできるが、それでも限界はある
Zaifのサーバは国内取引所の中でも最弱レベルでしょう。ウェブ画面からアクセスしようが、APIからアクセスしようが、相場がヒートアップしていると全く繋がらないです。15分くらいずっと全くつながらないこともあります。
APIのエラーは「ZaifServerException / return status code is 502」の場合と「ZaifApiError / trade temporarily unavailable.」の場合があります。
前者の場合は、ウェブ画面アクセス時に出る「502 Bad Gateway」と同じでしょう。一方、後者のケースはおそらく負荷軽減のためZaif側が意図的にブロックして繋がらないようにしているのではないかと思われます。
トレードが失敗したときのリカバリー・リバランスを自動売買プログラムに組み込むのは当然ですが、それは繋がらなくて良いというわけではないですので、サーバ強度の点においてZaifはかなりマイナスです。
Zaifは独特の注文方式。指値のみ親注文でSTOPとLIMITが属性として付いている。どうすれば・・？
Zaifの注文方式は独特です。指値のみ注文可能で、STOPとLIMITが属性値としてくっついています。成り行き注文はできません。
しかも、APIからの注文時、「①指値のみが刺さって、STOP/LIMIT待ちになっている（ポジションあり）」「②指値も刺さってない（ポジションなし）」の区別が簡単に出来ません（「active_positions」でこの２つが区別なく両方取れてくるので、中を見ないと判別できない）。
また、STOPとLIMITの値も制約が多く、ティッカー現在値より100円以上離れていたり、STOPのロスカット値が現在値に近すぎたり遠すぎたりすると、すぐにエラーになります。
さらに、「①指値のみが刺さって、STOP/LIMIT待ちになっている（ポジションあり）」の場合、キャンセルもできないので、APIからどのように決済すればいいのかわかりません。
仕方ないので、↓のように「change_position」でSTOP/LIMITの幅をティッカー現在値を中軸に狭めることで対応しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # ポジションのクローズ defclose_exec(api,base_price): # 注文の取得と注文変更(limitとstopの幅を狭めて対応) positions=api.active_positions(type='futures',group_id=1) forrowinpositions: key=row data=positions[key] if(data['action']=='bid'): val_sonkiri=int(round(base_price-1000,-1)) val_rikaku=int(round(base_price+1000,-1)) if(data['action']=='ask'): val_sonkiri=int(round(base_price+1000,-1)) val_rikaku=int(round(base_price-1000,-1)) orderid=api.change_position(type='futures',group_id=1,leverage_id=int(key),price=int(data['price']),limit=val_rikaku,stop=val_sonkiri) |
カッコ悪っ！本当にこんな方法しかないのかな・・・。
なんで、こんなシステム設計にしてしまったのだろう・・。
通常IFDOCO注文の場合、STOPとLIMITは子注文の概念になります。Zaifの場合、親注文の1属性としてSTOP/LIMITがくっついてるので、こんな理不尽な状況になってしまいます。
たぶん、「IFDOCOとか投資初心者には、わかりにくいよね。だから、利確とストップロスを親注文にくっつけちゃえ」って設計なんだと思いますが・・。システム設計が正解がどうかは利用者が満足しているかどうかなので、一概に何が正しいとは言いませんけど、本当にこの仕組みでみんな満足して使ってるのかな？
EPS（追証が不要になる仕組み）の強制決済により、システムトレードが邪魔される。再注文したらエラーになるからリカバリーできない…
ZaifはEPSという追証が不要になる仕組みがあります。利用者が安心して使える仕組みと謳っていますが、実際はZaifが利用者から損金を回収する手間を省きたいがために実装された仕組みでしょう。
これは証拠金不足に陥りそうなポジションがある場合に、他の人の相対するポジションと同時に強制利益確定・ロスカットすることで、追証が発生する前に解消しちゃうというものです。
簡単に言っちゃと、「全力フルレバショート」とか「ストップロス無しフルレバ寝ロング」とか平気でやっちゃうようなリスク管理のできない3流トレーダーを、勝ってるトレーダーが懐を痛めて救うという、全く理不尽・意味不明な仕組みです。
通常、完全自動売買の場合、注文の発注・決済だけでなく資金管理・リスク管理もプログラムにより全自動で行うため、トラブル時以外はシステムトレードでは原理的に追証は発生しません（というか、資金ショートが発生しないトレードロジック・システム設計になっていなければ設計不備・不具合です）。そのため、ビットコイン自動売買ではEPSは何のメリットもありません。
なお、「EPSで自動決済されたとしても、建玉がなくなったことを自動検知して自動再注文すればいい」と思うかもしれませんが、EPSが発動するのは相場が大きく動いているケースが多く、前述したサーバ強度の問題から、自動再注文が通らずエラーになるケースが多いです（実際に、私はEPS→再注文→502エラー失敗を何度も経験しています）。
bitFlyer Lightning FX：APIも便利で使いやすく、サーバ強度も良い。Pythonライブラリもあるので、最初に自動売買に着手すべき取引所。
| 取引所 |  引用元：bitFlyer https://bitflyer.jp/ |
|---|---|
| 総合評価 | API自動売買に限るならbitFlyerは一番取り組みやすいです。他の変な取引所のAPIで幻滅して、「ビットコインFXなんて、もう嫌だ…」ってなっちゃう前に、初心者は最初にbitFlyerで自動化を目指しましょうｗ。唯一の弱点はIPホワイトリストが無い点。APIの権限セキュリティには最大級注意。 |
| レバレッジ | 最大2倍 |
| APIドキュメント | 日本語 |
| Pythonライブラリ | あり(pybitflyer) |
| IPホワイトリスト | なし |
| ハッシュアルゴリズム | HMAC-SHA256 |
| メッセージ | 文字列 |
| サーバ強度 | 画面からの注文はさておき、APIからの注文は混雑時でなければほとんど通ります。また、サーバ状態を取得できるので、それを見つつ注文を出せばほぼ100％注文に成功します。混雑時はAPIからの注文でも弾かれたり遅延したりしますので、注意しましょう。 |
| 注文方式 | 通常の指値注文・成り行き注文はもちろん、IFDOCO注文もAPIから一発でできます。また、一発で注文全キャンセルのAPIもあります。唯一の弱点は基本的にネットアウトになる点です。両建てが必要なトレードロジックの場合は対応できません。 |
| 取引履歴CSV | 取引履歴CSVはbitFlyer Lightningの画面から簡単にダウンロードできます。と、思ったんですけど、仮想通貨送金していると出力できない模様（後述）。何この意味不明な仕様・・・。 |
| その他、実装上の注意点 | Lightning FX SFDを収支期待値に加味する必要あり。 |
bitFlyer Lightningのサーバは画面からはちょっと重いが、APIなら普通に使える。サーバ状態を見てトレードすれば、なお良し。
「bitFlyer Lightningは重い」「注文が遅れる」という話もありますが、API経由なら普通に使うことができます。さらにAPIの「gethealth」でサーバ状態を簡単に取得できるので、以下のようにサーバ状態を見ながら注文を出すようにプログラムを組めば、ほぼ100％注文を通すことができます。
1 2 3 4 5 6 7 8 9 10 | healthwait=0 health=api.gethealth(product_code="FX_BTC_JPY") while((health['status']=='STOP')or(health['status']=='VERY BUSY'))and(healthwait<20): time.sleep(10) healthwait=healthwait+1 health=api.gethealth(product_code="FX_BTC_JPY") if((health['status']=='STOP')or(health['status']=='VERY BUSY')): print('失敗') else: orderid=nariyuki_sell(api,size_vol) |
「gethealth」でステータスに「STOP」が返ってくると注文が通りません。「VERY BUSY」だと失敗の確率が上がります。
なので、10秒ごとにチェックして「STOP」「VERY BUSY」以外になったタイミングで注文を入れるようにしています。あまりにも「STOP」状態が長い場合は一旦中断にしてますが、何回か繰り返せばほぼ100％注文が通りますね。
画面でデイトレしている人たちはストレスもありそうですけど、API自動売買ならかなり確度の高い発注ができます（失敗時のリバランスが不要というわけではないので、注意！）。
便利なAPIが揃っているのがbitFlyerのAPIのメリット。超簡単に複雑な処理が組み込めます。
bitFlyerのAPIなら、IFDOCO注文も一発で発注できます。もちろん、Zaifみたいにクソ仕様ではないので、子注文の部分だけキャンセルすることもできます。便利！
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | # IFDOCO買い注文 defifdoco_buy(api,size,rikaku,songiri): buy=api.sendparentorder (order_method="IFDOCO", minute_to_expire=10000, time_in_force="GTC", parameters=[ {"product_code":"FX_BTC_JPY", "condition_type":"MARKET", "side":"BUY", "size":size}, {"product_code":"FX_BTC_JPY", "condition_type":"LIMIT", "side":"SELL", "price":rikaku, "size":size}, {"product_code":"FX_BTC_JPY", "condition_type":"STOP", "side":"SELL", "trigger_price":songiri, "size":size} ]) |
注文のキャンセルも便利なAPIが用意してあります。「cancel = api.cancelallchildorders(product_code=”FX_BTC_JPY”)」で、発注している全ての注文を一括キャンセルできます。便利！
ちなみに、他の取引所の場合、このような一括キャンセル機能はないので、以下のように注文IDを取りながら1件づつキャンセルする必要があります。
1 2 3 4 5 | defcancelorder(self): result_check=self.get_api_call('/orders').json() forrowinresult_check['models']: result=self.put_api_call('/orders/'+str(row['id'])+'/cancel').json() returnresult |
ただし、bitFlyerはネットアウトになるので両建ては出来ません。私はトレードロジック上、両建てをしないので特に問題ないですが、両建てしたい人はbitFlyerは使えないですね。
年間取引報告書がダウンロードできない！取引履歴は分割してダウンロードする必要がある。
bitFlyerは年次損益報告書ダウンロードコーナーがありますが、仮想通貨送付を行っているとダウンロードできないというヒドイ仕様のようです・・・。
bitFlyer Lightningの取引履歴画面からダウンロードできますので、これを使うしかないです。確定申告や税務調査の際にはコチラを利用しましょう。
注意点は65536行までしか出力できない点です。高頻度系やMMbotの利用者で売買回数が多い場合は、日付範囲を指定して分割出力するしかありません。超メンドクサイです。他に方法はないの？
FTXJapan：APIからの注文の柔軟性とセキュリティは最高。しかし、ドキュメントが日本語未対応。
| 取引所 |  |
|---|---|
| 総合評価 | ⇒（注意）以下、旧Liquid版（旧QUOINEX版）のレビューです。FTXJapan版は検証中。終わったら更新するので待ってね。 シンプルなAPI設計で柔軟な発注・建玉管理で自動売買に向いている取引所。価格が飛び値する点と、WEBサイトで表示されるチャートデータとAPIデータで乖離があったりする点と、APIドキュメントが日本語未対応なのが弱点。それを苦にしないなら普通に使えます。現状、国内取引所だと他に選択肢がない。海外取引所は不安だしねぇ・・・。 |
| レバレッジ | 最大2倍 |
| APIドキュメント | 英語 |
| Pythonライブラリ | あり(pyliquid) |
| IPホワイトリスト | あり |
| ハッシュアルゴリズム | HMAC-SHA256 |
| メッセージ | JSON Web Token |
| サーバ強度 | 注文の失敗はほとんどありません。自動売買で安定して使える取引所だと思います（他社に比べて利用者が少ないだけかもですがｗ）。ただし、間髪いれずに連続注文を入れると失敗するので、数秒ウェイトしてから後続の注文を入れること。 |
| 注文方式 | 建て玉タイプは「両建てなし」「両建てあり」「ネットアウト」から選択できます。注文タイプも「limit」「market」「market_with_range」から選択できます。なので、自分でプログラムで制御する必要はありますが、組み合わせで何でもできる柔軟性が最大の利点です。一方でネットアウトでゴミロットが残る問題はある。 |
| 取引履歴CSV | 以前は取引履歴CSVのダウンロード機能はないようでした。しかしリニューアルしてからは簡単にダウンロードできるようになった模様。 |
| その他、実装上の注意点 | ポジション料を収支期待値に加味する必要あり。重要事項確認通知が出ていると、APIからの注文に失敗するのが辛い。 |
最もシンプルなAPI構成。便利機能はないが、自分で作れば何でできるのがFTX JapanのAPIの利点。
建て玉タイプは「両建てなし」「両建てあり」「ネットアウト」、注文タイプは「limit」「market」「market_with_range」から選択できますので、自分でプログラムで制御すれば色々とできます。
本格的なトレードルールによる売買をする人向け。
建て玉タイプの並列保持も可能です。例えば「両建てなし」の売りポジと「ネットアウト」の売りポジを持っているときに、「ネットアウト」の買いポジを入れると「ネットアウト」のポジションのみを相殺できます。つまり、複数の建て玉タイプを独立・並列してポジションすることも可能です。
一方でネットアウトで売買する際にゴミロットが残ったりする不具合(？)があるのが難点(ネットアウトにならずLとSが同量だけ残ってしまう)。基本的に放っておけば解消されるので、レバに対して余裕のある資金余力で対応すればＯＫ。
jwt(JSON Web Token)を利用する必要があるが、pip installするライブラリに注意。
既存のPythonラッパーを使わない場合、自分で作りこむ必要がありますが、注意すべきところはjwtで送る必要があるというところです。
ここで、「pip install JWT」でインストールすると、実行時にエラーになってハマるので、「pip install PyJWT」の方をインストールするようにしてください。
ちなみに、「get_api_call」だけですけど、「put_api_call」「post_api_call」も必要ですし、必要な注文はクラスで一式作っておくと良いと思います。
重要事項確認通知に注意。放置すると、APIから一切注文を受け付けなくなる？？
突然、API注文が一切受け付けなくなり、何度やってもダメになったんですよ。
で、手動でログインしてみたら、規約の変更があったとかで、重要事項確認通知のメッセージがログイン後に出たんです。その確認作業を済ませたところ、API注文が通るようになりました。
重要事項確認を放置しているとAPIが使えなくなります。規約変更などはメールで事前通知されることが多いですので、しっかりチェックして変更があったらすぐに手動ログインする必要があります。これが最大の難点でしょうね・・・。
以前は問答無用で突然ＡＰＩが使えなくなったのですが、現在は予告メールが届くので、それまでに規約確認を行えばbotが止まることはなくなっています。
取引履歴のダウンロードが超簡単に。
個人的に一番評価したいのは、取引履歴がPDFファイルで簡単にダウンロードできるようになったことです。「電子帳票閲覧」の専用ページから、日次・月次・年次と分けて出力もできます。確定申告・税務調査も安心です。
bybit：APIはクセあるがサーバ強度も良い。海外取引所なので要注意。
| 取引所 | ※私はつかってますが、海外取引所なのでブログではオススメしてないです。サラっとだけ書いておきますので、ご利用は自己責任で。 |
|---|---|
| 総合評価 | APIにクセがあるので、作るときに苦労するかもしれない。特にrecv_windowの扱いに罠。サーバ強度はなかなか良いので自動売買プログラムを作った後はかなり快適に動く。 |
| レバレッジ | 最大100倍 |
| APIドキュメント | 英語 |
| Pythonライブラリ | あり(pybybit) |
| IPホワイトリスト | あり |
| ハッシュアルゴリズム | HMAC-SHA256 |
| メッセージ | 文字列 |
| サーバ強度 | 高頻度はやってないのでわからないけど、普通の売買botなら何の問題もなく動く。快適度が半端ない。 |
| 注文方式 | 通常の指値注文・成り行き注文などは普通にできるので特に困ることはありません。stop_loss、time_in_force、trigger_byなどで細かく制御できる。ただし、recv_windowの取扱いがややこしい⇒「Please make sure that the timestamp parameter adheres to the following rule: server_time – recv_window <= timestamp < server_time + 1000; server_time stands for Bybit server time, which can be queried via the Server Time endpoint.」。詳しくはコチラの方が解説してくれている。 |
海外取引所のリスク・危険性は以下参照。
以上！
他には現在、FTX JAPAN版、GMOコイン、BITNEXTなどのAPIを検証中。ブログ記事にするまでには時間かかると思うけど、また更新しますね。
bot関連記事
他にも仮想通貨botや自動売買の記事書いてます～。
