クラウドに任せられない処理だけ、家のMacに残した【スマホで周回！#18】

こんにちは、スマホ投資パパです。

以前、口座のスクショをAIに読ませて、保有銘柄のファイルを直す方法を書きました。

▶ 参考（第11回）：自動化できない手作業をスクショとAIで簡単にした方法

あれはあれで、スマホ完結の現実解でした。今でも悪くない方法だと思っています。

ただ、あのとき私は、はっきり一つ諦めていました。

証券口座と直接つながって保有データを取ってくる自動化は、いったん見送った んです。口座の窓口プログラムを動かすための別マシンが要る。それがスマホだけで回す運用と噛み合わなかったからでした。

今回は、その諦めを、ちょっと前にソフマップで買った中古のMac1台で越えた話です。

この記事は、銘柄を当てる話ではありません。
手元の保有データを「スクショと推測」から「口座の事実」に変えるために、処理を家のMacとクラウドでどう分けたか、という設計の話です。
前回（第17回）の通知設計の、さらに一段手前にあたる回です。

ちょっと前まで、私はスクショで保有を直していた

第11回でやっていたのは、こういう流れでした。

moomooの口座画面をスクショする。AIに読み取らせる。更新用の指示文を作らせる。それをコーディングエージェントに投げて、手元の3つのファイルを直す。

手入力よりずっと安全で、1〜2分で終わる。実際、しばらくはこれで回していました。

ただ、私は毎朝、子どもの送りをしています。バタバタの朝に、証券アプリを開いてスクショを撮り、AIに読ませ、出てきた指示を確認して流す。時間そのものは大したことなくても、朝の限られた気力を、地味に削られる作業でした。

正直に言えば、これは私が大事にしている「スマホだけで完結させる」という線にも、少しだけ反していました。毎朝、手作業の儀式が1つ残っている。今回の改善は、この朝の一手間を消すためのものでもあります。

そして、問題は面倒くささだけではありませんでした。

売買した翌朝は、結局この作業が要ります。持ち値は、最後はスクショの数字頼み。そして一番やっかいだったのが、「いくらで買ったか」を正確には記録していなかったこと です。

「増えた日の始値」で、持ち値を推測していた

私は、持ち値を「保有数が増えた日の、その銘柄の始値」で推測していました。

その日の朝の値段で買ったことにする。ざっくりですが、当時はこれで十分だと思っていました。

でも、実際に使ってみると、これがけっこうズレます。

始値で買えるとは限りません。少し高いところで約定していれば、実際の持ち値はもっと上です。持ち値がズレれば、そこから計算する含み損益も全部ズレます。

さらにまずいのが、同じ銘柄を同じ日に2回に分けて買ったときです。推測ロジックには「その日は1回」としか見えず、2回の買いが1つに潰れて平均がおかしくなる。

これでは、保有の弱さを見るどころではありません。弱さを測る物差しそのものが、推測でできていた わけです。

全部クラウドに置ければ楽なのに、置けない一点があった

私の観測システムは、基本はクラウド（GitHub Actions）の上で回っています。

決まった時間に自動で起動して、データを集めて、観測して、Slackに投げる。ここまでは私が寝ていても勝手に進みます。スマホしか持っていなくても回るのは、判断以外の処理をクラウドに寄せているからです。

だったら、保有データの取得もクラウドに置けばいい。最初はそう考えていました。

でも、越えられない壁がありました。

証券口座とつながる窓口だけは、クラウドに置けなかった んです。

私が使っている口座は、やり取りのために、手元の端末で専用の窓口プログラム（常駐アプリ）を立ち上げ、そこにログインしておく必要があります。これは、都合のいいクラウドのサーバーからは触れません。自分の手元の端末でしか成立しない。

処理のほとんどはクラウドに置けるのに、「口座に問い合わせる」その一点だけは、家に残すしかなかった。

この窓口（OpenD）そのものの入れ方や、moomoo証券の情報を取得するまでの具体的な手順は、私が書くより分かりやすい記事があります。手を動かして試したい方は、こちらが具体的です。

▶ 参考（外部・アールグレイさん）：moomoo証券の口座開設からAPI発注ダッシュボードまで1日で作った話

私の記事は、この窓口を「どう常駐させ、クラウドの処理とどう役割分担したか」という設計側に絞ります。

家のMacを、クラウドの“出張所”にした

ここが今回の肝です。

GitHub Actionsのジョブは、ふだんはGitHubが用意したクラウド上のマシン（毎回使い捨ての仮想マシン）の上で動きます。でも、「このジョブだけは、自分の家のMacで動かして」と指定できる仕組み があります。self-hosted runner、日本語で言えば自前の実行係です。

家のMacをGitHubに実行係として一度登録しておくと、クラウドの処理の流れの中で、特定のジョブだけを家のMacに降ろせるようになります。

ちなみに、この実行係はMac専用ではありません。self-hosted runnerは、WindowsでもLinuxでも動きます。家に常時起きているPCが一台あって、そこで口座の窓口プログラムが動くなら、それを実行係にできます。私はたまたま、ちょうどいい中古のMacを見つけたので、Macにしただけです。

私の使い方はこうです。

口座の窓口（OpenD）は、家のMacに常駐させておく。再起動しても勝手に立ち上がるようにしておく。そのうえで、「口座に問い合わせる」ジョブだけを、この家のMacに降ろす。 同じMacの上で走るから、そこにいる窓口に触れる。取れた保有・現金・約定を、手元の3ファイルに書き戻す。

