Meta Muse for ServiceNow対応:2026年にMetaのWhatsApp AIをServiceNowの前面に置く

要点

「Meta Muse for ServiceNow」は、配管の問題ではなく席の問題です。ServiceNowにはすでにMetaと直接やり取りするネイティブのWhatsAppアプリがあるので、チャネル自体は存在します。しかしMetaはWhatsApp番号1つにつきAIエージェント1つしか認めていないため、Meta Business AgentとServiceNow自身のAI(現在はOttoというブランド名)は、同じ番号で両方が応答することはできません。Muse自体は一般消費者向けのエージェントで、Muse Sparkはその上に構築するモデルなので、どちらもそのままでは顧客に応答してくれません。

配管の面は、私が調べてきたほとんどのヘルプデスクより素直です。MetaはすでにServiceNowを2025年に引き継ぎパートナーとして挙げており、管理者がシステムプロパティを1つ切り替えれば、ServiceNowのOAuthクライアント資格情報グラントはMetaのコネクタ認証に合います。ただし、ServiceNowの新しいMCPサーバーはまったく合いません。認可コードフローにしか対応していないため、Metaのエージェントは通常のREST API経由で入る必要があります。

コスト面では、Metaのエージェントは1会話あたり約16〜50セント、ServiceNowはAIをアシスト単位で課金しますが、その単価は公開していません。私はeeselの連携を作っている立場なので先に言っておくと、eeselにはServiceNowのネイティブ連携がありません。私の見立てでは、ServiceNowの導入先の多くは社内ITデスクで、従業員がWhatsAppでメッセージを送ることはないため、この話が関係するのはカスタマーサービスのチームだけです。それに当てはまるなら、eeselがその番号の唯一のAI席を担い、REST API経由でServiceNowに接続できます。

「Meta Muse for ServiceNow」が実際に意味すること

Metaの2026年の名称は整理に少し時間がかかります。私はAPIドキュメントを読むのが仕事ですが、それでもです。Museの名を冠するか、それに近い製品は3つありますが、顧客と話すのはそのうち1つだけです。

1. Muse。Metaが9月に一般消費者向けの用事代行として公開したパーソナルAIエージェントです。企業の顧客に応答するために作られたものではありません。
2. Muse Spark 1.3。Meta Model APIで販売されているモデルです。この上にServiceNowボットを構築することもでき、これは後述します。モデルの詳細はMuse Spark 1.3の概要にあります。
3. Meta Business Agent。Metaが6月にローンチした、WhatsApp、Messenger、Instagramで顧客に応答するAIです。ServiceNowのチームが本当に検討しているのは、この製品です。

3製品の整理は、私のカスタマーサポート向けMeta Museガイドにあります。この記事はServiceNow側に絞り、現在WhatsAppがどうServiceNowに入るか、Metaのエージェントが番号を引き受けると何が起きるか、認証がどう合うか、スタック全体のコストがいくらかを扱います。

別のヘルプデスクをお使いですか?Salesforce版とJira Service Management版が、この記事に最も近い内容です。

Zendesk版とFreshdesk版もあります。

配管の話の前に、正直なふるい分けを1つ。ServiceNowのインスタンスの多くは、従業員向けのITサービス管理を動かしており、従業員はポータル、メール、TeamsやSlackで依頼を出します。あなたのインスタンスがそうなら、依頼者はWhatsAppで連絡してこないので、この記事はほぼ豆知識です。Metaの話が現実味を持つのは、顧客がすでにWhatsAppで暮らしているカスタマーサービス管理(CSM)のチームだけです。

現在WhatsAppはどうServiceNowに届くか

JSMと違い、ServiceNowにはネイティブのWhatsAppチャネルがあり、Metaへ直接つながります。StoreアプリはConversational Integration with WhatsAppという名前で、ServiceNow自身が販売しています。そのStoreの掲載ページには、「WhatsApp Cloud APIとの直接統合のためのネイティブWhatsAppアダプタを提供し、現行のサードパーティ型ソリューションに置き換える」とあります。バージョン1.1.6は2026年9月10日に、Brazil、Australia、Zurich、Yokohamaの各リリース向けに公開されました。

