デモ口座を使って窓埋め自動売買の試験運用やってみました！ たっきん(Twitter)です！
自作の自動売買システムですが、ようやく運用可能なレベルにまで作り上げることができました。
開発着手したのが今年の１月ですからここまで作り上げるのに約10ヵ月を要したことになります。
ブログを書きながら開発してきたのでやや時間がかかってしまいましたが、やり切ったときの達成感があるのはシステム開発の醍醐味ですよね！
シストレ・テーキテクチャ図は以下のようになりました。
＜シストレ・アーキテクチャ ver.1.0.0＞
現状シストレのアプリケーションとしてはまだ窓埋め(gap_fill)の1種類しかありませんが、今後は徐々にアプリケーションのラインナップを増やしていこうと考えてます。
窓埋めトレードの試験運用をやってみてわかったこと
僕が考えた窓埋め自動売買トレードは以下のようなアルゴリズムで実行されます。
- 月曜の朝5時くらいにOANDAのPricingStream APIを有効にし、PricingStreamノードがトピック上に発行する為替情報メッセージをGap-Fillアプリケーションが受け取れる状態にする。
- 月曜オープン時、一発目に取得した為替情報から窓の開き幅をチェックし、窓埋めトレード実施可否を判定する。
- 実施可で判定されたら成行注文を出す。
このアルゴリズムで為替情報の取得から成行注文の発行までの一連の動作が問題なく実行できるか、実際に月曜のオープン時間で何回かテストしてみました。
結論を先に言ってしまうと無事成行注文の発行＆約定までは実行できたのですが、実際に動かして判明した事実や懸念事項がいくつかありましたので１つずつ紹介していきたいと思います。
月曜オープン時のスプレッド
僕が窓埋め解析で作成したヒートマップですが、当然ながらスプレッドも考慮した理論価格を算出しています。
そしてその理論価格を算出するのに使用した為替（ローソク足）情報はOANDAのInstrumentsCandles APIから取得しています。
言うまでもありませんが、トレードはスプレッドによって損益値に影響を与えます。
ましてや、スプレッドが広がりやすい月曜のオープン時間はなおさらです。
そのため、スプレッドの影響を調査すべくInstrumentsCandles APIとPricingStream APIで取得したAskとBidの為替情報のスプレッド幅に差があるのか調べてみました。
※下記条件下での調査結果となります。
- 通貨ペア：USD/JPY
- 時間足：10分（InstrumentsCandles APIのみ）
＜OANDA API オープン時の価格比較表＞
| 日付 | API種別 （※） | Ask | Bid | Middle | スプレッド |
|---|---|---|---|---|---|
| 2020/9/14 | ① | 106.181 | 106.081 | 106.131 | 0.100 |
| 2020/9/14 | ② | 106.173 | 106.089 | 106.131 | 0.084 |
| 2020/9/21 | ① | 104.617 | 106.089 | 104.567 | 0.100 |
| 2020/9/21 | ② | 104.609 | 105.464 | 104.567 | 0.084 |
| 2020/9/28 | ① | 105.564 | 105.464 | 105.514 | 0.100 |
| 2020/9/28 | ② | 105.556 | 105.472 | 105.514 | 0.084 |
| 2020/10/5 | ① | 105.375 | 105.275 | 105.325 | 0.100 |
| 2020/10/5 | ② | 105.367 | 105.283 | 105.325 | 0.084 |
| 2020/10/12 | ① | 105.785 | 105.685 | 105.735 | 0.100 |
| 2020/10/12 | ② | 105.777 | 105.693 | 105.735 | 0.084 |
※API種別
①：InstrumentsCandles API
②：PricingStream API
表を見ていただければわかると思うのですが、5日分のデータは全て
- InstrumentsCandles APIのスプレッド幅：0.100円
- PricingStream APIのスプレッド幅：0.084円
という結果になりました。
今回は５日分のデータでしか検証しませんでしたが、基本的にスプレッド幅はPricingStreamのほうが小さいと言ってよいでしょう。
この結果は何を意味するかというと、InstrumentsCandlesベースで算出したヒートマップシミュレーション結果に基づいてトレードを行った場合、シミュレーション結果よりも良いパフォーマンスが得られるということです。
少なくとも逆の結果にならなくて本当に良かったと思います。
逆の結果になっていたらシミュレーション結果がそもそも信用できないデータになってしまいますからね。
成行注文の発行時のレスポンス
OANDA APIで成行注文を発行すると通常以下のようなレスポンスが返されます。
{
"orderCreateTransaction": {
"price": "1.20000",
"stopLossOnFill": {
"timeInForce": "GTC",
"price": "1.22000"
},
"timeInForce": "GTC",
"reason": "CLIENT_ORDER",
"id": "2304",
・
・
・
},
"lastTransactionID": "2304",
"relatedTransactionIDs": [
"2304"
]
}しかし、月曜オープン時の窓埋めトレードではレスポンスが返されない時がありました。
- 2020/9/14：成行注文レスポンスあり
- 2020/9/21：成行注文レスポンスなし
- 2020/9/28：成行注文レスポンスなし
ただ、成行注文は正常に約定されていたため、どうやらOANDAサーバー側でレスポンスのみが返されてないようでした。
レスポンス無しの場合は「504: Gateway time-out」という内容のhtmlが返されており、どうやらOANDAサーバー側でタイムアウトを起こしているようです。
OANDAサーバーへ成行注文を発行してからtime-outレスポンスが返されるまで10秒であったことから、どうやらタイムアウト時間は10秒に設定されているようです。
まぁ注文自体は正常に約定されていたため、いったんこの問題は保留としておきましょう。
しかし、レスポンスがタイムアウトを起こしているにも関わらず約定が成立していた場合、注文発行から約定が成立するまでに要した時間が気になりますよね。
あまりにも時間がかかりすぎているとスリッページを起こしていないか気になりますからね。
これについても検証してみたので次の項目で説明していきます。
月曜オープン価格と約定価格のスリッページ
成行注文を発行するタイミングは月曜のオープン価格取得直後のため、
- オープン価格 = 約定価格 （スリッページなし）
となるのが理想です。
これについても検証してみましたのでその結果を公開したいと思います。
※全て買いの成り行き注文で検証しました。
＜オープン価格・約定価格比較表＞
| 日付 | オープン価格(Ask) | 約定価格 |
|---|---|---|
| 2020/9/14 | 106.173 | 106.173 |
| 2020/9/21 | 104.609 | 104.609 |
| 2020/9/28 | 105.556 | 105.556 |
３日分の検証データしかありませんが、全て結果はスリッページなしという結果になりました。
さいごに
約１ヵ月ほどデモ口座でのOANDA APIによる窓埋め自動売買トレードの試験運用を実施しましたが、運用上問題になるようなことはありませんでしたので、いよいよ本口座で運用を開始していこうと思います。
ヒートマップによるシミュレーションの結果に近づけるにはとにかく試行回数を増やし、長期の運用が必要になると思います。
短期的な運用だと一時的に損益がマイナスになることも十分考えられますが、長期で運用することで最終的には損益はプラスになってくれるはずです。
運用成績ブログも逐次書いていきたいと思っているので長い目で見守っていただけたらなと思います。
また現状アプリケーションは窓埋めトレード１つしかないので、今後はアプリケーションのラインナップを増やすのを目標にしていきます。
自動売買トレードのウリは完全放置プレイできるところにあります。
窓埋めトレードを運用サーバーにやらせ、僕はせっせと次のアプリケーション開発に取り組んでいきます。
それではまた次の報告で！
コメント