PythonとPine Scriptのバックテスト：同じ売買戦略で結果が異なる理由

売買ルールは、バックテストを構成する一部分にすぎない

ビットコインがブレイクアウトしたという判断が一致しても、購入数量、約定コスト、報告する利益指標は異なり得ます。終値時点のシグナルは、注文を作成する指示です。その終値で約定したという記録ではありません。TradingViewは通常、一般的な成行注文を次に利用可能なティックで処理します。多くの場合は翌足の始値ですが、設定によって変わります。[1]

固定した1つの日足ビットコイン・ブレイクアウトルールで、この違いを調べます。宣言した4種類の執行規約を、まったく同じローソク足に適用します。以下の数値比較はすべてPythonで実行しました。ここで扱うPine Script実装はTradingViewでコンパイルも実行もしておらず、Pineからエクスポートした台帳もありません。したがって、測っているのは明示した規約の帰結であり、プラットフォーム間の成績比較を完了したとは主張しません。

本記事は、先のアルゴリズム構築の実例研究を発展させたものです。前の記事は研究の一連の手順を示し、Pineの数量決定とスリッページの違いを論じました。今回はその違いを明示的な実験にします。最後の節では、自分のPython実装とTradingView実装の記録を比較する方法を説明します。

経済的な問いと会計処理を、実行前に固定する

経済的な仮説は、持続的なトレンドが、繰り返す失敗ブレイクアウトの損失を補えるかもしれないというものです。55と20だけが利益を生む数字だという意味ではありません。執行の検証対象を一定にするため、前の記事のルックバック期間を維持します。純資産曲線が魅力的だから新たなルールを選べば、別の問いに答えることになり、選択の機会も増えます。

このワークフローで成績を計算する前に、仕様、設定、データ修正を記録しました。これは内部の研究記録であり、独立した事前登録ではありません。同じルールと重複する市場履歴は、すでに当サイトで研究済みです。2024～2025年は、固定した実装を時間順に評価する区間であり、未知だった市場から得た新たな証拠ではありません。

主な合格条件は機械的なものです。約定が記録した情報時点に従うこと、現金を借りないこと、決済済み損益と未決済損益の合計が口座純資産と一致することを確認します。経済的な評価には、同額予算の買い持ち、ドローダウン、摩擦コストへの感応度、利益集中を報告します。収益率がプラスというだけでは、運用開始の判断には足りません。

新たなデータ出所の照合で確認できたこと

主要な計算は、以前の研究で使ったデータセットにある2,142件の日次観測を使います。UTCの各日について6本の4時間足を集計したもので、humblefool06がHugging Face上でCC BY 4.0と宣言して公開したデータです。研究記録には、固定したリビジョン、帰属表示、変換の説明、SHA-256ハッシュを保持しています。前の研究で、その前日の不完全なデータを除外したため、保持した系列は2020年2月20日から始まります。今回は2025年12月31日までの固定した部分集合を使います。[3] [9]

別途、Binanceの公開市場データAPIから、2024～2025年の日足731本をすべて取得しました。始値・高値・安値・終値・出来高の計3,655項目は、すべて完全一致しました。検証レポートにリクエストURL、レスポンスのハッシュ、比較手順を記録しています。APIの生レスポンスを主要データセットとして再配布はしていません。Binanceの文書では、ローソク足の標準区切りはUTCであり、Klineは開始時刻で識別されると説明しています。[4]

これはファイルのハッシュ確認だけより踏み込んだ検査です。別の配信経路が評価期間の同じ足を報告するかを検証しているからです。ただし同じ取引所の照合であり、独立した価格監査ではありません。OHLCの価格で注文を約定できたことも示しません。ウォームアップと開発期間の履歴は、この731本のAPI照合の対象外です。

研究データの読み込み時には、日時の連続性、日付重複、有限かつ正の価格、OHLCの整合性を検査しました。再現可能でも、誤った系列は誤ったままです。データカードと本文で説明した照合手順によって、残る不確実性を見える形にします。説明を強めるために、専門家の査読者や第二の独立したデータフィードを架空に設けることはしません。

完成したシグナルで、その足の過去の始値では買えない

