パソコンがない。それでも資産運用アプリを作りたかった【AI運用#3資産運用編②】

第３部　資産運用編

今回の記事で分かること

* なぜスロット設定判別ツール、電気計算ツールの次に
　投資ツールを作ろうと思ったのか
* 「予測するAI」ではなく「検証できる環境」を先に作った理由
* 現金（CASH_JPY）をポートフォリオの一部として扱う発想
* AIの出力を信じる前に、検証できる設計を作る重要性

5.投資への興味

投資を始めたのは2022年の夏だった。

オルカン、
S&P500、
NASDAQ、
金、
ハイイールド債ETF。

新NISAでよく見かけるようなラインナップを、
少しずつ積み立ててきた。

私の投資歴は約3年半。
旧NISAの最終年。

初めは投資信託という仕組みがわからず、
ビビって独身時代から貯めていた貯金の3万円を毎月オルカンに投資をしていた。

その一年間の中で
オルカンだけでなくS&P500、NASDAQ100、
日経平均インデックスファンドも含めて40万円程度投資した。

また、自分の投資スタイルは
毎月よりも一喜一憂せずに済む毎週、毎日の方がメンタル的に合っていることに気付き、
今もその方法で投資を続けている。

投資2年目には
現在の新NISAがスタートした。
新NISAでは
金やインド株式、半導体も積立の対象に含めた。

その年の投資額は年間120万円ほどになった。

現在、令和8年7月。
インドは元気はないが、全体的には積立評価額がプラスになっていた。

特別に長いわけではないが、
トランプ関税による一時的な暴落や、
円安からの円高、含み損も一通り経験した。

暴落に対する耐性やインデックス投資の考え方、
投資方法はYouTubeで見た動画から得ていた。

始めたきっかけはシンプルだった。

データで優位性を探すことが、
昔から好きだった。

パチスロ、競馬、期待値の計算。

しかしそれらを長く続けた結果、
残ったのは
「期待値があっても収支は安定しない。胴元の取り分がある以上、プラスにすること自体が困難」
という現実だった。

投資信託は違った。

仕事を続けながら、
毎日少しずつ、長く続ければ続ける程、
複利が仕事をして資産が徐々に増えていく実感がある。

私が月に自由に使えるお金は
おこづかいの5,000円しかない。

そのため、それ以上のお金を使うには、
独身時代に貯めていた貯金400万円を
ストレスなく投資で増やすことが、
自分の中では非常に重要だった。

積立投資は、
私にとって最も現実的な選択肢だった。

問題は、積立の「その先」だった。

積立の始め方は本やYouTubeで学べる。

しかし続けていくうちに、
別の問いが生まれてきた。

暴落時は何もしないべきか。

現金比率を増やすべきか。

金利や市場の状態は考慮すべきか。

YouTubeの専門家の意見は分かれた。

当時の私は、
「暴落でも積立を続けろ」
という一般的な考え方を理解していた。

しかし実際には、
暴落局面で現金をどれだけ残しておくべきなのか、あるいは逆に買い増すべきなのかについては、人によって答えがまったく違っていた。

また、独身の時に貯めていた貯金の80%は
投資信託に回していたが、残りの20%の現金を今後どう運用、活用していけば良いのか全くわからなかった。

これまで投資方法は、
何も考えずにひたすら同じ額を積み立てたり、
暴落が来たら投資額を増やす。
加熱気味だと感じたら投資額を減らす。

という感覚で投資するというスタイルだった。

これをAIを駆使してアプリ化しよう。

具体的には自分で過去の相場データを使って
自分で検証できる仕組みを作ろう。

そう考えたことが、
この投資ツール開発の出発点だった。

情報が多すぎると
何を信じればいいのか分からなくなる。

そして人間は、
相場が急落した瞬間に冷静ではいられない。

ニュースを見て不安になり、
SNSを見て焦る。

感情に流されないための仕組みが欲しいと
思うようになった。

