Pine ScriptのMTF戦略で未来参照を防ぐ：request.securityとlookahead bias

MTF監査の核心は、値ではなく利用可能時刻

上位時間足の最終close、high、low、indicator値は、その上位barが閉じるまで確定しません。 15分chart上の09:00時点で、09:00〜10:00の1時間closeを使うことはできません。historical plotが09:00から完成値を表示するなら、future informationが過去へ漏れていないかを確認します。

MTF code reviewでは、symbol、requested timeframe、expression、gaps、lookahead、offset、historical/realtime挙動を一つのrequest contractとして保存します。「1時間足を使う」という説明だけでは不十分です。どの1時間足の、確定前か確定後か、LTFのどのbarから利用可能かを文章で答えられる必要があります。

本稿でHTFと呼ぶのは、requested timeframeがchart timeframeより厳密に大きい場合だけです。60分chartから60分をrequestする同一時間足、60分chartから15分をrequestする下位時間足は、このconfirmed HTF patternの対象外です。両方を秒数へ変換してrequested > chartを満たさなければ、値を使わずruntime errorで停止します。

HTF barの確定境界をLTF barへ写す

15分足4本が1時間足1本に対応する単純例では、09:00〜10:00 HTF barの最終値は10:00の境界で初めて確定します。それ以前のrealtime更新で見えるhigh、low、closeは流動値です。確定値だけを使うdesignなら、09:00〜10:00の間は一つ前の確定HTF barを保持し、10:00以降に新しい確定値へ切り替えます。

data revisionやsession差は別途残るため、「同じになりやすい」は完全一致保証ではありません。

「60÷15＝4」だけでは市場時刻上の四本対応を証明できません。実在するbarを使って境界を再現します。

例えば通常営業日の整列した四本、短縮取引日の終端、休日明けの最初のbarを別caseにします。各caseでHTF開始、HTF終了、直前LTF、直後LTFを時刻付きで記録し、完成値が最初に現れるbarを目視とlogの双方で照合します。欠損したはずのbarを架空に補わず、利用不能を監査結果へ残します。

lookahead_onはoffsetの有無で意味が逆転し得る

`barmerge.lookahead_on`は、それだけで安全または危険と決まるoptionではありません。HTF expressionが現在barの`close`なら、historical chartで完成値をperiod冒頭へ配り、未来漏洩を起こす危険があります。一方、`close[1]`のように一つ前の確定HTF expressionをrequestし、lookahead_onでLTFへ揃えるpatternは、historicalとrealtimeで確定値を安定して受け取る代表的な方法です。

同じtimeframeやlower timeframe requestでは意味が異なります。HTF前提を検証してからpatternを選びます。

`barstate.isconfirmed`をLTF strategyへ足すだけでは、request expressionへ混入したfuture HTF valueを取り除けません。chart barの確定と、requested contextの確定は別の状態です。

symbol・timeframe・gaps・sessionも同時に固定する

request先symbolがchartと同じでも、session、adjustment、currency、ticker constructionが違えば別seriesです。`gaps_off`で前値を埋めるか、`gaps_on`で利用不能barを`na`にするかもsignal timingへ影響します。HTF boundaryだけでなく、休場、extended hours、週末、daylight saving timeを含む実際のbar alignmentを確認します。

• 完全な`syminfo.tickerid`または明示したticker IDを保存する。
• chart timeframeより本当に高いtimeframeかruntimeで拒否条件を置く。
• expression内のindicator lengthとhistory offsetを保存する。
• gapsとlookaheadを省略せず、意図をcommentへ書く。
• session・timezone境界のsample日時を手計算で確認する。

同じplot色や近い最終値は同一contractの証拠ではありません。入力と時刻を一行単位で比較します。

failure boundaryでは、request先のsessionだけをextendedへ変えたcase、gaps_onでnaが出るcase、銘柄切替でexchange timezoneが変わるcaseを用意します。signal数の増減を見る前に、どのseriesがどのbarで利用可能になったかを比較し、暗黙の前値埋めを確定情報と取り違えていないか確認します。

前の確定HTF値を明示的にrequestする

下のPine v6 sampleは、chartより高いtimeframeだけを許可し、`close[1]`と`ta.ema(close, 20)[1]`をHTF contextで評価して`lookahead_on`でLTFへ揃えます。cross ruleはcode timing説明用で、entry手法や20期間を推奨しません。確定値を使う代償として、現在形成中のHTF情報より遅くなります。

