― Botが「生きて」「死んで」「また蘇る」仕組み
前回のセクションで「外部インターフェースと情報の流れ」について解説しました。
しかし、Botは一度起動すれば永久に走り続けるわけではありません。
実際には、一定のサイクルで停止・再起動されたり、異常検出で自動的に落ちたり、手動で再ビルドされたりします。
このセクションでは、その**“生と死”を管理するライフサイクル設計**を図解とともに解説します。
🧩7.1 全体のライフサイクルフロー
まずは「Botのライフサイクル全体像」を俯瞰しましょう。
🧭【図解】MMBotのライフサイクルフロー
flowchart TD
A["docker compose up --build"] --> B["Dockerfile → イメージ生成"]
B --> C["コンテナ起動"]
C --> D["entrypoint.sh 実行"]
D --> E["core.py 実行"]
E --> F{"Botが正常終了？"}
F -- Yes --> G["Slack通知 → exit 0"]
F -- No --> H["例外 or DD hit → exit"]
H --> I["Dockerの再起動ポリシーが発動"]
I --> C
🛠️7.2 Botの起動から実行までの仕組み
起動はいつもこのコマンド：
docker compose up -d --build
| 処理 | 内容 |
|---|---|
--build | Dockerfile を元に最新イメージを再構築 |
-d | バックグラウンドで実行（ログは別で確認） |
up | コンテナを作成し、起動 |
この時点で、以下の順で処理が流れます：
- イメージが再構築される（
core.pyや.env.prodを反映） - コンテナが生成されて起動
entrypoint.shが実行され、設定ファイルを流し込みcore.pyがスタート →run_loop()が回り始める
⚠️7.3 正常終了 vs 異常終了の違い
Botはループを終えたあと、次のように終了します：
| 終了パターン | 原因 | 挙動 |
|---|---|---|
exit(0)（正常） | 指定サイクル数に達した／自発的終了 | 再起動されない（unless-stopped） |
exit(1)（異常） | 設定エラー／例外／DD Hit | 再起動ポリシーにより復活する |
🔄7.4 Docker再起動ポリシー restart: unless-stopped
docker-compose.yml には以下の設定があります：
restart: unless-stopped
これは：
🔁「Botが自分で落ちても、ユーザーが止めない限り自動で復活する」
という**“自己蘇生”のような機能**です。
🧪例：設定ミスで落ちたとき
.env.prodに誤った値（例：カンマの欠如）があるjq emptyでconfig_mainnet.jsonが壊れてると検出されるentrypoint.shがexit 1- コンテナが終了 → 再起動 → また失敗 → 再起動...
こうして「無限再起動ループ」に入ります
📦7.5 手動で完全に止めたいときは？
無限ループから抜けたい／Botを完全停止したいときは、次のコマンド：
docker compose down
| コマンド | 内容 |
|---|---|
down | コンテナの停止＋削除＋ネットワーク解体 |
up | コンテナの起動（再生成される） |
restart | 今あるコンテナを再起動（再ビルドなし） |
♻️7.6 ホットスワップとの連携：再起動だけでロジック更新
この構成ではコードが bind mount されているため、
Mac側で .py を保存 → 再起動だけで反映されます。
docker compose restart
これで、再ビルドせずに core.py の修正だけが反映されるので、非常に効率的です。
🧵まとめ：再起動ポリシーとライフサイクルを制す者がBotを制す
- コンテナは「起動 → 実行 → 終了」の中で柔軟に再起動される
- Dockerの
restart: unless-stoppedにより自律回復が可能 - 「正常終了」はそのまま静かに停止、「異常終了」は何度でも復活
- 再起動だけでコード変更が即反映される開発体験
次回（セクション8）では、「ファイル別運用早見表」や「日常操作コマンド一覧」などを通して、Bot開発・運用を効率化する実践Tips集をお届けします。