サポートチケットのトリアージにMeta Museは使える？MetaのWhatsApp AIが振り分けるものと、2026年に自前で作るもの

「サポートチケットのトリアージにおけるMeta Muse」の本当の意味

私はeeselで連携機能を作っており、たいていは他社のAPIを丁寧に読み込んで、マーケティングの言葉が途切れるところを探す作業です。トリアージでは、そのギャップが最も大きくなりがちです。誰もが「AIがチケットを振り分けます」と言いますが、ドキュメントを開いて優先度を保存するフィールドを探しても見つかりません。この記事では、Metaのドキュメントをそういう読み方で確認しました。

まず名前の整理です。「Meta Muse」は3つの異なる製品を指し得ますが、チケットトリアージに関係するのはそのうち2つだけです。

Metaは「more than one million businesses are already using a Meta Business Agent on WhatsApp and Messenger」と述べています（Meta Newsroom）。Meta Business SuiteとWhatsApp Businessアプリの中にセルフサービス版があり、WhatsApp Business Platform APIを使う企業向けにはMeta Business Agent Platformがあります。背後にあるモデルはMetaから公表されていません。

製品全体の内訳は、私のガイドカスタマーサポート向けMeta Museをご覧ください。

5つのトリアージ作業と、それぞれの担当

サポートチケットのトリアージを突き詰めると、5つの作業になります。言語を判別する、カテゴリを選ぶ、優先度を設定する、適切なチームに送る、誰かが対応するチケットを作成する、です。Metaのスタックがそれぞれをどう扱うかを見ていきます。

言語がいちばん簡単なので、そこから始めます。

言語：自動だが、報告はされない

Metaははっきり述べています。「Meta Business Agent handles language automatically. There is no language setting to configure」（Capabilities）。「Detects the language of each customer WhatsApp message and responds in the same language」とあり、判断がつかないときは事業のプライマリ言語にフォールバックし、ナレッジソースは元の言語のまま読み込みます。Meta自身の但し書きは「English has the strongest response quality.」です。

トリアージで問題になるのは、検出された言語がエージェントの外に出ないことです。私が読んだWebhookやコネクタのページには、言語コードを公開しているものがありませんでした。スペイン語のチケットをスペイン語対応チームに回したいなら、自分のシステムでもう一度言語を検出する必要があります。選択肢については、私のガイドAIは多言語サポートに対応できるかで扱っています。

カテゴリ：自分のツール経由でのみ

Meta Business Agentは、コネクタを通じてアクションを実行できます。コネクタとは、自分のAPIに対して定義するHTTPツールです。Metaのカスタマーサポートエージェントガイドでは create_support_ticket というツールが紹介されており、Metaのドキュメント全体で、これがトリアージに最も近いものです。その説明はエージェントにこう指示しています。「Call this for damage, missing items, payment disputes, refund decisions, and anything the documented policies do not cover.」ボディには4つのフィールドがあります。

• category：「One of: damage, missing_item, payment, refund_request, product_fault, other.」
• summary：「A short summary of what the shopper reported, in their own words where possible.」
• order_id：「The related order, when the shopper is asking about one.」
• customer_phone：WhatsAppの番号から自動で入力されます。

これはチケット分類の構成として悪くありませんが、注意点が2つあります。1つ目は、これはMetaの機能ではなく、コピーして自分のエンドポイントに向ける例だということです。2つ目は、許可される値を強制するものが何もないことです。コネクタのフィールドは「string」「integer」「number」「boolean」のみで（Connector tools）、ページに「enum」は登場しません。カテゴリのリストはフィールドの説明文にプレーンテキストとして書かれているだけなので、リストにないカテゴリはエンドポイント側で拒否する必要があります。

優先度：そもそも存在しない

