#2 そもそもの環境問題——株の自動売買をするにあたって最初にそろえるべきもの
この記事は「vibe codingで日本株自動売買システムを作ってみた」という連載の一部です。
前回記事はこちら
3行まとめ
- 個人投資家がリアルタイムの株価を無料で取得できるAPIは選択肢がほぼ2つしかない
- kabuステーションAPIを選んだ理由と、その代償としてWindows PCが必要になった経緯
- Windows PCが届くまでの間はMacで開発を進め、届いてからWindows環境に移行した——その切り替えも含めると、環境構築には結果的に数週間かかった
コードを書く前に、まずそろえるべきものがあります。
自動売買システムを作るには証券会社のAPIが必要です。個人投資家がリアルタイムの株価データを無料で取得できるAPIは、実は選択肢がほとんどありません。現実的な候補は2つ。kabuステーションAPI（三菱UFJ eスマート証券）と立花証券e支店APIです。
APIをkabuステーションに決めた理由
kabuステーションAPIを選びました。理由は3つあります。
当初デイトレードを主戦場にしようとしていたこと。デイトレードでは売買回数が多くなるため、取引手数料が直接パフォーマンスに響きます。kabuステーションAPIはAPI経由の信用取引手数料が無料で、この点が決定的でした。ただし後述しますが、戦略を組み始めるうちにスイングや中長期も視野に入ることになり、この前提は割と早い段階で崩れます。
売買システム自体をローカルで構築する予定だったこと。どうせローカルで動かすなら、APIもローカルにまとまっていた方が遅延も少なく作りやすいと判断しました。kabuステーションAPIはローカルホスト経由でアクセスする設計なので、相性が良かった。ただし実際には、kabuステーション経由で証券取引所にリクエストを送る構造なので、遅延面ではあまり関係なかったかもしれません。
認証まで含めて無人化できると思っていたこと。当初は、認証メールアドレスに届くワンタイム認証コードを処理できれば、起動まで自動化できるのではないかと考えていました。一方、立花証券e支店APIは2025年7月26日以降、電話番号認証が必要です。私は電話認証を自動化する方法が思いつきませんでした。
※立花証券e支店APIは2026年5月16日（土）に公開鍵暗号化方式を利用した認証がリリースされたようです。タイミング… 認証方式の変更により、今後は立花証券も有力な選択肢になり得ます。
認証メールのコードを機械的に読み取る処理は、セキュリティリスクを理解したうえで、自己責任として実装しました。ただ、あとから調べてみると、この運用が許容されるかは公開情報だけでは確認できませんでした。執筆時点（2026年5月）では、kabuステーションもパスキー認証に対応しています。
比較表（参考）
| 項目 | kabuステーションAPI | 立花証券e支店API |
|---|---|---|
| 動作環境 | Windowsのみ | 環境問わず |
| APIスタイル | REST（ローカルホスト経由） | REST（インターネット経由） |
| 信用取引手数料 | API経由で無料 | 無料 |
| 信用買方金利（通常） | 制度信用 年2.98% / 一般信用（長期）年2.79% / デイトレード信用 年0% | 年2.50% |
| 認証 | ワンタイム認証コード / 認証アプリ / パスキー認証（kabuステーション対応） | 電話番号認証（2025年7月26日〜。2026年6月27日まではAPIログインでも必要）/公開鍵暗号化方式の秘密キー認証 |
| 参照URL | https://kabu.com/item/kabustation_api/default.html | https://www.e-shiten.jp/api/ |
そしてWindowsが必要だと気づく
さて、kabuステーションAPIを選んだはいいものの、重大な前提を見落としていました。
kabuステーションはWindowsのみの対応です。 公式サイトにも明記されています。
私の開発環境はMacです。
どこかのセッションでClaudeが「Windows環境が必要です」と言っていたかもしれません。ただセッションをまたぐと記憶が消えるし、私も見落としていた。いざkabuステーションをインストールしようとしたタイミングで、初めて動作環境を確認して発覚しました。
本業でプロジェクトを進める場合、動作環境の確認は設計の最初期にやります。個人開発だと「まず動かしてみよう」でいきがちですが、こういうところで詰まります。
解決策として中古のWindows PCを購入しました。力技(笑)
もともと開発していたMacBookは大学生の頃に購入し既にOSのサポート期限も切れてるような古いものだったので、どのみちPCを買い替えるつもりでした。いい機会です。
Windows PCを1台用意して、そこにkabuステーションをインストール。さらに、VPNにTailscale、リモートデスクトップに**Windows App（Microsoft Remote Desktop）**を使い、MacやiPad、iPhoneからもWindows PCにアクセスできるようにしました。これが、実運用へ進む前に組んだ構成です。
ひとつだけ誤算があって、私のMacはOSが古すぎてWindows Appをインストールできませんでした。そのため、Mac側だけRoyal TSXというmacOS向けのRDPクライアントを代わりに使っています。iPad・iPhoneはWindows Appで問題なく使用できます。
もう一つ、この構成が後で予想外の形で問題を起こします。リモートデスクトップ経由でWindowsに繋ぐと、ある条件でkabuステーションが止まってしまう。stagingもprodもkabuステーションを共有しているので、両方が道連れになる——その話は#5で書きます。
（余談）購入PCをClaudeに調査させてみた
PCの購入時にもClaudeのチャット版を使って推奨スペックのPCを調べましたが、確認した時点ですでに売り切れていてページだけ残っている商品や、メモリ高騰前の数年前の価格帯と思われる提案も含まれていました。これは過去の情報が残り続けるWebの性質も関係するでしょうが、LLMは時間の概念を扱うのが難しいのかもしれません。
次回
次回は、バックテストを動かして初めて見えた「動いている」と「正しい」は別物だった、という話を書きます。
損切り判定に使う価格や、サブ戦略で使える予算、更新したはずのファクターの読み込み。結果が出ているように見えても、前提や実装の経路がずれていれば数字は簡単に変わりました。
Claude Codeに実装を任せながら、どこを人間が確認しなければいけなかったかを整理します。
Discussion