Yodaka

マーケットメイカー戦略において、「スプレッドが開いた瞬間にだけ発注する」ロジックは、効率よく期待値を積み上げる上で極めて重要なアプローチです。しかし、その「スプレッドが開いたかどうか」をどう検知し、どのように記録・分析するか？という点については、意外と情報が整理されていません。 本記事では、自作のMarket Maker Botにおいて「秒足クロスによる全約定→即ヘッジ」という手数料ループから脱却するために、板幅（Top-of-Bookのbid/ask差）を基準としたスプレッド判定ロジックを導入するまでの ...

セクション1｜はじめに — 秒レベルで精度を上げたかった話 トレード戦略の調整を続ける中で、どうしても無視できなくなってきたものがあった。それは「時間分解能(どれくらい細かく時間軸で物事を測定できるか)」だ。 私は現在、板寄せ系の自動取引戦略を継続開発している。本番環境での稼働も視野に入れつつ、パフォーマンスチューニングを繰り返している段階だが、とある時点でバックテストと実運用の数値が乖離していることに気づいた。 バックテストでは、「このロジックなら Maker fill 比率は高くなるはずだ」と思ったも ...

1. はじめに ─ なぜ “ログと DB の分離” がボット運用の死活を分けるのか 結論：テキストログ と 構造化データ（DB） を “同じ場所／同じ設計思想” で扱うと、いつか必ず ボットが止まるか、データが飛ぶか、どちらかが起こる。 取引ボット――とくに FR (Funding Rate) × Market Making のように保有時間が数秒〜数時間 と振れ幅の大きい戦略では、「1 秒毎に大量に吐き出されるイベントログ」 と「1 取引で 1 行残る実績レコード」 が同居します。 区分特性具体例破綻シ ...

【思考ログ】・最適なエントリとは、fill 確率と exit 確率を掛け合わせた期待値が最大になる瞬間に注文を出すことであり、・それに対して、Exitとは、「市場に向けて抱いた仮説（≒entry）を、現実として精算するフェーズ」である。— よだか(夜鷹/yodaka) (@yodakablog) June 7, 2025 1.はじめに ─ FR × Market Making が生む “二重のエッジ” 「同じ 1 ドルを 2 回稼ぐ」――Funding Rate（FR）とマーケットメイク（MM ...

今週は「システム周りの細々したことをさわりつつ、必要なものだけを最小構成で取り入れた」一週間でした。 1. 今週のハイライト 🔦 日付キーワードざっくり出来事5/31v2 基盤リファクタ.env 分離, docker-compose 再配線を完了。270 file の大掃除コミットでレガシー CI 設定・不要 GitHub files を一斉削除。6/1再起動体制完成restart: unless-stopped で Docker 自律再起動 を組み込み、watchdog.sh を DRY-RUN/Sla ...

1. はじめに – “防御ファースト”の一日 仮想通貨の自動取引botを実戦投入する前に、どうしても先に片付けておきたかった課題がある。それが 「Slack通知が飛ばなくなったらBotを即座に止める仕組み」 だ。 一見すると「そこまでしなくても…」と思えるかもしれない。けれど私にとっては、これが本番投入への “絶対条件” だった。 なぜなら、botの暴走が発覚する頃には大抵ポジションは天井か底を突き抜けていて、Slack通知が届かないというのはすでに「異常が外部から観測できない状態」を意味するからだ。 今 ...

1. はじめに ── テストネット調整から本番スモールテストへ 今回の開発フェーズでは、テストネット上で整えてきた運用基盤とロジックの安全性を一通り確認し、その上で ミニマムサイズの本番稼働テスト（Mainnet Small Test） に踏み出す準備を進めた。 具体的には、以下のようなステップを意識して構築・検証を進めていった： Makefile ベースでの 環境ごとの起動／停止の切り替え .env.testnet / .env.production による 環境分離と本番APIキーの安全管理 テンプレ ...

1. はじめに：プロジェクトの再編からスタート 仮想通貨Botの運用に向けて、今回はプロジェクト構造の再編から着手した。その理由は単純で、「機能が増えてきた分、構成が煩雑になってきた」からだ。 特に次のような課題が浮かび上がっていた： スクリプト間の依存関係がコードを追わないと分からない 各種ファイル（設定・ログ・DBなど）の保存場所が散らかっている Dockerコンテナとホストマシンの間でファイルパスが不安定 こうした状態では、本番運用への移行やCI/CDの自動化、監視体制の構築が足を引っ張られるのは目 ...

🎯 目的 Botが沈黙・フリーズ・ログ出力停止したときに自動的に検出し、Slack通知を出す 必要に応じて再起動 or 停止を自動で行う それらの定期監視を Cron に組み込む ✅ 実施した取り組みと到達点 1️⃣ watchdog.sh の設計と実装 主な監視機能： logs/MMBot.log の更新が止まっていないか（タイムスタンプ差分を pnl_age として計算） pnl_report.csv の最終更新が古すぎないか Slack へのエラー通知機能（Webhook） 安全制御ラップを実装済み ...

🧭 背景とスタート地点 元々はバラけた構造と断片的なスクリプトの中で テストネットBotの再稼働に取り組む状況だった。 特に「Docker + Compose での一貫運用」と「config生成の自動化」「環境切り替えの安全性」を確保するには、構成の全面的な見直しが必要だった。 🛠️ リポジトリ再構築フェーズで乗り越えた課題 ① コンテナが即終了する問題の原因特定と修正 症状：docker compose up -d でBotが即終了、ログはほとんど出ず。 原因： .env.testnet 内の環境変数と ...