前回は、AIデイトレ検証システムで監視する銘柄をどう選ぶかについて書きました。

今回は、その監視リストの中から、AIに渡す候補データをどう整理していったかについてです。

AIに判断させるといっても、ただ銘柄コードだけを渡してもあまり意味がありません。

その銘柄がなぜ候補に入ったのか、今どんな動きをしているのか、注意すべき材料はあるのか。そういった情報をまとめて渡す必要があります。

AIに渡す前に情報を整理する

最初に意識したのは、AIへ渡す情報をできるだけ同じ形にそろえることです。

人間が画面を見るときは、多少バラバラな情報でも雰囲気で読めます。

価格、前日比、出来高、シグナル、注意点、候補に入った理由。こういう情報を見ながら、なんとなく全体像をつかめます。

でもAIに渡す場合は、その「なんとなく」を減らす必要があります。

どの銘柄にも同じ種類の項目があり、同じ意味で読めるようにする。まずはそこを整えることにしました。

銘柄ごとに残したい情報

AIに渡す候補データでは、銘柄ごとに最低限の情報をまとめるようにしました。

  • 銘柄コードと銘柄名
  • 現在値や直近の価格情報
  • 出来高や売買の活発さ
  • 候補に入った理由
  • シグナルの状態
  • 注意すべき材料

このあたりをそろえておくと、AIの判断結果をあとから見返したときにも、なぜその判断になったのかを追いやすくなります。

逆に、候補ごとに渡している情報がバラバラだと、判断の比較がしづらくなります。

ある銘柄には出来高の情報がある。別の銘柄には注意シグナルだけがある。さらに別の銘柄には候補理由がない。

こうなると、AIの判断が良かったのか、入力データが足りなかったのかが分かりにくくなります。

候補数をしぼる理由

監視リストは80件前提にしましたが、その全部を毎回AIへ渡すわけではありません。

AIに渡す候補は、さらにしぼる必要があります。

理由は単純で、候補が多すぎると判断がぼやけるからです。

80件すべてを見せて「この中から判断して」とすると、AI側も見るべき材料が多くなりすぎます。

そこで、まずはシグナルや値動きの条件で候補をしぼり、AIには検証対象として見やすい数だけ渡す方針にしました。

多すぎず、少なすぎず、あとから比較できる数にする。

このバランスがけっこう大事でした。

除外した候補も記録する

もうひとつ大事だと思ったのが、AIに渡した候補だけでなく、除外した候補も記録しておくことです。

候補から外した銘柄は、つい見なくなってしまいます。

でも後から振り返ると、除外した銘柄の方がよく動いていた、ということもあります。

そのときに、なぜ候補から外したのかが残っていないと、次の改善につながりません。

そこで、候補に入った理由だけでなく、候補から外した理由もできるだけ残すようにしました。

  • 注意シグナルが強かった
  • 候補数の上限から外れた
  • 検証対象として優先度が低かった
  • その時点の条件に合わなかった

こういう記録があると、AIに渡す前の段階で何が起きていたのかを確認できます。

AIの判断だけを見るのではなく、AIに見せる前のしぼり込みも検証対象にする、という考え方です。

AIに見せる情報で結果が変わる

AIに判断させるとき、ついプロンプトやモデルの性能に目が行きます。

もちろん、それも大事です。

でも実際に作ってみると、それ以前に「何を見せるか」がかなり大事だと感じました。

価格だけを見せるのか。シグナルも見せるのか。注意点も見せるのか。候補に入った理由を見せるのか。

渡す情報が変われば、AIの判断も変わります。

だからこそ、AIへ渡したデータそのものをあとから確認できるようにしておく必要があります。

AIがどんな判断をしたかだけでなく、その判断の前提として何を見ていたのか。

ここを残しておかないと、判断結果だけを見ても改善しづらくなります。

まとめ

今回は、監視リストの中からAIに渡す候補データをどう整理したかについて書きました。

AIに判断させる前に、候補の形をそろえ、必要な情報をまとめ、除外した理由も残しておく。

この前処理をきちんと残すことで、AIの判断結果をあとから検証しやすくなります。

AIデイトレ検証システムでは、AIの答えだけを見るのではなく、AIに何を見せたのかもセットで記録していく方針にしました。

次回は、整理した候補データを使って、複数のAIに売買判断をさせてみる流れについて書きます。

※この記事は、個人開発している株価・デイトレード検証システムの作業記録です。

特定の銘柄の売買を推奨・勧誘するものではありません。

掲載内容は投資助言ではなく、実際の投資判断はご自身の責任でお願いします。

また、実注文機能について触れる場合も、検証・安全設計の考察として記載しています。