バグ再現のためのMeta Muse:2026年、MetaのAIはバグ報告に何ができて何ができないのか

「バグ再現のためのMeta Muse」が実際に意味するもの

私はeeselでAIエージェントを作っています。その仕事の中で、デモでは誰も見せない部分が、他人による問題の説明をもとにしたデバッグです。バグ報告は、添付された証拠の質がそのまま質になります。そこで今回はMetaのドキュメントを、顧客のスクリーンショットが各プロダクトのどこまで生き残るかを追う形で読みました。

まず名前の整理です。「Meta Muse」は4つの異なるプロダクトを指し得ますが、そのうち3つがバグ報告のトリアージに関わります。

どのステーションも機能します。どれにもないのはチケットです。つまり、報告、スクリーンショット、エンジニアのメモ、顧客への返信を1か所にまとめておくものです。その部分は自分で配線することになり、バグ報告が行方不明になりやすいのもそこです。

再現可能なバグ報告に必要なもの

Metaのツールを見る前に、目標を具体的にしておくと役立ちます。エンジニアがバグを再現できるのは、手順、顧客の期待と実際に起きたこと、デバイスとOS、アプリのバージョン、スクリーンショットまたは録画、発生頻度がそろっている場合だけです。1つでも欠けると、チケットは質問付きでサポートに戻ります(典型的なテクニカルサポートのループです)。サポートは、すでに離れてしまった顧客のところへ戻らなければなりません。

Meta自身のサンプルのチケットツールを見ると、デフォルトがどれほど不足しているかが分かります。Metaのカスタマーサポートエージェントのガイドにある create_support_ticket ツールのフィールドは4つ、category、summary、order_id、customer_phone です。「荷物が破損して届いた」にはよい形です。しかし「写真をアップロードするとアプリがクラッシュする」では、エンジニアに必要なもののほとんどが欠けています。カテゴリについて同じ指摘をチケットのトリアージの記事でも書きました。

Shopifyの開発者は、これを省いた場合のコストを率直にこう述べています。

"You're not unlucky with the queue, tier one is macro-driven and a bug report that doesn't come with a clean reproduction gets closed with a help doc every time."

u/vladeta, r/shopify on Reddit

これはMetaの落ち度ではありません。ガイドは小売のサポート向けに書かれており、MetaはBusiness Agent向けのテクニカルサポートやバグトリアージのガイドを公開していません。ただ、フィールドは自分で追加する必要があるということです。

ステージ1:Meta Business Agentで報告を集める

Business Agentは入り口です。WhatsAppで応答し、自社APIに対して定義するHTTPツールであるコネクタを通じてアクションを実行できます。バグ報告を集めるには、上記のフィールドを持つツール(仮に report_bug とします)を作り、各フィールドをしっかり説明します。Metaのコネクタツールのリファレンスは、"define the body schema with explicit field types, descriptions, and required fields" と述べ、その理由を "the agent uses this schema to extract the correct values from the conversation" としています。app_version と device を必須にすれば、エージェントにはそれらを尋ねる理由ができます。

Metaのガイドから、ほかにも2行は取り入れる価値があります。1つ目は "Enumerate the escalation triggers rather than describing them." です。ガイド自身の例にも、エスカレーション対象として "Technical faults" がすでに含まれています。2つ目は購入後サポートのガイドにある "Telling the agent to escalate does nothing on its own. Configure the handoff policy in agent settings and implement thread control." です。これは標準的なAIエスカレーションの基本で、バグの疑いがあるケースはエージェントが推測すべきでない場面なので、ここでは特に重要です。

スクリーンショットの問題

ここからが面白いところです。WhatsAppでバグを報告する顧客は、ほぼ必ずスクリーンショットを送り、ときに画面録画を、しばしばどこをタップしたかを説明するボイスメモを送ります。そこで、Business Agentがそれらをどう扱うのかを調べました。

Metaは何も述べていません。Business Agentの開発者向けページ約20ページのうち、顧客の画像、動画、ボイスメモ、ドキュメントをエージェントが読むのか、説明するのか、無視するのか、引き継ぐのかを文書化しているものはありません。最も近い手がかりはすべてテキストを指しています。Agent test エンドポイントの user_msg は "The text content of the test message" で、メディア用のフィールドはなく、APIではスクリーンショットのシナリオをテストすることすらできません。エージェントはUIスキルを通じて画像を送信でき、アップロードするナレッジファイルとして画像を受け付けます。ただし、どちらも顧客が送った画像がどうなるかは教えてくれません。

ファイルをチケットシステムに届けるのも、見た目より難しいです。

