Jira Service Management向けMeta Muse：MetaのWhatsApp AIをJSMの前段に置く方法(2026年)

要点

「Jira Service Management向けMeta Muse」は、要するにブリッジの問題です。JSMにはWhatsAppのネイティブチャネルがないため、Meta Business AgentはWhatsApp上で応答できても、引き継ぎのたびにJSMのリクエストへ運ぶ第三のアプリが必要になります。Muse自体は一般消費者向けのエージェントで、Muse Sparkは上に構築するモデルなので、どちらもそのままでは顧客に応答しません。

構成は、1つのWhatsApp番号の上に3つの層が載ります。Metaのエージェントが最初に応答し、TicblueのWhatsApp ChannelやAppfireのChat for JSMのようなMarketplaceアプリがエスカレーション先となり、JSMがリクエストを保持します。構築する側にとっての朗報は認証です。OAuthクライアント認証情報を使うAtlassianのサービスアカウントは、Metaのコネクタ認証にほぼぴったり合います。Zendesk、Freshdesk、Zoho Deskではそうはいきませんでした。

コストでは、Metaのエージェントは1会話あたり約16～50セントで、JSMのバーチャルサービスエージェントは月1,000件を超えると支援会話1件あたり$0.30(SlackとTeamsのみ)、CSMのAIエージェントは解決1件あたり$1.00です。私はeeselのインテグレーションを作っており、eeselのJSMコネクタはすでにあるお客様で月5万件超のリクエストを処理しています。私の見立てでは、ほとんどのJSMチームはAIをサービスプロジェクトの隣ではなく内側に置くべきです。eeselはあらゆるチャネルからのJSMリクエストを処理し、返信する前に社内メモを下書きします。

「Jira Service Management向けMeta Muse」が実際に意味するもの

私は毎週の大半を他社のAPIドキュメントの読み込みに費やしていますが、2026年のMetaの名前の付け方は、整理するのに最も時間がかかる部分です。Museの名前を持つか、その近くにあるMeta製品は3つあり、顧客と話すのはそのうち1つだけです。

1. Muse。Metaが9月に、消費者の日常的な用事向けに発表したパーソナルAIエージェントです。企業の顧客に応答するようには作られていません。
2. Muse Spark 1.3。Meta Model APIで販売されているモデルです。これでJSMボットを構築することもでき、後ほど触れます。モデルの詳細はMuse Spark 1.3の概要にあります。
3. Meta Business Agent。Metaが6月にリリースした、WhatsApp、Messenger、Instagram上で顧客に応答するAIです。JSMチームが実際に検討しているのは、この製品です。

3つの区別はカスタマーサポート向けMeta Museのガイドにまとめてあります。この記事はJSM側に絞ります。WhatsAppがそもそもどうやってサービスプロジェクトに入るのか、Metaのエージェントが番号を引き受けると何が起きるのか、認証はどう合うのか、全体でいくらかかるのか、という点です。

別のヘルプデスクをお使いですか？Zendesk向けMeta MuseとFreshdesk向けの記事が対応しています。

Zoho Desk版とHubSpot版もあります。

配管の話に入る前に、1つ言っておくべきことがあります。JSMは2つの異なる用途で使われています。従業員がSlackやTeamsからリクエストを出す社内のITおよびHRサービスデスクと、Atlassianが現在Service Collectionの中でCustomer Service Managementとして販売している社外向けのカスタマーサービスです。JSMプロジェクトが社内ITデスクなら、従業員がWhatsAppで連絡してくることはほぼないので、この記事全体は興味本位の話にすぎません。Metaの問題が現実になるのは、社外の顧客がWhatsAppでメッセージを送ってくる場合だけです。

現在WhatsAppがJira Service Managementに届く仕組み

これが以下すべてを形作る部分です。WhatsAppはJSMのチャネルではありません。Atlassianのリクエストチャネルのドキュメントは「メール、ヘルプセンターとその中のポータル、チャット、カスタマイズ可能なウィジェット」を挙げており、ここでのチャットはSlackを指します。顧客リクエストのページではMicrosoft Teamsが加わります。これがネイティブの全リストです。

