Issue #002: 学習基盤改善

報告日

2026-02-22

開発ルール

# コマンド実行は必ず poetry run を使うこと
poetry run python manage.py predict_ohlc ...
poetry run python manage.py confirm_predictions ...

# ジョブを走らせる前にユーザーに確認すること（バックテスト実行中の場合があるため）
# 精度検証・バックテストは自律実行OK（ユーザーレビュー不要）
# コーディング・設計変更はユーザーレビューを求める

関連issue

002 学習基盤改善     ← このissue（最優先）
003 予測アーキテクチャ刷新（HLC化, Close+レンジ, 信頼度）
004 方向予測の強化（クロスシグナル, レーティング, バッジ, チューニング）

実施順: 002 → 003 → 004

改修一覧

実施順

#1 ultra-fast実装（検証基盤。これがないと始まらない）
  ↓
#3 early_stopping + validation split（最もインパクトが大きい）
  → ultra-fastで効果検証
  → 今の精度がモデルの実力か過学習の結果かを切り分ける
  ↓
#4 曜日・時間帯別精度分析（#3と同時に結果を確認）
  ↓
#2 ループ速度改善（issue 003のコード書き換え時に同時実施が効率的）

#1. ultra-fastバックテストモード

問題: バックテストが遅すぎて改修のイテレーションが回らない

現状の1予測ポイントあたりのmodel.fit回数:

3モデル(XGB/LGBM/Cat) × 4ターゲット(OHLC) × 2段階(Lasso+残差) = 24回
+ Lasso 4回 = 28回

30M足200期間・step1で約3時間。改修ごとにこれでは検証不能。

改修内容: --ultra-fast オプション新設

# ultra-fastバックテスト（傾向確認用、精度は落ちる）
poetry run python manage.py predict_ohlc -t 30M --backtest --periods 200 --ultra-fast --save

# 通常バックテスト（最終検証用）
poetry run python manage.py predict_ohlc -t 30M --backtest --periods 50 --step 10 --save

ultra-fastの内容

→ 1ポイントあたり28回 → 1回 = 約28倍高速

用途の使い分け

H/Lの扱い（ultra-fast時）

Closeのみ予測し、H/Lはルールベースで概算する:

predicted_close = base_price * (1 + pred_close_pct / 100)
predicted_high = predicted_close * (1 + atr_pct * 0.5 / 100)  # ATRベースの概算
predicted_low = predicted_close * (1 - atr_pct * 0.5 / 100)

base_price とは: 予測起点のBTC価格（＝直前足の終値）。モデルは変動率(%)で予測するため、実価格への変換起点として使う。BtcPrediction.base_price に保存されている。 Openは予測しないため、表示側でOpen値が必要な場合は base_price（直前終値≒次の始値）をそのまま使う。

検証フロー

1. ultra-fast で A/B テスト（5-10分）→ 方向性の判断
2. step=10 で通常検証（30分）→ パラメータ調整
3. step=1 で最終確認（3時間）→ 本番投入の判断

影響範囲

• predict_ohlc.py: --ultra-fast オプション追加、_run_backtest_for_timeframe に分岐
• model.py: ultra-fast用の軽量予測関数追加

#2. バックテストループの速度改善

問題: ループ内のDataFrameスライスがボトルネック

特徴量のnumpy化（X_all = df_model[feature_cols].values）は実装済み。 残るボトルネックは以下の2つのDataFrameスライス:

1. df_slice = df_model.iloc[:i+1] — predict_v3_multiにDFを渡している（オシレータ値1行のため）
2. df_for_direction = df_copy.loc[:current_idx] — 方向予測にDFを渡している

改修内容

A. predict_v3_multiのオシレータスライス排除（効果: 大）

# 現状: df_sliceからオシレータ値を取得（ループごとにDFスライス発生）
df_slice = df_model.iloc[:i+1]
pred_pct_arr = predict_v3_multi(df_slice, X_train, ...)

# 改善: オシレータ値を事前にnumpy化し、スカラーで渡す
rsi_all = df_model['rsi_14'].values  # ループ前に1回
pred_pct_arr = predict_v3_multi(X_train, ..., oscillator_values={'rsi_14': rsi_all[i]})

B. 方向予測のDataFrameスライス排除（効果: 中）

# 現状: 方向予測にDataFrameを渡している
df_for_direction = df_copy.loc[:current_idx]   # 重いコピー

# 改善: 必要なのはRSI, Stoch K等の最新値のみ
# → ループ前に各指標の配列を準備、ループ内はインデックスアクセスのみ

C. バッチDB保存の最適化（効果: 小）

bulk_create で一括保存に変更。

適用タイミング

A〜Cは issue 003 の改修（HLC化、Close+レンジ方式）と同時に実施するのが効率的。 コードを書き換えるタイミングで一緒にnumpy化する。

#3. early_stopping + validation split

問題: 過学習しているかどうか分からない

現状のモデル構成:

Stage 1: LassoCV（トレンド系特徴量のみ）→ ベース予測
Stage 2: XGB/LGBM/CatBoostアンサンブル（全特徴量）→ 残差予測
Stage 3: オシレータ補正（ルールベース8種）→ 最終調整

