Discord Bot向けおすすめホスティング：用途別の5社比較

2つのBotを考えてみましょう。一方はPythonで動作し、ローカルのSQLiteデータベースを保持し、もう一方はJavaScriptで動作してコマンドを処理します。どちらもノートPCでは動いています。しかし、サーバーへ移すと、依存関係、ストレージ、プロセス障害後の動作について判断が必要になります。最適なDiscord Botホスティングは、これらをどう連携させて動かすかによって変わります。

選ぶ前にホスティングプランを比較する

同じ「1 vCPU」と記載された2つのプランでも、リソースの割り当て規則が異なることがあります。まずコンピュートのシリーズを確認し、その価格に対応する請求期間とバックアップ範囲を調べましょう。共有vCPUは他の顧客とCPUリソースを利用します。専用割り当てでは、そのVPS用にCPUリソースを確保します。動作の少ないBotなら、共有コンピュートでも十分に動く場合があります。

同じ期間で、必要なものを含む構成全体を比較してください。年単位の契約と柔軟な月払いでは、移行や構成のサイズ変更をする際の影響が異なります。必要なアドレス、バックアップサービス、別のストレージも支払見込み額に含めましょう。

実際のワークロードに合うプロバイダーを選ぶ

イベントを待ち、ときどきコマンドを処理するBotと、バックグラウンド処理を継続するBotではCPU需要が異なります。その動作に合うコンピュートシリーズを選び、デプロイ全体のメモリとディスク要件を確認してください。プロバイダー名だけでは決められません。

マネージドVPSとアンマネージドVPSの違いも購入後の作業に影響します。OS更新、ファイアウォール設定、アプリケーション保守の担当を決めてください。サーバー料金を支払っても、すべての運用作業がホスティング事業者へ移るわけではありません。

複数Botを自分で管理するならCloudzy

複数Botに独立したランタイム、プロセス監視、自分で管理するローカルストレージが必要なら、当社のLinux VPSを選んでください。root権限と自己管理の環境を提供するため、アプリケーションに合わせてPythonやNode.jsのプロセスを配置できます。当社のNVMeストレージにはBotのローカルデータベースやファイルを保存できます。

当社のCPUシリーズの割り当ては、CPUリソースへの予測可能なアクセスが要件に含まれる構成、特にBotがバックグラウンド作業を継続する構成に適しています。

当社は低い導入価格を提供し、当社の料金ページで容量と請求期間をまとめて選べます。合計ワークロードに合わせてプランのサイズを決め、ソフトウェアはご自身で保守してください。

文書化されたVM構成ならDigitalOcean

明確なLinux VMのセットと、文書化されたコンピュートシリーズの選択肢が容量計画に役立つ場合は、DigitalOceanが候補になります。Dropletの料金ページには、1 GiB RAM、1 vCPU、25 GiB SSD、1,000 GiB転送量のBasic構成が掲載されています。

短い処理の合間にアイドル時間があるなら、Basicは合理的な出発点です。Botが多くの時間をジョブ処理に費やす場合は、Basic内でサイズを上げる前に専用CPUシリーズと比較してください。メモリ追加とCPU割り当ての変更は、それぞれ異なる問題を解決します。アップグレードを選ぶ前に、メモリ逼迫やCPUスケジューリングの遅延を特定しましょう。

2026年11月のDroplet料金では、このBasic構成の月額上限は$6です。割合で課金される週次バックアップを選ぶ場合、計算例は月額$6 × 1.20 = $7.20で、税金やその他の料金は含みません。これは選択したサーバーとバックアップオプションの費用であり、アプリケーションが使うすべてのサービスを含むものではありません。購入前に現在のDroplet料金を確認してください。

適切な場所で複数の軽いプロセスを動かすならHetzner

複数の軽いプロセスが、公表された2 Intel/AMD vCPU、4 GB RAM、40 GB NVMeに収まるなら、Hetznerの欧州向けコスト最適化型CX23を検討できます。確認時点ではこの低コストCX23は利用不可と表示されていたため、移行を計画する前にコスト最適化製品ページで希望する場所の空き状況を確認してください。

独立したランタイムにメモリが必要でも、ほとんどの時間を待機に使う場合、この構成は検討に値します。連続処理用に選ぶ前に、持続的なCPU需要を調べてください。

Hetznerのサーバードキュメントでは、Primary IPv4アドレスはVAT別で月額€0.50です。請求FAQではバックアップはサーバー料金の20%とされ、バックアップドキュメントでは接続されたVolumesは対象外です。データベースをVolumeへ移すなら、そのバックアップ費用を別途見込んでください。選択した場所と構成に、実際に使うIPとバックアップの選択肢を加え、他の見積もりと同じ税の計算基準で比較しましょう。