Customer Service Managementでもこの溝は埋まりません。AtlassianのCSMのページは、顧客が「Web、チャット、メール、音声、ライブサポートの間をシームレスに移動する」と述べており、通話を文字起こし付きのワークアイテムに変えるVoice AIもあります。WhatsAppは名指しされておらず、AtlassianのCSMドキュメントのどこにもWhatsAppのネイティブチャネルは見つかりませんでした。少なくとも私が見つけられた範囲では、です。

JSMの顧客は何年も前からそれを求めてきました。Atlassian自身のコミュニティフォーラムで、ある管理者はこう書いています。

"I want to integrate our Service Desk with WhatsApp to ensure users can do Password reset from their whatsapp."

Jude, Atlassian Community

ボランティアのCommunity Championによる2024年のスレッドでの定番の回答は、2026年でも正しいままです。"You'll need one of the WhatsApp integration apps available on the Atlassian Marketplace to do this, or develop an integration of your own."

WhatsAppとJSMをつなぐMarketplaceアプリ

Atlassian Marketplaceで見つけた6つのWhatsAppアプリと、2026-09-29時点で掲載されていたインストール数です。どの掲載にもユーザーごとの価格は表示されていなかったため、導入を決める前に各アプリの料金タブを確認してください。

これらの掲載から、Metaの問題に関わる詳細が2つあります。第一に、どれもそれ自体がWhatsApp番号に接続されたアプリで、MetaのCloud APIに直接、またはInfobipのようなプロバイダー経由でつながっています。第二に、そのうち2つはすでに番号上にボットを置いています。TicblueのVirtual Agentは決定木を実行し、Hey WhatsApp Meには自分のOpenAIキーを使うオプションの「AI Concierge」があります。これは覚えておいてください。後でまた出てきます。

アプリがバックグラウンドで静かに解決しているアイデンティティの問題もあります。JSMの顧客APIは「メールアドレスと表示名」から顧客を作成します。WhatsAppのユーザーは電話番号だけを持って現れます。Hey WhatsApp Meのようなアプリは「顧客を自動作成」し、OmniChatは「既存のJSM顧客に電話番号を追加」できるので、本来は自分で作る必要があるマッピングの手順を担っています。

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

Metaのドキュメントは9月にかなり詳しくなりました。すでにこれらのアプリのどれかでWhatsApp番号をJSMにつないでいる場合、その詳細は重要です。

最初に応答し、WhatsAppアプリはスタンバイに移る

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

平たく言えば、新しいWhatsAppメッセージはJSMのキューではなく、まずMetaのエージェントに届きます。エントリポイントごとに分けることもできます。たとえばダイレクトメッセージではJSMアプリをプライマリのままにし、Click-to-WhatsApp広告にAIを置く、といった具合です。この設定はMeta Business Suiteの中でしか行えず、Metaもはっきり述べています。"There is no public API for configuring Conversation Routing."

1番号につきAIは1つ、だからボットを選ぶ

Metaのプラットフォーム概要は適格性のルールを定めています。番号は「その番号ですでに別のAIエージェントを稼働させていない」必要があり、それは「有効な認可済みエージェント連携がMeta Business Agentをブロックする」ためです。

ただし、Metaは何が該当するのかを正確には示していません。私が前提にして計画する読み方は、番号上で独自のボットを動かしているMarketplaceアプリは該当するというものです。その場合、TicblueのVirtual AgentのフローやHey WhatsApp MeのAI Conciergeは先にオフにする必要があります。メッセージをJSMの人間の担当者に渡すだけのシンプルなブリッジアプリなら、スタンバイ兼エスカレーション先として問題ないはずです。

引き継ぎはスレッド経由、そしてAtlassianは名指しのパートナーではない