「ツールを作ろう」と決めたのは、
スロットのツールがひと段落した頃だった。

スロットの設定判別ツールが動くようになって、
「自分が欲しいものは自分で作れる」
という感触が少しずつ体に馴染んでいた。

次に作るなら、
もっと日常に近いものがいい。

「感情ではなく、データを見て判断できる道具」を
作ろうと決めた。

ただし、
競馬予想ツールの失敗は忘れていなかった。

あの頃は「AIに予測させる」ことを
目的にしていた。

しかし実際には、
AIは予測の形を作るのが得意なだけで、
未来を知っているわけではない。

出力が整っているほど信じてしまう。

そして検証しなくなる。

だから今回は、
最初から「予測に頼らない設計」を
目標に置いた。

値上がりを当てるツールではない。

自分の資産配分を整理し、
リスクをコントロールし、
長期的に市場に居続けるための道具を作りたい。

どうせ作るなら、
長期運用しても壊れないものを作りたい。

その時の「壊れない」が
何を意味するのか、
正確には分かっていなかった。

暴落しても耐えられることなのか。
リターンが安定することなのか。
コードが保守しやすいことなのか。

どれも違うとは言えないし、
どれも正しいとも言えない。

曖昧な目標を抱えたまま、
AIとの対話を始めた。

「壊れないシステム」の定義が
何度も変わっていくことを、
この時点ではまだ知らなかった。

6.試せる環境、検証できる設計

どんな投資戦略が正しいのかは、
まだ分からなかった。

しかし一つだけ確かなことがあった。

戦略の良し悪しを判断するには、
「試せる環境」がなければ何も始まらない。

だから最初に作ることにしたのは、
投資ロジックそのものではなく、
バックテストエンジンだった。

過去のデータを使って
「もしこの戦略で運用していたら、
過去10年でどういう結果になっていたか」
を計算できる環境。

それが最初の目標だった。


Claudeに
「バックテストエンジンをReactで作りたい」
と伝えると、コードが出てきた。

画面を表示するReact。
状態を管理するZustand。
重い計算をUIスレッドから分離するWeb Worker。

この三つが組み合わさって、
バックテストが走る設計が整った。

実際の市場データがないと何も試せないので、
10年分・5資産の疑似データを
生成する仕組みを先に作った。

シードを固定した乱数で動く価格データ。

本物ではないが、設計を試すには十分だった。


同時に、
最初から引っかかっていた問いに
向き合うことにした。

現金をどう扱うのか、だ。

投資の話では、
どの銘柄を買うかに注目が集まりがちだ。

しかし実際の運用では
「何も買わない」という判断も、
同じくらい重要な意思決定だ。

そこで「CASH_JPY」という概念を
システムに明示的に組み込んだ。

価格は常に1。リターンは0。

当たり前のことに見えるが、
これをコードとして書き下すことには意味があった。

「現金もポートフォリオの一部である」
と定義することで、
初めて現金比率を設計の対象として
扱えるようになる。

市場の状態を判定する仕組みも作った。

BULL、NEUTRAL、BEAR。

三段階のレジーム判定だ。


「危険そうなら現金を増やす。
安全そうならリスクを取る。」

もちろん、
「本当にその判断で成績は良くなるのか」
は分からない。

だからこそ、
バックテストで検証できる設計を
先に作ることにした。

当時の考え方は、シンプルだった。

コンポーネントに分割して、
GitHubへ保存した。

その段階で、
静かに浮かんでくる問いがあった。

これは本当に動くのか。

コードはある。
設計も整えた。
ファイルも保存した。

しかしiPhone一台だけの環境では、
ローカルでコードを実行したことがない。
コンパイルしたこともない。
バックテストを一度も走らせたことがなかった。

画面上にモック表示が出ていても、
それがAIの用意したダミーデータ
によるものであることは自分でも分かっていた。

パソコンがあれば5分で確認できることが、
私には確認できなかった。

