日本株AI自動売買ツール開発記録|未経験から実運用を目指すまで

KABU BUILDでは、AIとPythonを使って日本株の投資支援・自動売買ツールを開発しています。

プログラミング経験がほとんどない状態から開発を始め、

売買ルールを作る
↓
過去データでバックテストする
↓
問題点を見つけて改善する
↓
実際の資金・売買条件に近づける
↓
証券会社の市場データにつなぐ
↓
Paper Tradingで検証する
↓
少額の実運用を目指す

という流れで進めています。

このページでは、これまでの開発・検証を時系列でまとめています。

良かった結果だけでなく、最大損失やバックテストの問題点、実装途中で分かった課題なども含めて公開しています。


開発の現在地

このプロジェクトは、ChatGPTとPythonを使って日本株の分析を効率化するところから始まりました。

最初から完全自動売買を目指したのではなく、実際に使いながら少しずつ機能を追加し、現在はPaper Trading開始前の最終確認まで進んでいます。

日本株の分析を効率化するツールを作り始める
✓ 開発スタート

↓

複数銘柄を分析し、売買候補を絞り込む
✓ 完了

↓

過去データを使って売買ルールをバックテスト
✓ 完了

↓

損切り・資金制約・スリッページなどを加えて検証
✓ 完了

↓

実際の運用を想定した注文管理・安全対策を実装
✓ 完了

↓

証券会社APIから実際の市場データを取得
✓ 完了

↓

100万円の仮想資金で資金管理・緊急停止を実装
✓ 完了

↓

AIの売買判断から仮想注文までを接続
✓ 完了

↓

市場データを使った仮想約定判定を実装
✓ 完了

↓

Paper Trading開始前の監査・最終確認
← 現在ここ

↓

Paper Tradingで継続検証

↓

少額での実運用

↓

実運用結果を検証しながら改善


プログラミング未経験から開発をスタート

最初はChatGPTやPythonを使って、

  • 株価データを取得する
  • RSIやMACDなどのテクニカル指標を計算する
  • 複数銘柄を分析する
  • 条件に応じて売買候補を絞り込む

ところから始めました。

この段階では、まだ「自動売買」というよりも、投資判断を支援するツールです。

→ プログラミング未経験から日本株AI投資支援ツールを作ってみた

複数の指標から売買候補をスコア化

株価データやテクニカル指標を取得できるようになったあと、RSI・MACD・出来高など複数の情報を組み合わせて、銘柄ごとに売買判断をスコア化しました。

単に点数を出すだけではなく、

「なぜそのスコアになったのか」

も確認できるようにし、複数銘柄から売買候補を絞り込む仕組みへ発展させています。

→ 株の売買判断をPythonでスコア化してみた|RSI・MACD・出来高を点数化


売買ルールをバックテスト

売買候補を出せるようになったところで、

「この売買ルールは、過去の相場でも本当に利益が出ていたのか?」

を確認するため、バックテスト機能を作りました。

まずバックテストの仕組みを作り、その後、対象を20銘柄まで拡大。

20銘柄・224取引まで広げると、高い勝率が出た一方で、最大損失が-60%を超える取引も見つかりました。

→ 株のバックテストとは?プログラミング未経験者がPythonで売買ルールを検証してみた

→ 株のバックテストを20銘柄に拡大|224取引で勝率75%、でも最大損失-62%


「勝率が高い=安全」ではなかった

20銘柄へ広げたバックテストでは、

  • 総取引数:224回
  • 勝率:76.3%
  • 平均損益率:+8.23%

という結果が出ました。

しかし中身を見ると、最大損失は-61.30%。

そこで、保有中にどこまで上昇・下落したのかまで調べ、固定STOP(損切り)を実装しました。

さらに、一度大きな含み益が出たあとに損失へ転落する取引もあったため、利益を守るためのトレーリングSTOPも検証しています。

→ 勝率76%でも安心できない。AI株バックテストに損切りを実装した結果

→ トレーリングSTOPは有効?日本株バックテストで6パターン検証してみた


「実際の資金で買えるのか」を検証

売買ルール単体の成績だけでは、実際の運用結果は分かりません。

そこで、

  • 初期資金
  • 日本株の100株単位
  • 同時保有数
  • 現金残高
  • 1銘柄を買うために必要な資金

などを追加し、ポートフォリオ単位のバックテストへ進みました。

すると、単純な売買成績とは別の問題が見えてきました。

「シグナルが出ても、実際の資金では100株買えない」

という問題です。

さらに調整済み株価と実際の購入価格の扱いにも問題が見つかり、バックテストの価格処理を見直しました。

→ 100万円で株のバックテストをしたらSTOPなしが最終資産トップに|資金制約で見えた落とし穴

→ 調整済み株価の落とし穴|100万円のバックテストで「買えない株」を買っていた


実運用候補を50銘柄へ拡大

それまでの20銘柄には、100株買うだけで大きな資金が必要になる値嵩株も含まれていました。

そこで、50万~100万円程度から実際に運用することを想定し、対象銘柄を50銘柄へ組み直しました。

ところが、買える銘柄を増やせば資金効率も良くなると思っていたものの、今度は現金が余るという別の問題が発生。

銘柄数だけではなく、

「何銘柄まで同時に保有するのか」

も重要だと分かりました。