この記事のために、Metaのすべてのページで「priority」と「urgent」を検索しました。ルーティングのドキュメント、エージェント設定、コネクタのリファレンス、サポートガイドのどこにも優先度や緊急度のフィールドは定義されておらず、サンプルのチケットツールにもありません。自分のツールに priority 文字列を追加して説明文にルールを書くか、カテゴリと注文金額からエンドポイントで計算することになります。どちらを選んでも、ルールを書くのは自分です。ゼロから書くなら、AIによるチケットの優先度付けの記事に出発点となるルールセットがあります。

WhatsApp Conversation Routingが実際に振り分けるもの

この部分は多くの人が誤解しますし、私も最初に読んだときはそうでした。MetaはWhatsApp向けにConversation Routingを公開しましたが、「ルーティング」という言葉はトリアージのように聞こえます。実際は違います。

Metaは「each inbound message to a single responder based on the message's entry point」で受信メッセージを1つの応答者に割り当て、エントリーポイントを「the context in which the WhatsApp user's message arrives」と定義しています（Overview）。エントリーポイントは5つあります。通常のメッセージ（Service、デフォルト）、Click-to-WhatsApp広告への返信、ユーティリティテンプレートへの返信、マーケティングテンプレートへの返信、着信通話です。「Each entry point maps to exactly one responder」（Entry points and routing）。そしてスレッドに所有者が決まると、「the message is delivered to the current owner regardless of its entry point.」となります。

このダイアログが設定のすべてです。「返金の問い合わせ」や「VIP顧客」といった行はありません。壊れた製品について苦情を言う顧客と、営業時間を尋ねる顧客は、どちらも「Customer sends a message」として届くため、同じ応答者に送られます。

作れるものを左右するルールがさらに3つあります。

1. アカウントごとにエスカレーションパートナーは1つ。 エスカレーションパートナーは「can take control of any thread, regardless of who currently owns it. Each account has at most one escalation partner」です（Overview）。請求チームと技術チームが別々のアプリにいて、両方がエスカレーション先になることはできません。
2. 引き継ぎの対象はチームではなくロール。 ターゲット指定のパスでは、target_role を ai_agent、ctwa、customer_service、escalation、marketing、utility のいずれかに設定します（Thread control）。これらは部署ではなくエントリーポイントに対応しています。
3. 設定はUIのみ。 「There is no public API for configuring Conversation Routing」（Get started）。Business Agentを有効にすると「the sole primary for messaging entry points」になり、それまでのプライマリ（多くの場合ヘルプデスク）はスタンバイに移ります。Zendesk環境でこれが何を意味するかは、私の記事Zendesk向けMeta Museで書きました。

実際には、ヘルプデスクをエスカレーションパートナーにして、チームへの振り分けはそこで行います。ヘルプデスク内のインテリジェントルーティングはそのためのもので、FreshdeskでWhatsAppチケットをグループへ振り分ける場合も、Zendeskのトリガーの場合も同じです。

ルーティングのドキュメントが出る前から、開発者たちはまさにこれを求めていました。

"Is there anything in the WhatsApp Business Platform that supports this natively ; a queue, an agent assignment concept, a way to mark a conversation as "human handling now" so my webhook knows not to auto-reply, or any equivalent of the Messenger handover protocol (primary and secondary receiver apps) for WhatsApp?"

u/_Udara27、Redditのr/WhatsappBusinessAPI

Conversation Routingは、この質問のうち引き継ぎの半分には答えてくれます。キューと担当割り当ての半分については、今もまだ何もありません。

エスカレーション：何が引き継ぎのきっかけになるか

エスカレーションは、Metaが代わりに決めてくれる唯一のトリアージ判断です。同時に、いちばん制御できない判断でもあります。

組み込みのトリガーは固定です。「the agent starts a handoff automatically when it detects a signal such as low confidence, an integrity violation, or a customer asking for a human. You do not configure the triggers」（Capabilities）。Agent Settings APIでは handoff.enabled、引き継ぎメッセージ、フォローアップタイマーは設定できますが、しきい値やルールのフィールドはありません。

