botの監視方法と放置の危険性｜24時間自律セッション運用の実際

botの監視とは、自動売買プログラムが「動いているか」「意図どおりに動いているか」「損益が想定内か」を継続的に確認し、異常時に検知・停止できる状態を保つ運用のことである。結論から言えば、自動売買における最大のリスクは相場ではなく「監視されていないbot」だ。放置されたbotは、発注の失敗も、損益の悪化も、設定の陳腐化も、誰にも気づかれないまま静かに進行させる。

当サイト編集部は2026年4月から、AIコーディングエージェントのClaude Codeにトレード判断と執行を任せる検証運用を実口座で継続している。稼働形態は「毎朝6時に起動し、翌朝に自己終了する日次セッション」を毎日回す方式で、これにより実質24時間の相場監視を成立させている。本記事では、この実運用の監視構成を具体的に公開し、「自動売買の放置はなぜ危険か」「何をどう監視すべきか」を、実際に踏んだ失敗事例とともに解説する。

なぜ「完全放置」は危険なのか

「自動売買=ほったらかしで稼げる」というイメージは、運用の現実と噛み合っていない。放置が危険な理由は、botの故障や劣化が「音を立てない」からだ。

一般論として、自動売買の運用では取引所側のAPI障害やメンテナンス、サーバーやネットワークの停止によってbotが動けなくなる事態が起こりうると指摘されている。しかし実運用の経験から言えば、本当に怖いのは「完全に止まる」障害ではない。止まってくれれば異常は明白で、人間は対応できる。怖いのは「動いているように見えて、一部が壊れている」状態——編集部はこれを「静かな失敗」と呼んでいる。

編集部の実例を挙げる。運用中、特定銘柄（WBTC）でだけ発注が正常に通らないバグが発生した。他の銘柄では問題なく取引が続いていたため、システム全体としては「正常に稼働している」ように見えた。しかし実際には、WBTCのエントリー条件が成立しても建玉が立たず、取引機会を失い続けていた。botはエラーで止まらず、ログ上も破綻せず、ただ静かに機会損失を積んでいた。もしこれが「発注できない」ではなく「決済できない」側のバグだったらと考えると、監視の重要性は明らかだろう。損切りを設定していても、その注文が通らなければ絵に描いた餅である。

一般的な運用でも、放置が事故につながる経路は複数知られている。取引所・プロトコル側のAPI仕様変更やメンテナンスにbotが追従できず、注文が通らなくなる。サーバーの再起動やネットワーク断でプロセスが落ち、ポジションを持ったまま無防備になる。相場の急変にパラメータが合わなくなり、有効だった戦略が損失を出し続ける。いずれも「起きるかもしれない」ではなく「長く運用すれば必ずどれかは起きる」と考えて設計するのが実務的だ。編集部の運用でも、後述するとおり発注系の不具合は実際に起きた。

放置の危険はもう1つある。損益の把握が「体感」になることだ。勝ちトレードは記憶に残り、手数料や小さな損失は忘れられる。編集部が2026年7月上旬に運用開始からの全取引をオンチェーン記録と突き合わせる監査を行ったところ、実現損益は約-21ドルと確定した。監査の過程では、初期の建玉サイズが小さすぎて利確してもガス代・手数料で利益が消える「ガス代負け」の構造も定量的に可視化された。記録と突き合わせなければ、この構造欠陥の発見はさらに遅れていたはずだ。

実運用の監視構成を全公開：日次セッションリサイクル方式

編集部の検証運用の構成を具体的に示す。2026年7月時点の実構成だ。

• 運用主体: Claude Code（AIコーディングエージェント）。相場分析・エントリー判断・決済管理・異常検知までを1つのエージェントセッションが担う
• 取引の場: オンチェーンDEX（GMX）のパーペチュアル。全取引がブロックチェーンに記録され、後から第三者検証できる
• 稼働サイクル: 毎朝6時にセッションが起動し、翌朝に自己終了する。終了時に当日の状況を申し送り（ハンドオフ）として書き出し、翌朝の新セッションがそれを読んで引き継ぐ
• 設定値: レバレッジ10倍、利確+3.5%、損切り-4.5%、トレーリングストップ併用、建玉下限400ドル
• 資金と成績: 当初188ドル＋追加400ドルの投入に対し、実現損益は約-21ドル（2026年7月上旬のオンチェーン監査で確定）

なぜ「起動しっぱなし」ではなく毎日作り直すのか