基準実装のループは、まず前日から保留した注文を当日の始値で執行し、次に当日の完成した終値でポジションを評価し、その後に当日分の次の指示を計算します。エントリーと決済のチャネルには、それ以前の足だけを含めます。エントリーチャネルに当日の高値を含めると、正しいOHLCデータでは、終値がその高値を厳密に上回るブレイクアウトは不可能になります。 情報を利用できる時点の検査については、先読みバイアスの検証をご覧ください。

entry_level = max(b.high for b in bars[i-55:i])
exit_level = min(b.low for b in bars[i-20:i])
# Evaluate only after today's completed close.
if quantity == 0 and bar.close > entry_level:
    pending = ("buy", bar.date)
elif quantity > 0 and bar.close < exit_level:
    pending = ("sell", bar.date)
# Execute pending on the next bar; never at this bar's earlier open.

約定時の現金配分を使う基準実装は、q = 0.9 × 現金 / [約定価格 × (1 + 手数料率)]で買います。ブローカーやシミュレーターは、執行価格が分かった時点で数量を計算できます。一方、前の終値時点で明示数量を指定するPine注文は、その時点で利用可能な情報を使う必要があります。代替実装はシグナル終値で数量を固定し、後で資金不足になった注文は拒否します。存在しない現金を補ったり、黙って数量を変更したりはしません。

人工的な価格ギャップを使うと、違いが分かりやすくなります。現金10,000 USDT、シグナル終値100、翌足始値110、コストゼロ、配分90%なら、約定時点の数量決定は81.818182単位を買い、現金1,000を残します。シグナル時点の数量決定は90単位を要求し、9,900を使って100を残します。約定時の純資産は両方とも10,000ですが、その後のエクスポージャーは異なります。この算例は説明用であり、測定したビットコイン履歴とは別です。

収益率を比較する前に、Pine版の規約を明示する

ここで扱うPine v6の設計は、確定日足、過去足のチャネル、明示したシグナル時点の数量、百分率手数料、標準機能の5ティック・スリッページを使います。独立した比較では、標準のBTCUSDT現物日足チャート、固定仕様の期間、十分なウォームアップ履歴、明示した設定を使う必要があります。この検証ではTradingViewでのコンパイルもStrategy Testerによる確認も行っていません。

混同しやすい単位が2つあります。5ベーシスポイントは価格の0.05%ですが、0.01 USDTの5ティックは0.05 USDTです。仮にビットコイン価格が100,000 USDTなら、不利な価格調整はそれぞれ50 USDTと0.05 USDTになります。ティック数は百分率ではありません。Pineの組み込みスリッページはティック数を受け取り、エントリーのqtyを明示すると、標準の百分率による数量設定より優先されます。[1]

Pythonのsignal-qty-ticksモデルは、明示したPineの規約を照合するための対象であり、TradingViewの完全な複製ではありません。フィードの更新、最小契約単位、数量の丸め、資金充足や証拠金のルールは、なお異なる可能性があります。基準実装は取引所のロット条件を適用せず、端数数量を許します。これらの模擬数量が、実際の取引所で有効な注文だとは主張しません。

calc_on_every_tickとcalc_on_order_fillsは宣言した標準値のままとし、process_orders_on_closeは無効にします。計算や注文処理の方針を変えると、別の実験になります。Pineの実行モデルは過去データとリアルタイム更新を区別するため、完成足では同等に見える戦略も、足の形成中には異なる動作をする可能性があります。[2]

基準実装は利益を出したが、収益ベンチマークには届かなかった

2024年1月1日から2025年12月31日までの評価731日間で、基準実装は10,000 USDTを12,445.81 USDTにしました。想定変動コスト控除後で+24.46%です。同じ初期配分の買い持ち口座は+96.28%でした。いずれも明示した期間の累積収益率であり、年率換算値ではありません。

戦略の日次終値ベースの最大ドローダウンは20.04%、買い持ちは30.86%でした。時価評価した投資比率の平均は37.59%で、731回の終値のうち300回はポジションを保有していました。売買代金の合計を初期純資産で割った回転率は12.96倍です。この指標は往復取引数ではなく、買いと売りの両方を数えます。

