CRMには問い合わせや商談の情報があるのに、担当者が更新に気付かず、メールやチャットで改めて連絡している。TeamsとCRMの連携は、そんな情報伝達の負担を見直す方法の一つです。

まずは、CRMの出来事をTeamsへ通知し、担当者がCRMで内容を確認して対応結果を残す流れから検討できます。Teams内でCRM情報を見る、TeamsからCRMを更新する使い方は、必要な機能と権限を別に確認します。

この記事では、中小企業の経営者・営業責任者・業務担当者に向けて、連携の種類、Workflowsを使う通知の構成例、導入前の確認点、小さく試す手順を解説します。

1.TeamsとCRMの連携は、3つの使い方に分ける

Teamsは、会話や共有の場として使えます。CRMでは、顧客・商談・問い合わせに関連付けて、担当者や期限、対応結果を管理します。連携を考える際は、どの場面をつなぎたいかを具体化しましょう。

通知・表示・更新では、必要な構成が異なる
使い方例確認すること
CRMから通知する問い合わせ受付や担当変更を、対象のチャネルへ投稿CRMのイベント取得、送信処理、Teamsの投稿先
Teamsで情報を見るリンクや対応するアプリ・タブから、商談や顧客情報を確認認証、閲覧権限、画面・端末への対応
Teamsから更新する対応するアプリやカードから、担当や状態の変更を依頼・実行CRM API、実行者の権限、承認、結果確認
役割をつなぐ気付く・相談する場と、対応を管理する場
Teamsで進めること

必要な通知を受け取る
担当者どうしで相談する
関連するCRM情報へ移動する

CRMで整えること

顧客・商談・問い合わせを識別
担当・期限・状態を管理
確認した対応結果を記録する

運用の考え方を示す図です。Teams側の反応や会話が、CRMにどのように反映されるかは、別に設計します。

例えば、「確認しました」というTeamsの返信やリアクションだけで、CRMが自動的に対応済みへ変わるとは限りません。最初は、通知からCRMを開き、担当者が結果を記録するところまでつなげると、管理の範囲を決めやすくなります。

2.TeamsとCRMを、営業・顧客対応で使う例

何でも通知するのではなく、誰かの行動につながる出来事を選びます。次は、連携を検討するための運用例です。

通知の条件と、その後に行うことをそろえる
場面通知の例通知後の対応
新しい問い合わせ対象の種別を受け付けたとき、対応チームへ通知CRMで内容を確認し、担当と期限を決める
商談の担当変更引き継ぎ先へ、対象商談と確認事項を通知過去の経緯と次回対応を確認する
対応期限の確認期限を迎えた未完了の対象を、決めた頻度で案内担当者が対応するか、期限・状態を見直す
重要な状態変更共有が必要な段階へ変わった商談・問い合わせを通知関係者が準備し、必要な作業をCRMへ残す

これらを実現するには、CRM側で対象を判定する機能や、連携側の処理が必要です。期限の通知であれば、対象を定期的に調べる処理なども含めて検討します。

通知の文章より、担当と次の行動を明確にする

通知を読んだ人が、何を確認し、どこで対応すればよいかをわかる形にします。CRMのレコードへのリンクがあれば、権限のある担当者が詳細へ進む導線になります。

「誰かが対応するはず」という状態を避けるため、担当未定の案件を誰が確認するかも決めます。Teamsで相談した結果も、管理に必要な内容はCRMへ残します。

顧客対応の情報を確認し、チームで次の行動を相談する担当者のイラスト
必要な情報を共有し、次の対応を相談するイメージです。AI生成イラストで、実際のTeams画面やCRMの利用画面ではありません。

3.Workflowsを使って、CRMからTeamsへ通知する方法

Microsoftは、外部からのWebhook要求を受け、Teamsへメッセージを投稿するWorkflowsの使い方を案内しています。Webhookは、システムで出来事が起きた際に、指定した接続先へ情報を送る仕組みとして利用できます。[1]

ここでは、CRM側で通知対象の情報を取得し、Teamsのワークフローへ送る構成を紹介します。CRMに送信機能があるか、追加の設定・開発が必要かは、別に確認が必要です。

