※本記事はプロモーションを含みます。
※本記事は情報提供を目的としており、特定の金融商品への勧誘や投資助言を目的とするものではありません。投資判断はご自身の判断と責任で行ってください。
AIに株式投資ツールの実装を頼むと、コードはかなり前に進みます。
ただ、画面が表示されて、テストが通り、見た目が整ってきても、それだけで「実際に使える」とは限りませんでした。
私が操作してみると、株価が表示されない、銘柄を変えても前の判定が残る、チャートの大きさが合わないといった問題が出てきました。
今回の記事では、AI株式投資ツールのフロントエンド実装と、使いながら見つけたUIエラーの修正記録をまとめます。
技術的な原因調査やコード修正は、AI側でかなり進められました。一方で、調査のきっかけになったのは、私が実際に画面を操作して見つけた違和感です。
AIに実装を任せても、最後に使う人間の確認は残る。この開発で、あらためてそう感じました。
要件定義、モノレポ構成、バックエンド実装までの流れは、前の記事で整理しています。
AI株式投資ツールをモノレポで自作した理由｜要件定義からバックエンド実装まで
この記事では、その続きとして、画面を作ったあとに見えてきた詰まりを扱います。
フロントエンドは画面を作るだけではなかった
バックエンドの土台ができたあと、次に必要になったのは、実際に操作できる画面でした。
フロントエンドはVite、React、TypeScriptを使う構成です。テストにはVitestとjsdomを使い、画面部品の表示、フォーム操作、データ取得後の更新などを確認する形にしました。
ここで最初に詰まったのは、投資ロジックの計算ではありません。ブラウザ上の動きを再現するテスト環境でした。
jsdomの設定が足りない。必要なブラウザAPIが存在しない。フォーム操作のタイミングが合わない。非同期でデータを取得したあと、画面が更新される前にテストが判定してしまう。
バックエンドの関数テストと比べると、エラーの原因が一か所にまとまっていないため、何が足りないのか見えにくい状態でした。
「テストが落ちています」と伝えるだけでは、AIも修正箇所を絞りにくくなります。
どの操作を想定しているのか。操作後に何が表示されるべきなのか。どの状態になるまで待つ必要があるのか。そこまで伝えることで、設定や待機処理の修正が進みました。
この段階で感じたのは、フロントエンド開発は、単に画面の見た目を作る作業ではないということです。
状態管理、データ取得、描画のタイミング、テスト環境がつながって、ようやく画面として正しく動きます。
AIは不足している設定を調べ、テストコードや待機処理を直してくれました。ただし、どの動きが自然なのかを決めるには、実際に使う側の感覚も必要でした。
lightweight-charts v5でチャートが表示されない
投資ツールの画面で、特に目立つのが株価チャートです。
今回はlightweight-charts v5を使いましたが、チャート表示でもいくつか詰まりました。
既存の実装例を参考にしても、そのコードが別のバージョンを前提にしていることがあります。見た目には正しそうなコードでも、実際に入っているバージョンとAPIが合わず、チャートが表示されません。
今回も、Seriesを作るAPIの違い、Series名や型の不一致、描画時点で親要素のサイズが決まっていない問題、画面サイズの変更に追従しない問題が出ました。
私はブラウザで起きている症状やエラーログをAIに渡し、原因調査と修正を進めてもらいました。
AIはSeriesの作成方法を見直し、チャートサイズを自動調整する構成へ変更しています。私がAPI仕様を一つずつ調べて書き直したというより、実際の症状を共有し、AIに対象コードを追ってもらった形です。
ここでは、「lightweight-chartsの正しい書き方を調べて」だけでなく、「現在使っているv5を前提に確認して」と伝えることが重要でした。
バージョンを指定しないと、古いサンプルコードをもとに修正が進み、別のエラーにつながることがあるからです。
チャートは、線が一本表示されれば終わりではありません。
銘柄を変えたときにデータが切り替わるか。画面幅が変わっても崩れないか。データ取得に失敗したときに、何が起きたか分かるか。
コードを眺めるだけでは、このあたりの問題には気づきにくいです。画面を開き、銘柄を入力し、表示の変化を確認して、初めて分かることがありました。
銘柄を変えても前の判定が残っていた
見た目が整ってきたあと、かなり重要なバグが見つかりました。
銘柄を切り替えても、買いタイミングの判定が最初の銘柄のまま残ってしまう問題です。
これは、画面が崩れたり、目立つエラーメッセージが出たりする不具合ではありません。最初の銘柄を表示しただけでは、正常に動いているように見えます。
チャートも表示され、判定パネルにも結果が出ています。
しかし、別の銘柄に切り替えると、本来は変わるはずの判定だけが変わりませんでした。
原因は、画面の見た目ではなく、Reactの状態管理とデータ取得処理のつながりにありました。
初回表示だけで確認を終えていたら、この不具合は見逃していたと思います。実際に複数の銘柄を切り替え、チャートと判定結果が一緒に変わるかを見る必要がありました。
AIに症状を伝えると、表示部品だけでなく、状態管理のhookやデータ取得処理の依存関係まで確認し、修正を進めてくれました。
どの銘柄のデータを参照しているのか。銘柄が変わったとき、どの処理が再実行されるのか。前の判定結果をいつ消すのか。
こうした状態の流れをつなぎ直す必要がありました。
ここで学んだのは、UIの確認は「表示されたか」だけでは足りないということです。
銘柄を変えたら、チャートと判定の両方が変わるか。
一度エラーになったあと、別の銘柄でやり直せるか。
別の画面へ移動して戻ったとき、古い状態が残りすぎていないか。
こうした操作まで試さないと、「最初の一回だけ正しく見える画面」になってしまいます。
UIエラーを5つに分けて整理した
今回発生したUIエラーを振り返ると、大きく5つに分けられました。
- データ更新・状態管理：銘柄を変えても前のシグナルが残る、チャートと判定パネルで異なるデータを参照する
- チャート表示：lightweight-charts v5のAPI差分、Series名や型の不一致、描画時の要素サイズが決まっていない
- バックエンド接続：FastAPIが起動していないときの取得失敗、APIエラーの表示不足、バックエンド側のデータ変換による500エラー
- テスト環境：Vitestとjsdomの設定、フォーム入力テスト、非同期で画面が更新されるまでの待機
- 画面全体の停止：一部のコンポーネントでエラーが起きたとき、アプリ全体が白い画面になる可能性
こうして分けると、「AIがバグを直してくれた」という一言では足りないことが分かります。
エラーの種類によって、確認する場所が違うからです。
たとえば、バックエンドのデータ変換で500エラーが出ている場合、画面のコードだけを見ても原因は分かりません。バックエンドがどの形式でデータを返し、フロントエンドがどう受け取っているかを両方見る必要があります。
一方、一つの表示エラーで画面全体が止まる問題に対しては、Error Boundaryを追加し、一部でエラーが起きてもアプリ全体が止まりにくい構成へ変更しました。
投資判断の材料を確認する画面で、一部の表示失敗によって全体が操作できなくなると、確認作業そのものが止まってしまいます。
UIエラーは、見た目の問題だけではありません。
状態、データ、接続、テスト、エラー後に操作を続けられるかという問題に分けると、修正箇所を整理しやすくなりました。
AIに個人開発を頼むときも、完成画面を一度眺めるだけではなく、操作の流れを決めて確認した方がよさそうです。
最初に表示する。値を変える。意図的に失敗させる。戻る。もう一度実行する。
ここまで試すと、AIに伝える修正依頼も具体的になります。
AIが直せても、症状は人間が見つけていた
技術的な原因調査とコード修正は、かなりAI側で進められました。
厳密な作業台帳を付けていたわけではありませんが、感覚としては、原因の特定や修正方針の多くをAIが担っています。
ただし、AIが自動的にすべての問題を発見したわけではありません。
調査の起点になったのは、私が実際に操作して見つけた症状でした。
株価が表示されない。
銘柄を変えても買いタイミングの判定が変わらない。
実行すると500エラーが出る。
想定していた画面と違う。
こうした違和感を私が共有したあとに、AIがコードを読み、原因を探し、修正しています。
特に印象に残っているのは、「このツールは、カップウィズハンドルの形そのものを判定しているのか」と質問した場面です。
この質問をきっかけに、その時点の実装説明では、厳密な形状認識というよりも、Pivotの上抜けや出来高など、ブレイク時の条件を中心に判定していることが分かりました。
画面に「カップウィズハンドル」と表示されていても、内部で自分の想定どおりの判定をしているとは限りません。
表示された結果をそのまま信じず、「内部では何を見ているのか」を確認する必要がありました。
AIにデバッグを頼むときは、次の内容を分けて渡すと進みやすくなりました。
- どの操作をしたか
- 本来どうなるはずだったか
- 実際にはどうなったか
- 同じ問題を再現する手順
単に「動きません」と伝えるよりも、「銘柄Aから銘柄Bへ切り替えたとき、チャートは変わるが判定だけがAのまま残る」と伝えた方が、AIも原因に近づきやすくなります。
AIは広い範囲のコードを読み、修正案を出し、テストを実行できます。
ただ、実際の使い心地や、投資判断の確認画面として気持ち悪い挙動は、使う本人が見つけないと残りやすいです。
AIに任せる範囲が広がるほど、人間側の操作確認はむしろ重要になると感じています。
実装できたことと、効果を確認できたことは別だった
このツールは、一度完成して終わったものではありません。
銘柄変更時のシグナル更新、チャートが表示されない問題、画面サイズへの追従、APIエラー時の表示、履歴画面、チャート上の判断根拠、保有銘柄と候補銘柄の管理など、使うたびに直したいところが出てきました。
すでに修正したものもあれば、今後の改善項目として残っているものもあります。
バックテストの結果を受けて、判定条件の見直しも進めています。
ただし、出口条件の短期化について確認できているのは、実装してテストが通ったところまでです。
変更前と変更後を比較し、成績が改善したことを確認したわけではありません。そのため、ここでは「改善した」とは書けません。
AIがコードを変更できたことと、その変更が投資ルールとして有効だったことは別です。
テストが通っても、プログラムが想定どおり動くことを確認できただけです。投資判断に使える変更かどうかは、別途バックテストや運用結果を見て判断する必要があります。
私がこの開発ログで残したいのは、「AIに作らせれば一気に完成する」という話ではありません。
AIによって実装や原因調査の速度は上がりました。
一方で、実際に使って見つける違和感、内部の判定内容を確認する作業、変更を採用するかどうかの判断は、人間側に残っています。
シリーズ全体を読みたい場合は、開発まとめ記事から入ると流れを追いやすいです。
AI株式投資ツール開発まとめ｜設計・実装・エラー修正・改善ログの全体像
AIコーディングは、コードのことを何も考えなくてよくなる魔法ではありません。
自分の困りごとを伝え、AIに実装してもらい、実際に動かして、おかしなところを返す。
原因調査や修正はAIにかなり任せられても、何を正しい状態とするのかは、人間が確認する必要があります。
投資判断についても同じです。ツールやAIの判定をそのまま採用するのではなく、最終的には私自身が根拠を確認して判断します。
この往復を続けながら、もう少し実際に使える道具へ近づけていきます。
AIに任せる前に、最低限の仕組みや使い方を動画で確認したい人は、Udemyで「生成AI」「ChatGPT」「Python」「AI活用」などの入門講座を探してみるのも一つです。講座を選ぶときは、レベル、更新日、レビュー、価格を自分の目的に合わせて確認してください。
