Meta Business Agentのカタログトレーニングとウェブサイトトレーニングが内部で実際にどう動いているのか、どのデータソースから情報を引き出しているのか、そしてエージェントを推測任せにしてしまう設定ミスを解説します。
Meta Business Agentのセットアップガイドの多くは、「ウェブサイトを接続しましょう」「カタログをリンクしましょう」と書いて、その2つの手順が自明であるかのように先へ進みます。しかし、この2つはまったく同じ種類の接続ではありません。一方はページを読み取り、そこに書かれている内容をインデックス化します。もう一方は、行と列で構成された構造化フィードを読み取ります。この違いを理解しておくことには意味があります。エージェントがカタログに関する質問にはうまく答えられるのにポリシーに関する質問では的外れになる、あるいはその逆が起きる原因は、たいていここにあるからです。
ここでは、Meta Business Agentにウェブサイトと商品カタログを指定したときに実際に何が起きるのか、そしてそれぞれが実務のどこから崩れやすいのかを見ていきます。
Meta Business Agentは、5つの独立した入力を参照します。過去の会話、ウェブサイトのURL、商品カタログ、直接入力するビジネス情報とFAQ、そしてアップロードしたファイルです。FAQとブランドボイスの側面については、セットアップの完全なガイドとMeta Business Agentをブランドボイスに合わせてトレーニングする方法の解説ですでに取り上げました。この記事で扱うのは、人がFAQの回答を打ち込む場合とは動き方がまったく異なる2つのソース、つまりウェブサイトとカタログです。
エージェントにURLを渡すと、Metaはそのアドレスにあるページをクロールしてインデックス化し、後から回答に使える商品やサービスの詳細を抽出します。これは「エージェントがウェブサイトをライブで読んでいる」というのとは、意味のある違いがあります。顧客が質問するたびにページを開き直しているわけではありません。指定したページをクロールして構築されたインデックスをもとに動いており、これは検索エンジンを支えているのと同じ一般的な仕組みであって、CMSへのライブ参照ではありません。
そこから2つのことが導かれます。
1つ目。リンクしたページ上で公開状態になっているものはすべて、顧客への回答に登場しうるということです。ステージング用のページ、どこかの忘れられたURLに残ったままの古い価格表、noindexタグを付け忘れた社内向けページなどがサイトにある場合、ドメインを指定するとそれらが表に出てくる可能性があります。トップページだけを指定してクローラーが意図した経路から外れないことを祈るのではなく、実際に顧客に読ませたいページをリンクしてください。
2つ目。ライブ接続ではなくインデックスである以上、今日サイトに加えた変更が今日のエージェントの回答に反映されるとは限りません。返品ポリシーを更新したりサービスを終了したりした場合は、更新が自動的に反映されたと決めつけるのではなく、その特定のページに紐づくエージェントのテスト回答をもう一度確認するのが安全です。これは多くのAIトレーニングパイプラインの背後にあるのと同じクロールベースのモデルであり、ウェブサイトのリンクはサイトマップの送信と同じように扱う価値があります。有用ではあるが、即時ではない、ということです。
カタログの接続は、まったく別の仕組みです。そこに至る経路は2つあります。小規模なビジネスであれば、WhatsApp Businessアプリの中で商品名、価格、写真を1件ずつ追加して、手作業でカタログを作成できます。すでに広告を運用していたり大きな在庫を管理していたりするビジネスは、代わりにCommerce Manager経由で構造化フィードを接続するのが一般的で、Metaのコマースプラットフォームが受け付ける形式はCSV、TSV、RSS XML、ATOM XML、または適切な形に整えたGoogle Sheetです。
フィードベースのカタログが機能するには、特定のフィールドが必要です。商品ID、商品名、画像リンク、説明、価格と通貨、商品URL、そして在庫ステータスです。この最後のフィールドは決まった値しか受け付けません。「in stock」(在庫あり)、「out of stock」(在庫切れ)、「preorder」(予約注文)、「available for order」(取り寄せ可能)のいずれかであり、在庫状況を自由記述で書いたものは受け付けられません。
カタログを接続すると、ここでようやく「カタログを読む」ではなく「カタログトレーニング」という名前が意味を持ってきます。顧客が「これの青はありますか」と尋ねたとき、エージェントは在庫を文章で説明しているのではありません。フィードから実際のエントリを、画像、価格、購入リンクごと、商品カードとしてチャットに直接引き出しています。これがMetaの商品レコメンド機能を支えている仕組みであり、一般的なFAQボットにはないWhatsApp BusinessカタログAIならではの機能です。そして、セットアップの他のどの部分よりもここでフィードの正確さが重要になる理由でもあります。カードは正確か、チャット上で目に見えて間違っているかのどちらかであり、テキストの回答のような曖昧な中間地帯が存在しないからです。
この構造化フィードは、AIエージェントの商品カタログを単なる商品リストと分ける要素でもあります。フィードはエージェントが一度読んで終わるものではなく、関連する質問が来るたびに何度でも参照し続けるソースなのです。
カタログで最もよくあるミスは、在庫ステータスのフィールドが古いまま放置されていることです。先週売り切れた商品にフィードがまだ「in stock」と書いていれば、エージェントは自信満々にその商品を勧めます。エージェントから見れば、それはまだ事実だからです。これはAIの問題ではなく同期の問題であり、フィードがデフォルトでほぼリアルタイムに更新されると思い込むのではなく、実際にどれくらいの頻度で更新されているのかを確認する価値があります。
ウェブサイトで最もよくあるミスは、良いFAQ回答のちょうど裏返しです。マーケティング的な表現ばかりで、具体性がまったくないページです。商品が「高品質」だとしか書かれておらず、実際の価格、サイズ、返品期限に一切触れていないウェブページは、エージェントに回答の根拠となる具体的な材料を何も与えません。その結果、エージェントは曖昧な回答になるか、手作業で書いたFAQのほうにより強く依存することになります。リンクしているページに、実際の顧客が尋ねそうな質問への答えが載っていなければ、エージェントがそれを作り出すことはできません。
3つ目は、より見えにくいものです。2つのソースの間で情報が食い違っているケースです。ウェブサイトには何か月も更新していない価格が載っていて、カタログフィードには現在の価格が入っている、あるいはその逆という場合、エージェントにはどちらが正なのかを知る手立てがありません。どちらも信頼するよう指示された、正当な入力だからです。この2つを同期させておくことはMeta Business Agent固有の要件ではなく、単に良い運用習慣というだけですが、AIが両方を読んで、たまたま引き当てたほうから回答するようになると、その重要度は一気に上がります。
エージェントを本番に切り替える前に、組み込みのテストフローを使い、簡単な質問ではなく、顧客が実際に送ってくるようなカタログや商品に関する質問をそのままぶつけてください。返ってきた商品カードの画像がきちんと表示され、正しい価格が付いているかを確認し、在庫切れの商品を少なくとも1つ試して、自信ありげなレコメンドではなく正確な回答が返るかをチェックしてください。ウェブサイトを新しい情報に更新したばかりであれば、その特定のページに紐づく質問をして、回答に変更が反映されているかどうかを、反映済みだと決めつける前に確認してください。どちらのソースからも答えられない質問にエージェントが当たったときの対応については、Meta Business Agentの人間へのハンドオフとエスカレーションの仕組みのガイドをご覧ください。
Metaは、Shopifyやサポートツールといったサードパーティのシステムを、カタログフィードやクロールしたウェブページよりも直接的に接続するための、独立したBusiness Agent Platformも公開しています。これはここで扱ったセットアップとは別のレイヤーであり、Meta Business Agentのロードマップの記事でエンタープライズ向けコネクタ層として説明したものに近い位置づけです。カタログがすでにWhatsApp管理のフィードより構造化された場所にあるなら、確認しておく価値があります。
ここまでの内容はすべて、Metaが自社のエージェントをカタログとウェブサイトでどうトレーニングするかに固有の話です。クロールされたページ、構造化フィード、そしてこちらの都合ではなく自分のスケジュールで更新されるインデックス。自律的に回答するエージェントとしては妥当なトレードオフですが、同時にそれは、自動返信の正確さが、その2つのソースを最後に更新したのがいつかによって決まるということでもあります。
The Chat Quotientは、そもそもインデックスから読み取っていないという点で動き方が異なります。AI返信提案は、依頼したその瞬間に自社のナレッジベースから下書きを生成し、AIエージェントは、別途カタログフィードやクロールの手順を同期させておかなくても、WhatsApp Web内で直接与えたビジネス情報と目標をもとに動きます。カタログをMeta Business Agentに接続したばかりで、同じクロールとインデックスのタイミングに依存しないもう1つのレイヤーが欲しいビジネスにとって、実務上の違いはここにあります。2か所で更新し続けなければならないものが1つ減る、ということです。組み込みCRMとビジュアルパイプラインは、商品に関する質問に答えた後で会話がどこへ向かおうと、その先を引き受けます。返信で終わりにするのではなく、リードをパイプラインの中で追跡していきます。
Meta Business Agentはウェブサイトをリアルタイムで読んでいますか。 いいえ。指定したURLにあるページをクロールしてインデックス化し、顧客の質問ごとにライブページを取得するのではなく、そのインデックスから回答します。ウェブサイトを大きく更新した後は、変更がすぐ反映されていると決めつけず、テスト回答を確認し直してください。
Meta Business Agentのカタログはどのファイル形式に対応していますか。 Commerce Manager経由の構造化フィードは、CSV、TSV、RSS XML、ATOM XML、または適切な形式のGoogle Sheetに対応しています。小規模なビジネスであれば、WhatsApp Businessアプリの中で1件ずつ手作業でカタログを作成することもできます。
なぜエージェントは実際には在庫切れの商品を勧めたのですか。 エージェントはカタログフィードの在庫ステータスのフィールドを信頼します。商品が売り切れた後もそのフィールドが「in stock」のままなら、フィードが更新されるまで、エージェントにはそれ以外を知る手段がありません。
Meta Business Agentにウェブサイトの特定のページを使わせないようにできますか。 最も安全なのは、そもそも参照させたくないページを最初からリンクしないことです。接続したURLで公開状態にあるものはすべて、クロールでインデックス化される候補になるからです。
カタログとウェブサイトのトレーニングがあれば、FAQを書く必要はなくなりますか。 いいえ。直接入力するFAQとビジネス情報は別のデータソースであり、ウェブページや商品フィードでは通常明示されない、具体的なポリシーや手続きに関する質問をカバーするのはこちらです。両者がどう連携するかはセットアップの完全なガイドで解説しています。
Meta Business Agentのカタログトレーニングとウェブサイトトレーニングは、「データを接続する」という同じラベルを付けられた2つの別々の仕組みです。ウェブサイトの接続はクロールとインデックスであり、説明的なコンテンツやポリシーには有効ですが、サイトのライブミラーではありません。カタログの接続は構造化フィードであり、その中の在庫ステータスのフィールドと同じだけしか信頼できません。ビジネスが変わったときに、どちらも自動的に直るわけではありません。そこは一度きりのセットアップ手順ではなく、定期的な運用として組み込む価値がある部分です。
Chrome拡張機能を追加して、ビジネスのWhatsApp会話管理の方法を変革しましょう。
