サイト全体を1体に読ませない。MicrosoftがAsk Microsoftを作り直した

自社サイトにAIアシスタントを置くと、最初の版はたいてい動きます。難しいのはその次で、扱う製品が増え、ページが増えるほど、答えるのが遅くなり、内容も雑になります。Microsoftは、自社サイトに置いた案内役「Ask Microsoft」でこの段階を通過し、作り直しの中身と結果を導入事例として公開しました。手がけたのは同社のマーケティングとeコマースの部門で、最初の試作はAzureの製品サイトを担当するチームが作っています。

先に要点を書きます。最初の版は、サイト全体を1体のエージェントに読ませる作りでした。新しい版では、Azure製品・Microsoft 365製品・価格・試用ページという4つの役割にサブエージェントを分け、Ask Microsoftという司令塔がその都度呼び分けます。公表されている結果は4つで、応答の遅さが最大で61%小さくなったこと、人が対応するチャットの総量が最大で70%減ったこと、Azureの製品サイトで試用の開始が16%増えたこと、そしてこのエージェントに触れた顧客はサービスの申し込みへ進む可能性が10倍高い、というものです。

この記事が使うのは、Microsoftが公開している事例ページ1本と、Copilot Studioの公式ドキュメント2本だけです。開発にかかった費用、関わった人数、数値を測った期間と母数、日本語での提供状況は、いずれにも記載がありません。確認日は2026年9月11日です。読みどころは数値そのものではなく、1体で抱えるのをやめる判断をどこで下すかという線引きのほうです。

何が置き換わったのか：1体でサイト全体を抱える作りをやめた

事例ページによれば、Ask Microsoftはmicrosoft.com上に置かれた案内役で、製品の情報探し、価格の確認、技術的な問い合わせに答えます。役割は最初の情報提供にとどまらず、製品の検討そのものを助け、申し込みまで運ぶところまで広がっている、と説明されています。

きっかけとして挙げられているのは、営業担当への問い合わせが本来の用途から外れていたことです。Principal PM LeadのChris Haklitch氏は「People would reach out to the sales reps about everything, including non-sales questions, which is not the best use of the sales reps’ time.（人々は営業に関係のない質問まで含めて何でも営業担当へ問い合わせていた。営業担当の時間の使い方として最善ではない）」と述べています。同氏は、できるだけ早くエージェントを出したかったこと、そのためにCopilot Studioが最適だったことも語っています。

最初の版は、Microsoftのサイト全体を1体のエージェントに読ませ、決められた筋書きに沿って会話を進める作りでした。事例ページは、掲載する内容と流入が増えるにつれて待ち時間が伸び、顧客がそれに気づくようになったと書いています。ここが分かれ目です。応答が遅くなったとき、多くの現場ではモデルを替える、あるいは知識の量を削るという発想になります。この事例で選ばれたのは、1体が抱えている選択肢の数を減らすという方向でした。

4つのサブエージェントと、司令塔が抱えるもの

新しい版の構成は、事例ページの記述だけでも輪郭がつかめます。中心にAsk Microsoftという司令塔があり、その下にAzure製品、Microsoft 365製品、価格、試用ページという専門のサブエージェントが並びます。大量の情報を扱う部分ではMicrosoft Foundryのエージェントとつながり、人へ渡す必要がある場面では有人チャットへ引き継ぎます。このとき会話の続きが保たれると明記されている点は、実務では見落とせません。引き継いだ先で顧客が同じ説明を繰り返すなら、削れたはずの手間がそのまま戻ってきます。

もうひとつ、運用側の記述があります。すべてのエージェントについて、応答の遅さ、エラー、利用状況、フィードバックを1つのダッシュボードで監視しているというものです。分けた数だけ見る場所が増えるため、監視をまとめる仕組みは分割とセットで用意されたことが読み取れます。