電気設備の工事でも、
配線を始める前に幹線の容量を計算し、
分電盤の位置を決め、接地を確保する。

焦って器具だけ付けようとすると、
後から全部やり直しになる。

この順番を守ることと、
工事が完成することは、まだ別の話だ。

設計図は描いた。

しかしそれが動くかどうかは、
まだ分からない。

その事実を抱えたまま、
次の問いに進むことにした。

結果だけ見ても、
なぜそうなったのか分からない、
ということだ。

バックテストを走らせると、
最終的な数字は出る。

過去10年でどのくらいのリターンになったか。
最大でどのくらい下がったか。

数字は出る。

しかし、途中で何が起きたのかが見えない。

あの下落局面で、システムはどう判断したのか。
BULLと判定したのか、BEARと判定したのか。
その時の現金比率はどのくらいだったのか。

全部ブラックボックスになっていた。

競馬予想ツールの失敗を思い出した。

あの時も、
AIが出力する数値が正しいかどうかを
検証できなかった。

検証できない出力を信じてしまったことが
問題だった。

投資ツールの設計でも同じことが起きていた。

計算結果が良くても、
なぜ良いのかが分からなければ、
それは検証できていないのと同じだ。

そこでポートフォリオの記録に、
レジーム情報や市場参加率の情報も
一緒に残すようにした。

どの時点で何を判断したのか、
後から追跡できるようにする。

UIにも現在の状態を表示するパネルを追加した。

この変更は表示機能の追加に見えて、
本質的には
「システムの思考を人間が
追跡できる設計への転換」
だった。

ブラックボックスの中を少し開けることで、
初めて「検証する」という行為が可能になる。



しばらく後に、
もう一度同じ問いが戻ってきた。

ポートフォリオの最終的な配分に至るまでに、
どの処理がどのくらい影響を与えたのか、
その内訳がまだ見えていなかった。

ある資産の保有比率が、
最終的には18%になっていた。

しかし途中の計算では25%だった。

リスク制御なのか。
現金比率の調整なのか。
それとも複数の処理が重なった結果なのか。

どの処理で18%になったのかが分からなかった。

どこで削られたのか。
どの制御で削られたのか。
それとも複数が重なったのか。

原因が分からなければ、
設計を改善できない。

そこで、
計算の途中経過を
すべて記録する仕組みを作ることにした。

各処理を通るたびに、
配分がどれだけ変化したかを保存する。

後から見返すと、
「どの処理が何%動かしたのか」
が分かるようになる。

これが後に
「帰属分析」
と呼ぶ仕組みだった。

計算の各段階を通るたびに、
配分がどのくらい変化したかを記録する。

どの処理で何%動いたかを積み上げると、
最終的な配分が
「どこで」「どのくらい」変化したのかが
見えるようになる。

出力を信じる前に、
その出力がどのように作られたのかを
追跡できる構造を持つ。

競馬では、
「AIが出した答え」を信じてしまった。

今回は逆だった。

AIがどうやってその答えを出したのかを、
人間が追跡できる仕組みを先に作る。

競馬予想の失敗から学んだことが、
ここで形を変えて活きていた。

ただし技術的な問題もあった。

帰属分析の仕組みは、
計算のたびに大量のデータを生成する。

10年分を一日ずつ計算する想定だ。

その全日数分の内訳を全部保存しようとすると、
データ量が膨大になる。

iPhoneのメモリには限界がある。

そこで、通常時はこのデータの生成を
スキップするように設計した。

調べたい時だけ有効にする。

必要な時だけ使える「観測の窓」を作る。

「観測する能力を持つことと、
常時観測することは違う。」

この発想は、この頃から
自分の中に根を張り始めた。

ただしこの段階では、
まだ「設計上でそうなっている」だけだった。

それが実際に機能するかどうかは、
まだ確かめられていなかった。

今回得られた設計思想

* 予測より検証
* 現金も設計対象にする
* ブラックボックスを作らない
* 結果だけでなく、判断の過程も記録する