VPSでAIトレードBotを24時間動かす実践ガイド：止まらない・暴走しない・あとから検証できる運用設計

自動トレードBotで本当に怖いのは、「儲からないこと」だけではありません。

もっと危険なのは、夜中にBotが止まっているのに気づかないこと、APIエラーを注文チャンスと誤認すること、同じ注文を何度も出すこと、APIキーを漏らすこと、そして失敗ログが残らず原因を追えないことです。

この記事では、完全無人AIトレードBotをVPSで動かすための環境構築手順を、初心者でも実装順に進められる形で整理します。

扱う範囲は、売買ロジックではなく運用基盤です。

• VPS選び
• SSH接続
• Python環境構築
• APIキー管理
• screen と systemd の使い分け
• ログ・通知・停止条件
• KPIでの月次改善
• よくある失敗と対策

本記事は投資助言ではありません。特定銘柄、売買タイミング、利益保証を示すものではなく、自動トレードBotを安全に検証・運用するための技術情報です。

この記事の結論

完全無人AIトレードBotをVPSで動かすなら、最初に作るべきものは「儲かるAI」ではありません。

先に作るべきものは、次の4つです。

1. 止まったら分かる仕組み
2. 危険な状態では注文しない仕組み
3. 再起動後に自動復旧する仕組み
4. あとから検証できるログとKPI

Botは人間のように「なんとなく危ない」と判断して止まりません。コードに書かれた条件だけで動きます。だからこそ、VPS環境構築では、売買ロジックより先に運用設計を固めます。

Hiro環境の実行ログから見えた一次情報

この記事は一般論だけで構成していません。Hiro運営の auto-ai-blog リポジトリで、実際の自動化ログを確認しました。

確認したログの例です。

source=G:\マイドライブ\AI_Agents\github\repos\auto-ai-blog\generator\logs\generate.log

2026-07-13 04:57:39 [INFO] Selected topic 44/50:
完全無人AIトレードBotのためのVPS環境構築と運用上の注意

2026-07-13 05:00:19 [INFO] draft: codex CLI succeeded
2026-07-13 05:00:19 [WARNING] review: gemini CLI failed: The command line is too long.
2026-07-13 05:00:19 [INFO] review: calling codex CLI

同じ日の別ログでは、次のような運用イベントも確認できました。

2026-07-13 04:36:05 [INFO] Saved post: ...
2026-07-13 04:36:06 [INFO] Saved to Notion successfully.

2026-07-13 04:52:32 [ERROR] git commit failed:
fatal: cannot lock ref 'HEAD':
Unable to create '.git/HEAD.lock': File exists.

これはブログ自動化のログですが、AIトレードBotにもそのまま当てはまります。

無人運用は「一度設定したら放置」ではありません。実際には、成功、失敗、代替処理、保存、ロック、再実行が細かく発生します。

重要なのは、失敗しないことではなく、失敗が時刻付きで残り、どこで止まったか分かり、次の復旧アクションを判断できることです。

Hiro環境の予算台帳 generator\.budget_ledger.json では、2026年7月10日時点で次の値も確認できました。

{
  "today": "2026-07-10",
  "articles_today": 10,
  "images_today": 0,
  "articles_this_week": 15,
  "images_this_week": 0
}

これはトレード成績ではありません。ここで参考にすべきなのは、無人運用でも「何回動いたか」「どこで失敗したか」「どの工程が詰まったか」を数字で残している点です。

AIトレードBotでも、最低限これと同じ考え方が必要です。

全体像：AI Bot、VPS、取引所API、ログ、通知の関係

完全無人AIトレードBotは、次の部品で構成します。

初心者が最初に目指すべき状態は、いきなり実注文Botではありません。

おすすめの順番は次です。

1. 価格監視だけ行う
2. シグナル通知だけ行う
3. ペーパートレードで仮想売買する
4. 少額で実注文する
5. 複数銘柄・複数取引所へ広げる

この順番を飛ばすと、Botのバグなのか、API制限なのか、売買ロジックの問題なのか、資金管理の問題なのかを切り分けできなくなります。

事前チェック：VPS契約前に決めること

VPSを契約する前に、次の項目を1枚にまとめてください。