顧客が今どのページを見ているかによって答えを変える、という記述もあります。サイト内アシスタントは、質問文だけでなく読者がいる場所を手がかりにできます。同じ「価格は」という問いでも、Azureの料金ページとMicrosoft 365の比較ページでは求められている答えが違うためです。

選ぶ主語が変わる：クラシックと生成オーケストレーション

事例ページには、新しい版で使った仕組みとして生成オーケストレーションとマルチエージェントのオーケストレーションが挙がっています。この2つが何を指すのかは、Copilot Studioの公式ドキュメントに書かれています。

クラシックのオーケストレーションでは、利用者の入力とトピックのトリガーフレーズを突き合わせ、いちばん近い1つのトピックを起動します。返答も、あらかじめ作ったメッセージのノードを人が書いておく形です。対して生成オーケストレーションでは、トピック・ツール・ほかのエージェント・知識源の説明文をもとに、必要なものを1つ以上選びます。複数の意図が混ざった質問にも、複数を順に呼び出して答えられます。入力が足りなければ、質問そのものをエージェントが作って利用者へ尋ねます。

実務で効いてくるのは、ここから先です。ドキュメントは、選択を左右するいちばん重要な要素は説明文だと明記しています。名前、入出力のパラメータ、その名称と説明も影響しますが、中心は説明文です。さらに、似た説明文を持つトピックが複数あると、エージェントは1つだけを選んで応答し、その選択は予測しづらくなる、とも書かれています。

つまり、役割で分けるという作業の実体は、箱を増やすことではありません。それぞれの担当範囲を、重ならない言葉で書き切ることです。ドキュメントの推奨も具体的で、能動態と現在形で短く書く、専門用語や社内の言い回しを避ける、そして必要なら「これはできない」という記述も入れる、という形になっています。この作業を飛ばして分割だけ進めると、司令塔が毎回違う相手を選ぶ状態になります。

公表された4つの数値と、そこに書かれていないこと

数値を、出どころと測定の条件つきで並べます。

公表された内容	数値	対象として書かれている範囲
応答の遅さ（レイテンシ）	最大で61%小さい	Microsoft 365のサイトでの試験
人が対応するチャットの総量	最大で70%減	Ask Microsoft導入後の総量
試用の開始	16%増	Azureの製品サイトでの試験
申し込みへ進む可能性	10倍	エージェントに触れた顧客

読み方の注意を3つ書きます。ひとつめは、この事例ページがMicrosoft自身のサイトで、自社製品の導入例として公開されていることです。当事者と提供元が同じなので、第三者の検証を経た数値ではありません。

ふたつめは、61%と16%が別々のサイトでの試験だという点です。前者はMicrosoft 365のサイト、後者はAzureの製品サイトで、同じ環境の前後比較として並んでいるわけではありません。比較した期間、対象にしたページ、母数はどちらも書かれていません。

みっつめは、10倍という数字の性質です。事例ページは、エージェントに触れた顧客のほうが申し込みへ進む可能性が高いと述べています。ただし、触れるかどうかを決めたのは顧客の側です。もともと検討が進んでいる人ほど質問をする、という筋道が排除できるかは書かれていません。社内で共有するときは、効果の大きさではなく「関連が観測された」という形で伝えるのが誠実です。

顧客接点にAIを載せた事例としては、Macy’sがAsk Macy’sを4週間で公開した経緯も、公表された数値が1つだけという点で似た読み方が要ります。

分ければ速くなる、とは書かれていない

ここが、この事例でいちばん誤読されやすいところです。Copilot Studioのドキュメントは、複数のエージェントに分けたときの影響として、オーケストレーションの往復が増えるぶん遅くなりうると明記しています。司令塔が担当のエージェントを見つけ、そのエージェントが自分のオーケストレーションで手元のツールを選ぶ、という段が重なるためです。テストと管理と統制の範囲が広がることも、あわせて挙げられています。

