― Botが「生き物として目を覚ます」瞬間を解き明かす
前回は、Botの起動時に entrypoint.sh がテンプレートを整え、設定の検証まで行っていることを見てきました。
今回は、いよいよその後に呼び出される**Pythonモジュール本体 core.py**の初期化処理について解説していきます。
🚀4.1 core.py とは何か？
core.pyは、仮想通貨Botのメインロジックが詰まった心臓部です。
具体的には：
- APIキーなどの設定を読み込み
- ログの初期化
- データベースの準備
- WebSocketやRESTの接続
- 実際の取引ループに入る
など、**「Botとして動き始めるために必要なこと全て」**を担当します。
🧩4.2 初期化ステップの全体像
ここでは core.py 起動直後に行われる主要な初期化処理をステップごとに分けて紹介します：
| ステップ | 概要 |
|---|---|
| ① CLI引数解析 | argparseで --mode などの引数を処理。 |
| ② configファイル読み込み | config_mainnet.json を読み、各種API設定などを取得。 |
| ③ エンドポイント設定 | モード（mainnet / testnet）に応じてURLを切り替え。 |
| ④ SQLite DB 初期化 | 取引履歴などを保存するDBファイルを生成（通常は一時的）。 |
| ⑤ ロガー設定 | loguru によりログ出力を整備。日次ローテート付き。 |
このあとに「取引ループ」が開始されますが、それは次回解説予定です。
🧭【図解】core.py の初期化処理の流れ
flowchart TD
A["core.py 実行開始"] --> B["argparseで--modeを解釈"]
B --> C["config_mainnet.jsonを読み込み"]
C --> D["モードに応じたURLを選択"]
D --> E["SQLite DB 初期化"]
E --> F["loguruでログ設定"]
F --> G["取引ループへ（次回解説）"]🧪4.3 ステップごとの初心者向け補足
🔸① CLI引数解析（argparse）
parser = argparse.ArgumentParser()
parser.add_argument("--mode", default=os.getenv("MMBOT_MODE", "mainnet"))
args = parser.parse_args()
- 起動時に
--mode mainnetのような引数を受け取る - 指定がなければ
.env.prodのMMBOT_MODEを使う - つまり 環境変数ベースで制御できる柔軟な設計
💡これは何をしているの？
ここでは、**「Botをどのモードで動かすか」**を決めています。
たとえば、テストネットで動かすのか、本番の取引所で実弾運用するのか――この切り替えを行っているのがこの箇所です。
🧪詳しく見てみましょう：
| 処理 | 解説 |
|---|---|
argparse.ArgumentParser() | コマンドライン引数を受け取る準備をする。 |
add_argument("--mode", ...) | --mode という名前の引数を受け取るように設定。 |
default=os.getenv(...) | もし --mode が指定されなかった場合は、.env.prod に定義された MMBOT_MODE を使用。 |
"mainnet" | 環境変数も無かった場合の最終的なデフォルト値。 |
✅ポイント：
- 優先順位は次のようになります：
--mode引数（コマンドラインで渡された）
→.env.prodの MMBOT_MODE
→"mainnet"という文字列 - この仕組みのおかげで、Botは柔軟な起動が可能になります。
🧪なぜCLI引数と環境変数の“ハイブリッド”にするのか？
初心者にありがちな疑問ですが、「環境変数だけで良くない？」と思うかもしれません。
でもこの方法には、実運用上の強力なメリットがあります：
| メリット | 説明 |
|---|---|
| テスト時の切り替えが速い | 本番とテストの切り替えが --mode testnet の一言で済む。 |
| 自動化との相性が良い | CI/CDやスクリプトから起動時にモードを柔軟に指定できる。 |
| 環境変数の上書きができる | .env を書き換えずに一時的な実験ができる（事故防止）。 |
🔍例：手動でテストネットで起動したいとき
docker compose run mmbot python -m MMbotbybit.core --mode testnet
こうすることで .env.prod の内容を変更せず、一時的にtestnetで起動できます。
🧵まとめ：引数＋環境変数＝Botの柔軟性の鍵
このCLI引数処理は一見地味ですが、Botのモード管理や運用の安全性にとって非常に重要です。
複数Botを同時運用したり、戦略別に切り替えたりする未来に向けて、今のうちにしっかり理解しておきましょう。
🔸② 設定ファイルの読み込み
with open("config_mainnet.json") as f:
config = json.load(f)
entrypoint.shが生成した 構文検証済みの設定ファイル- APIキー、シンボル名、取引単位、DD閾値などがここに集約
- 構造的に問題ない状態が保証されている
🔸③ モード別URL選択
if args.mode == "testnet":
base_url = "https://api-testnet.bybit.com"
else:
base_url = "https://api.bybit.com"
- mainnet/testnet の切り替えを明示
- 他にも WebSocket のURLなどもこの時点で定義される
🔸④ SQLite DB の初期化
db = sqlite3.connect("mmtrades_mainnet.db")
- ローカルファイル型DBを一時的に作成
- 取引ログや失敗履歴などの記録用
- ホストには永続化しない設計（実験的に作成→破棄される）
💡これは何をしているの？
Botが取引をする際に、発注・約定・キャンセル・損益などの履歴を記録するためのローカルデータベースを作っています。
sqlite3.connect(...) によって、Bot内で小型データベース（.dbファイル）を生成し、以後の処理で使えるようになります。
🧪なぜSQLiteを使うのか？
SQLiteは以下のような特徴を持つ、組み込み型の軽量データベースです：
| 特徴 | 内容 |
|---|---|
| インストール不要 | Pythonに標準で組み込まれている。 |
| サーバー不要 | PostgreSQLやMySQLのように外部サーバーが不要。ファイルだけで動く。 |
| 高速＆軽量 | ローカルファイル操作なので読み書きが速い。 |
| 小規模用途に最適 | 単一Botのトレードログ程度であれば十分な性能。 |
📁このDBファイルの扱いと寿命
Bot起動時に .db ファイルが作られ、実行中のトレードログがそこにどんどん書き込まれます。
ただし、本構成では：
🔸DBはホスト側にbind mountされていない
🔸コンテナ内で一時的に生成され、コンテナ停止時に破棄される
という設計になっています。
🔒なぜあえて外部保存しないのか？
この設計には意図があります：
| 意図 | 理由 |
|---|---|
| 軽量運用 | テスト運用や頻繁な再起動時に、不要な過去データで肥大化しない。 |
| 安全性 | Botがクラッシュした後に古いログを読み込んで誤動作するのを防ぐ。 |
| 簡単なメンテ | 「止めたら消える」前提でシンプルに保てる。 |
💡もしログを永続保存したい場合は？
もちろん、取引ログを長期保存したいという場面もあるはずです。
その場合は docker-compose.yml に以下のような volume定義を追加すればOKです：
volumes:
- ./db:/app/db
そして、コード内のDB接続を以下のように変更します：
sqlite3.connect("db/mmtrades_mainnet.db")
🛠️活用アイデア：DBを活かしたトレード分析
- 取引履歴をエクスポートしてExcelで可視化
- スリッページ／勝率／ポジションサイズなどの統計出力
- 特定条件下でのfill率分析（HFT向け）
など、後工程（分析・改善）に使える強力な武器になります。
🧵まとめ：SQLiteはBotに最適な「小型の脳」
- 軽くて早くて壊れにくい
- 本番でもテストでもすぐ使える
- ログの蓄積・分析・デバッグに役立つ
本構成では最初は消えるDBで運用し、必要になったら永続化を検討するという段階的アプローチが採用されています。
これはBot開発を柔軟かつ安全に進めるための合理的な選択です。
🔸⑤ ロガーのセットアップ
from loguru import logger
logger.add("logs/{time:YYYY-MM-DD}.log", rotation="1 day")
loguruを使った超シンプルかつ強力なログ管理- 毎日1ファイルに自動ローテート
- Slack通知・PnLログなどとあわせて、Botの可観測性を担保
🧵まとめ：core.pyは「Botとして立ち上がるための一連の儀式」
この初期化プロセスのおかげで：
- モード切り替えが自由に行え
- API接続の安全性が保たれ
- ログとデータが記録され
- ロジックが安定して稼働を始められる
という堅牢な起動体制が築かれています。