独自のトリガーはインストラクションに書きます。Metaのサポートガイドもそれを明確に推奨しています。「Enumerate the escalation triggers rather than describing them. 'Escalate when appropriate' is not an instruction an agent can follow consistently.」その例では、「when the shopper reports damage or a missing item, disputes a payment, asks for a refund decision, mentions a legal or safety issue, or asks twice for a person」に引き継ぎます。これはAIエスカレーションのどんな構成にも通用する助言です。ただ、Metaの購入後ガイドの次の一文は壁に貼っておく価値があります。「Telling the agent to escalate does nothing on its own. Configure the handoff policy in agent settings and implement thread control.」

引き継ぎとともに届くもの

スレッドがヘルプデスクに渡るとき、2つのものが一緒に届く場合があります。

• metadata 文字列：「Free-form string, maximum 2,000 characters, forwarded verbatim to the receiving app」（Thread control）。Metaのガイドは、これを「to carry the ticket or order reference」に使うことを提案しており、例として "Ticket MF-T-40917, damaged glass shade" を挙げています。
• conversation_context 内のAI要約。Metaは「Identifiers and amounts are preserved verbatim」「Open items are framed as unresolved」と述べており、引き継ぐ担当者には役立ちます。ただし同時に、summary.text は「human-readable prose, not structured data」として扱い、「not parse it for fields」とも書いています（Conversation context）。

得られるのは、人が読むためのチケット要約であって、振り分けに使える理由コードではありません。エスカレーションされたチケットにカテゴリと優先度がヘルプデスクで必要なら、それらは引き継ぎイベントではなく、create_support_ticket の呼び出しから来る必要があります。また「no endpoint that reports which responder currently owns a thread」なので、自分のシステムが引き継ぎイベントから所有者を自力で追跡しなければなりません。

セルフサービス版はよりシンプルで、より手作業

Business Suiteのセルフサービス版では、トリアージはさらに軽いものです。「assign conversations in Inbox to different people」（Assign conversations）ができ、ラベルを「by category, topic or importance」で付けられます（Labels）が、どちらも手動です。エージェントは独自に「Meta Business Agent Responding」と「Meta Business Agent Transferred」というラベルを追加します（Manage responses）。

受信トレイの自動化は「up to 5 specific keywords or phrases」に一致し、「keywords are case-sensitive, and an automated message will not be sent unless the keywords match exactly」です（Inbox automations）。Metaはまた、Business Agentを有効にすると既存の自動化が一時停止し、手動で返信するとそのチャットではエージェントが「after 7 days of inactivity」まで一時停止すると述べています。自動ラベル付け、ラウンドロビン、チームキューはありません。WhatsAppを2人で対応する店なら耐えられますが、10人のチームではスプレッドシートが必要になる未来が見えています。

自前で作るトリアージパイプライン

部品を組み合わせると、Meta Business Agentの上に載せるトリアージはこうなります。

1. 実際のカテゴリで create_support_ticket を定義する。 リストは短く、互いに重ならないようにします。重複する20個より、ヘルプデスクのチケットフィールドに合った6〜10個のほうが優れています。私のトリアージ用プロンプトテンプレートは、説明文を書く際の出発点になります。
2. インストラクションでエスカレーションのトリガーを列挙する。 Metaのガイドと同じやり方で、ツールが毎回同じ状況で呼び出されるようにします。
3. エンドポイントで検証する。 未知のカテゴリは拒否し、自分のルールで優先度を追加し、WhatsAppの会話IDを添えて適切なヘルプデスクのグループにチケットを書き込みます。
4. Business Suiteでヘルプデスクをエスカレーションパートナーにする。 スレッドの人間側が、チケットのある場所に届くようにします。
5. コネクタの失敗を監視する。 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.」コネクタのログは「the last seven days」分しかないため、エラーの日次アラートを設定してください。

