開発・検証の記録

Codexと作る、
米国株の自動売買。

完成した仕組みだけでなく、考えたこと、確かめたこと、失敗から直したことも記録します。

戦略を検証し
バックテストを経て実戦で確かめる

しっかり者の女性キャラクター

完成した自動売買だけを紹介するの?

完成形だけでは、なぜそうなったか分からへん。試した案、失敗した理由、実運用で見つかった違いも残します。

サイト案内役のおっちゃんキャラクター
女性キャラクターの返答

良い結果だけでなく、作って確かめた過程まで読めるようにするんだね。

このページで紹介すること

自動売買は、売買ルールだけで完成するものではありません。必要なデータをそろえ、注文が本当に約定したかを確認し、保有中の状態を管理し、決済後の結果を記録するところまでが一つの仕組みです。このページでは、その開発と検証を段階ごとに紹介します。

作るどんな問題を解決するか

思いついた機能ではなく、必要な理由と期待する動きを先に整理します。

確かめる意図したとおり動くか

過去データ、テスト、実際の記録を使い、成功例と失敗例の両方を確認します。

振り返る実運用との差は何か

注文、約定、損益を確認し、次に直す点と変更しない点を分けます。

自動売買が記録になるまで

各工程をつなげ、途中の状態を飛ばさないようにしています。「候補になった」と「実際に買えた」、「注文した」と「約定した」は別の状態として扱います。

  1. 1
    データをそろえる

    価格や市場の状態など、判断に必要な情報を確認します。

  2. 2
    売買候補を確認する

    決めた考え方に合う銘柄があるかを確認します。

  3. 3
    注文と約定を分ける

    注文を出しただけで取引成立とはせず、約定結果まで確認します。

  4. 4
    保有と決済を管理する

    保有中の状態を追い、決済が終わってから損益を確定します。

  5. 5
    記録して確認する

    実約定を基に記事を作り、公開前に人が内容を確認します。

Codexと人の役割

Codexが担当すること

作る・調べる・比較する

  • 要件を整理してプログラムへ反映する
  • テストを行い、意図と違う動きを探す
  • 複数の結果を同じ条件で比較する
  • 変更内容と確認結果を記録する
人が担当すること

目的と採否を決める

  • 何を解決したいか、優先順位を決める
  • 損失や資金の扱いを含む運用方針を決める
  • 検証結果を見て、採用するか判断する
  • サイトやXへ出す内容を公開前に承認する

Codexが利益を保証したり、良い結果だけを選んで採用を決めたりするわけではありません。最終判断は確認できたデータを基に人が行います。

検証結果を見るときの4つのポイント

成績を見るときは、利益が出たかだけでなく、いつのデータを使い、何回売買し、途中でどの程度減ったかまで確認します。

いつのデータか検証した期間開始日・終了日・対象銘柄
何回売買したか取引回数少ない件数だけで判断しない
いくら増減したか利益と損失手数料などの費用も含める
途中でどこまで減ったか最大の下落続けられる範囲かを見る

検証記事では、この4項目を同じ場所で確認できるようにします。確認できていない数値は載せません。

バックテストで大切にしていること

1

相場が違っても続くか

上がり続ける年だけでなく、下落や方向感のない時期も確認します。

2

勝率だけで判断しない

何回勝ったかだけでなく、1回の利益と損失の大きさも確認します。

3

実際の運用と比べる

過去データでは良くても、実際の売買で同じように動くとは限りません。

開発記事の基本構成

記事ごとに書き方が変わりすぎないよう、次の順で整理します。

01
課題

何が問題で、なぜ変更を考えたのか。

02
変更

どの部分を、どのような考え方で直したのか。

03
確認

どの期間・データ・条件で確かめたのか。

04
結果

改善した点、悪化した点、想定外だった点は何か。

05
判断

採用、見送り、継続確認のどれにしたのか。

しっかり者の女性キャラクター

勝率が高ければ、良い仕組みってこと?

100回小さく勝っても、1回で大きく負けたら困るやろ。勝率だけでは決められへん。

サイト案内役のおっちゃんキャラクター
女性キャラクターの返答

利益と損失の大きさ、取引回数、最大の下落も一緒に見る必要があるね。

これから紹介する内容

まずは、自動売買の開発と検証を理解するための5つの基礎記事を用意しました。各テーマを選ぶと、個別記事で詳しく読めます。今後の開発記録も、確認できた内容からここへ追加します。

良い結果が出なかった案も残します

検証して採用しなかった案や、実運用で想定どおりに動かなかった機能も、理由を確認できるものは紹介します。過去の検証が良くても実運用では差が出ることがあり、反対に一度の成功だけで仕組み全体が良いとは判断できません。採用、見送り、継続確認を分けて記載します。