【要約】Untitled [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動売買システムを開発するエンジニアが、Zaif APIの成行注文時に発生する予期せぬレスポンスによって、注文失敗と誤判定してしまう問題。具体的には以下の事象が発生する。
- ・成行注文が即時約定すると、order_idが0で返却される。
- ・order_id > 0を成功条件とする実装では、これをエラーと見なす。
- ・結果として、実際には約定しているにもかかわらず再注文を行い、二重注文を招くリスクがある。
// Approach
開発者がAPIレスポンスの判定ロジックを、単一のID確認から多角的な状態判定へと刷新する手法。以下のステップで堅牢性を高める。
- ・successフィールドを最優先の判定基準として採用する。
- ・order_id=0かつremainsが極小値の場合を「即時約定（FILLED）」と定義する。
- ・未約定注文のみを監視対象とするステートマシンを導入する。
- ・注文前後の残高差分を用いた二重確認ロジックを実装する。
// Result
開発者がZaif API特有の挙動を正しく制御し、堅牢な注文管理を実現できる。具体的な改善点は以下の通りである。
- ・order_id=0による誤判定と二重注文のリスクを排除できる。
- ・remainsの閾値判定や残高照合により、丸め誤差や通信エラーに強い実装が可能になる。
- ・取引所ごとの仕様差を吸収する設計パターンが確立される。
Senior Engineer Insight
> 取引所APIのドキュメントは、必ずしも実装の全挙動を網羅していない。本件のように「成功しているのにIDが0」という矛盾した挙動は、実運用でのみ露呈する。防御的プログラミングの観点から、successフラグの優先、残高による整合性チェック、閾値を用いた浮動小数点比較は、金融系システムにおける必須の作法である。また、レートリミットへの配慮も不可欠だ。