moomoo証券の口座開設からAPI発注ダッシュボードまで1日で作った話

こんにちは。

アールグレイです。

今回は、moomoo証券の口座を開設して、API経由で発注できる環境をUbuntu上に作った話です。

きっかけは、moomoo証券がAPI経由の米国株取引に対応していると知ったことでした。

それなら、株式取引の環境も、バイブコーディングで自分なりに作れるのではないか。

そう思ったのが、今回moomoo証券の口座を開こうと思った一番の理由です。

米国株のリアルタイムデータ取得やAPI経由の発注、自動売買、高度な分析ができます。

具体的には、Moomoo APIはOpenDとAPI SDKで構成されています。

OpenDはローカルPCやクラウド上で動くゲートウェイで、PythonなどのSDKからそこへ接続して、相場情報の取得や取引APIを使う形です。

つまり、自分のPCからAPIで米国株の情報を取り、必要なら注文までつなげられるということです。

ここが、自分にはかなり面白く見えました。

標準の取引アプリをそのまま使うだけではなく、自分の見たい銘柄、自分の見たいチャート、自分の注文フロー、自分のログ確認画面を作れるかもしれない。

さらに、AIに指示しながらフロントやサーバーを作れば、非エンジニア寄りの自分でも、自分専用の株式取引環境に近づけるかもしれない。

もちろん、最初から大きな自動売買システムを作ろうとしたわけではないです。

まずは、自分のPCからAPIで口座情報を見られること。
チャートを見られること。
ウォッチリストを管理できること。
そして、必要なときにAPI経由で発注できること。

このあたりを、自分で確認できるローカル環境として作ってみました。

結果として、口座開設からAPI発注できる仕組みの構築まで、ほぼ1日で一通り動くところまで持っていけました。

口座開設は思ったより早かった

最初にやったのは、moomoo証券の口座開設です。

証券口座なので、もっと時間がかかるかと思っていました。

本人確認や初期設定で数日待つくらいの感覚でいたのですが、実際には1日で使える状態まで進みました。

ここがまず大きかったです。

API取引の仕組みを触りたいと思っても、口座や取引環境の準備で止まると、その時点で熱が冷めますよね。

今回は、口座開設から実際にAPI接続を試すところまで同じ日に進められたので、かなりテンポよく検証できました。

ただ、証券口座なので、ここは人によって状況が違うと思います。

審査や本人確認の進み方は、そのときの条件にもよるかなと思います。

UbuntuにOpenDを入れてAPI接続する

moomoo証券のAPIを使うには、OpenDというローカルのゲートウェイを動かす必要があります。

ざっくり言うと、PC上でOpenDを起動して、そこにPythonなどから接続します。

ブラウザだけで完結する取引画面とは少し違って、ローカルPCにAPI接続用の入口を置く感じです。

今回はUbuntu環境で構築しました。

OpenDを起動する。
Python SDKから接続する。
口座情報を取得する。
保有ポジションを見る。
注文一覧を見る。
銘柄のスナップショットを取る。
ヒストリカルデータを取得する。

このあたりは、すべてCodexに指示して確認と実装を進めてもらいました。

今回は普段バイブコーディングで使っているClaude Codeではなく、Codexで試してみたかったのでCodexでやってみました。

自分はブラウザやログを見ながら、「次に何を見たいか」「どこが使いにくいか」を伝えるだけです。

流れとしては、やりたいことを伝えて、Codexにローカルの状態を見てもらいながら、必要なPythonサーバーやフロントを作ってもらう形です。

「OpenDにつながっているか確認して」
「口座情報を表示できるようにして」
「発注APIを叩けるようにして」
「ただし実弾発注は確認文字列を入れないと動かないようにして」

こういう指示を出しながら、少しずつ形にしていきました。

最初のフロントは、使えるけれど使いにくかった

最初に作ったフロントは、本当に最小限でした。

APIが生きているか。
口座情報が取れるか。
銘柄コードを入れて株価を取れるか。
発注フォームからAPIを呼べるか。

この確認だけなら、最小限のHTMLでも十分です。

でも、実際に触り始めると、すぐに不満が出てきました。

