こんにちは。皆さま、いかがお過ごしでしょうか？ “室長”こと吉島良平（Microsoft MVP for Business Applications|Microsoft Regional Director）です。

今日の東京は雨☔ですね。明日から4月ですか。就職・進学で、日本全国それぞれの街が華やかになるんでしょうね。室長にも、「そんな時があったなぁ」と考えます。皆さまも、思い出してみてください。初々しかったあの時をw

さて、Dynamics 365のERP側とCRM側にも、Microsoft 365 Copilotが連携シナリオがあり、先ほどのBlogではERP側との連携について解説しましたので、本稿では業務アプリケーション（CRM側）に活かせるMicrosoft 365 Copilotについて、取り上げていきたいと思っています。

Microsoft 365 Copilot 2026｜Sales Agent

―2026 release wave 1（2026年4月〜9月）におけるMicrosoft 365 Copilot for Sales Agentの新機能・改善点―

Microsoft 365 Copilot 2026 release wave 1｜Sales Agent
君はどこへ向かおうとしているのか？

Microsoft 365 Copilot 2026 release wave 1において、Sales Agentもまた明確な転換点を迎えました。今回のwaveは、営業現場に分かりやすい派手な新機能を次々と追加するwaveではありません。一見すると、従来の延長線上にある改善が中心であり、大きな変化がないように見えるかもしれません。

しかし、このwaveを丁寧に読み解いていくと、Sales Agentという存在が「何ができるのか」ではなく、「営業という役割の中で何を引き受ける存在なのか」を定義し直し始めたwaveであることが見えてきます。これは、機能単位の進化ではなく、営業活動そのものの構造に踏み込む変化です。これまでの営業支援は、入力を楽にする、情報を探しやすくする、レポート作成を効率化するといった個別作業の改善が中心でした。SalesAgentも当初は、その延長線上で理解されることが多かったように思います。しかし、Microsoft 365 CopilotとSales Agentが本質的に向き合っているのは、単なる作業効率化ではありません。

営業活動の中には、「探す」「整理する」「考える」「共有する」「次に動く」という連続した流れがあります。SalesAgentは、その流れのどこまでを人が担い、どこからをAgentに委ねるのか、その役割分担を再設計し始めています。
勘違いしがちですが、Sales AgentはDynamics 365 Salesや他のCRMを置き換える存在ではありません。案件管理、顧客管理、パイプラインの統制といった中核は、引き続きCRMが担います。一方でSalesAgentは、Outlook、Teams、CopilotChatといったMicrosoft 365の文脈の中で、営業活動そのものの進め方に影響を与え始めています。

今回の2026 release wave 1では、Sales Agentが「入力を支援する存在」から、「営業という役割を分解し、再構成する存在」へと進み始めたことが、さまざまな機能の配置や設計思想から読み取れます。本稿では、Dynamics 2026 wave 1と同様の記載方法を用いながら、SalesAgentの現在地と、その先に見える方向性を整理していきたいと思います。

この後は、Sales Agentが担う主要な機能領域について、機能概要、利活用方法、以前できていたこと、今回できるようになったこと、そして留意点という切り口で順に見ていきます。個々の機能名に引きずられるのではなく、Sales Agentが営業活動のどこに入り込み、何を変えようとしているのかに焦点を当てていきます。

≪Access and analyze sales data with Sales Chat≫

Link meetings to CRM records automatically with AI

この機能は、見た目以上にSales Agentの思想がよく表れています。営業の現場では、会議が入った瞬間から準備が始まりますが、その会議がどの案件やアカウントの話なのかをCRMに正しくひも付ける作業は、最後まで人の手に委ねられてきました。忙しいほど後回しにされ、結果としてリンクされないまま終わる。これは多くの営業組織で見慣れた光景だと思います。

今回のSales Agentは、そこに真正面から手を入れてきました。会議をスケジュールした時点で、その会議がどのCRMレコードに最も関係がありそうかをAIが推定し、既定で関連付けます。ここで重要なのは、いきなり確定させない点です。最初はsoft linkとして提案され、営業が確認したときにだけhard linkになります。提案は受け入れることも、変更することも、削除することもできます。この設計は非常に現実的です。自動化による誤リンクを恐れる気持ちと、手動リンクが現場で省略される現実。その両方を前提にした上で、「まず提案として出す」という落としどころを選んでいます。Sales Agentは、正解を押し付けるのではなく、営業が判断しやすい状態を先に用意する存在として振る舞っています。

Dynamics 365 Salesを利用している場合、この機能の価値は会議準備の質の平準化にあります。会議の前にCRMを開き、案件を探し、前回のやり取りを思い出す。その一連の準備作業が、会議準備の既定動作として自然に始まります。結果として、準備の抜け漏れが減り、営業が本来使うべき時間を顧客理解や提案の整理に使えるようになります。

他のCRMを利用している場合でも、考え方は同じです。会議という行為をトリガーにして、CRMコンテキストを自動で持ち込む。どのCRMを使っているかではなく、「会議準備はCRM起点で始まるべき」という作法を標準にしようとしている点が重要です。これは特定製品の便利機能というより、営業活動の型を変えに来ている動きだと感じます。

以前はどうだったかというと、会議とCRMレコードをひも付けること自体は可能でした。ただし、それはあくまで「やろうと思えばできる」話でした。忙しいほど省略され、結果として会議前に十分な情報が揃わない、会議後の内容がCRMに残らない、という状態が繰り返されてきました。今回の機能は、その人間系の摩擦を既定動作で消しに来ています。