買い持ちは初期配分を全期間維持しますが、ブレイクアウト戦略は現金とビットコインを行き来します。収益が高くドローダウンも大きいというだけでは、完全なリスク調整後の順位づけにはなりません。具体的に言えるのは、ブレイクアウト口座が、指定した累積収益ベンチマークを上回らなかったということです。また、日次終値のドローダウンには、日中に発生して回復した損失は含まれません。

損失取引を、注文から現金残高まで監査する

評価期間で最初に損失確定した取引は、2024-01-02のシグナルを受けて2024-01-03に入り、2024-01-22のシグナルを受けて2024-01-23に決済しました。数量は0.19993623 BTCです。台帳は生の基準価格と、不利に調整した約定価格を分けて記録します。下表は実際にシミュレーションした約定を使っています。

エントリー代金は8,991.01 USDT、手数料は8.99でした。現金は10,000.00から1,000.00へ減りました。決済時の約定価格ベースの損益は-1,083.88で、両側の手数料を引いた純損益は-1,100.78 USDTです。最終現金は8,899.22でした。表示値を足した際のわずかなずれは丸めによるもので、研究の計算では完全な精度を保持しています。

スリッページは、すでにエントリーと決済の約定価格を変えています。表示したスリッページによる不利分を、約定価格ベースの損益から再び引けば、二重計上になります。この台帳の「取引の総損益」は、手数料控除前ですが、約定価格に含まれるスリッページ反映後です。一方、戦略全体のコスト控除前の別計算では、手数料とスリッページの両方を除きます。異なる計算に付けたラベルです。

決済取引の利益と口座純資産は、異なる問いへの答え

評価期間は未保有で終わるため、6件の決済取引で口座利益の全額を説明できます。より分かりやすいのは2023年の検証口座です。決済取引は669.03 USDTの損失でしたが、残る0.25356187 BTCの時価評価益は、支払済みエントリー手数料を差し引いた後で2,323.63でした。したがって口座全体の利益は1,654.60 USDT、+16.55%です。最終現金は933.10にすぎず、口座価値11,654.60の残りは保有在庫が占めました。

照合の恒等式は、初期純資産 + 決済純損益 + 未決済の時価評価損益 = 現金 + 保有在庫の時価 = 最終純資産です。各実行について、丸め前の精度で検査します。プラットフォームの決済取引指標と口座全体の収益率は、両方が算術的に正しくても異なることがあります。バグだと判断する前に、同じ量を比べてください。

最終終値で清算すれば別の問いに答えることになり、追加の売却手数料と不利な約定が生じます。実現損益と未実現損益を黙って切り替えず、未決済分を時価評価し、その規約を明示します。

このローソク足では、どの執行上の違いが効いたのか

数量決定だけを、約定時の現金配分からシグナル終値による固定数量に変えると、評価収益率は+0.0099パーセントポイント変わります。その数量モデルで5ベーシスポイントを5ティックに変えると、+0.6651ポイント、66.507521 USDT変わります。同じ足の終値での執行は、基準口座の最終残高をわずか+0.002848 USDT変えました。これはPythonで測った方針の効果であり、TradingViewで観測した不一致ではありません。

ビットコインは連続的に取引されるため、このサンプルでは隣接する日足の終値と始値が近いことがあります。ここで時点の影響が小さくても、別の市場、流動性の低い時間帯、遅延があるライブ実装で、同じ足の終値による約定が妥当になるわけではありません。人工的なギャップの例は、同じ実装上の選択が、別の価格経路で大きく効く理由を示します。

実装同士を照合する際は、純資産曲線より先に約定記録を比較してください。最初に異なる数量や価格を見つけ、その現金への影響を後ろへ追います。後続の配分は過去の現金に依存するため、差は累積します。最終収益率が似ていても、取引の仕組みが一致した証拠にはなりません。

コストと、特別に大きな利益取引への依存を調べる

基準実装は12回の約定で129.58 USDTの手数料を支払いました。コスト表では片道手数料を10 bpに固定し、不利な価格調整を変えています。調整ゼロでも、コストゼロの口座ではありません。前の表のコスト控除前の戦略行は、手数料もスリッページもない別計算です。ここでは過去の売買スプレッドを推定せず、スプレッドと執行上の不利分を1つの価格調整にまとめて仮定しています。 コスト区分を広く確認するには、取引コストの分析をご覧ください。

