はじめに
ファンド運用の定量分析実習講座を担当しているのですが、受講生の多くが短期相場分析で同じデータの落とし穴にハマっているのを見かけます。 約定記録と一番安い売値・一番高い買値だけで分析してしまい、相場の転換シグナルを見逃したり、予測結果が大きくズレたりするケースがとても多いんです。
今回は実習で実際に構築した、WebSocket を活用した Level2 深度板情報の収集システムについてまとめました。データの選び方から長時間接続の作り方、データの不具合を防ぐ安定化テクまで、初心者でも分かりやすく記載しています。 Python で定量ツールを自作したい方、相場データ収集を勉強している方の参考になれば嬉しいです✨
1. 投資分析の現場でよくある課題：約定データだけでは事前の資金動きが読めない
私たちは長年、公募ファンド・私募ファンドの調査チーム向けに流動性分析の支援を行っています。 以前、日内の価格変動予測モデルを作成した際、最初は Tick 約定データと Level1 の一段階気配値だけを使用していました。
穏やかなレンジ相場ではモデルの結果がそれなりに使えるのですが、寄付き競り、引け前の一斉約定、大口注文による急変が起きるタイミングでは予測の誤差が一気に広がってしまいました。 原因を調べたところ、2 つの大きな問題が見つかりました。
- Tick データは「完了した取引結果」しか記録できず、これから起こりそうな資金の動きを事前に捉えられない
- Level1 の一段階気配値だけでは、深い価格帯に隠れた大量注文を確認できない
価格が動く裏側の注文の駆け引き全体を把握できないため、短期的な流動性の切り替わりを事前に察知するのが難しくなるのです。 この問題を解決するため、WebSocket を利用した全価格帯の Level2 相場収集システムを構築しました。
2. 3 種類の相場データの違い｜Level2 だけが持つ強み
定量分析をするときは、それぞれのデータの役割を理解し、用途に合わせて使い分けることが大切です。
Tick 約定データ
1 件ごとの約定履歴を記録し、ローソク足作成や過去の収益検証に向いています。 あくまで「取引が終わった結果」なので、事前の注文動向を予測する材料にはなりません。
Level1 一段階気配値
現在の最善買い価格・最善売り価格とその注文量だけを表示するシンプルなデータです。 簡易的な相場画面を作る程度には便利ですが、複数の価格帯に散らばる隠れた大口注文を見つけられない欠点があります。
Level2 全深度板情報
全ての価格帯の売買注文残量を完全に記録し、市場全体の多空の注文分布を可視化できます。 短期の価格支え・抵抗ライン、流動性の強弱を測るための中心的なデータです。
実際の現場では、「重要価格付近に一気に買い注文が増える」「上位価格の売り注文が一斉キャンセルされる」といった動きは Level2 データだけで捉えられる事前シグナルになります。価格の推移だけを追っていては、相場の転換点を事前に読むのは難しいです。
3. Level2 収集に WebSocket 長時間接続を選ぶ理由
昔ながらの HTTP ポーリング方式には明確なデメリットがあります。 一定時間ごとにサーバーにデータを取りに行く仕組みのため、ミリ秒単位で変化する板情報の更新を取りこぼしやすい上、頻繁なアクセスでサーバーの通信帯域を無駄に消費し、長期運用コストがかさみます。
Level2 板情報はリアルタイムで刻々と変化するため、双方向で常時接続できる WebSocket が最適な手段です。基本的な動きは 4 ステップです。
- クライアントと相場サーバーの間で WebSocket の持続的接続を確立
- 監視したい銘柄と Level2 データを指定した購読リクエストを送信
- サーバーから板の差分更新メッセージが連続で配信される
- ローカルプログラムが過去の板情報をもとに、リアルタイムで注文帳を更新
ここで初心者がよく見落とすポイントがあります。多くの相場 API は毎回完全な板情報を送らず、変化した箇所だけの差分データを配信する仕様になっています。 ローカル側に前回の板状態を保存しておかないと、差分データだけで板を描画した際、価格帯が欠けたり注文量の計算がズレたりし、流動性指標の精度が大きく低下します。
4. Level2 メッセージの必須項目と注文帳の保存ロジック
差分の板情報を解析し、ローカルに注文帳を維持するには、5 つの項目を必ず確認する必要があります。 ・銘柄コード：複数銘柄のデータを分けて管理する識別子 ・売買区分：買い注文 (bid)・売り注文 (ask) を判別 ・注文価格：更新対象の価格帯 ・注文残量：該当価格帯の未約定注文総量 ・タイムスタンプ：データ生成時刻。時系列の整合性チェックや複数データの同期に使用
開発時は買い側と売り側の価格帯を 2 つの独立した配列に分けて保管しています。 更新メッセージを受け取ったら売買区分に合わせて配列内の数量を修正し、残量が 0 になったら該当レコードを削除する仕組みです。 最善気配値や全体の流動性を集計する際に配列を再走査する必要がなく計算負荷が抑えられ、複数銘柄を同時監視する運用に適しています。
5. 安定運用のための 4 つの改善ポイント
Level2 データは毎秒大量の差分メッセージが発生するため、ネットワークの瞬断やタイムゾーンの時差がデータの連続性を壊す原因になります。複数の投資分析システムを運用した経験から、手動でのデータ修正工数を大幅に減らせる 4 つの対策をまとめました。
-
定期的な板情報スナップショット保存 一定間隔で全売買価格帯のデータをキャッシュに保存し、接続が切れて再接続した際にスナップショットから板情報を復元。全量データを再取得する手間を省けます。
-
時系列チェックによるノイズデータ遮断 新しいメッセージのタイムスタンプとローカルの記録時刻を比較し、時系列が逆転・重複した不正データを自動で除外。注文量が二重に加算される数値ズレを防止します。
-
切断後の自動再同期ロジック 通信が途切れた際、欠損した期間の板情報を自動的に補完するリクエストを送信し、断絶中の価格帯変動記録を埋め合わせます。
-
異常数値の閾値フィルター 価格・注文量に合理的な変動幅の閾値を設定し、突発的な価格飛びや不自然な架空大口注文といったノイズを自動遮断。指標の急激な変動による分析の混乱を抑えます。
時刻処理の小ワンポイントアドバイス
多くの相場 API は UTC 標準時でデータを出力するため、過去検証や時間帯別集計時にローカル時刻と混ぜると時系列軸にズレが生じます。データを解析する段階で全てのタイムスタンプを統一されたタイムゾーンに変換するルールを定め、根本的な時刻のズレを回避しましょう。
6. まとめ
今回の Level2 相場収集実習を通して感じたのは、WebSocket の接続を作るだけなら基礎的な工程に過ぎないということです。 データの品質を左右するのは、注文帳の保存、切断時の復旧ロジック、時刻の統一といった細かい開発調整の部分なのです。
Tick データは取引の結果を示すのに対し、Level2 深度板は市場参加者の事前注文動向を可視化でき、日内価格予測や流動性リスク測定に多層的な分析軸を追加してくれます。 短期の資金動向を頻繁に確認する調査チームにとって、標準化された Level2 データフローを構築することで、過去検証と実際の運用時のモデル精度の差を縮め、定量分析の結果を実務で活用しやすくすることができます。