Muse Sparkを分類器として使う

エージェントの外で分類したい場合、たとえばスタンバイWebhook経由で取得したすべてのWhatsAppメッセージを分類したい場合は、Muse Spark APIが使えます。response_format による構造化出力は「the response is always constrained to your JSON Schema」を意味し（Structured output）、どのチケットも {category, priority, language} という同じ形で返ります。コネクタのフィールドと違い、JSON Schemaには本物のenumを持たせられます。ただしMetaの但し書きは変わりません。入力を正しく読んだことではなく、形だけを「guarantees the shape, not that the model read」です（Chart analysis cookbook）。

知っておきたい料金ルールが2つあります。安価なコントリビューター向けティアはサポートデータには使えません。「You must not submit sensitive, confidential, or personal information to the Discounted Services」とあるためです（Terms of Service）。したがって標準料金を払うことになり、100万トークンあたり入力1.25ドル、出力4.25ドル、キャッシュされた入力は0.15ドルです（Prompt caching）。カテゴリリストとルールは固定のプレフィックスに置き、その部分がキャッシュされるようにしてください。

トレードオフは、きれいな分類器が手に入る代わりに、スタンバイWebhookと引き継ぎ要約は会話ごとに同時に使えず、同じチャットを読む2つのAIシステムを自分でホスティングすることになる点です。多くのチームにとって、分類器はチケットのある場所、つまりヘルプデスクに置くのが適切です。

WhatsAppでのチケットトリアージにかかる費用

各レイヤーにそれぞれ料金のメーターがあります。Metaの料金ドキュメントとModel APIのページによると、次のとおりです。

Metaは、エージェントの典型的な1メッセージで2万〜2万5,000トークンを使い、4メッセージのやり取りで約16〜20セント、10メッセージのチャットで40〜50セントになるとしています。多くのチームが見落とすのは2行目です。エスカレーションされたチケットは、まさにチームが何度も返信するものであり、10月1日からは、無料の1,000件を超えるとその1件1件が課金対象のメッセージになります。代理店はすでに気づいています。

"If Meta is gonna charge for every single service message after the first 1000, our clients' bills are gonna be insane."

u/assylzhan09、Redditのr/WhatsappBusinessAPI

料金の推移の全体像は、私のWhatsApp Business API料金の解説にまとめています。

トリアージにおけるMetaのスタックの限界

Metaのために言っておくと、WhatsApp中心の事業にとってBusiness Agentは妥当な入口であり、私はFreshdeskと並べて書き、Gorgiasユーザー向けにも別の記事を書いています。トリアージに限って言えば、私が重視する限界は次のとおりです。

• 優先度がどこにもない。 ルーティングにも、設定にも、サンプルツールにもありません。
• ルーティングは内容を無視する。 エントリーポイントが応答者を決め、エスカレーションパートナーは1つだけです。
• カテゴリは強制されない。 コネクタのフィールドは単なる文字列なので、不正な値がそのままエンドポイントに届きます。
• 1番号につきAIは1つ。 「An active authorized-agent integration blocks Meta Business Agent」（概要）とあるため、Metaのエージェントとトリアージ用AIを応答者として並べて動かすことはできません。Metaのより広い方針は、サードパーティAIに関するMetaのポリシーにあります。
• Metaのアプリしか見えない。 同じ注文についてメールで問い合わせた顧客は、紐付かない2件目のチケットになります。

コネクタが登場する前の初期にエージェントを試したBSPコンサルタントは、ナレッジ、パーソナリティ、オーディエンス、引き継ぎの4つの設定項目を数えました。その評価はこうです。

"Fine for a simple FAQ or catalog bot. But if you want real step-by-step logic, you hit the wall fast."

u/Kira_SENPAI_1、Redditのr/WhatsappBusinessAPI

その後、コネクタが「アクション」の穴を埋めました。それでも、トリアージのロジックは自分で書く必要があります。

