🛠️開発記録#261(2025/7/10)一人開発者が築く“堅実な”暗号資産 Bot 基盤──設計・運用・スケールまとめ

暗号資産のマーケットは、価格も仕様も API も“昨日の正解”がすぐ陳腐化する世界です。
一人開発で勝ち続けるには 「戦略を量産しては捨てる」 を苦なく回せる土台──すなわち 堅実だが可塑性の高い基盤 が欠かせません。本稿では Mac mini でのローカル開発からクラウド移行、そしてコンテナ分離・プラグイン設計まで、実践で得た教訓を 設計・運用・スケール の3軸で整理します。

設計や運用思想のような"振る舞い及び考え方の軸"が定まっていると下流のことはほぼ作業になるので、色々と楽。
私は後々ラクしたいという気持ちが強いけど、同時に今この瞬間も楽しみたいという気持ちもあるので、その両方を丁度良い感じのバランスで満たしてくれるbotterというポジションが好き。

— よだか(夜鷹/yodaka) (@yodakablog) July 10, 2025

1. 序章：なぜ“あとから外せる”構造が必須なのか

市場の変化速度と戦略寿命

• スプレッド縮小・取引所仕様変更・競合 Bot の増加──アルファは短命。
• 「ダメだ」と分かった戦略を秒速で剝がせる体制が、次の実験コストを劇的に下げる。

500 行警告フックに学ぶ“早期分割”の心得

• 1 ファイル 500 行超で pre-commit が warning → “規模が臭う”タイミングを可視化。(理想は300行以内)
• 小さく切るほど単体テストが速く、ロールバックも最小 diff
• 実装→検証→撤去を 1 日サイクルで回すには、リファクタ容易性が最優先。

アルファ探索フロー

flowchart LR
    idea([アイデア]) --> rec[Recorder<br>データ蓄積]
    rec --> eda[EDA & Backtest]
    eda -->|勝てる| deploy[Feature Flag ON<br>本番へ]
    eda -->|勝てない| trash[Git tag<br>戦略墓場]
    deploy --> monitor[Real-time Monitor]
    monitor -->|劣化| trash
    style trash fill:#ffdcdc,stroke:#ff8080

2. 三層アーキテクチャの基礎

2-1. ロジック層／I-O 層／設定層とは何か

2-2. 追加で意識すべき Service 層・Interface 層

2-3. DTO＆依存方向ルールで守るモジュール境界

• DTO (Data Transfer Object) を dataclass 化し層間通信を固定
• 依存矢印は 上 → 下 の一方通行。下位層が上位層を import しない
• 抽象（Protocol / Interface）で注入し、テスト時はスタブで差し替え

層構造の全体像

graph TD
    ui["Interface<br>(CLI / REST)"]
    svc["Service / Orchestrator"]
    logic["Business Logic<br>(Strategy)"]
    infra["Infrastructure<br>(Exchange, DB)"]
    ext[(取引所 API<br>DB, Slack)]
    config[("Settings / Secrets")]

    ui --> svc
    svc --> logic
    logic --> infra
    infra --> ext
    logic -->|Read-only| config
    svc -->|Read-only| config

2-4. Bot 開発のチェックポイント＆ヒント

【bot開発のチェックポイント＆ヒント】
☑️ロジック層から外部ライブラリ import が無いか確認 →分離の漏れが見える

☑️DTO や dataclass で層間のやり取りを固定する
→将来の変更が局所化

☑️依存方向は“上→下”のみ（上位層が下位層の抽象に依存）。逆依存を検出する CI ルールを入れると安全

— よだか(夜鷹/yodaka) (@yodakablog) July 9, 2025

# .github/workflows/static-check.yml 例
- name: Detect upward dependencies
  run: |
    pip install pydeps
    pydeps src/mmbot --no-show-deps | grep "↖" && exit 1 || echo "No upward deps"

Tip: ここでエラーが出たら “どの import が越境したか” を grep で探し、
① DTO を追加 → ② 依存を下層に寄せる → ③ Facade を削除、の順で修正すると安全です。

次章以降では Recorder ファーストの検証フロー、戦略プラグイン化とフィーチャーフラグ、Mac mini 省リソース術 など、具体的な実装＆運用テクニックを掘り下げていきます。

3. Recorder ファースト：アルファ検証のワークフロー

3-1. データ取り → EDA → Go/No-Go 判定の高速ループ

sequenceDiagram
    participant R as Recorder
    participant DB as Data Lake
    participant NB as Notebook / EDA
    participant JR as Jenkins / CI
    participant BT as Backtester
    participant Ops as Ops Flag

    R->>DB: ① Raw Tick / Funding / Depth<br>Parquet or Kafka
    NB-->>DB: ② SQL / pandas で探索
    NB->>JR: ③ 仮説パラメータを commit
    JR->>BT: ④ 自動 Backtest Matrix
    BT-->>JR: ⑤ Metrics (PnL, DD, Sharpe…)
    JR->>Ops: ⑥ 成績閾値を満たす？<br>Yes → feature_flag ON<br>No  → tag as trash