この構成の核心は、セッションを毎日意図的に使い捨てる「日次リサイクル」にある。プログラムやエージェントを長時間動かし続けると、メモリの肥大化、内部状態と実際の口座状態のずれ、文脈の混濁といった劣化が静かに蓄積する。これも一種の「静かな失敗」であり、発症してから気づくのは難しい。毎朝まっさらなセッションを起動し、前日の申し送りだけを引き継ぐことで、劣化の蓄積を24時間ごとに強制リセットしている。

サーバー運用の世界で「たまに再起動すると調子が戻る」という経験則があるが、日次リサイクルはそれを「調子が悪くなる前に、決まった時刻に、必ずやる」仕組みに変えたものだ。再起動のタイミングを相場の比較的落ち着いた早朝に固定していることもポイントで、ポジション管理の引き継ぎリスクを最小化している。

AIエージェントに監視させるという選択

従来型のbot監視は「価格条件のチェック」しかできない。編集部の構成では、監視の主体がAIエージェントであるため、数値条件に加えて「状況の解釈」を伴う監視ができる。たとえば急変動時に、単に損切りラインへの接近を検知するだけでなく、相場のモード（レンジかトレンドか）を判定し直し、新規エントリーの見送りやトレーリング幅の運用を状況に応じて調整する。編集部の戦略自体が「レンジ相場ではレンジ端の逆張り、トレンド相場では押し目の順張り」というモード判定式であり、監視と戦略判断が同じエージェントの中で連続している。これは従来の「監視ツール＋売買ロジック」を別々に組む構成との大きな違いだ。

ただし、AIエージェントによる監視は万能ではない。判断の質はエージェントに与える情報と権限の設計に依存するし、エージェント自身が異常な状態に陥る可能性もゼロではない。だからこそ編集部は、エージェントの上位に「日次リサイクルという強制リセット」と「オンチェーン記録という改ざんできない外部の帳簿」を置いている。エージェントを信頼しつつ、エージェントの外側に検証の仕組みを持つ——この二重構造が、AI主導運用の監視設計の要点だと考えている。

なお、Claude Codeのようなエージェント環境には、指定時刻や間隔でタスクを自動実行するスケジュール機能が用意されており（2026年7月時点）、毎朝の起動はOS側のタスクスケジューラと組み合わせて無人化している。「人間が毎朝起動ボタンを押す」運用は、人間が単一障害点になるため避けるべきだ。

申し送り（ハンドオフ）の設計：毎日作り直しても文脈を失わない

日次リサイクルの成否を分けるのが、セッション間の申し送り設計だ。毎日まっさらに戻す方式は、劣化をリセットできる反面、引き継ぎが雑だと「昨日までの文脈」も一緒に消えてしまう。編集部の運用では、終了するセッションが次の情報を書き出し、翌朝の新セッションが起動直後に読み込む。

• 現在保有しているポジションの一覧と、それぞれのエントリー根拠
• 当日の相場観（レンジかトレンドか、注目している価格帯）
• 発生した異常・違和感と、その対応状況
• 翌セッションへの注意事項（例: 特定銘柄の発注を見送る、など）

ここで重要なのは、「状態のすべて」ではなく「判断に必要な要約」だけを引き継ぐことだ。全部を引き継ぐと、劣化した内部状態まで一緒に持ち越してしまい、リサイクルの意味がなくなる。逆に、ポジションの存在だけ引き継いで「なぜ建てたか」を落とすと、新セッションが根拠のわからないポジションを抱えて判断に迷う。「翌朝の自分が読んで、5分で状況を再構築できるメモ」——これが申し送りの品質基準として実用的だ。

この設計は、人間のトレーダーが日誌をつける行為の自動化版でもある。引き継ぎ書式を最初に固めておけば、セッションが変わっても運用の一貫性は保たれる。

監視すべきは4層：何を見れば「異常」に気づけるか

実運用の経験から、botの監視は次の4層に分けて設計するのが実用的だ。

監視の頻度も層ごとに変えるのが合理的だ。死活監視と執行整合監視は取引のたび・数分単位のリアルタイム性が要る。一方、損益・残高の突き合わせは日次〜週次、記録ベースの本格的な監査は月次で十分に機能する。編集部の場合、リアルタイム層はセッション内のエージェントとwatchdogが担い、日次の区切りは申し送り作成時に、月次相当の監査は2026年7月上旬のオンチェーン突き合わせのような形で実施した。すべてをリアルタイムにする必要はなく、「異常の進行速度」と「監視の頻度」が釣り合っていればよい。

