同じドル円を表示しているのに、一方のチャートでは前日高値を上抜け、もう一方ではまだ届いていない。価格配信の差を疑う前に確認したいのが、日足をどの時刻で区切っているかだ。FXの日足は、全世界で一つの公式な終値から作られるわけではない。
日足一本は、一定の時間帯に観測した価格を始値・高値・安値・終値へ集計したもの。その時間帯が違えば、同じ価格列でも別のローソク足になる。ここではNYクローズ、夏時間、日曜足、価格の種類を分け、バックテストと実際の注文を一致させる手順を考える。
日足は価格だけでなく「集計窓」で決まる
例えばUTCの0時から翌0時までを一日とするチャートと、ニューヨーク時間17時から翌17時までを一日とするチャートがある。どちらも24時間を基本に集計していても、開始地点が違う。その間に起きた高値更新が、片方では昨日、もう片方では今日へ入る。
これは価格が改変されたことを意味しない。売上を暦月で集計するか、毎月20日締めで集計するかによって月次の数字が変わるのと似ている。比較するには、まず時間の箱をそろえる必要がある。ただし実際のFXでは価格供給元やスプレッドも異なるため、時刻だけが原因とは限らない。
NY17時は日本時間で一年中同じではない
ニューヨークが夏時間の期間はUTCとの差がマイナス4時間なので、NY17時はUTC21時、日本時間では翌日の6時になる。標準時間の期間はUTCとの差がマイナス5時間で、NY17時はUTC22時、日本時間の翌7時になる。日本時間が動くのではなく、ニューヨーク側の時差が変わる。
したがって「毎朝日本時間7時に日足が確定する」と固定して実装すると、夏時間中は一時間ずれる可能性がある。地域名のAmerica/New_Yorkと、固定オフセットのUTC−5は同じ指定ではない。前者は適切なタイムゾーン情報を使えば季節の変更を扱えるが、後者は年間を通じて固定される。
図のUTC22時に価格が跳ねたとする。NY17時で区切る夏時間のチャートでは、UTC21時から新しい日が始まっている。一方、UTC0時で区切るチャートはまだ日付が変わっていない。この高値を「前日高値」として参照するタイミングがずれる。
前日高値ブレイクの判定が食い違う理由
架空の二つの集計窓について、直近の確定日足の高値がAでは150.50円、Bでは151.00円だったとする。窓に含まれる時間が違い、151.00円の一時的な上昇がBの確定足にだけ含まれている設定だ。その後の観測価格が150.80円なら、Aの前日高値を超えているがBでは未達となる。
このときAを正解、Bを間違いと決めることはできない。二つは異なる売買ルールだからだ。Aの成績がよかったのでAの高値を採用し、注文の約定はBの価格で評価するなら、その組み合わせを最初から戦略仕様として検証しなければならない。
また、高値への到達を仲値で判定するか、実際に買える売り気配で判定するかも別問題だ。買い逆指値の発動条件や約定価格は業者の仕様に従う。チャート上の線を越えたことだけを根拠に、同じ水準で発注・約定できるとは扱わない。
画面の時計を変えても日足は変わらない場合がある
チャートの表示タイムゾーンを日本時間へ変更すると、横軸の表示だけが変わり、サーバー側で作った日足の四本値はそのままという場合がある。一方、ローソク足の集計開始時刻自体を選べるサービスもある。「表示時間」と「足の構築条件」を同じ設定だと思い込まないことが重要だ。
OANDAの公式API資料では、日足の整列時刻を指定するdailyAlignmentと、その地域を指定するalignmentTimezoneが説明されている。例として既定値は17時とAmerica/New_Yorkで、返される時刻はUTCとされる。これはそのAPIの仕様であり、全業者や全アプリの日足が同じという意味ではない。
確認する際は、一つの過去日を選び、変更前後の始値・高値・安値・終値を保存する。横軸だけが変わったのか、実際に四本値が再集計されたのかを比べれば、表示設定と集計設定の混同を避けられる。アプリの見た目だけで仕様を推測するより確実だ。
時刻の対応表を運用ノートに残す
保存する仕様は、通貨ペア、配信元、価格種類、日足開始時刻、タイムゾーン、足の日付ラベル、週末の扱いである。例えば「ドル円、配信元A、仲値、NY17時区切り、地域タイムゾーンで夏時間を処理、確定足のみ使用」と書けば、別の環境でも比較しやすい。
夏時間の開始・終了は地域ごとの規則で決まり、米国と欧州の切替日が一致するとは限らない。米国の区切りを欧州サーバーの固定時刻で代用すると、切替前後だけずれることがある。運用する年の取引時間案内とタイムゾーン情報を確認し、日付を独自の思い込みで固定しない。
日曜の短い足を削除するだけではそろわない
週明けの取引開始から日付変更までの短い時間が、独立した日曜足として表示される配信もある。別の配信ではその時間帯が月曜足へ含まれる。20本の移動平均を比較すると、前者の20本と後者の20本がカバーする営業期間は同じでなくなる可能性がある。
短い日曜足を単純に削除すると、その間の価格や高値・安値まで失われる。月曜へ統合したいなら、元の細かい足から目的の窓に再集計し、最初の価格、最大値、最小値、最後の価格を取り直す必要がある。削除と統合は別の処理である。
同様に、週末の取引停止を価格が動かなかった時間として大量の横ばい足で埋めると、指標が変わる。市場が開いていない時間と、開いていて同じ価格が続いた時間を区別する。データの欠損も週末と同じ扱いにはしない。
移動平均だけでなくATRとピボットも変わる
終値の区切りが違えば終値の移動平均が変わる。高値・安値・前日終値を使うATRでは、窓の違いが値幅とギャップの計算へ影響する。前日高値・安値・終値を使うピボットも、基礎となる足が違えば支持・抵抗の水準がずれる。
ATRに応じて数量を決める戦略なら、チャートの違いは単なる見た目ではなく、建玉量と損失額の違いになる。例えば同じ許容損失で損切り幅が広く算出されれば、数量は小さくなる。指標名と期間だけ一致していても、入力となる日足が違えば同じ戦略とはいえない。
仲値・買い気配・売り気配を混在させない
FXの価格には買い気配、売り気配、その中間の仲値がある。高値をどの価格から取るかによって、特にスプレッドが広がる時間帯のローソク足が変わる。日足の区切りをそろえてもヒゲが一致しないときは、価格種類を先に確認する。
データサービスによっては始値の平滑化にも設定がある。OANDAのAPI資料では、平滑化を有効にした場合の始値に前の足の終値を使う設定が説明されている。実際の時間窓内の最初の価格を使う設定とは異なり、始値を使うパターン検出へ影響し得る。
日足データを購入・取得する際は、OHLCの数値だけでなく構築方法も保存する。後から配信元を変更したのに以前の検証結果とそのまま比較すると、ルールの劣化とデータ仕様の変更を混同してしまう。
未確定の日足を完成したデータとして扱わない
APIで最終行を取得したら、その日足が既に確定しているかを確認する。配信によっては形成中の足も返される。確定状態を示す項目があるなら利用し、なければ仕様に基づいて時刻を判定する。日本の暦日が変わっただけでは、NY基準の日足が完成したとは限らない。
確定前の終値は、その時点の最新価格にすぎない。途中で条件を満たしたシグナルが、確定時には消えることがある。確定足で検証した戦略を、実運用では形成途中の足で発注すると別のルールになる。確定足を待つ設計なら、確認後に注文を送れる最初の価格で評価する。
バックテストの仕様を一枚の記録へ落とす
各シグナルについて、参照した日足の開始時刻と終了時刻、確定を確認した時刻、前日高値、注文送信時刻を一行に残す。時間は比較しやすいUTCで保存し、表示用に日本時間を併記するとよい。単に「月曜に買い」と記録するより、どの一日を材料にしたかが明確になる。
境界付近の時刻を含むテストも作る。例えば夏時間のUTC20時59分、21時ちょうど、21時01分がそれぞれどの足へ所属するかを確認する。開始を含み終了を含まない時間窓で処理するなら、境界ちょうどの価格を二本の足へ重複して入れてはいけない。データ配信元が時刻を足の開始として記録するか終了として記録するかも照合する。
過去データを結合するときは、文字列の日付だけで突き合わせず、時刻を伴う区間として比較する。同じ「9月1日」というラベルでも実際の対象時間帯が違う場合がある。こうした仕様の差を先に固定すれば、後から有利な区切りだけを選ぶ過剰最適化も抑えやすい。
二つの業者を比較する実務手順
まず一週間ほどの細かい価格データと、各社の日足を保存する。通常週だけでなく、夏時間の切替前後と週明けも含める。次に時刻をUTCへ統一し、同じ窓へ集計する。最後に価格種類、欠損、週末、平滑化を照合し、残る差を価格配信の差として調べる。
売買ルールは、日足の定義、指標計算、シグナル確定、注文発動、実際の約定という順番で分ける。どの段階で差が生じたかを記録すれば、業者を変えた途端に成績が変わった理由を追跡しやすい。日足は単なる一日の絵ではなく、時刻と価格種類を含むデータ仕様なのである。
参考：OANDA REST APIのローソク足集計仕様、OANDA Webのローソク足設定案内。記事中の為替水準は仕組みを示す架空例。
コメント