1. Recorder
   • Exchange REST/WS → Kafka or Parquet。
   • シンボル・頻度は最小構成（例：BTCUSDT, 1 m）。
2. EDA (Exploratory Data Analysis)
   • Jupyter/Polars/Pandas で Hypothesis-Driven に可視化。
3. Backtest 自動化
   • GitHub Actions などで パラメータ行列を全パターン回す。
4. Go/No-Go 判定
   • 指標テンプレ：Win% ≥ 55 && MaxDD ≤ 5%。
   • 通過したら Feature Flag を ON し本番で 1 % サイズから試す。
   • 落ちたら git tag failed/2025-07-10-α1 → 墓場フォルダへ移動。

3-2. スキーマ統一と欠損ガードのチェックリスト

3-3. TTL 設定とコスト最適化の考え方

4. 戦略プラグイン化とフィーチャーフラグ

4-1. BaseStrategy インタフェース設計

# core/strategy/base.py
from dataclasses import dataclass
from abc import ABC, abstractmethod
from decimal import Decimal
from typing import Iterable, Dict

@dataclass
class MarketSnapshot:
    ts: int
    bid: Decimal
    ask: Decimal
    position: Decimal

class BaseStrategy(ABC):
    id: str                     # 'mm_v1', 'arb_cex', ...
    version: str                # git sha / semver

    @abstractmethod
    async def warmup(self, snapshots: Iterable[MarketSnapshot]) -> None: ...

    @abstractmethod
    async def generate_signals(
        self, snapshot: MarketSnapshot
    ) -> Dict[str, Decimal]:  # {'buy': qty, 'sell': qty}
        ...

ポイント

• I/O 依存ゼロ → ユニットテストは DTO を流すだけ。
• id, version を必ず返し ログ & メトリクスにラベル付け。

4-2. entry_points / importlib でホットプラグ

# pyproject.toml
[project.entry-points."mmbot_strategies"]
mm_v1 = "mm_v1.strategy:MMV1"
arb_magic = "arb_magic.strategy:ArbMagic"

# service/loader.py
import importlib.metadata as md
from core.strategy.base import BaseStrategy

def discover(enabled_ids: set[str]) -> list[type[BaseStrategy]]:
    for epi in md.entry_points(group="mmbot_strategies"):
        if epi.name in enabled_ids:
            yield epi.load()

• pip install -e . でロード完了。
• bot 再起動せず --enable-strategy arb_magic で即テスト。

4-3. ON/OFF 切替を 1 行にする Feature Flag パターン

# config/flags.yaml  (Central Repo)
enabled_strategies:
  - mm_v1
  - arb_magic
risk_limits:
  mm_v1: {maxPos: 1000}
  arb_magic: {maxPos: 200}

# service/runner.py
import yaml, watchdog.events

class FlagWatcher(watchdog.events.FileSystemEventHandler):
    def on_modified(self, _):
        Runner.reload_flags()

class Runner:
    @classmethod
    def reload_flags(cls):
        flags = yaml.safe_load(open("/mnt/config/flags.yaml"))
        cls.active_ids = set(flags["enabled_strategies"])

• K8s ConfigMap or Docker bind-mount 更新 → watch → 自動リロード。
• 緊急停止は vim flags.yaml → save で完了。

フラグ適用フロー

flowchart LR
    ops["Ops<br/>edit flags.yaml"] --> cm["ConfigMap<br/>reload"]
    cm -- inotify --> runner["Runner<br/>reload_flags()"]
    runner --> loader["StrategyLoader"]
    loader -- "Δ enabled_ids" --> orchestrator["Orchestrator"]

次章では コンテナ分離 & リソース制御、Mac mini 省エネ運用術、クラウド移行の IaC 手順 を解説し、一人開発でも“壊さず速く”成長できる体制を仕上げます。

5. コンテナ分離の実践

5-1. 戦略ごとに分けるメリット & デメリット

5-2. 「3 Bot + Recorder」構成図

graph TD
    subgraph namespace[ ]
        recorder[Recorder<br>Market Stream]
        mm[FRMM Bot]
        arb[Arb Bot]
        liq[Liquidation Snipe Bot]
        nats[NATS / JetStream]
        psql[(TimescaleDB)]
        vault[HashiCorp Vault]
    end

    recorder -->|Tick| nats
    mm -->|Subscribe| nats
    arb -->|Subscribe| nats
    liq -->|Subscribe| nats

    mm --> psql
    arb --> psql
    liq --> psql
    recorder --> psql

    vault --> mm
    vault --> arb
    vault --> liq

5-3. Helm/Compose 最小サンプル

docker-compose.yml（抜粋）

version: "3.9"
services:
  nats:
    image: nats:2.10
    command: ["-js", "-sd", "/data"]
    ports: ["4222:4222"]
    volumes: ["./data/nats:/data"]

  recorder:
    build: ./recorder
    env_file: .env.recorder
    deploy:
      resources:
        limits: {cpus: "1.0", memory: "512M"}
    depends_on: [nats]

  frmmbot:
    build: ./frmmbot
    env_file: .env.frmm
    deploy:
      resources:
        limits: {cpus: "1.5", memory: "1G"}
    depends_on: [nats]

  arbbot:
    build: ./arbbot
    env_file: .env.arb
    deploy:
      resources:
        limits: {cpus: "1.0", memory: "1G"}
    depends_on: [nats]

  snipebot:
    build: ./liqbot
    env_file: .env.liq
    deploy:
      resources:
        limits: {cpus: "1.0", memory: "1G"}
    depends_on: [nats]

Helm values.yaml

global:
  imagePullPolicy: IfNotPresent
  vaultAddr: "http://vault.vault:8200"

recorder:
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
  env:
    NATS_URL: "nats://nats:4222"

strategies:
  - name: frmm
    replicas: 1
    resources:
      limits: {cpu: "1", memory: "1Gi"}
    env:
      STRATEGY_ID: "frmm_v1"
  - name: arb
    replicas: 1
    resources:
      limits: {cpu: "1", memory: "1Gi"}
    env:
      STRATEGY_ID: "arb_cex"
  - name: liq
    replicas: 1
    resources:
      limits: {cpu: "1", memory: "1Gi"}
    env:
      STRATEGY_ID: "hyperliq_snipe"

5-4. Secrets / 資金 / API レートリミットの中央ガード

6. Mac mini 開発環境を守る 6 つの Tips

multi-stage Dockerfile 雛形

# builder
FROM python:3.12-alpine AS builder
WORKDIR /app
RUN apk add --no-cache build-base
COPY pyproject.toml poetry.lock ./
RUN pip install poetry && poetry export -f requirements.txt --output reqs.txt

# runtime
FROM python:3.12-alpine
WORKDIR /app
COPY --from=builder /app/reqs.txt .
RUN pip install -r reqs.txt --no-cache-dir
COPY src/ ./src
ENTRYPOINT ["python", "-m", "src.cli"]

運用ヒント

• docker stats で CONTAINER 内 MEM%>90 が続けば restart: on-failure + back-off を設定。
• 冷却ファンは吸気↔排気を意識して配置すると 5 ℃ 以上差が出る。

次章は クラウド移行ロードマップ と CI/CD・セキュリティ自動化。これで “小さく作って速く回す” 基盤が完成します。

7. クラウド移行ロードマップ

7-1. 最小 VPS スペックと月額試算

*2025-07 時点の税込み目安。円換算 ≒€ 1 = ¥160 / $ 1 = ¥155

7-2. IaC 化（Terraform + Ansible）４ステップ

• 1,Terraform で箱だけ作る

resource "hcloud_server" "mm_main" {
  name        = "mm-main"
  image       = "ubuntu-22.04"
  server_type = "cpx31"
  ssh_keys    = [hcloud_ssh_key.default.id]
}

• 2,Ansible で共通ロール
  • roles/docker, roles/vault_agent, roles/promtail
  • 変数は group_vars/{recorder,bot,infra}.yml
• 3,CI で terraform apply → ansible-playbook の２段ジョブ
  • PR マージで自動デプロイ。
• 4,State 管理：Back-end S3 + DynamoDB lock（or Hetzner Storage Box）

7-3. Prometheus + Grafana Cloud で統合監視

flowchart LR
    node_exporter[Node Exporter]
    python_exporter[Python / Custom Metrics]
    promtail[Promtail]
    prometheus[Prometheus<br>Docker]
    loki[Loki<br>Docker]
    grafana[(Grafana Cloud)]

    node_exporter --> prometheus
    python_exporter --> prometheus
    promtail --> loki
    prometheus --> grafana
    loki --> grafana

設定ハイライト

# prometheus.yml
scrape_configs:
  - job_name: 'bots'
    static_configs:
      - targets: ['localhost:9100','localhost:8000']   # Node & Python
remote_write:
  - url: https://prometheus-blocks-prod-us-central1.grafana.net/api/prom/push
    basic_auth:
      username: <instance_id>
      password: <api_key>

7-4. バンド幅・レイテンシチェックの落とし穴

8. CI/CD・セキュリティ・運用自動化

8-1. GitHub Actions → self-host runner 連携

