kintoneとTeams連携の設計方法｜Power Automateと通知条件を整理する

kintoneとMicrosoft Teamsを連携したい会社では、Microsoft 365がすでに社内基盤になっていることが多いです。

チャットはTeams。

予定はOutlook。

ファイルはSharePointやOneDrive。

承認や通知はPower Automate。

業務データはkintone。

このように分かれていると、kintoneの更新や申請をTeamsへ出したくなります。

問い合わせが登録されたらTeamsへ投稿したい。

申請が承認待ちになったら担当者へ知らせたい。

期限が近いタスクをTeamsへ出したい。

kintoneのレコードからOutlook予定を作りたい。

添付ファイルをSharePointやOneDriveへ置きたい。

Teamsのチャネルで通知を見ながら、kintoneで対応状態を管理したい。

ただし、ここを設計せずに連携すると、次のような状態になります。

• Teamsのチャネルに通知は出るが、誰が対応するのか分からない
• Power Automateのフロー所有者が異動・退職して、連携が止まる
• 個人アカウントの接続で作ったため、認証切れや権限変更に弱い
• Teamsチャネルが増えすぎ、通知先が分からなくなる
• kintoneには未対応のまま、Teams上の会話だけで終わる
• Outlook予定、Teams投稿、SharePointファイルが同じレコードと結びつかない
• ゲストスペースや権限の制約を知らずに設計してしまう
• 投稿失敗、再実行、保留一覧の運用がない
• 従来のTeamsコネクタやWebhook前提で作り、移行時に詰まる

Teamsは、気づき、会話し、共同作業する場所です。

kintoneは、業務データと対応状態を残す場所です。

Microsoft 365は、予定やファイルや承認の周辺基盤です。

この役割を分けることが、kintoneとTeams連携の出発点です。

kintoneとTeams連携で最初に決めるべきなのは、通知をTeamsへ出す方法ではなく、kintone、Teams、Outlook、SharePoint/OneDriveの役割分担です。

この記事では、kintoneとTeams連携を、通知設定ではなく、Microsoft 365利用企業向けの業務設計として整理します。

kintone通知の設計方法はこちら
kintone Webhookの設計方法はこちら
kintoneプロセス管理の設計方法はこちら
kintone外部連携の設計方法はこちら

Teams連携で解決したい業務を決める

kintoneとTeams連携では、最初に何を解決したいかを分けます。

「Teamsに通知したい」だけでは、設計が広すぎます。

目的	Teamsの役割	kintoneの役割
新規受付を知らせる	チャネルへ投稿して気づかせる	問い合わせや申請の正本を持つ
担当者に作業依頼する	個人チャットやメンションで知らせる	担当者、期限、状態を持つ
承認待ちを知らせる	承認者へ通知する	プロセス管理と承認履歴を持つ
期限超過を共有する	管理者チャネルへ投稿する	未対応一覧、期限超過一覧を持つ
Outlook予定を作る	予定への導線を共有する	日時、参加者、目的を持つ
SharePoint/OneDriveへファイルを置く	ファイルへの導線を共有する	業務レコードとファイルURLを持つ
重大アラートを出す	専用チャネルへ即時共有する	重要度、責任者、対応状態を持つ

通知を出すだけなら、Teams投稿で終わります。

しかし、業務として回すなら、対応状態をkintoneに戻します。

Teams上で「対応します」と返信しても、kintoneの担当者、期限、ステータスが変わらなければ、未対応管理には使えません。

反対に、kintone側に担当者と期限があり、Teamsはそのレコードへ戻る導線であれば、会話が流れても業務状態は残ります。

Teamsは対応のきっかけ、kintoneは対応状態の正本として分けると、通知が増えても業務が崩れにくくなります。

Power Automate・連携コネクタ・Webhookの違い

kintoneとTeamsをつなぐ方法は複数あります。

代表的には、Power Automate、サイボウズの連携コネクタ、TeamsのWorkflowsによるWebhook、個別API連携があります。

方法	向いているケース	注意点
Power Automate	Microsoft 365の承認、Teams投稿、Outlook、SharePoint連携	有償プラン、OAuth設定、フロー所有者、接続管理を確認する
連携コネクタ	kintoneとMicrosoft 365をノーコードでつなぐ	対応できる処理範囲と運用ログを確認する
Teams WorkflowsのWebhook	外部からTeamsチャネルやチャットへ投稿する	ワークフロー所有者、レート制限、投稿形式を管理する
kintone Webhook	kintoneのレコード操作を外部へ知らせる	受信側でPower AutomateやAPI処理を設計する
個別API連携	厳密な条件分岐、再実行、監査ログが必要	開発、認証、監視、保守が必要