重要なのは、4層のどれか1つでも欠けると「静かな失敗」の温床になることだ。死活監視だけあっても、発注整合が壊れていれば機会損失は見えない。執行が正常でも、損益監視がなければガス代負けのような構造欠陥に気づけない。すべて正常でも、相場環境の急変に対応できなければ設定値が陳腐化する。監視は「動いているかの確認」ではなく「4層それぞれの前提が今日も成り立っているかの確認」と捉えてほしい。

失敗事例が証明した監視の価値

編集部の実運用で、監視の有無が結果を分けた事例を3つ共有する。

1. 発注バグの検知（執行整合監視の勝利）——前述のWBTC発注バグは、発注処理を監視する仕組み（watchdog）の差し替えによって解消した。「発注した」というプログラム内部の認識と、「約定した」というオンチェーン上の事実を突き合わせ、不整合を検知するアプローチだ。この経験から、執行整合監視は発注ロジック本体と同格の必須コンポーネントだと位置づけている
2. ガス代負けの発見（損益監視の勝利）——初期の建玉サイズでは、利確ライン+3.5%に到達しても利益がガス代・手数料の合計を下回っていた。この構造は日々の体感では見えず、オンチェーン記録と損益を突き合わせる監査で定量化された。対策として建玉下限400ドルを導入し、コスト割れの取引を構造的に排除した
3. 損切り設計の欠陥発見（記録レビューの勝利）——運用初期の「早期損切り」が相場ノイズで頻繁に刈られ、小さな損失を量産していたことも、取引記録のレビューから発覚した。2026年7月に早期損切りを廃止し、損切り-4.5%への一本化とトレーリングストップ併用へ決済ロジックを全面リライトした

3つの事例を時系列で振り返ると、監視体制の成熟にも段階があったことがわかる。運用開始直後は「動いているか」しか見えていなかった。ガス代負けの発見で「損益を記録で確定させる」レビューが加わり、発注バグの経験で「発注と約定の突き合わせ」が加わり、損切り設計の見直しで「記録から設定の妥当性を検証する」サイクルが確立した。つまり監視体制は最初から完成形で作れるものではなく、失敗のたびに1層ずつ厚くなっていくものだ。これから始める人は、編集部が失敗して学んだ層を最初から組み込めるぶん、有利なスタートを切れる。

3つに共通するのは、「監視と記録がなければ、いずれも発見がもっと遅れていた」ことだ。逆に言えば、監視体制とは失敗をゼロにする仕組みではなく、失敗を早く・安く発見して改善に回す仕組みである。検証運用の最新状況は当サイトの運用実績ページ（/ai-trading）で公開している。

監視ツールの組み合わせ方：無料でも4層はカバーできる

編集部の構成はAIエージェント前提だが、4層監視の考え方は一般的なツールの組み合わせでも実現できる。2026年7月時点で入手しやすい選択肢を層別に挙げる。

• 死活監視: 外形監視サービス（一定間隔でサーバーやエンドポイントの応答を確認し、無応答ならメール等で通知するもの）は無料枠のあるサービスが複数ある。プロセスレベルでは、OSのサービス機能やプロセス管理ツールの自動再起動を併用する
• 執行整合監視: これは既製ツールでは代替しにくく、bot本体に「発注後にポジション・残高を照会して一致を確認する」処理を実装するのが基本になる。実装コストはかかるが、編集部の経験上、最も投資対効果の高い監視だ
• 損益・残高監視: 取引所のアプリ通知や残高アラート機能、オンチェーン運用ならウォレット監視ツールが使える。加えて全取引のログをスプレッドシート等へ自動追記しておくと、週次レビューが数分で済む
• 相場環境監視: 価格アラートやボラティリティ通知を使い、「設定価格帯を抜けたら人間にも通知する」二重化をしておくと、botの判断がおかしい時に気づける

道具選びで迷ったら、「botが死んだことに気づける」「発注のずれに気づける」の2つを最優先で整備するとよい。この2つが欠けた状態が、最も高くつくからだ。逆に、最初から高機能な監視基盤を作り込む必要はない。運用しながら「気づけなかった異常」が出るたびに監視を1つ足していく育て方が、結果的に自分の運用に合った監視体制になる。

対◯◯で見る：日次セッション方式はどこが違うか

bot運用の稼働形態にはいくつかの型がある。編集部の日次リサイクル方式を、代表的な代替案と比較する。

対 常時起動デーモン型：安定感の正体は「劣化の見えにくさ」