設定の大半はMeta側で行います。ServiceNowのConversational Interfacesドキュメントによると、Meta開発者アプリを作成し、そのApp Secretと電話番号IDをコピーし、Meta Business Managerでシステムユーザーアクセストークンを作成します。その後、Metaのwebhookをあなたのインスタンスの/api/sn_va_whatsapp/va_whatsapp_adapterエンドポイントに向けます。CSMドキュメントはアカウントモデルを簡潔に述べています。「顧客は2つの別々のアカウントを維持する必要があります。Metaアカウントと、ServiceNowインスタンスです。」

選択肢の比較です。すべて2026年9月29日に確認したServiceNow Storeの掲載情報によります。

ServiceNow自身も、いまではTwilioを弱いルートとして扱っています。CSMドキュメントは、Twilio連携は「Cloud APIより機能が限定的」で、リスト選択や入力中表示がなく、アカウントも2つではなく3つ(Twilio、Meta、ServiceNow)を管理することになると述べています。管理者たちは、ライセンスの積み重なりに何年も前から気づいていました。

「それに、integration hub、twilio、whatsappなどのライセンスも必要になる」

u/bigredsage, Reddit

チャットが届くと、応答できるものは2つあります。Otto(ServiceNowがVirtual AgentとNow Assistをリブランドしたもの)がボットとして返信でき、人が必要な場合はチャットがAgent WhatsApp Queueに入り、エージェントがAgent Workspaceの受信箱から受け付けます。Brazilドキュメントの細かい点があとで効いてきます。WhatsAppはOttoに対応していますが、合成応答は「No」とされており、TeamsとSlackは「Yes」です。

CSMには2つ目のモードもあり、ここで重要なのはこちらです。CSMドキュメントは、「バーチャルエージェントによる偏向なしに、メッセージング会話を有人エージェントに直接ルーティングする」直接統合を説明し、「この方式はWhatsAppで利用できます」と付け加えています。これを覚えておいてください。

Meta Business Agentがその番号に加わると何が起きるか

Metaのドキュメントは9月にずっと詳細になりました。WhatsApp番号がすでにServiceNowにつながっている状態でBusiness Agentを有効にすると、次のことが変わります。

エージェントが先に応答し、ServiceNowのアプリはスタンバイに移る

MetaのConversation Routingは、接続された各アプリのうちどれが各メッセージに応答するかを決め、ServiceNowのWhatsAppアダプタもそのアプリの1つです。Business Agentを有効にすると、Metaのルーティング設定ガイドによれば、「エージェントがメッセージングの入口の唯一のプライマリになる」うえ、「以前のプライマリの宛先は、コンテキストを保持するためスタンバイに移る」とのことです。

平たく言えば、新しいWhatsAppメッセージはAgent WhatsApp Queueではなく、まずMetaのエージェントに届きます。入口ごとに振り分けることもでき、たとえばダイレクトメッセージではServiceNowをプライマリのままにし、Click-to-WhatsApp広告はAIが担当する、といった具合です。この設定はMeta Business Suiteでしかできません。「Conversation Routingを設定する公開APIはありません。」

1番号に1つのAI、だからOttoは身を引く必要がある

これがServiceNow構成における本当の判断です。Metaのプラットフォーム概要は、「その番号で他のAIエージェントがすでに動いていない」ことを要件としており、「有効な認可済みエージェント統合はMeta Business Agentをブロックする」ためです。

ただし、何が該当するのかをMetaは正確には書いておらず、ServiceNowのドキュメントもBusiness Agentには一切触れていません。私が前提に置くのは、番号上で応答するOttoは、他のAIエージェントに該当するという読み方です。そうなると、前のセクションで述べた直接モードでServiceNowのWhatsAppアプリを動かし、チャットをボットの段階なしで有人エージェントに直接送ることになり、番号上のAIはMetaのエージェントだけになります。

これは本物のトレードオフです。Ottoはあなたのナレッジベース、カタログアイテム、トピックを知っていますが、Metaのエージェントは読み込ませたものしか知りません。ちなみに、Virtual Agentに対するコミュニティの評価は割れています。

「みんなミニChatGPT/コパイロットのようなものを期待しているけど、僕の経験ではそれとは程遠い。ナレッジ記事、カタログアイテム、バーチャルエージェントのトピックに大きく依存している。」