kintone公式ヘルプでは、Microsoft Power Automateとkintoneを連携するには、Power Automateの有償プランが必要で、cybozu.com共通管理の外部連携でOAuthを有効にし、利用ユーザーを許可する必要があると説明されています。

また、ゲストスペース内のアプリとは連携できないことも案内されています。

kintoneヘルプ：Microsoft Power Automateとkintoneを連携する

サイボウズのcybozu developer networkでは、連携コネクタを使って、kintoneの通知をMicrosoft Teamsチャネルへ自動投稿する方法が紹介されています。

cybozu developer network：kintoneの通知をTeamsに送信する方法

Microsoft Learnでは、TeamsのWorkflowsアプリを使うと、Webhookリクエストを受け取り、TeamsのチャネルやチャットへメッセージやAdaptive Cardを投稿できると説明されています。

一方で、Workflowsは特定ユーザーに紐づくため、共同所有者を設定しないと所有者不在のフローになるリスクがあることも説明されています。

Microsoft Learn：Create Incoming Webhooks

連携方法は、技術の好みではなく、次の観点で選びます。

観点	確認すること
通知先	チャネル、個人チャット、グループチャットのどれか
条件分岐	重要度、部署、担当者、期限で分けるか
Microsoft 365連携	Outlook、SharePoint、OneDrive、承認まで扱うか
所有者	個人フローか、共同所有者を持つ業務フローか
認証	OAuth、接続ユーザー、権限、更新手順を管理できるか
失敗時	失敗通知、保留一覧、再実行を作れるか

Teams通知のチャネル設計

Teams通知で最も起きやすい失敗は、チャネル設計です。

チャネルが少なすぎると、すべての通知が混ざります。

チャネルが多すぎると、誰も見なくなります。

設計では、業務責任者が見る単位で分けます。

通知内容	推奨するTeams設計
新規問い合わせ	受付チームのチャネル
承認依頼	承認者への個人通知、承認者チームのチャネル
経理確認	経理確認チャネル
障害・重大クレーム	専用の緊急チャネル
期限超過	管理者チャネル、日次まとめ
作業完了	後続工程の担当チャネル
予定作成	関係者のチャット、予定リンク共有
ファイル保存	対象業務のチャネルにSharePoint/OneDriveリンクを共有

Teamsに出す文面は短くします。

詳細を全部出すと、個人情報や契約条件がTeamsに広がりすぎます。

Teamsに出す情報	kintoneに残す情報
件名、状態、担当、期限、kintone URL	詳細本文、添付、履歴、承認理由
重要度、次にしてほしいこと	正式なステータス、作業ログ
Outlook予定やSharePointリンク	予定の元データ、ファイルの責任範囲

Teams通知は、会話の入口です。

正式な状態変更はkintoneで行います。

Teamsチャネルには概要と導線だけを出し、詳細データ、承認履歴、対応完了はkintoneに残します。

Outlook予定・SharePoint・OneDriveとの連携

Microsoft 365環境では、Teams通知だけでなく、Outlook予定、SharePoint、OneDriveも関係します。

ここを分けないと、Teams投稿が増えるだけで、予定やファイルの正本が散らばります。

連携先	使いどころ	kintone側で持つ項目
Outlook予定	訪問、面談、作業予定、社内会議	開始日時、終了日時、参加者、予定ID、URL
SharePoint	チームで管理する業務ファイル	フォルダURL、ファイルURL、管理責任者
OneDrive	個人作業中の一時ファイル	原則、正式保管場所にしない
Teamsチャネル	通知、会話、共有	投稿先、投稿日時、投稿URL
Planner/Tasks	チームタスク管理	使う場合はkintoneタスクとの役割を分ける

たとえば、kintoneの訪問予定アプリからOutlook予定を作る場合、Teamsには「予定を作成しました」と投稿するだけにします。

予定の日時、参加者、会議URLはOutlookが正本です。

kintoneには、予定ID、予定URL、元レコード、作成日時、作成者を残します。

ファイルの場合も同じです。

kintoneレコードに添付ファイルを大量に置くのではなく、SharePointに正式なファイルを置き、kintoneにはリンク、ファイル種別、保管期限、責任者を持たせる設計が向きます。

Teamsには、SharePointファイルへの導線を出します。

kintoneデータ連携の設計方法はこちら

Microsoft Learnでは、Power AutomateのTeamsアクションとして、Flow botやユーザーとしてチャットやチャネルにメッセージを投稿する方法、ユーザーへのメンションを組み合わせる方法が説明されています。

また、Teamsメッセージ送信アクションには、プライベートチャネルへの投稿に未対応などの制限も案内されています。

Microsoft Learn：Send a message in Teams using Power Automate

このような制約を前提に、Teamsに何を任せるかを決めます。

承認・担当者変更・期限通知の設計

kintoneとTeams連携でよくある用途は、承認、担当者変更、期限通知です。

ただし、それぞれ設計が違います。

用途	kintone側	Teams側
承認依頼	プロセス管理、作業者、承認履歴	承認者へ通知、承認待ち一覧への導線
差し戻し	差し戻し理由、修正対象項目	申請者へ通知
担当者変更	担当者フィールド、引き継ぎコメント	新担当者へ通知
期限前通知	期限、重要度、未対応条件	担当者へリマインド
期限超過	期限超過一覧、上長確認	管理者チャネルへ日次投稿
完了通知	完了日時、完了者、次工程	後続担当へ通知

承認では、Teams上の「了解しました」だけで完了にしない方がよいです。

承認履歴はkintoneに残します。

Teamsには、承認待ちレコードへのリンク、期限、申請者、判断してほしい内容を出します。

担当者変更では、旧担当者と新担当者の責任分界を決めます。

Teams通知だけで引き継ぎを済ませると、後から経緯が追えません。

kintoneに引き継ぎコメント、変更日時、変更者を残します。

期限通知では、個別通知とまとめ通知を分けます。

期限前は担当者へ個別通知。

期限超過は管理者チャネルへまとめ通知。

このようにすると、通知量を抑えながら、滞留を見えるようにできます。

フロー所有者と認証切れ対策

Power AutomateやTeams Workflowsを使う場合、フロー所有者と認証管理は必ず設計します。

実務で多いのは、担当者が自分のアカウントでフローを作り、そのまま業務で使ってしまうパターンです。

最初は動きます。

しかし、担当者が異動・退職したり、パスワード変更、ライセンス変更、多要素認証、権限変更があったりすると、連携が止まります。

リスク	対策
フロー所有者が不在になる	共同所有者、管理者、引き継ぎ手順を設定する
接続ユーザーの権限が足りない	連携用アカウントや接続権限を整理する
認証が切れる	期限、再認証担当、通知先を決める
Teamsチャネルが削除される	投稿先ID、代替チャネル、失敗通知を持つ
SharePointフォルダ権限が変わる	フォルダ責任者と権限変更手順を決める
kintone項目が変更される	項目マッピングと変更履歴を残す

Microsoft LearnのTeams Webhookページでも、Workflowsが特定ユーザーに紐づくこと、共同所有者がいないと所有者不在のフローになり得ることが説明されています。

この点は、業務連携では重要です。

フローは「作った人の便利設定」ではなく、業務システムの一部として管理します。

少なくとも次を残します。

管理項目	内容
フロー名	何の業務フローか分かる名前
所有者	主担当、共同所有者、管理者
接続	kintone、Teams、Outlook、SharePointの接続情報
実行条件	どの状態で動くか
投稿先	チーム、チャネル、チャット
項目マッピング	kintone項目とTeams文面、予定、ファイルの対応
失敗時通知	どこへ通知するか
再実行手順	誰が、どのレコードから再実行するか

Power AutomateやTeams Workflowsは、作成者個人の設定ではなく、所有者・共同所有者・接続・再実行手順まで含めて管理します。

失敗通知と再実行

Teams連携は、必ず失敗します。

認証が切れる。

投稿先チャネルが変わる。

対象ユーザーが存在しない。

Teams側の制限に当たる。

kintone側の項目名や選択肢が変わる。

Power Automateのアクションが失敗する。

SharePointフォルダの権限が足りない。

Outlook予定の参加者メールアドレスが不正。

この前提で、連携ログを作ります。

ログ項目	内容
実行日時	いつ動いたか
対象レコード	kintoneレコード番号、アプリ名
連携種別	Teams投稿、Outlook予定、SharePoint保存など
実行元	Power Automate、連携コネクタ、Webhook、個別API
結果	成功、失敗、保留、再実行済み
エラー内容	認証、権限、投稿先、項目不足、制限など
通知先	管理者チャネル、担当者、フロー所有者
再実行可否	そのまま再実行できるか、修正が必要か

失敗通知の送り先も分けます。