今回できるようになったのは、自動でリンクされることそのものではありません。会議を入れるだけでAIが推定し、まず提案として提示され、営業が判断するという流れが最初から組み込まれたことです。リンクが義務ではなく、提案になる。しかも、その提案が既定で出る。ここが決定的に違います。

もちろん留意点もあります。soft linkが既定である以上、確実にCRMに履歴を残す運用をしている組織では、どこで承諾してhard linkにするかを意識する必要があります。また、AIの推定はconfidenceベースなので、常に期待どおりの案件に当たるとは限りません。ただ、だからこそ修正でき、使いながら精度が育つ前提になっています。最初から完璧を求めるより、運用で馴染ませていく設計です。

Sales Agentがここでやろうとしているのは、営業を賢くすることではありません。営業の流れの中で、省略されがちな一手を既定動作にすることです。会議は営業活動の中心です。その会議にCRMコンテキストを自然に持ち込むことは、営業という役割を分解し、再構成していくための重要な土台になるはずですね。

Capture opportunity notes using voice in Sales agent

この機能は、Sales Agentが「入力を楽にする」段階を越えたことを、非常に分かりやすく示しています。営業の現場では、会議が終わった直後がいちばん情報が新鮮です。どこに温度感があったのか、どこで相手が反応したのか、次に何をすべきか。しかし、そのタイミングでCRMに向き合う余裕はあまりありません。結果として、opportunityのメモは後回しになり、気づけば記憶も熱量も薄れてしまう。これは多くの営業組織で繰り返されてきた課題です。

Sales Agentは、そこを「声」で解決しにきました。Outlook Mobile上でSales Agentに話しかけるだけで、会議の内容をそのままopportunityのメモとして残せます。キーボードを開く必要も、アプリを切り替える必要もありません。話して、確認して、保存する。それだけです。重要なのは、単なる音声入力ではなく、その内容が後から読める形に整えられたノートとして保存される点です。会議の文脈、重要なポイント、次のアクションが含まれた状態で残るので、チーム内共有や後日の振り返りにも耐えます。

Dynamics 365 Salesを使っている場合、この変化は特に実感しやすいと思います。これまで、モバイルからopportunityを更新するには、それなりの覚悟が必要でした。フィールドを探し、入力し、保存する。その手間がある限り、「あとでやろう」が発生します。音声によるメモ入力は、その摩擦を一気に下げます。顧客との対話とCRM更新の間にあった遅延が縮まり、情報が新鮮なうちに記録されるようになります。その結果、記録の精度が上がり、次の打ち手も明確になります。

他のCRMを使っている場合でも、価値の構造は同じです。音声で残したメモが、正しいopportunityにひも付いた状態で保存される。この「正しいレコードに入る」という点が、現場ではとても重要です。便利でも、どこに入ったか分からない仕組みは使われません。Sales Agentは、部分的なopportunity名やaccountの文脈、会話の流れから対象を推定し、曖昧な場合は確認してから保存します。楽にするだけでなく、データ品質を守ることを前提にしています。

以前も、メモを残すこと自体はできました。しかしそれは、「入力できる」という意味であって、「入力され続ける」設計ではありませんでした。忙しいほど省略され、結果としてCRMが最新の状況を反映しなくなる。この負のループを、Sales Agentは断ち切ろうとしています。声で、その場で、終わらせる。営業がやる気や几帳面さに依存しなくても、記録が残る状態を既定にしようとしています。

今回できるようになったのは、音声入力という手段ではなく、記録のタイミングそのものを変えたことです。会議が終わった瞬間に、そのままCRMに反映される。この流れが組み込まれたことで、opportunityの情報は「思い出して書くもの」から「体験と同時に残るもの」に変わります。これは、営業活動の質を静かに底上げします。

もちろん留意点もあります。この機能はOutlook Mobileでの利用を前提にしているため、机の前で使うものではありません。移動中や会議の合間で使う、という前提をチームで共有した方が効果が出ます。また、並行案件が多い場合は、保存前に確認が入ることもあります。ただし、それは誤ったレコードに保存されるよりずっと健全です。最初から完璧を求めるのではなく、使いながら馴染ませる前提で捉えるのが現実的です。

この機能を見て改めて感じるのは、Sales Agentが入力支援を卒業しつつあるということです。営業が本来やるべきなのは、入力ではなく判断です。その判断に必要な情報を、最も楽な形で、最も早いタイミングで残す。Sales Agentは、営業という役割の中で省略されがちな一手を、既定動作に変える方向へ、確実に進んでいるように思います。即、使いたいですね。

Access and analyze sales data with Sales agent chat experiences

これは、一見すると「CRMデータをチャットで検索できるようになった機能」に見えます。しかし、この機能の本質は検索体験の改善ではありません。Sales Agentが、営業活動の中で「考える場所」をどこに置こうとしているのか。その思想が、非常に分かりやすく表れています。

