VPSでボットを24時間365日動かし続ける（静かに死なせないために）

サーバー上でボットが「動かない」には二通りあります。分かりやすいほう：SSHを閉じた途端に止まる。ずるいほう：二日間はちゃんと動き、未処理のエラーで午前4時にクラッシュし、誰かがなぜ落ちているのか尋ねる数時間後に気づく。どちらも同じ直し方で、それは「再起動を忘れないこと」ではありません — 仕事を systemd に渡すこと、あなたがやらずに済むよう物事を上げ続けるものです。

ログアウトでなぜ死ぬのか

SSHセッションで python bot.py で起動したなら、プロセスはそのセッションの子です。セッションを閉じれば、プロセスも一緒に。nohup と & はこれを覆いますが、クラッシュ時の再起動も起動時の開始も与えません — だから小さな問題を解いて大きいのを残したことになります。

本当の直し方：systemdサービス

これが全部です。/etc/systemd/system/mybot.service を作成：

[Unit]
Description=My bot
After=network-online.target

[Service]
WorkingDirectory=/home/youruser/mybot
ExecStart=/home/youruser/mybot/venv/bin/python bot.py
Restart=always
RestartSec=5
User=youruser
Environment=API_KEY=...

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mybot

二行が重労働をしています：

• Restart=always — ボットがクラッシュしても、systemdが5秒で戻します。その午前4時の死が、誰も気づかない5秒の途切れになります。
• enable — 再起動後に自分でまた始まります。「ああ、サーバーが再起動して全部立ち上げ直すのを忘れた」がなくなります。

それでも振る舞いがおかしいとき — ログを読む

クラッシュループし続けるボットは、より強く再起動しても直りません；実際に何かがおかしいのです。systemdはstdout/stderrを捕捉するので：

systemctl status mybot          # 上か下か、最後の終了コード
journalctl -u mybot -n 100      # 最近のログ + 死んだ原因のエラー
journalctl -u mybot -f          # ライブで追う

原因はほぼ必ずすぐそこにあります：欠けた環境変数、未処理の例外、APIのタイムアウト、OOMキル。それを直しましょう — Restart=always は安全網であって、本当のバグの治療ではありません。

ヒント：ログがメモリでボットが殺されていると示すなら、箱を超えて成長しています — サイジングガイドを確認。

代わりにtmuxやpm2が意味を持つとき

systemdだけが答えではなく、ただ最良の既定です：

• tmux — 手早いテスト や対話的なプロセスを見るのに最適。動かし、切り離し、後で再接続。でもクラッシュで再起動せず、再起動も生き延びないので、本番向けではありません。
• pm2 — すでにNodeの世界にいてプロセスダッシュボードが欲しいなら妥当。落とし穴：pm2自体、今度は生かし続けねばならないプロセスです（たいてい…systemd経由で）。一つのボットには、要らない層です。

単一の常時稼働ボットやエージェントには、systemdが実際に機能する最も単純なもの — すでにサーバーにあり、追加ツールが要らず、再起動、起動時開始、ログを箱から出してこなします。

正直な結論

稼働時間はより大きなサーバーやより多い規律の話ではありません — プロセスをノートPCに縛らないことの話です。Restart=always と enable を付けたsystemdユニットに包み、何かおかしいときは journalctl を確認。それを一度やれば、あなたが見ていようと眠っていようとボットは上がったまま。（新しい箱？まず締めましょう — 24時間のボットは24時間の標的でもあります。）

動かす場所が要る？ Nanoプラン（月$3） がボットを24時間365日生かします — 残りはsystemdがやります。