Microsoft Teamsを社内コミュニケーションに利用している企業では、
「業務システムで申請されたらTeamsへ通知したい」
「案件のステータス変更を担当チームへ自動通知したい」
「予約システムからTeams会議を作成したい」
といった要望が出てくることがあります。
こうした仕組みを実現する方法の一つが、Microsoft Teamsと外部システムのAPI連携です。
Teams関連の機能は、Microsoft Graph APIやTeamsのWebhook、Workflowsなどを利用して外部システムと連携できます。
例えば、
業務システム
↓
申請登録
↓
Teamsへ通知
↓
担当者が確認
という流れを自動化できます。
また、Microsoft GraphではTeamsのチャネル情報取得やチャット・チャネルへのメッセージ送信、オンライン会議の作成などのAPIが提供されています。:contentReference[oaicite:0]{index=0}
結論からいうと、Teams API連携は、
Teamsを「人がチャットするツール」として使うだけでなく、業務システムから必要な情報を自動的に届ける仕組みとして活用したい場合
に有効です。
この記事では、Microsoft Teams API連携で何ができるのか、社内通知や会議連携の具体例、WebhookやPower Automateとの使い分け、開発時の注意点を解説します。
Microsoft Teams API連携とは
「Teams API」と呼ばれるものの多くは、Microsoft Graph APIを通して利用します。
Microsoft Graphは、Microsoft 365のさまざまなサービスへアクセスするためのAPIです。
例えば、
- Microsoft Teams
- Outlook
- Microsoft 365ユーザー
- カレンダー
- OneDrive
- SharePoint
などと連携できます。
そのため、
「Teamsだけを単独で操作する」
というより、
Microsoft 365全体の情報と業務システムを連携する
という考え方が適しています。
Teams API連携でできること
代表的な活用方法を見ていきましょう。
1．業務システムからTeamsへ通知する
最も導入しやすい活用例です。
例えば経費申請システムで、
山田さん
↓
経費申請
↓
100,000円
↓
承認待ち
となったとします。
このタイミングでTeamsへ、
「新しい経費申請があります」
という通知を送ります。
例えば、
経費申請が登録されました
申請者：山田太郎
金額：100,000円
状態：承認待ち
といった内容です。
担当者が業務システムを常に開いていなくても、普段利用しているTeamsから新しい申請に気づけます。
2．案件ステータスの変更を通知する
案件管理システムとの連携も考えられます。
例えば営業案件が、
提案中
↓
受注
へ変更された場合、
営業チームのTeamsへ、
「A社案件を受注しました」
と自動通知します。
ほかにも、
- 新規案件登録
- 商談予定
- 見積提出
- 受注
- 失注
- 納期変更
- 担当者変更
などを通知できます。
ただし、すべての更新をTeamsへ送ると通知が多すぎて読まれなくなります。
Teamsへ通知するべき業務イベントを選ぶこと
が重要です。
3．在庫不足をTeamsへ通知する
在庫管理システムとの連携も有効です。
例えば、
商品A
現在庫：8個
発注点：10個
となった場合、
在庫管理システム
↓
発注点を下回る
↓
Teams通知
という処理ができます。
購買担当者のチャネルへ、
「商品Aの在庫が発注点を下回りました」
と通知すれば、在庫管理画面を常時確認する必要を減らせます。
4．予約が入ったら担当チームへ通知する
予約管理システムとの連携もできます。
例えばWebサイトから、
8月10日
14:00
オンライン相談
A株式会社
という予約が入った場合、
予約DB登録
↓
Teams通知
とします。
通知内容は、
- 会社名
- 担当者
- 予約日時
- 予約内容
- 予約詳細画面へのリンク
などです。
これにより、予約システムとTeamsを別々に確認する負担を減らせます。
5．システム障害をTeamsへ通知する
業務通知だけでなく、システム運用にも利用できます。
例えば、
バッチ処理
↓
エラー
↓
Teamsへ通知
という構成です。
通知対象には、
- バッチ処理失敗
- API連携失敗
- CSVインポート失敗
- Webhook処理失敗
- データ同期失敗
などがあります。
ただしMicrosoftは、Teamsを大量の機械ログを蓄積する「ログファイル」の代替として利用することは推奨していません。人が確認して対応する必要がある重要な通知に絞ることが適切です。:contentReference[oaicite:1]{index=1}
Teamsへの通知方法は1つではない
Teamsへ情報を送る方法には複数の選択肢があります。
代表的には、
- Workflows
- Webhook
- Microsoft Graph API
- Teams Bot
などです。
必要な機能によって使い分けます。
Webhook・Workflowsで通知する
単純に、
「外部システムでイベントが発生したらTeamsへ通知する」
という用途ならWebhook系の仕組みが候補になります。
例えば、
業務システム
↓
WebhookへPOST
↓
Teamsチャネルへ投稿
という構成です。
従来のMicrosoft 365 Connectorsは廃止に向けた移行が進められており、MicrosoftはWebhookによるTeams投稿についてWorkflowsアプリの「When a Teams webhook request is received」などを案内しています。新規開発では現在のMicrosoft公式仕様を確認して方式を選ぶことが重要です。:contentReference[oaicite:2]{index=2}
Microsoft Graph APIでメッセージを送る
より高度なTeams連携ではMicrosoft Graph APIを利用します。
Microsoft Graphには、指定したチャネルやチャットへメッセージを送信するAPIがあります。:contentReference[oaicite:3]{index=3}
概念的には、
業務システム
↓
Microsoft Graph API
↓
Teams
↓
指定したチャネルへ投稿
という流れです。
Graph APIを使う場合は、
- Microsoft Entra IDでのアプリ登録
- OAuth認証
- アクセストークン
- API権限
などの設計が必要になります。
Webhookより実装は複雑になりますが、TeamsやMicrosoft 365と深く連携したい場合に適しています。
6．Teams・チャネル情報を取得する
Microsoft Graph APIでは、チームに含まれるチャネル一覧などを取得できます。:contentReference[oaicite:4]{index=4}
例えばシステムの設定画面で、
通知先Teams
↓
営業部
通知先チャネル
↓
受注報告
と選択できるようにする構成です。
管理者がTeamsやチャネルのIDを直接調べる必要がなくなります。
7．Teams会議を作成する
Microsoft Graph APIではTeamsオンライン会議の作成も可能です。:contentReference[oaicite:5]{index=5}
例えばオンライン相談システムなら、
顧客
↓
予約
↓
Teams会議作成
↓
参加URL取得
↓
顧客へメール送信
という仕組みを作れます。
具体的には、
- 顧客が日時を予約
- 予約データを登録
- Microsoft Graph APIでオンライン会議作成
- Teams参加URLを取得
- 予約データへ保存
- 顧客・担当者へ案内
という流れです。
採用面接やオンライン商談などにも利用できます。
Teams会議とOutlook予定は同じではない点に注意する
Microsoft Graphのオンライン会議APIで作成するonlineMeetingは、単独ではユーザーのカレンダーに予定として表示されないAPIもあります。:contentReference[oaicite:6]{index=6}
そのため、
「Teams会議URLを作りたい」
のか、
「Outlookカレンダーにも予定として登録したい」
のかを要件定義で分けることが重要です。
例えば、
予約
↓
Outlook予定作成
↓
Teams会議情報設定
という構成が適している場合もあります。
8．Teamsのメッセージ変更を検知する
Microsoft GraphにはChange Notificationsという仕組みがあります。
これを利用すると、
- チャネルメッセージ作成
- チャットメッセージ作成
- 更新
- 削除
などの変更を購読できます。:contentReference[oaicite:7]{index=7}
例えば、
Teams
↓
特定チャネルへ投稿
↓
変更通知
↓
自社システム
↓
業務処理
という連携が考えられます。
ただし単純な社内通知だけであれば、ここまで複雑な構成は必要ない場合があります。
9．Teamsから業務システムへつなげる
Teams API連携は、
業務システム
↓
Teams
だけではありません。
例えば、
Teams上で問い合わせ
↓
Bot
↓
業務システム
↓
案件情報取得
↓
Teamsへ回答
という仕組みも考えられます。
例えば営業担当者がTeamsで、
「A社の次回商談日は？」
と入力すると、
顧客・案件管理システムから情報を検索して、
「8月15日 13:00です」
と回答する仕組みです。
生成AIを組み合わせれば、
Teams
↓
AI
↓
社内データ検索
↓
回答
という社内AIアシスタントへ発展させることもできます。
Teams連携の具体例｜申請承認システム
例えば社内の購入申請をWebシステムで管理しているとします。
現在
社員
↓
申請システムへ登録
↓
上司は申請画面を確認
↓
承認
この場合、上司がシステムを開かなければ新しい申請に気づけません。
Teamsと連携すると、
社員
↓
購入申請
↓
DB登録
↓
Teams通知
とできます。
例えば、
新しい購入申請があります
申請者：山田太郎
商品：モニター
金額：45,000円
状態：承認待ち
という通知です。
さらに、
「申請を確認する」
リンクから業務システムの詳細画面へ移動できます。
Teams上で直接承認するべきか
ここは要件によって判断します。
例えば、
Teams
↓
「承認」ボタン
↓
承認完了
まで実装すると便利です。
一方で、
- 誤操作
- 本人確認
- 権限
- 操作ログ
- 承認コメント
なども考える必要があります。
重要な承認業務であれば、
Teamsは通知だけに利用し、正式な承認は業務システムで行う
設計も有効です。
例えば、
Teams通知
↓
「詳細を確認」
↓
業務システム
↓
ログイン
↓
承認
とすれば、正式な業務データや操作ログを一元管理できます。
Teamsを業務データの保存先にしない
Teams連携で注意したい考え方です。
例えば、
「Teamsに通知したから申請データはTeamsだけで管理する」
という設計ではなく、
業務システム
↓
正式なデータ
Teams
↓
通知・コミュニケーション
と役割を分ける方法があります。
特に、
- 顧客
- 契約
- 申請
- 承認
- 在庫
- 予約
などは自社システム側で正式なデータとして保持するほうが管理しやすくなります。
Teamsは、
必要なタイミングで担当者へ情報を届けるインターフェース
として利用します。
Teams通知で最も重要なのは「通知しすぎない」こと
API連携ができるようになると、さまざまなイベントを通知したくなります。
例えば案件管理なら、
- 案件登録
- 案件更新
- 担当者変更
- ステータス変更
- コメント追加
- 金額変更
などです。
これをすべてTeamsへ通知すると、重要なメッセージが埋もれます。
例えば、
通知する
- 新規問い合わせ
- 受注
- 承認依頼
- 期限超過
- システム障害
通知しない
- 説明文の軽微な変更
- 表示順変更
- 管理者による内部修正
のように分類します。
「システム上でイベントが起きた」
ではなく、
そのイベントを知った人が何らかの行動をする必要があるか
を基準にすると整理しやすくなります。
Teams連携ではリンクを付けると使いやすい
通知にすべての情報を表示する必要はありません。
例えば、
新しい問い合わせがあります
A株式会社
Webシステム開発について
という通知とともに、
「問い合わせ詳細を見る」
リンクを付けます。
すると、
Teams
↓
通知確認
↓
詳細リンク
↓
業務システム
という導線を作れます。
Teamsを業務システムの代わりにするのではなく、入口として利用できます。
Teams API連携の認証・権限
Microsoft Graph APIを利用する場合、認証と権限設計が重要です。
例えば、
- チャネル一覧を読む
- メッセージを送信する
- 会議を作成する
- ユーザー情報を取得する
では必要な権限が異なります。
Microsoft Graphでは各APIごとに最小特権のアクセス許可が示されており、必要以上に広い権限を与えないことが重要です。例えばチャネル一覧取得ではChannel.ReadBasic.Allなど、チャネルへのメッセージ送信では委任権限のChannelMessage.Sendなどが用意されています。:contentReference[oaicite:8]{index=8}
Delegated PermissionとApplication Permission
Microsoft Graphでは、大きく分けてユーザーとしてアクセスする方法と、アプリケーションとしてアクセスする方法があります。
Delegated Permission
ログインしているユーザーの権限を利用します。
例えば、
山田さん
↓
Microsoftアカウントで認証
↓
山田さんとしてTeams APIを利用
というイメージです。
Application Permission
ユーザー操作とは独立して、システムがバックグラウンドで処理する場合などに利用されます。
ただしTeams APIでは、操作によってApplication Permissionが利用できなかったり、追加の管理者設定が必要だったりします。
例えばTeamsチャネルへの通常のメッセージ送信APIでは、Application Permissionは移行用途に限定されています。:contentReference[oaicite:9]{index=9}
そのため、
「バックエンドからTeamsへ投稿したいからApplication Permissionを付ければよい」
と単純には決められません。
利用したい機能ごとにMicrosoft公式仕様を確認する必要があります。
Teams通知だけならGraph APIが最適とは限らない
例えば要件が、
「システム障害時に開発チームのチャネルへ通知する」
だけなら、Microsoft GraphのOAuth認証まで実装する必要性は低い場合があります。
Workflowsを使ったWebhookのほうがシンプルなことがあります。
一方、
- チーム・チャネルを取得したい
- ユーザーと連携したい
- メッセージを取得したい
- Teams会議を作りたい
- Microsoft 365全体と連携したい
のであれば、Microsoft Graphを利用する価値があります。
Teams API・Webhook・Workflows・Botの使い分け
大まかには次のように整理できます。
| 方法 | 向いている用途 |
|---|---|
| Workflows・Webhook | 外部システムからのシンプルな通知 |
| Microsoft Graph API | Teams・ユーザー・会議などとの本格的な連携 |
| Teams Bot | Teams内での双方向コミュニケーション |
| Power Automate | ノーコード・ローコード中心の業務自動化 |
例えば、
「在庫不足をTeamsへ通知」
だけならWebhook・Workflows。
「Teams上で在庫数を質問すると回答」
ならBot。
「社員やチーム情報を取得して自社システムと連携」
ならMicrosoft Graph。
というように、目的から選びます。
API連携するかPower Automateにするか
小規模な社内業務ならPower Automateで十分なケースもあります。
例えば、
Microsoft Forms
↓
申請
↓
Teams通知
程度なら、システム開発をしなくても実現できる可能性があります。
一方、
- 独自の業務システムと連携する
- 複雑な条件分岐がある
- 大量データを扱う
- 独自DBと連携する
- 詳細な操作ログが必要
- 独自UIが必要
といった場合は、APIを利用したWebシステム開発を検討する価値があります。
Teams連携でエラーが起きた場合も考える
例えば、
案件登録
↓
DB保存成功
↓
Teams通知失敗
となることがあります。
この場合、
「Teams通知に失敗したから案件登録も失敗」
としてしまうと、Teams側の一時障害が主要業務に影響します。
そこで、
案件登録
↓
正常完了
↓
Teams通知
↓
失敗したら再試行
という構成が考えられます。
重要なのは、
Teams通知と本来の業務処理を必要以上に強く依存させないこと
です。
非同期処理・ジョブキューとの相性がよい
Teamsへの通知は、バックグラウンド処理にする方法があります。
例えば、
申請登録
↓
DB保存
↓
通知ジョブ作成
↓
画面へ正常応答
その後、
Worker
↓
Teams API
↓
通知
という構成です。
Microsoft GraphにはAPIごとの制限もあるため、大量通知を行う場合はレート制限やリトライも考慮する必要があります。
従来型Incoming WebhookについてもMicrosoft公式ドキュメントではリクエスト数の制限と、制限時の指数バックオフが案内されています。:contentReference[oaicite:10]{index=10}
Teams側の変更を検知する場合はWebhook受信も必要
Microsoft GraphのChange Notificationsを利用する場合、自社システム側に通知を受け取るHTTPSエンドポイントを用意します。
概念的には、
Teams
↓
Microsoft Graph
↓
変更通知
↓
自社Webhook
↓
業務処理
となります。
さらにサブスクリプションには有効期限があり、更新やライフサイクル通知への対応も必要です。TeamsリソースのChange Notificationsでは、一定条件のサブスクリプションでライフサイクル通知の設定が必要になります。:contentReference[oaicite:11]{index=11}
単純な通知送信より設計は複雑になるため、本当に双方向連携が必要かを先に確認しましょう。
Teams API連携の具体的な設計例
例えば顧客問い合わせ管理システムを考えます。
問い合わせ受付
Webサイト
↓
問い合わせフォーム
↓
DB登録
Teams通知
DB登録成功
↓
通知ジョブ
↓
Teams
Teamsへ表示
新しいお問い合わせがあります
会社名：A株式会社
内容：在庫管理システムについて
担当：未設定「問い合わせ詳細を見る」
担当者
Teams通知
↓
詳細画面
↓
担当者設定
↓
対応開始
この仕組みなら、Teamsそのものへ問い合わせ情報をすべて保存する必要はありません。
正式な情報は問い合わせ管理システムへ保存し、Teamsは担当者へ知らせるために使います。
【コピペ用】Teams API連携の要件整理チェックリスト
目的
- [ ] Teamsへ業務通知を送りたい
- [ ] チャネルへメッセージを投稿したい
- [ ] チャットと連携したい
- [ ] Teams会議を作りたい
- [ ] Teamsのユーザー情報を利用したい
- [ ] チーム・チャネル情報を取得したい
- [ ] Teams側の変更を検知したい
通知
- [ ] 何を通知するか決める
- [ ] 誰へ通知するか決める
- [ ] チャネルを決める
- [ ] 通知頻度を確認する
- [ ] 業務システムへのリンクを付ける
- [ ] 通知しすぎないようイベントを絞る
連携方式
- [ ] Workflowsで対応できるか確認する
- [ ] Webhookで対応できるか確認する
- [ ] Microsoft Graph APIが必要か確認する
- [ ] Teams Botが必要か確認する
- [ ] Power Automateで対応できるか確認する
Microsoft Graph
- [ ] Microsoft Entra IDでアプリ登録する
- [ ] 必要なAPI権限を整理する
- [ ] Delegated PermissionかApplication Permissionか確認する
- [ ] 管理者同意が必要か確認する
- [ ] 必要最小限の権限にする
エラー対応
- [ ] Teams通知失敗で本来の業務を止めない
- [ ] リトライ方法を決める
- [ ] 通知失敗をログへ残す
- [ ] 必要に応じてジョブキューを利用する
- [ ] 大量通知時のレート制限を考慮する
セキュリティ
- [ ] アクセストークンを安全に管理する
- [ ] Secretをソースコードへ直接記載しない
- [ ] Webhook URLを適切に管理する
- [ ] 認証情報をログへ出力しない
- [ ] 不要なAPI権限を与えない
すべてを最初から決める必要はありません。
例えば、
「問い合わせが入ったら営業チームのTeamsへ通知したい」
という要求からでも、Workflowsで十分なのか、Microsoft Graph APIが必要なのかを整理できます。
Teams API連携でよくある失敗
Teams APIという1つのAPIがあると思って設計する
実際には、
- Microsoft Graph
- Workflows
- Webhook
- Bot
など複数の仕組みがあります。
やりたいことから適切な方法を選びましょう。
単純な通知なのにGraph APIを使う
OAuthや権限管理が必要になり、システムが必要以上に複雑になる場合があります。
Webhook・Workflowsで十分かを先に確認します。
必要以上に広いAPI権限を付与する
「動かないから権限を広げる」
という方法は避けたほうがよいでしょう。
必要なAPIごとに最小権限を確認します。
全イベントをTeamsへ通知する
通知が大量になると、本当に重要な通知が読まれなくなります。
業務上のアクションが必要なイベントを中心に通知します。
Teams通知失敗で業務処理まで失敗する
Teamsは外部サービスです。
通知が一時的に失敗しても、
- 申請
- 注文
- 予約
- 問い合わせ
などの本来のデータを失わない構成にしましょう。
Teamsを業務システムそのものとして使う
Teamsはコミュニケーションには優れていますが、複雑な顧客管理や案件管理、申請管理をすべてチャットだけで行うと情報を検索・集計しにくくなることがあります。
正式なデータと通知を分けることが重要です。
Teams API連携に関するよくある質問
TeamsへAPIからメッセージを送れますか？
可能です。
Microsoft Graphにはチャネルやチャットへメッセージを送信するAPIがあります。ただし利用するシナリオによって認証方式や必要な権限が異なります。:contentReference[oaicite:12]{index=12}
WebhookだけでもTeamsへ通知できますか？
単純な外部システムからの通知であれば可能です。
現在はMicrosoft 365 Connectorsの廃止に向けた移行が進んでいるため、新規構築ではTeams Workflowsを利用したWebhookなど、Microsoftが案内している現在の方式を確認して選択することが重要です。:contentReference[oaicite:13]{index=13}
Teams会議をAPIで作成できますか？
Microsoft Graphのオンライン会議APIを利用してTeams会議を作成できます。ユーザーとして作成する方法や、管理者による設定を前提にアプリケーションからユーザーに代わって作成する方法があります。:contentReference[oaicite:14]{index=14}
Teamsの投稿を自社システムで取得できますか？
Microsoft GraphにはTeamsのチャネル・チャットメッセージを取得したり、変更通知を購読したりするAPIがあります。
ただし、権限やライセンス・課金要件が関係するAPIもあるため、対象機能ごとに確認が必要です。:contentReference[oaicite:15]{index=15}
Teamsと業務システムを双方向連携できますか？
機能によって可能です。
例えば業務システムからTeamsへ通知し、Teams側のメッセージ変更をChange Notificationsで受け取る構成などがあります。
ただし一方向通知より実装・運用が複雑になるため、双方向にする必要性を確認したほうがよいでしょう。
Power AutomateとAPI開発はどちらがよいですか？
簡単なMicrosoft 365内の自動化ならPower Automateが適していることがあります。
一方、
- 独自Webシステム
- 独自DB
- 複雑な処理
- 大量データ
- 独自画面
- 詳細な権限制御
が必要なら、Microsoft Graph APIを利用したシステム開発を検討する価値があります。
hiro-dev-labではTeams連携を含めた業務システム開発を相談できます
Teamsを日常的に利用している企業では、
「システムには情報が入っているが、担当者が気づかない」
という課題が発生することがあります。
例えば、
現在
問い合わせフォーム
↓
管理画面へ登録
↓
営業担当が管理画面を確認
という業務なら、
改善後
問い合わせフォーム
↓
DB登録
↓
Teamsへ自動通知
↓
営業担当が詳細画面を確認
という仕組みにできます。
hiro-dev-labでは、現在の業務フローを確認しながら、
- 業務ヒアリング
- 要求整理
- 要件定義
- Microsoft Teams連携
- Microsoft Graph API連携
- Webhook設計
- API連携
- 認証・権限設計
- Webシステム開発
- 業務自動化
- AI連携
などを検討できます。
最初から、
「Microsoft Graphを使いたい」
と技術を決める必要はありません。
例えば、
「申請されたらTeamsへ通知したい」
という要求であれば、Workflowsで十分なのか、Graph APIまで必要なのかを比較できます。
重要なのはAPIを利用することそのものではなく、現在発生している確認・転記・通知作業を減らすことです。
まとめ｜Teams API連携は「業務システムの情報を必要な人へ届ける」ために使う
Microsoft Teams API連携を活用すると、
- 業務システムからTeamsへ通知する
- チャネルへメッセージを送る
- チーム・チャネル情報を取得する
- Teams会議を作成する
- メッセージ変更を検知する
- Botから業務システムと連携する
といった仕組みを作れます。
特に中小企業の業務システムでは、
問い合わせ
↓
Teams通知
申請
↓
Teams通知
在庫不足
↓
Teams通知
予約
↓
Teams通知
といった比較的シンプルな連携だけでも、確認漏れや管理画面の巡回を減らせる可能性があります。
一方で、
「Teamsと連携する＝Microsoft Graph APIを使う」とは限りません。
単純な通知ならWorkflows・Webhook、双方向の対話ならBot、TeamsやMicrosoft 365の情報を本格的に扱うならMicrosoft Graph APIというように、目的に合わせて選択することが重要です。
また、正式な顧客・案件・申請・予約データは業務システム側へ保存し、Teamsは通知やコミュニケーションのために使うと役割を整理しやすくなります。
現在、
「業務システムを確認しないと新しい依頼に気づけない」
「担当者へ毎回チャットで連絡している」
「Teamsと別システムへ同じ内容を入力している」
という作業があるなら、Teams API連携やWorkflowsによる自動化を検討する価値があります。