ルックアヘッドとリペインティング — シグナルを知れた時刻で検証する

未確定足、上位足、過去への描画を分け、シグナルを知れた時刻と表示位置を記録して未来情報の混入を確かめます。

公開 2026年5月26日 · 内容更新 2026年10月1日

チャートの矢印を見るときは、どの足に描かれたかに加えて、いつ初めてその矢印を知れたかを記録します。

後から開いたチャートでは底に矢印があっても、その底を付けた瞬間に売買判断へ使えたとは限りません。足が動いている間の一時的な条件、数本後に確認されたピボット、上位足が確定してから得られた値は、それぞれ情報を知れる時刻が違います。

リペインティングは、過去の計算・表示とリアルタイムの挙動が異なる現象を広く指します。未確定足の値が変わる通常の挙動も含まれ、すべてが不正や未来情報の使用を意味するわけではありません。ルックアヘッド・バイアスは、その判断時点で未入手だった情報を過去の判断に使う問題です。この2つを区別すると、何を修正し、何を利用条件として明記すべきかが分かります。TradingViewのリペインティングの分類

この検証では収益率より先に、情報の利用可能時刻を追います。ソースの版、全入力、正確な銘柄・取引所、時間足、チャート種類、セッション、履歴範囲を保存し、同じ条件のリアルタイム記録と再読み込み後の表示を比べます。

足が動いている間のシグナルには未確定の値が含まれます

進行中の足では高値・安値・現在値が更新されます。価格が条件を満たした時に現れたマークが、終了前に消えることはあります。その時に使ったのが実際に届いた価格なら、未来を読んだのではなく、条件が変化したということです。確定後のOHLCだけでは、この途中の変化をすべて再現できません。

インジケーターはリアルタイムの更新ごとに動作し、戦略は標準では足の確定時に計算します。戦略のcalc_on_every_tickを有効にするとリアルタイムの足内更新でも計算しますが、履歴OHLCから元の全ティックは戻りません。Pineの実行モデル

足中で取引する設計そのものを否定する必要はありません。その設計を確定足だけのバックテストでどこまで検証できるかが問題です。確定足を条件にするなら、シグナルが一時表示された時刻と最終的に残った時刻を分け、どちらを注文条件とするのかを決めます。

例1 · 現在値とチャート足の確定終値（Pine v6）

入力はありません。通常の5分足で、琥珀色のCurrent closeと緑のConfirmed closeの点を比べます。進行中の足では線が現在値に応じて動き、点はチャート足の終了更新で表示する設計です。履歴足は確定済みなので両方の値が一致します。足中の変化を見るには、実際の更新を記録します。