name: Build & Deploy
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t bot:${{ github.sha }} .
      - run: docker save bot:${{ github.sha }} | gzip > bot.tar.gz
      - uses: actions/upload-artifact@v4
        with: {name: image, path: bot.tar.gz}

  deploy:
    runs-on: self-hosted   # VPS 内に runner
    needs: build
    steps:
      - uses: actions/download-artifact@v4
      - run: gunzip -c image/bot.tar.gz | docker load
      - run: docker compose up -d --no-deps bot

8-2. SBOM と脆弱性スキャンを bot 横断で共有

成果物を GitHub Security タブで集中管理 → 週次 Dependabot レポート。

8-3. Incident Runbook & Slack アラート設計

sequenceDiagram
    Bot ->> Prometheus: metric{position_dd, high_temp}
    Prometheus ->> Alertmanager: firing rule
    Alertmanager ->> Slack: webhook (ops-alerts)
    Slack ->> On-call: mention + runbook link
    On-call ->> Vault: fetch keys
    On-call ->> Bot: manual throttle / restart

Runbook checklist

1. Slack 通知受信 → 異常メトリクスを Grafana で確認
2. kubectl exec -it bot -- python tools/pause.py で緊急停止
3. 原因別フロー：Rate-limit / Liquidity 欠損 / ポジション競合
4. Jira ticket 作成 → Post-mortem 24 h 内提出

まとめ

• 最小コスト → 収益拡大に応じてスケールするクラウド設計で、マシン・人・学習コストを最適化。
• IaC, モニタリング, セキュリティを最初から仕組みに落とし、“壊れても 1 コマンドで復旧” を担保。
• Incident Runbook とフィーチャーフラグで トラブルを局所化し、25 分以内に緊急停止を徹底――これが個人でも戦える運用体制の鍵です。

9. 収益とコストのバランスシート

9-1. サーバー費用と期待 PnL シミュレーション表

†税込み概算（2025-07 現在）。*PnL はバックテスト中央値 –20 % を安全係数として採用。

9-2. “黒字ライン” に乗るまでのフェーズ分け

flowchart LR
    classDef phase fill:#e0f0ff,stroke:#007acc,stroke-width:1px,rx:6,ry:6

    p0(["Phase 0<br/>検証<br/>2025-07-01 → 07-14"]):::phase
    p1(["Phase 1<br/>初期黒字<br/>after p0 21d"]):::phase
    p2(["Phase 2<br/>スケール<br/>after p1 30d"]):::phase
    p3(["Phase 3<br/>自走<br/>after p2 45d"]):::phase

    p0 --> p1 --> p2 --> p3

10. まとめと次の一手

10-1. 「高速に試し、失敗を安く捨てる」文化

1. Recorder ファーストで “市場を観測してから動く”
2. プラグイン戦略 + フィーチャーフラグでホットスワップ
3. 三層＋サービス層でテストと撤去を 1 日以内に
4. IaC & 監視の自動化で「壊れても 1 コマンド復旧」
5. 収益↔コスト可視化で“黒字ライン”を常に把握

10-2. 今後の拡張ロードマップ

アクションプラン（ざっくり版）

横断タスク（Phase A–D で逐次実施）

1. Secrets 統合 ― Vault に mev_bot, nft_sniper, liq_bot の AppRole を発行。
2. Rate-limit Guard ― Envoy Lua で token-bucket、上限超過時は自動 back-off。
3. Cost Tracker ― Google Sheet 自動更新（Cloud Functions で Prometheus → Sheet）。
4. 依存チェック CI ― pydeps 逆依存ルールを新 bot にも追加。

次の“一歩”チェックリスト

• Flashbots RPC で自アカウントから 1 件 bundle 成功 → TxHash ログ保存
• ERC-721c ミントコントラクトを Hardhat テストネットでリプレイ・bypass ケース検証
• Hyperliquid Keeper テストジョブを登録し、job_status Polling が動くことを確認
• ポイント API で Bybit / Backpack のポイント残高取得スクリプトを Cron 登録

原則：「小さく作って速く試す、ダメなら安く捨てる」――このサイクルが維持できるかどうかが、次の拡張フェーズで資金と時間を溶かさない最大の鍵です。

10-3. 今後のアクション：自分の開発フロー点検チェックリスト

• ファイル行数警告フックは設定していますか？
• Recorder → EDA → Go/No-Go のパイプラインは 30 分で回せますか？
• Secrets / Rate-limit を中央で制御できていますか？
• クラウド費用と期待 PnL を Spreadsheet で即更新できる仕組みは？

まずは 1 日で「Recorder 専用 VPS を IaC で立ち上げ、Prometheus にメトリクスが流れる」までをやってみましょう。これが速く出来れば、Bot 開発のチューニングも必ず加速します。