MACDはどのように責任ある形でバックテストできますか？

まずMACDを定義し、その後「バックテスト」とは何かを定義する

MACD（Moving Average Convergence Divergence：移動平均収束拡散）は、移動平均から構築されるトレンド追随型のオシレーターです。バックテストでは、将来の方向性を保証するものとして「MACDそのもの」をテストしているのではありません。MACDの値を、過去データ上で測定可能な結果へ変換するルールをテストしているのです。

責任あるバックテストを行うには、まず使う仕組みを正確に書き出してください：

• MACDを計算するために用いる移動平均の種類とパラメータ（たとえば、2つの移動平均の長さとシグナルライン）。
• 同じ価格系列から、MACDラインとシグナルラインをどのように計算するか。
• ローソク足の終値の値でテストするのか、それともローソク足内の近似でテストするのか。
• タイムスタンプの扱い、欠損データ、そして（該当する場合）データソースにおけるコーポレートアクションのような調整をどう扱うか。

「バックテスト」の実務的な定義は次のとおりです：意思決定ルールを過去データに適用して、仮想の取引列または仮想のペイオフの系列を生成し、その後、コストや執行（エグゼキューション）の前提を考慮する指標で評価することです。

データと前提を明確にする（結果を最も左右し得るもの）

避けられる誤りの多くは、不整合または非現実的なデータの取り扱いから生じます。市場の結果は変動するため、次の点を明示的な前提として扱ってください：

データ範囲とサンプリング

• 時間範囲と固定のサンプリング頻度を選ぶ（たとえば日足）。頻度を混ぜたり、実行のたびにデータを別の方法で再集計したりすると、結果が歪む可能性があります。
• 指標を、後で取引の意思決定に使うのと同じ価格の終値で計算するかどうかを決める。

先読み（ルックアヘッド）とアラインメント

• 意思決定の時点で、指標の値が利用可能であることを確認する。同じバーで「エントリー」するのに使う情報を用いて指標を計算してしまうと、先読みバイアスを偶然導入してしまうことがあります。
• シフト（ずらし）の一貫したルールを使う：意思決定がバーtの終わりの指標に基づくなら、シミュレーション上の行動はバーtの後に行うべきです。

データの整合性

• ギャップ、重複したタイムスタンプ、価格フィードの突然の変化、そして欠損したバーがないか確認する。
• 調整済み、または変換された価格から指標を計算する場合は、変換手順を記録する。

これらの選択は見た目の問題ではありません。あなたがルールに投入するMACD値が変わり、それがバックテスト全体の経路を変えてしまうからです。

コストと執行（エグゼキューション）の前提を含める（摩擦が重要）

正しいMACDの実装であっても、摩擦を無視したバックテストでは利益が出ているように見えることがあります。責任あるバックテストには、少なくとも3つのコスト層と、明確に定義された執行挙動が含まれます：

コストの種類

• 取引コスト（コミッション、手数料）。
• スプレッド／価格インパクトの近似（理論上の意思決定価格と、実際の執行価格の差をどうモデル化するか）。
• スリッページ（執行が想定価格からどれだけ逸脱するか）。

執行（エグゼキューション）の前提

• 取引が意思決定価格で約定するのか、次のバーの始値で約定するのか、あるいは別の慣例で約定するのかを決める。文書化してください。
• 部分約定、板（オーダーブック）の影響、またはレイテンシは無視するのかを決める。

現実の執行が正確に分からない可能性があるため、感度チェックで不確実性をモデル化します（スリッページ／スプレッドの前提を、データと市場のミクロ構造に関する知識によって正当化できる妥当な範囲で変化させる）。目的は「未来を予測する」ことではなく、より現実的な前提のもとでも結論が生き残るかを確認することです。

過去の履歴への過学習を減らすためのバイアス制御を追加する

MACDのパラメータ選択やルールのバリエーションは、偶然ノイズに「当てはめてしまう」ことがあります。バイアス制御はそれを検出するのに役立ちます。

アウト・オブ・サンプルの分離

• データを少なくとも2つに分ける：パラメータ選定やルール設計に使う部分と、評価に使う別の部分。
• 評価期間を使ってパラメータを調整すると、結果が誤解を招くものになり得ます。

ウォークフォワードテスト

• 履歴全体に対して1つの固定パラメータセットを使う代わりに、ローリングまたは段階的な手順を使う：あるウィンドウでフィットし、次のウィンドウでテストし、その後前へ進める。
• これにより、あるパラメータセットが特定の歴史的期間でしか機能しない確率を下げられます。

繰り返しの覗き見を避ける

• 評価の結果を見た後に、何度もルール変更を繰り返すと、実質的に評価セットの中で最良の答えを探していることになります。
• これを抑えるには、広範な評価の前にプロセスを固定し、バージョンごとに評価セットを1回だけ使うようにします。

パラメータの透明性

• どのパラメータと閾値を、なぜ選んだのかを含めて、試した内容をログとして残してください。

少なくとも1つの重要な制限と失敗モードを確認する

責任あるバックテストは、何が壊れ得るのかを明示的に認識すべきです。

DOCUMENT END