VPS上でbotを常駐プロセスとして動かし続ける型は、最も一般的だ。プロセス管理ツールでクラッシュ時の自動再起動を仕込めば、死活監視としては十分に見える。ただしこの型の弱点は、「クラッシュしない程度の劣化」が蓄積し続けることだ。メモリリーク、内部状態と口座状態のずれ、ログの肥大化——どれも即死はしないが、判断の質を静かに蝕む。日次リサイクル方式は、再起動を異常時の回復手段ではなく正常運用の一部に組み込むことで、この蓄積を毎日ゼロに戻す。常時起動型を選ぶ場合でも、定期再起動と状態の再同期をスケジュールに入れることを勧める。

対 完全放置のクラウドbot：監視を「他人任せ」にする対価

取引所内蔵のグリッドbotや外部のクラウドbotサービスは、稼働の面倒をサービス側が見てくれるため、死活監視は実質不要になる。手軽さは圧倒的だ。ただし、執行整合や損益の監視まで任せきりにできるわけではない。特にグリッド型は、設定レンジを価格が抜けると含み損を抱えたまま実質停止するが、画面上は「確定利益」が積み上がって見えるため、実質損益の悪化に気づきにくい。サービスを使うにしても、「週に一度、実質損益（確定＋含み）を自分で確認する」という最低限の損益監視は自前で持つべきだ。監視の外注はできても、責任の外注はできない。

対 手動チャート張り付き：人間は24時間監視に向いていない

「自動売買は怖いから手動で見る」という選択は、一見安全に思える。しかし仮想通貨市場は24時間365日動いており、人間の連続監視は生理的に不可能だ。睡眠中の急変に対応できず、疲労は判断の質を下げ、感情は損切りを遅らせる。編集部がAIエージェント＋日次セッションの構成を選んだのは、「24時間の監視は機械に、監視設計と改善は人間に」という分業が、それぞれの得意分野に合っているからだ。人間の役割は画面を見続けることではなく、監視の仕組みを設計し、記録をレビューし、ルールを改訂することにある。

自分の監視体制を作る手順

編集部と同じ思想の監視体制を、一般的な環境で組む手順を示す。

1. 手順1: 稼働サイクルを決める——常時起動なら定期再起動の時刻を、セッション型なら起動・終了と申し送りの形式を決める。OSのタスクスケジューラやcronで無人化し、人間を単一障害点にしない
2. 手順2: 死活監視と通知を仕込む——プロセスの生存確認と、停止時にメールやチャットへ通知が飛ぶ仕組みを入れる。外形監視サービスを使えば、サーバーごと落ちた場合も検知できる
3. 手順3: 発注と約定の突き合わせを実装する——発注後に必ずポジション・残高を照会し、意図した状態と一致するか検証する。不一致時は取引を停止して通知する設計が安全側だ
4. 手順4: 損益と残高の記録を自動化する——全取引をログに残し、残高が想定レンジを外れたら通知する。取引履歴は確定申告にも必要になるため、消えない場所に保存する
5. 手順5: 週次・月次のレビューを予定に入れる——記録ベースで実質損益・取引内訳・異常の有無を確認する。編集部のオンチェーン監査のように、「体感」ではなく「記録」で成績を確定させる
6. 手順6: 緊急停止手段を用意して試す——botを即時停止し、ポジションを手動決済できる手順を事前に確認しておく。緊急時に初めて試すのでは遅い

手順を実行する順番についても補足したい。理想は6項目すべてを稼働前に整えることだが、現実には手順3（執行整合）の実装が重く、ここで挫折して「とりあえず動かす」に流れがちだ。その場合の妥協ラインは、「最小の建玉サイズで動かしながら、毎日必ず手動でポジションと発注履歴を突き合わせる」ことだ。人力watchdogは持続しないが、数週間なら回せる。その間に自動化を進め、突き合わせが自動になった段階でサイズを上げる。逆に決して飛ばしてはいけないのが手順6の緊急停止だ。編集部の経験では、異常はいつも想定していない形で来る。「何が起きているかわからないが、とにかく安全に止められる」という最終手段の有無が、パニック時の判断の質を決める。

構築後の確認用チェックリストも置いておく。

• botが停止したとき、24時間以内に自分が確実に気づける通知経路があるか
• 発注と約定の不一致を検知する仕組み（watchdog相当）があるか
• 残高・損益が想定レンジを外れたときの通知と対応手順があるか
• 定期再起動またはセッションリサイクルが予定に組み込まれているか
• 取引記録が自動保存され、週次・月次でレビューする予定があるか
• 緊急停止と手動決済の手順を実際に試したことがあるか

対 通知だけ受け取るシグナル型運用：最後の実行が人間ならボトルネックも人間