営業が判断しようとするとき、最初に起きるのは画面遷移です。CRMを開き、案件を探し、過去の活動を見て、TeamsやOutlookに戻る。この往復の中で思考は何度も中断されます。何を確認したかったのか、なぜこの情報を見ているのか。その文脈が、画面遷移のたびに薄れていく。この分断は長年当たり前のものとして受け入れられてきました。Sales agent chat experiencesは、この分断そのものを前提から壊しに来ています。営業が考え始めた瞬間、その場で聞ける。探すのではなく、対話する。この設計が出発点です。Sales Agentのチャットは、単なるCRM検索の置き換えではありません。CRMにある顧客情報や案件情報だけでなく、Teamsの会議や過去のやり取りなど、複数のアプリケーションにまたがる情報を、ひとつの会話の流れとして扱います。営業は「この顧客、最近どんな話題が多いか」「この案件、今どこがリスクか」と自然に聞くだけです。Sales Agentは、それに対して情報を集め、要点をまとめ、必要であれば分析として返します。営業は、データの在り処を意識しなくてよい。ここが決定的に違います。

Dynamics 365 Salesを使っている場合、この価値は特に分かりやすく現れます。新しくアサインされたアカウントについて、CRMを一つひとつ開かなくても、Sales Agentに聞けば全体像が立ち上がる。過去に誰が関わっていたのか、どんなテーマが多かったのか、どの案件が進行中なのか。営業が状況把握に費やしていた時間が、そのまま顧客理解の時間に変わります。これは単なる効率化ではなく、営業の立ち上がり速度を変える話です。

他のCRMを使っている場合でも、意味合いは同じです。この機能が示しているのは、「CRMを見に行く」という行為自体を減らそうとしている点です。営業の役割は、情報を探すことではなく、判断することです。Sales Agentは、判断に必要な材料を、会話という形で差し出します。どのCRMを使っているかではなく、「営業の思考はチャットから始まる」という前提を標準にしようとしている。そういう意図が見えます。

以前はどうだったかというと、こうした横断的な情報把握は、かなり経験を積んだ営業か、時間に余裕のある営業だけができるものでした。複数の画面を行き来し、情報を頭の中で統合する必要があったからです。その結果、準備の質は個人差に大きく依存していました。Sales agent chat experiencesは、この属人性を構造で消しに来ています。聞けば出てくる状態を既定にすることで、情報アクセスのばらつきを抑えています。

今回できるようになったのは、「チャットで聞ける」こと自体ではありません。営業の思考を止めずに、情報取得と分析をその場で完結させる体験が、最初から組み込まれたことです。検索ではなく対話、画面遷移ではなく思考の継続。この違いは、使い始めると想像以上に大きく感じるはずです。

もちろん留意点もあります。Sales Agentが扱えるデータ範囲は管理者によって制御されますし、CRMのカスタマイズや社内用語の反映状況によって体験は変わります。また、自然言語である以上、聞き方によって返ってくる答えの質も変わります。ただし、それは最初から完璧を求める設計ではありません。使いながら馴染ませ、育てていく前提になっています。たまごっち感覚ですね。

Sales Agentがここでやろうとしているのは、営業に代わって考えることではありません。営業が考え続けられる状態を壊さないことです。情報を探す行為を極限まで背景に追いやり、判断と対話に集中させる。Access and analyze sales data with Sales agent chat experiencesは、営業の思考の起点を「画面」から「対話」へと移すための、重要な土台だと感じました。

View AI-powered opportunity summaries in Sales agent

この機能は、「案件サマリーをAIが作ってくれる機能」として紹介されがちです。しかし、この機能の本質は要約そのものではありません。Sales Agentが、営業にとって「案件を把握する」とはどういう状態なのかを、あらためて定義し直そうとしている点にあります。

営業が案件を理解しようとするとき、これまでは断片を集める作業から始まっていました。CRMの案件レコードを開き、メールを読み返し、会議の内容を思い出し、メモを探す。その結果として頭の中に「今どういう状況か」を組み立てる。この組み立て作業は、経験があるほど早くなりますが、忙しいほど雑になりがちです。Sales AgentのAI-powered opportunity summaryは、この人間側の再構成作業そのものを、最初から用意された形で差し出します。このサマリーが扱っているのは、単なる案件の基本情報ではありません。案件の状態、最近の変化、顧客とのやり取り、関係者の動き、次に取るべきアクション。営業が本来頭の中で統合していた要素を、ひとつの構造化された視点としてまとめています。しかも、それは長い文章ではなく、「今この案件で判断すべきことは何か」が見える形で提示されます。ここに、単なる要約機能との決定的な違いがあります。

Dynamics 365 Salesを使っている場合、この価値は案件数が増えるほど効いてきます。複数の案件を抱えていると、すべてを同じ解像度で把握し続けるのは現実的ではありません。結果として、「よく知っている案件」と「感覚的に覚えている案件」が混在します。AI-powered opportunity summaryは、すべての案件に対して、一定の解像度の視点を強制的に与えます。これは営業の判断力を均一化する仕組みだと言えます。特に重要なのは、このサマリーが「最新の状態」に重きを置いている点です。何が変わったのか、どこが動いていないのか、何が滞留しているのか。営業は過去の履歴を読み解くのではなく、「今どうか」に集中できます。案件レビューやパイプライン確認が、報告の場から意思決定の場へと変わっていく下地が、ここにあります。

他のCRMを使っている場合でも、この考え方は共通です。案件情報はCRMの中にありますが、「案件の理解」は営業の頭の中にしかありませんでした。Sales Agentは、その理解の型を外に出し、誰でも同じ視点で案件を見られるようにします。これは単なる効率化ではなく、営業組織としての思考の標準化に近い動きです。

