2026、OpenClawでWhatsAppをLinuxクラウドVPSへ：QRペアリング、セッション永続化、マルチチャネル併走と切断／429の層別排障FAQ

WhatsAppは顧客がすでに持っている窓口だが、ゲートウェイ横では最も扱いづらいアダプタのひとつでもある。QRログインの猶予は短く、セッションファイルは資産であり、Meta側の抑制はログ上では「ただの切断」に見えがちだ。輸送層の落ちとHTTP 429を分けて読むまで原因が曖昧になる。本稿は2026年、LinuxクラウドVPS上のOpenClaw向けの再現手順：一度スキャンして専用OSユーザー下に状態を永続化し、TelegramやSlackと秘密情報を共有せず併走し、障害を層別に切り分ける。

再現手順：VPS準備、QRペアリング、最初のメッセージ

非rootユーザー（例：openclaw）と、そのユーザー所有の単一の書き込み可能な状態ルート（例：/var/lib/openclaw/whatsapp）を用意する。OpenClawはtarballでもコンテナでもよいが、セッションディレクトリはホストボリュームでマウントし、再構築でペアリングが消えないようにする。ゲートウェイを一度フォアグラウンドで起動し、ログのQR文字列またはASCII QRを端末のスクロールバックから欠けず取得し、業務用端末でタイムアウト内にスキャンする。「connected」相当のログを確認してからバックグラウンド化する。

外向きの露出やSSH／HTTPSの束ね方は、2026 OpenClaw Linux クラウドVPSの最小露出：ファイアウォール雛形、Gatewayループバック束ね、SSHトンネル管理面、HTTPS公開リバースプロキシとの意思決定マトリクスと段階別FAQのマトリクスと併せて決めると、運用後の切り分けが楽になる。

# ~/.config/systemd/user/openclaw-whatsapp.service
[Service]
WorkingDirectory=/var/lib/openclaw/whatsapp
ExecStart=/usr/local/bin/openclaw gateway --profile whatsapp
Restart=on-failure
RestartSec=5

ログアウト後も常駐させるならサービスユーザーのlingerを有効化し、ログローテーションはゲートウェイログに限定する——稼働中のセッションファイルを途中書き込みのまま回さない。初回ペアリング成功後、意図的に一度再起動し、QRなしでセッションが復元されるか確認する。

セッション永続化：再起動とイメージ更新で残すべきもの

WhatsAppのセッションストアはパスワードDBと同列に扱う。ビルドが対応していればディスク上は暗号化、パーミッションは0700、バックアップは箱外へ暗号化コピー、開発用PCへの「ついで持ち出し」はしない。ペアリングはゲートウェイ同一性に暗号材料が紐づくため、制御された移行なしにディレクトリだけを別VPSへ複製すると、新規QRと短時間の二重登録トラフィックを招き、濫用抑制側のパターンに当たりやすい。

スナップショットはプロセス停止後のみ。ホットコピーは壊れたペアとして突然ログアウトに見える。Blue/Greenなら、トラフィック切替前に同じボリュームを新インスタンスへマウントし、送受信が新ノードで成功してから旧VMを退役する。

Telegram・Slackなどとのマルチチャネル併走

チャネルごとに別プロファイルまたは別プロセスを立て、トークンファイルやセッションルートを分離し、ツール応答がネットワークを跨いで交錯しない単一出力キューを維持する。WhatsAppがTelegramの環境変数を読むような.envの貼り間違いは、ヘルスチェックは通るのに返信先だけが別アダプタへ流れる原因になる。

Linux VPS上でイベント購読とコールバックを束ねる具体例は、2026年、LinuxクラウドVPSでのOpenClaw × Slack：Botトークン、イベント購読、ゲートウェイへのコールバックURL──再現手順と403／リプレイの段階的FAQが近い。トランスポートは違っても、トークン分離と再送の見え方の整理はそのまま流用できる。

層別排障：単なる切断と429抑制

層1・接続性：WhatsApp向けの外向きUDP/TCPは、ノートPC経由SSHではなくVPS本体から検証する。小規模事業者線では中間装置による断続損失が出やすく、OpenClawのバージョンより egress や安定したリゾルバの方が効くこともある。

層2・セッション整合：ログにマルチデバイス競合や強制ログアウトが出るなら、セッションディレクトリへの主ライターは一つに限定する。同じ番号へ別ブリッジもログインしていると、丁寧なエラー文字列なしにゲートウェイ側が追い出される。

層3・レート制限：429や抑制文言が続くときは分あたり送信数を計測し、重複自動返信を畳み、ツール多めのフローにはジッター付きバックオフを入れる。429は予算問題であり鍵の取り違えではない——APIキー回し替えではWhatsAppセッションの送りすぎは解消しない。一部チャットだけ失敗する場合は、1件のインバウンドから複数アウトバウンドが扇状に広がっていないかを見て通知を合流させる。