銘柄を毎回手で入力するのが面倒。
ウォッチリストが保存されない。
チャートがないので判断しにくい。
注文画面と銘柄確認が行ったり来たりになる。
ログや口座情報も同じ画面に混ざると見づらい。

APIが使えることと、日常的に使えることは別なんですよね。

ここは、AI動画制作の仕組みを作っているときに感じたこととかなり近いです。
「動く」と「使い続けられる」は違います。

だから、途中から重きを置く場所を変えました。

moomoo証券の標準画面を置き換えるというより、自分が使いやすいローカルダッシュボードにする。
APIで取れる情報や発注機能を、自分が見やすく、操作しやすい形に並べ直す。
そう考えることにしました。

自分専用のローカルダッシュボードにした

最終的には、ローカルブラウザで開く自分専用のダッシュボードにしました。

左側にメニューを置いて、画面を分けています。

Watchlist。
Order。
Account。
Log。

ウォッチリストでは、登録した銘柄を一覧で見られます。
銘柄検索から追加できます。
お気に入りのリストは保存できます。
削除ボタンも付けました。

例えば、最初は銘柄コードを直接入力する欄が見えていましたが、これは邪魔だったので隠しました。

自分が普段触るのは、検索とお気に入りリストで十分です。

見た目で大きな変更は、チャートはTradingViewのLightweight Chartsを入れました。

ウォッチリスト画面では、登録銘柄のチャートを3列で並べて見られるようにしました。
日足、週足、月足、60分足、15分足、5分足、1分足を選べて、表示中のチャート全体に反映されます。

注文画面では、現在のチャートと注文フォームを横に並べました。
ウォッチリストの銘柄をクリックすると、その銘柄のチャートを注文画面に表示できます。

これだけで、かなり触りやすくなりました。

単にAPIを叩く画面ではなく、自分が見る順番に合わせた画面になってきた感じがあります。

口座情報もJSONではなく見やすくした

Account画面も、最初はAPIの戻り値をそのままJSONで表示されていました。

口座ID、取引環境、口座種別、資金、建玉、注文状態。

こういう情報を毎回JSONの中から探すのは、やはり使いにくいです。

そこで、Account画面も作り直しました。

口座はカード形式。
資金は総資産、現金、購買力、出金可能額などをカードで表示。
さらにJPYやUSDなどの通貨別資金は表で見られるようにしました。

建玉は、銘柄、数量、取得単価、現在値、評価損益を表で確認できます。
注文は、銘柄、売買、注文状態、数量、価格、注文ID、エラーメッセージを一覧で見られるようにしました。

この変更で、Account画面は「APIレスポンスを見る場所」から「口座状況を確認する場所」に少し近づきました。

こういう細かい表示の変更は、最初から仕様として決めるより、実際に触ってから直した方が分かりやすいです。

JSONのままだと使いにくい。

でも、全部をデザインしすぎる必要もない。

必要な情報を、必要な形に整える。

自分専用のローカルダッシュボードでは、このくらいの地味な調整がかなり効いてきます。

チャートとウォッチリストは自動更新にした

チャートも、最初は手動更新でした。

ただ、相場を見る画面で毎回更新ボタンを押すのは、やはり面倒です。

そこで、15秒ごとのポーリングを入れました。
注文画面の大きいチャートも、ウォッチリストのミニチャートも、自動更新をデフォルトにしています。

ただし、ブラウザのタブが非表示のときは更新を止めるようにしました。
PCに無駄な負荷をかけないためです。

15秒ポーリングくらいなら、自宅PCで使うローカルダッシュボードとしては十分軽いと思っています。
もちろん、本格的な高頻度取引をするなら全然別の設計が必要です。

でも、自分が銘柄を見ながら発注判断をする補助ツールとしては、このくらいがちょうどよさそうです。

自動起動も入れた

ローカルツールで地味に大事なのが、自動起動です。

PCを再起動するたびに、毎回ターミナルを開いてOpenDを起動し、ダッシュボードを起動するのは面倒です。

そこで、Ubuntuのsystemdユーザーサービスとして、OpenDとダッシュボードを起動できるようにしました。