以前はどうだったかというと、良い案件サマリーは「できる営業」が作るものでした。上司に説明するとき、役員に共有するとき、経験のある営業ほど要点を押さえた説明ができる。一方で、その品質は完全に属人化していました。AI-powered opportunity summaryは、その属人性を前提から崩します。誰が見ても、同じ観点で案件の状態を把握できる。ここが非常に大きいポイントです。

今回できるようになったのは、「案件を要約する」ことではありません。案件をどう見れば判断しやすいのか、その視点が最初から組み込まれたことです。営業はまとめる作業から解放され、考える作業に集中できます。サマリーは報告書ではなく、次の一手を決めるための道具として存在しています。

もちろん留意点もあります。AIがまとめたサマリーは、入力されている情報の質に依存します。CRMに情報が入っていなければ、見える景色も薄くなります。ただし、それはこの機能の欠点というより、運用を映し出す鏡です。どこが足りていないかが可視化されることで、入力や運用そのものが改善されていく余地があります。

Sales Agentがここでやろうとしているのは、営業を評価することではありません。営業が判断しやすい状態を、常に用意することです。案件を思い出す時間を減らし、次に進めるかどうかを考える時間を増やす。この機能は、営業の意思決定を支えるための、非常に実践的な一歩だと感じます。

Add custom insights to record summaries in Sales agent

この機能は、一見すると「サマリーに外部データを足せるようになりました」という拡張機能に見えます。しかし、この機能が示しているのは、Sales Agentが「正しい情報」とは何かを、CRMの外側まで含めて再定義しようとしている点です。これまでのCRMサマリーは、あくまでCRMに入っている情報の再構成でした。案件、アカウント、活動履歴。その範囲の中でいくら整理しても、営業が実際に判断するときに使っている情報のすべてはカバーできませんでした。契約管理システム、サポート履歴、請求状況、社内の承認ステータス。重要な文脈ほど、CRMの外に散らばっている。Add custom insightsは、この前提を正面から認めています。

Sales Agentは、サマリーを「CRMレコードの要約」ではなく、「営業が判断するための視界」として扱い始めています。そのために、CRM以外のアプリケーションにある情報も、サマリーの一部として取り込めるようにしています。営業は、どのシステムに情報があるかを意識しなくていい。ただ、案件やアカウントを見れば、判断に必要な材料が揃っている。この状態を目指しています。

Dynamics 365 Salesを使っている場合、この機能の意味はかなり大きくなります。標準の案件サマリーは、案件の状態や次のアクションを把握するには十分ですが、「なぜ今この判断が必要なのか」という背景情報までは含めきれません。そこに、自社独自のシステムやプロセスから得られるインサイトを重ねることで、サマリーは単なる整理結果ではなく、組織の意思決定ルールを反映したビューになります。Sales Agentは、企業ごとの営業の型を、サマリーに埋め込めるようになっています。ここで重要なのは、この機能が営業向けではなく、管理者や設計者向けに開かれている点です。どの情報を「重要なインサイト」として扱うかは、組織によって違います。Add custom insightsは、その違いを許容します。Sales Agentが決めた正解を使わせるのではなく、「自社にとっての正解」を組み込ませる。この姿勢は、これまでのCopilot系機能と比べても、かなり踏み込んだものです。

他のCRMを使っている場合でも、示唆は同じです。営業が判断するときに見ている世界は、CRM単体では完結しません。Sales Agentは、その現実を前提に、情報の集約点を「アプリ」ではなく「サマリー」に置いています。画面を切り替えるのではなく、視点を切り替える。その中心にサマリーがある。この考え方は、ツールを越えて汎用性があります。

以前はどうだったかというと、こうした情報統合は個人の頭の中か、ExcelやPowerPointの資料の中で行われていました。案件レビューのたびに作られる資料は、まさにカスタムインサイトの集合体でした。ただし、それは一時的で、属人的で、次に引き継がれないものでした。Add custom insightsは、その作業を日常業務に組み込み、しかも常に最新の状態で維持しようとしています。

今回できるようになったのは、「サマリーを拡張できる」ことではありません。営業組織が暗黙的に使ってきた判断材料を、正式なデータとしてサマリーに載せられるようになったことです。サマリーは読むものから、組織の意思決定を映すものへと役割を変えています。

もちろん留意点もあります。何でもサマリーに入れればよいわけではありません。情報が増えすぎれば、判断しやすさは逆に下がります。Add custom insightsは、何を足すかよりも、何を足さないかを考えさせる機能でもあります。その取捨選択こそが、営業プロセス設計そのものです。

Sales Agentがここでやろうとしているのは、情報を増やすことではありません。営業が迷わず判断できる視界を、組織として設計することです。Add custom insights to record summaries in Sales agentは、Sales Agentを「汎用AI」から「自社仕様の営業基盤」へと一段引き上げる、重要なピースだと感じました。いい方向への進化が止まらないね！

Configure record summaries easily in Sales agent

この機能は、機能名だけを見ると「管理画面が使いやすくなった話」に見えるかもしれません。しかし、この改善の本質は操作性ではありません。Sales Agentが「サマリーは誰が設計するものか」という責任の所在を、はっきりと管理者側に引き寄せてきた点にあります。これまでのレコードサマリーは、技術的にはカスタマイズ可能でした。ただし、どこで何を設定しているのかが分散しており、結果として「思ったとおりのサマリーにならない」「人によって出力が微妙に違う」という状態が起きやすかった。Sales Agentは、この曖昧さを前提としてきません。Configure record summaries easilyは、サマリーを一つの設計物としてまとめて管理するための仕上げの一手です。

この機能で変わったのは、サマリーの中身そのものではありません。サマリーをどう作るか、どの情報を参照し、どこまで新しさを求めるか。そのルールを、一か所で定義できるようになった点です。管理者は、CRMのどのデータをどう使うかを明示した上で、AIに対して指示を与えられます。結果として、出てくるサマリーの一貫性が大きく上がります。

Dynamics 365 Salesを使っている場合、この改善は地味ですが非常に効きます。案件サマリーやアカウントサマリーは、毎日何度も目にするものです。そこに揺らぎがあると、営業は無意識に信用度を下げます。Configure record summaries easilyは、その揺らぎを設計で抑えに来ています。AIに任せる部分と、組織として決める部分の境界線を、はっきり引いています。特に重要なのは、「どれくらい最近の情報を使うか」を制御できる点です。最新のメモややり取りを重視するのか、それとも一定期間を俯瞰した情報を重視するのか。この判断は、営業プロセスや商材の特性によって変わります。Sales Agentは、その違いを吸収するために、時間軸まで含めてサマリー設計を委ねています。

他のCRMを使っている場合でも、この考え方は示唆に富んでいます。AIサマリーは魔法ではありません。何を参照し、何を無視するかを決めなければ、組織にとって使えるものにはならない。Configure record summaries easilyは、「AIの品質は、設計の品質で決まる」という当たり前の事実を、プロダクトとして正面から扱っています。

以前はどうだったかというと、サマリーの品質は暗黙知に頼っていました。「このくらい分かっているだろう」「この項目は見なくてもいいだろう」という前提が、個人やチームごとに違っていた。結果として、サマリーは便利だが信用しきれない存在になりがちでした。今回の改善は、その曖昧さを排除し、サマリーを業務基盤の一部に引き上げています。

今回できるようになったのは、「設定が楽になった」ことではありません。サマリーを、個人の補助ではなく、組織の判断基準として扱えるようになったことです。Sales Agentは、営業に自由を与える一方で、判断の軸は揃えに来ています。このバランス感覚は、これまでのCopilot系機能の中でもかなり成熟しています。

もちろん留意点もあります。設計を誤れば、サマリーは過度に硬直します。何を重視するかを決めきれない組織では、設定そのものが止まる可能性もあります。ただし、それはAIの問題ではなく、営業プロセスがまだ言語化されていないというサインです。Configure record summaries easilyは、その課題を表に出す装置でもあります。

Sales Agentがここでやろうとしているのは、AIを賢くすることではありません。サマリーを「信頼できる前提」にすることです。毎回疑いながら読む補助情報ではなく、判断の出発点として使える情報にする。そのための設計を、一か所で、明確に行えるようにした。この一歩は、Sales Agentを実験的なAIから、業務に耐える基盤へと押し上げる非常に重要な進化だと感じますね。

Configure Sales agent starter prompts across applications

この機能は、「スタータープロンプトを管理画面から設定できるようになった」という話では終わりません。この機能が示しているのは、Sales Agentが“どう使われるべきか”を、ユーザー任せにしないという明確な意思です。生成AIを現場に入れたとき、最初につまずくのは機能ではありません。「何を聞けばいいのか分からない」という状態です。自由度が高いほど、逆に手が止まる。Sales Agentのスタータープロンプトは、その空白を埋めるための仕掛けです。そして今回のポイントは、その仕掛けを組織側が設計できるようになったことにあります。これまでのスタータープロンプトは、あくまで製品側が用意した“汎用的な入口”でした。便利ではあるものの、自社の商談プロセスや用語、優先順位とは必ずしも一致しない。その結果、「便利そうだけど自分の仕事には合わない」という距離感が生まれがちでした。Configure Sales agent starter prompts across applicationsは、このズレを構造的に解消しに来ています。

この機能では、スタータープロンプトを一か所で管理しながら、Dynamics 365、Outlook、Teamsといった利用コンテキストごとに内容を出し分けられます。営業がOutlookで使うときに求めているのは、メールや予定に直結する行動です。一方で、Dynamics 365ではアカウントや案件の把握が中心になる。同じSales Agentでも、使われる場所によって期待される役割は違う。その違いを、最初から前提にしています。

Dynamics 365 Salesを使っている場合、この意味は特に分かりやすいです。CRM画面では「この案件の状況を把握する」「次に何をすべきかを確認する」ことが多い。一方、TeamsやOutlookでは「今すぐ何かを進めたい」というニーズが強い。スタータープロンプトが場面に合っていないと、Sales Agentは単なるチャットボットになってしまいます。今回の機能は、その入口の質を管理者がコントロールできるようにしています。重要なのは、ここでも主語が営業ではなく、設計者にある点です。どんなプロンプトを最初に見せるかは、「営業に何を考えてほしいか」というメッセージそのものです。案件リスクを見るのか、顧客理解を深めるのか、次のアクションを決めるのか。スタータープロンプトは、組織の営業思想をそのまま反映します。Sales Agentは、その思想を毎回、最初の一言として営業に渡しています。

他のCRMを使っている場合でも、この考え方はそのまま当てはまります。生成AIの活用は、自由に使わせるだけでは定着しません。「ここから使い始めてほしい」という導線を、あらかじめ用意する必要があります。Configure Sales agent starter prompts across applicationsは、AI活用を個人のセンスに任せず、組織の設計として扱うための機能です。

