﻿---
title: "ポストオンリー注文"
description: "ポストオンリー注文は、即時に流動性を取らず板に残ることを意図した取引所固有の指値注文条件です。拒否、取消し、価格変更、キュー優先順位、手数料は正確なマッチング規則で決まります。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ポストオンリー注文

> 教育目的に限って提供するもので、投資助言ではありません。注文、手数料、約定は、取消しまたは最終照合までに変化する可能性があります。

<a id="answer"></a>

## 要点

ポストオンリーまたは流動性追加限定の条件は指値注文に付加され、注文がマッチングエンジンに到達した時点で判定されます。一部でも既存の流動性と直ちに約定する場合、取引所は固有の規則に従い、リクエストを拒否する、受理後に注文を取り消す、または市場性のない水準へ価格を移すことがあります。したがって、ポストオンリーは板への参加条件であり、結果が一つに定まる普遍的な注文種類ではありません。

板に残った注文は、その後に反対側の注文が到着すると約定できます。その約定は通常メイカー流動性に分類されますが、実際の約定記録と手数料台帳が優先します。確認応答、`open` 状態、ポストオンリーフラグだけでは、約定、メイカー扱い、リベート、良好な純結果のいずれも保証しません。

<a id="mechanism"></a>

## 仕組み

市場性は古い画面ではなく、エンジンの状態で判定されます。通常、最良売気配以上の買い指値と最良買気配以下の売り指値は板をクロスします。呼値への丸め、オークション、ロックまたはクロスした板、非表示流動性、価格保護、自己取引防止によって結果が変わる場合があります。自動価格変更も指定指値とキュー位置を変えるため、明示的に受け入れた取引所規則でなければなりません。

ポストオンリーは他の条件から独立しています。`GTC`、`GTD`、`IOC`、`FOK` は有効期間を規定し、一部の取引所ではポストオンリーと即時執行条件の組合せを拒否します。`reduce-only`、決済限定、ポジションサイドのフィールドはエクスポージャーを制御します。ストップ注文や利食い注文は発動まで板に入らない場合があり、変換された子注文がその時点のポストオンリー規則で判定されます。

キューとライフサイクルの意味も取引所固有です。価格時間優先は一般的ですが、普遍的ではありません。価格変更、数量増加、取消し・再発注では優先順位を失うことが多く、対応する数量削減なら維持できる場合があります。自己取引防止により、新規注文、既存注文、または両方が取消し・減量されることがあります。実際の結果を立証するのは、順序付けられた公開・非公開イベントだけです。

次の手順を使います。

1. 取引所、法的事業体、商品、セッション、APIバージョンを固定し、呼値、取引単位、最低想定元本、手数料階層、市場性のあるポストオンリー注文が拒否、取消し、価格変更のどれになるかを記録します。
2. タイムスタンプ付きでシーケンスが整合する最良買気配、最良売気配、深さを取得し、売買方向、指値、数量、有効期間、ポジションモード、ポストオンリー、リデュースオンリー、自己取引防止、トリガーフィールドを明記します。
3. 価格と数量を正確に丸め、クロス、価格帯、残高、証拠金、注文上限、両立しないモードを事前確認します。ただし、エンジン到達時の状態を最終判断とします。
4. 一意のクライアント注文IDで送信します。通信成功と受理、板への掲載、終端状態を分け、サーバー注文ID、タイムスタンプ、完全な応答を記録します。
5. 順序付けられた注文・約定イベントを受信し、累積約定、残数量、約定ID、価格、想定元本、流動性フラグ、手数料・リベート通貨、キューを変える変更を照合します。
6. 終端イベントが到着するまでは、変更、取消し、置換を競合状態として扱います。タイムアウト後は冪等に再試行し、重複、欠落、順序逆転の後は再同期します。
7. 約定、取消し、拒否、期限切れの数量を在庫、拘束資金、残高と照合し、実際の手数料、リベート、逆選択、未約定を評価します。オンチェーン取引所では、取込み、プロトコル実行、必要なファイナリティを別途検証します。

<a id="example"></a>

## 例