u/ultraviolencebby, Reddit

うまく動かしているナレッジチームからの妥当な反論もあります。「ナレッジから約70〜80%のデフレクション率が出ている」とu/Suspicious-Movie4993は述べています。あなたのOttoの数字がそのくらいなら、WhatsAppの席をMetaに渡すのは後退です。

ServiceNowは名指しされたパートナーだが、引き継ぎのドキュメントは誰も出していない

Business Agentが引き継ぐとき、チャットは同じWhatsAppスレッドに残り、所有権だけが番号上の別のアプリに移ります。Metaのカスタマーサポートガイドは前提条件として「引き継がれた会話のための、人員が配置された宛先」を挙げ、単純な引き継ぎは、thread controlドキュメントによれば、あなたが「escalation partner」に設定したアプリに渡ります。

ここではServiceNowが一歩リードしています。Metaが2025年10月にBusiness AIを発表したとき(Business Agentの以前の名称)、引き継ぎについて「Salesforce、Microsoft Dynamics 365 Contact Center、ServiceNow、Zendesk、Gorgias、Klaviyo Serviceを含む主要プラットフォームと積極的に提携している」と書いていました。AtlassianやFreshworksより多い顔ぶれです。

しかしその後、足取りは途絶えます。6月のローンチ発表には「Shopify、Zendesk、Shopee」とあり、ServiceNowはなく、ServiceNowのドキュメントにはBusiness Agent、引き継ぎ、conversation routingへの言及がまったくありません。そのセットアップは1つのWhatsApp電話番号IDを1つのチャネルIDに対応づけるもので、番号の共有については何も述べていません。Metaのルーティングドキュメントによれば、引き継ぎはServiceNowのアダプタに通常の受信会話として届くはずですが、それでも顧客の目に触れる前に予備の番号でテストします。

奇妙なことに、MetaにおけるServiceNowとのつながりは1人の人物です。9月28日に発表されたMetaの新しいEnterprise Platformを率いるCJ Desai氏は、「ServiceNowに8年近く在籍し、PresidentおよびCOOも務めた」人物です。

引き継ぎについて、ほかにも知っておくべき点があります。

• コンテキストは2,000文字のメモで運ばれます。 引き継ぎイベントには自由記述のmetadataフィールドがあり、Metaは「チケットや注文の参照を運ぶ」ために使うよう勧めています。アダプタがこれを読むとは、ServiceNowのドキュメントのどこにも書かれていません。
• トリガーは制御できません。 引き継ぎは、確信度が低い場合、整合性の問題がある場合、顧客が人間を求めた場合に発動し、Metaの機能ページによれば「トリガーは設定できません」。良い引き継ぎがどういうものかは、私のAIエージェントの引き継ぎガイドで扱っています。
• 24時間ウィンドウは引き続き適用されます。 ServiceNowのCSMドキュメントによれば、エージェントが開始するメッセージは「顧客の最後のメッセージから24時間以内」でなければなりません。午前2時の引き継ぎが翌日午前10時まで置かれるのは問題ありませんが、2日後に拾われたものは死んだスレッドです。
• 顧客の連絡先には通知が届きません。 ドキュメントには「消費者と顧客の連絡先はゲストとして扱われ、メッセージングチャネルで通知を受け取れません」とあります。つまりCSMの顧客は、ケースが更新されてもWhatsAppの通知を受け取れません。受け取れるのはユーザーアカウントを持つ従業員だけです。

MetaのエージェントをServiceNowのAPIにつなぐ:認証は合い、MCPサーバーは合わない

Business Agentは、コネクタ、つまり自分で定義するHTTP APIやリモートMCPサーバーを通じてアクションを実行します。Metaのコネクタ リファレンスには、「現在サポートされているのはOAUTH2_CLIENT_CREDENTIALS、API_KEY、NONEのみです」とあります。この構成のFreshdesk版とGorgias版が行き詰まったのはまさにこの一文のところで、どちらもBasic認証を求めるからです。

ServiceNowには2つのきれいな入り口があり、どちらもWashington DCリリースで登場しました。

• OAuthクライアント資格情報。 ServiceNowのKB1645212にはこうあります。「Washington DCリリース以降、ServiceNowは受信OAuthリクエストに対してClient Credentialsグラントタイプをサポートします。」これは「デフォルトで無効」なので、管理者がシステムプロパティglide.oauth.inbound.client.credential.grant_type.enabledを作成してtrueに設定します。これを使うすべてのアプリは、OAuth Application Userフィールドで「統合ユーザーにマップされている必要があり」、トークンは/oauth_token.doから発行されます。これはMetaのOAUTH2_CLIENT_CREDENTIALSタイプが想定する内容と一致します。
• REST APIキー。 ServiceNowのデベロッパーアドボケイトChuck Tomasi氏が同じリリースで受信APIキーを発表しました。キーはx-sn-apikeyヘッダーに入れ、選んだユーザーとして実行されます。MetaのAPI_KEY設定ではヘッダーのフィールド名を指定できるため、こちらも対応づけられます。

合わないルートが2つあります。長年のデフォルトだったBasic認証はMetaが非対応としており、ServiceNowのMCPサーバーは現状Metaのコネクタになれません。ServiceNowのMCP Server Console FAQは、「すべての接続の認証にAuthorization Code GrantによるOAuth 2.0を使う」とし、クライアント資格情報は「現在MCP Server Console接続ではサポートされていません。製品ロードマップにあります」と述べています。Metaのコネクタは認可コードフローを完了できないため、ServiceNowへの新しいAIの入り口は、当面閉じたままです。このサーバーがClaudeのようなクライアントに何をするかは、私のServiceNow MCP連携の記事で扱っています。

定義することになるツールと、3つの落とし穴

認証が片づけば、コネクタは数本のREST呼び出しに収まります。Meta自身の例はcreate_support_ticketツールで、その要約はエージェントがチャットから埋め、マクロを使えばWhatsApp電話番号と会話IDをフィールドに紐づけて、エージェントが推測しなくて済むようにできます。ServiceNowに当てはめると次のようになります。

1. レコードを作成する。 ITデスクならTable APIのPOST /api/now/table/incident、カスタマーサービスならCSM Case APIのPOST /api/sn_customerservice/caseを使います。
2. ステータスを照会する。 ケースへのGETで、エージェントは引き継ぎなしで「修理の進捗は?」に答えられます。
3. 顧客に見える更新を追加する。 work_notesではなくcommentsに書き込みます。Case APIリファレンスによれば、外部の顧客ロールはデフォルトで「commentsとstateフィールドしか設定できず」、work notesは内部用フィールドです。

落とし穴はすべてServiceNow自身のページに書かれています。

• Case APIは間違いを教えてくれません。 「パラメータの検証を行わない」ため、フィールド名のスペルミスは黙って捨てられます。Metaのツールテスト実行エンドポイントを使い、200だけでなくレコードも確認してください。
• WhatsAppのチャネル値はありません。 Case APIのcontact_typeは、chat、email、phone、social、webを受け付けます。1つを選び、送信元は別の場所にタグ付けしないと、レポート上でWhatsAppがWebチャットと一緒くたになります。
• レート制限は429として返ります。 KB3046852は、管理者が定義するレート制限ルール、ノードの過負荷、トランザクションあたり300秒の上限を挙げています。月曜朝のスパイク中に盲目的にリトライするコネクタは、状況を悪化させるだけです。

Metaは自社ガイドで、サイレント失敗のリスクを指摘しています。「失敗したチケットは目に見えません。エージェントはすでに同僚から連絡が行くと伝えてしまっており、買い物客は待ち、もう一度、より腹を立てて連絡してくるまで誰も気づきません。」不正なフィールドを無視するCase APIでは、この警告は二重に当てはまります。

コスト:Meta Business AgentとServiceNow自身のAIの比較

ServiceNowはこれらのどれについてもドル金額を公開していないため、比較はぎこちなくなります。

1つだけServiceNowに有利な数字があります。2026年4月のライセンス変更に関するServiceNow Communityの記事は、Virtual Agentが新しいITSMティアで「無制限の会話を持つようになった」と述べています。つまり従来型のトピックベースのボットはカバーされており、アシストを消費するのはLLMを使うNow Assistのトピックだけです。

Metaのエージェントは、今日スプレッドシートに入れられる価格を持つ唯一の行ですが、Business Agentの初期ユーザーは、その価格がいかに早く積み上がるかに気づきました。

