🔴 Oracle 23ai × 予測AI — 構造的優位の解剖

使い込むほど
精度が上がるDBがある

PostgreSQL・DuckDB・SQLiteでは代替できない5つのleakage-free特徴量エンジン。PJ33艇脳・PJ38馬脳の実装コードとOpus調査結果から解剖する。

AUC 0.9073
艇脳 DEFAULT
ROI 200.4%
艇脳 実運用
AUC 0.8976
馬脳 V28 dirt
¥79,147/月
馬脳 バックテスト
Core Thesis

なぜOracleを使うと精度が上がるのか

Opusの分析と実コードの調査から導いた本質的答え。

Thesis — Opus 4.7 調査結果

Oracle 23aiは ACID境界内でleakage-freeな特徴量を5系統(時系列rolling・グラフ関係性・ベクトル類似・行パターン・最新スナップショット)同時に積層できる唯一の商用DB である。 他スタック(PostgreSQL+pgvector+別グラフDB+ETL)では特徴量を1種類増やすたびにETL・同期・監査コストが線形増加するが、 Oracle上では全て同一スキーマ・同一トランザクションで完結するため、特徴量次元を増やすほど検証コストが逓減し、精度が爆発できる。 pari-mutuel予想は「時刻tに知り得た情報のみで特徴量を作る」制約が最も厳しいドメインの一つであり、Oracleのアーキテクチャ設計と完全に共鳴する。

5 Feature Engines

他DBでは代替できない5つのエンジン

PostgreSQL・DuckDBとの具体的差分。コードは全てPJ33/PJ38の実装から引用。

ENGINE 01
🕸️ Property Graph (SQL/PGQ)
既存リレーショナルテーブル上にGRAPH VIEWを定義し、MATCH句で2-hopパス(選手→過去同条件レース→対戦相手)を1クエリで評価。グラフはBASE TABLEに張った動的ビューなのでINSERT即反映。
他DBとの比較
PostgreSQLはApache AGE拡張が必要でSQL標準非準拠。Neo4j等に切り出すとETL必須でleakage発生源になる。DuckDBはグラフクエリ事実上不可。
PJ33: h2h_temporal_score = #2特徴量 gain 16.76% PJ38: h2h_pagerank Top-15入り
ENGINE 02
⚡ AI Vector Search (HNSW)
VECTOR型がネイティブSQL型。HNSWインデックスがin-DB・トランザクション境界内でKNN検索可能。同一クエリでvectorとリレーショナル条件(馬場・距離・クラス)を結合フィルタできる。
他DBとの比較
pgvectorは別拡張でACID境界外。HNSW build時間が長く、レース文脈ベクトルと確定オッズの「時刻t断面」を同一トランザクションで保証しにくい。
PJ33: race_vectors VECTOR(36,FLOAT32) + HNSW 本番稼働 PJ38: V32-E sim_context_familiarity
ENGINE 03
📊 SQL Analytics / Window Functions
ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING で「当該行を絶対に含まない」時系列rolling統計が宣言的に書ける。PARTITION BY × ORDER BY × RANGE で任意の時系列集計が1クエリで完結。
他DBとの比較
PostgreSQLは同等syntaxだが並列クエリ・大量パーティションでOracleに劣る。Pandas/Polarsで書くと「誤って未来データを含める」ミスが起きやすく監査が困難。
PJ33: exh_time_pct_rank PERCENT_RANK 5種同時計算 PJ38: trainer_win_rate 全版 Top-1〜3
ENGINE 04
🔀 MATCH_RECOGNIZE(行パターン)
正規表現的構文(PATTERN (FRONT+))でレース毎の状態遷移をSQL内FSMで抽出。「連続逃げ先行ストリーク」「脚質の変化トレンド」を1クエリで特徴量化。PostgreSQLには未実装。
他DBとの比較
PostgreSQL未実装(SQL標準提案中で未マージ)。PandasでLoop実装するとO(N)ループで遅く、leakage混入リスク。PJ38はPythonフォールバック実装を別途用意している。
PJ38 V32-A: consec_front_runs / front_runner_rate Snowflake/BigQueryも対応
ENGINE 05
📌 KEEP (DENSE_RANK LAST)
1回のGROUP BY集計で「最新1件の値」を同時抽出。追い切り記録が複数ある馬の「直前日追い切り指数だけ」を1クエリで取得。サブクエリ不要・I/O 1回・推論直前の再計算が秒オーダー。
他DBとの比較
PostgreSQLはDISTINCT ON句で代替できるが集計を同時に行うと冗長。MySQLは相関サブクエリが必須でN+1問題。
PJ38 V28: cha_last_oikiri_idx(直前追い切り指数) 推論直前10分の再計算に効く
Oracle固有度最高 — PJ38 V32 MATCH_RECOGNIZE(v32_match_recognize.py 実装)
-- 「最新レースから始まる連続逃げ先行ストリーク本数」を1クエリで抽出
WITH ordered_races AS (
    SELECT s.KETTO_TOROKU_BANGO, r.RACE_DATE, s.CORNER1, s.FIELD_SIZE,
           ROW_NUMBER() OVER (PARTITION BY s.KETTO_TOROKU_BANGO
                              ORDER BY r.RACE_DATE DESC) AS rn
    FROM JRDB_SED s JOIN RACES r ON r.RACE_ID = s.JRDB_RACE_KEY
    WHERE r.RACE_DATE < TO_DATE(:cutoff_date, 'YYYY-MM-DD')
),
front_streaks AS (
    SELECT * FROM ordered_races
    MATCH_RECOGNIZE (          -- ← PostgreSQL未実装
        PARTITION BY KETTO_TOROKU_BANGO ORDER BY rn
        MEASURES  COUNT(*) AS streak_len,  FIRST(rn) AS first_rn
        ONE ROW PER MATCH  AFTER MATCH SKIP PAST LAST ROW
        PATTERN (FRONT+)
        DEFINE  FRONT AS CORNER1 <= 3   -- 1〜3番手通過 = 逃げ/先行
    )
)
SELECT KETTO_TOROKU_BANGO,
       CASE WHEN first_rn = 1 THEN streak_len ELSE 0 END AS consec_front_runs
