今回は「見せる」回です
前回までで、手法の検証が一段落しました。逆張り戦略のバックテスト、パラメータの最適化、順張りとペアトレードの検証と凍結。開発フェーズが終わり、ここからは運用フェーズ——作ったシステムを毎日動かす話に入ります。
ただし、この回では技術的な実装方法を書きません。後述するGemini APIのプロンプト（ここだけは人間の知恵が必要です）を除けば、残りはすべてAIに丸投げで組める部分です。
ここまで読んでくださった方なら、もうお分かりだと思います。環境構築はAIにナビゲートしてもらえばいい。コードはAIに書かせてコピペすればいい。エラーが出たら貼って直せばいい。そのサイクルはもう身についているはずです。
今回は、完成したシステムが実際にどう見えるかを、画面のスクリーンショットでお見せします。「こういうものが毎日動いている」「帰宅したらこれが届いている」——その手触りを掴んでもらう回です。
もし「自分でも組んでみたい」と思ったら、この記事のフロー図をスクリーンショットで撮って、AIに投げてみてください。「この構成でシステムを作りたい」と伝えれば、ナビゲートしてくれるはずです。図が設計図になります。
買付シグナルのフロー
まず、毎日の買付候補が通知されるまでの流れです。
中央にあるPythonバッチが心臓部で、ここから4つのサービスに線が伸びています。順番に見ていきます。
①タスクスケジューラが起動する
これはWindowsに標準で入っているタスクスケジューラという機能です。「毎日◯時にこのプログラムを実行しろ」と登録しておくと、PCが勝手に実行してくれる。自分のバッチをここに追加するだけです。
私は午後6時に設定していました。相場が終わって株価データも更新されていて、仕事から帰宅する頃にはもう結果が届いている。ちょうどいい時間です。夜のうちに翌営業日の注文を出すので、朝はすることが基本ありません。
②J-Quantsからデータを取得し、③④Gemini APIで定性フィルターにかける
タスクスケジューラに起動されたPythonバッチは、まずJ-Quantsから直近数十日分の株価データを取ってきます。SMAやRSIの計算、出来高の変化の判定には、当日だけでなく過去数十日分の株価が必要だからです。
バックテストのときと違って毎日の取得量はそこまで多くないので、私は毎回まとめて取得する設定にしています。過去分を蓄積しておいて当日分だけ追加する方法もありますが、手順が複雑化する割にメリットがあまりない。勝手に実行されて勝手に終わっているので、これで十分です。
そしてバックテストで詰めた条件に基づいて全銘柄をスクリーニング。条件に合致した銘柄——つまりシグナルが出た銘柄を、次にGemini APIに渡します。
その心臓部がこれです。
冒頭にJ-QuantsのAPIキー、DiscordのWebhook URL、GeminiのAPIキーが並んでいます。先ほどのフロー図で線が伸びていた各サービスとの接続は、すべてここに集約されたキー情報で成り立っている。1つのファイルの中に、外部サービスへの扉がすべて揃っています。
（なお、実運用ではAPIキー類はコードに直書きせず、環境変数や別ファイルに分けるほうが安全です。この記事では構造を見せるために、接続情報がどこに集まっているかをそのまま示しています。）
そしてこのファイルの中には、バックテストで何十回も回して詰めた条件が詰め込まれています。これまでの回でずっと作ってきたのは、このファイルの中身です。第4回でPFを削って磨いた数字、第5回で凍結した手法との比較を経て生き残ったルール——その全部がここにある。
そしてもう1つ、重要な場所があります。
これが、定量スクリーニングを通過した銘柄に対して、Gemini APIが定性判断を行うためのプロンプトです。
ここも、この連載で繰り返してきた「人間がAIと対等に話し合う戦略」が実装されている場所です。定量スクリーニングの条件設計と、このプロンプトの中身——この2つが、あなたの投資経験から来る「暗黙知」をふんだんに発揮する部分。定量フィルターだけではすり抜けてしまう銘柄——業績が急悪化している銘柄、TOBが進行中で株価がアンカーされている銘柄——を、AIの定性判断で弾く。第2回のフロー図で示した「定量→定性」の二段構えが、コードの中に生きています。
このプロンプトの中身（何を棄却条件にしているか、なぜそう決めたか）は、次回の定性フィルターの回で詳しく話します。
⑤⑥Discordに通知が届く
そして帰宅すると、Discordにこれが届いています。
🟢が承認（買付候補）。銘柄コード、現在値、乖離率、RSI、出来高倍率と、Geminiの判断理由がセットで表示されます。「業績悪化条件に該当しないため承認」「棄却条件に抵触しないため承認」——理由まで書いてあるので、判断の根拠が一目で分かる。
そしてこちらが棄却された銘柄。
🔴が棄却。棄却理由も詳細に書かれています。「監理銘柄に指定されている」「コーポレートアクションが進行中」「業績悪化条件に該当」——こういう銘柄を機械的に弾いてくれる。
よく見ると、途中にAPIエラー（503 UNAVAILABLE）も出ています。Gemini APIがたまに混雑して応答しないケース。こうしたエラーの扱いも含めて、次回の定性フィルターの回で説明します。
決済シグナルのフロー
次に、保有中の銘柄をいつ売るかの判定フローです。
買付フローと比べて構造がシンプルです。Gemini APIを経由しない。決済は純粋に数字の判断なので、定性フィルターは要りません。
①②ポジションCSVから保有情報を読み込む
決済バッチはまず、自分の保有状況が記録されたCSVを読みます。
銘柄コード、取得日、取得価格、Tier（戦略の種別）。このファイルを自分で更新しておくと、バッチがここから情報を引っ張ってくる。
決済バッチ側のコードも、冒頭にAPIキーやCSVパスが並ぶ構造は買付と同じ。ただしGemini APIの接続情報がありません。決済は株価データだけで判断できるからです。
③④⑤⑥最新株価を取得→判定→通知→発注
J-Quantsから最新の株価を取得し、保有銘柄ごとに決済条件（SMA到達、RSI回復、ストップロス、タイムストップ）を判定。シグナルが出たらDiscordに通知が飛びます。
「タイムストップ（保有5営業日経過）」「成行売り指示」——どの条件に引っかかったか、現在の損益率まで表示されます。下部にはOCO注文（利確と損切りの指値を同時に出す注文）のターゲット価格も一覧で出る。
決済の自動化について
買付は人間の目を挟むべきだと思っています。AIの定性判断を最終確認するステップは、少なくとも今の段階では外せない。
でも決済は話が違います。むしろ人間の判断を入れてはいけないとすら考えています。「まだ上がるかもしれない」「この銘柄はやばいのではないか」——あとからそういう煩悩を実行に移してしまうことは、システムトレードにおいて絶対に避けるべきです。これはGeminiに口酸っぱく指導されました。日々の指値の更新、タイムストップによる成行注文への切り替え——これらは機械的に淡々と執行するものであって、そこに人間の裁量が入る余地を残してはいけない。
であれば、証券会社のAPIに直結させて完全自動化するのが理想です。三菱eスマート証券がAPIを提供していて、おそらくできると思います。ただし、株式取引のAPIを提供している証券会社はまだ多くないのが現状です。
今回のまとめ
- 完成したシステムは2つのPythonバッチ（買付・決済）で構成される
- タスクスケジューラで毎日自動起動。午後6時に設定すれば、帰宅時には通知が届いている
- 買付バッチは定量スクリーニング→Gemini API定性フィルター→Discord通知の流れ
- 決済バッチはポジションCSV→株価取得→条件判定→Discord通知。Gemini APIは経由しない
- 技術的な実装はAIに聞けばナビゲートしてくれる。この記事のフロー図を撮って投げるだけ
次回は、買付フローの中で一番「人間の知恵」が詰まっている場所——定性フィルターの中身に踏み込みます。Gemini APIに何をどう聞いているのか、棄却の判断基準、そしてAPIエラーの話。
次回・第7回：定性フィルターの中身——Gemini APIに「買ってはいけない銘柄」を判断させる
免責事項：本記事は筆者の実体験に基づく情報提供を目的としたものであり、特定の銘柄・手法・サービスへの投資や購入を推奨するものではありません。スクリーンショットに表示されている銘柄コード・価格・指標値は特定日時点のデータであり、投資助言ではありません。投資判断はご自身の責任でお願いします。