OpenWA は WhatsApp 接続の自由度とアカウントリスクを同時に引き受ける

自前のメッセージ基盤を組む TypeScript ゲートウェイ

OpenWA は TypeScript 製の無料、オープンソース、セルフホスト型 WhatsApp API ゲートウェイです。README は、データベースを SQLite または PostgreSQL、バックアップと移行の保存先をローカルディスクまたは S3、キャッシュを無効または Redis から設定で選べる構成として示しています。受信したメディアは API と webhook の利用者へ inline で返されますが、保存先へ自動的に永続化されるわけではありません。ここが、単に API を呼ぶだけの製品紹介と異なる点です。セッション、メディア、バックアップの責任はセルフホスト側に残ります。

非公式接続であることを最初に評価する

README は OpenWA が Meta の公式製品ではないと明記しています。接続にはリバースエンジニアリングされた whatsapp-web.js または Baileys を使い、Meta の Cloud API ではありません。アカウントが制限または停止されるリスクはゼロにならず、専用番号を使うよう案内されています。whatsapp-web.js はヘッドレス Chromium を使い、README の説明では実際の WhatsApp Web トラフィックに近い一方、1 セッション約 300 から 500 MB のメモリを使います。Baileys はマルチデバイスプロトコルを直接扱い、約 30 から 80 MB と軽い反面、識別されやすいとされています。いずれもプロジェクトの説明であり、停止率のベンチマークではありません。

送信ポリシーはコード品質では解消できない

安全送信の案内には、新しい番号を時間をかけて慣らすこと、見知らぬ人への一括送信を避けること、送信レートを絞ること、受信に同意した相手だけを使うことが含まれます。データセンターの IP は積極的にフラグを付けられる場合があるとも書かれています。新しい連絡先への最初のメッセージは API が成功を返しても WhatsApp 側で届かないことがあり、制限された番号を OpenWA が復元する手段はありません。つまり、再送ロジックや監視を作る前に、利用規約、対象番号、同意記録、失敗時の代替経路を決める必要があります。規制環境では公式 Cloud API を使うよう README が勧めています。

REST、webhook、セッション管理の面

機能表には REST API、複数セッション、API キー認証、Web Dashboard、Swagger、HMAC 署名付き webhook が挙げられています。メッセージング面はテキスト、メディア、リアクション、編集、一括送信、配信と既読の状態を含みます。グループ管理、プロフィール更新、通話イベントの自動拒否、チャンネル、ラベル、プロキシ、レート制限、CIDR の許可リスト、管理操作の監査ログも列挙されています。これらは README の機能主張で、独立検証や性能数値ではありません。実装前には、失敗時のイベント順序、再送、webhook の署名検証、セッション単位の権限を自分のフローで確認すべきです。

Docker プロファイルと公開境界

推奨の開始方法はリポジトリを取得して docker compose -f docker-compose.dev.yml up -d を実行することです。Dashboard は localhost:2785、API は /api、Swagger は /api/docs と README に示されています。開発用には npm ci と npm run dev があり、Vite の Dashboard は 2886、API は 2785 です。本番 compose では postgres、redis、minio、full のプロファイルを選べます。GHCR イメージは linux/amd64 と linux/arm64 の両方を掲げ、TLS と公開アクセスには自分のリバースプロキシを前段に置くよう案内しています。MCP の /mcp も認証プロキシの背後に置くべきで、公開ポートをそのまま信頼境界にしてはいけません。

MCP は REST と同じ権限面を通る

MCP は既定で無効で、MCP_ENABLED=true にすると既存サーバーの POST /mcp にステートレスな Streamable HTTP を取り付けます。セッション、メッセージング、連絡先、基本的なグループ操作、webhook 読み取りを含む約 39 の選別済みツールが公開されると README は説明します。すべての呼び出しは REST と同じ API キー認証、役割、セッション単位のスコープを通過します。専用の最小権限キーを使うこと、IP 許可リスト付きキーは MCP 上で実クライアント IP を取得できず拒否されること、OAuth 2.1 はまだ構築されていないことも明記されています。

Node 22 の構成と MIT の読み方

技術スタックには Node.js 22 LTS、NestJS 11 系、TypeScript 6 系、TypeORM、Docker が記載されています。ENGINE_TYPE で whatsapp-web.js と Baileys を切り替え、src には session、message、webhook、group、contact、auth、infra、health が置かれる構成です。ライセンスは MIT で、使用、複製、変更、統合、公開、配布、サブライセンス、販売を許可しますが、ソフトウェアは無保証です。MIT はアカウント停止、WhatsApp のサービス継続、セキュリティ監査、サポート時間を保証しません。

OpenWA の場合、機能検証より先に利用資格とアカウント保全の条件を決める必要があります。API が 200 を返したことは、WhatsApp の相手へ確実に届いたことを意味せず、新規連絡先への最初のメッセージがサーバー側で落ちる場合も README に明記されています。送信者、宛先、body、type、mentions、fromMe、hasMedia、isGroup を使う webhook フィルターは運用データを絞れますが、同意記録や法的な送信許可を作る機能ではありません。MCP の約 39 ツールも、REST と同じキーと役割を通るという権限面を持つ一方、OAuth 2.1 は未実装です。Docker socket proxy の制約、/mcp の公開境界、API キーの CIDR 条件、メディアの永続化先を確認し、専用番号を失っても業務が止まらない代替経路を準備してから試験するのが妥当です。

実際の通知や顧客対応に使うなら、最初に受信者の同意、送信量、番号の所有者、停止時の切り替えを明文化します。OpenWA のレート制限、CIDR 許可リスト、監査ログは API の管理面を整える機能ですが、WhatsApp 側の信頼判定を制御する機能ではありません。webhook の HMAC は配信元の確認に役立つ一方、秘密を安全に保管すること、再送を重複処理しないことは利用側の責任です。MCP を有効にするなら、REST 用の管理キーをそのまま共有せず、セッション単位の最小権限キーを用意し、/mcp を内部ネットワークまたは認証プロキシに限定します。Docker socket proxy は危険な操作を絞る入口ですが、README 自身が細粒度の特権境界ではないと説明しているため、侵害時の影響を別に評価しなければなりません。

編集部の結論

OpenWA は、自分のサーバーで WhatsApp セッション、API キー、webhook、保存先を管理したい開発者向けです。ただし Meta の公式製品ではなく、アカウント制限や停止の可能性を README 自身が警告しています。失ってもよい専用番号、オプトイン済みの宛先、送信レート制限、別チャネルの代替策を用意し、規制対象や重要通知では公式 Cloud API と比較してから採用してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes