AI株式投資ツールをモノレポで自作した理由｜要件定義からバックエンド実装まで

※本記事はプロモーションを含みます。

※本記事は情報提供を目的としており、特定の金融商品への勧誘や投資助言を目的とするものではありません。投資判断はご自身の判断と責任で行ってください。

AIにコードを書いてもらうとき、私は最初から「とりあえず実装して」とは頼まないようにしています。

今回作ったのは、株式投資の判断材料を整理するための自作ツールです。

既存の投資ツールでは、自分が試したい買い判定ロジックをそのまま組み込むことが難しく、追加したい機能にも不足がありました。近いことを実現しようとすると費用もかかるため、AIコーディングエージェントを使って自作できないか試すことにしました。

ただし、AIに任せたかったのは、投資判断そのものではありません。

私が決めた要件やルールをAIに整理してもらい、実装できる形へ落とし込むことが目的です。最終的に投資するかどうかは、ツールに表示された情報を見たうえで私が判断します。

この記事では、自作を決めた理由から、要件定義、私なりのモノレポ構成、バックエンド実装までをまとめます。

フロントエンドの実装やUIエラーの修正については、続きの記事で分けて整理します。

既存ツールでは自分の買い判定を作りにくかった

最初に感じていた不満は、既存の投資ツールでは「自分が試したい買い判定」をそのまま作りにくいことでした。

チャートを表示したり、銘柄情報を確認したりできるツールはあります。

ただ、私がやりたかったのは、移動平均線、出来高、Pivot、候補銘柄の管理、バックテスト結果などを、自分の投資ルールに合わせて一つの流れで確認することでした。

将来的には、条件に合う銘柄が見つかったときにGmailへ自動通知したり、バックテスト結果と候補銘柄の管理をつなげたりしたいとも考えていました。

既存ツールで近いことをしようとすると、費用がかかったり、細かなロジックを自分で変更できなかったりします。

実は以前にも、自分でアルゴリズムを組み、買い判定を自動化するツールを作ろうとしたことがあります。

しかし、そのときは実装に時間がかかりすぎて、途中で止まってしまいました。

そこで、Claude Codeのようなコーディングエージェントが使えるようになったタイミングで、もう一度挑戦することにしました。

私がやりたいことを言葉にして、AIに設計と実装へ落としてもらえば、以前より先へ進めるのではないかと考えたからです。

もちろん、自作ツールを作れば投資成果が出るという話ではありません。

私にとってこのツールは、買う銘柄を決める機械ではなく、判断に必要な材料を毎回同じ順番で確認するための道具です。

要件定義は「言語化してから実装する」順番にした

AIにツール開発を頼むとき、私が怖いと感じていたのは、「それっぽく動いているけれど、自分の意図とは違うもの」ができることでした。

「株式投資ツールを作って」と丸投げしても、AIは何かしらのコードを作ってくれます。

しかし、どの銘柄を対象にするのか、どの指標を確認するのか、候補銘柄と保有銘柄を分けるのか、判断理由を残すのかといった前提が曖昧なままだと、あとから修正する量が増えてしまいます。

そのため、今回は次の順番で進めました。

• 自分の意図を、できる限り言葉にする
• 言語化した内容をAIに整理してもらう
• 整理した内容を要件書に落とし込む
• 要件書を自分で確認する
• 内容を確認してから実装へ進む

先にこの手順を決めたことで、AIへ任せる範囲がかなり分かりやすくなりました。

AIには、要件の整理、要件書への変換、実装作業の分割、コードの作成を任せます。

一方で、何を投資ルールとして採用するのか、どの情報が表示されなければ自分で判断できないのかは、私が確認します。

要件定義は、AIの行動を細かく縛るための作業ではありません。

実際に進めてみると、AIが自分で次の作業を判断しやすいように、進む道を整える作業に近いと感じました。

前提や完了条件が整理されていれば、私が関数名やクラス構造まで指定しなくても、AIは必要な作業を分けて進められます。

AI株式投資ツールの開発全体については、次の記事にまとめています。

AI株式投資ツール開発まとめ｜設計・実装・エラー修正・改善ログの全体像

この記事では、その中でも「なぜ設計から始めたのか」と「バックエンドをどこまでAIに任せたのか」に絞って整理します。

私にとってのモノレポはAIへ文脈を渡すための構成