失敗	通知先	対応
認証切れ	フロー所有者、管理者	再認証、接続確認
投稿先なし	Teams管理者、業務責任者	チャネル確認、投稿先変更
項目不足	kintone入力担当	対象レコード修正
権限不足	M365管理者、kintone管理者	権限確認
一時的な制限	システム管理者	待機、再試行、通知量見直し
ファイル保存失敗	業務担当、管理者	SharePoint/OneDrive権限確認

Teams投稿が失敗したとき、Teamsには通知できません。

そのため、kintone側に保留一覧を用意します。

失敗した通知、未送信の予定、保存できなかったファイル、再実行待ちのレコードを一覧で見られるようにします。

kintone連携サービスの選び方はこちら

よくある失敗

kintoneとTeams連携でよくある失敗を整理します。

失敗	原因	対策
Teamsに投稿されるが誰も対応しない	通知先だけ決め、担当者と期限がない	kintoneの担当者、期限、未対応一覧を正本にする
チャネルが乱立する	業務責任者の単位で分けていない	受付、承認、経理、緊急など責任単位で整理する
個人フローが止まる	作成者のアカウントに依存している	共同所有者、接続管理、引き継ぎ手順を持つ
認証切れに気づかない	失敗通知と保留一覧がない	失敗時の通知先と再実行手順を作る
kintoneと予定がずれる	Outlook予定IDをkintoneに残していない	予定ID、予定URL、最終同期日時を持つ
ファイルの場所が分からない	SharePoint/OneDriveリンクをkintoneに残していない	ファイルURL、フォルダURL、責任者を持つ
Teamsで承認したつもりになる	正式な承認履歴がkintoneにない	承認はkintoneプロセス管理に残す
古いWebhook前提で作る	Microsoft側の移行方針を見ていない	Workflows/Power Automate前提で設計する
投稿文が長すぎる	レコード本文をそのまま出している	Teamsには概要とURLだけ出す

特に危ないのは、Teamsを業務台帳の代わりにすることです。

Teamsは会話には向きます。

しかし、未対応、承認待ち、期限超過、再実行待ちを正式に管理する場所には向きません。

Teamsで気づき、kintoneで状態を更新する。

この分け方を守る方が、連携後の運用は安定します。

実装前チェックリスト

kintoneとTeamsを連携する前に、次を確認します。

チェック	確認内容
目的	通知、承認、予定、ファイル、期限超過のどれを扱うか
正本	kintone、Teams、Outlook、SharePoint/OneDriveの役割を分けたか
投稿先	チーム、チャネル、チャット、メンションを決めたか
通知条件	新規、担当変更、承認待ち、期限超過、完了などを絞ったか
連携方法	Power Automate、連携コネクタ、Workflows、Webhook、個別APIを選んだか
所有者	フロー所有者と共同所有者を設定したか
認証	kintone OAuth、Microsoft 365接続、利用ユーザーを管理できるか
ゲストスペース	対象アプリが連携できる場所にあるか
ファイル	SharePoint/OneDriveの保管場所、権限、URLを決めたか
予定	Outlook予定ID、予定URL、参加者をkintoneに残すか
ログ	成功、失敗、再実行可否を記録するか
見直し	不要通知、停止フロー、所有者不在を棚卸しするか

このチェックをせずにTeams連携を作ると、最初は便利に見えても、通知量、所有者、認証、ファイル管理で詰まります。

Teamsに出すことより、Teamsからkintoneへ戻って業務が進むことを重視します。

Bitlightに相談できること

Bitlightでは、kintoneとTeams連携を、Microsoft 365環境に合わせた業務フローとして設計できます。

たとえば、次のような相談に対応できます。

• kintoneの通知条件、プロセス管理、担当者、期限を前提にしたTeams通知設計
• Power Automate、連携コネクタ、Teams Workflows、Webhook、個別APIの使い分け
• Teamsチャネル、個人チャット、メンション、日次まとめ通知の設計
• Outlook予定、SharePoint/OneDriveファイルとkintoneレコードの紐づけ
• フロー所有者、共同所有者、接続ユーザー、認証切れ対策の整理
• 失敗通知、保留一覧、再実行、連携ログの設計
• 既存Power AutomateフローやTeams通知の棚卸し
• M365管理者、kintone管理者、業務担当者の責任分界の整理

kintoneとTeams連携は、通知をTeamsへ流すだけなら短く作れます。

しかし、業務で使い続けるなら、Teamsは気づきと会話、kintoneは業務状態、Outlookは予定、SharePoint/OneDriveはファイル、Power Automateは連携処理として分けます。

kintoneとTeams連携は、Teams通知を増やす設計ではなく、Microsoft 365の各ツールからkintoneの未対応レコードへ戻る設計にすると使いやすくなります。