決済取引の平均純損益は407.63 USDTでした。平均利益取引は1,748.18、平均損失取引は-932.91です。決済取引のプロフィットファクターは1.87、勝率は50.00%でした。金額の平均は、変化していく口座規模に依存します。これらは台帳の記述統計であり、次の取引の安定した予測値ではありません。

利益が最大の3件の決済取引は、5,244.53 USDTをもたらしました。口座損益の合計からこの寄与を引くと、-2,798.72が残ります。これは集中度を調べる算術であり、その取引を見送って後続数量を再計算した実行ではありません。年次収益率にも経路が表れます。2024年は+38.44%、2025年は-10.10%でした。暦年の収益率は、毎年新しい口座を作るのではなく、連続した評価口座から計算しています。

採用しなかった候補も、読者に見える形で残す

エントリー期間35・55・80と決済期間10・20・30を組み合わせた9候補を宣言しました。表は、すべての開発結果をコスト控除後で示しています。順位にかかわらず55/20を維持するため、比較がいつの間にか、最も見栄えのよい執行結果を探す作業になることはありません。

9候補中8候補はプラスですが、収益率は−9.22%～+21.32%に広がります。35/30は損失で、決済期間は結果を大きく変えます。維持した55/20も、結果的に1位でした。選択記録は今回の実行より前ですが、前の記事ですでにこのルールを知っていました。この一致は独立した追認ではありません。同じ市場履歴を共有する結果には相関があり、期間分割やグリッドで既知の知識は消えません。Baileyらはバックテスト選択の過剰適合を分析していますが、今回のグリッドは、同論文の正式な過剰適合確率推定量ではありません。[5]

2区間のウォークフォワード検証では、先行データだけを使う記録済みの選択手順を調べます。訓練収益率が最大の候補を9候補から選び、次の年で評価します。テスト年は2022年と2023年で、2024～2025年を選択には使いません。これらは診断のための追加検証であり、最終口座に対する新たな未使用の証拠ではありません。

選択手順は、その次の期間でも試されなければならない

各区間は10,000 USDTから再開し、それ以前の足を指標のウォームアップに使い、選んだパラメーターを変更せず適用します。訓練で良い順位だったことは、候補をテストしてよいという意味にすぎず、テスト結果を与えるものではありません。

選択したパラメーターと、その後の収益率の両方を残します。後続期間が損失なら、その失敗もレポートに残します。記事に利益結果を載せるために、新しいフィルターを加えたり、主要ルールを再調整したり、最終期間を繰り返し参照したりはしません。

モンテカルロの経路は、証拠を増やさず並び方を変える

基準口座で観測した731日の日次純収益率を、連続20日の円形ブロックで再標本化し、系列の末尾では先頭に戻ります。各模擬経路の日数と初期資金は同じです。固定シード6142026で5,000経路を生成するため、計算を再現できます。日ごとのシャッフルと異なり、ブロックは一部の局所的な系列依存を保ちます。ブロック長は明示したモデル上の選択であり、最適値を推定したものではありません。[6]

模擬累積収益率の中央値は+20.98%、5・95パーセンタイルは-38.34%と+166.29%でした。最大ドローダウンの中央値は30.22%、95パーセンタイルは50.12%です。損失となった模擬経路の割合は32.28%でした。これらは条件付きの経路要約であり、将来損失の較正済み確率やアルファの信頼区間ではありません。

口座収益率の再標本化は、新しいローソク足を生成せず、ブレイクアウト判断を再実行せず、新たな流動性環境や欠けた危機を補いません。今回はベンチマーク相対成績をブートストラップしていません。経路を増やすと、選んだ手順に伴うモンテカルロ誤差は減りますが、根拠となる過去の証拠は同じ731日と同じ取引系列のままです。

各段階で、検証可能な作業をアシスタントに依頼する