• コネクタツールはファイルを運べません。 リクエストボディは "currently only supports application/json" で、パラメータの型は文字列、整数、数値、真偽値のみ、ランタイムマクロ(USER_MESSAGE、WHATSAPP_CONVERSATION_ID、WHATSAPP_MESSAGE_ID など)のどれもメディアIDやURLではありません(Connector tools)。report_bug ツールが送れるのは手順であり、スクリーンショットではありません。
• 引き継ぎ時の要約はテキストのみです。 スレッドがヘルプデスクに渡るとき、conversation_context には "an AI-generated summary of the conversation so far" が入りますが、メディアIDはなく、Metaは "Treat summary.text as human-readable prose, not structured data" と述べています(Conversation context)。要約がスクリーンショットに触れるかどうかすら文書化されていないため、チケット要約としては見かけより弱いものです。
• standby ウェブフックはメディアを運びます。 Business Agentがスレッドを持っている間、アプリは standby フィールドですべての顧客メッセージを受信できます。Metaによれば、画像、ドキュメント、音声、動画のメッセージは "are delivered in standby using the same schema as standard incoming message webhooks" です(Standby webhooks)。standby は "off by default" で、事業者側が許可する必要があります(Standby partners)。standby がヘルプデスクに何をもたらすかは、Meta Muse for Zendesk の記事で解説しています。

落とし穴は最後の2つにあります。要約が送られるのは "The receiving responder is not receiving standby events" の場合のみで、"for a given conversation you receive exactly one" のどちらか1つです。スクリーンショットを残すために standby をオンにすれば、AI要約は諦めることになります。要約に頼るなら、引き継ぎ前に送られた添付ファイルを入手する文書化された方法はありません。

バグ報告なら、私は常に standby を選びます。要約は保存したメッセージから作り直せます。保存しなかったスクリーンショットは、二度と作り直せません。

WhatsAppメディアの時間制限

メディアIDを手に入れても、長くは持ちません。MetaのWhatsApp Cloud APIのメディアに関するドキュメントにある制限は次のとおりです。

ボイスメモは見分けやすく、音声ウェブフックの voice フラグが "a recording made with the WhatsApp client voice recording feature" の場合に true になります。画面録画には専用のタイプがなく、通常の video として届きます。

痛いのは7日間の期限です。金曜に報告され、翌週にトリアージされたバグは、唯一のスクリーンショットを失うことがあります。ウェブフックが届いた時点で各ファイルをダウンロードし、会話IDをキーにしてチケットに添付してください。これは、あらゆるWhatsAppサポート自動化に必要なのに、多くが省いている地味な手順です。

ステージ2:Muse Spark APIでスクリーンショットを再現手順に変える

Metaが最も多くを提供できるのがこのステージです。Muse Spark APIは画像、動画、音声を受け付け、Metaはまさにこの作業に非常に近いレシピを公開しています。

そのレシピが、MetaのError screenshot fix cookbookで、コーディングエージェントのOpenCode内で muse-spark-1.3 を実行します。ステップ2は "Give it the bug report plus a screenshot, and get repro steps" です。実例はcal.comの実際のレイアウトバグで、オンボーディング画面でフッターがテキストフィールドに重なっているというものです。

このスクリーンショットとコードベースから、モデルは、ウィンドウを狭い幅と低い高さにリサイズすることを含む5つの番号付き手順を返し、コンポーネントファイルと行を指摘しました。

Metaは "The mention of both narrow width and short height is the part most readers miss" と述べています。これはまさに顧客が書き留めない詳細であり、スクリーンショットが重要な理由そのものです。このcookbookは、貼っておくべき2つの失敗パターンも記載しています。1つは "The Screenshot Names The Wrong Component" で、ブラウザのクロームがないスクリーンショットで起こり、URLを含めることで解決します。もう1つは "The Model Fixes The Symptom, Not The Root Cause" で、スクリーンショットが1枚しかないときに起こり、関連する画面のスクリーンショットをもう1枚添付することで解決します。どちらも、エスカレーションする前に顧客にもう1枚スクリーンショットを頼む根拠になります。

WhatsAppのバグ報告が運ぶ3種類の証拠について、APIが受け付けるものは次のとおりです。

WhatsApp特有の穴が2つあります。ボイスメモはOGG/Opusで届きますが、モデルの音声入力(MP3またはWAV)もMuse Voice Transcribe(モノラル16ビットWAV)もこの形式を受け付けないため、先に変換が必要です。Metaのドキュメントにはffmpegのコマンドがあります。また動画については、形式以外の制限をMetaは一切公開していないため、信頼する前に自分の録画で試してください。

チケットシステムで使える形で手順を受け取るには、response_format をJSONスキーマに設定します。Metaは "decoding itself is constrained, so the output is guaranteed to conform" と述べており(Structured output)、{action, expected, observed} のフラットな steps[] 配列(他所のJSON modeと同じ発想)は、10階層のネスト制限に十分収まります。Meta自身のチャートcookbookの注意書きもここに当てはまります。それは "guarantees the shape, not that the model read the chart correctly" です。きれいなJSONの再現手順でも、間違っていることはあり得ます。