以前はどうだったかというと、AIの使い方は属人化しやすいものでした。よく使う人と、まったく使わない人の差が広がる。結果として、「一部の人だけが便利に使っているツール」になってしまう。スタータープロンプトを組織で設計できるようになったことで、その格差を入口の段階で縮めに来ています。

今回できるようになったのは、「プロンプトを設定できる」ことではありません。Sales Agentの使われ方そのものを、組織として定義できるようになったことです。何を聞くべきか、どこから始めるべきか。その判断をAIではなく、人間側が握っています。

もちろん留意点もあります。スタータープロンプトを作り込みすぎると、逆に思考を縛る可能性もあります。あくまで入口であり、正解を固定するものではありません。そのバランスをどう取るかは、営業プロセス設計の腕の見せ所ですね。アプリケーションコンサルタントは、ここを常に頭においておかないと。

Sales Agentがここでやろうとしているのは、AIを使わせることではありません。使われ続ける状態を設計することです。Configure Sales agent starter prompts across applicationsは、Sales Agentを“賢い道具”から“定着する仕組み”へと進化させる、非常に実務的な一手だと感じました。

≪Application experiences≫

Control AI insights generation by meeting sensitivity labels

この機能は、「機密ラベルが付いた会議ではAIが動かないようにできます」という機能説明だけでは捉えきれません。この機能が本当に示しているのは、Sales Agentが「AIを使わない判断」も、正式な設計対象として扱い始めた点です。生成AIを営業活動に持ち込むとき、必ず出てくる不安があります。どこまでAIに見せてよいのか、どこから先は人間だけが扱うべきなのか。これまでは、その線引きは曖昧な運用ルールや注意喚起に委ねられてきました。Control AI insights generation by meeting sensitivity labelsは、その線引きを、会議という単位で、しかも既存のセキュリティラベルを使って明示的に行えるようにしています。ここで重要なのは、「AIを制限するための特別な設定」を新たに持ち込んでいない点です。会議に付けられた感度ラベル、そのままがAIの挙動を制御します。Privateや高い機密区分が付いた会議では、AIによるインサイト生成や保存が行われない。この設計は、営業とIT、セキュリティの間にあった溝を、かなり自然な形で埋めています。

Dynamics 365 Salesを使っている場合、この意味は非常に実務的です。役員同席の商談、戦略的な価格交渉、未公開情報を含む会議。そうした場では、AIに要約されること自体がリスクになる場合があります。一方で、通常の営業会議では、AIによる要点整理やアクション抽出は大きな助けになります。Control AI insights generation by meeting sensitivity labelsは、「すべて使う」「すべて使わない」という二択ではなく、会議の性質ごとに使い分ける前提を、プロダクトに組み込んでいます。特に評価すべきなのは、この制御が営業の操作に依存していない点です。営業が毎回「これはAIに使わせてよいか」を判断する必要はありません。会議のラベルを付けるという、すでに存在する行為が、そのままAIの可否判断になります。これは、現場負荷を増やさずにガバナンスを効かせる、非常に現実的な落としどころです。

他のCRMを使っている場合でも、この考え方は汎用性があります。AI活用における最大の課題は、「例外処理をどう扱うか」です。重要な会議ほど例外になりやすく、その例外を人に判断させると、運用は必ず崩れます。Sensitivity labelを基点にAIの挙動を制御するという設計は、AI活用を例外だらけにしないための、強いメッセージでもあります。

以前はどうだったかというと、機密性の高い会議では「録音しない」「共有しない」「メモは各自で管理する」といった、暗黙の了解に頼っていました。しかしAIが入り込むと、その暗黙知は簡単に破綻します。Control AI insights generation by meeting sensitivity labelsは、その暗黙知を正式な制御ルールに昇格させています。

今回できるようになったのは、「機密会議でAIを止められる」ことではありません。AIを使うか使わないかを、会議設計の一部として扱えるようになったことです。AIは常に動く存在ではなく、条件付きで動く存在として位置づけられています。これは、Sales Agentが成熟段階に入っていることを示しています。

もちろん留意点もあります。Sensitivity labelの設計が曖昧な組織では、この機能はうまく機能しません。ラベルが形骸化していれば、AI制御も形骸化します。ただし、それはこの機能の欠点ではなく、情報分類が未整理であることの表れです。Sales Agentは、セキュリティとAI活用の整合性を、正面から突きつけています。

Sales Agentがここでやろうとしているのは、AIを万能にすることではありません。AIが関わってよい領域と、関わるべきでない領域を、組織として定義できるようにすることです。Control AI insights generation by meeting sensitivity labelsは、AI活用を推進するための機能であると同時に、「使わない勇気」を支えるための機能でもありますね。本当に必要不可欠な機能です。設計自体に、難しさもありますが。

≪Copilot agents≫

View Sales Development agent metrics in Sales agent