通知の構成例CRMの出来事から、担当者の対応へ
  1. 1.CRMで判定新規受付など、通知する対象と条件を確認
  2. 2.情報を送る必要な項目を、連携処理からWebhookへ送信
  3. 3.Teamsへ投稿Workflowsで内容を整え、対象の場所へ投稿
  4. 4.CRMで対応担当者がリンク先を確認し、対応結果を記録
構成の提案例です。WebhookはTeams側の受信口であり、CRMの設定や送信処理を自動的に作るものではありません。

① 最初に、通知する条件と投稿先を決める

例えば「営業窓口への新しい問い合わせだけ」「担当が未定のものだけ」など、対象を絞ります。投稿先のチーム、チャネル、チャットと、その参加者が情報を見る必要があるかを確認します。

送信する項目は、内容を識別して次の対応へ進むための範囲にします。CRM内の受付IDや種別、担当、期限、レコードへのリンクなどを候補にし、本文全体や添付を送る必要があるかは別に判断します。

② Teams側に、受信するワークフローを用意する

Microsoftの公式手順を参考に、次の流れで設定します。画面名や利用できるテンプレートは、環境によって確認してください。[1]

  1. TeamsのWorkflowsを開き、Webhook通知用のテンプレートを選ぶ。
  2. 送信元に合う認証方式と、投稿先のチャネル・チャットを確認する。
  3. 保存後に発行されるWebhook URLを、連携の担当者が管理する。

テンプレートによって認証方式が異なるため、CRM側の送信処理で必要な認証を行えるかを確かめます。接続用URLや認証情報は、記事やチャットへ不用意に貼り付けず、設定情報として管理します。

③ CRM側のイベント取得と、送信処理を設定する

CRMの標準機能、拡張、連携サービス、追加開発のいずれで対象を取得するかを決めます。送信する項目の名前や形式をワークフロー側と合わせ、受付IDなどで対象を識別できるようにします。

同じ出来事が再送された場合の重複投稿、送信失敗、対象レコードの削除や担当変更も考えます。CRM側とTeams側のどちらで何を記録するかを決め、途中で失敗した場所を確認できるようにします。

④ テスト用の情報で、投稿とリンク先を確認する

まずは架空の情報で、想定した場所へ正しい内容が届くかを試します。投稿の成功に加えて、担当者がCRMのリンク先を開けるか、権限のない人に見せたくない情報が投稿されていないかも確認します。

通知に含める情報の例(架空データ)

新しい問い合わせを受け付けました
受付ID:CASE-001
種別:製品についての相談
担当:未割当
次の行動:受付担当がCRMで内容を確認し、担当と期限を設定
詳細:該当するCRMレコードへのリンク

これは通知内容の編集例で、実際のTeamsカードや動作画面ではありません。宛先や表示項目は、自社の閲覧範囲に合わせて決めます。

⑤ 通知の後に、誰が何をするかを確認する

通知しただけで放置されないよう、担当未定の確認、対応開始、完了までの記録方法を決めます。通知の文章と、CRM内の状態が違う場合は、最新のCRM情報を確認して対応します。

4.TeamsでCRM情報を見る・更新する方法

まずは、CRMへのリンクで必要な画面へ進む

最初からCRM全体をTeams内へ埋め込む必要はありません。通知に対象レコードのリンクを付け、CRMで認証して確認・更新する構成から始められます。Teamsから開く場合の動作を、PCとスマートフォンで確かめましょう。

対応するアプリやタブを使う場合は、表示と認証を確認する

Teams内にCRM情報を表示したい場合は、対応する公式アプリや、業務に合わせたタブを検討します。Microsoftはタブの構築に、HTTPS、埋め込みの許可、認証などの要件を示しています。[4]

CRMのURLをタブへ登録するだけで、ログインや画面操作が同じように使えるとは限りません。埋め込み先の制限、認証の流れ、モバイルの表示を確認し、無理に制限を外さず、対応する方法を選びます。

ボタンやカードから更新する場合は、実行する処理を別に用意する

