自己ホスト型WhatsApp APIを構築するOSS「OpenWA」の仕組みと選び方

「WhatsApp で通知やチャットボットを実装したいけれど、Meta 公式の WhatsApp Business API は審査も料金も BSP 契約のハードルも高い」——そんな壁にぶつかって、自己ホスト型の OSS ゲートウェイを探し始めた方は少なくないはずです。

実際に GitHub の Topics をたどると、whatsapp-web.js や Baileys を土台にした REST API ゲートウェイがいくつも見つかります。今回取り上げる「OpenWA」もその一つですが、似たカテゴリの OSS が複数あるため、「結局どれを選べばいいのか」「OpenWA は本番投入してよい成熟度なのか」と判断に迷いがちです。

そこで本記事では、自己ホスト型 WhatsApp API ゲートウェイ OSS である OpenWA について、「何をする OSS なのか」「どんな仕組みで動くのか」を整理したうえで、WAHA・Evolution API といった類似 OSS との違い、そして採用前に確認しておきたい成熟度・規約リスクまでを解説します。機能を網羅的に並べるのではなく、自分のプロジェクトに採用すべきかを自分で判断できる材料を提供することを目的としています。

なお本記事は、公開されている README・公式サイト・公式ドキュメントの情報をもとに整理したものです。筆者が実際に環境構築や動作確認を行ったわけではないため、導入手順は README に記載された内容の紹介にとどめている点をあらかじめお断りしておきます。

OpenWAとは — 自己ホスト型WhatsApp APIゲートウェイの全体像

OpenWA（rmyndharis/OpenWA）は、その説明文のとおり「Free, Open Source, Self-Hosted WhatsApp API Gateway」を標榜する OSS です。日本語にすると「無料・オープンソース・自己ホスト型の WhatsApp API ゲートウェイ」となります。

ここで重要なのは、OpenWA が Meta 公式の WhatsApp Business API を使うタイプではない、という点です。OpenWA は whatsapp-web.js というライブラリ経由でブラウザ上の WhatsApp Web に接続し、その操作を REST API として外部から叩けるようにする仕組みになっています。つまり、スマートフォンの WhatsApp アプリと同じプロトコルを使い、それを自社サーバーから API で制御するイメージです。

この性格から、OpenWA は次のような開発者に向いています。

• 公式 API の審査・料金・BSP（Business Solution Provider）契約のハードルを避けたい
• メッセージデータを外部サービスに預けず、自社サーバー内で完結させたい（データ主権の確保）
• ベンダーロックインを避けたい

ライセンスは MIT で、有料プランは存在せず、全機能を無償で利用できます。商用利用も可能です。リポジトリの基本情報は次のとおりです。

スター数が約 7,066 と一定の支持を集めている一方で、リリースバージョンが v0.1.6 とまだ初期段階にある点は、採用判断の際に押さえておきたいポイントです。この成熟度の論点については、後述の採用前の確認事項であらためて整理します。

OpenWA のより詳しい情報は、公式サイト（OpenWA 公式サイト）と GitHub リポジトリ（rmyndharis/OpenWA）で確認できます。

OpenWAの主な機能と仕組み

OpenWA は WhatsApp 連携に必要な機能をひととおり備えています。ここでは「自分がやりたいことが機能としてカバーされているか」を確認できるよう、採用判断に必要な粒度で主な機能を整理します。

OpenWA が提供する主な機能は次のとおりです。

• REST API（Swagger ドキュメント付き）
• マルチセッション（複数の WhatsApp アカウントを管理）
• リアルタイム Webhook（HMAC 署名対応）
• React ベースの Web ダッシュボード
• API キー認証
• グループ / チャンネル（Newsletter）対応
• ラベルによるチャット整理
• 一括送信（bulk messaging）
• 配信・既読レシートの追跡
• メッセージリアクション（絵文字）

セキュリティ・運用面では、HMAC 署名付き Webhook、API キー認証、CIDR による IP ホワイトリスト、セッションごとのプロキシ設定、レート制限、監査ログといった機能が用意されています。自社サーバーで運用する前提に立った仕組みが揃っている点は、本番運用を視野に入れる際の安心材料になります。

メッセージ送受信とマルチセッション

OpenWA の基本は、WhatsApp のメッセージ送受信を REST API 化することです。テキストやメディアの送信、グループ・チャンネルへの投稿、一括送信、配信・既読の追跡などを API 経由で扱えます。

特徴的なのがマルチセッション機能で、一つの OpenWA インスタンスで複数の WhatsApp アカウントを管理できます。複数の番号で通知を出し分けたい、あるいは顧客ごとに番号を分けて運用したいといったケースで役立ちます。

