― DockerでBotを育てる「土台」としてのmacOS ―
前回の記事では、仮想通貨Botを動かすための全体構成とその意義について整理しました。今回からはその中身を“レイヤーごと”に深掘りしていきます。
第1回目のレイヤーは、**私が普段操作している「Mac本体＝ホスト側」**です。ここがすべての出発点であり、開発・管理・実行の拠点でもあります。
🧩1.1 ホスト側の主な役割は「コントロールタワー」
Botが実際に取引所とやり取りするのはDockerの中＝コンテナ内ですが、その操作パネル・指令室・メンテナンス作業場はすべてMac側にあります。
つまりMac側の役割はざっくり以下のようなもの：
| 役割 | 解説 |
|---|---|
| コードを書く | .pyファイルや設定ファイルを編集します。VSCodeやCursorエディタで作業。 |
| 環境を定義する | Dockerfile, .env.prod, docker-compose.yml などで、Botの動作条件を指定。 |
| 起動・停止・ビルド | ターミナルで docker compose コマンドを実行してBotを制御。 |
| ログを見る・トラブル対応 | docker compose logs などでBot内部の挙動を確認。 |
🛠️1.2 使用技術スタック（ホスト側）
▸ macOS (Apple M2)
開発用の母艦。Apple SiliconチップのmacOS上で、仮想通貨Botを開発・操作しています。
▸ Docker / Docker Desktop
Mac上でLinuxベースのBot実行環境を仮想的に作り出すツール。
Docker Desktop はGUI付きのDocker管理ツールで、Macのシステム上に「仮想マシン」を立て、そこにBotの世界（コンテナ）を構築します。
▸ docker-compose
複数の設定ファイルや環境変数を束ねて、ワンライナーで操作できる便利コマンド。
docker compose up -d --build # Botの起動＆ビルド docker compose down # 完全停止（再起動ポリシーも削除）
▸ プロジェクトフォルダ構成（例：MMBot/）
以下のような構成でBotを管理しています：
MMBot/ ├── .env.prod ← 環境変数：APIキーや戦略パラメータなどを集中管理 ├── config_mainnet.tpl ← 設定テンプレート：JSON形式で流し込まれる雛形 ├── core.py ← Bot本体ロジック。取引ループの中核（ホットスワップ可） ├── entrypoint.sh ← コンテナ起動時に呼ばれるシェルスクリプト ├── Dockerfile ← コンテナ環境の設計図 ├── docker-compose.yml ← サービス定義。volumeやrestartなどを記述 ├── logs/ ← コンテナからのログ出力用（bind mountで永続化） ├── mmtrades_mainnet.db ← SQLite形式のトレード履歴DB（コンテナ内生成・外部保存なし） └── ...（その他 util ファイル等）
🔸補足：DBファイルはホストには「残さない」方針
mmtrades_mainnet.dbはSQLiteベースでBotのトレード履歴などを記録- コンテナ内でのみ保持され、通常はホスト側にbind mountしない
- つまり、Bot再起動でDBは保持されるが、
docker compose downで初期化される
その目的は？
- 軽量でクリーンなBot運用（残存データによる誤判定や集計バグの予防）
- PnL集計やポジション再現は必要な場合のみ明示的にエクスポート
🔧必要ならDBだけを外部に出すことも可能
もしDBの永続化やバックアップが必要であれば、以下のように docker-compose.yml でvolume設定を追加すれば対応できます：
volumes: - ./db:/app/db # 例：コンテナ内の /app/db をホストの ./db にマウント
ただし、その場合はDB肥大化やバージョン整合性に注意が必要です。
🧠1.3 コードが反映される仕組み（ホットスワップ）
🧭【図解】ホットスワップ構造（volumesの役割）
flowchart TD
subgraph Mac側
A1[./MMBot/] --> A2[core.py]
A1 --> A3[.env.prod]
A1 --> A4[config_mainnet.tpl]
A1 --> A5[logs/]
end
subgraph Dockerコンテナ内
B1[/app/] --> B2[core.py]
B1 --> B3[config_mainnet.json]
B1 --> B4[/app/logs/]
B1 --> B5[entrypoint.sh]
end
A2 -- bind mount --> B2
A3 -- env_file注入 --> B5
A4 -- entrypointの envsubst --> B3
A5 -- bind mount --> B4
初心者がつまずきやすいポイントですが、この構成では「Mac側でコードを保存 → 再起動するとすぐに新コードが反映」されます。
その仕組みは以下の部分で実現されています：
volumes: - ./:/app:rw
- 左側（
./）：Mac上のプロジェクトフォルダ - 右側（
/app）：コンテナ内の作業ディレクトリ rw：読み書き可能
つまり、コンテナはMac上のソースコードをリアルタイムで読み込んでいるのです。
そのため、再ビルドせずに再起動 (docker compose restart) だけでコード更新が即時反映されます。
📁1.4 ログやファイルの出入りもMac側で完結
Botが動いている最中に発生するログデータやエラー情報は、コンテナ内で完結させず、すべて logs/ フォルダに外部出力します。
これにより：
- ログが永続化される（コンテナを消しても残る）
- ローカルでgrepやtailしてトラブル解析できる
という利点があります。
🧪1.5 運用時のコマンドはこの3つだけでOK
日々のBot運用は、Macターミナルから以下の3本柱で完結します：
| コマンド | 目的 |
|---|---|
docker compose up -d --build | 起動＆ビルド。環境変数変更後に必須。 |
docker compose down | 完全停止。エラーループ時や構成変更時に使用。 |
docker compose logs -f mmbot | 実行中のBotの様子をモニタリング。 |
🧵まとめ：ホスト側は「指令・管理・改修」の中枢
このように、Botの本体はコンテナの中ですが、開発・制御・管理はすべてMac側で完結しています。ここをしっかり理解することで：
- 設定ミスを未然に防ぎ
- ロジック変更が即座に反映でき
- トラブル時にも冷静に対処できる
という、運用力の高いBot開発者に一歩近づけます。