ハードウェアシリーズを選びたいならVultr

Bot向けに特定のハードウェアシリーズを選ぶ理由があるなら、Vultrが候補になります。Cloud Computeのプロビジョニングドキュメントでは、通常のSSDを使う従来のCloud Compute、CPUクロックが高くNVMeを備えるHigh Frequency、新しいIntel XeonまたはAMD EPYCとNVMeを備えるHigh Performanceを区別しています。

アプリケーションの測定結果がCPU処理やストレージアクセスを指しているなら、これらの違いが候補を絞る助けになります。高クロックという表記だけでDiscordの応答が速いと証明できるわけではなく、表に示した割り当て区分も変わりません。遅延が変わらないかもしれないハードウェアに料金を払う前に、Botのどの処理に時間がかかるかとシリーズを照らし合わせてください。

Vultrのrootまたはsudo権限とOS/ISOの選択肢も、特定のランタイム要件がある構成に適しています。役立つのはインストール環境を管理できる点です。依存関係とデプロイ手順が選んだOSで動くかは、引き続き自分で確認する必要があります。プロビジョニングメニューに選択肢が増えても、この確認は行われません。

VultrのAutomatic Backups概要には20%の追加料金が示され、接続されたBlock Storageは対象外です。そこにBotデータを置く場合は、バックアップを別に用意してください。請求額を比べる前に選択した構成全体を確認しましょう。ハードウェアカテゴリーも既定のIPv4選択も、最終的な支払総額を示すものではありません。

既存の小規模Linux構成ならAkamai/Linode

小規模Linux構成が、適切なコアリージョンで利用できるShared CPUのリソースに収まるなら、Akamai/Linodeが候補になります。Shared CPUドキュメントには、1 vCPU、1 GB RAM、25 GB SSDの入門構成が掲載されています。rootで管理することでOSとアプリケーション設定の管理権限を維持できます。

文書化された用途には、CPU需要が低から中程度で、リソース競合を許容するアプリケーションが含まれます。そのため、ときどき処理が集中するBotには合理的な候補です。継続的な計算処理には、別のコンピュートシリーズを評価してください。

Akamaiはコアコンピュートリージョンと分散コンピュートリージョンを区別しており、後者ではShared CPUインスタンスを利用できません。見積もりを実際にデプロイする場所と合わせ、バックアップの選択肢は別に確認してください。

すべてを共有せずに複数Botを動かす

Python BotとNode.js Botは、依存関係、トークン、データパスを分けたまま1台のVPSに置けます。それぞれに独立した実行環境と再起動対象を用意してください。root権限はホスト設定に使えますが、アプリケーションプロセス自体をrootで実行する必要はありません。Botを追加する前に意図的に分離しましょう。

仮の配置例として、Python Bot Aのコードを専用Python環境とともに/srv/bot-aへ置きます。Node.js Bot Bのコードと依存関係のインストール先は/srv/bot-bにします。それぞれに、自分のトークンだけを含む別の設定ファイルかシークレット参照を用意してください。/var/lib/bot-aや/var/lib/bot-bのように異なるアプリケーションデータパスを選び、各サービスアカウントに必要なパスへのアクセスを許可します。これらは名前の提案であり、インストール手順ではありません。

コンテナーも依存関係を分ける手段です。Dockerのリソース制約ドキュメントでは、コンテナーには既定でリソース上限がないとされています。ワークロードを観察した後、メモリとCPUの制約を意図的に設定し、1つのBotがホストのリソース枠を無制限に消費しないようにしてください。

OS、ローカルデータベース、ログ記録を含めて、Botを同時に測定してください。インストール、ビルド、再起動のピークも含めます。アイドル時の値では、両アプリケーションが忙しくなる時間を見逃します。VPSに必要な基本ツールはホストの保守と観測の出発点になります。1 GB当たりのBot数という約束やguild数だけではなく、測定結果から容量を選びましょう。両プロセスは依然として1つのホスト障害の影響範囲を共有しています。

再デプロイ後もBotデータを残す

コンテナーの書き込み可能レイヤーに書いたSQLiteファイルは、そのコンテナーを削除すると消えます。Dockerのボリュームライフサイクルのドキュメントでは、保持されたボリュームは使用中のコンテナーから独立して存在すると説明しています。永続化すべきBotデータは意図的に保持するボリュームかホストパスに置き、再デプロイ前に場所を記録してください。