Webhook と REST API による連携

外部システムとの連携は、REST API による能動的な操作と、Webhook による受動的なイベント通知の二本立てです。たとえばセッションの作成からメッセージ送信、Webhook の登録までを次のような curl リクエストで行えます。

セッションの作成:

curl -X POST http://localhost:2785/api/sessions \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{"name": "my-bot"}'

テキストメッセージの送信:

curl -X POST http://localhost:2785/api/sessions/{sessionId}/messages/send-text \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{"chatId": "628123456789@c.us", "text": "Hello from OpenWA!"}'

Webhook の設定:

curl -X POST http://localhost:2785/api/sessions/{sessionId}/webhooks \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{"url": "https://your-server.com/webhook", "events": ["message.received"], "secret": "your-hmac-secret"}'

（出典: rmyndharis/OpenWA README）

メッセージ受信時に Webhook で自社サーバーへ通知が飛び、その内容に応じて REST API で返信を送る——という流れを組めば、チャットボットのような双方向のやり取りも実装できます。Webhook には HMAC 署名が付くため、受信側で正当な送信元かを検証できる点も実務上ありがたい設計です。

プラガブル設計 — OpenWAのアーキテクチャ

OpenWA を類似 OSS と比べたときに最も特徴的なのが、インフラ層のプラガブル（差し替え可能）な設計です。これは「自社の既存インフラに乗せられるか」という採用判断の具体的な軸に直結します。

OpenWA では、アプリケーションコードを変更することなく、設定だけで以下のバックエンドを差し替えられます。

たとえば、開発時は SQLite とメモリキャッシュ、ローカルストレージで手軽に動かし、本番では PostgreSQL・Redis・S3 に切り替える、といった運用が設定変更だけで実現できます。すでに PostgreSQL や S3 を運用している組織であれば、新たなミドルウェアを増やさず既存資産に相乗りできるため、運用負荷を抑えやすくなります。

技術スタックは次のとおりです。

NestJS と TypeScript を中心とした構成のため、Node.js での開発経験がある方であればコードベースを把握しやすいでしょう。なお、Node.js のバージョンについては README で「Node.js 22 LTS」と記載されている一方、公式サイトの一部には「Node.js 20」と記載された箇所も見受けられます。実際に導入する際は、お使いのバージョンのリポジトリの記述を確認することをおすすめします。

アーキテクチャやセキュリティ設計の詳細は、公式ドキュメント（OpenWA docs）に整理されています。プラガブルな構成をどう設定するか、セキュリティ機能をどう有効化するかは、こちらを参照すると把握しやすくなります。

導入方法の概要（Docker / ローカル）

ここでは、README に記載された導入手順の概要を紹介します。前述のとおり筆者が実際に環境構築を行ったわけではないため、あくまで README 記載の流れの紹介として参照してください。

Docker を使う方法が推奨されています。

git clone https://github.com/rmyndharis/OpenWA.git
cd OpenWA
docker compose -f docker-compose.dev.yml up -d

ローカル開発環境で動かす場合は次のとおりです。

git clone https://github.com/rmyndharis/OpenWA.git
cd OpenWA
npm install
npm run dev

（出典: rmyndharis/OpenWA README）

起動後のアクセス先は次のように整理されています。

Docker Compose で一式が起動するため、Node.js と Docker を扱える環境であれば、導入の初期コストはそれほど高くない構成といえます。API の仕様を Swagger 上で確認できるため、まずはダッシュボードと Swagger を眺めながら、自分のやりたいことが API でカバーされているかを確かめるとよいでしょう。

類似OSSとの比較（WAHA・Evolution API）

OpenWA と同じ「非公式 WhatsApp Web プロトコル経由で REST API を提供する自己ホスト型ゲートウェイ」というカテゴリには、ほかにも有力な OSS があります。代表的なのが WAHA と Evolution API です。「類似ツールとどう違うのか」「どれを選ぶべきか」は最も切実な疑問だと思いますので、ここで主要な差分を整理します。

WAHA との違い（エンジン選択 vs 単一エンジン）

WAHA（devlikeapro/waha）は「ワンクリックで設定できる WhatsApp HTTP API」を掲げる OSS です。最大の特徴は、WhatsApp に接続するエンジンを複数から選べる点にあります。

• WEBJS: ブラウザベース（whatsapp-web.js 系）
• NOWEB: WebSocket / Node.js ベースで Chromium 不要。CPU・メモリを節約できる
• GOWS: WebSocket / Go ベース