この表が埋まらない状態で実注文Botを動かすのは早いです。

逆に、この表が埋まると、VPS構築で何を設定すべきかが明確になります。

ステップ1：VPSとOSを選ぶ

VPSは、Linuxが使えるものを選びます。初心者にはUbuntu Serverが扱いやすいです。

Ubuntu公式のリリースサイクルでは、LTS版は2年ごとに出て、標準セキュリティメンテナンスを5年受けられるとされています。新規構築なら、2026年7月時点では Ubuntu 24.04 LTS または 26.04 LTS が現実的です。既存の教材やVPSテンプレートが22.04 LTS前提の場合は、22.04 LTSでも構いませんが、新規構築ではサポート期間の長いLTSを優先してください。

参考：Ubuntu Release Cycle
https://ubuntu.com/about/release-cycle

目安は次です。

一般的なVPSは、価格監視、低頻度売買、検証用Botには向いています。一方で、高頻度取引や超低遅延取引には向きません。

高頻度取引では、取引所との物理的距離、ネットワーク遅延、専用線、コロケーションが問題になります。初心者が最初に狙う領域ではありません。

ステップ2：SSHでVPSへ接続する

VPSを契約したら、手元PCからSSHで接続します。

WindowsならPowerShell、Macならターミナルを使います。

ssh root@YOUR_VPS_IP_ADDRESS

YOUR_VPS_IP_ADDRESS は、VPSのIPアドレスに置き換えます。

初回ログイン後、rootユーザーのままBotを運用しないようにします。Bot専用ユーザーを作ります。

adduser botuser
usermod -aG sudo botuser

以後は、次のようにBot用ユーザーで接続します。

ssh botuser@YOUR_VPS_IP_ADDRESS

ステップ3：サーバーを更新する

ログインしたら、まずパッケージを更新します。

sudo apt update
sudo apt upgrade -y

apt update はパッケージ一覧の更新、apt upgrade はインストール済みパッケージの更新です。

初期構築時だけでなく、月1回などの定期メンテナンスでも実行します。

ステップ4：最低限のセキュリティ設定を入れる

BotはAPIキーを持つため、VPSの基本防御を先に入れます。

sudo apt install -y ufw fail2ban
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

最低限、次も確認します。

whoami
hostname
timedatectl
df -h
free -m

見るポイントは次です。

時刻ズレはログ分析や約定時刻の確認に影響します。必ず初期段階で確認してください。

ステップ5：Pythonと必要ツールを入れる

Python製Botを想定して、必要なツールを入れます。

sudo apt install -y python3 python3-pip python3-venv git screen nano

それぞれの役割です。

ステップ6：Bot用ディレクトリを作る

Bot用の作業場所を作ります。

mkdir -p ~/trading_bot
cd ~/trading_bot
python3 -m venv .venv
source .venv/bin/activate

仮想環境が有効になると、プロンプトの先頭に (.venv) のような表示が出ます。

次に、ライブラリを入れます。

pip install --upgrade pip
pip install ccxt python-dotenv

ccxt は、複数の暗号資産取引所APIを統一的に扱うためによく使われるライブラリです。公式リポジトリでは、JavaScript / TypeScript / Python / C# / PHP / Go / Javaに対応し、100以上の取引所APIを扱うライブラリとして説明されています。

参考：CCXT公式
https://github.com/ccxt/ccxt
https://docs.ccxt.com/

ステップ7：APIキーを .env に置く

APIキーをコードに直接書いてはいけません。.env に分離します。

nano .env

例です。

EXCHANGE_API_KEY=your_api_key
EXCHANGE_API_SECRET=your_api_secret
DRY_RUN=true
MAX_ORDER_AMOUNT=1000
DAILY_LOSS_LIMIT=3000
MAX_CONSECUTIVE_ERRORS=5

保存後、権限を絞ります。

chmod 600 .env

さらに、Gitで管理しないように .gitignore に追加します。

nano .gitignore

.env
logs/
__pycache__/
.venv/

APIキー管理のルールは次です。

APIキーは資産そのものです。コードよりもAPIキー管理の失敗の方が、直接的な損失につながります。

ステップ8：最初は実注文しないBotで動作確認する