これを入れるだけで精度が変わる可能性がある。 今の予測精度がモデルの実力か過学習の結果かを切り分ける、全改修の土台。

改修内容

# 時系列なので末尾をvalidationに使う
val_size = max(int(len(X_train) * 0.1), 20)
X_val, y_val = X_train[-val_size:], y_t[-val_size:]
X_train_fit, y_train_fit = X_train[:-val_size], y_t[:-val_size]

# 各モデルにearly_stopping_rounds=10を追加

モデルパラメータ（現状参考）

アンサンブル重み（Optuna最適化済み）: XGB 0.21 / LGBM 0.20 / CatBoost 0.59

検証方法

• 訓練期間のMAE vs テスト期間のMAE（乖離が大きいほど過学習）
• early_stopping有無での比較

補足: decay_half_life の矛盾解決 ✅

解決済み: 002検証で99が全指標で改善 → config.pyを99に修正。

補足: 004#4/#5 前倒し判断

early_stoppingの結果次第で、003のアーキ変更前にこれらを先行実施すべきか判断する: - 004#4: max_depth統一（高ボラ時 depth=6 → 4） - 004#5: 特徴量の絞り込み（30M/15M足で100〜140特徴量は過剰）

影響範囲

• model.py: 各モデルのfit呼び出しにearly_stopping追加

#4. 曜日・時間帯別の精度分析

背景

時間特徴量（hour_sin/cos, day_of_week, session flags等）は学習に組み込み済み。 しかし「曜日・時間帯ごとにどれだけ精度が違うか」の分析手段がない。

目的

• 精度が低い曜日・時間帯を特定する
• 信頼度の調整材料にする（例: 週末は信頼度を下げる）
• 予測を控えるべきタイミングを判断する

想定される傾向

改修内容: バックテスト結果に曜日・時間帯別集計を追加

[MAE by Day of Week]
  Mon: Close 1.2%  High 1.5%  Low 1.4%  (n=120)
  Tue: Close 0.9%  High 1.1%  Low 1.0%  (n=118)
  ...
  Sat: Close 2.1%  High 2.8%  Low 2.5%  (n=95)
  Sun: Close 1.8%  High 2.3%  Low 2.2%  (n=98)

[MAE by Session]
  アジア (9-17 JST):  Close 1.0%  High 1.2%  Low 1.1%  (n=200)
  欧州 (17-23 JST):   Close 1.3%  High 1.6%  Low 1.5%  (n=180)
  米国 (23-6 JST):    Close 1.5%  High 1.9%  Low 1.8%  (n=210)
  深夜 (6-9 JST):     Close 1.1%  High 1.3%  Low 1.2%  (n=80)

[Direction Hit Rate by Day of Week]
  Mon: 62%  Tue: 58%  Wed: 55%  ...

実装方針

• _run_backtest のループ内で曜日・時間帯をキーにした辞書に結果を蓄積
• ループ後にサマリー出力
• 15M/30M/H足: 時間帯別が有効
• D足以上: 曜日別が有効

補足: 15M足専用パラメータの検討

• 現状: _compute_sample_weights で15M足は decay_half_life_30m（48本）を流用
• 15M足では48本=12時間、30M足では48本=24時間 → 減衰速度が2倍異なる

• 4の時間帯別分析で15M/30Mの精度差異が見えるはず → 結果を元に decay_half_life_15m の導入を判断

将来拡張

• 曜日・時間帯の精度データをDBに保存 → 信頼度計算に組み込み
• 精度が低い時間帯では予測を自動的にスキップ or 信頼度を大幅に下げる

影響範囲

• predict_ohlc.py: _run_backtest にサマリー集計・出力追加

総合評価

実施状況

検証結果

ultra-fast vs 通常モード（日足、step=5/10）

→ ultra-fastは精度を大きく損なわず30倍以上高速。パラメータ検証に十分使える。

曜日別精度（日足 ultra-fast）

→ 想定では「週末=精度低い」だったが、実際は月曜が最も精度が低い。 週末の動きは小さく予測しやすいが、週明けの反動が読みにくいと推測。

時間帯別精度（時間足 ultra-fast）

→ アジア時間と深夜帯は予測精度が高く、米国時間が最も低い。信頼度調整の材料になる。

補足課題の対応結果

特徴量分析サマリー

→ バイナリフラグ系（rsi_oversold, stoch_overbought, asia_session等）は全時間軸でゼロ。 連続値特徴量（RSI数値, hour_sin/cos等）と重複しており不要。 詳細は 004-1_特徴量分析結果.md 参照。

003への引き継ぎ

002で整備した検証基盤（ultra-fast、early_stopping、曜日/時間帯分析）を使って、 003（予測アーキテクチャ刷新: HLC化、Close+レンジ方式）の効果を効率的に検証できる体制が整った。

2（ループ速度改善）は003 Phase1にて実施済み。

002レビュー指摘（Lasso temporal leakage, 損失関数不一致, fast_mode固定, inf未チェック）は003に引き継ぎ済み。