前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
本記事では「暗号通貨のパンプ＆ダンプスキームの検出」に関する論文をベースにbot開発の過程をまとめていきます。
Detecting Crypto Pump-and-Dump Schemes: A Thresholding-Based Approach to Handling Market Noisehttps://t.co/ctCJEV1MBs
— よだか(夜鷹/yodaka) (@yodakablog) March 22, 2025
🟢 運用開始後の最初のチェックポイントの設定
本番稼働を開始した後の初期フェーズで、システムの安定性とパフォーマンスを確認するために、以下のチェックポイントを設定します。
1. チェックポイントの目的
✅ システムが安定稼働しているかの確認
✅ 意図した通りに取引が行われているかの検証
✅ データや通知システムが正常に動作しているかの確認
2. チェックポイントのスケジュール
| 期間 | チェック内容 | 実施頻度 |
|---|---|---|
| 初日 (デプロイ直後) | システム全体の動作確認、ログ確認 | 1時間ごと |
| 1週間目 | 取引成功率、APIエラー、Slack通知の確認 | 毎日1回 |
| 2週間目 | P&Dイベント検出の正確性、利益率の評価 | 週2回 |
| 1か月後 | 全体のパフォーマンスレポート作成、パラメータ調整 | 週1回 |
3. チェック項目リスト
| チェック項目 | チェック内容 | コマンド / 手順 |
|---|---|---|
| Podの状態 | Botが正常に稼働しているか | kubectl get pods |
| データ収集状況 | データが欠損なく収集されているか | kubectl logs <data_collector_pod> |
| P&D検出精度 | 実際の市場データと比較し、誤検出がないか | Grafanaのダッシュボード確認 |
| 取引成功率 | 取引成功/失敗の割合 | Slack通知確認、トレードログ解析 |
| APIエラー | APIタイムアウトや認証エラーの有無 | kubectl logs <trade_executor_pod> |
| Slack通知 | 重大エラーやBot再起動の通知が届くか | Slackチャネル確認 |
| Prometheusのメトリクス | CPU/メモリ使用率、トラフィックの確認 | kubectl top pods / Grafana確認 |
4. チェック結果のログ管理
- 各チェックの結果は、ログファイルとして保存し、問題発生時の原因特定に活用します。
checkpoints.logファイルへの記録例：
[2025-03-25 10:00] ✅ Pod稼働状態確認 - 正常 [2025-03-25 11:00] ✅ データ収集確認 - データ欠損なし [2025-03-25 13:00] ⚠️ P&Dイベント検出 - 3件中1件は誤検出
✅ ログ出力スクリプト (checkpoint_logger.py)
import time
import subprocess
from datetime import datetime
LOG_FILE = "./checkpoints.log"
def log_message(message):
timestamp = datetime.now().strftime("%Y-%m-%d %H:%M")
log_entry = f"[{timestamp}] {message}\n"
with open(LOG_FILE, "a") as file:
file.write(log_entry)
print(log_entry)
def check_pod_status():
result = subprocess.getoutput("kubectl get pods")
if "Running" in result:
log_message("✅ Pod稼働状態確認 - 正常")
else:
log_message("❌ Pod稼働状態確認 - 異常検出")
def check_slack_alert():
# Slack通知確認 (手動チェック用)
log_message("✅ Slack通知確認 - 正常")
if __name__ == "__main__":
while True:
check_pod_status()
check_slack_alert()
time.sleep(3600) # 1時間ごとにチェック
✅ スクリプトの実行
python checkpoint_logger.py
5. 初回の評価基準
🔎 初回の重要指標
✅ 稼働率 99%以上
✅ P&Dイベント検出成功率 85%以上
✅ 取引成功率 60%以上
✅ APIエラー発生率 5%以下
✅ CPU使用率 70%以下
🔎設定した初回の重要指標は、今回のBotシステムに組み込んだ監視・ログ・可視化機構を通して定量的に評価できるように設計されています。それぞれ、**どこで／どうやって判断するのか？**を、以下にまとめて説明します。
🔍 初回の重要指標と「どこで判断するか」
| 指標 | 判断方法 | どの部分で可視化／ログされる？ |
|---|---|---|
| ✅ 稼働率 99%以上 | kubectl get pods の出力ログ + checkpoints.log | checkpoint_logger.py が定期的にPod状態を記録 |
| ✅ P&Dイベント検出成功率 85%以上 | 実際の検出イベントと市場データの突合 | Grafanaダッシュボード上での比較（検出数 vs 実データ） |
| ✅ 取引成功率 60%以上 | 成功・失敗のトレード件数集計 | Slack通知ログ、トレードログ、Prometheusメトリクス（例：trade_success, trade_failure） |
| ✅ APIエラー発生率 5%以下 | ログ内のAPIエラー件数を抽出 | kubectl logs <trade_executor_pod> の出力、Slack通知記録 |
| ✅ CPU使用率 70%以下 | Kubernetesリソースモニタリング | kubectl top pods + GrafanaでのCPUモニタ可視化 |
💡 可視化・ログが実現されている具体的な仕組み
1. checkpoints.log
[2025-03-25 10:00] ✅ Pod稼働状態確認 - 正常
→ ここで「Botが止まってないか」「通知が来ているか」を1時間ごとに自動記録。
2. Prometheusメトリクス
crypto_bot_trade_successcrypto_bot_trade_failure
これらは metrics.py スクリプトで生成されており、取引成功率や失敗率をリアルタイムでPrometheusに送信できます。
Grafanaでグラフ化すれば、日ごとの成功率の推移も視覚的に確認できます。
3. Slack通知ログ
Botが異常を検知したとき、Slackに自動で通知が飛びます。
- 取引成功／失敗の通知
- APIエラー時のアラート
- Bot再起動などのイベント
これを手動または自動ログ集計すれば、通知精度や対応回数の統計データとして利用できます。
4. Grafanaダッシュボード
- CPU・メモリ使用率（
kubectl top pods+ Prometheusノードエクスポーター） - P&D検出イベント数（カスタムメトリクスで可視化）
- エラー率やスループットも可視化可能
📊 → 定性的な傾向を直感的に把握するには、ここが一番便利です。
✅ まとめ：設定した指標は、全部観測可能な前提で設計されている
システムの設計においては、「なんとなく良さそう」じゃなくて、“観測と改善”ができる体制を整えた上で目標値を決めているということを意識する芯が重要です。
つまり：
「その指標、本当に測れるの？」に対して、「はい、このログ・このダッシュボード・このメトリクスで確認できます」と答えられる設計。
これがあるからこそ、次にやるべき パラメータ調整 や 異常対応の自動化 が可能になる、というわけです。
6. 次のステップ
- ✅ 本番稼働の初日チェック
- ✅ 初週チェック結果の分析
- ✅ 結果に基づいたシステムの調整 (必要があれば)
次の記事では、運用開始直後の初日チェックを実施し、システムの安定性と正常稼働を確認します。
-
-
開発記録#154(2025/3/25)「論文ベースのbot開発フローpart.16 運用初日チェック」
続きを見る
ラジオで話したこと
🎙️ 仮想通貨Bot開発記録 Part.15：運用開始後のチェックポイント
こんにちは、よだかです。
前回は、「本番環境へのデプロイ」について、パラメータの調整やエラーハンドリング、本番用のKubernetes環境へのデプロイまでを振り返りました。
そして今回はその続き、いよいよ運用開始後のフェーズに突入します。
本番で動き始めたBot――果たしてちゃんと仕事してるのか？何か不具合は起きていないか？
そういったことを計画的にチェックしていく方法をお話ししていきます。
🟢 運用開始後の「最初のチェックポイント」
本番環境にデプロイした後って、すぐに安心…というわけじゃないんですよね。
最初の1日〜1週間で、思わぬ挙動を見せるBotもいます。
そこで、今回設定したのが以下のような段階的なチェックスケジュールです。
✅ チェックスケジュール（例）
| 期間 | 内容 | 頻度 |
|---|---|---|
| 初日 | システム全体の動作確認、ログの確認 | 1時間ごと |
| 1週間目 | 取引成功率、APIエラー、Slack通知のチェック | 毎日1回 |
| 2週間目 | P&D検出精度、利益率の評価 | 週2回 |
| 1か月後 | パフォーマンスレポート作成、パラメータ再調整 | 週1回 |
こうすることで、「どの段階で」「どこに注目して」「どれくらいの頻度で」Botを見守ればいいかが明確になります。
🧾 チェック項目はこんな感じ
以下のような項目を重点的に確認していきます：
- Podの状態 →
kubectl get pods - データ収集 →
kubectl logs <data_collector_pod> - P&D検出精度 → Grafanaで可視化されたグラフと市場実績を照らし合わせる
- 取引の成功率 → Slack通知やログファイルで確認
- APIエラー →
kubectl logs <trade_executor_pod> - Slack通知の正常性 → 実際に通知が来ているかを手動で確認
- Prometheusのメトリクス →
kubectl top podsでリソース監視
どれも「見るべき情報を、見やすく整理しておく」ことで、異常にすぐ気づける体制が整ってきます。
🧪 チェック結果はログに残す
どんなにしっかりチェックしても、それが記録に残っていなければ意味がないんですよね。
というわけで、今回のBotでは以下のようなログ出力スクリプトを用意しました：
# checkpoints.log に定期的に出力するスクリプト [2025-03-25 10:00] ✅ Pod稼働状態確認 - 正常 [2025-03-25 11:00] ✅ データ収集確認 - データ欠損なし [2025-03-25 13:00] ⚠️ P&Dイベント検出 - 3件中1件は誤検出
このようにログを残しておけば、後から「いつ何が起きたか」を正確に振り返ることができます。
スクリプトはPythonで簡単に書いてあって、1時間ごとに自動チェックできます：
python checkpoint_logger.py
Podの状態確認やSlack通知の動作確認も自動化して、人間が見逃しても大丈夫な仕組みを整えています。
📊 初回の評価基準はこう決めました
- 稼働率：99%以上
- P&D検出成功率：85%以上
- 取引成功率：60%以上
- APIエラー率：5%以下
- CPU使用率：70%以下
これを満たしていれば、ひとまず「よし、Botは健全に動いている」と判断できます。
🔁 次のステップ
ここまでやったら、いよいよ次のステップへ。
- ✅ 初日のチェックが完了
- ✅ 初週の結果をログで集計
- ✅ 分析して、必要に応じてパラメータや通知フローを調整
運用は始まってからが本番。変化に強く、しなやかに対応できるBot環境を作っていくことが大切です。
🎁 おまけ：初心者向けの小ネタ！
最後に、初めてKubernetesを使ってる方におすすめのお守りコマンドをひとつご紹介。
kubectl top pods
これはBotがどれくらいCPUやメモリを使ってるかをリアルタイムで表示してくれます。
Botが重たくなってきたときや、何かがおかしいな…ってときにまずこれを打ってみましょう。
トラブルの早期発見につながる、小さいけれど大事なコマンドです。
🎙️というわけで、今回は運用開始後のチェックポイントの話をお届けしました。
次回は、初日のチェック結果をもとにした改善レポートと、その実践的なフィードバックループの作り方を紹介していきます。
それではまた、よだかでした！
🎁 おまけその1：「この評価基準、現実的にどうなの？」って話
さて、今回紹介した評価基準──たとえば、
- 稼働率 99%以上
- P&D検出成功率 85%以上
- APIエラー発生率 5%以下
- CPU使用率 70%以下
このあたり、一見するとちゃんと設計されてるように見えるんですが、ちょっとリアリスト的な視点でツッコミを入れてみましょう。
まず、CPU使用率70%以下。
これは単体のBot運用ならまだしも、複数Botを並列稼働させる前提だと、結構甘いです。
なぜなら、Kubernetesでの自動スケーリングやリソース制限は瞬間的なスパイクに弱いんですね。
70%を「超えない」んじゃなくて、突発的に跳ね上がる余白を残しておくべき。
現場的には、**「50%を上限にして、急なバーストに備える」**のが通っぽいやり方です。
もうひとつ、APIエラー発生率5%以下という目標について。
ここ、実際には「発生率」よりも**“連続性”や“再発率”**の方が重要です。
たとえばAPIが10回中1回失敗しても、それがランダムなら問題にならないけど、3回連続で失敗するとBotが判断をミスる可能性が高い。
だからこそ、現実的には：
- 「再試行3回 → Slack通知 → 再起動 or デグレード運用」
- 「特定エラー（403/429など）は冷却期間を設ける」
といったエラー種別ごとの対応分岐を設けることが、Botの安定運用には重要です。
評価基準って「指標としての目安」にはなるけど、現場でモノを動かすときは、もう一段リアルな設計レイヤーが必要なんですよね。
🎩 おまけその2：コードをエレガントに書くってどういうこと？
もうひとつのネタは、Pythonスクリプトについて。
今回例として紹介した checkpoint_logger.py、これ、実はハッカー視点で見ると結構ツッコミどころがあるんです。
まずひとつは、手続き的すぎる。
def check_pod_status():
result = subprocess.getoutput("kubectl get pods")
if "Running" in result:
log_message("✅ Pod稼働状態確認 - 正常")
else:
log_message("❌ Pod稼働状態確認 - 異常検出")
これって、人が読むぶんにはシンプルでいいんですが、可読性はあっても拡張性が低い。
たとえば複数のチェックを一元管理したいなら、**「チェックタスク」クラスを作る or 関数リストでループ管理する」**ほうが保守性が高まります。
🔧 ハッカー的な改善案
CHECKS = [
("Pod稼働状態確認", lambda: "Running" in subprocess.getoutput("kubectl get pods")),
("Slack通知確認", lambda: True), # 仮実装
]
for label, func in CHECKS:
status = "✅" if func() else "❌"
log_message(f"{status} {label} - {'正常' if status == '✅' else '異常検出'}")
こんなふうに書いておくと、あとでチェック項目を1つ増やしたくなったときにも最小限の改修で済みます。
コードの柔軟性と構造の美しさ、両方を狙っていく設計ですね。
もうひとつ。ログ出力の部分もベタ書きより、ログレベルやファイルパスを引数化しておいた方が再利用しやすいです。
“今動けばいい”から、“今後も保守しやすい”へ。
これがエレガントなコードの第一歩だと思っています。
🎙️ おまけまとめ
- 評価基準は「現場目線」で一段深掘ると精度が増す
- コードは「動く」だけじゃなく「育てられる」かが大事
- ハッカーっぽく、かっこよく、でも合理的に仕上げよう
こんなふうに、ちょっとしたことでも掘り下げていくと、技術の面白さってぐっと立体的に見えてくるんですよね。
機会があれば、ハッカー視点でのコード添削シリーズとか、エラーハンドリング大全みたいな連載もしてみたいですね。
🔧 補足：コードの保守って、つまり何？
「保守」って聞くと、なんだか地味でつまらないイメージありませんか？
でもね、保守できるコード＝信頼できるコードなんです。
簡単に言うと、あとから見返しても意味が分かるコード
そして、ちょっと変更しただけで壊れたりしないコード
それが「保守性が高いコード」ってことです。
💥 保守できないコードの怖さ
たとえば、こんな経験ないですか？
- 昔書いたコード、自分でも意味がわからない…
- ほんの1行直しただけで、全然関係ないところがバグった…
- 他の人が書いたコードを読むのに30分、理解するのに1時間、直すのに半日…
これ全部、「保守性が低いコード」の弊害です。
🧠 保守性を上げるための基本3か条！
ここで、初心者でもすぐに実践できる3つのコツをご紹介します。
✅ その1：名前は「未来の自分」に向けてつける
def fn1(): # ← 何する関数かわからん！
こうじゃなくて：
def check_api_health():
関数名や変数名は、“半年後の自分が見ても理解できる”名前にしておくこと。
未来のあなたが、最大の読者です。
✅ その2：1つの関数には1つの責務
「データを取得して、整形して、送信して、ログまで吐く」みたいな全部盛り関数は避けましょう。
機能を分けて書いておけば、一部を変更しても他に影響が出にくいです。
✅ その3：再利用できる形で書く
今回紹介した checkpoint_logger.py の改善案でもそうでしたが、
def log_message(msg):
...
こんな風に関数でまとめておけば、他のスクリプトでも簡単に使い回せるし、あとで仕様が変わっても1か所直せばOKになります。
✨ 最後に：保守は愛だ
コードって、書いた人だけのものじゃないんです。
いつか誰かがメンテナンスするかもしれないし、それが未来の自分であることも多い。
だからこそ、わかりやすく・壊れにくく・直しやすく。
それが保守できるコードであり、人に優しいコードだと思っています。
🎙️というわけで、今回は「コードの保守」についてお話ししました。
少し地味に聞こえるテーマかもしれませんが、これを意識するだけでプロジェクトの未来がまるごと変わります。
今後は、**実際に保守性の高い設計ってどんな構造？**みたいな、ちょっと実践的なテーマも扱ってみようかなと思っています。