→ 買える株を50銘柄に増やしたら現金が余った|AI株バックテストで分かった資金配分の重要性


スリッページと期間による違いを検証

バックテストをさらに実運用へ近づけるため、

「想定価格と実際の約定価格がずれたらどうなるのか?」

を確認するスリッページも追加しました。

さらに、約5年間トータルで利益が出ているだけでは不十分と考え、開始時期を変えて結果が大きく崩れないかも検証しました。

その結果、2年間では良好だった一方、1年間ではマイナスになる期間も確認できました。

→ 取引コストより効いた「100株の壁」|スリッページ0〜20bpで自動売買を検証

→ 5年間プラスでも安心できない。バックテストを期間別に分解したら見えた弱点

ここまでで、バックテスト中心の開発はいったん一区切りとしました。


バックテストから実運用を想定したシステムへ

次に考えたのが、

「過去データではなく、実際の市場で動かすには何が必要なのか?」

という問題です。

売買ロジックだけでは実際の自動売買システムにはなりません。

そこで、

  • 注文を管理する
  • 同じ注文を二重に出さない
  • 異常時には新しい取引を止める
  • 証券会社と自分の記録が一致しているか確認する

など、実運用を想定した仕組みを作り始めました。

→ Pythonで株の自動売買システムを自作中|実運用に向けて注文管理と安全対策を実装


証券会社APIと実際の市場データ

実際の市場で動かすには、現在の株価を取得する必要があります。

そこで自動売買に利用できる証券会社の環境を比較し、最初の接続先として三菱UFJ eスマート証券のkabuステーションAPIを選びました。

その後、Pythonから実際の市場データを取得するところまで進めています。

→ 株の自動売買はどの証券会社を選ぶ?APIを比較して三菱UFJ eスマート証券にした理由

→ Pythonで株の自動売買ツールを証券会社APIに接続|実際の株価データ取得まで進んだ

実運用前に誤発注・異常データ対策を強化

証券会社APIから実際の市場データを取得できるようになりましたが、接続できたからといって、そのまま注文機能へ進むのは危険です。

実際のお金を扱うことを想定すると、

  • 同じ注文を二重に送らない
  • 古い株価や異常なデータでは注文しない
  • 注文結果が分からない場合は自動で再送しない
  • 再起動後に証券会社と自分の記録を照合する
  • 人間が承認した注文にも有効期限を設ける

といった安全対策が必要になります。

そこで、

「状態を確認できないときは、無理に取引を続けない」

ことを基本方針として、実運用前の安全対策を追加しました。

→ 株の自動売買を実運用する前に安全対策を実装|二重注文・異常データをどう防ぐ?


Paper Trading前に資金管理と緊急停止を実装

実際のお金を使う前に、Paper Tradingでシステム全体を検証します。

ただし、仮想売買だからといって無制限に注文してよいわけではありません。

そこで100万円の仮想資金を設定し、

  • 1銘柄への投資上限
  • 総投資額
  • 最低限残す現金
  • 同時保有数
  • 1日の損失上限
  • 異常時の緊急停止

などのルールを実装しました。

→ 100万円でPaper Tradingする前に。日本株自動売買に資金管理と緊急停止を実装


AIの売買判断から仮想注文まで

それまで個別に作ってきた機能をつなぎ、

株価データ
↓
AIによる売買判断
↓
買い候補を選ぶ
↓
人間が確認
↓
注文直前の安全確認
↓
仮想注文

という流れを作りました。

ただし、この段階では「注文を出した」だけです。

注文を出したことと、実際に約定したことは別なので、まだ仮想口座の保有株や現金には反映しません。

→ AIの売買判断から仮想注文まで。日本株Paper Tradingの仕組みをつないでみた


市場データを使って仮想約定を判定

次に、

「出した注文が、実際の市場なら本当に約定していたのか?」

を市場データから判定する仕組みを追加しました。

注文を出しただけでは約定扱いにせず、市場データから条件を満たしたことを確認できた場合だけ、仮想口座の現金や保有株へ反映します。

→ 仮想注文は本当に約定した?日本株Paper Tradingに約定判定を実装


現在はPaper Trading開始前の最終確認

現在は、

AIが売買候補を判断し、人間が確認したうえで仮想注文を出し、市場データを使って仮想約定を判定する

ところまで進みました。

ただし、まだ正式なPaper Tradingを開始したわけではありません。

現在は、システムが安全条件を守って動いたことを後から確認できるようにするため、監査記録や最終確認の仕組みを整えています。

この確認が終わったあと、一定期間Paper Tradingを行い、

  • AIがどの銘柄を選んだか
  • どの価格で仮想注文を出したか
  • 実際に仮想約定したか
  • 利益・損失はいくらだったか
  • バックテストとの違い
  • 想定外の動作がなかったか

を検証する予定です。

Paper Tradingでも問題がなければ、その後は少額での実運用へ進む予定です。


完成した結果だけではなく、開発の過程も公開します

KABU BUILDでは、完成したツールだけを紹介するのではなく、

作る → 試す → 問題を見つける → 改善する

という過程そのものを公開しています。

バックテストで良い数字が出ても、その結果をそのまま信用するのではなく、条件を変えたり、実際の資金や売買単位を入れたりしながら検証してきました。

今後もPaper Trading、少額での実運用、その後の改善まで進め、このページも開発状況に合わせて更新していきます。