省けないルールが1つあります。標準ティアを使うことです。Metaの利用規約は "You must not submit sensitive, confidential, or personal information to the Discounted Services" と述べ、機密にしておく必要があるコードもそこには送れないと付け加えています。顧客のスクリーンショットは名前、メールアドレス、口座番号だらけで、手元にある中でも特に機微なサポートデータです。したがってバグ報告は、標準の muse-spark-1.3(100万トークンあたり入力$1.25、出力$4.25)に送ります。そこでは "your prompts and completions are not used to train Meta models" とされています(Pricing and rate limits)。

ステージ3:Muse Codeでコード上で再現する

最後のステージは証明、つまりバグのせいで失敗するテストです。これはコーディングエージェントの得意分野で、Meta自身のMuse Code cookbookにサンプルがあります。サンプルゲームのBastion Breakerには "one planted rule bug" があり、そのテストスイートは最初にそれを示します。test_enemy_shot_does_not_destroy_bricks FAILED です。修正は独自のgit worktree内のサブエージェントで実行されるため、レビューするまで親ブランチには手が加わりません。ハーネスについてはMuse Codeのレビューで扱いました。

取り入れたいパターンは、ステージ2のJSON再現手順をMuse Codeに渡し、まず失敗するテストを、次に修正を頼むことです。失敗するテストは、エンジニアが1分で確認できます。テストのない修正は、diffを添えた推測にすぎません。これはClaude Codeでのデバッグや他のエージェントにも私が勧める助言と同じです。

すでにこのやり方で働いている開発者も、同じことを報告しています。

"In many cases it will have figured out the bug. In many cases it will have produced a small, clean, deterministic reproducer. In my daily work I see these cases. It does help that the bugs that are filed contain a test case and some analysis by the agent."

derdi, Hacker News

Muse Codeのドキュメントからの注意点が2つあります。サンドボックスは初回実行からオンで、フェイルクローズドです。見知らぬ人のバグ報告に基づいてエージェントがコードを実行する場合には望ましい挙動です。そしてMuse Codeには利用上限がありません。同じMuse Sparkのトークンを課金し、3つのバックグラウンドのオブザーバーエージェントがデフォルトで動き、文書化されている唯一の歯止めである --max-model-steps はヘッドレス専用です。詳細はMuse Codeの料金の解説にあります。

Metaのスタックでバグ再現にかかる費用

各ステーションにそれぞれのメーターがあります。

スクリーンショット自体は安く、標準料金で入力が約0.2セントです。高いのは2行目です。バグ報告はやり取りが最も多いチケット(「どのバージョンですか?」「もう1枚スクリーンショットを送れますか?」)で、10月1日以降は、無料の1,000件を超えるとその人による返信の1件1件が課金対象になります。料金の全履歴はWhatsApp Business APIの料金の記事にあります。

バグ再現でMetaのスタックが足りない点

公平に言えば、個々のパーツは優れています。Error screenshot fix cookbookは、モデルベンダーが出したバグ再現のウォークスルーの中でも出来のよいもので、サンドボックス化されたworktree内の失敗するテストは最終ステージの正しい出力です。限界はパーツ同士のつなぎ目にあります。

• Business Agentの顧客メディアの扱いは文書化されていません。 スクリーンショットは見えないものとして計画してください。
• チケットへのファイル経路がありません。 コネクタツールはJSONしか送らないため、スクリーンショットは standby ウェブフックと自前のダウンロードコードを通ることになります。
• standby か要約か、両方は不可です。 証拠を残すか、Metaの要約を得るかを選ぶことになります。
• メディアの7日間の期限。 トリアージが遅いと添付が失われます。
• 1番号につきAIは1つ。 "An active authorized-agent integration blocks Meta Business Agent"(概要)とあるため、同じ番号でBusiness Agentと別のサポートAIを同時に動かすことはできません。Metaのより広い姿勢はサードパーティAIに関するポリシーにあります。
• 3つのプロダクト、3つの請求、3組のログ。 自分で作らない限り、WhatsAppの会話、再現JSON、テスト実行を1つのチケットに結びつけるものはありません。

Metaが手を付けない部分:チケット

ここから私が得る教訓は、Metaのドキュメントというより、eesel自身のサポートキューから来ています。eeselのヘルプデスクチームメイトが扱った中で最も技術的な報告の1つは、現場エンジニアのハードウェア障害でした。EtherCATネットワークでエラーコード6001、3174、5169を出すステージの問題です。エージェントは顧客のPDFマニュアルに対して6回検索し、2つを全文読み、段階的な切り分けテストを含む返信を下書きしました。魔法ではありません。報告、マニュアル、返信がすべて同じチケットにあったから機能したのです。