チャート分析ツールのアラートを受けて人間が発注する「半自動」の型もある。実行の最終判断を人間が握れる安心感はあるが、監視の観点では2つの弱点を抱える。第一に、通知を受けてから発注するまでの遅延と、深夜・就業中の対応不能。第二に、「通知が来なかったこと」の異常に気づけない点だ。アラート設定のミスやツール側の障害で通知が沈黙しても、人間には「静かな日」と区別がつかない。完全自動の日次セッション方式では、セッション自体が定時に起動して生存を示すため、「何も起きていない」と「監視が死んでいる」を区別できる。半自動を選ぶ場合は、定時の生存確認通知（今日も監視は生きている、という便り）を仕込むことで、この弱点をある程度補える。

監視運用のリスクと注意点

監視体制を組むうえでの注意点を整理する。

1. 監視すれども保証されず: 監視は損失を防ぐ仕組みではなく、異常を早く見つける仕組みだ。編集部の実運用も監視体制の下で実現損益約-21ドルであり、監視があっても負けるときは負ける
2. 通知疲れのリスク: 通知を増やしすぎると人間が慣れて無視するようになり、本当の異常を見逃す。通知は「行動が必要なもの」に絞る設計が重要だ
3. 監視システム自体の障害: 監視ツールやサーバーも落ちる。「監視の監視」として、定時の生存報告（ハートビート）が途絶えたら異常とみなす二重化を検討したい
4. 自動復旧の暴走リスク: クラッシュ時の自動再起動は便利だが、壊れた状態のまま再起動を繰り返すと、異常な発注を量産しかねない。再起動回数に上限を設け、超えたら停止して人間を呼ぶ設計にする
5. 放置期間の長期化リスク: 数週間単位でレビューを怠ると、相場環境の変化に設定が置き去りになる。ガス代・手数料・ボラティリティの前提は定期的に見直す
6. セキュリティリスク: 監視のために口座情報へアクセスする以上、APIキーや秘密鍵の管理が甘いと監視系が攻撃面になる。権限は読み取り・取引に限定し、出金権限は付与しない
7. 監視コストの軽視リスク: 監視体制の構築・維持には時間がかかる。運用資金が小さいうちは「監視に使う時間の価値が損失リスクを上回る」逆転も起きうるが、だからといって監視を省くと、資金を増やした後も省いたままになりがちだ。小さいうちに型を作るのが結局は近道である
8. 税務・記録のリスク: 仮想通貨の利益は原則として雑所得に区分され、一定額を超えると確定申告が必要になる。取引記録の保存は監視のためだけでなく申告のためにも必須で、詳細は税理士など専門家に相談してほしい

まとめ：放置と自動化は別物である

自動売買botの監視は、「死活」「執行整合」「損益・残高」「相場環境」の4層で設計し、定期リセット（日次セッションリサイクル）と記録ベースのレビューで支えるのが実運用の結論だ。編集部の検証運用では、発注バグはwatchdogの突き合わせで、ガス代負けはオンチェーン監査で、損切り設計の欠陥は記録レビューで発見された。どれも「監視と記録がなければ発見が遅れ、損失が膨らんでいた」失敗である。

監視体制の要点を一枚にまとめるなら、こうなる。定時に生まれ変わるセッションが劣化を防ぎ、watchdogが執行のずれを捕まえ、オンチェーンの帳簿が損益のごまかしを許さず、週次のレビューが設定の陳腐化を検出する。そして緊急停止の手順が、想定外のときの最後の安全弁になる。派手な要素は1つもないが、この地味な多層防御が、24時間動き続ける自動売買を「安心して任せられる仕組み」に変える。

自動化とは人間の作業をなくすことではなく、人間の役割を「実行」から「設計と監視」へ移すことだ。24時間の監視実行は機械とAIに任せ、人間は仕組みの設計・記録のレビュー・ルールの改訂に集中する。この分業が成立して初めて、自動売買は放置ではなく運用になる。編集部の実現損益約-21ドルという数字は誇れるものではないが、監視と記録の体制があったからこそ、この損失は「原因が特定され、対策に変換された授業料」として機能した。監視されないbotの損失は、原因不明のまま繰り返される、ただの損失で終わる。同じ金額を失うにしても、そこから学べる体制かどうかで、検証運用の価値は大きく変わる。なお、口座開設やAPI設定といった環境構築の具体的な手順は、当サイトの手順記事で別途詳しく解説している。

<!-- INTERNAL_LINKS_RELATED -->

関連記事

• Bybit撤退の資産移動手順を見る
• Bybitの代替取引所を見る
• 海外取引所の確定申告手順を見る
• botの確定申告のやり方を見る
• 海外取引所への送金手順を見る

<!-- INTERNAL_LINKS_RELATED -->