暗号資産アービトラージについて調べると、
すぐに「動くコード」を示す記事が多く見つかります。
しかし私は、現時点では
まだ一行も本番運用コードを書いていません。
実装に入る前に、私が暗号資産アービトラージ設計を3つ捨てた理由
暗号資産アービトラージについて書かれた記事の多くは、いきなりコードから始まります。
取引所APIを叩き、価格差を検出し、売買を自動化する――。
しかし私は まだ一行も本番運用コードを書いていません。
単純に書けないからではなく、
「書ける設計ほど破綻が速い」
という実務的な痛みを知っているからです。
この記事では、Pythonで暗号資産アービトラージ設計を進める過程で、
実装に入る前に捨てた3つの設計判断を共有します。
コードや完成形は示しません。
代わりに なぜそれらを「やらない」と判断したのか だけを書きます。
なぜ実装より先に「捨てること」を書くのか
私はこれまでPHPを中心に25年以上、
業務システムや決済系を含むシステム開発に関わってきました。
運用停止やロジック破綻が直接損失につながる領域を数多く設計してきました。
その現場で得た一つの結論はこうです。
問題は「どう書くか」ではなく、「何を先に書かないか」にある。
暗号資産アービトラージは：
- 実際に金が動く
- 外部APIに依存する
- API仕様が変わることが常態化している
この3つの特性によって、単純に動くコードを書くことが最優先ではない
という構造的な危険性があります。
捨てた設計①：単純な価格差検出 → 即発注モデル
最初に検討したのは、取引所間の価格差を検出して即時に発注する
最も教科書的なモデルです。
- 複数取引所の板情報を取得
- 最安値と最高値を比較
- 差があれば売買
ccxtなどを使えば数十行で組めます。(Qiita)
（秀逸な記事ですので、今すぐ組み始めたい方はそちらへ。私も PoC(Docomo) 作成の参考にしました。）
しかし、このモデルには次の問題があります。
- 板情報は「その瞬間の状態」であり、確定情報ではない
- 発注完了までの時間差が損失に直結する
- APIレスポンスの揺らぎが利益計算を破壊する
つまり、
検出時点では有利でも、
約定時点では不利になっている可能性を常に抱える。
これを単純モデルで扱うのは現実的ではありません。
この設計は、コストや手数料以上に構造的な欠陥を持つと判断しました。
捨てた設計②：非同期処理を前提とした高速化モデル
次に考えたのが、非同期処理を活用することで APIレスポンスの遅延を抑える設計です。
- asyncioによる並列APIコール
- レスポンス遅延の削減
- 即時価格更新への対応
一見、強い設計に見えます。
ですが非同期処理は制御と可視性を犠牲にします。
- どのAPIが遅れているか分かりにくい
- 失敗時の代替ルートが曖昧
- 失敗処理の境界が定まらない
この段階で、制御不能な多重非同期はむしろ損失リスクを高めると判断しました。
捨てた設計③：最初から完成形を描くアーキテクチャ
三つ目に検討したのは、
アービトラージシステムとして理想的なアーキテクチャを最初に描くことです。
- 複数取引所対応
- 永続的なDB設計
- ログ・監視・管理画面
これは一見すると正攻法です。しかし暗号資産の世界では仕様変更や挙動の不確実性が高く、完成形を前提にした設計は“変更不可能性”を抱えます。
変化の中で固定設計は必ず破綻しやすく、先に固定した完成形は柔軟性を失わせます。
それでも私はまだ実装していない
ここまで3つの設計を捨てましたが、「では何を採用したのか？」については、あえて明言しません。
理由は単純です。
- まだ完全に実運用レベルで成立する設計には到達していない
- 断言できる境界条件が整っていない
暗号資産アービトラージというミッションクリティカルな領域では、
「まだ書かない」判断そのものが最も重要な設計判断になることがあるという、
経験則があるからです。
動かない・存在していないのなら、
インシデント（事故）は起こり得ませんから。
最後に
この記事は、成功体験としてのチュートリアルではありません。
ただ、ひとつだけ確実に言えることがあります。
実装より先に、どの設計を捨てたかを書こう。
これが、破綻を遠ざける最初の一歩です。
アジャイル・プログラミング礼賛の昨今ですが、ウォーターフォール的な志向も、こういうとき大切だなと思うのでした。
とはいえ、開発が始まればスクラム組んで進むほうが好き（そうじゃないと無理）な私です。