AIに株式投資のツールの仕様書を書かせてみた

現在のモノレポ構成を前提に、株式投資用ツールの仕様設計を手伝ってください。

実装はまだ行わず、まずはプランモードとして、要件整理・仕様策定・ディレクトリ構成案・責務分割までを詳細に検討してください。

# 背景

私は現在のモノレポ構成をベースに開発を進めています。

このモノレポの中に、新しく日本株向けの株式投資ツールとしてアップデートしたいと思います。

今後、AIに精度高くコーディングしてもらうことを前提にしているため、曖昧なまま実装に進むのではなく、最初に仕様・責務・コンテキストを整理したいです。

# 作りたいもの

ベースラインとしては、フロント画面上で株式コードを入力すると、対象銘柄のロウソク足チャートを表示できるツールを作りたいです。

# 対象

・対象市場は日本株

・入力は株式コード

・チャートはロウソク足

・足種は日足、週足、月足を切り替え可能にしたい

# この段階でやってほしいこと

以下を、実装ではなく「仕様設計」として整理してください。

1. 要件定義

– このツールの目的

– 想定ユーザー

– ユーザーが最初にできること

– MVPとして必須の機能

– 将来的に拡張しやすいように分けるべき機能

2. 画面仕様

– 最低限必要な画面やUI要素

– 画面上の情報配置

– 株式コード入力欄

– 銘柄名表示の必要性

– 日足、週足、月足の切替UI

– ローディング、エラー表示、データなし時の表示

– 今後、売買ルール判定やテクニカル指標追加を見据えた拡張性

3. 技術設計のたたき台

– フロントエンドの責務

– バックエンドの責務

– データ取得部分の責務

– チャート描画部分の責務

– 日本株データを扱う際に必要になるデータ項目

  例: 日付、始値、高値、安値、終値、出来高

– 日足データから週足・月足を生成するべきか、APIで直接取得するべきか、その設計上の論点

– 銘柄コード入力時のバリデーション方針

4. モノレポ構成案

現在のモノレポを前提として、この機能を追加する場合のディレクトリ構成案を出してください。

以下の観点を含めてください。

– app / web / api / packages などにどう分けるべきか

– chart表示機能

– 株価データ取得機能

– 共通型定義

– 設定ファイル

– テスト

– 将来的な売買ルールエンジン追加余地

5. CLAUDE.md で管理すべき内容

この株式投資ツールをAIに継続的に実装してもらう前提で、

ルートのCLAUDE.mdや各ディレクトリ配下のCLAUDE.mdに何を書くべきか整理してください。

以下を具体的に示してください。

– プロジェクト全体の目的

– 日本株のみを対象とすること

– MVPの範囲

– 命名規則

– コンポーネント分割方針

– データ取得時の制約

– テスト方針

– 実装時に避けるべきこと

– 将来拡張を見越した注意点

6. 今後の実装フェーズに向けた成果物

最終的に、次の実装フェーズへ進みやすい形で以下を出力してください。

– 推奨アーキテクチャ案

– 推奨ディレクトリ構成

– 機能一覧

– 画面仕様一覧

– データモデル案

– API案

– CLAUDE.md の記載項目案

– 実装着手順序

# 出力形式

次の見出し構成で、できるだけ具体的に出力してください。

## 前提整理

## MVPのスコープ

## 機能要件

## 画面仕様

## 技術設計

## ディレクトリ構成案

## データモデル案

## API案

## CLAUDE.md 設計案

## 実装の優先順位

## 懸念点と設計上の論点

# 注意

– まだコードは書かないでください

– 実装よりも先に、仕様の曖昧さを減らすことを重視してください

– 将来的に売買ルール判定やテクニカル指標追加をしやすい構成を意識してください

– モノレポで長期運用しやすい設計を優先してください

前提整理

現行モノレポはSprint 0完成済み（Python / FastAPI / domain-data-app分離）。フロントエンドは未存在。packages/data の yfinance プロバイダーは日本株（7203.T 形式）をすでにサポート済み。

MVPのスコープ

機能 MVP 将来

銘柄コード入力・検索 ✅

銘柄名表示 ✅

ロウソク足チャート ✅

日/週/月足切替 ✅

テクニカル指標（SMA等） ✅

売買ルール判定シグナル表示 ✅

ウォッチリスト管理UI ✅

機能要件

F-01 銘柄検索: 4桁数字のみ受け付け。内部で .T を付与してAPIへ

F-02 銘柄情報: 銘柄コード + 銘柄名を表示

F-03 チャート: 日足デフォルト、週足・月足は日足データから domain 層で集計

F-04 足種切替: タブUI、切替時は再フェッチ（またはフロント集計）