OpenWA が whatsapp-web.js（ブラウザベース）の単一エンジンであるのに対し、WAHA は NOWEB や GOWS のように Chromium を起動しない軽量なエンジンを選べます。リソース消費を抑えたい、多数のセッションを軽く回したいといった軽量運用を重視するなら WAHA のエンジン選択肢が有利です。ただし WAHA は一部機能が有料の WAHA Plus で提供されており、OSS 版は WAHA Core にあたります。全機能を無償で使える OpenWA とは、この点で性格が異なります。

Evolution API との違い（外部連携の広さ vs インフラ差し替えの柔軟さ）

Evolution API（EvolutionAPI/evolution-api）は、WhatsApp に加えてマルチチャネル連携を視野に入れた本番運用向けの REST API です。Baileys ベースの非公式 Web API に加え、Meta 公式の WhatsApp Cloud API も併用できる点が特徴です。

さらに、Typebot・Chatwoot・Dify・OpenAI・RabbitMQ・Kafka・Amazon SQS など、チャットボット基盤や CRM、メッセージキューといった外部サービスとの連携が豊富に用意されています。業務システムへの組み込みや大規模運用を見据えるなら、この連携の広さは強力です。

一方で OpenWA は、外部連携こそ Webhook 中心とシンプルですが、その分インフラ層（DB・キャッシュ・ストレージ）をコード変更なしで差し替えられるプラガブル設計に注力しています。豊富な連携ハブとして使いたいなら Evolution API、自社インフラの構成に合わせて素直に組み込みたいなら OpenWA、という住み分けになります。

採用前に確認したいポイント（成熟度・規約リスク・メンテナンス状況）

OpenWA を本番に投入してよいかを判断するうえでは、機能だけでなくリスク面も押さえておく必要があります。ここでは成熟度・規約リスク・メンテナンス状況の3点を整理します。

成熟度

OpenWA の最新リリースは v0.1.6 で、まだ初期段階のバージョンです。スター数が約 7,066 と支持を集めている点は安心材料ですが、バージョン番号が示すとおり、API や仕様が今後変わる可能性は念頭に置くべきです。本番投入する場合は、特定バージョンに固定する、十分に検証期間を取るといった運用上の備えがあると安全です。

規約リスク（番号 BAN リスク）

OpenWA は Meta 公式の API ではなく、非公式の WhatsApp Web プロトコル経由で動作します。このため、WhatsApp 側のプロトコル変更によって動作が影響を受ける可能性や、利用規約との関係で番号が BAN される可能性といった論点が存在します。

重要なのは、これは OpenWA に固有の問題ではなく、whatsapp-web.js や Baileys を土台とする同カテゴリの OSS（WAHA や Evolution API を含む）に共通する論点だという点です。自己ホスト型ゲートウェイを採用する以上は避けて通れないリスクとして、用途や送信量に応じて慎重に判断する必要があります。なお、Meta 側の規約解釈やどこまでが許容されるかについては、本記事の調査範囲では断定できないため、未確認の論点として扱います。

メンテナンス状況

リポジトリの最終更新は 2026-05-25、最新リリースは 2026-05-17 と、調査時点では活発に更新されています。初期バージョンの OSS では更新が止まっていないかが重要な確認ポイントになりますが、その点では現状は前向きに評価できます。実際に採用を検討する際は、最新の更新状況とコミット頻度を GitHub 上で改めて確認することをおすすめします。

まとめ — OpenWAが向くケース・向かないケース

最後に、ここまで整理した判断軸をもとに、OpenWA と類似 OSS の選び分けをまとめます。

• OpenWA が向くケース: メッセージデータを自社サーバー内で完結させたい、すでに運用している PostgreSQL や S3 などに合わせて構成を組みたい、全機能を無償（MIT）で使いたい開発者。インフラ層を自社構成に寄せられるプラガブル設計が決め手になります。
• WAHA が向くケース: Chromium を起動しない軽量エンジン（NOWEB / GOWS）でリソースを抑えたい、即起動・エンジン選択を重視したい場合。
• Evolution API が向くケース: Typebot や Chatwoot、各種 AI・メッセージキューと連携した業務システムを構築したい、公式 Cloud API も併用したい大規模運用。

いずれを選ぶ場合も、非公式プロトコル経由ゆえの規約・BAN リスクは共通の前提として残ります。OpenWA については、v0.1.6 という成熟度を踏まえ、まずは小さく検証してから本番運用へ広げる進め方が現実的でしょう。

次のステップとしては、まず OpenWA の機能が自分の用途に合うかを GitHub の README（rmyndharis/OpenWA）で確認し、アーキテクチャやセキュリティ設計の詳細を公式ドキュメント（OpenWA docs）で読み込むとよいでしょう。本記事が、自己ホスト型 WhatsApp API ゲートウェイの採用判断を進めるうえでの出発点になれば幸いです。