Teamsのカードへボタンを表示することと、CRMの担当や状態を変更することは別です。応答を処理するフローやAPI、CRM側の権限、実行結果の表示、同じ操作の二重実行を防ぐ処理などが必要になります。

Microsoftの移行案内でも、入力やボタンを使う場合はAdaptive Cardsと、その応答を処理するワークフローの構成が必要と説明されています。[2]単なるリアクションを、承認や業務の完了として扱わないようにしましょう。

VtigerCRMは、公式クラウド版とOSS版の案内を分ける

Vtigerの公式資料には、Teams内でのCRM情報の表示、通知、レコード共有などの案内があり、対象の公式クラウドのエディションも示されています。[5]

この案内を、OSS版VtigerCRMやvtplusに同じ機能がそのまま標準搭載されているという説明には使えません。利用中の版・バージョン・拡張と、通知・表示・更新のどこまで必要かを伝え、設定や追加開発、外部サービスの範囲を確認します。

5.権限・通知条件・所有者を決めて、運用を続ける

つながった後に使い続けるため、環境と運用の条件もそろえます。連携を選定・見積もりする際は、次の項目を整理しましょう。

事前に整理する情報
項目確認する内容
Teams・CRMの環境契約、利用できるアプリ、CRMの版・プラン・バージョン、接続方式
目的と投稿先通知・表示・更新の対象、チーム・チャネル・チャット、参加者とゲスト
対象データと権限CRMから送る項目、閲覧できる人、更新する場合の実行者と承認
通知のルール発生条件、重要度、頻度、再通知、重複、通知を止める条件
フローと接続の管理所有者、必要な共同所有者、接続の認証、異動・退職時の引き継ぎ
例外・費用・保守失敗時の確認と再実行、ログ、実行回数、必要なライセンス、追加開発・保守

Teamsの参加者と、CRMの閲覧権限を照らし合わせる

Microsoftは、Teamsアプリがデータへアクセスする際の権限や同意を説明しています。どの情報を読み、どの操作をするかに合わせて、必要な権限と管理者の確認を行います。[3]

特に、CRMのリンク先に権限があっても、Teamsへ投稿した本文は、投稿先で閲覧できる人に見えます。ゲストがいるチャネルや、参加者が変わる場へ何を表示するかを確認しましょう。

情報の分け方通知で伝える内容と、CRMで確認する詳細
Teamsに投稿する情報

共有が必要な受付ID・種別
次に確認する担当や行動
権限のあるCRM画面へのリンク

CRMで確認する情報

詳細な問い合わせや契約条件
個別の対応履歴・添付資料
権限に基づく確認と更新

情報量を考えるための例です。IDや件名も内容を推測できる場合があるため、投稿先に応じて表示項目を決めます。

通知は、確認すべきものへ絞る

全更新を投稿すると、大事な依頼が埋もれる場合があります。新規受付や担当未定、対応期限などの目的で条件を分け、まとめて確認できるものは定期的な一覧にする方法も検討します。

投稿後に担当や状態が変わることもあるため、通知時点の情報だとわかるようにします。処理が完了した場合の再通知停止など、継続して必要かを見直すルールも決めます。

フローの所有者だけでなく、接続を引き継ぐ方法も決める

Power Automateのフローは、共同所有者を追加して管理する方法があります。ただし、所有者が退職した際などに、その人の接続を使う処理が失敗する場合があり、接続の認証も更新する必要があります。[6]

共同所有者はフローの編集や実行履歴の確認などができるため、必要な管理担当者に絞ります。通知を受ける全員を共同所有者にするのではなく、実行・閲覧・管理の役割を分けて運用します。

6.小さく導入して、通知が対応につながるか確かめる

最初の試行一つの出来事と、一つの投稿先から始める
  1. 対象と完了条件を決める例:営業窓口の新しい問い合わせを通知し、担当・期限をCRMで確認できるようにする。
  2. テスト情報で構成するCRM側の取得・送信、Workflows、投稿先、認証・権限を確認する。
  3. 通常と例外を試す重複、送信失敗、認証切れ、権限外の閲覧、担当変更を対象範囲で確認する。
  4. 運用を見て対象を増やす対応開始・記録漏れ・通知量・保守負担を振り返り、条件と手順を修正する。
