search
LoginSignup
1
Help us understand the problem. What are the problem?

posted at

updated at

【v8】auカブコム証券のkabuステーションREST APIで自前のリピート注文を作ってみる(注文約定調査編)

はじめに

過去記事は「auカブコム証券のkabuステーションREST APIに関する記事一覧」。

さて、前回のトレイル注文ツールでは、既存の建玉の返済注文が可能になったのですが、今度は、夜中に決済されてしまったら、そこから翌日までノーポジで何もしないことになります。
そこで次はまた同じ注文、もしくはテクニカルのトリガーによる注文といった新規建玉のツールを作成します。
当初は、返済と同じ程度の工数で新規もできると思っていたら、意外と大変なことがあり、一度要件を整理してから作っていくことにします。

注文約定照会API

残高照会、注文発注、注文取消について、一通り使ってみたので、注文約定照会にもサンプルPGMで必要となりそうな項目をファイルに保存してみる。

出力されたMainOrders.txtの例(タブを改行に変換)。

orderId: 20220419A02N81583688
code: 167060019
name: 日経225mini 22/06
state: 1 ※逆指値は予約状態
price: 0  ※逆指値の価格は分からない
qty: 1
side: 2(L)
cashMargin: 3 ※返済
createDate: 1650349347398(2022/04/19 15:22:27.398)
updateDate: 1650349347398(2022/04/19 15:22:27.398)
executionIds:

orderId: 20220419A02N81915533
code: 167060019
name: 日経225mini 22/06
state: 3 ※注文中
price: 27160
qty: 2
side: 1(S)
cashMargin: 2 ※新規
createDate: 1650349347400(2022/04/19 15:22:27.400)
updateDate: 1650349347401(2022/04/19 15:22:27.401)
executionIds:

orderId: 20220419A02N81967017
code: 167060019
name: 日経225mini 22/06
state: 5 ※約定済
price: 26950
qty: 2
side: 1(S)
cashMargin: 2 ※新規
createDate: 1650371524259(2022/04/19 21:32:04.259)
updateDate: 1650371524260(2022/04/19 21:32:04.260)
executionIds: E2022041902X8F:26950x2 ※残高照会側の約定番号

面倒なことのメモ

  • 例えば、26000Lで注文して、26100で約定されないが、有利な25900で約定されることがある。最初、簡単に作ったとき、26000Lの注文や残高があるかチェックしたら、25900で約定する価格帯の場合、注文→約定→注文→約定のループになって、残高がすごいことになる。。。

  • 26000Lで注文して、後から、25500Lに変更したい場合に、まったく約定していない場合は、26000Lを取り消して、25500Lの発注すればよいが、すでに約定していた場合に、すぐに返済するわけにもいかない。

  • 2枚以上で注文した場合、1枚だけ約定して、1枚注文中で残っている場合があり、そのときに変更したい場合。

  • 踏まえると、ドキュメントの版管理(リビジョン管理)と同様に注文指示の履歴管理をするか、1回目注文、2回目注文と主キーに枝番をつけて、2回目の前提条件として1回目の完了状態を待ち合わせるようにすれば、1回目と2回目の価格、数量を変更できるかもしれない。

  • トリガー条件や手作業の注文と、注文PGMを切り離す。間に注文指示ファイルを保存し、トリガー監視PGMや人間が操作するテキストエディタやWebアプリが注文指示ファイルに書き込み、注文PGMが注文指示ファイルをポーリングする。

追記:state=2と4について

APIリファレンスには、state値は以下の説明となっている。

  • 1.待機(発注待機)
  • 2.処理中(発注送信中)
  • 3.処理済(発注済・訂正済)
  • 4.訂正取消送信中
  • 5.終了(発注エラー・取消済・全約定・失効・期限切れ)

state=1,3,5は普通に見かけるが、2と4について、いつ起きるのか調査したところ、通常は一瞬2になって、すぐに3に変わる。
一方、08:00から08:02ごろのプレオープニングが始まってすぐの時間では、おそらく証券会社は注文を受け付けるが、取引所が詰まっているときに10秒から20秒くらいはこのステータスのままとなる。

したがって、ザラ場の時間帯しか注文発注/取消しなければ、まず発生しないので、エラーデータとしてWARNレベル扱いでログに出力して、処理から除外する。

追記:ソースをarchiveブランチへ移動

最新版に移行し、もう使われることはないので、アーカイブする。

githubソース

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
1
Help us understand the problem. What are the problem?