では、いつ分けるのか。ドキュメントは、目安として司令塔が持つ選択肢（ツール・トピック・ほかのエージェント）が30〜40を超えたあたりから、区別する力が落ちてくると書いています。数が少なくても説明が似ていれば同じことが起きる、という注意もついています。順序としては、まず説明文を見直して差を作れないかを確かめ、それでも足りないときに分ける、という流れです。

分け方も2種類あります。1つの用途を担うだけで、設定や認証を分ける必要がなく、単体で公開しないものは子エージェント。担当するチームが別で、公開や更新の管理を分けたい、あるいは複数の親から使い回したいものは接続エージェントです。Ask Microsoftの4つがどちらにあたるかは事例ページに書かれていないため、ここでは判断しません。

公式が挙げている制約も、導入前に見ておく価値があります。生成オーケストレーションでは、複数のトピックが近い意図に一致したときに利用者へ選ばせる仕組みが呼ばれません。会話履歴として使える量には限りがあり、前のほうのやり取りを参照できないことがあります。知識源に含まれるリンクは、回答の中では文字列として出ます。

公表された数値と、公式の但し書きは、別々の場所に置かれています。事例ページだけを読むと「分けたから速くなった」と読めますが、そう書かれてはいません。比較されているのは、サイト全体を1体に読ませていた古い設計と、役割を分けたうえで生成オーケストレーションを使う新しい設計です。設計が2か所同時に変わっているため、速さがどちらの効果なのかは、公開されている情報からは切り分けられません。

日本の実務者が参考にできる点

ひとつめは、分割の判断を選択肢の数と説明文の重なりで見ることです。「サイトが大きいから分ける」ではなく、司令塔が抱えている選択肢を数え、説明文が互いに区別できているかを確かめる。30〜40という目安は、Microsoftが自社の製品について示している数字なので、そのまま持ち込むのではなく、自社の評価と合わせて使ってください。

ふたつめは、書き分けの作業を先に済ませることです。生成オーケストレーションでは、説明文がそのまま呼び出しの精度になります。「何ができるか」だけでなく「何をしないか」まで書くと、隣の担当との境目がはっきりします。これは社内の業務分掌の文書づくりに近い作業で、モデルの選定より前に効きます。

みっつめは、人へ渡す経路を最初から設計に入れることです。この事例では、有人チャットへ引き継いだあとも会話の続きが保たれます。引き継ぎ先で最初から聞き直す作りだと、問い合わせの総量が減っても顧客の体験は悪くなります。組織のなかで動くエージェントを設計した例は、GE ApplianceのGemini Enterprise活用にもまとめています。

よっつめは、監視の置き場所です。分けた瞬間から、遅さもエラーも利用状況もエージェントごとに散らばります。この事例で全エージェントを1枚のダッシュボードで見ているのは、その散らばりに対する答えです。分割の計画には、監視をまとめる計画を同時に付けると考えてください。

いつつめは、成果の測り方です。この事例で並んでいるのは、問い合わせ対応の指標だけではありません。試用の開始と申し込みという、マーケティング側の指標が並んでいます。サイト内アシスタントを「サポートの経費削減」としてだけ評価すると、検討を助けた分の価値が計測から抜け落ちます。ただし、数値の作り方が公表されていない以上、これは測る対象の選び方の参考であって、同じ数値を期待してよい根拠ではありません。

出典と注記

この記事は、Microsoftの導入事例ページ「Microsoft uses Copilot Studio to reshape customer experience and drive higher engagement」と、Copilot Studioの公式ドキュメント2本（「Orchestrate agent behavior with generative AI」「Add other agents overview」）を出典としています。1本目は当事者であるMicrosoft自身が、自社製品の導入例として公開しているもので、2本目と3本目は同社の製品ドキュメントです。本文の数値は原文の表記のまま記載し、単位の換算や、記載のない項目の補完はしていません。確認日は2026年9月11日です。仕様も数値も改定されるため、判断に使う前に各ページの現在の記載を確認してください。成果を保証する記述は含みません。ほかの事例は海外AI活用事例にまとめています。