F-05 状態表示: ローディング / エラー / データなし

画面仕様

┌─────────────────────────────────────────────────┐

│  [タイトル]                                       │

├─────────────────────────────────────────────────┤

│  銘柄コード: [____] [検索]   7203 トヨタ自動車    │

├─────────────────────────────────────────────────┤

│  [日足] [週足] [月足]                             │

├─────────────────────────────────────────────────┤

│  ロウソク足チャート（メイン）                      │

│  出来高バー（サブ）                               │

└─────────────────────────────────────────────────┘

技術設計

フロントエンド: React + TypeScript + Vite + Lightweight Charts（TradingView製、MIT、ロウソク足特化）

バックエンド: 既存 FastAPI skeleton を拡張

週足・月足の集計方針: APIで直接取得せず、日足から domain 層で集計

理由: yfinance の週足・月足は区切りが不安定、domain 層に置けばプロバイダー交換時も影響ゼロ、純粋関数なのでテスト容易

ディレクトリ構成案

packages/

├── domain/src/trading_domain/

│   └── candle_aggregator.py     ← 新規（週足・月足集計）

├── data/src/trading_data/

│   └── symbol_info.py           ← 新規（銘柄名取得）

├── app_api/src/trading_api/

│   └── routers/

│       ├── chart.py             ← 新規

│       └── symbol.py            ← 新規

└── web/                         ← 新規（フロントエンドアプリ）

    └── src/

        ├── components/

        │   ├── StockSearch/

        │   ├── CandleChart/

        │   └── IntervalTabs/

        ├── hooks/useChartData.ts

        ├── api/chartApi.ts

        └── types/chart.ts

データモデル案

APIレスポンス:

{

  “ticker”: “7203.T”,

  “symbol_name”: “トヨタ自動車株式会社”,

  “interval”: “daily”,

  “candles”: [

    { “date”: “2024-01-04”, “open”: 2500, “high”: 2580, “low”: 2490, “close”: 2560, “volume”: 15000000 }

  ]

}

将来の売買シグナル追加に備え signals: list[SignalPoint] | None = None フィールドを予約。

API案

エンドポイント 説明

GET /api/v1/chart/{ticker}?interval=daily&limit=252 ロウソク足データ

GET /api/v1/symbol/{ticker}/info 銘柄名・市場情報

CLAUDE.md 設計案

ルート: packages/web の追加、日本株のみ対象の明記、MVPスコープの明記

packages/web/CLAUDE.md: コンポーネント設計方針、命名規則、hooks経由のみのAPI呼び出し、Lightweight Charts限定

packages/app_api/CLAUDE.md: wiring only、ロジックは domain/data へ委譲

実装の優先順位

Phase 1 (バックエンド): candle_aggregator → symbol_info → API routers → CORS設定

Phase 2 (フロント基盤): Vite初期化 → 型定義 → APIクライアント → フック

Phase 3 (UI): StockSearch → IntervalTabs → CandleChart → App組み合わせ

Phase 4 (ドキュメント): data_contracts更新 → ADR-0003 → CLAUDE.md更新

懸念点と設計上の論点

論点 結論

週足・月足: API直接取得 vs 日足から集計 domain層で集計（安定性・テスト容易性）

packages/web vs apps/web packages/web（既存構成に apps/ がなく統一が楽）

開発時の二重サーバー起動 Makefile に make dev 追加、Vite proxy 設定

yfinance 銘柄名取得の不安定性 簡易キャッシュで吸収、後でプロバイダー交換可能な設計

チャートキャッシュ 既存 CandleCache をそのまま活用

将来の売買シグナル表示 ChartData に signals フィールドを予約、Lightweight Charts のマーカーAPIを将来使用

確認したい点があれば教えてください。問題なければ実装フェーズへ進めます。

Claude’s Plan velvet-mapping-music.md

User approved the plan

プランが承認されました。実装フェーズへの準備が整っています。

仕様設計のまとめとして、以下が確定した方針です:

主要な設計判断:

週足・月足: API直接取得ではなく domain 層で日足から集計（安定性・テスト容易性）

フロント配置: packages/web（既存構成に合わせた統一管理）

チャートライブラリ: Lightweight Charts（TradingView製、MIT、ロウソク足特化）

将来拡張: ChartData.signals フィールド予約で売買シグナル表示に備える

実装順序:

candle_aggregator.py（週足・月足集計）

symbol_info.py（銘柄名取得）

FastAPI routers（chart / symbol）

packages/web 初期化 → 型定義 → フック

UI コンポーネント（StockSearch → IntervalTabs → CandleChart → App）

ドキュメント更新