ティックデータは価格だけでなく、スプレッドや更新間隔、約定環境を検証する基礎になります。CSV保存の限界を整理し、Parquet形式でBid・Ask・時刻を蓄積して、Pythonから執行品質を分析しやすいデータ基盤を作る方法を解説します。
ティックを残す目的は価格履歴だけではない
EAの検証で1分足やOHLCだけを保存していると、そのバーの内部でスプレッドがどこまで拡大したか、価格更新が何ミリ秒間隔だったかは失われる。執行品質を調べるには、少なくとも時刻、Bid、Askをティック単位で残したい。
問題はデータ量である。長期間・複数銘柄をCSVへ追記するとファイルが肥大化し、Pythonで期間を絞って読むだけでも不要な行を大量に処理することになる。そこで分析用の保存形式として使いやすいのがParquetである。
列指向形式が執行分析と相性がよい
Parquetは列単位でデータを格納できる列指向フォーマットで、圧縮や必要列だけの読み込みに向く。ティックを timestamp、bid、ask、last、volume などの列として保存しておけば、スプレッド分析ではbidとaskだけを選択できる。
さらに日付や銘柄をパーティションとして分割すれば、数カ月分を一括走査せず対象範囲だけ読み込める。保存時にはspreadを固定値として持つより、BidとAskという元データを保持し、分析時にask－bidとして再計算する方が後から定義を変更しやすい。
時刻についても秒単位へ丸めず、取得できる精度を維持する。更新間隔そのものが流動性を測る変数になるためである。
Python側で約定環境を再構成する
データ基盤ができれば、Pythonで1秒ごとのスプレッド中央値、90％・95％点、ティック更新回数などを集計できる。特定時間帯だけスプレッド分布が変化しているか、価格急変時に更新間隔がどう変わったかも比較可能になる。
EAの実運用ログには発注時刻と実約定価格を残し、同時刻付近のティックと結合する。これにより、提示スプレッドとスリッページを分離し、「シグナルが悪かった」のか「執行時の市場環境が悪化していた」のかを検証できる。
まとめ
Parquet化の目的は保存容量を減らすことだけではない。Bid、Ask、時刻という一次データを分析可能な形で蓄積し、スプレッド、更新頻度、スリッページを後から再構成できることに価値がある。
ローソク足だけでは消えてしまう約定環境をティックから復元できれば、バックテストと実運用の差を価格方向ではなく執行構造から測れる。データ形式の選択は、そのための計測基盤の一部である。
