🛠️開発記録#227(2025/5/14)トレードロジック以外の基礎部分🌐セクション6：外部インターフェースと情報の流れ

― Botが外の世界とやり取りする「入口」と「出口」

これまでのセクションでは、Botの内部処理（起動・初期化・取引ループ）を順に見てきました。
しかしBotは、ひとりで完結しているわけではありません。

このセクションでは、以下のような**外部インターフェース（I/F）**が、どのようにBotと関わっているかを整理していきます。

🧩6.1 主なインターフェース一覧

これらが組み合わさって、「Botは市場とユーザーに対して観測・判断・報告」しているのです。

🧭【図解】Botと外部との情報のやり取り（構造図）

flowchart TD
    subgraph Container
        A[core.py]
        B[loguru_log]
        C[sqlite_db]
    end

    subgraph Bybit
        D1[REST_API]
        D2[WebSocket_API]
    end

    subgraph User
        E[Slack_notification]
        F[Host_log_view]
    end

    A -- POST/GET --> D1
    D2 -- Orderbook_stream --> A
    A -- Webhook_msg --> E
    B -- log_output --> F
    A -- DB_access --> C

🔍解説：この図の構造

🔍6.2 REST API（取引指令の送信・状態確認）

await rest.place_order(...)
await rest.cancel_order(...)
position = await rest.get_positions()

• Botが**「取引したい」と思ったとき**にアクセスするのがREST API
• 主に以下の用途で使われます：
  • 指値／成行などの新規注文
  • 注文の取消（キャンセル）
  • ポジション情報・損益の取得
• 通信は同期的（送って→返ってくる）

💡これは何をしているの？

これは、Botが取引所の「サーバー側にある情報」へアクセスしに行く処理です。
Botが以下のような行動をするときに使います：

• 新しく注文を出す（place）
• 出した注文を取り消す（cancel）
• 現在のポジションや保有資産を確認する（get）

これらはすべて「Botから取引所にリクエストを送って、レスポンスを受け取る」という**“同期型”**のやりとりで実現されています。

📫補足：REST APIとは何か？

REST（レスト）APIとは、インターネット上で情報をやり取りする共通の方式のひとつで、
Botから「ちょっとこの情報ちょうだい」とか「この注文出して」といった指令を送るために使います。

📨 郵便みたいなものです：
必要なときに1通ずつ送り、返事をもらう。

これは、次項で説明するWebSocketのように「常時つながりっぱなし」ではありません。

🔄使われる場面と処理の種類

これらはすべて1回のリクエスト＝1回の応答という構造になっており、
**必要なときだけ使われる“ピンポイント通信”**です。

🧪実際のデータ（例）

以下は get_positions() のレスポンス例（簡略化）です：

{
  "result": {
    "list": [
      {
        "symbol": "BTCUSDT",
        "side": "Buy",
        "size": "0.01",
        "entryPrice": "49900",
        "unrealisedPnl": "-3.21"
      }
    ]
  }
}

Botはここから：

• 保有中のポジション（Buy/Sell）
• 含み損益（unrealised PnL）
• 平均取得価格（entryPrice）

などを抽出し、戦略判断に活かします。

⚠️補足：RESTの注意点と限界

✅対策：

• 無駄なアクセスを避ける（不要なループで get_positions() を連発しない）
• WebSocketと併用し、リアルタイムはWSに、状態確認はRESTに分担させる

🤖Bot運用におけるRESTの役割とは？

WebSocketが「目と耳（板情報）」なら、RESTは「手と体の操作系」です。

• 注文を出す：アクション（攻撃）
• 状態を確認する：防御（DD確認）
• キャンセルする：撤退

このように、Botの実行力・制御力そのものがREST APIにかかっています。

🧵まとめ：RESTはBotの「行動する手段」

• 状態の確認も、注文の発射も、キャンセルもREST
• 毎回1通1通やりとりする分、明確で制御しやすい
• ただし、頻度制限と遅延には十分注意が必要

この仕組みを理解しておくと、**「なぜBotが今動かないのか？」**を的確に診断できるようになります。

📡6.3 WebSocket API（板情報のリアルタイム監視）

await ws.subscribe("orderbook.1.BTCUSDT")

• WebSocketは「常時接続型の通信」。一度つながると最新の板情報がリアルタイムで届く
• これにより、Botは以下を常に監視できます：
  • 最良のBID/ASK価格
  • 板の厚さ、スプレッド、瞬間的な変動

✅ 高速かつ継続的に情報を得る手段として、HFTやMMに不可欠

💡これは何をしているのか？