Business Agentが引き継ぐとき、チャットはMetaの受信箱には移りません。同じWhatsAppスレッドに留まり、所有権だけが番号上の別のアプリに渡ります。Metaのカスタマーサポートガイドは前提条件として「引き継がれた会話のための、人が配置された宛先」を挙げており、スレッド制御のドキュメントによれば、通常の引き継ぎは「エスカレーションパートナー」として設定したアプリに渡ります。

JSMチームにとって、そのパートナーはMarketplaceアプリであり、リクエストを作成するのもそのアプリです。MetaがBusiness AIを発表したとき(Business Agentの以前の名称)、名前が挙がったのは「Salesforce、Microsoft Dynamics 365 Contact Center、ServiceNow、Zendesk、Gorgias、Klaviyo Service」でした。6月のリリース記事では「Shopify、Zendesk、Shopee」が挙がっています。Atlassianはどちらのリストにもありませんし、6つのアプリの掲載のどれもBusiness Agentに触れていません。Metaのルーティングドキュメントによれば、引き継ぎはアプリに通常の会話として届くはずです。だからこそ、本物の顧客が関わる前に、まず予備の番号でテストします。

引き継ぎについて知っておくとよい詳細をいくつか挙げます。

• コンテキストは2,000文字のメモで運ばれます。 引き継ぎイベントには自由記述のmetadataフィールドがあり、Metaは「チケットや注文の参照を運ぶ」ために使うことを勧めています。アプリがそれをJSMリクエストにコピーするかどうかは、アプリベンダー次第です。
• トリガーは制御できません。 引き継ぎは、確信度の低さ、インテグリティの問題、顧客が人を求めたときに発動し、Metaの機能ページによれば"You do not configure the triggers"です。良い引き継ぎがどういうものかは、AIエージェントの引き継ぎのガイドで扱っています。
• Metaは午前2時の引き継ぎについて警告しています。 ガイドにはこうあります。"An agent that hands off at 02:00 into an unstaffed queue produces a worse outcome than one that says when the team is next available and raises a ticket." JSMにはまさにこのためのSLAカレンダーがあり、エージェントに直接リクエストを起票させる根拠になります(次のセクション)。

早期にプラットフォームへアクセスしたBSPコンサルタントは、精度の面を指摘しています。

"Consistency is a problem. I saw the same product come back at two different prices in two replies. If you don't ground it properly, it just makes things up. No third-party connectors yet. CRM, order systems, anything to actually complete a sale - not there yet."

u/Kira_SENPAI_1, Reddit

7月のその投稿以降、コネクタが登場しました。ここから、JSMが意外なほど相性のよい相手だとわかる部分に入ります。

MetaのエージェントをJSM APIにつなぐ：認証は実際に合う

Business Agentはコネクタを通じてアクションを実行します。コネクタとは、自分で定義するHTTP APIまたはリモートMCPサーバーのことです。Metaのコネクタのリファレンスにはこうあります。"Currently, only OAUTH2_CLIENT_CREDENTIALS, API_KEY, and NONE are supported." この1行で、この構成のFreshdesk版とGorgias版は行き詰まりました。どちらもBasic認証を求めるからです。Zoho Deskはリフレッシュトークンのせいで厄介になりました。

Atlassianは違い、その理由はサービスアカウントです。私はこの種のコネクタを仕事で作っているので、調査全体で最もうれしい驚きでした。

• サービスアカウントはOAuth 2.0クライアント認証情報に対応しています。 AtlassianのOAuth認証情報ガイドによれば、client_id、client_secret、grant_type=client_credentialsをhttps://auth.atlassian.com/oauth/tokenにPOSTすると、「60分間有効」なBearerトークンが返ります。これはMetaのOAUTH2_CLIENT_CREDENTIALSタイプが想定するグラントそのもので、トークンURL、クライアントID、シークレット、form-urlencodedのボディを使います。
• サービスアカウントのAPIトークンはBearerが使えます。 Atlassianのサービスアカウントトークンのページには、api.atlassian.comゲートウェイで"You can use Bearer token authentication or basic authentication in the HTTP header"とあり、有効期限は1～365日です。これは、Bearer プレフィックス付きのMetaのAPI_KEYに対応します。
• 5つまで無料です。 Atlassianは組織ごとに「無料のサービスアカウント5つ」を提供しており、Atlassian Guard Standardなら最大250まで、サービスアカウントは「ユーザー数の上限に含まれません」。

合わないのは古い方法です。従来の個人用APIトークンは、AtlassianのAPIトークンのドキュメントによればメールアドレスを使うBasic認証で、MetaはBASICを非対応としています。API_KEYヘッダーにあらかじめエンコードして入れる手もありますが、その場合ボットは実在の人物のアカウントに紐づきます。そしてOAuth 2.0(3LO)アプリは、ローテーションするリフレッシュトークンを伴う認可コード方式のみで、Metaのコネクタにはそれを保存する手段がありません。

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

認証が片づけば、コネクタはリクエストAPIを使った数個のJSM REST呼び出しです。

1. リクエストを作成する。 serviceDeskId、requestTypeId、requestFieldValuesを指定したPOST /rest/servicedeskapi/requestです。Meta自身の例はcreate_support_ticketツールで、その要約をエージェントがチャットから埋めます。またマクロで、WhatsAppの電話番号と会話IDをフィールドに紐づけて、エージェントが推測しないようにできます。
2. ステータスを確認する。 リクエストへのGETで、エージェントは「ノートパソコンの交換について進捗はありますか？」に引き継ぎなしで答えられます。
3. コメントを追加する。 コメントのエンドポイントはpublicのブール値を取ります。顧客に見えるのは公開コメントだけなので、コネクタで意図的に設定する必要があります。

落とし穴は、すべてAtlassianのドキュメントに由来します。

• cloudIdはURLに入れます。 サービスアカウントのトークンはhttps://api.atlassian.com/ex/jira/{cloudId}/...でしか動作せず、yourcompany.atlassian.netでは動きません。コネクタのベースURLにそれを含める必要があります。
• スコープはシビアです。 AtlassianコミュニティのスレッドであるJSMユーザーは、サービスアカウントのトークンでサービスデスクの一覧は取れてもリクエストは取れないことに気づき、Atlassianサポートの回答を共有しています。"For fetching requests, the scope read:user:jira is required." 粒度の細かいJSMスコープに加えてread:user:jiraを見込んでください。
• 顧客はメールで識別されます。 raiseOnBehalfOfは"is not available to Users who have the customer permission only"で、顧客の作成には"Jira Administrator Global permission"が必要です。電話番号しかないWhatsAppユーザーの場合は、サービスアカウントとしてリクエストを起票して番号をフィールドに入れるか、そのマッピングをMarketplaceアプリ側に持たせるかのどちらかです。

RovoのMCPサーバーをMCPコネクタとして使うのはどうでしょうか。AtlassianのMCP認証のドキュメントによれば、管理者がAPIトークン認証を有効にすれば、サービスアカウントのキーをBearerトークンとして受け付けます。ただし、4つのJSMツールはオンコールのアラート用でリクエスト用ではなく、それはClaude for Jira Service Managementの記事で詳しく掘り下げています。サポート用コネクタなら、素直なRESTのほうが単純にすっきりしていると私は思います。

Metaは自社のガイドで、静かな失敗のリスクを指摘しています。"A failed ticket is invisible: the agent has already said a colleague will be in touch, the shopper waits, and nobody finds out until they message again angrier." エージェントに何かを約束させる前に、コネクタのテスト実行エンドポイントを使ってください。

コスト：Meta Business AgentとJSM自身のAI

ここでの比較は少し奇妙になります。3つのAIは同じチャネルで応答しないからです。