FROM front_streaks WHERE match_num = 1
DB Comparison

PostgreSQL / DuckDB との機能対比

「代替可能」と「代替困難」を明確に分離する。

機能 Oracle 23ai PostgreSQL DuckDB ML精度への影響
Property Graph (SQL/PGQ) ✅ ネイティブ Apache AGE拡張(非標準) ❌ 不可 h2h_pagerank / racer_venue相性が Top-1〜5 特徴量
VECTOR型 + HNSW ✅ ネイティブ pgvector拡張 (ACID境界外) ❌ 不可 類似レース文脈KNN特徴量 / 36次元HNSW本番稼働
MATCH_RECOGNIZE ✅ SQL標準実装 ❌ 未実装(提案中) ❌ 不可 consec_front_runs 等の状態遷移特徴量(V32)
KEEP (DENSE_RANK LAST) ✅ Oracle固有 DISTINCT ON (冗長) ROW_NUMBER サブクエリ必要 直前追い切り指数の推論直前再計算(V28)
Materialized View + DBMS_MVIEW ✅ オンデマンド制御 REFRESH CONCURRENTLYで代替可 ❌ 不可 player_motor_affinity MVIEW / WF-CV高速化(数時間→数分)
Window Functions (PARTITION/ORDER/ROWS) ✅ ANSI標準 ✅ 代替可 ✅ 代替可(高速) trainer_win_rate 等 rolling統計(代替可能だがOracle並列実行が高速)
MERGE INTO (冪等UPSERT) ✅ ANSI標準 INSERT...ON CONFLICT で代替可 INSERT OR REPLACE で代替可 ETL信頼性。PJ33/PJ38合計 26箇所以上で使用
FLASHBACK / AS OF SCN ✅ Oracle固有 ❌ 不可 ❌ 不可 「過去任意時点の特徴量」再現でfeature/serving skew撲滅
Evidence

PJ33・PJ38の実装が示す証拠

抽象論ではなく、実際のコードと精度数値で検証する。