今回の記事で使っている「モノレポ」は、一般的な意味でのモノレポとは少し異なります。

一般的には、複数のプロジェクトやパッケージを一つのリポジトリで管理する構成を指します。

一方、今回私が重視したのは、一つのプロジェクトに関するファイルを一つのフォルダへ集め、AIが要件、仕様、フロントエンド、バックエンド、設定をまとめて読めるようにすることでした。

一つのプロジェクトを一つのフォルダにまとめる、私なりの使い方です。

AIに作業を任せるとき、情報がいくつもの場所に散らばっていると、必要な前提を取りこぼす可能性があります。

例えば、バックエンドのAPIだけを見ていても、画面側でどの情報が必要なのかは分かりにくいです。

反対に、フロントエンドだけを見ても、データの取得方法や保存方法までは分かりません。

そこで、役割ごとに分けながら、同じプロジェクトフォルダの中で管理する構成にしました。

• packages/domain：売買条件や判定ロジックの中心
• packages/data：株価データや銘柄情報の取得
• packages/app_api：APIとして画面へ返す実行部分
• packages/app_cli：コマンドラインで確認やスキャンを動かす部分
• docs：仕様書、前提、判断メモ
• configs：対象銘柄や設定値の管理

さらに、CLAUDE.mdに開発時のルールを記載しました。

AIへ毎回同じ前提を説明し直すのではなく、「このプロジェクトでは、どの順番で確認して進めるか」を最初から共有するためです。

モノレポという言葉だけを見ると、コードを管理するための技術的な構成に見えるかもしれません。

しかし、今回の私にとっては、コードの管理以上に、AIへプロジェクト全体の文脈を渡すための構成でした。

バックエンド実装は要件を渡したあとAI主導で進んだ

要件とフォルダ構成を決めたあとは、バックエンドの実装をかなりAI主導で進めました。

私が関数名やクラス構造を細かく指定したわけではありません。

AIへ渡したのは、「このツールで何ができる必要があるか」という機能要件です。

具体的には、次のような内容を伝えました。

• 銘柄コードを入力すると株価を表示できる
• 日足データから週足・月足を作れる
• 25日移動平均線と75日移動平均線の位置関係を確認できる
• 複数銘柄をまとめてスキャンできる
• 候補になった理由をあとから確認できる
• スキャン結果を保存し、履歴として見返せる

これらの要件をもとに、AIは既存のコードを読み、必要な作業をTodoとして整理し、実装単位に分けて進めました。

バックエンドでは、日足データから週足・月足を集計する処理、yfinanceを使った株価や銘柄情報の取得、チャートデータAPI、銘柄情報API、ウォッチリストAPI、スキャン結果の保存や履歴取得APIなどが実装されました。

静的チェックやテストについても、ruffやpytestを使って確認する流れになりました。

対象銘柄の設定ファイルは、prime.yaml、topix500.yaml、symbols_watchlist.yamlのように、優先順位を付けて読み込む形へ変更しています。

AIに任せられたのは、単にコードを書く部分だけではありません。

要件を読み、必要な機能へ分解し、実装する順番を整理するところまで含まれていました。

これは、以前に私一人で作ろうとして途中で止まったときとの大きな違いでした。

AIが実装しても人間側の動作確認は残る

AI主導で実装が進んだからといって、私は何も確認しなくてよかったわけではありません。

実装後にAPIを実行すると、500エラーが発生したこともあります。

原因は、yfinanceから取得したSeriesを、そのままfloatへ変換しようとしていた部分でした。

私はエラーの症状をAIへ渡し、該当部分を確認して修正してもらいました。

このときに感じたのは、AIはコードベースを読み、自分で原因を調べて修正するところまでかなり進められるということです。

一方で、実際に機能を動かし、想定した結果になっているかを確認し、エラーの症状を返す役割は人間側に残ります。

コードが存在することと、自分が求めている動作をしていることは同じではありません。

AIが実装したあとに、私が使って確認する。この往復が必要でした。

投資ルールそのものはAIへ決めさせなかった

このツールの開発で、特に線引きしたのが投資ルールです。

AIに売買条件を相談すると、MACD、RSI、ADX、ボリンジャーバンドなど、さまざまな指標の候補が出てきます。

条件を増やすほど、ツールは高度で賢そうに見えます。

しかし私は、すべてを入れると、自分で判断の仕組みを理解できなくなると感じました。