これがMeta中心の構成の本当の穴です。上のどのステージも機能し得るのに、報告はスクリーンショットのない文章の要約としてヘルプデスクに届き、再現JSONは1つのログに、失敗するテストは別のログにあります。eeselの営業通話でサポートチームは、同じ願いを別の言葉で語ります。つまり「when to pull a real person in」を知っていて、確信がないときは推測せずに黙っているAIです。バグの疑いはまさにそのケースです。証拠が保たれ、適切な人への引き継ぎがあり、誰かが動けるエンジニアリング向けチケットが必要です。それがAIによるエスカレーション対応の核心であり、Metaがあなたに任せている部分です。

顧客の席から見ると、こうなります。

"support responded me by asking build version, my os version, device type - me screenshot all the requested details + manually wrote down in response email so someone can also copy-paste somewhere directly from my email - support responds by asking me to clear my iphone cache(sending me a guide for Android's App data cleaning process)"

n_ary, Hacker News

これは、証拠と会話が切り離されてしまったチケットの顧客側の姿です。そのループの誰も不注意ではありませんでした。ただ、次の人が見る場所に詳細がなかっただけです。

サポートからのバグ報告にeeselを試す

eeselはリレーのチケット側の端から始まります。Zendesk、Freshdesk、Jira Service Managementの中で動くAIヘルプデスクチームメイトです。WhatsAppで応答することもでき、専用のJira Service Management連携もあります。

バグ報告の場合の流れは次のとおりで、どのステップもドキュメントに記載されています。

1. 証拠を読む。 ZendeskとFreshdeskでは "reads up to five images or PDFs per turn"(Zendeskのドキュメント)なので、スクリーンショットは推論の材料に含まれます。制限を正直に言うと、"Videos, zip files and other formats are ignored" のため、画面録画は引き続き人の目が必要です。
2. 足りないものを尋ねる。 ルールは普通の言葉で書きます(「バグをエスカレーションする前に、アプリのバージョン、デバイス、手順を尋ねる」)。次のチケットから適用されます。
3. 重複を確認する。 Jira Service ManagementではJQLでSearch Issuesを実行でき、"so your agent can find related or duplicate issues" です(JSMのドキュメント)。これでエンジニアリングが同じバグを二度再現せずに済みます。Jiraが中心なら、Jira AI agentのガイドとMeta Muse for JSMの記事が連携方法を扱っています。
4. 承認用に課題を作成する。 Create Issueはプロジェクト、要約、説明、担当者、ラベルを設定し、needs-approvalに設定すれば、すべてのエンジニアリングチケットを担当者が承認できます(Actions and approvals)。

もう1つ正直な制限があります。eeselはJira課題にファイルを添付できないため、スクリーンショットはヘルプデスクのチケットに残り、Jira課題がそこへリンクで戻ります。またLinearやGitHub Issuesの既製の連携もありません。エンジニアがそこにいる場合は、Network Accessを使います。許可したREST APIをチームメイトが呼び出せるようにするものです。

エンジニアがもう1つダッシュボードを開きたくない場合は、eesel CLIがターミナルから同じチームメイトを動かします。すべてのコマンドがJSONを出力するので、エンジニアや、Claude CodeやCodexのようなコーディングエージェントが、eesel activity でチームメイトがどのバグ報告をなぜエスカレーションしたかを確認し、eesel approvals approve で保留中のJira課題を承認し、eesel automations enable でエスカレーションルールを調整できます。リポジトリを離れる必要はありません。これは失敗するテストが動くのと同じターミナルであり、バグ報告の2つの半分が出会う場所として悪くありません。自分のツールに組み込みたい場合は、カスタマーサポートエージェントAPIもあります。

Metaの1番号1AIのルールにより、1つのWhatsApp番号では、eeselかBusiness AgentのどちらかをAIとして動かすことになり、両方は使えません。選択肢をもっと広く見たい場合は、私のWhatsAppサポート向けベストAIの一覧をご覧ください。WhatsAppのバグ報告を1人の開発者がすべて読む小規模チームなら、Business Agentに standby ウェブフックとError screenshot fixのレシピを組み合わせる構成は妥当です。報告がWhatsAppとメールから届き、証拠を添えてJiraに届ける必要があるなら、チケットのある場所で動かすほうが保守が少なくて済みます。料金は月額固定のクレジットプランで、500クレジットで$299から、チケットまたはチャット1件が、返信が何回になっても1クレジットです。まず過去のチケットで動かして、先月のバグ報告をどう処理したかを確認できます。

eeselを試す 100クレジット無料、カード不要。