建玉残高（OI）：未決済ポジション、出来高と先読みのないシグナル

実践の流れ

1. 契約スキーマを読む単位、乗数、片側または両側の計数を記録する。
2. 利用可能なスナップショットを整列する各判断の締切時刻までに受信した観測値だけを使う。
3. 数量と評価額を分けて記載する米ドル価格の変動と新規契約を混同しないでください。
4. 価格トリガーが必要ブレイクアウトブランチとリクレームブランチには、それぞれ異なる無効化ルールが適用される。
5. データ品質への感度を検証遅延、古い値、限月ロール、スキーマ変更の影響を試す。

すべての契約には両面がある

片側だけで契約数を数える方式では、両当事者が新規ポジションを開く取引は OI を一契約増やす。双方が既存ポジションを閉じれば一契約減る。閉じるポジションを新たに開くポジションが引き継ぐ場合、OI は不変である。いずれの場合も出来高は増える。CME は未決済契約の残高と取引活動の流量を区別する。[1]

価格上昇と OI 増加は新規ポジションの形成に伴うことがあるが、各契約には必ず両側がある。誰がロングまたはショートを新規に建てたかを知るには、追加の分類済みデータが必要だ。価格下落と OI 減少はレバレッジ縮小と整合することがあるが、閉じた全ポジションが強制清算されたロングだとは証明できない。

価格の上昇／下落とOIの上昇／下落というおなじみの4つの組み合わせは、あくまでも説明であり、完全な戦略ではありません。これらには、エントリーのタイミング、参加者の身元、ヘッジの動機、執行コストといった要素は含まれていません。それぞれの組み合わせを、将来の関係性を対象市場で推定する必要のある、候補となる説明要素として扱ってください。

単位と計数方式を特徴量の定義に含める

契約乗数、逆または線形商品タイプ、および API のカウント規則を読み取ります。ここで調べた Bybit のドキュメントでは、両側でカウントされる openInterest と片側でカウントされる singleOpenInterest を区別しています。逆商品は USD 単位を使用し、線形商品はコイン単位を使用します。[2] 履歴データとライブデータでフィールドを暗黙的に切り替えることなく、フィールド名とスキーマ バージョンを保持します。

USD建てのOIは、原資産価格が上昇する一方で、コインや契約の数量が変わらない場合に上昇する可能性があります。ポジション作成を分析するには、一貫した数量測定方法を用いるか、価格と数量の影響を分解してください。BTCの数量をETHの数量に加算しないでください。クロスアセットのUSD集計には、評価価格とタイムスタンプを明記する必要があります。

契約仕様の変更や、片側報告から両側報告への移行は、取引行動とは無関係な不連続性を生み出す可能性があります。このような変更を検出し、注釈を付けてください。視覚的に滑らかな正規化を行うと、不連続性を隠蔽しつつ、誤ったパーセント変化シグナルを保持してしまう可能性があるため、元のフィールドと変換メタデータを保持してください。

満期のある先物では限月のロールも重要だ。期近契約の建玉減少は、市場全体のエクスポージャー減少ではなく次の限月への移行かもしれない。特徴量が特定契約を追うのか、対象限月を文書化した方法で集計するのかを定義する。

決定時点のスナップショットを結合し、最も近いタイムスタンプで結合しない。

決定前に実際に受信した最新のスナップショットを使用してください。最も近い時間での結合では、将来の観測値が選択され、情報が漏洩する可能性があります。前方補完は、宣言された最大経過時間に制限してください。そうしないと、古い OI によって、活発な市場が変化していないように見えてしまう可能性があります。堅牢なデータセットには、観測タイムスタンプと値が利用可能になったタイムスタンプの両方が格納されます。

期間比較のために、現在のカットオフ時点と以前のカットオフ時点における最新の適格数量を取得します。両方の観測値について、正の以前の数量、一貫した契約識別子、および許容可能な経過期間を要求します。擬似コードは、両方のスナップショットをそれぞれのカットオフ時点と比較します。

既知の過去スナップショットと将来のものの間を線形補間して日中値を作ってはいけない。振り返りの可視化には使えても、当時利用可能な入力にはならない。過去の利用可能時刻が欠ける場合は制約を明記し、即時受信を仮定せず保守的な公開遅延を与えて感度を検証する。

それぞれの可用性ルールに基づいて、一致する期間における価格変動と取引量を計算します。不規則な更新により、名目上は同じ5分間の比較でも二つの比較が、実際の期間が異なる可能性があるため、実際のスナップショット時刻を保存してください。アライメントの不一致が著しい観測値は、除外するか、個別に分析してください。

各スナップショットの経過時間を、それぞれのカットオフ値と比較します。現在の値はtと比較し、以前の値はt−horizonと比較します。両者とも、互換性のある契約ID、単位、乗数、およびカウント規則を持つ必要があります。comparable_quantity_schemaは、未処理の変更を拒否します。経過時間には観測タイムスタンプが使用され、received_atは値が到着したかどうかを確認します。

at decision_time t:
    oi = latest_snapshot(received_at <= t, instrument=contract)
    prev = latest_snapshot(received_at <= t-horizon, instrument=contract)
    if missing(oi,prev): return INSUFFICIENT_DATA
    if stale(oi, asof=t, max_age=max_age): return INSUFFICIENT_DATA
    if stale(prev, asof=t-horizon, max_age=max_age): return INSUFFICIENT_DATA
    if not comparable_quantity_schema(oi,prev): return INCOMPATIBLE_DATA
    if prev.quantity <= 0 or oi.quantity < 0: return INVALID_DATA
    delta_oi = oi.quantity / prev.quantity - 1
    delta_price = last_known_price(t) / last_known_price(t-horizon) - 1
    volume = sum(trade.size for trade in contract_trades
                 if t-horizon < trade.exchange_time <= t
                 and trade.received_at <= t)
    emit_features(delta_oi,delta_price,volume,oi.schema_version)

