pm2×Discord Bot、複数運用で実際にハマった3つの罠

チャットシステムを使った個人開発を続けていると、Discord Botの数はいつの間にか増えていく。

通知用、応答用、そして今回新しく作ったサービス用と、気づけば同じVPS上で複数のBotが動くようになっていた。

複数運用に切り替えるタイミングで3つハマったので、同じ状況になりそうな人向けに整理しておく。

Tomoya

意外とハマりやすいポイントになるかもしれないので、
自分用にもここに記録しておく意味で書いていきます。

2つの前提知識

罠①：Botトークンの使い回しによる衝突

最初、新しいBotのために新しくDiscordアプリケーションを作らず、既存のBotトークンをそのまま使い回そうとした。

同じトークンで別々のプロセスがDiscord Gatewayに接続すると、セッションが競合し、片方の機能が正常に動かなくなることがある。

Tomoya

今回は、新しく追加したサービスの通知が、既存Botの処理に埋もれて機能しなかった。

サービスを追加するたびに、Discord Developer Portalで新しいアプリケーションを作り、専用のBotトークンを発行するのが安全だ。

サーバーやチャンネルは共用していい。競合するのはBotの「中身」の方だ。

罠②：pm2のexec_modeの設定漏れ

そもそもcluster modeとfork modeの違い

pm2でBotを常駐化する際、ecosystem.config.cjsにexec_modeを明示していなかったところ、意図せずclusterモードで起動してしまっていた。

nano ecosystem.config.cjs // 編集エディタ

module.exports = {
  apps: [{
    name: "my-bot",
    script: "src/bot.js",
    exec_mode: "fork", // 明示しておく
    instances: 1,
    autorestart: true,
  }]
};

Discord Botのように「1本の接続を常に保つ」タイプのプロセスは、clusterモードには向いていない。

複数インスタンスが起動すると、同じトークンで複数のGateway接続が発生したり、定期処理が重複実行されたりするリスクがある。

exec_mode: "fork"は明示しておいた方がいい。

設定を直した後は、pm2 deleteしてからpm2 startし直すと確実に反映される。

Tomoya

セーブした後に、再起動は忘れずに

使用しているVPS

Xserver VPS（このシリーズで使っているサーバー）

罠③：DiscordのID種類の混同

Tomoya

ここはホントに毎回悩みます。。。

Discordには似たような役割のIDがいくつも存在する。

チャンネルIDとBot Application IDは、どちらも似たような桁数の数字なので混同しやすい。実際、自分もここで一度ハマった。

通知が届かない場合、まず疑うべきはこの取り違えだ！！

なお、これらのIDを表示するには、Discordの「ユーザー設定→詳細設定→開発者モード」を先にONにしておく必要がある。普段は一般ユーザーが使う機会がないため、初期設定では非表示になっている。

まとめ

複数のBotを1台のVPSで運用する時のポイントは

「サーバー・チャンネルは共用していいが、Botアプリケーションはサービスごとに分ける」

これに尽きる。

IDの取り違えも含めて、最初の1回さえ乗り越えれば、次からは同じ手順の繰り返しになる。

▼ Discord Botを活用した記事とそのシリーズ ▼

あわせて読みたい

【非エンジニアが挑む】ついにDiscordの常駐Botが完成｜「VPSである意味」にようやく到達した話 非エンジニアが音声AIチャットをDiscordの常駐Botとして完成。既存のGemini・VOICEVOX処理をそのまま再利用しつつ、Git・pm2のトラブルを乗り越え、『VPSである意味』にようやく到達するまでを記録しました。

①：テーマ選定

あわせて読みたい

【非エンジニアが挑む】VOICEVOX×Geminiで音声AIに挑戦｜なぜあえてVPSでやるのか 非エンジニアが、GeminiとVOICEVOXを組み合わせた音声AIに挑戦。あえてサーバーレスではなくVPSで作る理由、キャラクター選びと利用規約の確認まで、企画の過程を記録しました。

②：基盤構築（土台作り）

あわせて読みたい

【非エンジニアが挑む】本番SaaSのコピーからFirebase依存を剥がしてみた 非エンジニアが、本番運用中のSaaSコピーからFirebase・Stripe・認証機能を段階的に削ぎ落とし、VOICEVOX単体のシンプルな構成に整理した記録。1,900行から280行への大幅な軽量化を実現しました。

③：実装編（MVP）

あわせて読みたい

【非エンジニアが挑む】Dockerで動かすVOICEVOXと、Geminiを繋げてみた 非エンジニアが、Docker初挑戦でVOICEVOXをローカル起動し、Geminiと接続。読み上げツールが対話するシステムに変わるまでと、本番環境への危険な参照ミスに気づいた経緯を記録しました。

④：VPSに反映(MVP)

あわせて読みたい

【非エンジニアが挑む】VPSにDockerを導入｜「あえて公開しない」という設計判断とGitのヒヤリハット 非エンジニアがVPSにDockerを導入し、VOICEVOXエンジンをあえて非公開設定で構築。コピー元の本番リポジトリを書き換えかけたGitのヒヤリハットも含めて、デプロイの全過程を記録しました。

⑤：VPS上である意味の為に機能追加(発展)

あわせて読みたい

【非エンジニアが挑む】AIとの会話を続けられるようにし、検索機能も試してみた 非エンジニアが音声AIチャットに会話継続機能とGemini検索連携（Grounding）を追加。DBを使わない設計判断や、ローカルは有料・VPSは無料枠という使い分けの理由を記録しました。