Issue #003: 予測アーキテクチャ刷新

報告日

2026-02-22

開発ルール

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

# 精度検証・バックテストは自律実行OK（ユーザーレビュー不要）
# コーディング・設計変更はユーザーレビューを求める

関連issue

002 学習基盤改善 ← 完了
003 予測アーキテクチャ刷新 ← 完了（このissue）
004 方向予測の強化 ← active（実装中）

改修一覧

実施順

0. ベースライン記録 ← 完了
  ↓
#1 OHLC → HLC + #2 Close+レンジ方式 + #5 コード重複解消 + 002#2ループ速度改善 ← 完了
  ↓
#8 002引き継ぎ（損失関数統一 → アンサンブル重み再最適化）← 完了
  ↓
#5 003-1指摘事項: コード重複・config整理 ← 完了
  ↓
#3 値の信頼度 ← 次にやる（重みが確定した状態で実装）
  ↓
#6 データ品質（欠損ローソク足、デリバティブ0埋め）
  ↓
#4 抵抗帯チャート表示 + #7 confirm改善（表示・運用系、最後に対応）

ベースライン記録（完了）

改修前後の精度比較基準として記録済み:

改修後もultra-fastのMAEはベースラインと完全一致を確認済み。

#1. OHLC → HLC（Open予測廃止）【完了】

実施内容

• Open予測を廃止。predicted_open はnullable化（段階的廃止、既存データ保持）
• BtcPredictionDetail.effective_open プロパティ追加: predicted_open ?? prediction.base_price
• views.py 4箇所で d.effective_open に統一
• predict_ohlc.py: target_open = base_price を設定（Open予測モデルは不使用）
• direction_prediction.py: predicted_open 引数は後方互換で残すが内部で無視、ref_price = base_price に統一
• confirm_predictions.py: detail.effective_open を使用
• マイグレーション: 0010_predicted_open_nullable

当初方針との差異

issueは「カラム完全削除」を指示していたが、既存データ保持のため「nullable化 + effective_openプロパティ」で段階的廃止とした。

#2. Close+レンジ方式（HLC予測アーキテクチャ変更）【完了】

実施内容

• predict_range() を model.py に追加（LightGBMのみ、軽量レンジ予測）
• _predict_single(): Close予測(predict_v3_multi, 1ターゲット) + Range予測(predict_range, 2ターゲット)
• H/L導出: pred_high = pred_close * (1 + max(0, upper_range) / 100) — クリッピングでH>C>L構造保証
• apply_ohlc_constraints 呼び出し全削除（構造的に不要）
• バックテストループも同様にClose+Range方式に変更
• 全timeframeに一括適用（30M先行ではなく全TF同時）

精度検証結果（改修前後、ultra-fast）

誤差伝播の評価

未実施（A vs B比較）。現時点ではH/L MAEに顕著な悪化は見られず、優先度を下げている。

#3. 値の信頼度（モデル合意度）

現状

3モデル（XGBoost, LightGBM, CatBoost）の予測値を加重平均して最終予測としているが、 個別予測値は捨てている。モデル間のばらつき情報が失われている。

改修内容

3モデルの個別予測値のばらつき（標準偏差）を「値の信頼度」として算出・保存する。

preds = [pred_xgb, pred_lgbm, pred_cat]
ensemble_pred = xgb_w * pred_xgb + lgbm_w * pred_lgbm + cat_w * pred_cat
model_std = np.std(preds)  # モデル間のばらつき

0-100スコア化

stdをATR基準で正規化し、0-100のスコアにする。

std_pct = model_std / base_price * 100       # ばらつきを価格比%に変換
ratio = 1 - min(std_pct / atr_pct, 1.0)      # ATR比で正規化（0〜1）
value_confidence = round(ratio * 100)         # 0-100スコア

• 100: 3モデル完全一致（ばらつき0）
• 50: ばらつきがATRの半分
• 0: ばらつきがATR以上（予測が信用できない）

2軸の信頼度

DB保存

# BtcPredictionDetail に追加
value_confidence = models.SmallIntegerField("値の信頼度", null=True)  # 0-100スコア
value_confidence_detail = models.JSONField("値の信頼度詳細", null=True)

# JSONの中身（HLCターゲットごと）
{
    "close": {"xgb": 0.12, "lgbm": 0.08, "cat": 0.15, "std": 0.035},
    "high":  {"xgb": 0.45, "lgbm": 0.38, "cat": 0.52, "std": 0.070},
    "low":   {"xgb": -0.30, "lgbm": -0.25, "cat": -0.35, "std": 0.050},
    "atr_pct": 0.8,
    "score": 96
}

注意点

• ultra-fast時の扱い: ultra-fastモードはLightGBMのみで動作するため、3モデルの標準偏差が算出できない。以下のいずれかを選択する:
• ultra-fast時は値の信頼度を算出しない（null保存）
• ultra-fast時は固定値（例: 50）を入れる

予測モニタリングとの連携

信頼度スコアを導入するなら、以下の監視も合わせて設計すべき: - 信頼度の時系列推移（信頼度が継続的に低下していないか） - 信頼度と実際の予測精度の相関（信頼度が高い予測は実際に精度が高いか） - 予測スキップ回数の追跡（データ取得失敗による無予測期間の検出）

影響範囲