PCを再起動しても、ローカルのダッシュボードが戻ってくる。
ブラウザでを開けばすぐに見られる。

この状態まで持っていくと、実験用ツールから日常的に触れる道具に少し近づきます。

AIエージェントやローカルツールは、作った瞬間よりも、次の日にまた自然に使えるかが大事だと思っています。

自動起動は地味ですが、かなり便利です。

Codexに作ってもらうと、開発の粒度が変わる

今回おもしろかったのは、ほとんどの実装をCodexに指示しながら進めたことです。

自分は「こうしたい」と伝える。

Codexがローカルのファイルを見て、PythonサーバーやJavaScriptやCSSを直す。

こちらはブラウザで確認して、また追加の要望を出す。

この繰り返しです。

人間が最初から完成形を設計するというより、触りながら違和感を見つけて、そこをCodexに直してもらう感じです。

特にフロント画面は、作ってみないと分からないことが多いです。

どこに注文画面があると見やすいか。
ウォッチリストとチャートを同じ画面に出した方がいいか。
銘柄入力欄は本当に必要か。
タグはどこに出すべきか。

こういう細かいUIの違和感を、その場で直せるのは大きいです。

取引APIは、便利だからこそ慎重に扱う

API経由で発注できるようになると、急にできることが増えます。

自動売買もできます。
シグナルに応じた発注もできます。
ポジション管理もできます。
ログを残すこともできます。

ただ、ここはかなり慎重に扱うべきだと思っています。

ブラウザでボタンを押して注文するのと違って、APIは一度仕組みを作ると、プログラムから注文が出せます。
便利ですが、間違えると危ないです。

なので、今回のダッシュボードでは実弾発注に確認文字列を入れました。
意図せず注文が出ないようにするためです。

また、自動売買の前に、まずは人間が見るための環境を整えました。

チャートを見る。
ウォッチリストを見る。
口座情報を見る。
注文内容を確認する。
それから発注する。

この順番を崩さないことが大事だと思っています。

API取引は、自分専用の道具づくりに向いている

今回やってみて感じたのは、API取引は単に「自動売買のためのもの」ではないということです。

むしろ、自分専用の取引環境を作れるところに価値があります。

標準の取引画面は、どうしても多くの人向けに作られています。
機能は多いですが、自分が見たい順番とは違うこともあります。

自分の場合は、まずウォッチリストを見たい。
チャートを並べたい。
気になった銘柄をクリックして注文画面に移りたい。
量子や核融合やAIインフラのようなテーマ別タグも見たい。
ログや口座情報は別画面で確認したい。

こういう好みは、人によってかなり違うはずです。

APIがあると、その好みに合わせてフロントを作れます。

もちろん、証券取引なので安全性は最優先です。
でも、ローカルで小さく作って、自分の使い方に合わせて育てていくという意味では、かなり相性がいいと感じました。

まずは「自分が確認しやすい環境」を作る

最終的にできたものは、まだ完成形ではありません。

でも、口座開設から1日でここまで来られたのは、かなり大きいです。

moomoo証券のAPIに接続する。
UbuntuでOpenDを動かす。
Pythonのローカルサーバーを立てる。
TradingView Lightweight Chartsでチャートを出す。
ウォッチリストを保存する。
銘柄検索を付ける。
注文画面を分ける。
タグを付ける。
PC再起動後も戻ってくるようにする。

これをCodexに指示しながら組み上げていくと、思ったより現実的に進みました。

大事なのは、いきなり完全自動売買を目指さないことだと思います。

まずは、自分が確認しやすい環境を作る。
どの情報を見て判断したいのかを整理する。
誤発注しないように安全装置を入れる。
ログを残す。
使いにくいところを直す。

この順番で進める方が、自分には合っていそうです。

AIにコードを書いてもらいながら、証券APIを自分用の道具にしていく。

今回は、その最初の一歩としてかなり面白い構築になりました。

しばらくは、このダッシュボードを使いながら、自分の投資スタイルに合った取引環境にできるかを試していこうと思います。

Substack始めました。
よかったらフォローしてくださいね。