TradingViewの注文はどう約定する？Broker EmulatorとBar Magnifierの仕組み

Strategy markerは、Broker Emulatorが作った模擬fillの記録

TradingView strategyはorder commandを作り、Broker Emulatorが次に利用可能なtickまたは価格条件でfillを模擬します。 codeが条件barで注文を生成した時刻と、markerが表示されるfill時刻は同じとは限りません。market order、price-based order、process-on-close等で境界が変わるため、List of Tradesとchart markerだけでなく、order typeと作成barも照合します。

この仕組みは、過去のbarへ機械的に同じruleを適用するためのsimulationです。brokerのorder book、実際のspread、通信遅延、rejection、partial fill、価格改善を自動で復元しません。したがって「Strategy Testerで104に約定した」ことは、「同じ日時の実口座でも必ず104で約定した」という証拠ではありません。

OHLCだけの履歴barではintrabar経路を仮定する

OHLCはbar内で到達した四点を示しますが、すべてのtick順序を保存していません。Broker Emulatorはopenがhighとlowのどちらに近いか等の規則から、open→high→low→closeまたはopen→low→high→closeという経路を仮定します。entryとexitの両水準が同じbarのrange内にある場合、この順序が結果を変えます。

価格がrangeへ触れたことと、十分な流動性で注文全量が約定したことは同義ではありません。

失敗境界は四種類に分けます。注文が作られる前に同じ価格へ触れていても、その接触は約定証拠になりません。前bar終値と次bar始値の間を飛び越えたgapでは、指定価格を順番に通過したと仮定できません。同一barの高値と安値にentryとexitが両方含まれても、entry後にexitへ到達した順序が必要です。limit注文では価格条件に加え、現在のverification設定と注文が有効だった期間を確認します。

market・limit・stop・stop-limitの役割を分ける

market orderは価格を指定せず次の利用可能な機会でfillを求めます。limit orderは指定価格以上に不利にならない条件、stop orderはstop到達後にmarket型の注文をactivateする考え方、stop-limitはstop activation後にlimit条件を持ちます。同じ「線へ触れた」表示でも、注文種類によって必要なeventが違います。

正確な現在仕様はTradingView公式StrategiesとBroker Emulator資料を確認してください。

chart barのcloseで条件を評価してmarket orderを作る標準的なstrategyでは、markerが次barのopen側に現れることがあります。これを「signalが遅れた」とだけ表現すると原因が不明です。条件確定時刻、order creation、next available tickという三段階で説明します。

下位時間足で経路を細かくしても、coverageを確認する

Bar Magnifierを有効にすると、Broker Emulatorは利用可能な下位時間足dataを参照し、chart barのOHLCだけに基づく既定経路より細かなintrabar情報でfillを模擬します。同じchart bar内でentry後にexit水準へ到達した順序を確認できれば、既定仮定では起きなかったsame-bar exitが生じる場合があります。

ただし下位足dataの取得上限があり、長いhistoryの初期部分ではcoverageがないことがあります。plan、symbol、chart timeframe、available lower timeframeも影響します。Bar Magnifier ONという一項目だけを保存せず、どの期間に適用されたか、比較sampleの何件がcoverage内かを確認します。

coverage内でも実市場約定の証明にはなりません。ここで証明するのは、どの模擬fillがどの粒度のchart dataに基づいたかです。

注文種類とBar Magnifier設定をsourceへ残す

下のPine v6 sampleは、確定barの架空crossからbuy stopを生成し、position成立後にstopとlimitのexitを置きます。`use_bar_magnifier = true`を明示しますが、機能availabilityと適用coverageは実環境で確認が必要です。EMA期間、10 ticks、20 ticksは教育用で、推奨entry・stop・targetではありません。

//@version=6
strategy(
    "Intrabar fill audit demo",
    overlay = true,
    use_bar_magnifier = true,
    calc_on_order_fills = false,
    process_orders_on_close = false
)

float basis = ta.ema(close, 20)
bool setup = ta.crossover(close, basis) and barstate.isconfirmed

if setup
    float entryStop = high + syminfo.mintick
    strategy.entry("L", strategy.long, stop = entryStop)

if strategy.position_size > 0
    float protectiveStop = strategy.position_avg_price - 10 * syminfo.mintick
    float target = strategy.position_avg_price + 20 * syminfo.mintick
    strategy.exit("L-X", "L", stop = protectiveStop, limit = target)

plot(basis, "EMA", color.orange)

source codeだけで実際のfillを説明できるとは限りません。List of Tradesからentry/exit barとpriceを取り、chart O/H/L/C、下位足coverage、order creation logと突き合わせます。`calc_on_order_fills`や`process_orders_on_close`を変更する比較は、TV15のexecution auditと組にしてください。

驚いたfillから順に一件ずつ反証する

空欄を推測で埋めず、説明不能も監査結果として残します。

まず高利益tradeではなく、同一barでentry/exit、gap fill、limit touch、長期history初期など仮定へ敏感なtradeを抽出します。変更後に成績が悪化しても削除せず、どのfill assumptionへ依存していたかをversion差として保存します。

再現手順では、対象tradeを含む期間を固定し、最初に既定経路版、次にBar Magnifier版を同じsource hashとPropertiesで実行します。両方から同じ形式の取引一覧を出力し、trade IDがずれた地点から一件ずつ照合します。さらに別の日に同じchart contextを開き直し、coverage開始位置、注文時刻、fill価格が同じ説明で再構成できるか確認します。成績が良い方を先に採用せず、説明不能件数と未covered件数を合否条件へ使います。

約定前提を監査してから結果dataをLabへ渡す

驚いた約定ごとの反証ログとBar Magnifierのcoverage記録がそろったら、対応する約定一覧（CSVまたはXLSX）をBacktest & Robustness Labの比較画面へ投入します。そこでequity curve、DD、取引分布をMagnifier OFF/ONや保守的fillの各versionで照合できます。前提を保った比較を継続保存したい段階が、有料のversion比較へ移る自然な時点です。

無料インジケーターはsignal条件の観察に使えますが、indicatorはstrategy orderやStrategy Testerの取引dataを自動生成しません。注文ruleを別途strategyとして定義し、fill監査を終えてからLabへ進みます。Bar Replay、Paper Trading、Broker Emulatorも互いの代用品ではありません。