WhatsApp（Metaが運営するメッセージアプリ）で顧客対応を自動化するAIエージェントを検討している開発者に向けた内容です。予約受付や在庫確認をLLM（大規模言語モデル）に任せる構想は珍しくありません。ただ実際に24時間365日稼働させるとなると、デモとは別次元の判断が必要になります。
WhatsAppは全世界で月間20億人以上が利用し、中小企業向けの調査では顧客の60%が電話よりメッセージでの連絡を好むとされています。開封率もメールの20%程度に対して98%と報告されており、通知が届けば読まれる可能性が高いチャネルです。ただしこの高い到達率は、裏を返せば「エージェントが誤動作したときの被害も即座に広がる」ことを意味します。導入前にどこで失敗しやすいかを整理しておく価値があります。
どんな場面で判断が必要になるか
典型的なのは、飲食店や美容室、旅行代理店などの予約管理をAIチャットボットに任せたいというケースです。単純なFAQ応答なら気軽に始められますが、「予約を作成する」「在庫を確認する」といったツール呼び出し（LLMが外部システムの関数を実行する仕組み）を含めるかどうかで、設計の難易度が一気に上がります。
この段階で決めておくべきことは大きく4つあります。順に見ていきます。
判断軸1: プロバイダー冗長化をどこまでやるか
LLM APIは単一プロバイダーに依存すると、レート制限やサービス障害がそのまま業務停止につながります。実運用されているWhatsApp AIエージェント「SARA」（オープンソースで公開されている業務用エージェント）では、Groq（高速推論に特化したAPIプロバイダー）を優先に、Cerebras、SambaNova、Mistralへと順にフォールバックする4段構成を採用しています。
各プロバイダーで2回まで指数バックオフ（失敗ごとに待機時間を延ばす再試行方式）付きの再試行を行い、失敗したら次のプロバイダーに切り替えます。この構成で6か月間の稼働率99.7%を、しかも無料枠のみで達成したと報告されています。
自分のプロジェクトがこの対応を必要とするかは、「LLM APIが5分止まったら誰が困るか」で判断できます。個人の検証用途なら単一プロバイダーで十分ですが、顧客からの予約を24時間受け付ける前提なら、最低でも2段のフォールバックは検討すべきラインです。
判断軸2: 自律実行の許可レベルをどこまで広げるか
AIエージェントにツール呼び出しを許す場合、「何を確認なしで実行させるか」の設計が事故防止の核になります。SARAでは、ユーザーの発言をまず意図分類し、リスク評価をしたうえで実行フローを分岐させています。
- 低リスク: 即時実行（在庫確認など読み取り系の操作）
- 中リスク: 実行後にオーナーへ通知（小規模な予約作成など）
- 高リスク: 実行前に人間の承認を求める（大口注文や取り消しなど）
500人分のケータリング注文を、人間の確認なしにAIが自動発注してしまう事態は避けたいところです。ツールを追加するたびに、この3段階のどこに置くかを最初に決めておくと、後から事故対応に追われるリスクを減らせます。
判断軸3: PII（個人を特定できる情報）の扱いをどう設計するか
WhatsAppのメッセージには氏名・電話番号・住所が自然に含まれます。これをそのままLLMに送るかどうかは、セキュリティ設計上の重要な分岐点です。
SARAの実装では、LLMに渡す前に「Mario Rossi」のような実名を「[PERSON_1]」のような匿名トークンに置き換え、匿名化した状態で推論を行い、ツール呼び出しの実行時だけ実名に戻すという3段階のパイプラインを組んでいます。ログにも平文のPIIを残さない方針です。
自社サービスがこの設計を必要とするかは、「LLMプロバイダーの利用規約でデータがどう扱われるか」を確認するところから始められます。契約プランによってはトレーニングデータへの再利用が既定でオフになっている場合もあるため、まず利用規約とデータ処理契約を確認する価値があります。
判断軸4: セルフホストかクラウドサービスかの分岐点
WhatsApp連携基盤（WAHAのようなWhatsApp Web連携ツール）とAPIサーバーを自前のVPS（仮想専用サーバー）で運用するか、マネージドサービスに乗せるかも重要な分岐です。
| 観点 | セルフホスト | マネージド/SaaS型 |
|---|---|---|
| 初期コスト | 低い（VPS数千円/月〜） | 利用料が発生 |
| 運用負荷 | 自分で監視・復旧が必要 | 提供側が担保 |
| カスタマイズ性 | 高い（ツール追加が自由） | 提供機能に依存 |
| マルチテナント対応 | 自分で実装が必要 | 標準搭載が多い |
SARAの実運用構成では、4vCPU・8GBメモリのVPS1台で、WhatsApp連携部分が約500MB、ブリッジサービスが約50MB、API本体が約200MB、PostgreSQL（オープンソースのリレーショナルデータベース）とpgvector（ベクトル検索拡張）で約2GBという内訳で、合計3GB程度のメモリに収まっています。GPUは不要で、推論はGroqなどのクラウドプロバイダーに委ねる構成です。
ケース別の推奨
検証目的でまず動きを見たいだけなら、単一プロバイダー・低コストVPSで十分です。顧客との実運用を前提にするなら、フォールバックチェーンとリスクゲートの実装を先行させることをおすすめします。
複数業種・複数店舗のテナントを抱える予定があるなら、最初からマルチテナント対応の設計（テナントごとのCRMデータ・メニュー・価格情報の注入機構）を組み込んでおいたほうが、後からの改修コストを抑えられます。
あえて見送るべき条件
次のような場合は、WhatsApp AIエージェントの本格導入を急がないほうが安全です。
- ツール呼び出しの権限設計にリソースを割けない体制
- LLMプロバイダーのデータ取り扱い方針を確認する余裕がない
- 日付・時間帯のパース処理（多言語での「明後日」表現やタイムゾーン処理）に対応する開発時間が確保できない
- WhatsAppの同一番号での二重ログインなど、プラットフォーム特有の制約を調査する時間がない
特に日付処理は軽視されがちですが、イタリア語の「dopodomani」（明後日）のような表現とタイムゾーン、営業時間の整合を取るだけで数週間を要したという報告もあります。多言語対応や複雑な業務ルールを持つ場合は、この工数を過小評価しないことが肝心です。
まとめ
WhatsApp AIエージェントの導入判断は、プロバイダー冗長化、自律実行のリスクゲート、PII保護、セルフホストかクラウドかの4軸で整理できます。
最初の一歩としては、想定しているツール呼び出しを列挙し、それぞれを低・中・高リスクに分類する作業から始めるのが現実的です。そのうえで使用予定のLLM APIの利用規約でデータ取り扱いを確認し、単一プロバイダーで進めるかフォールバック構成を組むかを決めていく流れがおすすめです。