最初のBotは、実注文を出さず、価格取得とログ出力だけにします。

例として、bot.py を作ります。

nano bot.py

import os
import time
import logging
from dotenv import load_dotenv
import ccxt

load_dotenv()

os.makedirs("logs", exist_ok=True)

logging.basicConfig(
    filename="logs/bot.log",
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
)

dry_run = os.getenv("DRY_RUN", "true").lower() == "true"

exchange = ccxt.bitflyer({
    "apiKey": os.getenv("EXCHANGE_API_KEY"),
    "secret": os.getenv("EXCHANGE_API_SECRET"),
    "enableRateLimit": True,
})

symbol = "BTC/JPY"

while True:
    try:
        ticker = exchange.fetch_ticker(symbol)
        last_price = ticker.get("last")

        logging.info({
            "event": "price_check",
            "symbol": symbol,
            "last_price": last_price,
            "dry_run": dry_run,
        })

        print(f"{symbol} last={last_price} dry_run={dry_run}")

        time.sleep(60)

    except Exception as e:
        logging.exception({
            "event": "error",
            "error": str(e),
        })
        time.sleep(60)

実行します。

mkdir -p logs
source .venv/bin/activate
python bot.py

確認することは3つです。

1. 価格が表示されるか
2. logs/bot.log にログが残るか
3. エラー時にBotが即終了せず、ログを残すか

ログを確認します。

tail -f logs/bot.log

この段階では注文を出しません。価格取得、ログ、例外処理が安定してから次へ進みます。

ステップ9：screen で手動常駐させる

SSHを閉じてもBotを動かし続けるには、まず screen を使います。

screen -S trading_bot
cd ~/trading_bot
source .venv/bin/activate
python bot.py

Botが動いたら、次の操作で画面から離れます。

Ctrl + A
D

再接続する場合は次です。

screen -r trading_bot

現在のscreen一覧は次で確認します。

screen -ls

screen は検証段階に向いています。

ただし、VPSが再起動した場合は自動でBotを戻せません。再起動後もBotを復旧させるには、次の systemd を使います。

ステップ10：systemd で自動起動させる

本番運用では、systemd でBotをサービス化します。

sudo nano /etc/systemd/system/trading_bot.service

例です。

[Unit]
Description=AI Trading Bot
After=network-online.target
Wants=network-online.target

[Service]
User=botuser
WorkingDirectory=/home/botuser/trading_bot
EnvironmentFile=/home/botuser/trading_bot/.env
ExecStart=/home/botuser/trading_bot/.venv/bin/python /home/botuser/trading_bot/bot.py
Restart=on-failure
RestartSec=30
TimeoutStopSec=20

[Install]
WantedBy=multi-user.target

反映します。

sudo systemctl daemon-reload
sudo systemctl enable trading_bot
sudo systemctl start trading_bot
sudo systemctl status trading_bot

ログを確認します。

journalctl -u trading_bot -f

再起動テストも行います。

sudo reboot

再接続後に確認します。

systemctl status trading_bot
journalctl -u trading_bot --since "10 minutes ago"

ここでBotが自動起動していなければ、完全無人運用にはまだ進めません。

screen と systemd の使い分け

初心者は、いきなり systemd に進まず、次の順で進めると切り分けしやすいです。

1. python bot.py で動く
2. screen で動く
3. systemd で動く
4. VPS再起動後も動く
5. 異常時に通知される

ステップ11：停止条件をコードに入れる

自動トレードBotでは、利益条件より先に停止条件を書きます。

最低限、次を決めます。

重要なのは、「エラーが出たらリトライする」だけでは不十分という点です。

リトライし続けるBotは、API制限に引っかかる可能性があります。注文状態が不明なまま再注文すると、二重注文になる可能性もあります。

安全側に倒すなら、次の原則にします。

• 価格が取れないなら注文しない
• 残高が取れないなら注文しない
• 注文結果が確認できないなら次の注文を出さない
• 連続エラーが続くならBotを止めて通知する

ステップ12：通知を入れる

完全無人運用では、ログだけでは足りません。人間が気づける通知が必要です。

通知すべきイベントは次です。

通知先は、Discord、Slack、LINE、メールなどで構いません。

