仮想通貨botのVPSとは、取引所のAPIに接続して売買を自動実行するプログラムを、自宅PCの電源やネット回線に依存せず24時間動かし続けるために借りるレンタルサーバーのことである。結論を先に言うと、個人が1〜2取引所で数銘柄を回す用途なら「メモリ2GB/CPU3コア/SSD 100GB」クラスで十分足り、国内VPSなら月額1,100〜1,600円前後(2026年7月時点の各社公表価格)で確保できる。ここに取引所の売買手数料と、AIに判断させる場合のAPI利用料が上乗せされる、というのが実費の全体像だ。
日本語で「仮想通貨 bot VPS」を検索すると、上位に出てくるのはFXのMT4/MT5を前提にした記事がほとんどで、Windows Serverのデスクトップ環境を推す内容が並ぶ。しかし暗号資産のbotはPythonやNode.jsで書かれたプログラムをLinux上で常駐させる形が主流で、必要なスペックもセキュリティ設計もMT4とはまったく別物である。この記事はその空白を埋めるために、Linux前提の構成・実費・セキュリティ設定を、そのままコピーして使える形でまとめる。
この記事でできること・できないこと
VPSは万能ではない。何が解決して何が解決しないのかを最初に整理しておく。
| 項目 | VPSでできること | VPSでもできないこと |
|---|---|---|
| 稼働の継続 | 自宅の停電・回線断・PC再起動と無関係に動き続ける | データセンター側の障害・メンテナンスは避けられない |
| 通信の安定 | 常時接続の固定IPで取引所APIのIP制限が使える | 取引所側のAPI障害・レート制限は回避できない |
| 応答速度 | 家庭回線より遅延のばらつきが小さい | ミリ秒を争う高頻度取引で業者に勝つことはできない |
| 運用コスト | 月1,000円前後から固定費が読める | 手数料・スプレッド・資金調達率のコストは別途かかる |
| 収益 | botを止めずに済むので機会損失が減る | 戦略が損失を出す性質なら、稼働時間が長いほど損失も増える |
最後の行が一番重要である。VPSは「勝てない戦略を勝たせる装置」ではなく「決めたルールを取りこぼさず実行する装置」でしかない。ルールの中身が悪ければ、VPSは損失を効率よく積み上げる道具になる。
なぜ自宅PCではなくVPSなのか
自動売買を自宅PCで動かすと、次のような形で必ず取りこぼしが起きる。
- OSの自動更新と再起動:Windows Updateは深夜に再起動をかけることがあり、その間ポジションは無防備になる。
- 回線断:家庭用回線は工事やルーター再起動で数分〜数時間落ちる。損切り注文をローカルで管理していた場合、監視が消える。
- スリープ・省電力:ノートPCは蓋を閉じただけで通信が止まる。
- IPアドレスの変動:取引所APIキーにIP制限をかけたいのに、家庭回線のグローバルIPは再接続で変わることがある。
- 熱と騒音:常時稼働は家庭用ハードにとって過酷で、寝室に置くには音がうるさい。
VPSはこの5つをまとめて解決する。特に4番目は見落とされがちだが、APIキーの安全性を大きく左右する。取引所のAPIキーにIP許可リストを設定できるかどうかは、キーが漏れたときの被害額を決める分岐点になる。BitgetのAPIキーはIP制限に対応しているため、固定IPを持つVPSと組み合わせる価値が大きい。
用途別の推奨スペックと月額実費
暗号資産botの負荷は「同時に監視する銘柄数」「WebSocket接続数」「バックテストや機械学習をサーバー上でやるか」でほぼ決まる。判断の目安は次の通りである。
| 用途 | メモリ | vCPU | SSD | 月額の目安 |
|---|---|---|---|---|
| 1取引所・1〜3銘柄・シンプルなロジック | 1GB | 2コア | 50GB | 800〜1,000円 |
| 1〜2取引所・5〜15銘柄・DB+監視あり | 2GB | 3コア | 100GB | 1,100〜1,600円 |
| 複数取引所・裁定・AI判断の常時呼び出し | 4GB | 4コア | 100〜200GB | 2,100〜3,300円 |
| サーバー上でバックテスト/学習も回す | 8GB以上 | 6コア以上 | 400GB | 6,400〜9,800円 |
2026年7月時点の主要な国内VPSの公表価格を並べると、さくらのVPSは2GB/仮想3コア/SSD 100GBが月1,594円(石狩リージョン・年間支払いの月額換算)、ConoHa VPSは2GB/3コア/SSD 100GBが月1,133円(1か月契約のまとめトク価格・税込)、Xserver VPSは2GB/3コア/NVMe 50GBが月2,200円(初回契約時・税込)となっている。いずれも長期契約にするほど月額換算が下がる料金体系で、ConoHaは最長36か月契約で大幅な割引が設定されている。
最初の1台は2GBプランを選び、足りなければ上位プランへ移行するのが失敗の少ない選び方だ。1GBでも動くが、PythonでpandasやNumPyを使う、ログをDBに書く、Dockerを併用する、といった要素が2つ以上重なると途端に苦しくなる。メモリ不足でOOM Killerにプロセスを落とされるのは、botの障害としては最悪の部類に入る。落ちたことに気づかないまま含み損だけが残るからだ。
リージョン(設置場所)の選び方
「取引所のサーバーに近いリージョンを選べ」という説明をよく見るが、これは半分正しく半分は誤解を招く。海外取引所の多くはAPIの物理的な配置を公表しておらず、Bitgetも公式に所在地を明示していない。したがって「東京に置けば速い」「シンガポールが正解」といった断定は、少なくとも公開情報からは裏付けられない。
現実的な手順はこうだ。候補リージョンを2つ借りて、実測してから決める。多くのVPSは時間課金があるので、1日試して片方を消せば費用は数十円で済む。実測は次のコマンドをそのまま使えばよい。
# 取引所APIエンドポイントへの往復遅延を50回測って中央値を見る
# (スキームの大文字小文字はcurl・requestsとも区別しないのでそのまま使えます)
for i in $(seq 1 50); do
curl -o /dev/null -s -w "%{time_total}\n" \
"HTTPS://api.bitget.com/api/v2/public/time"
done | sort -n | awk '{a[NR]=$1} END {print "median:", a[int(NR/2)]}'
判断基準は「中央値が0.15秒を切っているか」「50回のうち極端に遅い外れ値が5%未満か」の2点で十分である。分足以上の時間軸で動くbotなら、中央値100ミリ秒と50ミリ秒の差が損益に効くことはまずない。遅延そのものより、遅延が突発的に跳ねる頻度のほうが実害が大きい。
なお、日本国内に置くか海外に置くかは、遅延よりも「障害時に日本語サポートへ連絡できるか」「請求が円建てか」といった運用のしやすさで決めたほうが後悔しにくい。
対決:他の選択肢とどちらを選ぶか
対 自宅PC・Raspberry Pi
Raspberry Piは電気代が月100円程度と安く、初期費用1万円前後で買い切れる点が魅力だ。ただし家庭回線のIPが変動する問題は解決せず、SDカードの書き込み寿命という固有のリスクを抱える。ログを書き続けるbotはSDカードを1〜2年で壊す。SSDを外付けにすれば回避できるが、そこまでやると初期費用と手間がVPSの1年分を超える。回線とIPを自分で管理したい人以外にはVPSのほうが素直である。
対 国内VPS vs 海外VPS
海外VPSは月5〜6ドル程度から借りられ、リージョンの選択肢が圧倒的に多い。一方で、障害報告もサポートも英語、支払いはドル建てで為替の影響を受け、決済に使ったカードの都合で突然停止するといったトラブル時の解決難易度が上がる。日本語で運用の証跡を残したい、確定申告の経費計上を円建てで整えたい人は国内VPSが無難だ。逆に、複数リージョンでの実測を前提に最適な場所を探したい人は海外VPSの選択肢の広さが効く。
対 サーバーレス(AWS Lambda・Cloud Functions)
「常時稼働のサーバーを持たずに関数だけ動かす」構成は、5分に1回価格を取得して条件を満たしたら発注する、といった単純なbotなら非常に安く上がる。無料枠に収まることも珍しくない。しかしWebSocketで板やポジションを常時監視する構成とは相性が悪い。関数の実行時間には上限があり、接続を張りっぱなしにできないからだ。トレーリングストップのように「価格を秒単位で追いながら建値を動かす」ロジックを組むなら、常駐プロセスが置けるVPSのほうが素直に書ける。
対 取引所内蔵のbot機能
Bitgetのようにグリッド・マーチンゲール・自動積立・トレンド追従といったbotを取引所内で提供しているところもある。サーバーを一切持たずに済み、稼働は取引所が保証する。ロジックが用意されたテンプレートで足りるなら、VPSを借りる理由はない。VPSが必要になるのは「自分で書いたロジックを動かしたい」「複数取引所をまたぎたい」「AIに判断させたい」という段階からである。
実際に構築する手順
手順1:VPSを契約してOSを選ぶ
OSはUbuntu Server の LTS版を選べばよい。日本語の情報量が多く、PythonもNode.jsも公式手順が整っている。GUI(デスクトップ環境)は入れない。メモリを数百MB食うだけで、botの運用にはSSHで十分だからである。契約時にSSH公開鍵を登録できるサービスなら、この時点で登録しておくと後の作業が1つ減る。
手順2:取引所の口座とAPIキーを用意する
サーバーの設定より先に、取引しようとしている取引所でAPIキーが発行できる状態を作っておく。ここでつまずくと、せっかく設定したサーバーが遊んでしまう。国内取引所で日本円を入金し、暗号資産を購入するところまでを先に済ませ、そのうえで海外取引所を使う場合は送金する、という順序が基本になる。
Bitgetは現物・先物ともにREST APIとWebSocketを提供し、APIキーにIP許可リストを設定できるため、固定IPのVPSと組み合わせる構成が取りやすい。手数料は2026年7月時点で現物が0.1%(BGB払いで0.08%)、先物がメイカー0.02%・テイカー0.06%である。
APIキーを作るときの原則は3つだ。出金権限は絶対に付けない、IP許可リストにVPSのグローバルIPだけを登録する、読み取り用と発注用でキーを分ける。この3点を守っておけば、キーが漏れても被害は「勝手に売買される」までに限定でき、資産を持ち出されることはない。
手順3:SSHを鍵認証だけにしてポートを閉じる
VPSは契約した瞬間から世界中のスキャンにさらされる。パスワード認証を有効にしたまま放置すると、数時間で総当たりが始まる。次の設定をそのまま適用すればよい。
# --- 1. 作業用ユーザーを作る(rootで直接運用しない) ---
adduser botuser
usermod -aG sudo botuser
# --- 2. 手元のPCから公開鍵を送る(ローカル端末で実行) ---
# ssh-keygen -t ed25519 -C "bot-vps"
# ssh-copy-id -i ~/.ssh/id_ed25519.pub botuser@<サーバーのIP>
# --- 3. SSH設定を鍵認証のみに固める(サーバー側で実行) ---
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
Port 22022
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AllowUsers botuser
ClientAliveInterval 60
ClientAliveCountMax 3
EOF
sudo systemctl restart ssh
再起動する前に、必ず別のターミナルで新しいポートへのログインが通ることを確認する。ここを飛ばして接続できなくなり、コンソール復旧に半日溶かすのは初心者の典型的な事故である。
手順4:ファイアウォールと侵入検知を入れる
# ufw:必要なポート以外を全部閉じる
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22022/tcp comment 'ssh'
sudo ufw enable
sudo ufw status verbose
# fail2ban:総当たりを自動でBAN
sudo apt update && sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[sshd]
enabled = true
port = 22022
maxretry = 3
findtime = 600
bantime = 86400
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
# 自動セキュリティ更新(再起動は自分の判断で行う設定)
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
ここまでで、外から入れる口はSSHの1つだけになる。botはWebサーバーではないので、80番も443番も開ける必要はない。TradingViewのアラートを受け取るなど外部からのリクエストを受ける構成にする場合だけ、必要なポートを追加で開ける。
手順5:APIキーを環境ファイルに置いて権限を絞る
APIキーをソースコードに直接書くのは論外である。次の形で環境ファイルに分離し、所有者以外が読めないようにする。
sudo mkdir -p /etc/mybot
sudo tee /etc/mybot/env > /dev/null <<'EOF'
BITGET_API_KEY=ここにキー
BITGET_API_SECRET=ここにシークレット
BITGET_API_PASSPHRASE=ここにパスフレーズ
TRADE_SYMBOL=BTCUSDT
MAX_POSITION_USDT=400
TAKE_PROFIT_PCT=3.5
STOP_LOSS_PCT=4.5
EOF
sudo chown botuser:botuser /etc/mybot/env
sudo chmod 600 /etc/mybot/env # 所有者だけ読み書き可
chmod 600 を忘れると、同じサーバーに別のユーザーやサービスがいた場合に読まれる。個人利用でも癖として必ず付ける。
手順6:systemdで常駐させ、落ちたら自動で立て直す
nohupやscreenでプロセスを放置する運用は、サーバー再起動で消える。systemdのサービスとして登録しておけば、異常終了時の自動再起動もOS再起動後の自動復帰も両方まかなえる。
# /etc/systemd/system/mybot.service
[Unit]
Description=Crypto trading bot
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=botuser
WorkingDirectory=/home/botuser/mybot
EnvironmentFile=/etc/mybot/env
ExecStart=/home/botuser/mybot/.venv/bin/python -u main.py
Restart=always
RestartSec=10
StandardOutput=append:/var/log/mybot/out.log
StandardError=append:/var/log/mybot/err.log
# 事故防止のための最低限の隔離
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
[Install]
WantedBy=multi-user.target
sudo mkdir -p /var/log/mybot && sudo chown botuser:botuser /var/log/mybot
sudo systemctl daemon-reload
sudo systemctl enable --now mybot
sudo systemctl status mybot
journalctl -u mybot -f # ログを追う
Restart=always と RestartSec=10 の組み合わせは、APIの一時的なエラーで落ちた場合に10秒後へ自動で復帰させる設定である。ただし再起動時にポジション状態を取引所から取り直す実装になっていないと、再起動のたびに二重発注する危険がある。ここは自作botで最も事故が起きやすい箇所なので、起動処理の先頭で必ず現在のポジションを問い合わせる作りにしておく。
手順7:ログローテーションと死活監視を入れる
# ログが肥大してディスクを埋めるのを防ぐ
sudo tee /etc/logrotate.d/mybot > /dev/null <<'EOF'
/var/log/mybot/*.log {
daily
rotate 14
compress
missingok
notifempty
copytruncate
}
EOF
# 5分ごとにプロセスの生存を確認し、落ちていたら通知する例
sudo tee /home/botuser/healthcheck.sh > /dev/null <<'EOF'
#!/bin/bash
if ! systemctl is-active --quiet mybot; then
echo "[ALERT] mybot is down on $(hostname) at $(date -Iseconds)" \
| mail -s "bot down" you@example.com
fi
EOF
chmod +x /home/botuser/healthcheck.sh
# crontab -e に追記: */5 * * * * /home/botuser/healthcheck.sh
死活監視は「あったほうがよい」ではなく必須である。botが止まっていることに気づくのが翌朝では、その間に相場が大きく動いていた場合に取り返しがつかない。通知手段はメールでもチャットのWebhookでもよいが、自分が確実に気づくものにする。
やってはいけないこと・実際に起きた失敗例
ここが実務で一番差がつくところなので、中盤にまとめて置く。
- APIキーに出金権限を付ける:botの発注に出金権限は一切不要である。付けた瞬間、キー漏洩=資産喪失になる。
- IP許可リストを空のまま運用する:VPSの固定IPを登録するだけで、盗まれたキーが他所から使われる経路を潰せる。設定にかかる時間は1分である。
- APIキーをGitリポジトリに入れる:公開リポジトリに置かれたキーは、数分で自動収集されて悪用される。
.envは必ず.gitignoreに入れる。 - 再起動時にポジションを取り直さない:編集部が実口座で運用している自動売買でも、初期の実装では発注の状態管理に不具合があり、特定銘柄で意図しない挙動が出た。発注監視の仕組みを差し替えて解消したが、「落ちて復帰したときに何が起きるか」を設計していない実装は必ず事故る。
- ガス代・手数料に対して建玉が小さすぎる:手数料やネットワーク費用が利益幅を上回ると、勝ちトレードでも損になる。編集部の運用では建玉の下限を設ける対処を入れた。
- サーバーの時刻がずれている:取引所APIは署名にタイムスタンプを使うため、数秒のずれで認証が通らなくなる。
timedatectl set-ntp trueを必ず有効にする。 - ログを出しすぎてディスクを埋める:1分足のティックを全部ログに書くと、100GBのSSDでも数か月で埋まる。埋まった瞬間にbotは書き込みエラーで止まる。
- バックテストと本番を同じサーバーで回す:バックテストがCPUを食い切ると、本番の発注が遅延する。重い検証は手元のPCでやる。
コストの実額:月にいくらかかるのか
見落とされがちな費用を含めて、実際の出費を積み上げると次のようになる(2026年7月時点、1取引所・数銘柄の個人運用を想定)。
| 費目 | 月額の目安 | 備考 |
|---|---|---|
| VPS(2GBクラス) | 1,100〜1,600円 | 長期契約でさらに下がる |
| ドメイン・SSL | 0〜150円 | 外部からWebhookを受ける場合のみ必要 |
| 監視・通知サービス | 0〜500円 | 無料枠で足りることが多い |
| AIに判断させる場合のAPI利用料 | 数十ドル | 呼び出し頻度で大きく変わる |
| 取引手数料 | 売買代金×0.02〜0.1% | 頻繁に回すほど効く |
AIを組み込む場合、コストの主役はVPSではなくAI利用料になる。1分ごとにモデルを呼ぶような設計にすると、VPS代の何十倍にも膨らむ。呼び出しは「相場のモードが変わったとき」「エントリー候補が出たとき」に限定し、通常の監視はコードで完結させるのが現実的な設計である。編集部でもClaude Codeによる自動売買を実口座で運用しており、その検証結果は運用実績ページで公開している。
海外取引所を使う場合のリスクと注意点
VPSでbotを動かす場合、板の厚さやAPIの機能性から海外取引所を選ぶ人が多い。ただし前提として、日本円の入出金は国内の金融庁登録業者で行い、海外取引所はその先の運用先として使うという位置づけを崩さないほうがよい。国内取引所で日本円を入金して暗号資産を買い、それを海外取引所へ送る流れである。国内取引所はUSDTを扱っていないことが多いため、海外へはUSDT/USDCのまま、国内へ戻すときはBTCやETHに変換して送るのが定石になる。
そのうえで、以下は必ず理解しておく必要がある。
- 金融庁登録がない:Bitgetをはじめとする海外取引所の多くは日本の暗号資産交換業者として登録されていない。日本の法規制による保護や補償の対象外である。
- 出金が制限される可能性:本人確認の追加要求やシステムメンテナンスにより、出金が一時的に止まることがある。全資産を一か所に置かないのが唯一の実務的な対策になる。
- サービス方針の変更:日本居住者向けのサービスが縮小・終了する事例は実際に起きている。Bybitは日本居住者向けサービスを終了し、2026年3月23日にクローズオンリー(新規建玉不可)、2026年7月22日正午に未決済ポジションが強制決済される扱いとなった。乗り換え先を常に把握しておく必要がある。
- 利益は確定申告が必要:国内・海外を問わず、暗号資産の利益は課税対象である。海外取引所は年間取引報告書が出ないことが多いため、取引履歴のCSVを毎月ダウンロードして保管しておく。botは取引数が多くなりやすく、後からまとめて集計するのは非常に手間がかかる。税務の扱いは個別事情で変わるため、税理士など専門家に相談することを勧める。
- ネットワーク選択ミスは資産喪失:送金時にTRC20とERC20を取り違えると、資産が戻らないことがある。初回は必ず少額でテスト送金する。
- レバレッジの上限に引きずられない:Bitgetは最大125倍のレバレッジを提供するが、上限が高いことと適切な倍率であることは別の話である。botの検証段階では低倍率から始める。
- サーバー障害時の建玉:VPSが落ちている間もポジションは市場に残る。損切りは取引所側の注文として置いておくのが基本で、プログラム内の判定だけに頼らない。
稼働前チェックリスト
本番資金を入れる前に、次の項目をすべて満たしているか確認する。
- SSHはパスワード認証を無効化し、鍵認証のみで接続できる
- ufwで不要なポートをすべて閉じ、fail2banが稼働している
- APIキーに出金権限がなく、IP許可リストにVPSのIPだけが登録されている
- 環境ファイルが
chmod 600になっており、Gitに含まれていない - systemdでの自動再起動と、OS再起動後の自動復帰を実際に試験した
- 再起動後にポジション状態を取引所から取り直す実装になっている
- 損切り注文が取引所側に置かれており、bot停止中も有効である
- 死活監視の通知が自分の手元に実際に届くことを確認した
- ログローテーションが設定され、ディスク使用量を監視している
- サーバーの時刻同期(NTP)が有効になっている
- 少額(想定運用額の10分の1以下)で1週間以上の実弾テストを終えた
まとめ
仮想通貨botのVPS選びは、スペック競争ではなく「止まらない仕組みをどれだけ安く作れるか」の設計問題である。2026年7月時点の相場観で言えば、個人の自作botはメモリ2GB・3コアクラスで足り、国内VPSなら月1,100〜1,600円程度に収まる。スペックに追加で払うより、SSHの鍵認証・ファイアウォール・APIキーの権限設計・死活監視という4つの土台に時間を使ったほうが、実際の損益への効き目は大きい。
そしてVPSはあくまで実行環境であり、収益を生むのは戦略そのものである。稼働時間が延びれば、良い戦略の利益も悪い戦略の損失も等しく拡大する。少額での実弾テストを飛ばさず、損切りは取引所側に置き、資産を一か所に集中させない——この3つを守ったうえで、自分のロジックを育てていくのが現実的な進め方だ。
<!-- INTERNAL_LINKS_RELATED -->
関連記事
<!-- INTERNAL_LINKS_RELATED -->
