バックテストで利益が出てもライブで損失が出る場合、しばしばスリッページが原因として挙げられますが、まずPine Scriptのrequest.security()関数の特定の問題を確認する必要があります。この問題はTradingViewによって文書化されており、高時間足データの使用方法に関係しています。デフォルトでは、request.security()はbarmerge.lookahead_offを使用し、将来のデータ漏洩を防ぎます。しかし、認識されている1バーの遅延を回避するためにlookahead=barmerge.lookahead_onを設定すると、重大な欠陥が生じます。この設定により、バックフィルはライブ取引ではまだ利用できないデータを取り込むことができます。例えば、現在の価格を高時間足の終値と比較する戦略は、日中のバーのバックテストでは将来の終値を使用します。ライブでは、この将来のデータは存在しないため、不一致が生じます。この問題は、ライブでは発見が難しいため、巧妙です。リアルタイム取引中、将来のデータが存在しないため、lookahead_onとlookahead_offの両方のシリーズは同じ値を示します。しかし、リアルタイムのバーが閉じられて履歴になると、「再描画」され、完全な履歴記録で再計算され、ライブで観測されたものから乖離します。これは、一見正常に機能しているライブセッションが、チャートをリロードすると完全に変わる可能性があることを意味します。関連するバリアントは、request.security()がチャート自体の解像度以下の時間足に使用される場合に発生します。この場合、lookahead設定によってどのイントラバーの値が返されるかが決まり、バックテストとライブ実行の間で不一致が生じる可能性があります。これを診断するには、スクリプトユーザーはすべてのrequest.security()呼び出しで「lookahead_on」を調べる必要があります。見つかった場合は、明示的な履歴オフセットが適用されていることを確認してください。さらに、同じまたはそれ以下の時間足のリクエストに対するイントラバーの選択を確認してください。再描画の直接的な症状は、最近閉じられたバーの値がスクリプトのリロード後に変更されることです。履歴的に利用可能なデータとライブで知ることができるデータとのこの重要な区別は、信頼性の高い戦略パフォーマンスにとって不可欠です。