月3,000円の現物積立botを、予想ではなく状態機械として設計した
今回やったこと / この記事について
月3,000円の現物積立を、価格を予想する仕組みではなく、決めた条件を順番に実行する状態機械として設計した。対象は、少額の定期処理を自動化したい個人開発者や小規模チームである。この記事で扱うのは銘柄の推奨ではなく、残高確認、数量計算、注文、記録をどう分離したかという実装上の判断だ。
初期実装はGitHub Actionsのcronとstate.jsonを中心に組み立て、Phase 1〜4、dry-run、pytest 17件まで進めた。自動化の目的は利益を当てることではなく、毎回の判断を同じ入力とガードレールで再現することに置いた。
固定額をそのまま注文額にしない
「毎月3,000円」と決めても、各銘柄の最小数量、数量刻み、手数料を無視すると注文は成立しない。そこで、シンボルAPIから最小数量、sizeStep、手数料を動的に取得し、取引可能な単位へ丸める処理を先に置いた。設定ファイルに数字を固定すると、取引条件の変更時に古い値で注文する可能性があるためだ。
銘柄ごとに1,500円ずつのような固定配分にもせず、数量刻みの粗い銘柄から配分した。最後にBTCを0.00001刻みで調整し、JPY残高をできるだけ使い切る方式にした。重要なのは、配分の結果を予想に結び付けず、残高と取引ルールから機械的に導くことだ。
月次上限を読む
↓
シンボル条件と手数料を取得
↓
数量刻みに合わせて各注文を計算
↓
残額を最終銘柄の刻みで吸収
↓
dry-runで注文内容を記録
↓
ガードを通った場合だけ発注
state.jsonには、処理がどこまで進んだかを残す。残高を読んだだけなのか、注文を送ったのか、約定結果を記録したのかを区別できるため、途中停止時に同じ注文を二重に送るリスクを抑えられる。自動化では「成功したか」だけでなく「次にどの状態から再開するか」が必要になる。
dry-runと実注文で分けたもの
初期実装ではdry-runを用意し、残高・数量・手数料を使った計算結果を注文前に確認できるようにした。テストは17件まで増やし、丸め、残額、最小数量、状態遷移を個別に確認した。注文APIへの接続だけを本番に切り替えても、計算部分を同じテストで守れる構成にしたかった。
初回の本番ではSOL 0.16とBTC 0.0002を約3,981円で購入した。約定待ちの時間が運用上のストレスになったため、価格モードはmakerからtakerへ切り替えた。この変更は「有利な価格を予想する」ためではなく、約定待ちという別の失敗要因を減らすためのものだった。手数料や約定価格は結果に影響するので、固定額だけを見て成功と判断しない必要がある。
| 設計対象 | 採用した考え方 | 避けたこと |
|---|---|---|
| 金額 | 月3,000円を上限として扱う | 価格予想による増額 |
| 数量 | APIの最小数量・刻みを使う | 固定値の永続化 |
| 残額 | BTCの0.00001刻みで吸収 | 端数の放置 |
| 検証 | dry-runとpytest 17件 | 本番注文だけで確認 |
| 公開 | コードだけをpublicテンプレートへ移す | 購入履歴を含む運用リポジトリの公開 |
これで解決できること、できないこと
この設計で解決できるのは、毎月の注文判断を忘れること、数量刻みの計算を都度やり直すこと、注文前の条件確認が人によって揺れることだ。状態を残せば、途中で停止した場合の再開条件も整理できる。
一方、価格下落、約定価格、取引所障害、API仕様変更、資産価値の損失は解決できない。積立botは予測機ではなく、決めた資金を決めた条件で使う自動化である。生活資金を使わない、上限額を先に決める、実注文の前にdry-runを通す、といったガードレールが設計の一部になる。
やってみてわかったこと
少額の積立でも、難所は「何を買うか」より、取引条件と状態遷移を曖昧にしないことだった。APIから条件を取り、数量を丸め、残額を処理し、実行結果を記録する。これらを一つの巨大なスクリプトに詰め込まず、状態として区切ることで、dry-runと本番の差を小さくできる。
自動化の成果を測るなら、価格の当たり外れではなく、想定した入力に対して同じ安全な停止条件で動いたかを見るべきだ。今回の実装は、投資判断を自動化したのではなく、決めた範囲からはみ出さない注文手順を自動化した。
更新履歴
- 2026-09-24: 初稿。Phase 1〜4の実装内容と初回運用結果を整理。
訂正履歴
- なし。