初心者は、まず日次サマリーから入れると運用しやすいです。

例です。

[AI Trading Bot Daily Summary]
date: 2026-07-13
uptime: 99.2%
api_errors: 3
orders_attempted: 0
dry_run: true
manual_intervention: 0
status: OK

最初から注文通知だけを入れると、注文していない時間の異常を見逃します。Botが「何もしていないが正常に監視している」ことも通知対象にしてください。

専門家目線のチェックポイント

チェック1：注文前に「データの鮮度」を見る

価格データが古い状態で注文してはいけません。

確認すべき項目です。

• 取得時刻
• API応答時間
• 最終価格
• bid / ask
• スプレッド
• 出来高
• 取引所側のメンテナンス情報

価格が取れたことと、注文に使ってよい価格であることは別です。

チェック2：注文IDを必ず保存する

実注文する場合、注文IDをログに残します。

最低限、次を保存します。

• 注文時刻
• 取引所
• 通貨ペア
• side（buy/sell）
• 注文数量
• 注文価格
• 注文ID
• 注文ステータス
• Botバージョン
• 判定理由

「注文したはず」ではなく、「どの注文IDが、どの状態か」を追える必要があります。

チェック3：Botバージョンをログに残す

同じBotでも、コードを変更すれば挙動が変わります。

ログには、GitのコミットIDやバージョン番号を残してください。

例です。

bot_version=2026-07-13-001
strategy=price_watch_v1
dry_run=true

あとから損益を見たときに、どのロジックで動いていたか分からないと改善できません。

チェック4：ライブラリのバージョンを固定する

pip install ccxt だけで運用すると、再構築時に別バージョンが入り、挙動が変わる可能性があります。

検証後に固定します。

pip freeze > requirements.txt

再構築時は次です。

pip install -r requirements.txt

チェック5：規約・税務・法規制を確認する

取引所APIを使う場合、取引所の利用規約、API制限、禁止行為を確認してください。

日本居住者が暗号資産を扱う場合は、金融庁の暗号資産交換業者向け監督指針や関連制度も継続確認が必要です。

参考：金融庁 Laws & Regulations
https://www.fsa.go.jp/en/laws_regulations/index.html

VPSでBotを動かせることと、その取引・サービス利用が規約上問題ないことは別です。

よくある失敗と対策

運用KPI：利益だけで判断しない

Botの成果は利益だけで見ません。

利益は相場環境に左右されます。運用改善を見るには、次のKPIを追います。

不労所得的な自動化資産を作るなら、利益額だけでなく、人間の介入がどれだけ減ったかを見ます。

月に10回手動復旧しているBotは、まだ自動化資産ではありません。月に1回のレビューで改善点が分かる状態に近づけることが目標です。

初心者向けの実装ロードマップ

最短で安全に進めるなら、次の順番にしてください。

1日目：VPSに慣れる

• VPSを契約する
• SSH接続する
• Bot用ユーザーを作る
• Ubuntuを更新する
• ufw を設定する

完了条件です。

whoami
sudo ufw status
df -h
free -m

この確認ができればOKです。

2日目：価格監視Botを動かす

• Python仮想環境を作る
• ccxt を入れる
• 価格取得だけのBotを動かす
• logs/bot.log に記録する

完了条件です。

tail -f logs/bot.log

価格取得ログが残ればOKです。

3日目：常駐化する

• screen でBotを動かす
• SSHを切っても動くか確認する
• systemd に登録する
• VPS再起動後に自動復旧するか確認する

完了条件です。

systemctl status trading_bot
journalctl -u trading_bot --since "10 minutes ago"

再起動後もBotが動いていればOKです。

4日目：通知と停止条件を入れる

• 連続エラー停止を入れる
• 日次サマリー通知を入れる
• Bot停止時の通知を入れる
• 実注文はまだしない

完了条件は、異常時に通知が届くことです。

5日目以降：ペーパートレードする

• 実注文なしで売買判定だけ記録する
• 判定理由をログに残す
• 日次で勝率、損益、エラー数を見る
• 最低2週間は検証する

ここで初めて、実注文に進むか判断します。

反論と限界：VPS化しても儲かるわけではない

VPSでBotを動かしても、利益は保証されません。

