# FIX プロトコル > FIX プロトコルは、注文や約定などの取引のメッセージを、金融機関や取引所のシステムの間でやりとりするための、公開された標準です。メッセージの意味と手順を定めるアプリケーション層と、メッセージを順番どおりに届けるセッション層があります。上場デリバティブの取引所には、注文の入力や約定の通知の写しの配信に使うところがあります。 - URL: https://www.derivatives-compass.org/ja/data-systems/fix-protocol/ - 分野: データ・システム › データの標準 - 最終確認日: 2026-10-21 - 英語版: https://www.derivatives-compass.org/en/data-systems/fix-protocol/index.md ## 要点 - FIX は、メッセージの意味を定める層と、順序と再送を扱う層に分かれ、FIX 4.4 の書き方はタグ=値形式と FIXML の 2 つです。 - 版は 4.2、4.4、5.0 SP2 などがあり、同じ約定の通知でも、版によって項目が違います。 - 上場デリバティブでは、注文の入力と約定の通知の写しの配信に FIX を使う取引所があります。 - FIX の仕様は、約定の通知の重複、再送、訂正、取消、番号の欠落への対応を定めています。 - 大阪取引所のデリバティブの売買システム J-GATE には、API や OUCH などの接続方式があります。 取引所やブローカーから約定の通知を受け取り、自社の取引管理システムに取り込む仕事では、通知の形式の 1 つとして [FIX](https://www.derivatives-compass.org/ja/glossary/fix-protocol/) を使う接続先があります。通知が二度届いたり、番号が飛んだりしたときに、取り込みがどう振る舞うべきかを知っていると、システムの担当者と業務の担当者が同じ前提で話せます。 ## FIX とは何か FIX（Financial Information eXchange）は、金融機関、取引所、ベンダーが、取引のメッセージを共通の形でやりとりするための標準です。FIX Trading Community が開発と維持を担い、仕様は公開されています。ネットワークの種類に依存せず、メッセージの構造と内容、手順を定めるプロトコルです[^fix-tc]。 対象の資産には、株式、債券、為替のほか、上場デリバティブと[店頭デリバティブ](https://www.derivatives-compass.org/ja/glossary/otc-derivative/)が入ります。メッセージは、取引の前、取引、取引の後に分けて整理されています[^fix-tc]。 | 段階 | 扱うこと | メッセージの例（MsgType） | | --- | -------------------- | -------------------------------------------------------------------------------------------------------------- | | 取引前 | 市場データ、気配 | Market Data Request（V）、Quote（S） | | 取引 | 注文と約定 | New Order - Single（D）、[Execution Report](https://www.derivatives-compass.org/ja/glossary/execution-report/)（8） | | 取引後 | アロケーション、確認、報告、持ち高の管理 | Allocation Instruction（J）、Trade Capture Report（AE）、Position Report（AP） | ## 層、書き方、版 FIX は、セッションとアプリケーションの 2 つの層で定義されています。セッション層はデータの配送を扱い、アプリケーション層は業務の内容を定めます[^fix44-levels]。 セッション層は、メッセージの個別の受領確認をしません。送る側がセッションの中で 1 から順に MsgSeqNum（番号）を付け、受ける側が番号の欠落を見つけて、再送を求める作りです[^fix44-optimistic]。 FIX 4.4 の仕様書では、書き方はタグ=値形式と FIXML の 2 つです。業務のメッセージの流れは同じで、同じものを別の書き方で表すだけです。タグ=値形式は、数字のタグと値を「タグ=値」の形で並べ、項目の区切りに制御文字の SOH（0x01）を使います。FIXML は XML の書き方で、セッション層を持たないため、FIX のセッションの中でも、ほかのプロトコルの上でも運べます[^fix44-syntax]。現行の仕様では、従来のタグ=値形式のほかに、binary や JSON などの形式もあります[^fix-tc]。 次の例は、先物の約定を知らせる Execution Report（MsgType が 8）を、FIX 4.4 のタグ=値形式で書いたものです[^orch-fields]。メッセージの名前と MsgType は、FIX 4.4 の定義のものです[^orch-msgtypes]。 **サンプル 1: 先物の約定通知（FIX 4.4 のタグ=値形式。抜粋・架空の例）** ```text 8=FIX.4.4| 9=243| 35=8| 34=2087| 49=SELLSIDE1| 56=BUYSIDE1| 52=20261021-01:23:45.200| 37=ORD-000123| 11=CL-000045| 17=EXEC-000789| 150=F| 39=1| 1=ACCT-DUMMY| 55=DUMMYFUT| 167=FUT| 200=202612| 54=1| 38=10| 32=4| 31=1234.5| 14=4| 151=6| 6=1234.5| 60=20261021-01:23:45.123| 75=20261021| 10=041| ``` 約定の通知は実際には 1 行で送られ、各項目の後ろに SOH が付きます。ここでは読みやすいように、SOH を `|` で表し、項目ごとに改行しました。BodyLength（9）と CheckSum（10）は、改行を除いた本来の形で計算した値です。 銘柄（DUMMYFUT）、注文と約定の ID、口座、会社の識別子（SELLSIDE1、BUYSIDE1）、数量、価格、日時はすべて架空のダミーで、そのままでは接続に使えない抜粋です。版は FIX 4.4 です。 見てほしい点は 2 つです。ExecType（150）が F（Trade）なので、新しい約定の通知です。LastQty（32）と LastPx（31）がこの約定の数量と価格で、CumQty（14）と LeavesQty（151）が注文の累計と残りの数量です。 同じ約定を FIXML で書くと、次のようになります[^fixml-schema]。 **サンプル 2: 同じ約定の FIXML（FIXML 4.4。抜粋・架空の例）** ```xml ``` FIXML 4.4 の抜粋で、値はすべて架空のダミーです。BodyLength と CheckSum に当たる属性は、FIXML のメッセージにはありません。 タグ番号の代わりに略称の属性名が使われ、ExecType は ExecTyp、OrdStatus は Stat、ClOrdID は ID になります。数量、価格、日時は ExecRpt 要素の属性で、銘柄の項目は Instrmt 要素、注文の数量は OrdQty 要素に分かれます。ヘッダーの項目は Hdr 要素の属性です。日付と時刻は、XML の日付と日時の形式（2026-10-21、2026-10-21T01:23:45.123Z）で書きます。 ### 版の考え方 FIX は、4.x の版から 5.0 のサービスパックを経て、2009 年からは「FIX Latest」に移りました。FIX Latest は、拡張パック（仕様を少しずつ加えていく単位）で更新されます。FIX Trading Community は、FIX Latest の利用を強く勧めています。2026 年 10 月時点で、古い実装のために 4.2 と 4.4 の対応も続けています[^fix-tc-versions]。 FIX 5.0 では、セッション層がアプリケーション層から分かれ、FIXT という別の版の名前を持ちます。アプリケーション層は「FIX.x.y」、セッション層は「FIXTx.y」で表します[^legacy-fixt]。5.0 SP2 は 2013 年 12 月 9 日の仕様で、19 の拡張パックを含みます[^legacy-sp2]。 版によって、項目の名前や使い方が違います。約定の取消と訂正の表し方を、FIX 4.2 と FIX 4.4 で比べると、次のとおりです[^orch-42-44]。 | 版 | 取消と訂正の表し方 | 数量（タグ 32）の名前 | | ------- | ------------------------------------------------- | ------------ | | FIX 4.2 | 約定は ExecType の 1、2。取消と訂正は ExecTransType（20）で分ける | LastShares | | FIX 4.4 | ExecType（150）の F、G（訂正）、H（取消）で表し、ExecTransType はない | LastQty | FIX Latest の ExecType も、F、G、H を持っています[^orch-42-44]。 同じ版でも、接続先ごとに標準との差があります。Cboe Futures Exchange は FIX 4.2 のサブセットを使い、標準との差を仕様書に書いています[^cboe]。[ドロップコピー](https://www.derivatives-compass.org/ja/glossary/drop-copy/)（取引所が約定の通知の写しを配信する仕組み）の ASX 24 の仕様は、FIX 5.0 SP2 の拡張パック 196 に基づいています[^asx-intro]。接続先の仕様書を読むときは、標準の版と、その仕様書が決めた差の両方を見ます。 ## デリバティブでの使いどころ 海外の上場デリバティブの取引所には、注文の入力と、約定の通知の写しの配信に FIX を使うところがあります。Cboe Futures Exchange は、先物とオプションの注文入力とドロップコピーに FIX を使います[^cboe]。 ドロップコピーは、取引所が、参加者の注文と約定に関するメッセージの写しを、別の接続に配信する仕組みです。ASX 24 の仕様書は、同じ会社の複数のユーザーの約定をまとめて受け取ることと、[清算参加者](https://www.derivatives-compass.org/ja/glossary/clearing-member/)が顧客の約定をまとめて確かめることを、使い方の例に挙げています[^asx-intro]。ASX 24 では、ドロップコピーの Execution Report は、注文の発注者に送る Execution Report と同じ業務の情報を持ち、CopyMsgIndicator（797）が Y になります[^asx-er]。 **図 1: 注文と約定の通知、ドロップコピーの流れ** 実線は、注文が自社のシステムから取引所へ向かい、約定通知が取引所から自社のシステムへ戻る向きを表します。点線は、取引所が清算参加者に、注文の入力とは別の接続で配信する約定通知の写しです。 店頭デリバティブでは、5.0 SP2 の拡張パックが、[米国商品先物取引委員会（CFTC）](https://www.derivatives-compass.org/ja/glossary/cftc/)のトレード・キャプチャの要件（拡張パック 77）に対応しました。清算の対象にする標準化されたクレジット・デフォルト・スワップの識別（拡張パック 83）にも対応しています[^legacy-sp2]。FIX Trading Community は、FIX が CFTC などの規制の報告にも使われていると説明しています[^fix-tc-reg]。 ### FpML、CDM との関係 [FpML](https://www.derivatives-compass.org/ja/glossary/fpml/) は、店頭デリバティブの取引の情報を表す XML の標準です[^boj-fpml]。FIX は、注文や約定のメッセージをやりとりする標準です。FpML の中身は[FpML](https://www.derivatives-compass.org/ja/data-systems/fpml/)で扱います。 FIX 4.4 には、2 つの標準をつなぐ方法があります。銘柄を表す Instrument の項目の中に、FpML の商品の仕様を入れられます。SecurityID（48）に FpML の仕様の XML か、その場所を示す URL を入れ、SecurityIDSource（22）に I（ISDA/FpML Product Specification）を指定します[^fix44-fpml]。 [ISDA CDM](https://www.derivatives-compass.org/ja/glossary/isda-cdm/) は、取引とイベントのデータモデルで、FIX、FpML、ISO 20022 などの標準の形でも表して、受け渡しや保存ができます[^finos-cdm]。 ## 約定を取り込むときの注意 FIX で届く約定の通知には、同じ通知が複数回届く場合、番号が飛ぶ場合、後から訂正や取消が届く場合があり、扱いは仕様で決まっています。取り込んだ約定を入力し、確認する業務は[約定の管理](https://www.derivatives-compass.org/ja/internal-operations/trade-capture/)で扱います。 ### 重複と再送 FIX には、再送を表す印が 2 つあります。PossDupFlag（43）が Y のメッセージは、同じ番号と同じ内容の再送です。受け取る側は、その番号のメッセージをすでに受け取っていれば無視し、まだなら通常どおり処理します[^fix44-posdup]。再送のときに変わる項目は、CheckSum、OrigSendingTime、SendingTime、BodyLength、PossDupFlag に限られます[^fix44-ordered]。 PossResend（97）が Y のメッセージは、同じ内容を新しい番号で送り直したものです。受け取る側は、注文番号のような項目を調べて、受け取り済みの内容かどうかを判断します[^fix44-posdup]。約定の通知なら、ExecID が手がかりの 1 つです。東京証券取引所の CONNEQTOR（気配提示の依頼と提示を扱うサービス）の接続仕様書には、参加者のシステムが PossResend を Y にして送った Execution Report の扱いが定められています。ExecID が受信済みの値なら、CONNEQTOR は受信済みと判断して破棄します[^conneqtor]。 受信した番号が期待より小さく、PossDupFlag もない場合は、重大な誤りです。セッションを切って、人が対応することが強く勧められています[^fix44-recovery]。 ### 欠落と Resend Request 受信した番号が期待より大きいときは、メッセージの欠落です。受け取る側は Resend Request（MsgType が 2）で再送を求めます。BeginSeqNo（7）に欠落の最初の番号、EndSeqNo（16）に最後の番号を入れ、「それ以降すべて」を求めるときは EndSeqNo を 0 にします[^orch-resend]。欠落した番号の後のメッセージは、欠落分を受け取る前に処理しません[^fix44-ordered]。 再送する側は、元の番号のまま PossDupFlag を Y にして再送するか、再送しないメッセージの番号を Sequence Reset（MsgType が 4）の Gap Fill で飛ばします。Logon や Heartbeat のような管理のメッセージは再送せず、Gap Fill で飛ばします[^fix44-recovery]。再送された約定の通知は、PossDupFlag が Y でも、元の通知を受け取っていなければ通常どおり処理します[^fix44-posdup]。 ### 訂正と取消 FIX 4.4 以降では、約定の通知の種類を ExecType で分けます。新しい約定は F（Trade）です。誤って報告された約定を取り消す通知は H（TradeCancel）、直す通知は G（TradeCorrect）です。いずれも、元の約定の ExecID を ExecRefID（19）で指します[^fix44-correct]。FIX 4.2 では、約定は ExecType の 1、2 で表し、取消と訂正は ExecTransType で分けます[^orch-42-44]。 訂正を複数回行うときは、ExecRefID が最後の訂正の通知の ExecID を指します。取消の通知を取り消すことはできません。取り消した約定を直したいときは、G ではなく F の通知を新たに送ります[^fix44-correct]。 訂正の通知の CumQty、LeavesQty、AvgPx は、訂正の時点の注文の状態です。元の約定の時点の値ではありません。同じ日に約定を取り消すと、CumQty が取り消した数量だけ減り、LeavesQty が同じだけ増えて、注文の数量は変わりません[^fix44-correct]。 次の例は、ログオンから約定の通知、番号の欠落、再送、取消、訂正までの並びです[^orch-seq]。 **サンプル 3: ログオンから約定通知、再送、取消、訂正までの並び（FIX 4.4。抜粋・架空の例）** ```text R>S 35=A|34=1|98=0|108=30| S>R 35=A|34=1|98=0|108=30| S>R 35=8|34=2|37=ORD-000123|17=EXEC-000789|150=F|39=1|32=4|31=1234.5|14=4|151=6| S>R 35=8|34=4|37=ORD-000123|17=EXEC-000791|150=H|19=EXEC-000789|39=1|14=6|151=4| R>S 35=2|34=2|7=3|16=0| S>R 35=8|34=3|43=Y|122=20261021-01:23:46.000|37=ORD-000123|17=EXEC-000790|150=F|39=2|32=6|31=1235.0|14=10|151=0| S>R 35=8|34=4|43=Y|122=20261021-01:23:47.000|37=ORD-000123|17=EXEC-000791|150=H|19=EXEC-000789|39=1|14=6|151=4| S>R 35=8|34=5|37=ORD-000123|17=EXEC-000792|150=G|19=EXEC-000790|39=1|32=6|31=1235.5|14=6|151=4| ``` 1 行が 1 つのメッセージで、SOH を `|` で表しています。S>R は約定を配信する側から受け取る側へのメッセージ、R>S はその逆です。受け取る側（R）が、配信する側（S）にログオンしたものとします。8、9、10、49、52、56 の項目は省き、再送の行には、FIX 4.4 で再送に付く OrigSendingTime（122）だけを残した抜粋です。会社、注文、約定の ID、数量、価格、日時はすべて架空のダミーです。版は FIX 4.4 です。 見てほしいのは次の点です。番号 2 の次に番号 4 が届き（MsgSeqNum（34）の 3 は失われたものとします）、Resend Request で 3 以降を求めると（番号 4 は、3 が届くまで処理を保留します）、再送された 3 と 4 は PossDupFlag（43）が Y で、番号は元のままです。最後の G のメッセージは、ExecRefID（19）で、直す約定の ExecID（EXEC-000790）を指します。 ### 約定の通知の識別子 約定の通知には、次の 3 つの識別子があります。どの識別子を、重複の判定や、元の約定の特定に使うかは、接続先の仕様書で確かめます。 | 識別子 | 付ける側 | 注意 | | ----------- | -------------- | ---------------------------------------- | | OrderID（37） | 売り手（ブローカー、取引所） | 1 取引日の中で一意。注文が変わっても変わらなくてよい | | ClOrdID（11） | 注文を出す側 | 取消や変更のたびに連鎖する。複数の接続をまとめるドロップコピーでは一意と限らない | | ExecID（17） | 売り手 | 約定の通知ごとの識別子で、訂正や取消の通知も別の値を持つ | ExecID が一意でなければならない範囲は、1 取引日の中か、複数日にわたる注文の存続期間の中です。複数日の注文を受ける会社では、OrderID と ExecID に日付を含めて、日をまたいでも一意にする設計があります[^orch-ids]。 接続先による違いもあります。ASX 24 のドロップコピーでは、ClOrdID は元の接続で入力された値で、複数の接続の活動をまとめて報告する接続では、一意とは限りません。取引所が付ける OrderID は一意で、注文の特定に使えます[^asx-er]。 ### 銘柄、口座と持ち高の例 銘柄は、Symbol（55）か、SecurityID（48）と SecurityIDSource（22）の組で表します。SecurityIDSource には、ISIN（4）、取引所のシンボル（8）、ブルームバーグのシンボル（A）などの値が決まっています。先物の限月は MaturityMonthYear（200）に YYYYMM の形で入ります[^orch-fields]。口座は Account（1）です。 通知を受けて[持ち高](https://www.derivatives-compass.org/ja/glossary/position/)を更新する処理を、F は加算、H は打ち消し、G は置き換えとする、取り込む側の設計の架空の例で考えます。先物の買い注文 10 枚に対して、上のメッセージの並びと同じ 4 通の通知が届くものとします。FIX の仕様が定めるものではありません。 | 通知の ExecID | ExecType | 通知の内容 | 取り込み後の買い持ち | | ----------- | -------------------------- | ------------ | ---------- | | EXEC-000789 | F | 買い 4 枚の約定 | 4 枚 | | EXEC-000790 | F | 買い 6 枚の約定 | 10 枚 | | EXEC-000791 | H（ExecRefID が EXEC-000789） | 4 枚の約定の取消 | 6 枚 | | EXEC-000792 | G（ExecRefID が EXEC-000790） | 6 枚の約定の価格の訂正 | 6 枚 | G の通知は枚数を変えず、約定の価格を 1235.0 から 1235.5 に直します。届いた順に処理すると、EXEC-000791 の取消が EXEC-000790 より先に届いたとき、持ち高は一時的に 0 枚になります。FIX の仕様では、欠落した番号の後のメッセージを、欠落分より先に処理しません[^fix44-ordered]。 ## 日本取引所グループのデリバティブ 日本取引所グループ（JPX）は、大阪取引所のデリバティブの売買システムを J-GATE と呼びます。J-GATE への接続方式には、取引用の API と OUCH があります。API は、相場情報の受信と、注文の発注、訂正、取消ができる共通の接続方式です。OUCH は、注文の発注、訂正、取消に特化した方式です。相場情報は、API か ITCH で受け取ります[^jpx-jgate]。 J-GATE が OMnetAPI で配信する、ユーザーごとの注文と約定に関する配信メッセージのデータは、ドロップコピーのデータとして提供されます。ドロップコピーのデータを使えるのは、大阪取引所の取引参加者だけです[^jpx-alt]。JPX のこれらのページが挙げる接続方式は、API、OUCH、ITCH、OMnetAPI で、FIX は含まれていません。 ## この記事が書いていないこと FIX の全メッセージと全項目の定義、各接続先の仕様の違い、国内の証券会社経由の約定の連携は、この記事では扱いません。 [^fix-tc]: FIX Trading Community「The FIX Protocol」（2026 年 10 月 21 日に参照）の "An Introduction to the FIX Protocol"、"What It Is (and Isn't)"、"The FIX Protocol's Scope and Reach"。 [^orch-msgtypes]: FIX Trading Community の FIX Orchestra（OrchestraFIX44.xml、FIX 4.4 の拡張パック 311 時点）の MsgType（35）のコード一覧と、メッセージの定義 TradeCaptureReport（AE、略称 TrdCaptRpt）。 [^fix44-levels]: FIX Protocol Limited「FIX 4.4 Specification with 20030618 Errata」Volume 2 の 3 ページ、"Introduction"。 [^fix44-optimistic]: 同 Volume 2 の 3〜4 ページの "Sequence Numbers"、"Message Acknowledgment"、6 ページの "Session Protocol"。 [^fix44-syntax]: 同 Volume 1 の 14 ページの "FIX Protocol Syntax"、18 ページの "Message Format"、"Field Delimiter"、23 ページの "FIXML Syntax"。 [^orch-fields]: FIX Orchestra（OrchestraFIX44.xml、FIX 4.4 の拡張パック 311 時点）のタグ番号とフィールド名の定義。BodyLength と CheckSum は FIX 4.4 の Volume 2 の 4 ページと 26 ページの方法で計算し、例は仕様書の例を写さず作りました。 [^fixml-schema]: Liquid Technologies による FIXML 4.4 のスキーマの解説（ExecRpt、Hdr、Instrmt、OrdQty、FIXML の各要素と属性、日付と日時の型）。 [^fix-tc-versions]: FIX Trading Community「The FIX Protocol」の "How It Works"（2026 年 10 月 21 日に参照）。 [^legacy-fixt]: FIX Trading Community「Legacy FIX Specifications」の FIX 5.0 の項（2026 年 10 月 21 日に参照）。Transport Independence の枠組みと、FIXT 1.1 への言及。 [^legacy-sp2]: 同ページの "FIX 5.0 Service Pack 2 Specifications (9 December 2013)" の項。拡張パック 77 は CFTC のトレード・キャプチャの要件、83 は清算対象の標準化クレジット・デフォルト・スワップの識別です。 [^orch-42-44]: FIX Orchestra の FIX 4.2（拡張パック 310）、FIX 4.4（拡張パック 311）、FIX Latest（拡張パック 312）の ExecTransType（20）、ExecType（150）、タグ 32 の定義。 [^cboe]: Cboe「Cboe Titanium Cboe Futures Exchange FIX Specification」の "Introduction"（2026 年 10 月 21 日に参照）。 [^asx-intro]: ASX Operations Pty Limited「ASX 24 FIX Drop Copy Specification V2.05」（2023 年 10 月）の 4 ページ、"1. FIX Drop Copy Introduction"、"1.1. Supported Versions"。 [^asx-er]: 同仕様書の 24 ページ、Execution Report の冒頭の注意と OrderID（37）、ClOrdID（11）の説明。CopyMsgIndicator（797）が Y になることも同じ箇所です。 [^fix-tc-reg]: FIX Trading Community「The FIX Protocol」の "The FIX Protocol's Scope and Reach"（2026 年 10 月 21 日に参照）。 [^boj-fpml]: TC68 国内委員会事務局「ISO 20022 の概要」（2015 年 3 月）の 6 ページ、脚注 13。 [^fix44-fpml]: FIX 4.4 の Volume 1 の 38〜39 ページ、"Specifying an FpML product specification from within the FIX Instrument Block"。SecurityIDSource（22）の I は、FIX Orchestra の定義で ISDAFpMLSpecification です。 [^finos-cdm]: FINOS「Common Domain Model- An Overview」（2023 年 10 月）の 3 ページ、"Mapping" の行と、4 ページ、"CDM vs. FpML"。 [^fix44-posdup]: FIX 4.4 の Volume 2 の 4 ページ、"Possible Duplicates"、"Possible Resends" と、11 ページ、"Standard Message header"。 [^fix44-ordered]: 同 Volume 2 の 3〜4 ページ、"Ordered Message Processing"、"Possible Duplicates"。 [^conneqtor]: 東京証券取引所「CONNEQTOR FIX接続仕様書（投資家/接続編）」の 2.1「システム概要」と 6.4「アプリケーションレベルの再送メッセージ」。 [^fix44-recovery]: FIX 4.4 の Volume 2 の 8 ページ、"Message Recovery"。 [^orch-resend]: FIX Orchestra（OrchestraFIX44.xml、FIX 4.4 の拡張パック 311 時点）の ResendRequest（2）、BeginSeqNo（7）、EndSeqNo（16）の定義。 [^fix44-correct]: FIX 4.4 の Volume 4 の 11〜13 ページ、Execution Report の説明（Trade Cancel、Trade Correct、取消の日の扱い）。ExecRefID（19）は FIX Orchestra の定義です。 [^orch-seq]: FIX Orchestra（OrchestraFIX44.xml）の Logon（A）、ResendRequest（2）、PossDupFlag（43）、OrigSendingTime（122）、ExecRefID（19）の定義。FIX 4.4 の Volume 2 の 4、8 ページ。 [^orch-ids]: FIX Orchestra（OrchestraFIX44.xml）の OrderID（37）、ExecID（17）の説明。複数日の注文では日付を含めることを検討するよう記されている。OrderID が注文の変更で変わらなくてよいことは、FIX 4.4 の Volume 4 の 12 ページ。 [^jpx-jgate]: 日本取引所グループ「Derivatives Trading Systems (J-GATE)」の "2. J-GATE Connectivity Methods"（2026 年 10 月 21 日に参照）。 [^jpx-alt]: 日本取引所グループ「Alternative Data Service J-GATE」の "Drop Copy Data" の項（2026 年 10 月 21 日に参照）。 ## 出典 - [The FIX Protocol](https://fixtrading.org/standards/fix-protocol/) — FIX Trading Community - [FIX 4.4 Specification with 20030618 Errata](https://fixtrading.org/packages/fix-4-4-specification-with-20030618-errata/) — FIX Protocol Limited - [FIX Orchestra, FIX Standard (OrchestraFIX42.xml、OrchestraFIX44.xml、OrchestraFIXLatest.xml)](https://github.com/FIXTradingCommunity/orchestrations/tree/master/FIX%20Standard) — FIX Trading Community - [Docs for schema item ExecRpt in Financial Information eXchange (FIX)](https://schemas.liquid-technologies.com/fixml/4.4/execrpt.html) — Liquid Technologies - [Legacy FIX Specifications](https://fixtrading.org/legacy-fix-specifications/) — FIX Trading Community - [Cboe Titanium Cboe Futures Exchange FIX Specification](https://www.cboe.com/document/tech-spec/content/technical-specifications/cboe-titanium-cboe-futures-exchange-fix-specification) — Cboe Global Markets - [ASX 24 FIX Drop Copy Specification V2.05](https://www.asxonline.com/content/dam/asxonline/public/documents/NTP%20document%20library/Protocol%20technical%20specifications/asx-fix-drop-copy-specification.pdf) — ASX Operations Pty Limited - [ISO 20022 の概要](https://www.boj.or.jp/paym/iso/isotc68/data/1ISO20022gaiyo.pdf) — TC68 国内委員会事務局（日本銀行金融研究所） - [Common Domain Model- An Overview](https://www.finos.org/hubfs/Projects%20%2B%20SIGs/CDM%20-%20Common%20Domain%20Model/CDM%20Overview.pdf) — FINOS - [Derivatives Trading Systems (J-GATE)](https://www.jpx.co.jp/english/systems/derivatives-trading/01.html) — 日本取引所グループ - [Alternative Data Service J-GATE](https://www.jpx.co.jp/english/markets/paid-info-alternative/j-gate/index.html) — 日本取引所グループ - [CONNEQTOR FIX接続仕様書（投資家/接続編）](https://jpxsystem.com/doc/cq/doku.php?id=spec%3Ajp%3Aconnection) — 東京証券取引所