置き換え可能なコードを、データベース、アップロード済みファイル、Botが保持すべきその他の状態から分けてください。各場所へ書き込むプロセスと、その場所を削除するデプロイ操作を記録します。保持されたボリュームはコンテナーの置き換え後も残りますが、そのボリュームを明示的に削除するのは別の操作です。ログの保持上限も設定し、蓄積した出力がアプリケーションデータ用のディスク領域を消費しないようにしましょう。

永続化はデプロイをまたいで作業用コピーを利用可能にします。バックアップには、別の復元可能なコピーが必要です。稼働中のSQLiteデータベースには、文書化されたSQLite Online Backup APIのようにデータベースを考慮した方法を選んでください。これはオンラインのデータベースを別のデータベースファイルへコピーします。プロバイダーのディスクスナップショットだけでは、アプリケーションの状態を正しく復元できるとは証明できません。

バックアップのコピーをVPSの障害範囲外に保管し、復元方法を記録してください。最初に隔離した場所へ復元し、想定したレコードやファイルを確認します。設定済みのチャンネルや保存設定など、既知のBot状態を調べてください。復元したテスト用コピーが本番用の認証情報で接続しないようにします。バックアップジョブの完了は、復元確認の成功と組み合わせて初めて有用な証拠になります。

全Botを移す前に復旧を確認する

Botのプロセスが生きていても、Discordコマンドに応答できないことがあります。プロセスごとに1つの監視ツールを選び、障害時と起動時の動作を設定したうえで、アプリケーションの応答を別にテストしてください。ネイティブサービス、PM2管理のNode.jsプロセス、Dockerコンテナーでは復旧設定が異なり、再起動ポリシーだけではBotの可用性を証明できません。

ネイティブサービスについては、systemdサービスマニュアルが、ゼロ以外の終了コードなど対象となる障害に対するRestart=on-failureを説明しています。OS起動時の自動起動は別に設定してください。Node.jsでは、PM2の起動ドキュメントが、再起動後の復旧に起動連携と保存済みアプリケーション一覧を必要としています。Node.jsのバージョンを変えたら、その連携を更新してください。

Dockerの再起動ポリシードキュメントは、意図的な停止をデーモン再起動後も維持するunless-stoppedと、デーモン再起動時にはコンテナーを再起動しないon-failureを区別しています。コンテナーの監視はDockerに任せ、ホストのプロセスマネージャーと同じコンテナーの再起動を競合させないでください。

DiscordのGateway接続ドキュメントでは、持続するWebSocket接続でハートビートと切断処理が必要とされています。アプリケーションまたはライブラリは適切に再接続する必要があります。インフラの稼働率では、この接続が正常か、Botのコマンドハンドラーが動くかは確認できません。

全Botを移す前に、重要度の低い構成で次の受け入れ確認例を実施してください。

1. 制御されたプロセス障害を発生させます。選択した監視ツールがプロセスを再起動し、保持したログで障害を説明できることを確認してください。無人の再起動ループを有効にする前に、繰り返すクラッシュを調査します。
2. ホストを再起動します。意図したプロセスが、想定した設定とデータパスで復帰することを確認してください。
3. Discord接続を確認し、各Botで代表的なコマンドを実行します。プロセス状態だけでなく、観察した結果を記録してください。
4. 前述の隔離した復元手順を実施し、想定したアプリケーション状態を確認してください。

結果を記録し、失敗した確認をすべて解決した後で、残りのBotを移してください。

よくあるご質問

Discordのインタラクション方式とデータベースの書き込みパターンによって、デプロイ要件が変わることがあります。

すべてのDiscord Botに持続接続が必要ですか？

いいえ。Discordのインタラクション配信ドキュメントでは、GatewayまたはHTTP Webhook経由でインタラクションを受信できます。HTTP方式では、接続中のGatewayクライアントは不要です。ただし、到達可能なエンドポイントは必要であり、すべてのGatewayイベントを置き換えるものではありません。アプリケーションが利用するイベントに合わせて接続モデルを選んでください。

複数のBotが同じSQLiteデータベースへ書き込めますか？

はい。書き込みを順番に実行できる場合は可能です。SQLiteの同時実行ガイドでは複数の読み取りを認めていますが、1つのデータベースファイルに同時に書き込めるのは1つだけです。同時書き込みを待ち行列に入れられないなら、クライアント／サーバー型データベースを検討してください。VPSを変えてもSQLiteの書き込み同時実行モデルは変わりません。

高速なVPSならDiscordのインタラクションタイムアウトを解消できますか？

必ずしもそうではありません。Discordのインタラクション応答要件では、3秒以内に最初の応答を送る必要があり、インタラクショントークンは後続応答用に15分間有効です。ホストを変える前に、アプリケーションの応答処理を確認してください。CPUやメモリの追加が役立つのは、リソースの圧迫が期限超過の一因になっている場合だけです。