「懸念は、メッセージ1件あたりのコストがとんでもなく高く、約5セントもすることだ。」

u/Aromatic-Surround167, Reddit

ServiceNow側の痛みは、単価ではなくバンドルにあります。あるCSM管理者は更新についてこう述べています。「AIスターターパック付きでCSM Pro Plusを25席持っていた。それを50席に増やした。CSM Proでは全体で900席を維持している。新しいモデルは?すべての席が同じタイプでなければならない」、とu/12_barrelmonkeysは述べています。さらに詳しくは、私のServiceNow AIの料金の内訳とライセンスタイプのガイドをご覧ください。

10月1日に影響を受けるのはAIではなく、エージェントの返信

WhatsAppを使うServiceNowチームの多くは、AIの価格とは別の変化を感じることになります。2026年10月1日から、Metaは電話番号ごとに月1,000件の無料枠を超えたサービスメッセージをメッセージ単位で課金します。Metaの料金ページは、各メッセージは「Meta Business Agentメッセージとして、または_サービスメッセージとして_のどちらかで課金され、両方に課金されることはありません」としています。

ServiceNowのネイティブアプリはあなた自身のMetaアカウントで動くため、こうしたサービスメッセージ料金はMetaの請求書に直接乗り、間でそれを吸収したり上乗せしたりするBSPはいません。引き継ぎ後にエージェントがAgent Workspaceから送る返信は、すべて1件として数えられます。Metaのエージェントを選んでもこれは避けられず、最初の数件の返信を誰が書くかが変わるだけです。料金の変遷は私のWhatsApp API料金の解説にすべてあり、Metaがサードパーティボットに何をしたかはMetaのポリシー変更の記事で扱っています。

Muse Sparkで自前のServiceNowボットを作る

3つ目のルートはBusiness Agentを飛ばして、モデルの上に直接構築するものです。私の本業に最も近いので、実際に何が必要かを書きます。

モデル側では、Muse Spark 1.3は標準ティアで100万トークンあたり入力1.25ドル、出力4.25ドルです(Meta Model APIドキュメント)。より安いコントリビューターティアは、サポート用途では使えません。Metaの利用規約に「Discounted Servicesに機密情報、秘密情報、個人情報を送信してはならない」とあるからです。ServiceNowのケースには氏名やメールアドレス、アカウント番号が含まれます。モデルの強みは私のMuse Spark 1.3レビューで扱っています。

ServiceNow側では、残りはすべて自前です。

1. WhatsApp側。 ServiceNowのアダプタが番号のwebhookを持っているので、自作ボットはそれを置き換えるか、Custom Chat Integrationの背後に置くことになります。どちらも週末でできる作業ではありません。
2. 認証。 専用の統合ユーザーとスコープを絞ったAPI認証スコープによるクライアント資格情報で、30分ごとに更新します。正直、ここは簡単な部分です。
3. ナレッジ。 ナレッジ記事、カタログアイテム、解決済みケースを、Table APIで同期し続けます。
4. ループ。 ケースを読み、コメントまたはwork noteの下書きを作り、カテゴリと担当グループを設定します。最初のバージョンでは、work noteだけを書くようにして出すのがよいでしょう。そうすれば、人を通さずに顧客へ届くものは何もありません。
5. エスカレーションとテスト。 独自の確信度しきい値と、本番前に実際のケースを再生するテストです。完全なリストは私の自作か購入かガイドにあります。

2026年のあるスレッドは、ServiceNow自身のスタック内であっても、どんなバグを抱え込むことになるかを示しています。ある管理者のカスタムエージェントは、AI Agent Studioでは問題なく動き、WhatsAppチャネルでだけ壊れました。

「AI Agent StudioでAI Agentを直接テストすると正しく動作する。実行プランが作成され、Work Order Agentが実行できる。しかし、同じAI AgentをWhatsAppから呼び出すと、正しく実行されない。」

u/Affectionate_Bet971, Reddit

スレッド内の返信によれば、原因はおそらく、WhatsAppチャネルが管理者セッションとは異なるユーザーコンテキストで動いており、エージェントに必要なロールがないことです。同じユーザーコンテキストの問題は、あなたが作るどのボットにも当てはまります。ほかのモデルについては、ServiceNow向けChatGPT、ServiceNow向けClaude、ServiceNow向けGrokで同様に扱っています。

