バックテストとは、過去の相場データに売買ルールを当てはめて「もしこのルールで取引していたら」を計算する検証手法である。結論を先に書くと、バックテストで出た右肩上がりの資産曲線は、そのままでは実運用の予測にならない。理由は成績が悪いからではなく、計算の前提そのものが実際の取引と何箇所もずれているからだ。
この記事は、その「ずれ」を7つに分解して具体的に潰していく。加えて、編集部が2026年4月から実口座で続けているAI自動売買の検証運用で、実際に机上の想定と現実が食い違った箇所も併せて書く。良い結果だけでなく、うまくいかなかった部分も含めて出す。数字の裏付けがない一般論より、そのほうが役に立つはずだ。
編集部が実際にやっていること
前提として、こちらの検証内容を明示しておく。読者が数字の重みを判断できないまま読むのはフェアではないからだ。
2026年4月から、Claude Codeにトレード判断を任せる自動売買を実口座で継続運用している。取引の場はオンチェーンDEX（GMX）の永続契約で、毎朝6時に起動して翌朝に自己終了する日次セッションを繰り返し、24時間ポジションを監視する構成だ。入金は当初188ドル、その後400ドルを追加。実現損益は約-21ドルで、これは2026年7月上旬にオンチェーンの記録と突き合わせた監査で確定させた数字である。
設定はレバレッジ10倍、利確+3.5%、損切り-4.5%、トレーリングストップ併用、建玉下限400ドル。戦略はモード判定式で、レンジ相場と判断すればレンジ端での逆張り、トレンド相場と判断すれば押し目の順張りに切り替える。
つまり、現時点で自慢できる成績は出していない。だからこそ「机上の検証では見えなかったもの」の一覧としては、それなりに正直な材料になっていると思う。以下の7つの落とし穴は、その多くを実際に踏んだ上で書いている。
バックテストで「分かること」と「分からないこと」
個別の落とし穴に入る前に、この道具の守備範囲を整理しておく。
| 分かること | 分からないこと |
|---|---|
| ルールが論理的に破綻していないか | 実際の約定価格（スリッページ） |
| おおよその取引頻度とポジション保有時間 | 板の厚みが足りない場面での不成立 |
| 最大ドローダウンの概算 | 取引所の障害・APIエラー・遅延 |
| パラメータを変えたときの感度 | 自分の注文が相場に与える影響 |
| 相場レジームごとの得手不得手 | 未来の相場が過去と似ているかどうか |
要するにバックテストは「このルールは検証に進む価値があるか」を判定するふるいであって、期待収益の見積もり装置ではない。ふるいとして使う分には極めて有用だが、収益予測として読んだ瞬間に道を誤る。
落とし穴1: 未来を覗いている（ルックアヘッドバイアス）
最も多く、最も気づきにくいのがこれである。バックテストのエンジンは過去データ全体を一度メモリに読み込み、インジケーターをまとめて計算する。この構造上、うっかり書くと「その時点ではまだ知りえない値」を参照してしまう。
典型的な混入経路は次のとおりだ。
shift(-10)のように負の値でずらして未来の足を参照する- 判定関数の中で
iloc[]によって行を直接指定する - ループ処理で後続行にアクセスする
.mean()や.max()をローリング窓ではなくデータ全体に対して計算する- インジケーターのパラメータ設定そのものが未来を含んでいる
Freqtradeにはこれを自動検出するコマンドが用意されている。基準となるバックテストを実行した上で、各エントリー・エグジットシグナルごとに個別のバックテストを走らせ、インジケーターの値と取引タイミングの食い違いを比較して混入を検出する仕組みだ。
freqtrade lookahead-analysis -s MyStrategy -i 5m \
--timerange 20250701-20260701 \
--minimum-trade-amount 10 \
--targeted-trade-amount 50 \
--lookahead-analysis-exportfilename lookahead.csv
このコマンドは誤検出を防ぐため、実行時にキャッシュ無効化・同時ポジション数をペア数と同数に設定・成行注文の強制・保護機能の無効化を自動で行う。ただし万能ではない。公式ドキュメントも「発火しなかったシグナルは検証されないため偽陰性につながる」と明記している。ツールが通ったから安全、ではなく「明白なものは潰せた」程度に受け止めるのが正しい。
落とし穴2: ローソク足の中身を知らない
バックテストが参照できるのは、1本の足につき始値・高値・安値・終値の4つだけである。1時間足なら、その1時間の中で高値と安値のどちらが先に来たかを、エンジンは知らない。
これが致命的になるのは、利確条件と損切り条件が同じ足の中に同居した場合だ。実際には損切りに引っかかってから反発したのに、バックテスト上は利確扱いになる（あるいはその逆）という判定が起こる。エンジンは内部の優先順位ルールで機械的に処理するしかなく、Freqtradeの場合はエグジットシグナル、損切り、ROI、トレーリング損切りの順で評価される。損切りがROIより先に評価されるため、同じ戦略でもドライラン・実運用と比べて「損切り」を理由とする取引が多く出やすい、という差が生じる。
対処法は、より細かい時間足を同時に読み込ませることだ。
freqtrade backtesting --strategy MyStrategy \
--timeframe 1h --timeframe-detail 5m \
--timerange 20250701-20260701
詳細足を使うと結果が大きく変わりうる、と公式も明記している。ポジションを保有している間だけ細かい足で判定するため、決済タイミングが早まって次のエントリー枠が空き、本来なら発生しなかった取引が生まれることもある。逆に言えば、詳細足を入れたら成績が崩れる戦略は、元の結果が足の内側の曖昧さに寄りかかっていたということになる。
落とし穴3: 手数料とスリッページを甘く見ている
多くのバックテストエンジンは「要求した価格が足の高値・安値の範囲内にあれば、その価格で全量約定する」と仮定する。スリッページはゼロという前提だ。
実際にはそうならない。指値は板が届かなければ約定しないし、成行は板を食って不利な方向にずれる。そして手数料は往復で確実に引かれる。仮に往復0.12%のコストがかかる環境で1日10往復すると、それだけで1日1.2%相当が消える。期待値0.1%の戦略を高頻度で回せば、勝率が高くてもコストで負ける。
編集部の検証運用では、この問題がさらに極端な形で現れた。オンチェーンDEXでの取引ではネットワークのガス代が取引ごとに発生する。当初の建玉サイズが小さすぎたため、利確条件の+3.5%に到達しても、ガス代を差し引くと手元に残らないという状態になっていた。つまり「勝っているのに利確できない」。この構造に気づいてから、建玉下限を400ドルに設定するルールを追加した。
固定費が存在する環境では、コストは率ではなく実額で効く。次の表は、建玉サイズごとに1往復あたりのコストがどう変わるかを示したものだ。手数料率を往復0.12%、ガス代など固定費を1往復あたり2ドルと仮定している。
| 建玉サイズ | 手数料（往復0.12%） | 固定費 | 合計コスト | 建玉に対する実質コスト率 |
|---|---|---|---|---|
| 50ドル | 0.06ドル | 2ドル | 2.06ドル | 4.12% |
| 100ドル | 0.12ドル | 2ドル | 2.12ドル | 2.12% |
| 400ドル | 0.48ドル | 2ドル | 2.48ドル | 0.62% |
| 1,000ドル | 1.20ドル | 2ドル | 3.20ドル | 0.32% |
利確幅を+3.5%に設定していても、建玉50ドルでは実質コストが4.12%となり、条件を満たしても手元には何も残らない。同じ戦略・同じ設定でも、サイズを変えるだけで成立するかどうかが変わる。バックテストで手数料を率としてしか入れていない場合、この落とし穴は絶対に見えない。
落とし穴4: 過剰最適化（カーブフィッティング）
パラメータ最適化ツールを回せば、成績は必ず良くなる。当たり前だ。過去データに対して最も都合のよい数値の組み合わせを探しているのだから。
問題は、その数値が「相場の性質」を捉えたのか「その期間のたまたま」を捉えたのかを、最適化結果自体からは区別できない点にある。パラメータ数が多いほど、また探索回数が多いほど、たまたまを拾う確率は上がる。
実務的な防衛策は3つある。
- 期間を分けて検証する: 最適化に使う期間と、検証に使う期間を完全に分離する。最適化期間で優秀だった設定が、検証期間でも平均以上なら、多少は信用してよい
- パラメータの近傍を見る: 最適値の周辺の数値でも成績が滑らかに良いなら、その領域は本物の可能性がある。最適値だけが突出して周囲が崖なら、ほぼ確実にたまたまである
- パラメータ数を絞る: 調整項目が10個ある戦略は、10次元の空間から都合のよい1点を探しているのと同じだ。3〜4個に抑える
編集部の運用でも、最初は損切りを早めに置く設定を入れていた。机上では損失を小さく抑えられて見栄えがよかったが、実際に回すと相場のノイズで次々に刈られ、方向が合っていた取引まで潰していた。2026年7月に早期損切りのロジックを廃止し、トレーリングストップに置き換える全面リライトを行っている。数字が良く見える設定と、生き残る設定は違う。
落とし穴5: 銘柄の選び方が結果を作っている（生存者バイアス）
「主要10銘柄で検証しました」という条件設定には、暗黙の情報が入り込んでいる。その10銘柄が現在も主要である、という事実は、検証開始時点では知りえなかったからだ。上場廃止になった銘柄、流動性が枯れた銘柄、消えたプロジェクトは、最初から検証対象に入っていない。
暗号資産はこの偏りが特に強い分野である。数年前に主要だった銘柄の一部は、現在ほとんど取引されていない。現在の主要銘柄だけで検証すれば、「生き残ったものだけを選んで買い続けた場合」の成績が出るのは当然である。
同じ構造の問題は銘柄以外にも潜む。取引ペアの選定を「バックテスト成績が良かった順」に決めているなら、それも同じ種類のごまかしだ。検証時に使う銘柄リストは、成績を見る前に決めておくのが原則になる。
落とし穴6: 検証期間のレジームが偏っている
2020年から2021年のデータだけで検証した戦略は、上昇相場でしか検証されていない。そこで優秀な成績を出すのは、押し目買い戦略なら当たり前のことである。
相場には局面（レジーム）があり、トレンド、レンジ、高ボラティリティ、低ボラティリティで有効な戦略は変わる。実際、2026年7月時点の暗号資産市場は弱気に傾いており、ビットコインは6万ドル台で日本円換算では1,000万円を割り込み、上半期で3割超の下落となった。強気相場のデータで作った戦略が、この局面で同じように機能する保証はどこにもない。
対処法は、検証期間を局面ごとに切って個別に成績を見ることだ。全期間で均した1本の資産曲線は、局面ごとの弱点を隠してしまう。上昇局面で+30%、下降局面で-25%という戦略と、どの局面でも+3%前後の戦略では、まったく性質が違う。
編集部が戦略を「レンジ相場ならレンジ端の逆張り、トレンド相場なら押し目の順張り」というモード判定式に組み替えたのは、まさにこの理由による。単一のロジックで全局面をカバーしようとすると、どの局面でも中途半端になりやすい。
落とし穴7: 実運用の制約が入っていない
最後は、バックテストのコードには存在しないが現実には必ず存在するものだ。
- 最小注文単位: 取引所ごとに最小注文数量・最小注文金額がある。バックテストが計算した0.0003 BTCの注文は、実際には通らないかもしれない
- 同時ポジション数と資金の制約: 資金が足りず、シグナルが出ても入れない場面がある
- API障害と遅延: 取引所のメンテナンス、レート制限、ネットワーク遅延でbotは止まる
- 実装バグ: これが一番多い
最後の項目については実例がある。編集部の運用では、特定銘柄（WBTC）で発注が正しく通らない不具合が発生していた。ロジックは正しくシグナルを出しているのに、注文が成立していなかった。発注監視の仕組み（watchdog）を差し替えることで解消したが、これはバックテストでは絶対に検出できない類の問題である。
机上の戦略と実運用の間には、必ず「実装」という層が挟まる。そしてその層は、静かに壊れる。
やってはいけない検証のやり方
7つの落とし穴を裏返すと、避けるべき行動がはっきりする。ここは記事の中で最も実害に直結する部分だ。
1. 資産曲線のスクリーンショットだけで判断する。 右肩上がりの1枚絵は、最大ドローダウン、取引回数、勝敗の偏りを全部隠す。少なくとも取引回数と最大ドローダウンは必ず併せて見る。
2. 取引回数が少ないまま結論を出す。 10回の取引で勝率70%と出ても、それは偶然の範囲に収まる。最低でも数十回、できれば100回以上の取引が発生する条件で検証する。
3. 最適化した設定をそのまま本番投入する。 最適化は「過去に最も都合のよい設定を探す作業」であって、将来に最も適した設定を探す作業ではない。必ず別期間で検証を挟む。
4. 手数料をゼロまたはデフォルト値のまま回す。 高頻度戦略ほど、この一手抜きで結論がひっくり返る。
5. うまくいかない結果が出たときだけ条件を変える。 良い結果が出るまで期間や銘柄を変え続ける行為は、検証ではなく結果の選別である。条件は結果を見る前に固定する。
6. ドライランを省略する。 バックテストとドライランは代替関係ではなく直列の工程だ。片方だけでは実装層の問題が残る。
7. 一度検証したら二度と見直さない。 相場のレジームは変わる。稼働中の戦略も定期的に再検証する前提で運用する。
他の検証方法との使い分け
バックテストは検証手段の一つでしかない。それぞれの守備範囲を理解して組み合わせるのが正解になる。
| 手法 | 必要な時間 | 実装層を検証できるか | 主な弱点 |
|---|---|---|---|
| バックテスト | 数分〜数時間 | できない | 約定・スリッページ・障害が反映されない |
| ペーパートレード | 1〜2週間 | 部分的にできる | 自分の注文が板に与える影響を再現できない |
| ドライラン | 1〜2週間 | ほぼできる | 実際の資金が動かないため心理面は分からない |
| 最小サイズの実運用 | 数週間〜 | 完全にできる | 時間がかかり、損失も実際に発生する |
対 ペーパートレード
ペーパートレードは実際の板データを見ながら仮想の注文を出す方式で、バックテストより現実に近い。ただし自分の注文が板に存在しないため、板が薄い場面で「実際には約定しなかったはずの注文」が約定扱いになる。約定率が現実より高く出る方向のバイアスがあると理解して使う。
対 ドライラン（模擬売買）
ドライランは本番と同じコードを実際の取引所APIに接続して動かし、発注だけを行わない方式である。バックテストで検出できない実装層の問題——API接続の失敗、レート制限、深夜の停止、想定外のデータ形式——がここでほぼ全部あぶり出される。時間はかかるが、情報量では最も濃い工程だ。バックテストの代わりにはならず、バックテストもドライランの代わりにはならない。
対 いきなり最小サイズで実運用
「検証に時間をかけるより実弾で試したほうが早い」という考え方もあり、これは一概に否定できない。実際、編集部が発見した問題の大半は実運用でしか出てこなかった。ただし前提として、ルックアヘッド検査と手数料の実額計上という2つだけは先に済ませておきたい。この2つを飛ばすと、原理的に成立しない戦略に資金を投じることになる。
同じ検証環境を自分で作る手順
ここまでの7つを踏まえて、実際に信用できる検証をやるための順序を示す。上から順にやってほしい。
- ルールを言葉で書く: コードを書く前に、エントリー条件・エグジット条件・資金管理を日本語で書き下す。ここで曖昧なら、コードにしても曖昧なまま
- 粗いバックテストで足切りする: 手数料を実額で入れ、最初の1回は最適化なしで回す。ここで明らかに駄目なら、その先に進まない
- ルックアヘッド検査を通す: 自動検査ツールを実行する。引っかかったら必ず原因を特定する
- 詳細足を入れて再実行する: 上位足のバックテストに細かい足を組み合わせ、成績がどれだけ落ちるか見る。大きく崩れるなら、それが実力に近い
- 期間を分割して局面別に見る: 上昇・下降・レンジの各局面で個別に成績を出す
- 最適化は期間を分けて行う: 最適化期間と検証期間を分離し、最適値の近傍も確認する
- ドライラン（模擬売買）を1〜2週間回す: 実際の相場に接続し、注文の出方・停止の有無・想定外の挙動を見る。ここが最も情報量が多い
- 最小サイズで実運用を開始する: 失っても影響のない金額で始め、実際の約定価格と机上の想定の差を記録する
工程2から6は、次のように連続して回すと手戻りが少ない。そのままコピーして使ってよい。
# 1) 過去データを取得（検証期間より長めに取る）
freqtrade download-data --timerange 20240101-20260701 -t 5m 1h
# 2) 最適化なしの素の成績を見る
freqtrade backtesting -s MyStrategy -i 5m --timerange 20240101-20250630
# 3) 未来データの参照がないか検査する
freqtrade lookahead-analysis -s MyStrategy -i 5m --minimum-trade-amount 10
# 4) 詳細足を入れて、どれだけ成績が落ちるかを見る
freqtrade backtesting -s MyStrategy -i 5m --timeframe-detail 1m \
--timerange 20240101-20250630
# 5) 最適化は前半期間だけで行う
freqtrade hyperopt -s MyStrategy --epochs 200 --timerange 20240101-20250630
# 6) 最適化に使っていない後半期間で検証する（ここが本番）
freqtrade backtesting -s MyStrategy -i 5m --timeframe-detail 1m \
--timerange 20250701-20260701
6の結果が5の期間の成績と大きくかけ離れているなら、それは戦略ではなく過去データへの当てはめを作っただけである。Freqtradeの公式ドキュメントも、バックテストがドライランの代わりになることは決してない、と明記している。工程7を飛ばして実運用に入るのが、最も損失につながりやすい進め方である。
検証結果を疑うためのチェックリスト
良い成績が出たときこそ、この項目を上から確認してほしい。疑うべきタイミングは、結果が悪いときではなく良いときである。
- 手数料を実額（固定費含む）で計上し、スリッページの想定を入れたか
- ルックアヘッド検査を実行し、指摘をすべて確認したか
- 詳細足を併用したバックテストでも成績が維持されたか
- 最適化期間とは別の期間で検証し、そこでも平均以上だったか
- 最適パラメータの近傍でも成績が滑らかに良かったか
- 上昇・下降・レンジの各局面で個別に成績を確認したか
- 検証対象の銘柄を「今生き残っているから」という理由で選んでいないか
- 最小注文単位・資金制約を満たす注文サイズになっているか
- ドライランを実施し、注文が想定どおり出ることを確認したか
リスクと注意点
検証の話とはいえ、その先には実際の資金が動く。以下は必ず理解しておいてほしい。
- 過去の成績は将来の利益を保証しない: これは決まり文句ではなく、レジームが変われば前提が崩れるという構造的な事実である
- 良いバックテスト結果ほど疑う: 異常に良い結果は、優れた戦略の証拠ではなく検証の欠陥の兆候であることのほうが多い
- レバレッジは検証誤差を増幅する: 10倍のレバレッジは、机上と現実のわずかなずれも10倍にして返してくる
- 実装バグは静かに損失を生む: ロジックが正しくても発注が通らない、あるいは二重に通る事故は現実に起きる。稼働後の監視を前提に設計する
- システム障害でbotは止まる: ポジションを持ったまま停止する前提で、取引所側の損切り注文を併用する
- 元本毀損リスク: 自動売買は損失も自動化する。失っても生活に影響しない金額から始める
- 税務: 日本では暗号資産の利益は原則として雑所得として課税対象になる。bot運用は取引回数が多く計算が煩雑になるため、履歴を保存し、申告方法は税理士など専門家に相談してほしい
- 他人の戦略に乗る場合も同じ: コピートレードのように他人の判断に乗る手法でも、過去の成績は将来の利益を保証しないという点は変わらない
まとめ
バックテストで騙されないための要点を、もう一度整理する。未来を覗いていないか、足の内側の曖昧さに寄りかかっていないか、コストを実額で入れたか、たまたまを最適化していないか、銘柄選定と期間選定が結果を作っていないか、そして実装という層を検証に含めたか。この6つを潰して、なお成績が残るなら、ドライランに進む価値がある。
編集部の実口座検証は、現時点で実現損益が約-21ドルというところにいる。決して誇れる数字ではない。ただ、建玉サイズがガス代に負けていたこと、早期損切りがノイズで刈られていたこと、特定銘柄の発注が通っていなかったこと——これらはどれも、バックテストの画面をどれだけ眺めても出てこなかった発見である。机上の検証は必要だが、それだけでは足りない。小さく実際に回して壊れた場所を直す、という工程を省略できる方法は、今のところ見つかっていない。
なお、実際にbotを動かす環境の作り方、取引所の口座開設やAPIキーの設定・接続手順については、当サイトの手順記事で個別に解説している。検証の段階を終えたら、そちらを参照してほしい。編集部の運用実績についても、専用のページで継続的に公開している。
<!-- INTERNAL_LINKS_RELATED -->
関連記事
<!-- INTERNAL_LINKS_RELATED -->