これは、BybitのWebSocket（双方向通信のストリーム）を通じて、BTCUSDTの板情報（Orderbook）を常にリアルタイムで受信し続けるための処理です。

この情報をもとに、Botは次のような判断を行います：

• 今のスプレッドはどのくらいか？
• 取引板の厚みや変動性はどうか？
• 今エントリーすべきか、それとも見送るべきか？

🔄補足：HTTP（REST）とWebSocketの違いは？

Botのように相場の変化を瞬時に察知して反応するプログラムにとって、WebSocketは不可欠なセンサーです。

📦補足：orderbook.1 の意味とは？

Bybit WebSocket v5 では、orderbook.1.BTCUSDT のようなチャンネルを指定して購読します。

つまりこれは：

✅「BTCUSDTの板情報を1秒間隔で受け取るよ」という指定

🔄Botが受け取るデータの例（簡易化）

{
  "topic": "orderbook.1.BTCUSDT",
  "data": {
    "b": [["50000.0", "2.5"]],  // BID（買い板）: 価格・数量
    "a": [["50010.0", "1.2"]]   // ASK（売り板）: 価格・数量
  }
}

• b：最良買い注文（BID）のリスト
• a：最良売り注文（ASK）のリスト

Botはこのデータから：

bid = float(orderbook["b"][0][0])
ask = float(orderbook["a"][0][0])
spread = ask - bid

のように、スプレッド（売買の差額）を計算します。

⏱️補足：なぜスプレッド監視に向いているの？

• WebSocketは1秒ごとに板情報が更新されるので、Botはチャンスを逃さず監視できる
• これをRESTでやろうとすると大量のリクエストになり、非効率＆BANのリスク

WebSocketを使うことで、Botは**「今がエントリーすべき瞬間か？」**を常に見張れるのです。

🧵まとめ：WebSocketはBotの「目と耳」

• 市場の動きをリアルタイムで検知
• スプレッド判定や板厚チェックに活用
• コストも軽く、正確で、即応できる

BotにとってWebSocketは、まさに**“戦場で情報を読むセンサー”**です。

📨6.4 Slack通知（Botから人間へのアウトプット）

requests.post(SLACK_WEBHOOK_URL, json={"text": "📊 PnL +2.14"})

• Botが「今こうなったよ！」と人間に知らせるための唯一のチャネル
• 以下のような場面で通知が飛びます：
  • エントリー／キャンセル／Fill
  • DD警告（損失過多）
  • 正常終了 :checkered_flag:

SlackはスマホやPCから即時確認できるため、
実運用時に「Botの死活確認」を行うのに最も適しています。

📁6.5 Bind Mount（ホストとのファイル共有）

#yamlファイル
volumes:
  - ./:/app:rw

• コンテナとホスト（Mac）でフォルダを共有している
• 主に以下の目的で活用：
  • Macで編集したPythonコードをコンテナ内に反映（＝ホットスワップ）
  • コンテナが出力するログを logs/ に書き出し → Mac側から確認

🔁この構造により、Botを止めずにコードだけ修正／再起動で即反映という開発サイクルが成立しています。

💡これは何をしているのか？

この設定は、**Mac側（ホスト）にあるフォルダ（./）を、コンテナ内の /app にそのまま“つなぐ”**という指定です。
つまり、Macで保存したファイルを、Dockerの中でも即座に使えるようにする仕組みです。

📂「ホストとコンテナが、同じフォルダを共有して同時編集できる状態」を作ります。

🧪実際にどう使われているのか？

✅この構成のメリットとは？

🔁つまり、Botのロジック修正 → 再起動 → 実戦テストという開発ループが超高速になります。

📎Volumeとの違いは？

初心者が混乱しやすいのが、Bind MountとVolumeの違いです：

このBotでは、開発と実運用のハイブリッド用途として、Bind Mountがベストマッチしています。

⚠️注意点：使いこなすために押さえておくこと

🧵まとめ：Bind Mountは「Botと開発者をつなぐ直通ケーブル」

• Macで編集 → コンテナに即反映
• コンテナのログ → Macで即確認
• 繰り返し再起動でも環境はそのまま

この設計があるからこそ、ロジック変更 → テスト →検証 →修正 のサイクルを高速に回し続けることができます。

🧵まとめ：Botは外部との連携で「見える化」と「安全性」を確保する

このBotは完全自律型のロジックを持っていますが、
その力を安定運用・安全停止・即時把握という方向に拡張しているのが、この外部インターフェース群です。

🔚次回予告

次回は、Botの**「コンテナライフサイクル」全体像と、その中で行われる自動再起動／停止判断／ホットスワップ／再ビルドなどの挙動**を詳細に追っていきます。