OptiNod アカデミー
バックテストと実運用 — 最初に違った取引から原因を確かめる
同じ条件で比較を始め、シグナル・約定・費用のどこで結果が分かれたかを、取引ごとの記録で確かめます。
曲線を比べる前に、同じ戦略・同じ市場・同じ期間を比べているかを揃えます。原因を調べる入口は、損益の合計ではなく最初に違った取引です。
同じ戦略名でも、ソースコードの版、入力値、取引所、現物か無期限先物かが違えば、結果の差を約定コストだけで説明できません。まずコードと入力を保存し、完全な銘柄識別子、通常のローソク足、時間足、セッション、読み込んだ履歴、検証の開始・終了時刻を揃えます。
次に初期資金、口座通貨、注文数量の単位、複利・固定数量の区別、ピラミッディング、手数料、スリッページ、注文処理と再計算の設定を記録します。日付が同じでも、指標の初期化に使った開始前の履歴が違うと、最初のシグナルから分かれる場合があります。見た目の時間帯と取引所のセッション時刻も混同しないようにします。
バックテストは、これらの条件に基づく模擬取引です。実運用は、届いたシグナルから実際の注文・約定までを含みます。差が出たら「実運用は常にバックテストより悪い」と決めず、シグナル、発注、約定、費用の順に証拠を揃えていきます。
比較用の記録には、ソースの保存版と全入力値、データ提供元と正確な銘柄・取引所・契約、通常足か合成足か、時間足とセッション、履歴の範囲、検証期間をまとめます。先物なら契約乗数や数量単位も必要です。銘柄名が似ていても、異なる取引所や契約の値動きが完全に一致するとは限りません。
資金条件も同じにします。各注文が「口座資金の何%」なのか「一定の数量」なのか、「注文金額」なのかを揃えないまま収益率を比べると、戦略の差とポジション量の差が混ざります。分割約定、部分決済、ポジション反転を、比較する両側で同じ取引に対応づけます。
TradingViewの設定では注文量、手数料、スリッページ、再計算などを個別に指定します。通常のローソク足を比較の基準にし、Heikin AshiやRenkoなどの合成価格を実際に売買できた価格として扱わないことが大切です。戦略プロパティと非標準チャートのデータで前提を確認できます。
検証の開始条件: 同じ保存版・入力・銘柄・期間で取引一覧を出し、最初の不一致を1件選びます。比較に入れる約定は注文IDと数量で対応づけます。前提の不一致が見つかったら損益原因の判定を止め、条件を揃えて再実行します。
シグナルの計算時刻と注文の約定時刻を分けます
TradingViewの戦略は、標準設定では足の確定時に計算し、そこで生成された成行注文は最も早くても次のティックで模擬約定します。履歴上では通常、次の足の始値です。「シグナル足の終値で約定する」が標準設定ではありません。また、次の足の始値という記録は、丸々1本分の時間を待つという意味ではありません。TradingViewの注文作成と約定
process_orders_on_closeは、足の終了時に注文を処理できるようにする選択肢です。この模擬処理を有効にしたことだけで、未来の情報を使うルックアヘッドと断定はできません。ただし、終了後に送られたアラートから実際の同じ終値で約定できるかは別の問題です。市場の休場、通信、取引所への到着時刻によって約定は変わります。約定設定の説明
照合では、シグナルが成立した時刻、アラート送信、注文受付、各約定を別々に残します。指値や逆指値は足の途中で条件に達することもあるため、すべての注文を「次の足の始値」に置き換える必要もありません。まず対象の注文種別と発注時点を合わせます。
比較用の設定 — 通常の15分足で確定終値のシグナルだけを比較し、成行注文は標準のエミュレーター方式で記録します。エントリーはシグナル後の最初の可能な約定、損切りは先に決めたシグナル足の安値より下の価格に固定します。取引の推奨ではありません。シグナル時刻・数量・損切り規則が異なる取引は約定品質の比較から除外します。
スリッページは基準価格と注文条件を揃えて測ります
スリッページを調べるには、比較する基準価格を決める必要があります。シグナル時の終値、送信時の気配値、取引所が注文を受けた時の気配値では、含まれる遅延が異なります。実際の平均約定価格との差を測り、買いと売りで不利な方向の符号を揃えます。有利な約定差が生じる場合もあります。
同じ金額でも板の厚さ、スプレッド、注文の種類、時間帯で結果は変わります。部分約定や未約定の指値を除外すると、都合のよい約定だけが標本に残ります。約定価格に加えて、要求数量、約定数量、未約定・取消の記録を保存します。
全銘柄に共通する最低bpを置くより、自分の銘柄・注文量・注文種別から通常時と不利な局面の分布を作り、複数の費用条件で再計算します。TradingViewの固定スリッページはティック単位の仮定であり、板の待ち行列を再現するものではありません。スリッページの設定
手数料は売買代金、ファンディングは決済時の保有で計算します
手数料は実際の料率、maker・takerの区別、割引やリベート、契約仕様に合わせます。「往復0.1%」と「口座資金の0.1%」は同じではありません。元の資金に対して何回売買したかだけで、費用を計算しないようにします。
説明用の仮定として、新規建てと決済の売買代金がそれぞれ1,000ドル、各約定の手数料が0.05%なら、往復費用は1ドルです。同じ取引を100回行うと100ドルです。口座資金の何%になるかは資金と数量によるため、取引回数に往復手数料率を掛けた値をそのまま口座収益率から引いてはいけません。
無期限先物のファンディングは、決済時点の保有額、料率の符号、ロング・ショートで受払いが決まります。取引回数に比例するとは限らず、決済間隔も商品や状況によって異なります。8時間固定や常に支払う費用とせず、対象契約の履歴を使用します。取引コストの確認
計算結果を口座の手数料・ファンディング明細と対応づけ、約定価格にすでに含まれた差を二重に差し引いていないかも点検します。費用の修正後も利益が残るかは、そのデータで改めて確認する必要があります。
同じ足で利確と損切りに触れた取引は経路を確認します
OHLCには高値と安値がありますが、その4点だけで全ティックの順番は分かりません。すでに有効な利確・損切り注文の両方に同じ足が触れたなら、先に実行可能になった注文によって結果が変わります。注文がまだ出ていなかった時点の高値に触れたことを、約定の証拠にはできません。
仮想例としてエントリー100、損切り98、利確103のロングを考えます。その足の高値104・安値97だけでは、どちらの決済が先だったかは分かりません。
TradingViewの標準ブローカーエミュレーターは始値と高値・安値の位置関係から足内経路を仮定します。「必ず損切りを優先する」という規則ではありません。Bar Magnifierを使うと利用可能な下位足データを約定推定に使えますが、実際の板、約定待ち順位、通信、すべてのティックまで再現できるわけではありません。ブローカーエミュレーター
両方に触れた取引を抽出し、下位足の対象期間が揃う範囲で設定を変えて比較します。結果が大きく変わるなら経路仮定に敏感な戦略です。細かいデータがない区間はその制約を残し、どちらの結果も実際の約定として確定しません。
過去のデータにも、その時点で知れた範囲があります
現在取引できる銘柄だけを使って過去の銘柄選択を評価すると、上場廃止銘柄などを除く生存者バイアスが入り得ます。銘柄集合を使う戦略なら、その時点の採用条件と上場状況を復元します。欠損データを単純に利益ゼロの期間として扱うのも避けます。
ルックアヘッドは、判断時点で未入手の情報を過去の判断に使う問題です。上位足の最終値を確定前に過去へ割り当てたり、全検証期間から作った統計量で前半を判断したりしていないかを調べます。進行中の足の現在値が変動すること自体は、未来を読むことではありません。確定値だけが必要な戦略なら、その情報がいつ確定するのかを別途設計します。リペインティングの区別
後からの価格修正や履歴の追加も、再計算した結果を変える場合があります。元データの取得時点と比較時点を残せば、コード変更、データ変更、計算条件の違いを切り分けやすくなります。
症状から証拠を選ぶと、修正の順番が決まります
| 観察した症状 | 原因の候補 | 確かめるテスト・証拠 | 判断の限界 |
|---|---|---|---|
| シグナルの足から異なる | ソース・入力・市場・履歴・HTF確定条件の差 | 比較条件の保存版と同時刻の入力・シグナルを照合 | 取引CSVだけではシグナルの存在時刻を証明できません |
| シグナルは同じで約定価格が異なる | 注文時刻、遅延、スプレッド、スリッページ | 送信・受付時刻、気配値、注文ID、平均約定価格 | 当時の板がなければ影響を完全に分解できません |
| 利確と損切りの結果が逆 | 足内経路、注文の有効時点、指値の未約定 | 下位足と注文履歴、Bar Magnifierの比較 | 下位足でも板と待ち順位は復元できません |
| 取引は揃うが純利益が異なる | 数量、契約乗数、手数料、資金調達、換算 | 約定代金と費用明細を取引単位で再計算 | 丸めや決済通貨の違いも確認が必要です |
| 実運用だけ取引が欠ける | アラート未達、注文拒否、最小数量、未約定、ポジション制限 | アラート・注文ID、拒否理由、要求・約定・残数量と利用可能残高 | 通知やAPI受付の成功だけでは約定の証拠になりません |
| 再読み込みでシグナルが変わる | 未確定HTF、足中計算、過去描画、データ改訂 | 先に保存した観察記録と再読込後の同一区間 | 差だけで未来漏洩と断定はできません |
| 最適化した期間だけ良い | 反復選択、期間固有の条件、データ漏洩 | 試した設定と選択基準を保存し、別期間で同じ手順を評価 | 成績の低下だけでは過剰適合やリペインティングを断定できません |
条件を一度に全部変えず、選んだ原因候補について1項目ずつ変更し、同じ取引の差がどう動いたかを残します。たとえば手数料だけを修正してシグナル位置まで変わるなら、資金依存の注文量など、計算に戻る経路も調べます。
選んだ条件だけを変え、最初の同じ取引を再比較します。資料がなければ原因は未確定のまま残し、次の観察で必要な記録を集めます。反復選択の検証はウォークフォワード分析で扱います。別期間の成績低下だけで原因を断定しません。
取引一覧の一致に、実時間の記録を重ねます
TradingViewと別エンジンを比べるときは、同じ条件の取引一覧を出し、エントリー・決済の時刻、方向、数量、価格から対応づけます。合計利益だけの一致よりも、不一致がどの取引から始まるかが役立ちます。ただし一覧が一致しても、両方が同じ不適切な前提を使っている可能性は残ります。
CSVとBar Replayは履歴計算の調査に使えますが、当時リアルタイムでシグナルが存在したことを単独では証明できません。コード・入力の保存版、アラート作成条件、時刻付きの画面や値、送信・注文・約定記録を前向きに保存し、後から再読み込みした同じ区間と照合します。既存記録に不足がある箇所は、次の観察で埋めます。
差を説明できない状態で、良い曲線に合わせてパラメーターを変更し続けると、原因を隠してしまいます。まず最初の不一致に戻り、どの情報と注文がその時点で存在したのかを確かめます。その手順が、過去の数字を採用する根拠と、まだ検証できていない範囲を分けます。
戦略の適用とコスト・期間の設定は、TradingViewバックテストの基本ガイドの実行例で確認できます。