この機能は、「エージェントのメトリクスが確認できるようになった」という機能紹介では終わりません。この機能が示しているのは、Sales Agentがエージェントを“導入して終わりの自動化”ではなく、“運用し、改善し、育てる存在”として扱い始めたという明確な意思です。Sales Development agentは、リードへの初期アプローチという営業プロセスの入口を担います。この領域は、量が多く、属人化しやすく、しかも成果が見えにくい。人がやっても、AIがやっても、放置すれば質は落ち、現場の信頼も失われます。だから本来必要なのは、「ちゃんと動いているか」ではなく、「期待した成果につながっているか」を継続的に把握できる視点です。View Sales Development agent metricsは、その視点をSales agentの中に最初から組み込んでいます。ここで可視化されるのは、単なる稼働状況ではありません。どれだけのリードに接触したのか、どれだけをエスカレーションしたのか、どれだけ営業に引き渡したのか。つまり、Sales Development agentが営業プロセスの中で、どんな流れを作れているのかが、指標として整理されています。この設計は、エージェントを「便利な自動化」ではなく、成果責任を持つ業務主体として扱い始めていることを意味します。

Dynamics 365 Salesを使っている場合、この機能の価値は非常に実務的です。Sales Development agentが扱うのは、リードの初動という最もボリュームがあり、かつ判断が難しい領域です。ここを感覚だけで運用すると、「なんとなく良さそう」「たぶん問題ない」という曖昧な状態に陥りがちです。View Sales Development agent metricsは、エージェントマネージャーが状況を客観的に把握し、どこに手を入れるべきかを判断するための入口になります。特に重要なのは、メトリクスを見るだけで終わらない点です。集計された数字から、そのまま個別のリードにドリルダウンできます。各リードについて、どんなアクティビティが行われ、どんなコミュニケーションがあったのか、その概要まで追える。「数字が悪い」という結果から、「どの段階で詰まっているのか」「どこで止まっているのか」へ、思考をそのまま移せる設計になっています。これは単なるダッシュボードではなく、改善行動に直結する視界です。

一方で、Dynamics 365 Salesを使っていない場合でも、この機能が示している考え方は十分に成立します。ここで扱われているのは、特定のCRMの機能ではなく、「AIエージェントを労働力としてどう扱うか」という視点だからです。多くの組織では、インサイドセールスやSDRの活動は、CRM、MA、メールツール、スプレッドシートなどに分散しています。そのため、AIや自動化を導入しても、「どれだけ動いたか」「どこまで成果に結びついたか」を一貫した視点で追えないケースが少なくありません。View Sales Development agent metricsが示しているのは、そうした分断を前提にしたうえで、「エージェントの仕事ぶり」をひとつの流れとして把握するという発想です。ここでの評価軸は、AIの精度や賢さではありません。どれだけ接触し、どこまで進め、どのタイミングで人に渡したか。これは、人のSDR（Sales Development Representative/インサイドセールスと言い換えてもいい）を評価するときと同じ視点です。つまり、AIエージェントを“特別な存在”として扱うのではなく、業務プロセスの一員として、同じ物差しで見る。この考え方は、どのCRMを使っていても、そのまま適用できます。他のCRMを使っている組織にとって特に重要なのは、「エージェントをブラックボックスにしない」という姿勢です。AIが自動で動いていると、成果が出ていないときに原因が分からなくなりがちです。View Sales Development agent metricsは、AIが今どのリードに関わり、どこまで進め、どこで止まっているのかを追える前提を示しています。これは、AIを外注先のように扱うのではなく、内部プロセスとして運用するための考え方です。

以前はどうだったかというと、エージェントや自動化の運用は、ログと現場の体感に頼りがちでした。何件送ったかは分かるが、なぜ引き渡しが少ないのかは分からない。個別の状況を把握しようとすると、結局はCRMやメール履歴を開き、時間を使う必要がある。その結果、改善が続かない。View Sales Development agent metricsは、「改善が続かない理由」そのものを、プロダクトの設計で取り除いています。

今回できるようになったのは、「指標が見える」ことではありません。エージェントを業務として運用し、改善し続けるための視界が、最初から用意されたことです。エージェントマネージャーという役割を、単なる監督者ではなく、成果を育てる設計者として位置づけている点に、この機能の本質があります。

もちろん留意点もあります。指標が可視化されると、数字そのものが目的化しやすくなります。接触数を増やすことが正義になり、質が落ちる。引き渡し数だけを追い、適切なタイミングを逃す。これは、人の営業指標でも繰り返されてきた罠です。ただし、この機能では個別リードまで降りて文脈を確認できます。数字と現場の実態を行き来できることが、運用を健全に保ってくれるのではないでしょうか。

Scale your sales team to grow your pipeline with Sales Development agent

この機能は、「営業人員を増やさずにパイプラインを拡大できます」という効率化の話ではありません。この機能が本当に示しているのは、営業組織のスケール方法そのものを変えに来ているという点です。営業を成長させるとき、これまでの選択肢は明確でした。人を増やすか、無理をさせるか。そのどちらかです。しかし実際には、リードの初動対応や一次対応に追われ、最も価値の高い商談に十分な時間を割けていないケースが少なくありません。Scale your sales teamという言葉が指しているのは、「人を増やす」ことではなく、「対応できるキャパシティを増やす」ことです。その役割を担うのが、Sales Development agentです。Sales Development agentは、SDR（Sales Development Representative/インサイドセールスと言い換えてもいい）の役割を担う自律型のAIエージェントです。リードに対して一次対応を行い、質問に答え、必要な確認を行い、商談として成立するものだけを営業に引き渡す。しかも、これを営業時間に関係なく、同時並行で行います。ここで重要なのは、単にメールを自動送信する仕組みではない点です。Sales Development agentは、対話を通じて見込み顧客の状況を把握し、条件を満たしたと判断したときに、人に引き渡す設計になっています。