ServiceNowチームにとってMetaのエージェントが止まるところ

これらはどれも隠されておらず、すべてMeta自身のドキュメントにありますが、ServiceNowチームにはより重くのしかかります。

• Metaのアプリの中でしか応答しません。 あなたのインスタンスは、ポータル、メール、Teams、Slackも受け付けます。Business Agentはそのどれもカバーしないので、2つのルールセットを持つ2つのAIを動かすことになります。これらのチャネルは、私のServiceNowチャットボットの記事で扱っています。
• ケース履歴はナレッジソースになりません。 Metaのサポートガイドは「直近四半期のヘルプデスクの主な問い合わせ要因をエクスポートする」よう勧め、FAQエントリを手で書くよう言っています。ナレッジベースと何年分もの解決済みケースは、手の届かないままです。
• あなたの構造を知りません。 ServiceNowの価値は構造にあります。カテゴリ、担当グループ、SLA、承認、CMDBです。Metaのエージェントが見るのはチャットであってケースではなく、コネクタが教えない限りそのままです。
• 規制業種は対象外です。 金融、医療、政府、酒類、ギャンブルの事業者は、Platformを利用できません。
• 正確性には依然としてグラウンディングが必要です。 Metaのヘルプセンターは「一部のAIメッセージは不正確または不適切な場合があります」と警告しています。

r/WhatsappBusinessAPIのあるコメンターは、その境界をうまく言い表しました。

「現在のAIエージェントをよく見ると、Metaの中のことしかできず、外のことは何もできない。」

u/Ok_West333, Reddit

ServiceNowチームに残したい捉え直しはこれです。Metaのエージェントは、WhatsAppの玄関口です。仕事が実際にあるのはServiceNowで、元が取れるAIとは、そこで読み書きできるAIです。

あなたのServiceNowチームに合う構成

誰が連絡してくるか、チームがどう働いているかに応じて、私ならこう選びます。

ServiceNowチームの多くは最初の行にいて、WhatsAppの問題はそもそも浮上しません。CSMチームなら、2行目と4行目に時間を使うでしょう。インスタンス自体に使うAIツールを比較しているなら、私のServiceNowに最適なAIのまとめとServiceNowにAIを追加するガイドが次に読むのに向いています。

Ottoを見直したいならServiceNow Virtual Agentの代替のリストが役に立ち、ヘルプデスク横断のWhatsAppはWhatsAppサポートに最適なAIで扱っています。

ServiceNowのWhatsApp向けにeeselを試す

まず率直な答えを。eeselにはServiceNowのネイティブ連携がありません。設定画面で気づくより、私の口から聞いてもらうほうがいいと思います。あるのは、この構成が本当に必要とする2つの要素です。

eeselは、WhatsAppで自ら応答するAIヘルプデスクのチームメイトなので、Metaのエージェントの代わりにも、Ottoの代わりにも、その番号の唯一のAI席に座れます。ServiceNowへはNetwork Accessを通じて接続します。インスタンスのドメインを許可し、ServiceNow APIキー用のx-sn-apikeyヘッダーを追加すれば、エージェントはREST API経由でケースを作成し、ステータスを読み、コメントを投稿できます。認証情報はヘッダーとして保存され、AIには表示されません。またAction Permissionsで各書き込みを「ask」に設定すれば、人が先に承認します。

ヘルプセンターや過去の会話から学び、どのリクエストに触れてよいかについての自然言語の指示に従います。料金は月額固定のクレジットプランで、チャットは返信が何回あっても1クレジットと数えるため、アシストの計算はありません。

スクリプトで扱いたいなら、eesel CLIで、あなた、またはClaude CodeやCursorのようなコーディングエージェントが、ターミナルからeesel statusを確認し、eesel activityを読み、eesel approvalsを片づけられます。対象はダッシュボードで設定するのと同じチームメイトです。ServiceNowのフローからのwebhookで、ケースが変わったときにそれを起動できます。

eeselを試すなら、100クレジット付きでカード不要の無料です。10月1日の料金変更が始まる前に、WhatsAppの会話をどう扱うかを確かめてください。