アセマネファンドの国内先物におけるVaR証拠金とBloombergでの算出実務

2023年11月、日本証券クリアリング機構（JSCC）の先物・オプション証拠金計算ロジックが、従来のSPAN方式からVaR（ヒストリカル・シミュレーションVaR）方式へ移行した。

インデックスファンド（先物買い）やベータヘッジ・ベータニュートラル戦略のファンド（先物売り）など、単一限月の片道ポジションを保有するだけの運用であっても、キャッシュバッファの管理や証拠金算出の前提は従来から大きく変わっている。将来の自分やチームメンバーのための備忘録として、実務上の影響とBloombergでのデータ取得をまとめておく。

1. VaR方式への移行に伴う実務的な変化

旧SPAN方式と現在のVaR方式では、証拠金の算出ロジックが根底から異なる。アセマネ実務において留意すべき主な変更点と前提知識は以下の通り。

• 「過去5年の最悪ケース」の正確な意味 現在のHS-VaR方式は、過去約5年（1,250営業日）のヒストリカルデータやストレスシナリオ等から価格変動シナリオを生成し、損失分布のテール（97.5% Expected Shortfall）を用いて、結果的に99%をカバーする水準として証拠金を算出している。
• 売りと買いで証拠金単価が異なる理由 旧SPAN方式では下落リスクと上昇リスクを対称とみなし、売り買いで証拠金単価は同一だった。一方のVaR方式では、方向ごとの過去の損失分布に基づいて算出される。過去の相場データにおいて損失分布は非対称であるため、実際の公表値では買い（ロング）の方が高くなるケースが多いが、固定的な大小関係として理解すべきではない。
• 「パラメータの日次更新」と「値洗い」の違い 先物実務で毎日行われる「値洗い（Variation Margin：前日の清算値と本日の清算値の差額を日々現金精算すること）」と混同されやすいが、ここでの話は「証拠金の単価（パラメータ）そのものが毎日更新される」ということ。 旧SPAN時代、「1枚あたりの必要証拠金額」は原則週1回しか改定されなかった。しかしVaR方式では、JSCCが毎営業日15:45～16:00頃に最新のボラティリティを反映したパラメータを公表し、その日の必要証拠金として即日適用する。相場変動に応じて証拠金単価が日々上下するため、ファンド内の現金バッファのコントロールはよりシビアに行う必要がある。
• プロシクリカリティ抑制策（フロア設定など） 相場が平穏な局面でも証拠金が過度に低下しないよう、追加のストレスシナリオやボラティリティ下限値など、プロシクリカリティ（順循環性：証拠金急増が投げ売りを呼ぶ悪循環）の抑制策が設けられている。
• スプレッドリスクの相殺とは何か 例えば、期近を売り、期先を買っている状態（スプレッドポジション）を想像してほしい。日経平均が急落しても、期近の売りポジションで利益が出て、期先の買いポジションの損失をカバーするため、トータルでの大損は起きにくい。 VaR方式では、ポートフォリオ全体に対して各シナリオの損益を計算する。結果として、両限月の共通した価格変動によるリスクが相殺され、主として限月間の価格差の変動によるリスクが残るため、必要証拠金が大幅に安く計算される仕組みになっている。

2. Bloomberg（BDP関数）でのVaR証拠金取得のリアル

単一の先物・片道ポジションについては、Bloombergから1枚あたりの証拠金額を取得し、「証拠金単価 × 枚数」という形で管理用の概算額を算出できる。ただし、取得するフィールドには実務上の制約がある。

存在しない「MS（売り単価）」フィールド

JSCC自身は「売り1枚」「買い1枚」それぞれの証拠金額を正式に公表している。しかし、Bloombergの標準フィールドにおいて、買い用フィールドである FUT_INIT_SPEC_ML は存在するが、対応する売り用フィールド FUT_INIT_SPEC_MS は存在しない。

ファンド方針ごとの実務対応

このデータ取得環境の制約を踏まえると、ファンドのポジション方向によってExcel等での管理に以下のような特徴が出る。

• インデックスファンド（先物買い）

• 計算式: FUT_INIT_SPEC_ML × 枚数

• 精度: JSCCが公表する1枚あたりの買い証拠金に概ね対応する（JSCCも明記している通り、複数枚計算時の端数処理等により少額の誤差が生じる場合はあるため、1円単位での完全一致は保証されない）。

• ベータヘッジファンド（先物売り）

• 計算式: FUT_INIT_SPEC_ML × 枚数（※代用）

• 精度: キャッシュバッファ管理上の簡便な「保守的見積り」となる。

• 理由: 実際の公表値では買い単価の方が高いケースが多いため、売りポジションにML（買い単価）を代用して適用すれば、結果として少し多めの金額が算出され、資金ショートを防ぐ安全サイドのバッファ管理として機能しやすい。ただし、これはあくまで代用計算であり、実際の売り必要証拠金額とは異なる点に留意が必要だ。

3. 複数ポジション・スプレッド保有時の罠

平常時（片道ポジション）であればBDP関数の掛け算が管理用として機能する。 また、期近から期先へ乗り換える「ロールオーバー」も、実務上はカレンダースプレッド取引として同時約定させるため、数日間にわたって両建てで持ち越す（オーバーナイトする）ケースは限定的かもしれない。

しかし、万が一ファンドの移行戦略などで「期近と期先を同時に保有するポジション」が発生したり、日経225とTOPIXを組み合わせたりするケースでは、各銘柄・限月の単価をBDPで個別に取得して (単価A × 枚数) + (単価B × 枚数) と単純合算してはいけない。

JSCCは「銘柄別ファイルによる単価計算は1銘柄保有時のみ有効であり、複数ポジションには使えない」と明記している。単純合算をしてしまうと、前述のリスク相殺が一切反映されず、実際の必要額に対して過大な証拠金額を見積もることになってしまう。

正確な相殺後の証拠金所要額を確認する場合は、ブローカーから提供されるステートメントを参照するほか、JSCC自身が提供している「Web試算環境」や「VaR証拠金計算ソフトウェア（VMA ※2026年現在もアップデートされ提供中）」を利用してポートフォリオ単位で計算する必要がある。

まとめ

単一銘柄・片道ポジションのキャッシュバッファ管理という目的なら、現状の FUT_INIT_SPEC_ML × 枚数 は簡便な管理方法として利用できる。一方、複数限月・複数商品を跨ぐポートフォリオの正式な証拠金所要額を求める場合には、この方法ではVaRの相殺効果を再現できない。

VaRへの移行により「売り/買いの非対称性」と「ポートフォリオ全体でのリスク相殺を反映した評価」が導入された。現場のミドル・バックオフィス担当者は、「Bloombergから引いた数字をどこまで信じて（あるいは割り切って）業務に使うべきか」を正しく線引きしておくことが重要だ。