kabu API独自足生成からTradingView Webhookへ移行した理由
自動売買システムの開発環境を見直し
Googleアップデートによるアクセス変化への対応や、
自動売買システムの改善など、日々の運用で考えたことを記録する「運用者ブログ」を始めてみます。
今回は、ここ半年ほど進めている売買システム構成の変更についてです。今回は、ここ半年ほど進めている売買システム構成の変更についてです。
これまでの開発環境：kabu APIによる独自足生成
これまで一部の戦略では、kabu APIのPush APIを利用した独自足生成ベースで開発していました。
この方式のメリットは、細かなデータ処理や独自ロジックの自由度が高い点です。
また、TradingViewのWebhook連携とは異なり、足の確定を待たずにリアルタイムデータをもとに任意のタイミングで発注処理を実行できる点も大きな特徴です。
例えば、
- 独自の足生成
- 標準指標では扱いにくい条件判定
- リアルタイムデータを利用した細かなエントリー・決済条件
- 足確定前のタイミングでの発注制御
など、自由度の高い戦略設計が可能でした。
戦略数が増えるにつれて開発コストが課題に
一方で、戦略の数を増やしていくにつれて、開発・検証コストと工数が課題になってきました。
もちろん1つの戦略を時間をかけて作り込むことはできます。
しかし、個人で複数戦略を運用する場合、
- 新しいアイデアを試す
- バックテストする
- 改善する
- 実運用へ移行する
というサイクルを随時回すことが重要になります。
1つの戦略開発に時間がかかりすぎると、検証できるアイデアの数自体が減ってしまいます。
TradingView + Webhook構成へ移行
そこで現在は、多くの戦略をTradingViewのWebhook連携ベースへ移行しています。
正確には、売買シグナルの生成部分をTradingView + Pine Scriptへ移行し、Webhook経由で既存のkabu API発注システムへ連携する構成です。
発注処理自体は引き続きkabu API側で行うことで、証券APIとの接続や注文管理部分はこれまでの環境を活用しています。
細かなデータ処理や独自ロジックの自由度では、独自足生成方式のほうが有利です。
ただ、個人運用で複数戦略を分散する場合、1つの戦略を作り込むことだけではなく、多くのアイデアを低コストで検証し、改善サイクルを回せる環境を作ることも重要だと考えています。
TradingView + Pine Scriptの場合、
- 戦略作成までの速度が速い
- バックテスト環境が整っている
- 条件変更や比較検証が容易
- 複数アイデアを試しやすい
というメリットがあります。
現時点での判断
そのため現在の運用方針では、Pine Scriptで素早く戦略を作成し、バックテスト・検証まで進められるTradingViewベースの構成のほうが費用対効果が高いと判断しています。
もちろん、独自足生成環境が不要というわけではありません。
より高度なデータ処理や、標準環境では実現できないロジックが必要になった場合は、用途に応じて使い分けていく予定です。
今後も運用しながら、開発効率と戦略パフォーマンスのバランスを見て改善していきます。
コピペで動く! 無料TradingViewストラテジー公開中 →はじめての自動売買・Pine Scriptの学習におすすめ
