「個人の株式投資ツールに、AI に設計から実装まで任せてファクター分析機能を追加した」──こんな事例が X（旧 Twitter）で共有され、話題になりました。投稿者はフリーランスのプログラマーで個人投資家でもある駄犬（@daken_in_market）さん。データソースには J-Quants API を使い、AI モデル Claude Fable 5（投稿中の「fable」）に「まず設計を検討してほしい」と投げるところから始めています。
本記事では、この事例をもとに次の 3 点を整理します。
- 設計から丸投げする AI 開発のプロンプトの型 — いきなり実装させず、まず設計を出させる
- 株式ファクター分析ツールに必要な構成 — ファクター算出・登録機能と、それを使った分析機能
- J-Quants API を使ううえでのデータ品質の注意点 — 財務データ・分割調整・自力抽出データの落とし穴
株の話に見えて、実態は「AI にどう仕事を任せるか」というプロンプト設計・ハーネス設計の実例です。ファクター投資に興味がない人にも参考になる部分が多いはずです。
事例の全体像
まず、今回作られたツールの構成を図にすると次のようになります。投稿者が AI に依頼した「2 つに大別される機能」がそのまま構造に表れています。
- ① ファクターを算出して DB に登録する機能：J-Quants API から取得した株価・財務データをもとに、バリューやモメンタムといったファクター値を計算し、データベースに保存する。
- ② 登録済みファクターを使って分析する機能：保存されたファクター値を読み出し、過去の株価でバックテストを行い、結果を画面で確認する。
この「算出・登録」と「分析」を分離する発想は、AI が出した設計そのものではなく、依頼者が最初のプロンプトで既に切り分けて提示していた点が重要です。つまり 人間側が問題を粗く 2 分割して渡し、細部の設計・実装を AI に任せた 構図になっています。
設計から任せる：投げられた最初のプロンプト
投稿者が Claude Fable 5 に最初に投げたプロンプトは、そのまま公開されています。ほぼ原文のまま引用します。
この株式投資ツールで、ファクター分析ができるようにしたい。 大きく分けて、ファクターを算出してデータベースに登録する機能と、登録されたファクターを使って分析する機能の2つが必要と思われる。 これらの機能をどう実現するのがよいか、設計を検討してほしい。 ultrathink
ファクターは、最初のバージョンとしては、バリューやモメンタムといった主要なファクターに一通り対応したい。 また、後から新しいファクターを柔軟に追加できるような設計としてほしい。 ファクターの算出のために不足しているデータがあれば、J-Quants APIから取得できるか調べて、取得できないようなら教えてして[ママ]ほしい。
分析の機能としては、過去の株価を使用してバックテストができるようにして、その結果を画面から確認できるようにしたい。 どのような画面にするかも設計してほしい。
このプロンプトは短いながら、AI 開発で効くポイントを一通り押さえています。
1. 実装ではなく「設計を検討してほしい」と頼む
最初の一手が「どう実現するのがよいか、設計を検討してほしい」である点が肝です。いきなり「実装して」と頼むと、AI は前提や制約を確認しないまま最初に思いついた構造でコードを書き始めてしまいます。まず設計を出させることで、方向性が違えば安価にやり直せ、レビューして合意してから実装に進めます。投稿者も「この後に細かな仕様のやりとりを少しして、あとはお任せで実装まで終わってちゃんと動くものができた」と述べています。設計フェーズと実装フェーズを明確に分けた ことが成功要因になっているわけです。
2. ultrathink で熟考させる
末尾の ultrathink は、Claude Code などの Claude 系コーディング環境で使われる独自の記法で、思考の予算（思考トークン）を最大まで引き上げる合図です。think < think hard < think harder < ultrathink の順に、より多くの推論を割り当てます。設計のように「後戻りコストが大きく、比較検討が必要な工程」ほど、この一言の効果が出ます。
3. 拡張性を最初に要求する
「後から新しいファクターを柔軟に追加できるような設計としてほしい」という一文が、初版の作りを大きく左右します。これがないと、バリューとモメンタムをベタ書きした拡張しにくい実装になりがちです。将来の追加を最初の設計要件として明示する ことで、AI はプラグイン的な構造（ファクターを定義として登録し、算出エンジンが順に処理する形）を選びやすくなります。
4. データの不足を自分で調べさせる
「不足しているデータがあれば J-Quants API から取得できるか調べて、取得できないなら教えてほしい」という指示は、AI に制約の探索まで委ねています。ファクター算出には特定の財務指標や時系列が必要で、それが API で取れるかどうかは実装可否を左右します。ここを人間が事前に全部調べる代わりに、AI に「取れる／取れない」を切り分けさせているわけです。
ファクター分析とは何か
そもそもファクター分析・ファクター投資とは、株式のリターンを説明する共通の要因（ファクター）に注目してポートフォリオを組む手法です。市場平均（ベータ）を上回る超過リターンの源泉を、いくつかの定量的な特徴に分解して捉えます。代表的なファクターは次のとおりです。
| ファクター | 概要 | 代表的な指標 |
|---|---|---|
| バリュー（割安） | ファンダメンタルズに比べ株価が割安な銘柄 | PER、PBR、配当利回り |
| モメンタム | 過去一定期間（3〜12ヶ月）のリターンが高い銘柄を順張り | 過去リターン |
| クオリティ | 収益性・財務健全性が高い銘柄 | ROE、自己資本比率 |
| サイズ | 時価総額の小さい銘柄 | 時価総額 |
| 低ボラティリティ | 値動きの小さい銘柄 | 過去ボラティリティ |
今回のプロンプトでは「初版はバリューやモメンタムといった主要ファクターに一通り対応」を目標にしています。PER・PBR・配当利回りといったバリュー系指標は、投稿者いわく もともと J-Quants API のデータから算出してデータベースに保存済み で、それを再利用しているとのことです。
なお、ファクター戦略の良し悪しはバックテスト（過去データでの検証）で評価しますが、バックテストの結果は仮説に基づくものであり、将来の実際のパフォーマンスを保証しません。過去に効いたファクターが今後も効くとは限らない点は、投資判断の大前提として押さえておく必要があります。
データソース：J-Quants API
J-Quants API は、日本取引所グループ（JPX）が個人投資家・データ分析者向けに提供する公式のデータ配信サービスです。日本株の株価（OHLC）、財務情報、配当、株式分割などを API 経由で取得できます。
プランとデータ期間
料金プランによって、同じ種類のデータでも遡れる期間が変わります。
| プラン | データ期間の目安（株価四本値・財務情報） |
|---|---|
| Free | 直近 12 週間を除く約 2 年分（12 週間前〜2 年 12 週間前まで） |
| Light | 5 年前まで |
| Standard | 10 年前まで |
| Premium | 20 年前まで（格納期間は 2008/5/7 以降） |
（上記は V2 仕様。プランや時期によって変わることがあるため、正確な条件は必ず公式のデータ格納期間ページで確認してください。）
バックテストで長期の検証を行いたい場合、Free プランは直近 12 週間を除く約 2 年分にとどまり、しかも最新の 12 週間は取得できません。ファクター戦略を数年〜十数年のスパンで検証するなら、Standard（10 年）以上、できれば Premium（全期間）が現実的な選択になります。
V2 API への移行に注意
J-Quants API は V2 への移行が進んでおり、V1 のリフレッシュトークン方式から API キー認証方式へと認証が変わっています。2025 年 12 月 22 日以降に登録したユーザーは V2 API のみ利用可能です。AI にコードを書かせる際は、どちらのバージョンを前提にするか を明示しないと、古い V1 前提の認証コードを生成してしまうことがあります。
エンドポイント名も変わっている点に注意が必要です。たとえば財務情報は V1 の /fins/statements から V2 では /fins/summary になっています。付随的な機能追加として、2026 年 1 月には CSV 形式での提供や、分足・Tick データ（Light プラン以上のアドオン、月額 5,500 円・税込）も加わりました。
データ品質の落とし穴
この事例で技術的に一番示唆に富むのは、投稿者がデータ品質について率直に語っている部分です。ファクター分析は「入力データの質」で結果がまったく変わってしまうため、ここは AI に任せる／任せない以前の本質的な論点です。
投稿者と別のユーザー（@mi_fits さん）とのやりとりで、次のような課題が挙がっていました。
- 財務データの時系列が揃っていない：財務データと株価データをマージすると、実態と乖離するケースがある。
- XBRL 由来の数値ミス：開示書類（XBRL）そのものに数値の誤りが含まれることがある。
- 株式分割の調整値が怪しいことがある：分割前後の株価を連続的に扱うための調整値がずれると、過去リターンの計算が狂う。
- 自力で抽出したデータの品質が低い：受注情報やセグメント情報など、API に無い情報を独自にスクレイピング・抽出したデータは、公式データより品質が落ちる。投稿者も「そっちを何とかするのに注力している」と述べている。
ここから得られる教訓は明快です。ファクター分析ツールの難所は、ファクターの計算式でもバックテストのロジックでもなく、その手前のデータ整備にあるということ。バリューやモメンタムの計算そのものは定義が確立していて AI でも安定して書けますが、「時系列の整合」「分割調整」「欠損補完」といったデータの前処理は、ドメイン知識と地道な検証を要します。AI に丸投げできる部分（設計・実装）と、人間が責任を持つべき部分（データの正しさ）を切り分ける視点が欠かせません。
この事例から学べること
株式投資ツールの話を、AI 開発一般の教訓として抽象化すると次のようになります。
- 人間が問題を粗く分割し、設計は AI に任せる：今回なら「算出・登録」と「分析」の 2 分割までは人間が提示し、その中の設計は AI に検討させた。分割の粒度が適切だと、AI は各ブロックの設計に集中できる。
- 実装の前に設計を出させ、レビューしてから進む：「設計を検討してほしい」→ 仕様のやりとり → 実装、という順序がやり直しコストを下げる。
ultrathinkで設計工程の思考量を増やすのも有効。 - 拡張性・制約探索を最初の要件に含める：「後から追加できる設計に」「不足データは自分で調べて」と最初に要求しておくと、AI の出力が実運用に耐えるものになる。
- データの正しさは人間が握る：AI が書いたコードが動いても、入力データが間違っていれば分析結果は無意味。前処理・データ検証こそ人間の付加価値が残る領域。
「設計を検討してほしい」の一言から始め、細かい仕様を数往復詰めるだけで動くツールができる──AI コーディングの現在地を、株式ファクター分析という具体的な題材でよく表した事例だと言えます。
出典：駄犬（@daken_in_market）さんの X 投稿（2026 年 7 月 5 日）
参考リンク