個人開発では、テストが全部通っているように見えても、実際に手を動かすと想定外の失敗にぶつかるものです。ある株価予測アプリの実装記録に残っていた、実際に起きた5つの失敗と、そこから引き出された運用ルールをまとめます。

1. 手順書に書かれたスクリプトが存在しなかった

最初のリサーチキャッシュ手順は、文書に記載されていたPythonパスが現行のコードには存在せず、そのまま失敗しました。AI向けの手順書も時間とともに古くなります。以後は、手順書の内容を信じる前に実ファイルの存在を確認することを、最初の受け入れ条件に組み込むようにしています。

2. 隔離E2Eでウォッチリストを保存していなかった

隔離データ領域でE2Eテストを実行した初回は、同期処理の前に対象銘柄の保存が行われておらず失敗しました。テストの前提状態をfixtureだけで再現し、「保存 → 同期 → 学習 → 予測 → 表示」という順序を1本のE2Eテストへ閉じる形に修正しています。

3. ポート競合とCORS不足

開発中、既存の8000番ポートを別プロセスが使用していたこと、隔離UI/APIのポートを変更した際にCORS設定が不足していたことが起きました。APIのベースURLと許可Originを環境変数で切り替えられるようにし、E2Eは専用の隔離ポート（API・UIそれぞれ別）で実行する運用に変更しています。

4. DuckDBのロック

稼働中のPythonプロセスがDuckDBをロックしていると、別プロセスから直接read-only接続できない場合があります。この問題を回避するため、状態確認はDBファイルを直接開くのではなく、稼働中のローカルAPI経由で読み取る方式に変更しています。DBファイルへの直接アクセスは、複数プロセスが同時に動く構成では思わぬロック競合を生みやすいポイントです。

5. 学習失敗でも、確率を捏造しない

初回の実データ同期後、学習ジョブが失敗し、対象銘柄はすべて「未検証」状態になりました。ここで数値を無理に埋めることはせず、未検証であることをそのまま画面に反映する運用を守っています。後に、未検証の予測を「研究用」として隔離し、翌営業日の実績と答え合わせできる経路が別途実装されました。

まとめ：失敗を隠さず、運用ルールへ変換する

どれも派手な障害ではなく、実装を進める中で普通に起きる類の失敗です。重要なのは、失敗が起きたときに「なんとなく回避する」のではなく、二度と同じ形で失敗しないよう受け入れ条件やテストの構造そのものへ落とし込んでいる点です。