自分で理解できない条件が増えると、候補銘柄が表示されたときに、「なぜ候補になったのか」を説明できません。

そこで、売買パターンは一つに絞り、カップウィズハンドルを中心にしました。

開発の途中では、AIに「現在の実装は、カップウィズハンドルの形そのものを判定しているのか」と確認しました。

その結果、当時の実装は厳密な形状認識ではなく、Pivotの上抜けや出来高など、ブレイク条件を中心に判定していることが分かりました。

この確認は重要でした。

AIが実装したものをそのまま正しいと思うのではなく、自分が何を判定していると思っているのかを言葉にし、実際の実装と一致しているかを確かめたからです。

資金管理については、公開できる範囲として次のルールを設定しています。

• 損切りライン：マイナス12%
• 1回の最大損失：資金の2%
• 月間停止ライン：マイナス10%
• 同時保有：3〜4銘柄
• 現金比率：30〜40%

一方で、カップウィズハンドルの形状判定に使う具体的なしきい値や、出口条件の細かな日数・値幅は公開しません。

まだ検証中の売買ルールであり、具体的な数値まで示すと、そのまま再現できる形になりやすいためです。

また、バックテスト後の改修でも、私は複数の条件を同時に変更しないようにしました。

例えば、反発確認の方法を変更するときは、カップウィズハンドルの条件、市場フィルター、出口条件、ポジションサイズを同時に変えません。

いくつもの条件を一度に変えると、どの変更が結果へ影響したのか分からなくなるからです。

AIには実装を任せますが、どのルールを採用し、何を変更するかは人間側で確認しています。

対象銘柄を増やして初めて見えた問題もあった

最初のツールは、対象銘柄がかなり少ない状態から始まりました。

そこから18銘柄のウォッチリスト、TOPIX500向けの銘柄リスト、東証プライム全体の1,575銘柄へと、段階的に対象を広げています。

これは、最初から完成形として決めていた設計ではありません。

実際に使ってみて、「この銘柄数では対象が狭い」と感じたことがきっかけでした。

対象銘柄が少ない段階では、画面やAPIが動くかどうかを確認するだけでも十分でした。

しかし、実際の運用に近づけようとすると、候補銘柄が少ない、結果を読みづらい、スキャン結果を保存してあとから見返したいといった、別の問題が出てきました。

そこで、銘柄リストを設定ファイルによって切り替えられるようにし、スキャンの実行と結果の閲覧も分けていきました。

さらに、次のような流れも必要になりました。

• スキャン中の進捗を表示する
• スキャン結果を一覧で確認する
• 結果をバックエンドへ保存する
• 過去の結果を履歴画面で確認する
• 気になる銘柄のチャートへ移動する

これらは、最初に要件書を書いた時点ですべて見えていたわけではありません。

実際に使いながら、足りないものが分かってきました。

AIに開発を任せる場合でも、使ったときの違和感を返すのは人間側の仕事です。

AIはコードを修正できますが、「この対象数では、自分の判断材料として使いにくい」と感じるのは、実際にツールを使う側だからです。

バックエンドが動いてもツールはまだ完成ではなかった

バックエンドまで実装したことで、ツールはひとまず「動く土台」に近づきました。

ただし、バックエンドが動いたからといって、すぐに使いやすい道具になったわけではありません。

画面側を作って実際に使い始めると、株価が表示されない、チャートが崩れる、銘柄を切り替えても前の判定が残るといった問題が出てきました。

バックエンドのAPIが正しく動いていても、画面の状態管理やデータの受け渡しがずれていれば、利用者から見たツールは正しく動きません。

この続きは、フロントエンドの実装とUIエラー修正の記録として、次の記事に分けて整理しています。

AI株式投資ツールのフロントエンドとUIエラー修正で学んだこと

今回の開発を通じて、自作ツールは完成品を一度作って終わるものではないと感じました。

自分がやりたいことを言語化し、AIに整理と実装を任せる。できたものを人間が実際に使い、違和感やエラーを見つける。その内容を、もう一度AIへ返して修正してもらう。

この往復を続けることで、少しずつ自分の判断材料として使える形に近づいていきます。

AIへ丸投げするのではなく、AIが進みやすい前提を作り、結果を人間が確認する。

今回の要件定義からバックエンド実装までは、その進め方を試した開発ログになりました。