ChatGPTとClaudeは、ルールの言語化、会計上の不一致の説明、レポートへの反論を支援できます。CodexとClaude Codeは、リポジトリを調べ、ファイルを編集し、開発コマンドを実行できます。文書に記載されたこれらの能力は作業を支援しますが、利益の出る売買アルゴリズムの証拠にはなりません。今回の検証は、リポジトリ開発にCodex、計算にPythonを使いました。ChatGPT対Claudeの統制実験は行わず、どちらにも売買シグナルを予測させていません。[7] [8]

最初に、情報を利用できる境界を決めます。厳密比較か等号を含むか、過去足の窓、発注・約定の時点、現金予算、丸め、最終在庫など、未解決の詳細は実装前に明らかにすべきです。最初のプロンプトは再利用できる依頼文であり、モデル比較実験を記録したという主張ではありません。

コーディング前に、この売買アイデアを実行可能な仕様へ変換してください。経済的な仮説、エントリーと決済、各入力が使う足、シグナルの利用可能時点、発注と約定の時点、数量と現金の制約、コスト、タイムゾーン、最終評価、時間順の期間、ベンチマーク、判断基準を明示してください。未解決の選択肢を一覧化してください。過去の結果が改善するという理由でルールを選ばないでください。

次に実装を制約します。状態機械とテスト用データを求め、バグ修正の依頼に戦略最適化を紛れ込ませないようにします。有用な未来データ検査は、時点tより後の価格を変えても、それ以前の判断や約定が変わらないことを確かめます。有用な会計検査は、最後の取引が未決済でも、現金、在庫、手数料を照合します。

添付の固定済み仕様を正確に実装してください。シグナル、注文作成、約定、現金会計、報告を分離してください。フィルターの追加やパラメーター最適化はしないでください。当該足の除外、翌足始値の時点、手数料込みの数量決定、資金不足の注文、最後の未決済ポジションに人工的なテストデータを用意してください。各ルールとコード・テストの対応を示してください。

デバッグでは、最初の不一致から行単位で比較します。報告では、ファイルに基づく数値と、未実行の部分に対する明示的な状態表示を求めます。市場データが観測を供給し、実行可能なコードが計算し、どの仮定と比較を信頼するかを研究者が判断します。

この2つの正規化済み台帳を日時順に比較してください。入力足、シグナル、要求数量、約定価格、手数料、ポジション、純資産の最初の違いを見つけてください。記録した設定と行の値を使って説明してください。初期純資産に決済済み・未決済の損益を加えた値を、最終純資産と照合してください。戦略を再調整したり、最終収益率だけからバグを推測したりしないでください。

提供した設定、データマニフェスト、実行済み結果ファイルだけから報告書を作ってください。試した全候補、期間境界、コスト控除前後の収益率、ベンチマーク、ドローダウン、エクスポージャー、回転率、利益集中、未決済ポジションの会計を含めてください。すべての表を元ファイルにリンクしてください。未実行コードと未実施の検査を明示してください。不利な結果を残し、架空の査読やモデル比較を作らないでください。

自分のTradingView実行をどう照合するか

自分のPine実装とPython実装を比較する際は、同じ銘柄と期間の標準日足チャートを使い、Pineソース、設定、チャートフィード、エクスポートした取引を保存してください。シグナルを切り分ける際はゼロコストから始め、その後で両エンジンに手数料と同じティック単位のスリッページを加えます。口座収益率より先に、シグナル日と取引を比較します。ロット単位やフィード履歴の違いは、丸めて消さず、不一致として記録してください。

両方の約定記録を、日時、売買方向、要求数量、基準価格、約定価格、手数料、約定後のポジション、現金、純資産という共通スキーマにそろえます。エクスポートの各項目について、タイムゾーン、単位、丸めを含めて対応関係を明示してください。本文のシグナル数量・ティックコストのPython規約を比較対象にします。これは診断手順であり、各言語のStrategy Testerエクスポート形式が同じだという主張ではありません。Pineの実行結果をエクスポートしない限り、エンジン間の結果は未検証です。

この順序は、利益が出たバックテストが実運用で損失になる理由も説明します。ライブシステムは、別の足を受け取ったり、発注が遅れたり、少ない数量で約定したり、別のスプレッドを支払ったりするかもしれません。記録が一致した後にも成績が悪ければ、それは戦略と市場の問いになります。執行仮定を変え続ける口実にはなりません。