//@version=6
strategy("Confirmed HTF audit demo", overlay = true)

string higherTf = input.timeframe("60", "Higher timeframe")
int chartSeconds = timeframe.in_seconds()
int higherSeconds = timeframe.in_seconds(higherTf)

if higherSeconds <= chartSeconds
    runtime.error("Choose a timeframe higher than the chart timeframe")

float confirmedHtfClose = request.security(
    syminfo.tickerid,
    higherTf,
    close[1],
    lookahead = barmerge.lookahead_on
)
float confirmedHtfEma = request.security(
    syminfo.tickerid,
    higherTf,
    ta.ema(close, 20)[1],
    lookahead = barmerge.lookahead_on
)

bool longCondition = ta.crossover(confirmedHtfClose, confirmedHtfEma) and barstate.isconfirmed
bool exitCondition = ta.crossunder(confirmedHtfClose, confirmedHtfEma) and barstate.isconfirmed

if longCondition
    strategy.entry("L", strategy.long)
if exitCondition
    strategy.close("L")

plot(confirmedHtfClose, "Confirmed HTF close", color.teal)
plot(confirmedHtfEma, "Confirmed HTF EMA", color.orange)

二つのrequestは同じHTF barのprevious closeとprevious EMAを返します。HTF closeをLTFで20回並べてからEMAを計算するのではなく、EMA自体をHTF contextで計算してoffsetする点を区別します。request countとperformance limitも現行manualで確認します。

historical・realtime・reloadの三つを同じbarで比較する

1. 01Known boundaryを選ぶ

   HTF close前後のLTF barを一組選び、時刻を保存します。

2. 02Historicalを記録

   reload直後のHTF value、signal、order markerを保存します。

3. 03Realtimeを観察

   open HTF中に値が固定か変動かをtimestamp付きで記録します。

4. 04HTF closeを確認

   どのLTF barから新しい確定値へ切り替わったか確認します。

5. 05再度reload

   同じbarのvalueとsignalが残るかdiffを取り、違えば原因を分類します。

さらにsafe patternと危険patternを同じperiodへ並べ、signal count、最初の利用可能bar、trade timestampを比較します。成績差ではなく、未来値がいつ過去へ現れたかを証拠化します。BT07のoverfittingとは異なり、ここで直すのはparameter選択ではなくdata availability bugです。

比較する二版はexpression offsetとlookahead以外を同じ設定フィンガープリントへ固定します。

再現は一度の画像で終えません。最初にhistorical runの対象barと値をCSVへ保存し、次に同じHTFが形成中のforward観察で更新時刻を記録し、確定後にreloadします。三つの表をticker ID、version ID、timezone、sessionで結びます。データ改訂、session差、code差を区別できない行は「同じ」と丸めず未解決のまま公開判定から外します。

公開判定用のavailability台帳には、各LTF barの開始時刻・終了時刻、対応するHTF開始・終了、予想した最初の利用可能時刻、実際に値が切り替わった時刻を別列で残します。値だけが同じでも、時刻が早ければ合格にしません。休日、短縮取引、extended session、gaps設定が異なるrunは同じ母集団へ混ぜず、境界ごとのcase IDを付けます。

negative controlも必須です。offsetなしのlookahead_on版を意図的に並べ、監査が早すぎる完成値を本当に検出できるか確認します。危険版まで合格する台帳は検出力がないため作り直します。confirmed版はHTF close前に前回確定値を保持し、close後の最初のeligible barでのみ更新し、reload後も同じbarへ残ることを四条件すべて満たして初めてCSV出力へ進めます。

未来参照を除去したstrategy結果だけをLabへ送る

known boundaryとreload後の両方で未来参照が消えたことを証明してから、修正版Strategy Tester CSV/XLSXをBacktest & Robustness Labへ読み込みます。漏洩あり／なしのversionについて、成績指標、DD、stress、OOS、parameter stabilityの差を追えば、未来情報が作っていた見かけのperformanceを切り分けられます。比較証拠を保持する段階では有料のversion管理が自然です。

無料インジケーターをMTF条件の観察に使う場合も、indicator plotはstrategy出力ではありません。source公開範囲、requested timeframe、確定値、alert timingを確認し、strategy変換は注文とfillを含む新しい仕様として扱います。