未決済契約の残高と取引の流量は異なる

片側計数方式で OI が1,000契約の状態から始める。双方が新規に建てる100契約の取引は OI を1,100へ増やし、出来高に100を加える。続いて双方が閉じる60契約の取引は OI を1,040へ減らし、出来高にさらに60を加える。総出来高は160だが OI の純増は40にすぎない。

評価の反例として、数量は100 BTCのままで、価格は50,000から55,000に上昇します。USDの想定元本は5百万から5.5百万に増加し、数量は変化せずに10%増加します。これを新規契約の10%増加と判断するフィルターは、ポジション作成に評価効果を誤って割り当てることになります。

時刻の誤りの例として、10:05の OI スナップショットで10:00のエントリーを正当化することはできない。最終ファイルが観測時刻順でも同じだ。09:55と10:05の間の補間も10:00の特徴量へ未来情報を混入させる。並べ替えても当時の利用可能性は修復できない。

このグラフは、数量が上昇した後、下降する様子を示しています。参加者を特定したり、自主的な撤退と強制的な清算を区別したり、投資収益を示したりはしていません。これらの結論を導き出すには、他の観察結果と、別途定義された研究課題が必要です。

価格とOIに関する2つの仮説は個別に検証できる。

ブレイクアウト継続の提案分岐は、条件を固定した価格候補と抵抗線より上での終値から始める。固定期間の数量ベース OI 変化が正である条件を検証し、高い RVOL を追加フィルターとして別途検証する。期間と閾値は研究上の選択だ。確認後に入り、ストップは価格構造から決める。OI 単独では有効なストップ位置を決められない。

ウォッシュアウト後のリクレーム分岐には、安値を下回るスイープ、OI 数量の有意な減少、価格の回復が必要だ。その後の価格確認を待ってロングに入る。OI が減っただけで買わず、構造の無効化または期限切れで取り消す。5%や10%の減少は普遍的な市場定数ではない。

清算データが追加された場合、取引フィードにおいて、清算されるポジションの側とテイカー側を区別する必要があります。それぞれのラベルは異なるオブジェクトを参照する可能性があります。例えば、ロングポジションの決済は、あるAPIの「Buy」ラベルを別のもののセマンティクスに単純にコピーすることで解釈されるべきではありません。

最初から分岐を分離してください。OIが下落している間にブレイクアウトが失敗した場合でも、自動的にウォッシュアウト実験が成功したとはみなされません。新しい候補には、独自のイベント時間、確認、およびリスクルールが必要です。失敗した元の候補は評価ログに保存してください。

フィルターを評価する前にデータを検証してください。

Giagkiozis と Said は、7 つの取引所にわたる 2023 の 2 期間のティック データを調査し、OI と清算の不整合を報告しています。ここでの読書範囲は、改訂版論文の要約であり、データセットの複製ではありません。[3] これは、スナップショット、取引、スキーマを確認する動機付けになりますが、現在のすべての取引所フィードを拒否することを正当化するものではありません。

同じ価格検出器で OI の有無を比較し、RVOL または清算の特徴量を一つずつ追加する。公開遅延、古い値の比率、限月ロール、API 変更を調べる。ファンディング、スプレッド、スリッページ、適用される借入費用を含め、スナップショット更新周期をさらに一周期遅らせた場合も検証する。

純期待値、取引回数、ドローダウンに加えて、データ不足で見送った機会を報告する。後日修正された OI 値でしか機能しないフィルターは、当初の時点で実行可能だったとは立証できない。データ品質や報告遅延が見かけの予測利益を打ち消すという結果も有用だ。

よくある落とし穴

この手法を使う前のチェックリスト

ご自身のデータで確認した項目にチェックを入れてください。進捗はこのブラウザに保存されますが、戦略の収益性を認定するものではありません。

• OIフィールドとスキーマバージョンを正確に記録してください。
• 数量と米ドル名目評価額は分けて計算してください。
• 集計値OIから、ロングポジションがショートポジションよりも多いと推測しないでください。
• 受信時点を基準とした結合を使用し、未来の最も近い時点を基準としたスナップショットは絶対に使用しないでください。
• 現在と過去の両スナップショットの経過時間を確認する。
• 契約乗数と満期ロールを処理する。
• 適用される融資費用および実行費用を含めてください。
• 価格のみを基準とした比較対象と比較してください。

研究資料

各資料は、その横に記載された定義や根拠を支えています。擬似コード、架空の例、提案パラメータは別途検証が必要です。

1. Open InterestCME Group. 未決済契約の定義と、取引量との区別。 確認日: 2026-10-11.
2. Get Open InterestBybit. 製品単位、カウント項目、および更新に関する注意事項。実装で使用したバージョンを保持する。 確認日: 2026-10-11.
3. Reconciling Open Interest with Traded Volume in Perpetual SwapsGiagkiozis および Said. 改訂された要約とそのサンプル範囲である2023を検証したが、独立した再現実験は行わなかった。 確認日: 2026-10-11.

関連する手法