それ以外は、いっさいMacに持たせません。Macの仕事は、口座に聞いて、結果をファイルに置くところまで。あとの観測も判断も、全部クラウドに戻します。

つまり、クラウドが本社、家のMacはその出張所。 といっても、出張所に置くのは「現場の窓口」ひとつだけです。

ここで一つ、誤解されやすい点を先に潰しておきます。

家のMacに移したのは、この一ジョブ「だけ」です。処理の中身も、Slackや口座につなぐための秘密の鍵（シークレット）も、これまで通り全部GitHubのリポジトリで一括管理しています。変わったのは、ジョブが実行される場所が、クラウドから一部だけ家のMacに移ったこと。それだけです。

私がMacの前に座って操作するわけでもありません。Macは、電源が入っていて窓口が常駐しているだけ。普段は放っておく置物です。

だから、私の運用はこれまで通りスマホ一本 です。むしろ、朝のスクショの儀式が丸ごと消えた分、こだわっていた「スマホだけで完結」に、一歩近づきました。

この“窓口ジョブ”には、地味だけど効く安全装置をいくつか付けました。

• 短い時間で必ず打ち切る。窓口が応答しないなら、だらだら待たずに終える。

• この3ファイルを書き換えるのは、この窓口ジョブ「だけ」に固定する。ほかの処理には絶対に書かせない。

• 送り出す直前に、クラウド側の最新を一度取り込んでから送る。別の変更とぶつかって押し合いにならないようにする。

• この書き戻しが、また別の処理を芋づるで呼び出さないよう、印を付けておく。ぐるぐる回り続ける事故を防ぐ。

本社と窓口は、直接つながない

役割を分けるうえで、一番こだわったのがここです。

本社と窓口を、直接つながないこと。 両者をつなぐのは、口頭の指示ではなく、1枚の報告書（保存データ）だけにしました。

窓口は、口座に聞いた結果を報告書として置く。本社は、その報告書を読んで先を進める。窓口の中で何が起きているかを、本社は知らなくていい。報告書さえ正しければいい。

エンジニアの言葉で言えば疎結合です。片方が中で作り替わっても、報告書の形さえ守れば、もう片方は動き続ける。

さらに、その報告書を書く担当を1つ（＝窓口ジョブ）に固定しました。書く人を絞ると、数字の出どころが常に1つに定まります。複数の処理が同じファイルを取り合って上書き合戦になる、という事故が消えました。

窓口が閉まっていても、ちゃんと気づけるように

役割を分けたことで、新しい心配も出ました。

窓口は家のMacです。電源が落ちていたり、ログインが切れていたら、窓口は開きません。開かなければ、本社は最新の報告書を受け取れない。しかも朝はスマホしか見ていないので、それに気づけない。

だから、窓口が時間内に開かなかったら、それ自体をSlackで知らせる見張り役 を別に置きました。中身の良し悪しではなく、「窓口が開いたかどうか」だけを見張る係です。これが鳴ったら、私はログインし直すだけでいい。

もう一つ、取れなかったときに止まらない仕組み も入れました。

実際の約定が取れた銘柄は、その事実を正とする。もし取れなければ、その分だけは従来の推測に自動で戻して、処理そのものは止めない。

全部が事実に置き換わるのが理想です。でも、たまに一部だけ取れないことはある。そこで全体が止まると、結局また手作業に逆戻りです。だから 「良くなるが、壊れない」 を優先しました。

役割を1つに絞ったら、壊れた場所が分かるようになった

一番の変化は、収益でも精度でもありませんでした。

壊れたときに、どこが壊れたかがすぐ分かるようになったこと です。

スクショ運用の頃は、通知がおかしいと「写し間違いか、推測ロジックか、観測処理か」を毎回いちから疑っていました。全部が一続きだったからです。

今は、窓口（Mac・口座への問い合わせ）と本社（クラウド・処理とジョブ管理）が、報告書1枚を挟んで分かれている。だから「報告書が古いのか」「本社の処理がおかしいのか」を先に切り分けられる。見張り役が黙っていれば、窓口は開いている、と当たりを付けられる。

役割を欲張らせないと、故障もシンプルになる。忙しい生活の中で何かを仕組み化するときの、いい教訓でした。

今の私の考え方

第11回で私は、口座APIの自動化を一度諦めました。別マシンが要る、スマホ完結と噛み合わない、と。

今回それを越えられたのは、高性能なマシンを新調したからではありません。ちょっと前にソフマップで買った中古のMac1台を、クラウドの出張所として登録し、任せる仕事を「口座の窓口」ただ一つに絞っただけです。

中古とはいえ、出費はゼロではありません。でも、保有の数字が正確になり、何より毎朝のスクショのストレスが消えました。私にとっては、いい買い物でした。

派手な機能ではありません。スクショをやめて、推測を事実に置き換えて、口座の窓口だけを家に残した。ほんとうに、それだけです。

でも、この地味な一段を踏んでから、私は自分の運用ログを、ようやく素直に信じられるようになりました。

これが、今の私の基本方針です。処理はできる限りクラウドに寄せる。どうしても手元にしか置けない一点だけを、家に残す。そして両者は、報告書1枚で疎につなぐ。

私の地味な周回プレイはまだまだ続けることができそうです。

あなたの手元のデータは、事実ですか。それとも、いつの間にか推測になっていませんか。

次回・第19回は、いよいよ「損切りより先に、保有を疑う仕組み」の話に入ります。今回そろえた“正しい保有の事実”が、その土台になります。

記事が少しでも役に立ったら、スキで教えてもらえると、次を書く励みになります。