- **板をクロスする場合。** 最良買気配と最良売気配が `99.90 / 100.00`、呼値が `0.01` とします。ポストオンリー買い `2 BTC at 100.00` は直ちに売気配と約定します。拒否型の取引所はリクエストを拒否し、取消し型は約定ゼロのまま注文を取り消します。価格変更型では `99.99` へ移すことがありますが、その文書化された動作を指定した場合に限ります。エンジン状態が変わらなければ `99.99` の買い注文は板に残る可能性がありますが、約定は保証されません。
- **板に残ったメイカー約定と手数料。** 売り `3 ETH at 99.90` が、最良買気配と最良売気配が `99.80 / 100.00` のとき板に残り、その後に積極的な買い注文が約定させます。想定元本は `3 x 99.90 = 299.70` です。メイカー料率が `-1 bp` なら、手数料は `299.70 x -0.0001 = -0.02997`、つまりリベートです。誤って `5 bp` のテイカー料率に分類すると `0.14985` の支払いとなり、差は `0.17982` です。実際の流動性フラグと手数料記録を使います。
- **部分約定と取消しの競合。** 板にあるポストオンリー売りを `10 units at 100` とします。`4` が約定してからクライアントが取消しを送り、終端の取消し前にさらに `1` が約定し、残り `5` が取り消されます。総約定数量は `5` であり `4` ではありません。約定想定元本は `500` で、`2 bp` のリベートは `0.10` です。取消し確認応答は最終在庫記録ではありません。
- **低い手数料でも総費用は高くなり得る。** `10` を `100.00` で即時購入し、`8 bp` のテイカー手数料を払う総費用は `1,000.80` です。その価格を逃し、`100.20` で板に残して `2 bp` のメイカー手数料で約定した総費用は `1,002.2004` です。メイカー経路は手数料を `0.5996` 節約しますが、総費用は `1.4004` 高くなります。ポストオンリーは執行動作を管理するもので、取引全体を自動的に最適化しません。

<a id="risks"></a>

## リスク

- 取引所または商品について誤ったポストオンリー規則を想定する。
- 市場性のある注文が予想外に拒否、取消し、価格変更される。
- 気配遅延により、クライアントでは非クロスの価格がエンジン到達時にクロスする。
- 呼値への丸めが送信価格またはクロス判定を変える。
- ロックした板、オークション、特別取引モードが動作を変える。
- 板に残った注文が約定しない。
- 逆選択がメイカーリベートを上回る。
- 手数料階層、リベートの符号、手数料通貨が変わる。
- 各約定ではなく注文リクエストからメイカー扱いを推測する。
- キューの深さまたは非表示流動性を過小評価する。
- 注文変更でキュー優先順位がリセットされる。
- 部分約定が在庫または現金から漏れる。
- 取消し・置換競合で追加約定または重複注文が生じる。
- タイムアウトや非冪等な再試行で不確実または重複した状態が生じる。
- WebSocketの欠落、重複、順序逆転でローカルビューが壊れる。
- 自己取引防止が予想外の側を取消しまたは減量する。
- ポストオンリーが `IOC`、`FOK`、別の有効期間規則と競合する。
- リデュースオンリー、決済限定、ポジションモードが意図を拒否、縮小、反転する。
- 発動後の子注文が市場性を持ち、取消しまたは拒否される。
- 取引所、カストディ、API、規則の障害、またはオンチェーンの順序付け、ガス、再編成、ファイナリティにより照合できなくなる。

<a id="misconceptions"></a>

## よくある誤解

- **ポストオンリーなら約定が保証される。** 拒否、取消し、未約定のまま掲載、期限切れになる場合があります。
- **APIの成功応答は注文が板にある証拠である。** 通信確認とマッチングエンジンの状態は別の記録です。
- **ポストオンリーの約定はすべてリベートを得る。** メイカー分類、手数料階層、通貨、料率は約定と取引所に固有です。
- **変更または取消し後に約定することはない。** 優先順位がリセットされる場合があり、終端確認より先に約定が競合に勝つこともあります。
- **トランザクションハッシュまたはブロックへの取込みは、オンチェーン注文がメイカー流動性になり最終的に約定した証拠である。** 取込み、プロトコル実行、掲載状態、約定、チェーンファイナリティは別のイベントです。

<a id="related"></a>

## 関連トピック

- [暗号資産の指値注文](/ja/crypto/limit-order-crypto/)
- [メイカーとテイカーの手数料](/ja/crypto/maker-taker-fee/)
- [暗号資産の板](/ja/crypto/order-book-crypto/)

<a id="sources"></a>

## 出典

- [Coinbase Markets Trading Rules](https://www.coinbase.com/legal/trading_rules) - Coinbase（参照日：2026-08-13）
- [Create a new order](https://docs.cdp.coinbase.com/api-reference/exchange-api/rest-api/orders/create-new-order) - Coinbase Developer Documentation（参照日：2026-08-13）
- [Exchange Matching Engine](https://docs.cdp.coinbase.com/exchange/concepts/matching-engine) - Coinbase Developer Documentation（参照日：2026-08-13）
- [Order Management Best Practices](https://docs.deribit.com/articles/order-management-best-practices) - Deribit Documentation（参照日：2026-08-13）
- [Post-Only Order](https://www.bybit.com/en/help-center/article/Post-Only-Order) - Bybit（参照日：2026-08-13）
- [Basic Order Types](https://www.okx.com/en-us/help/x-basic-order-types) - OKX（参照日：2026-08-13）
- [Order Amend Keep Priority](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/order_amend_keep_priority.md) - Binance Spot API Documentation（参照日：2026-08-13）
- [Exchange endpoint](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint) - Hyperliquid Docs（参照日：2026-08-13）

Source: https://wiki.fcontext.com/ja/crypto/post-only-order/index.mdx