🚤
PJ33 艇脳 Teinou
102特徴量 · AUC 0.9073 · ROI 200.4%
motor_win_rate MVIEW 343,707ペア #1特徴量
h2h_temporal_score GRAPH 10年self-JOIN #2 gain 16.76%
field_motor_strength_mean GRAPH Property Top-5
knn_avg_payout / upset_rate VECTOR HNSW v9 本番稼働
exh_time_pct_rank 他4種 PERCENT_RANK Window v18 会場間スケール解消
motor_win_rate ETLが5/6〜5/7に無通知停止した際、1着的中率が76%→26%に崩壊。MVIEW 343,707ペアの情報なしにはモデルが機能しないことをアクシデントが証明した。
🐎
PJ38 馬脳 Umanou
215特徴量 · V28 · WF-CV AUC 0.8976/0.8922
trainer_win_rate_all Window rolling 全版 Top-1〜3
chokyo_idx / kyusha_idx JRDB JOIN 305K行 常時 Top-3〜5
h2h_win_rate GRAPH 246万行 V5以降 Top-1
horse_avg_pace_dev kijun_times MEDIAN/STDDEV turf EV +4.9pp
consec_front_runs MATCH_RECOGNIZE V32-A Oracle固有度最高
V4でオッズ特徴量を除外してOracle由来のfundamental 33列に切り替えたとき、AUCは下がったがEV回収率は逆に改善。市場コンセンサスでなくOracleが計算する「実力値」がモデルの本質的なエッジになっている。
Oracle機能追加と精度改善の対応関係
追加したOracle機能 PJ 特徴量 精度変化
Property Graph 2-hop (v6) 🚤 PJ33 h2h_win_rate_min / field_motor_strength_mean 回収率 +4.2pp → 160.7%
VECTOR(36) + HNSW ANN (v9) 🚤 PJ33 knn_avg_payout / upset_rate / payout_std ROI 200%超ラインを突破
H2H時系列 ADD_MONTHS 10年 (v10) 🚤 PJ33 h2h_temporal_score (#2, gain 16.76%) True OOS ROI 199.8%
JRDB 305K行 JOIN (V3) 🐎 PJ38 chokyo_idx / kyusha_idx (+11列) 調教指数が常時Top-3入り
H2H Graph 246万行 (V5) 🐎 PJ38 h2h_win_rate (全特徴量中 Top-1) V5以降の全モデルで安定Top-1
kijun_times MEDIAN/STDDEV 126条件 (V11) 🐎 PJ38 horse_avg_pace_dev (Top-11/12) turf EV回収率 +4.9pp
MATCH_RECOGNIZE FSM (V32-A) 🐎 PJ38 consec_front_runs / front_runner_rate V32 評価中
KEEP (DENSE_RANK LAST) (V28) 🐎 PJ38 cha_last_oikiri_idx(直前追い切り) 推論直前再計算コスト ↓
Generalization

競馬・競艇を超えた一般化可能なパターン

「時系列厳守 × 関係性 × 類似性 × 状態遷移が全て効く」ドメインならどこでも成立する。

Generalized Pattern — Opus 4.7 分析

point-in-time correctness を担保しながら、多角的な関係性・類似性・状態遷移を同時に特徴量化する必要があるドメインでOracle 23aiは構造的優位を持つ。 pari-mutuel予想はこの構造の純粋形。金融・スポーツ・サプライチェーン・与信など「時間的に厳密な多次元特徴量エンジニアリング」が求められる全ドメインに転用できる。

📈
金融トレーディング
point-in-time bar + カウンターパーティグラフ + 類似相場KNN + ブレイクアウトパターン検出
H2H→取引相手グラフ MATCH→ブレイクアウト
スポーツアナリティクス
選手相性グラフ + 試合文脈ベクトル + 調子ストリーク検出 + 直近スタッツ最新値抽出
Property Graph→相性 MATCH_RECOGNIZE→調子
🏭
サプライチェーン需要予測
Tier-N依存グラフ(2-hop) + 類似週KNN + 需要急変パターン + 在庫最新スナップショット
Graph→Tier依存度 VECTOR→類似週
🏦
与信 / 不正検知
取引相手グラフ + 類似取引パターン + 異常遷移検出 + 監査要件の過去時点再現
FLASHBACK→監査再現 MATCH→異常遷移
Next Steps

Oracle Enterprise化(Docker Linux)で解放されるもの

Free版 12GB制限 → Enterprise 無制限移行で今まで諦めていた機能が全て有効化される。

📦 JVLink全量データ保持
初期フェッチで100〜200GB規模のJVLink歴史データを格納。全年・全種別の馬データが揃えばPedigree Gen2(祖父系統)も有効化でき、特徴量がさらに拡張する。
現状: 12GB制限でブロックEnterprise: 無制限
🧬 Pedigree Gen2 完全解放
現在 pedigree_edges は Gen1(父馬・母父馬)396K行のみ。全量取得後に祖父・曾祖父系統(SQL/PGQ 3-hop)まで展開するとさらなる精度向上が見込める。
現状: ID形式不一致で0行解消でTop-15増加期待
🔢 複数PDB並行稼働
PJ33専用PDB / PJ38専用PDB / 将来PJ用PDBをセキュリティ境界付きで同一インスタンスに共存。接続文字列を変えるだけで完全分離。Free版は2PDB上限。
Free: 2PDB上限Enterprise: 無制限PDB
🚀 月次リトレイン高速化
M4 Pro 12コア + Oracle Enterprise の並列実行エンジンで、現在数時間かかるself-JOIN(H2H 246万行)やWF-CV学習が大幅短縮。PJ38 V29以降の特徴量増にも耐える。
現状: MacBook Air M3M4 Pro + Enterprise並列