//@version=6
indicator("OptiNod - Open bar and confirmed close", overlay=true)
// Layout: Minimal Overlay. Educational indicator; no orders or alerts.
float confirmedClose = barstate.isconfirmed ? close : na
plot(close, "Current close", color=#f59e0b, linewidth=2)
plot(confirmedClose, "Confirmed close", color=#10b981, linewidth=2, style=plot.style_circles)

lookahead_offだけでは上位足の確定を保証できません

request.security()で上位時間足、HTFを参照するときは、表示先の足が閉じたことと、参照するHTFが閉じたことを区別します。5分足が1本閉じても、その足が属する1時間足はまだ進行中かもしれません。

HTFの現在の式にlookahead_onを使い、履歴上で最終値をHTFの開始側へ渡すと、その時点では未知だった値が過去へ漏れる場合があります。一方、標準のlookahead_offはその履歴上の先取りを防ぐ設定ですが、リアルタイムの未確定HTFの値まで固定する設定ではありません。再読み込み後に結果が変わる余地は残ります。異なる時間足のデータ

したがって、lookahead_onという語だけで不正と断定したり、lookahead_offという語だけで確定済みと判断したりしません。取得する式、時間足の関係、値が更新される時刻を一緒に読みます。

確定HTFを使う設計は、前のHTF足を参照します

チャートより厳密に上位の時間足で、確定済みの値を一貫して受け取りたい場合、公式文書が示す方法は、取得する式をHTF側で1本前へずらすexpression[1]とlookahead_onの組み合わせです。前のHTF足の確定値を、次のHTF区間の開始から利用する考え方です。式の1本ずらしと取り込み方をセットで扱います。確定したHTF値を取得する考え方

これは「いま形成中の1時間足の最終値」を早く知る方法ではありません。利用する値が前の1時間足になるため、反応の速さと確定性の関係が変わります。同じ時間足や下位足の取得へ、そのまま万能な修正として適用しないでください。

チャート足でのbarstate.isconfirmedは、そのチャート足の確定を調べます。参照するHTFまで確定させるものではなく、request.security()内に入れれば解決する条件でもありません。足の状態に関する公式説明

HTF検証の条件: 通常の5分足チャートで1時間足の値を観察します。各5分足の確定時刻と、参照した1時間足の識別時刻・値を保存します。確定HTFを使う設計なら、値が意図した1時間の境界で更新されるかを見ます。境界の途中で予期せず変わったら、注文への利用を保留して式と足の関係を調べます。

例2 · 直前の確定HTF終値（Pine v6）

通常の5分足で、上位時間足の入力を60にします。緑の階段線は、新しい1時間区間の開始から直前の1時間足の終値を使う設計です。[1]は取得する1時間足の文脈内に適用され、lookahead_onは既に確定した値を区間の開始から配置します。現在の1時間足の未来の終値を読む方法ではありません。同じ時間足や下位の入力はエラーで拒否します。進行中の1時間足の最新の動きには反応せず、データ改訂や別のコードによる過去描画までは解決しません。

//@version=6
indicator("OptiNod - Previous confirmed HTF close", overlay=true)
// Layout: Minimal Overlay. Educational indicator; no orders or alerts.
string higherTimeframe = input.timeframe("60", "상위 시간대", tooltip="차트보다 큰 시간대만 사용합니다. 5분 차트에서는 60분을 선택합니다.")
if timeframe.in_seconds(higherTimeframe) <= timeframe.in_seconds()
    runtime.error("Choose a timeframe strictly higher than the chart.")
float confirmedHigherClose = request.security(syminfo.tickerid, higherTimeframe, close[1], gaps=barmerge.gaps_off, lookahead=barmerge.lookahead_on)
plot(confirmedHigherClose, "Previous confirmed HTF close", color=#10b981, linewidth=2, style=plot.style_stepline)

実行で観察した結果と範囲 — Pine v6の両方の例をTradingView Pine Editorでコンパイルし、チャートで実行しました。通常のローソク足のOANDA:EURUSD5分足を短時間リアルタイムで観察したところ、例1の現在値は1.12886で、チャート足の確定終値はまだ表示されていませんでした。別に実行した例2では、現在の5分足の価格1.12892と直前の確定1時間足の終値1.12912が異なり、過去のチャートにも緑の階段線が表示されました。過去のAAPL日足の終了済みの足では、例1の両方の値が333.02でした。これらは観察時の値であり、取引条件や固定入力ではありません。

確認したのはチャート実行と短時間のリアルタイム観察までです。5分足の全期間や1時間境界の前後を連続で追跡していないため、再起動前後の一致やすべての市場での動作を検証した結果とは扱いません。次はソース・入力・市場・データ範囲を固定し、実際の足の終了とHTF境界を記録して、再実行の結果と照合します。

ピボットの位置と、ピボットを検出した足を区別します

右側に2本の足を必要とするピボットを考えます。候補の高値が足Aにあっても、判定に必要な右側2本が揃うのは後の足Cです。足Cで検出したマークを足Aに描画すると、履歴では最初から高値にマークがあったように見えます。売買条件に使えるのは検出後であり、表示位置をそのまま約定時刻にできません。

ZigZagも、設定した反転条件に達するまで最後の線分や候補の頂点が動くことがあります。形状を読む用途には役立ちますが、最終的な山や谷がその時点で既知だったという証拠にはなりません。採用する実装で何がいつ確定するかを確かめます。

負の描画オフセットは表示を過去へ動かす指定であり、未来の価格を読む履歴添字ではありません。Pineの履歴参照は過去の値を参照する仕組みです。表示位置をずらす操作と、情報が利用できる時刻を混同しないでください。描画のoffset、履歴参照演算子

アラートの終値設定にも確認できる範囲があります

「Once Per Bar Close」はチャート足の終了時に成立している条件で通知するための設定です。足中で一時的に成立した条件だけで通知する問題を減らせます。ただし、その条件が未確定のHTFに依存していれば、チャート足の終了後にも元のHTF値は変わり得ます。通知頻度だけを変えても、HTF参照は修正されません。

アラートが何のイベントを通知するのかも確認します。条件通知と戦略の注文約定通知は同じものではありません。作成済みアラートは作成時のスクリプト・入力などのコピーで動くため、チャート側を変更したら必要に応じてアラートを作り直します。TradingViewのアラートの仕組み

記録には表示マークだけでなく、アラートの設定、発生時刻、受信時刻、対象の足を残します。通知を受けた事実から、その時点に注文が約定したとまでは結論できません。

TradingViewの標準的な戦略計算では、足の確定時に作った成行注文は次の利用可能なティック以降に処理され、履歴では通常、次足の始値になります。process_orders_on_closeは終了時の処理を許す模擬約定の選択肢であり、それだけで未来漏洩と判定はできません。戦略の注文処理

未来情報を使っていなくても、終了後の通知から同じ終値で実際に約定できるとは限りません。データの利用可能時刻はコード・観察記録で、実行可能性は注文・約定記録で確認します。すべてのシグナルを1本遅らせるだけでは、未確定HTFや過去への描画を一律に解決できません。

再読み込みの比較は、同じデータ条件で行います

同じ差でも原因は複数あります。まずソースと入力を固定し、1つの候補を確認します。データ供給元の修正や読み込み履歴の変化も候補に残し、差が出たという事実だけで作者の意図や未来情報の使用を決めつけません。

Bar Replayに、実時間の記録と再読み込みの比較を加えます

Bar Replayで1本ずつ進めると、ピボットの検出遅れや過去への描画を調べやすくなります。取引CSVは履歴計算の時刻・数量・価格の照合に使えます。しかし、どちらも単独では当時の全ティックやリアルタイムの一時的な状態を証明できません。

検証期間を先に決め、コード・入力・市場条件を固定して観察します。各シグナルについて初回観察時刻、対象の足、チャート足とHTFの確定状態、アラート記録を保存します。期間後に同じ条件で再読み込みし、消えた・移動した・追加されたシグナルを照合します。足中取引の検証では、その間の値を残さないと未観察の変化が残ります。

勝率の数値だけで未来漏洩を診断することはできません。「non-repainting」という説明だけでも足りません。採用の根拠になるのは、どの情報がいつ使えたかを説明でき、その設計で記録と再計算の差を説明できることです。差が不明なシグナルを見つけたら、利益の良し悪しを評価する前に、初めて観察できた時刻へ戻って確認します。