Zaifのorder_id=0にハマった話 ── 即時約定の罠と3段階フォールバックで解決した全記録 | TechDistill

> Source: Zenn_Python

// Problem

Zaif APIでは即時約定時にorder_id=0が返るが、これがPythonのtruthy判定により「成功」と誤認され、約定確認ループに陥る。また、注文実行後に状態フラグを更新する設計のため、実行中の重複注文が発生し、ポジションが異常膨張するリスクを抱えていた。

// Approach

判定基準をorder_idからreceived（約定数量）へ変更し、注文実行前にペンディングフラグを立てることで重複を防ぐ。さらに、約定確認において「アクティブ注文の有無」「履歴の時刻照合」「残高差分」の3段階で検証を行うフォールバック機構を実装した。

// Result

取引所固有の特殊なレスポンス仕様を吸収し、注文の重複と無限リトライを完全に解消した。ccxt等のライブラリによる抽象化ではカバーしきれないエッジケースに対し、実レスポンスに基づいた堅牢なハンドリングを実現した。

Senior Engineer Insight

> 本件は、APIの抽象化レイヤーを過信することの危うさを露呈させている。金融系システムにおいて、外部APIの挙動は「仕様書通り」とは限らない。特に、即時約定のようなエッジケースでの状態遷移は、単一のIDに依存せず、数量や残高といった複数の観点から整合性を検証する「多層的な防御」が不可欠である。また、注文実行中の状態管理（ペンディングフラグ）を「実行前」に行う設計は、高頻度なリクエスト環境における重複実行を防ぐための基本であり、極めて重要な教訓である。実装の複雑性は増すが、システムの堅牢性と信頼性を担保するためには避けて通れないコストである。