• model.py: 個別予測値とstdを返す
• predict_ohlc.py: スコア算出・DB保存
• models.py: value_confidence + value_confidence_detail 追加
• 表示側: 値の信頼度をスコア表示

#4. 抵抗帯/支持帯のチャート表示

背景

cluster_r_price / cluster_s_price は既に計算・保存可能だが、表示していない。 クラスタリング方式（_add_cluster_levels）はヒストグラムのビン幅で価格帯を算出しており、ライン（線）ではなくゾーン（帯）のデータが取れる。

改修内容

予測OHLCチャートにクラスタ抵抗帯/支持帯を半透明の帯として重ねる。

データ構造定義

004#3（抵抗帯バッジ表示）でも同じデータを使うため、ここで定義しておく: - クラスタ価格帯: ビン上端/下端、タッチ回数 - views → テンプレートへの受け渡し: コンテキスト変数名、JSON構造

# 例: viewsからテンプレートへ渡す構造
resistance_zones = [
    {"upper": 68500, "lower": 68200, "touches": 5},
    {"upper": 67800, "lower": 67500, "touches": 3},
]
support_zones = [
    {"upper": 66500, "lower": 66200, "touches": 4},
]

計算パス

_add_cluster_levels は feature_engineering で特徴量として計算されるが、 チャート表示用にはゾーン（帯の上端/下端）のデータが必要。

方針: 予測時にゾーン情報を計算し、BtcPredictionDetail にJSON保存する。 views はDBから読むだけ。 - 予測時点の抵抗帯が記録として残る - views に計算ロジックを持たせない

影響範囲

• templates/crypto/prediction_ohlc.html: チャートに半透明帯を描画
• crypto/views.py: クラスタ価格帯を計算してコンテキストに渡す

#5. config不整合・コード品質の解消【完了】

003本体のコードレビューにより19項目の指摘を検出（003-1）。 コード重複解消（~755行対象）とconfig集約を実施。

指摘事項の対応判定

完了判定基準（#7 対応）

1. コード重複解消: ヘルパー関数に抽出し、元の重複箇所がヘルパー呼び出しに置換されていること
2. Config集約: ハードコード値が config.py に移動し、get_config() 経由で参照されていること
3. 検証: predict_ohlc -t D --backtest --periods 50 --step 5 のMAEがリファクタ前と一致すること
4. 回帰なし: 30M/H/D/W/M の全時間軸でバックテストが正常実行できること

実装内容

feature_engineering.py 共通化（~400行削減）

バックテストループ速度改善（002#2引き継ぎ）

predict_v3_multi に oscillator_values: dict パラメータ追加。 バックテストループ内の df_slice = df_model.iloc[:i+1] を完全排除。

model.py ヘルパー抽出（#8-10, ~168行削減）

predict_ohlc.py ヘルパー抽出（#11-15, ~430行削減）

data_loader.py + _utils.py（#16-19, ~157行削減）

Config集約（#17）

• sideways_range_ratio: 0.45, sideways_change_pct: 0.1 → config.py
• atr_periods: {15M:48, 30M:24, H:12, D:14} → config.py
• direction_prediction.py: リテラル → get_config() 参照
• confirm_predictions.py: ATR periods + 乖離率計算 → 共通関数参照

設計決定

検証結果

全Phase（A-D）でMAEが一致し、回帰なしを確認:

D足バックテスト（50d, step=5）:
  +1d | Close 3.23%  High 2.82%  Low 3.25%
  +3d | Close 5.67%  High 5.31%  Low 5.81%

30M足バックテスト（100bars, step=50）:
  +1bar | Close 0.27%  High 0.24%  Low 0.22%
  +2bar | Close 0.38%  High 0.36%  Low 0.38%
  +6bar | Close 0.81%  High 0.82%  Low 0.86%

git diff: +435 / -478（ネット -43行）

#6. データ品質の改善

欠損ローソク足の未検出

サブ日足データ（15M/30M）で取引所ダウンや API 障害によるギャップがあっても、 pct_change(), rolling(), shift() がそのまま計算され、不正な特徴量が生成される。 data_loader.py にもデータ連続性チェックがない。

→ データロード後にタイムスタンプの連続性チェックを追加。ギャップが閾値を超える場合は警告 or 学習から除外

デリバティブ特徴量の 0 埋め問題

# feature_engineering.py — 現状
deriv_cols = ['funding_rate', 'long_short_ratio', ...]
df[col] = df[col].fillna(0)

• funding_rate = 0 は「中立ファンディング」という実際の市場情報。「データ欠損」と区別できない
• long_short_ratio = 0 は「ショート極端偏り」を意味してしまう

→ has_derivative_data インジケータ特徴量を追加し、欠損時は中央値/平均値で補完

#7. confirm_predictions の改善

確定ロジックの脆弱性

# confirm_predictions.py — 現状
return actual.updated_at >= candle_close_time

updated_at がローソク足確定前に更新された場合、未確定データで判定してしまう。 → ローソク足のタイムスタンプ検証を追加

N+1 クエリ問題

_get_atr が各 detail レコードごとに DB クエリを発行。100件の確定処理で100回の個別クエリ。 → ATR 計算を一括プリフェッチに変更

#8. 002からの引き継ぎ（パイプライン品質）【完了】

対応結果

002 残課題（全て反映済み）