目を引くのは2点です。バーチャルサービスエージェントの単位は見た目より広く、Atlassianは会話を「バーチャルサービスエージェントが問題を解決するかエスカレーションするかにかかわらず、インテントに一致した」場合に支援ありと数えます。つまり、エスカレーションされたチャットにも課金されます。そして3つのうち実際にWhatsAppで応答するのはMetaのエージェントだけで、WhatsAppが必要なJSMチームが何度もそこに行き着く理由です。Atlassian側については、Atlassian IntelligenceとRovoの料金の解説とJSMのAIは価値があるかの記事がさらに詳しく扱っています。

Business Agentの初期ユーザーは、メッセージ単位の計算にすぐ気づきました。

"My concern is that the per-message cost is insanely high at approximately 5 cents per message."

u/Aromatic-Surround167, Reddit

その上に乗るMarketplaceアプリも忘れないでください。ブリッジアプリはどれもAtlassian経由でユーザー単位の課金で、50エージェントのプロジェクトなら、AIの請求額を見る前にこの項目を確認する価値があります。

10月1日で担当者の返信の計算が変わる

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

JSMの構成では、担当者がワークアイテムからMarketplaceアプリ経由で送るすべての返信が、番号が無料枠を超えた時点で有料のサービスメッセージになるという意味です。Metaのエージェントを選んでも、これは避けられません。変わるのは最初の数通の返信を誰が書くかだけで、Business Agentのメッセージはトークンとして課金され、引き継ぎ後にチームが送るものはすべてサービスメッセージとして課金されます。アプリベンダーがこれらの料金をどう転嫁するか(自分が所有するMetaアカウントか、InfobipのようなBSPのクレジットか)は、1日より前に尋ねておく価値があります。全体の料金推移はWhatsApp APIの料金の解説に、サードパーティボットに対してMetaが行ったことはMetaのポリシー変更の記事にあります。

Muse Sparkで独自のJSMボットを作る

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

モデル側では、Muse Spark 1.3は標準ティアで100万トークンあたり入力$1.25、出力$4.25です(Meta Model APIのドキュメント)。より安いコントリビューターティアはサポート用途では使えません。Metaの利用規約に"You must not submit sensitive, confidential, or personal information to the Discounted Services."とあるからです。JSMのリクエストは、氏名、メールアドレス、デバイスのシリアル番号だらけです。モデルの強みはMuse Spark 1.3レビューで扱っています。

JSM側では、それ以外はすべて自分の担当です。

1. WhatsAppブリッジ。 メッセージを取り込み、返信を送り出すために、Marketplaceアプリか独自のCloud API連携が引き続き必要です。JSMはそれをしてくれません。
2. 認証。 クライアント認証情報を使うサービスアカウント、ベースURLに組み込んだcloudId、60分ごとのトークン更新です。正直、全体の中で簡単な部分です。
3. ナレッジ。 Confluenceのページ、リクエスト履歴、解決済みコメントを同期し続けます。ここではレート制限がかかります。Atlassianのポイント制の制限は、2026年3月2日からOAuthアプリにも適用されています。
4. ループ。 リクエストを読み、返信か社内コメントを下書きし、リクエストタイプと担当者を設定します。最初のバージョンでは社内コメントだけを書くようにして出荷します。人を介さずに顧客に届くものがないようにするためです。
5. エスカレーションとテスト。 独自の確信度のしきい値と、本番前の実際のリクエストのリプレイです。全体のリストは自作か購入かのガイドにまとめています。

この道を検討するチームを数多く見てきましたが、私のアドバイスはいつも同じです。構築だけでなく、保守も数えてください。他のモデルでの同じ構築は、Grok for Jira Service ManagementとChatGPT for Jira Service Managementで扱っています。

JSMチームにとってMetaのエージェントが止まる場所

どれも隠されておらず、Meta自身のドキュメントに書いてあることですが、チームがJSMで仕事をしているとなおさら響きます。