残るリスクは多いです。

• 相場急変
• スリッページ
• 流動性不足
• 取引所障害
• API仕様変更
• メンテナンス
• 税務処理
• 規約変更
• Botのバグ
• VPS障害
• APIキー漏洩

特に初心者が誤解しやすいのは、「VPSで24時間動く = 収益機会を逃さない = 儲かる」という飛躍です。

正しくは、VPS化で減らせるのは、自宅PCのスリープ、回線断、手動起動忘れなどの運用リスクです。売買ロジックの優位性までは保証しません。

VPS運用が向かないケース

次に当てはまる場合は、実注文Botに進まない方がよいです。

• 売買ロジックを検証していない
• 損失上限を決めていない
• APIキー管理に自信がない
• VPSの基本操作を学ぶ気がない
• ログを読む習慣がない
• 税務用の取引記録を残せない
• 高頻度取引で低遅延を求めている

この場合は、価格監視Bot、シグナル通知Bot、ペーパートレードから始めてください。

実資金を入れるのは、ログ、通知、停止条件、KPIが回ってからです。

類似記事との差別化ポイント

よくある自動トレード記事は、売買ロジックや収益イメージに寄りがちです。

この記事では、VPS、SSH、Python、APIキー、screen、systemd、ログ、通知、停止条件、KPIまでを一つの運用システムとして扱いました。

さらに、Hiro環境の実行ログをもとに、無人化システムでは実際に次のようなイベントが起きることを示しました。

• CLIの成功
• CLIの失敗
• 代替処理への切り替え
• Notion保存成功
• Gitの HEAD.lock によるコミット失敗
• 実行回数の台帳管理

AIトレードBotでも同じです。

派手な予測モデルより先に、止まらず、止まったら分かり、危険なら止まり、数字で改善できる仕組みを作る必要があります。

読了後すぐにやるアクション

今日やることは、VPS契約ではありません。

まず、次のチェックリストを埋めてください。

Bot運用チェックリスト

目的:
実注文の有無:
対象取引所:
対象通貨ペア:
1回の最大注文額:
1日の損失上限:
連続APIエラー停止:
価格データ鮮度の確認:
通知先:
ログ保存場所:
注文IDの保存:
月次KPI:
APIキーの出金権限:
APIキーのIP制限:

このチェックリストが埋まれば、VPS環境構築はかなり具体的になります。

埋まらない項目があるなら、まだ実注文Botを置く段階ではありません。

まとめ：VPSはAI Botを自動化資産に変える土台

完全無人AIトレードBotのVPS環境構築は、次の順番で進めます。

1. 運用目的を決める
2. 実注文前提ではなく価格監視から始める
3. VPSとUbuntu LTSを選ぶ
4. SSHで接続する
5. Bot用ユーザーを作る
6. Python仮想環境を作る
7. APIキーを .env で管理する
8. screen で検証する
9. systemd で自動起動する
10. ログと通知を入れる
11. 停止条件を先に決める
12. KPIで月次改善する

VPSは、Botを「24時間動かす場所」です。

ただし、本当に価値があるのは、ただ動き続けるBotではありません。危険なときに止まり、止まったら通知し、原因をログで追え、次の改善につなげられるBotです。

最後にもう一度書きます。本記事は投資助言ではありません。利益を保証するものでもありません。

それでも、自分の時間を守りながら収益機会を検証するための土台として、VPS運用、ログ設計、通知設計、停止条件、KPI管理は学ぶ価値があります。

本気で自動化・不労所得を構築したい方向けの実践マニュアル

「AI BotをVPSで動かす」「ブログを自動生成する」「アフィリエイト導線を作る」「ポイントや収益が積み上がる仕組みをログ付きで運用する」。

これらを別々に学ぶと、途中で手が止まりやすくなります。

収益化まで進む人は、ツールの使い方だけではなく、人間の作業時間を減らし、AIとサーバーが回り続ける設計図を持っています。

本気で自動化・不労所得を構築したい方は、実践マニュアル一覧を確認してください。VPS運用、AI活用、収益導線、運用KPIまで、手を動かして進められる形に整理しています。

本気で自動化・不労所得を構築したい方向けの実践マニュアルを見る