個人開発で株価予測アプリを作るとき、一番危険なのは「それっぽく当たって見える」モデルを作ってしまうことです。バックテストでは好成績なのに、実運用では全く機能しない——いわゆる過学習は、株価のような時系列データでは特に起きやすい罠です。ある個人開発アプリの実装記録から、「LLMに確率を作らせない」「モデルに自己申告させない」という2段構えの安全設計を見ていきます。

境界1：自然言語モデルに、確率そのものを作らせない

このアプリでは、Grok CLIやローカルLLMを設計の壁打ち・実装補助・説明文生成には使いますが、個別銘柄の上昇・下落確率を出す経路には一切関与させていません。理由は明快です。自然言語モデルが出す「もっともらしい確率」は、再現可能な学習・校正・アウトオブサンプル評価を経た結果ではないからです。

「LLMが止まっても数値モデルが動く」「LLMの回答が変わっても売買確率は変わらない」という2点を、後付けのルールではなくアーキテクチャの要件として最初に固定しています。

境界2：検証に落ちたら、モデルに自己申告させず出力を隠す

もう一つの安全装置が「lockbox」と呼ばれるウォークフォワード検証ゲートです。学習は最小504営業日、校正126日、テスト63日、gap 1日、前進幅63日で回し、最後の252営業日は一度しか評価しない「lockbox」として固定します。

本番で確率を画面に表示するためには、少なくとも次の全てを満たす必要があります。

• 連結アウトオブサンプルのBrierスキルスコアが0より大きい
• コスト控除後アウトオブサンプル累積リターンがプラス
• 複数の売買ベースラインを上回る
• 63営業日のテストブロックの過半数でプラス
• 最終252営業日のlockboxを一度だけ評価して合格

これに落ちたモデルは、確率を出さずmodel_unverifiedとして画面に明示します。「予測しない」ことを失敗ではなく、正常な安全機能として扱う設計です。

実際に検証落ちが発生し、設計どおりに機能した

これは机上の話ではありません。開発記録によれば、初回の実データ学習では実際にジョブが失敗し、対象5銘柄すべてがmodel_unverifiedになりました。この時点で数値確率を捏造して表示することはせず、後に「研究用予測」としてresearch_only: true・verified: falseのフラグと「研究用・未検証。売買判断には使用しない」という警告付きで隔離する経路を実装し、翌営業日の実績と答え合わせできるようにしています。

設計として「安全側に倒す」ことと、実際に検証落ちが起きたときに本当にその通り動くかは別問題です。この記録では、両方が確認できています。

個人開発・AI活用にも応用できる考え方

この2段構えは、株価予測に限らず「AIの出力をそのまま信じない仕組み」の一例として参考になります。

• 数値・判定ロジックはLLMの経路から切り離し、決定的な処理に置く
• LLMの役割は「説明」「壁打ち」「実装補助」に限定し、最終判断の経路には入れない
• 検証に通らない結果は、もっともらしく見繕わず、明示的に「未検証」として隠す
• 「隠す」設計が実際に機能するかを、意図的な失敗ケースで確認する

AIをアプリに組み込むほど、「AIが間違えたときに何が起きるか」を先に設計しておく価値は大きくなります。