（楽天証券の口座で取引する前提で）デイトレ自動売買を実現するには、Windows / Excel 上で マーケットスピード II RSS を利用することがまずは確実な方法だと考えました。そこで、Windows / Excel / VBA で自動売買のためのマクロを作ってリアルタイムの取引シミュレーションを始めており、Python で検証をしています。
現在の開発状況を更新しました。
| フェーズ | 開 始 | 状 況 | 目 的 | 成 果 |
|---|---|---|---|---|
| Phase 1 | 2024-12-10 | 終了 | 実現可能性 (feasibility) |
|
| Phase 2 | 2024-12-16 | 終了 | マクロ再構成 |
|
| Phase 3 | 2024-12-31 | 取りやめ | 実装 |
|
| Phase 4 | 2025-03-09 | 開発中 | 評価・実装 |
|
| Phase 5 | 2025-05-17 | 開発中 | 再評価・再実装 |
|
| Phase 6 | 2025-07-?? | 未着手 | 本運用 |
|
Python で作っている自作のデイトレアプリで、ゆくゆくは自動売買に挑戦するために取り組んでいます。しかし自動売買実現までの道のりは長いので、まずはセミオート操作で売買ができるように進めています。以下は株価などの情報の流れを示しています。
楽天証券では、Python からネットワーク越しに直接取引できるような API が提供されていないので、マーケットスピード２ RSS を介して取引をする構成を取っています。
リアルタイムデータ向け Parabolic SAR（RealtimePSAR クラス）の改良
6/16 の週は自作アプリで取引シュミレーションを続けましたが、特に最初のエントリ部分で損失を重ねて、トレーディング・センスの無さを晒け出してしまいました。😮💨
センスが無いことは重々自覚しています。鋼のような揺るがない精神力を持てるよう精進して、設定したルール通りにトレードできる優秀なトレーダーを目指すつもりは毛頭ありません。その代わり、センスの無さを排除できる自動取引アルゴリズムを作ろうとしています。
ということで、面倒そうなので後回しにしていましたが、最初のエントリを自動化することこそが最優先事項だと考え直し、この週末は RealtimePSAR クラスの改良に取り組みました。
方針は、ベストなエントリ・ポイントを探ることではなく、寄り付き後にそこそこ妥当なトレンド方向を示して、それに従ってそこそこまともな取引をすることです。完璧な目標を設定すると計画倒れに終わる可能性があるので、実現できそうなところから始めました。😅
Google Gemini との作業
いままで使用してきた Parabolic SAR のクラスは、参考サイト [7] で紹介したものとほぼ同じアルゴリズムです。最初のトレンドはとりあえず最初の 2 点の株価の大小で決めてしまっています。
最近は Google Gemini（以降、単に Gemini）と一緒にコーディングをすることが多くなり、便利過ぎて手放せなくなってしまいました。もちろん、今回も手伝ってもらっています。
この RealtimePSAR クラスを Gemini と共有すると、ご丁寧にも最初のトレンド判定は敏感過ぎるとアドバイスをしてくれます（ちょっとムッとしますが、ここは堪えます）。それでは、ロバストな判定をするためにはどうすれば良いかと尋ねると、下記のような提案とサンプルコードまで示してくれました。
- 移動平均線 (Moving Average) の利用
- リニア回帰 (Linear Regression) の傾き
- ボリンジャーバンド (Bollinger Bands) や標準偏差の利用
- 高値・安値の更新パターン
もっともらしい提案だったので、少しは付き合ってもいいかなと心が動きましたが、たぶん時間の無駄になります。そこで、いままで温めていた案をぶつけることにしました。それは多数決のアルゴリズムです。
少ない点でそこそこ妥当なトレンドを決めるのに、線形的なアプローチは要らないと考えました。寄り付き後の最低 30 秒（= 30 点）をトレンド決定のために使うと決めて、長い長い Gemini との議論と Jupyter Lab での検証作業が始まりました。
多数決アルゴリズムを加えた Parabolic SAR
長い長い議論を経て、使えそうな多数決アルゴリズムにたどり着くことができたので、改良した RealtimePSAR クラスについて Gemini に要約してもらいました。少し文章を編集して掲載しています。
RealtimePSAR クラスの主要な特徴
この RealtimePSAR クラスは、Parabolic SAR (PSAR) をリアルタイムのティックデータに適用し、特に寄り付き直後の初期トレンド決定に焦点を当てています。その特徴は以下の通りです。
リアルタイムデータ処理:
add(price: float) メソッドを通じて、新しい価格ティックが、リアルタイムにほぼ等間隔（約 1 秒）で追加されることを前提として設計されています。内部で PSARObject を管理し、トレンド、EP (Extreme Point)、AF (Acceleration Factor)、PSAR 値などをティックごとに更新します。
初期トレンド多数決ロジック:
判定基準:
寄り付き直後の PSAR の初期トレンドを決定するために、decide_first_trend メソッドに多数決ロジックを実装しています。このロジックは、期間内の各価格が最新の価格に対して高いか低いかを基準に投票を行います。
- p < price ならば「低い票」としてカウントします。
- price < p ならば「高い票」としてカウントします。
- p == price の場合は投票に含めません。
トレンドの解釈:
低いデータが多い場合（「低い票」が優勢）は上昇トレンド、高いデータが多い場合（「高い票」が優勢）は下降トレンド」と判断します。これは、過去の価格分布から現在の価格がどの方向へ推移してきたかを捉えるものです。
固定長データ期間:
多数決の評価には collections.deque を使用し、固定長の n ティック分（デフォルトは 30 ティック）の価格データを効率的に保持・利用します。これによりデータ管理が最適化されています。
多数決の閾値:
トレンドを決定するためには、特定方向の票数（「低い票」または「高い票」）が投票総数の 2/3（約66.6%）を超える必要があります。
PSAR と EP の初期値設定:
初期トレンドが決定されると、PSAR の初期値は決定されたトレンドと反対方向の収集期間内の極値に、EP は決定されたトレンド方向の収集期間内の極値に設定されます。これにより、PSAR が価格から適度に離れた位置から始まり、寄り付き直後のノイズによる急激な反転を抑制し、安定した追従を促します。
未決定時の挙動:
固定長の n ティックのデータが揃っていない場合、または多数決の閾値を満たすほど明確なトレンドが見られない場合は、トレンドを決定せず obj.trend は 0 のままとなります。この場合、PSAR は表示されません。
最初のエントリの比較
金曜日の 7011 について、寄り付きから 20 分間のトレンドを、改修前後の RealtimePSAR クラスで比較しました。ほんの些細ま差です。しかし、これによって自動化の道が少し開けてきました。
多数決を取るデータ数や多数決を採る 2:1 の閾値は、えいやっで決めていますので、しばらく使ってみて良さげであれば、最適条件の探索を検討したいです。
これから、アプリの GUI の変更に取りかかります。明日、東京市場が始まるまでにどこまでできるか…。
参考サイト
- マーケットスピード II RSS | 楽天証券のトレーディングツール
- マーケットスピード II RSS 関数マニュアル
- PythonでGUIを設計 | Qtの公式Pythonバインディング
- PyQtGraph - Scientific Graphics and GUI Library for Python
- Python in Excel alternative: Open. Self-hosted. No limits.
- Book - xlwings Documentation
- 私の株日記: Realtime Parabolic SAR
0 件のコメント:
コメントを投稿