Dynamics 365 Salesを使っている場合、この価値は非常に分かりやすく現れます。リードはCRMに蓄積されているものの、人手が足りず、フォローが遅れる。その結果、機会損失が発生する。Sales Development agentは、既存のリード割り当ての流れに組み込まれ、営業の代わりに一次対応を進めます。営業は、条件が整ったタイミングで引き継ぐだけでよい。これにより、営業は「数をこなす仕事」から解放され、「判断と提案」に集中できます。

一方で、Dynamics 365 Salesを使っていない場合でも、この機能が示している考え方は十分に成立します。ここで語られているのは、特定のCRMの拡張ではなく、「営業のスケールは人の増減で行うものではない」という発想だからです。インバウンドリードが増えたときに、すぐに人を増やすのではなく、一次対応をエージェントに任せる。営業は、本当に人が介在すべきフェーズに集中する。この役割分担の考え方は、どのCRMを使っていても、そのまま当てはまります。特に注目すべきなのは、Sales Development agentを「一人の仮想営業」として扱っている点です。エージェントは個別に作成され、役割と責任を持ちます。つまり、スケールとは「処理能力を上げる」ことではなく、「役割を増やす」こととして再定義されています。これは、営業組織の設計思想そのものを変える発想です。

以前はどうだったかというと、パイプラインを増やすためには、対応漏れを減らすか、対応スピードを上げるしかありませんでした。そのために人を増やし、教育し、管理する。しかしそのプロセス自体がボトルネックになり、スケールの限界を作っていました。Scale your sales team to grow your pipeline with Sales Development agentは、その制約を前提から外しています。

今回できるようになったのは、「営業活動を自動化できる」ことではありません。営業組織のキャパシティを、連続的に拡張できる構造が用意されたことです。しかも、その拡張は、既存の営業のやり方を壊すのではなく、補完する形で行われます。営業は減らされるのではなく、より価値の高い仕事に集中できるようになります。

もちろん留意点もあります。Sales Development agentは万能ではありません。どの段階で人に引き渡すのか、その基準を誤れば、営業は不完全な状態で商談を引き継ぐことになります。だからこそ、前段で書いてきた「指標」「可視化」「設計」が重要になります。Scaleは、仕組みなしには成立しません。

Sales Agentがここでやろうとしているのは、営業をAIに置き換えることではありません。営業の役割を分解し、スケール可能な部分と、人が担うべき部分を明確に切り分けることです。Scale your sales team to grow your pipeline with Sales Development agentは、営業組織を“人の数で成長させるモデル”から、“構造で成長させるモデル”へと移行させる、象徴的な一手だと感じます。小規模で案件を回している営業組織にとって非常に有益な機能だと思っています。

Microsoft 365 Copilot 2026 release wave 1｜Sales Agent
君はどこへ向かおうとしているのか？

ここまで見てきたとおり、2026 release wave 1のSales Agentは、個々の機能を足し算するwaveではありませんでした。むしろ、営業活動の中に散らばっていた「本来はやるべきだが、省略されがちな一手」を、既定動作として組み込み直すwaveだったように思います。

会議とCRMを自動でひも付ける。
会議直後に、声でopportunityを残す。
画面を切り替えず、対話の中で状況を把握する。
案件の状態を、人によらず同じ視点で見られるようにする。
判断材料をCRMの外側まで含めて統合する。
AIの出力品質を、運用ではなく設計で揃える。
使い始め方そのものを、組織として定義する。
使ってはいけない場面を、曖昧にしない。
AIエージェントを成果責任を持つ存在として測り、育てる。

営業の現場に長くいる人ほど、「ここが変わると現実が変わる」と感じるポイントばかりではないでしょうか。Sales Agentは、営業を自動化しようとしているわけではありません。営業を楽にもしようとしていません。Sales Agentが向き合っているのは、営業という役割そのものです。営業は、入力係ではありません。情報整理係でもありません。本来は、判断し、次の一手を決める存在です。Sales Agentは、その判断に至るまでの摩擦を、構造として取り除こうとしています。

また重要なのは、Sales AgentがDynamics 365 Salesを置き換える存在ではない、という点です。CRMは引き続き、案件管理、顧客管理、パイプライン統制の中核を担います。一方でSales Agentは、Outlook、Teams、Copilot ChatといったMicrosoft 365の文脈の中で、営業活動の進め方そのものに影響を与え始めています。つまり、Sales Agentは「CRMの機能」ではなく、「営業の進行役」に近づいています。

Copilot agentsの領域で見えてきたのは、さらに明確な方向性です。Sales Development agentは、SDR（Sales Development Representative/インサイドセールスと言い換えてもいい）という役割をAIとして実装しました。しかしそれは、人を置き換えるためではありません。営業組織のスケールを、人の増減ではなく、構造で実現するためです。人が本当にやるべき判断と提案に集中できるように、一次対応や見極めを引き受ける。その成果を測り、改善し、育てていく前提まで含めて、設計されています。

総じて言えば、Sales Agentは「営業を賢くするAI」ではありません。「営業という役割を分解し、再構成するための基盤」です。2026 release wave 1は、その再構成が始まったことを示しています。派手なデモよりも、日々の仕事の流れの中で効いてくる改善が積み重ねられています。だからこそ、このwaveは後から評価されるwaveになる気がします。

最後に一つ、個人的に役にたった記事（How Copilot for Sales Works & How To Set It Up）をご紹介します。技術者・設計者の方は是非ご覧ください。