トリアージは最初のメッセージで行う必要がある

ここから私が得た教訓は、Metaのドキュメントよりも、eeselの営業の場での会話から来ています。月に約7,000件のチケットを扱うD2Cブランドのカスタマーエクスペリエンス責任者は、本当に必要なのは確信度ベースのルーティングだとチームに伝えました。AIは確信があるときに回答し、確信がないときは人間がすぐに受け取るというものです。月次のアナリティクスレポートが答えとして提案されると、顧客は月次レポートを待ちたくないのだと反論しました。

これがMeta中心の構成のギャップです。エージェントは応答し、文章の要約を添えて引き継ぎ、チケットは自分のツールが埋めたカテゴリだけを持ってヘルプデスクに着きます。優先度、担当チーム、「これで3回目の問い合わせ」というフラグは、後から要約を読んだ人が決めることになります。本当に機能するトリアージは、誰かが返信する前、チケットが開かれた時点で行われます。これがキュー内でのAIによるサポートタグ付けの考え方であり、スパムフィルタリングも同様で、だからこそ私はチケットのある場所でトリアージを行います。

サポートチケットのトリアージにeeselを試す

上で説明した構築作業の多くは、Metaのエージェントが顧客に応答はするものの、チケットを振り分けないために必要になるものです。eeselは逆の端から始まっています。AIヘルプデスクチームメイトとして、WhatsAppに接続し、Zendeskのほか、FreshdeskやGorgias内でも動作します。

Zendeskでは、トリアージのトリガーは「Only on the customer's first message ... when a ticket is opened, before anyone replies」実行されます（eesel Zendeskドキュメント）。チケットにタグを付け、「like status or priority」のフィールドを更新し、「so tags get set correctly」のためにフィールドの選択肢を読み取ります。ルーティングにはヘルプデスク自身の割り当てアクションを使い、「driven by your own instructions, for example low confidence or an angry customer」です（ヘルプデスクのユースケース）。ルールは平易な英語で書きます。Metaのガイドがトリガーの列挙を勧めているのと同じ形ですが、こちらは実際のチケットフィールドを設定します。

私が挙げたい数字は、月約1,000件のEコマース受信トレイでの実トラフィックによる試験から得たものです。トリアージ精度は93%で、スパムは100%を誤検知なしで捕捉しました。この受信トレイでは、チケットの22%がスパムでした。すべてのアクションは、その根拠とともにアクティビティログに表示され、信頼が築けるまでは、どのアクションも自動または承認必須に設定できます。実際のチケットに触れる前に、過去のチケットでeeselを実行し、先月をどうタグ付けして振り分けたかを確認することもできます。

サポートスタックをスクリプトで扱うなら、eesel CLIで、同じチームメイトとワークスペースをターミナルから操作できます。すべてのコマンドはJSONを出力するため、あなた自身やClaude Codeのようなコーディングエージェントが、ダッシュボードを開かずに eesel activity で誤って振り分けられたチケットを確認したり、eesel approvals をレビューしたり、トリアージの自動化を調整したりできます。カスタマーサポートエージェントAPIもあります。

補足です。Metaの「1番号につきAIは1つ」というルールのため、1つのWhatsApp番号ではeeselかMeta Business Agentのどちらかを動かすことになり、両方は使えません。WhatsAppが唯一のチャネルで、1人がすべてのエスカレーションを読むなら、Metaのエージェントに手動ラベルを組み合わせる構成は、手頃で妥当です。チケットがWhatsAppとメールの両方から届き、正しい順序で別々のチームに届く必要があるなら、最初のメッセージでのトリアージのほうが作る手間は少なくて済みます。料金は月額固定のクレジットプランで、チケットまたはチャット1件が1クレジットで、返信が何回になっても変わりません。

eeselを無料で試して、まずは先月のWhatsAppとメールのチケットで実行してみてください。