導入手順の提案です。実際のアプリや接続方式に合わせて、必要な設定と検証を行います。

届いた件数より、対応の進み方を確かめる

対象の問い合わせが発生してから担当者が決まるまでの時間、未対応の件数、CRMへの記録漏れ、二重対応などを見ます。通知が多すぎないか、関係のない投稿が増えていないかも確認します。

画面へ投稿されたことと、担当者が読んだこと、対応が完了したことは分けて扱います。通知の件数だけで効果を判断せず、CRMの状態と結果で確かめましょう。

ライセンスと、連携全体の費用を分けて確認する

Microsoftは、案内するWebhookテンプレートとTeams Webhookトリガーについて、Premiumライセンスは不要としています。[1]一方、CRMへ接続する追加のコネクターや処理、契約条件によって、連携全体のライセンス要件は変わります。

Teams・CRM・Power Automateなどの契約、設定・開発、動作確認、保守、運用担当者の作業時間を確認します。利用者、実行回数、必要な操作をそろえて、初期費用と継続費用を見積もります。

7.TeamsとCRMの連携でよくある質問

Teamsだけで顧客管理を行えますか?

会話やファイルを共有する使い方はできます。顧客・商談ごとに担当、期限、状態、対応履歴を継続して管理する場合は、CRMなどの管理先と更新ルールを決めておく方法があります。

CRMからの通知は、標準機能だけで設定できますか?

製品や版、導入済みの拡張、対象イベントで変わります。CRM側の送信機能とTeams側の受信・投稿を確認し、足りない部分の設定・開発・連携サービスを検討します。

Teamsのチャネルなら、どこでも同じように投稿できますか?

選んだ方式と認証、投稿先のチャネルの種類、組織の設定で確認します。本番と同じ種類の投稿先で、送信と閲覧範囲をテストしましょう。

Teamsの返信で、CRMも自動更新できますか?

必要なアプリや応答処理、CRM API、権限などを用意すれば、対象業務で検討できます。単純な通知や返信だけで更新されると考えず、実行結果の確認と二重実行の防止まで設計します。

VtigerCRMの公式Teamsアプリを、OSS版でもそのまま使えますか?

公式クラウド向けの案内を、OSS版へそのまま適用できるとは限りません。現在の版と環境、必要な通知・表示・更新の範囲を確認してください。

8.まとめ|Teamsへの通知を、CRMでの対応につなげる

TeamsとCRMの連携は、通知、情報表示、更新を分けて検討します。最初は、一つの出来事をTeamsへ通知し、担当者がCRMで確認・対応・記録する流れから試す方法があります。

Workflowsなどの投稿方式に加え、CRM側の送信処理、権限、通知条件、所有者と接続の管理を整えましょう。通知が届くことだけでなく、対応が進んでいるかを見ながら、連携範囲を広げていくことが大切です。

参考資料

  1. Microsoft Support:Send messages in Teams using incoming webhooks — Workflowsのテンプレート、認証方式、投稿先、Webhookの利用条件。
  2. Microsoft 365 Developer Blog:Retirement of Office 365 connectors within Microsoft Teams — 2026年4月14日更新の廃止案内、Workflowsへの移行とカードの扱い。
  3. Microsoft Learn:Microsoft Teams apps permissions and consent — アプリが情報へアクセスするための権限と同意。
  4. Microsoft Learn:Requirements for Building Tabs — Teams内に表示するタブの要件。
  5. Vtiger Knowledge Base:Using Vtiger CRM in Microsoft Teams — 対象の公式クラウドのエディションを伴う、表示・通知・共有の案内。
  6. Microsoft Learn:Share a cloud flow — フローの所有者、共同所有者、接続を引き継ぐ際の確認点。

参考情報確認日:2026年10月19日。図解・通知例・運用例・導入手順・効果の確認方法は編集上の提案であり、実測済みの導入事例ではありません。対応機能や利用条件は更新される場合があるため、導入時点の公式資料と実際の契約・環境で確認してください。