• Metaのアプリ内でしか応答しません。 JSMプロジェクトはポータル、メール、Slack、Teamsも受け付けます。Business Agentはそのどれもカバーしないので、ルールセットが2つの別々のAIを運用することになります。残りはJSM向けAIチャットボットの記事で扱っています。
• リクエスト履歴はナレッジソースになりません。 Metaのサポートガイドは「直近の四半期のヘルプデスクの主な問い合わせ要因をエクスポート」して、FAQ項目を手で書くよう勧めています。ConfluenceのナレッジベースとJSMの長年の解決済みリクエストは手の届かないままです。
• SLAもリクエストタイプも知りません。 JSMの価値は構造にあります。リクエストタイプ、キュー、SLAの時計、承認です。コネクタで教えない限り、Metaのエージェントに見えるのはチャットであって、サービスプロジェクトではありません。
• 規制業種は対象外です。 金融、医療、政府、酒類、ギャンブルの事業者はプラットフォームを利用できません。
• 精度には引き続き根拠づけが必要です。 Metaのヘルプセンターは警告しています。"Some AI messages may be inaccurate or inappropriate."

r/WhatsappBusinessAPIのあるコメント投稿者が、その境界をうまく言い表していました。

"If you look at the current AI agent closely, it can only do things inside Meta, but nothing outside it."

u/Ok_West333, Reddit

JSMチームに残したい捉え直しは、おおよそそれです。Metaのエージェントは、WhatsAppの玄関口です。仕事が実際に存在するのは、リクエストタイプ、SLA、履歴を備えたJSMで、報酬に値するAIはそこで働くAIです。

JSMチームに合う構成は

リクエスト者がどこから書き込むか、チームがどう働くかに応じて、私ならこう選びます。

私が話すほとんどのJSMチームにとっては、1行目か3行目が当てはまります。WhatsAppがそもそもチャネルではないか、複数あるチャネルの1つにすぎないかのどちらかで、WhatsAppでメッセージを送り、メールでフォローアップし、後でポータルにコメントするリクエスト者には、そのすべてが1つのリクエストにまとまっている必要があります。だから最終的には、Metaの問題よりも、JSM内でのAIの選択のほうが重要になります。

それらを比較するなら、JSMに最適なAIの比較記事とJSMのAIの概要が、次に読むのに向いています。

ツール自体を見直すならJSMの代替のリストが役立ち、ヘルプデスク全般でのWhatsAppについてはWhatsAppサポートに最適なAIが扱っています。

Jira Service Managementでeeselを試す

eeselは、新入社員のようにJira Service Managementに加わる、AIヘルプデスクのチームメイトです。誰かがリクエストを起票またはコメントするとそれを拾い、履歴を読み、関連する課題を調べ、そのうえで報告者に返信し、社内メモを残し、課題を先に進め、担当者を割り当て、またはトリアージ用にラベルを付けます。ヘルプセンター、Confluence、過去のリクエストから学び、どのリクエストに手を出してよいかについての平易な言葉の指示に従います。

すでにJSM上で大規模に稼働しており、Design.comはこれを通じて月5万件超のリクエストを処理し、GridwiseのKim SimpsonはeeselのJSMページでこう述べています。"In the first month, eesel is resolving 73% of our tier 1 requests." eesel自体がWhatsAppでも応答するので、WhatsAppとJSMキューをまとめて1つのAIにしたいなら、Metaのエージェントの代わりに番号の1つだけのAI枠に入れます。料金は月額固定のクレジットプランで、リクエストまたはチャット1件が、返信が何回かかっても1クレジットとして数えられます。

スクリプトで扱いたい場合は、eesel CLIを使えば、自分でも、Claude CodeやCursorのようなコーディングエージェントでも、ダッシュボードで設定するのと同じチームメイトに対して、ターミナルからeesel integrations connect jiraを実行し、eesel statusを確認し、eesel automationsを一覧表示できます。

eeselを試すなら、100クレジットでカード不要、無料です。10月1日のWhatsApp料金変更が始まる前に、JSMのリクエストをどう処理するか確かめてみてください。