kintoneの通知は、標準のままだとkintoneの通知画面とメールにしか届きません。チャットで仕事が回っている会社では、kintoneを開かない人が通知を見落とし、承認や対応が止まります。この記事では、kintoneの更新をSlackとTeamsのチャンネルに出すまでを、方法の選び方、kintoneのWebhookの設定、受け側の作り方、形式の変換、条件の付け方、逆方向の登録、セキュリティの順に通して書きます。アプリ管理権限があり、アプリの通知設定を触ったことがある人を前提にしています。
先に決めること
通知連携は、作り始めてから「やっぱりあのステータスだけにしたい」「このチャンネルではなく担当者に」と変わりやすい部分です。変わるたびに受け側の作り直しになるので、作る前に3つ決めます。
標準の通知で足りないのはどこか
kintoneのアプリの通知には、「アプリの条件通知」「レコードの条件通知」「リマインダーの条件通知」の3種類があります。届く先はkintoneの「通知」画面とポータルで、kintoneの管理者がメール通知を有効にし、本人が個人設定でメール通知を有効にしていれば、メールでも届きます。
足りなくなるのは、社内のやり取りがSlackやTeamsに集まっていてメールもkintoneも見ない人がいるとき、担当者個人ではなくチーム全体に知らせたいとき(受付、受注など)、通知を見た人がそのままチャットで相談したいときです。
本人にだけ届けばよい通知(自分が作業者になった、など)は、標準の通知とメールで足ります。チャットに流すのは、チームで見る必要がある通知だけに絞ります。全部流すとチャンネルが通知で埋まり、誰も読まなくなります。
どのチャンネルに、何を出すか
実際に回っている形は、業務ごとに通知専用のチャンネル(「#kintone-受注」など)を作り、人の会話と混ぜないやり方です。混ぜると通知と会話が交互に並び、どちらも追えなくなります。
中身は、「何の件か」「次に誰が何をするか」がわかる3〜4項目と、レコードを開くリンクで足ります。詳しい内容はリンクからkintoneで見ます。
どの方式で送るか
決める軸は、条件を付けたいか(特定のステータスだけ、など)と、受け側を保守できる人が社内にいるかの2つです。条件が要らず、届く先が担当者個人のSlackでよいなら、kintone標準の「Slack連携」で終わります。条件を付けてチャンネルに出すなら、Webhookと中継か、メール転送を使います。
方法の全体像
| 方式 | kintone側 | 受け側 | 形式の変換 | 向く場面 |
|---|---|---|---|---|
| 標準のSlack連携 | 「Slack連携」を設定 | kintoneのボット | 不要 | 作業者になった人にSlackのDMで知らせる |
| メール転送 | 「レコードの条件通知」とメール通知 | Slackのチャンネル用メールアドレス | 不要 | 条件付きでチャンネルに出したい。設定だけで済ませたい |
| Webhook+自前の中継 | 「Webhook」を設定 | Slackの着信Webhook、Teamsのワークフロー | 中継で行う | 文面や条件を細かく決めたい |
| iPaaS | 「Webhook」を設定、または連携サービス側で接続 | Zapier、Power Automateなど | サービスの画面で行う | コードを書かずに条件と文面を組みたい |
| プラグイン、JavaScript | アプリに追加 | Slackの着信Webhookなど | プラグインやコードで行う | 画面の操作に合わせて細かく出したい |
kintoneのWebhook、APIトークン、プラグイン、JavaScriptカスタマイズ、標準のSlack連携は、どれもライトコースでは使えません(料金はライトが1ユーザー月額1,000円、スタンダードが1,800円、税抜、10ユーザーから)。
設計表
通知連携は、アプリのフィールドより先に「どの操作で、どの条件のとき、どこへ、何を出すか」を表にしておくと、受け側を作るときに迷いません。案件管理アプリでプロセス管理を使っている場合の例です。
| 通知の名前 | きっかけ(kintoneの操作) | 条件 | 送り先 | 本文に入れる項目 |
|---|---|---|---|---|
| 受注の共有 | ステータスの更新 | ステータスが「受注」 | #kintone-受注 | 顧客名、案件名、金額、担当、レコードのURL |
| 承認待ちの知らせ | ステータスの更新 | ステータスが「承認待ち」 | 承認者のDM | 申請者、件名、金額、レコードのURL |
| 新しい問い合わせ | レコードの追加 | なし | #kintone-問い合わせ | 会社名、問い合わせ種別、受付日時、レコードのURL |
| コメントの共有 | コメントの書き込み | なし | 出さない | 標準の通知とメールに任せる |
あわせて、アプリに次のフィールドがあると通知が組みやすくなります。
| フィールド名 | 種類 | 設定 |
|---|---|---|
| 通知用の件名 | 文字列(1行) | 計算式 顧客名 & "/" & 案件名。レコードのタイトルにする |
| 担当 | ユーザー選択 | 通知先の指定とメンションに使う |
| 通知済み | チェックボックス | 選択肢「受注通知」。二重通知を防ぐときに使う。任意 |
| メンバー対応表 | 別アプリ | kintoneのログイン名とSlackのメンバーIDを持つ。メンションしたいときだけ |
Webhookで送られるデータにはレコードのタイトルが入るので、通知用の件名をタイトルにしておくと、受け側で項目を組み合わせる手間が減ります。
作る手順
標準のSlack連携を設定する
条件を付けず、作業者になった人にだけ知らせればよいなら、これだけで終わります。Slack連携は、プロセス管理で作業者になったユーザーに、kintoneのボットからSlackのダイレクトメッセージ(DM)が届く機能です。チャンネルには投稿されません。
先に、cybozu.com共通管理者が次の設定を済ませます。
- 「cybozu.com共通管理」の「ユーザー管理」で、各ユーザーのメールアドレスを、Slackのワークスペースで使っているメールアドレスと同じにします。
- 「cybozu.com共通管理」の「外部連携」にある「OAuth」を開きます。
- 「Slack」を「有効」に切り替えます。
そのうえで、アプリ側で設定します。プロセス管理を設定していないアプリでは通知が届かないので、先に設定しておきます。
- 「レコードの一覧」画面の右上にある「アプリを設定」をクリックします。
- 「設定」タブの「カスタマイズ/サービス連携」にある「Slack連携」をクリックします。
- 「Add to Slack」をクリックします。
- Slackの画面で連携するワークスペースを確かめ、「許可する」をクリックします。
- 「アプリの設定に戻る」をクリックします。
- 「アプリを更新」をクリックし、ダイアログでもう一度「アプリを更新」をクリックします。

レコードで「処理開始」を実行して作業者を選び、その人にDMが届けば完成です。DMにはレコードのタイトルが出ます。タイトルがレコード番号か空のときは、レコードのURLが出ます。
「Slack連携」のメニューが出ないときは、共通管理で「Slack」が有効か、「組織間のアクセス権」が有効になっていないか、ライトコースでないかを見ます。
Slackの受け口を作る
チャンネルに出すなら、Slack側に「着信Webhook(Incoming Webhooks)」の受け口を作ります。
- Slackのアプリ管理画面で新しいアプリを作り、ワークスペースを選びます。
- アプリの設定で「Incoming Webhooks」を開きます。
- 「Activate Incoming Webhooks」をオンにします。
- 「Add New Webhook to Workspace」をクリックします。
- 投稿先のチャンネルを選び、「Authorize」をクリックします。
- 「Webhook URLs for Your Workspace」に出たURL(
https://hooks.slack.com/services/で始まる)を控えます。
【画面:Slackのアプリ設定で「Activate Incoming Webhooks」がオンになり、Webhook URLが1行表示された状態】
着信Webhookには、先に知っておく性質がいくつかあります。
- URL1本が1つのチャンネルに結び付きます。チャンネルを分けたいならURLを分けて作ります
- 投稿者の名前とアイコンは送るたびには変えられず、投稿したメッセージを着信Webhookで消すこともできません
- 送れるのは目安として1秒に1件です。超え続けると
HTTP 429が返ります - プライベートチャンネルに出すなら、作る人が先にそのチャンネルに入っておきます
着信Webhookは、決まった形のJSONを受け取ります。いちばん単純な形は text だけを持つものです。
{"text": "受注しました:株式会社サンプル/基幹更新 <https://example.cybozu.com/k/12/show#record=345|レコードを開く>"}
<URL|表示する文字> と書くとリンクになります。本文の & < > は、それぞれ & < > に置き換えます。顧客名に「<株>」のような文字が入る会社では、置き換えないとリンクが崩れます。メンションは <@メンバーID> と書き、その人が投稿先のチャンネルにいないと通知は届きません。
Slackのワークフロービルダーにも、Webhookで開始するワークフローがあります(有料プラン)。ただし変数は20個までで、ネストされたJSONは使えません。入れ子で届くkintoneのWebhookを直接つなぐ受け口にはなりません。
Teamsの受け口を作る
Teamsでは、以前のチャネルの「コネクタ」で着信Webhookを作る方法は廃止されました。Microsoftの告知では、2026年5月の展開完了をもって動かなくなっています。今の受け口は、Teamsの「ワークフロー」アプリで作るWebhookです。
- Teamsで「ワークフロー」を開きます。
- テンプレートを検索し、「Webhook アラートをチャネルに送信する」を選びます。
- 投稿先のチームとチャネルを選びます。
- 「保存」をクリックします。
- 作成後の詳細ページで、Webhook URLを「コピー」します。
【画面:Teamsのワークフローで「Webhook アラートをチャネルに送信する」テンプレートを選んだ画面】
チャットに出すなら「チャットに Webhook アラートを送信する」を選びます。テンプレートは送り手の認証の種類ごとに分かれています。プレミアムライセンスは要りません。
Teamsの受け口が受け取るのは、アダプティブカードの形のJSONです。type を message にし、attachments の中に、contentType が application/vnd.microsoft.card.adaptive、contentUrl が null、content にカード本体(TextBlock に本文)を持つ要素を入れます。
投稿はワークフローのボットの名前で出て、名前やアイコンは変えられません。また、ワークフローは作った人(所有者)に結び付き、チャネルには結び付きません。作った人が退職するとフローが孤立するので、作ったらすぐ共同所有者を足します。
kintoneのWebhookを設定する
Webhookは、アプリで操作があったときに、その内容を外部のURLへ送る機能です。共通管理の「その他の設定」で「Webhookの送信を許可する」が外れていると使えません。
- 「レコードの一覧」画面の右上にある「アプリを設定」をクリックします。
- 「設定」タブの「カスタマイズ/サービス連携」にある「Webhook」をクリックします。
- 「追加する」をクリックします。
- 「説明」に、何のためのWebhookかを書きます(64文字まで)。例「受注をSlackの#kintone-受注へ」。
- 「Webhook URL」に受け口のURLを貼り、先頭の「https://」を消します(1,024文字まで)。
- 「通知を送信する条件」で、送りたい操作にチェックを入れます。
- 「このWebhookを有効にする」にチェックが入っていることを確かめます。
- 「保存」をクリックします。
- 「アプリの設定に戻る」をクリックします。
- 「アプリを更新」をクリックし、ダイアログでもう一度「アプリを更新」をクリックします。

「通知を送信する条件」で選べるのは、「レコードの追加」「レコードの編集」「レコードの削除」「コメントの書き込み」「ステータスの更新」の5つです。フィールドの値で絞る設定はありません。1アプリに作れるWebhookは10個までです。
ExcelやCSVファイルの読み込み、レコードの一括削除、一括操作用のREST APIでは、Webhookは送られません。また、送信はドメイン単位で1分間に60回までで、61回目以降の操作は送られません。アプリごとではなく、会社のkintone全体で60回です。
送られてくる中身を知る
kintoneのWebhookは、操作の種類ごとに決まった形のJSONを送ります。レコードの追加、編集、ステータスの更新のときは、次のキーが入ります。
| キー | 中身 |
|---|---|
id | 通知ごとの固有のID |
type | 操作の種類。ADD_RECORD、UPDATE_RECORD、UPDATE_STATUS |
app | アプリのIDと名前 |
record | レコードの中身。レコード取得のREST APIと同じ形 |
recordTitle | レコードのタイトル |
url | レコードのURL |
レコードの削除(DELETE_RECORD)では、record の代わりにレコード番号、削除した人、削除日時が入ります。コメントの書き込み(ADD_RECORD_COMMENT)では、コメントの本文や書いた人、メンションされた人が入ります。
record の中は、フィールドコードごとに type と value を持つ入れ子の形です。ステータスは "type": "STATUS" の項目として入り、値は「受注」のような文字列です。抜粋すると次のような形になります。
{
"id": "通知のID",
"type": "UPDATE_STATUS",
"app": {"id": "12", "name": "案件管理"},
"record": {
"顧客名": {"type": "SINGLE_LINE_TEXT", "value": "株式会社サンプル"},
"ステータス": {"type": "STATUS", "value": "受注"}
},
"recordTitle": "株式会社サンプル/基幹更新",
"url": "https://example.cybozu.com/k/12/show#record=345"
}
ここで大事なのは、変更前の値が入っていないことです。ステータスの更新なら「今どのステータスになったか」はわかりますが、「どこから来たか」はわかりません。編集なら、どのフィールドが変わったかもわかりません。
Webhookをそのまま投げられない理由
kintoneのWebhook URLにSlackの着信WebhookのURLを直接入れても、投稿されません。Slackは text などのキーを持つJSONを待っていて、kintoneは type や record を持つJSONを送るからです。Teamsも同じで、アダプティブカードの形でないものはカードになりません。
なので、kintoneと受け口の間に「中継」を置き、kintoneの形を受け取ってSlackやTeamsの形に組み直して送ります。中継の作り方は3通りあります。
| 中継の作り方 | 中身 | 注意 |
|---|---|---|
| iPaaSを使う | ZapierのCatch Hookなどで受け、SlackやTeamsへ送る手順を画面で組む | 受け取った中身は項目ごとに分けて扱える |
| Power Automateのkintoneコネクタ | kintoneのトリガーで受け、Teamsに投稿する | Power Automateの有償プランが必要 |
| 受け口を自分で書く | 社内のサーバーやGoogle Apps Scriptのウェブアプリで、変換して送るコードを書く | 書いた人がいなくなると直せない。手順を残す |
中継でやることはどの方式でも同じで、届いたJSONの type を見て通知したい操作かを判断し、record から値を取り出し、SlackやTeamsの形に組み立てて受け口へPOSTで送ります。
【画面:ZapierでCatch Hookが受け取ったkintoneの通知の中身が、項目ごとに並んで見えている状態】
kintoneのWebhookには、失敗したときのリトライも、失敗を知らせるメールもありません。中継の処理が重くてタイムアウトしたり、送信データが1MBを超えたりすると、その通知は失敗で終わります。中継は受け取ったらまず応答を返す形にすると落ちにくくなります。
Power Automateのkintoneコネクタを使う場合
Teamsを使っている会社なら、Power Automateのkintoneコネクタが候補になります。トリガーは「レコードの追加」「レコードの更新」「レコードの削除」「レコードコメント投稿」「プロセス管理のステータス更新」から選べ、取り出した値をTeamsへの投稿に渡せます。
使う前に、cybozu.com共通管理の「外部連携」の「OAuth」でMicrosoft Power Automateを有効にし、「利用者の設定」で使うユーザーを許可します。トリガーの裏ではkintoneのWebhookが動くので、「Webhookの送信を許可する」が要り、1分間60回の上限も効きます。テーブルの中のフィールドはトリガーで取れません。プレミアムコネクタなので、Office 365に付いてくるPower Automateでは使えず、ゲストスペースのアプリにもつなげません。
【画面:Power Automateでkintoneのトリガーを検索し、「レコードがアプリに追加されたとき」を選ぶ画面】
届いたかを確かめる
テスト用のレコードを追加するかステータスを進め、チャンネルに投稿が出なければ、「Webhook」の画面で対象のWebhookのログを開き、結果のアイコンで成功か失敗かを見ます。

ログはWebhookごとに直近10件で、古いものは監査ログに残り、見られるのはcybozu.com共通管理者だけです。kintone側が成功なのに投稿が出ないなら、原因は中継か受け口にあります。
条件を付けて通知する
Webhookでは中継で絞る
kintoneのWebhookには、フィールドの値で絞る設定がありません。「ステータスの更新」にチェックを入れると、どのステータスに進んでも送られます。特定のステータスだけ出したいときは、中継で絞ります。
typeがUPDATE_STATUSのものだけを通すrecordの中のステータスの値が「受注」のものだけを通す- それ以外は何もせずに応答だけ返す
注意するのは「差し戻して、もう一度受注にした」ときです。変更前の値が来ないので、中継からは初めての受注か2回目かが区別できず、同じ受注が2回流れます。二重に流したくない場合は、設計表の「通知済み」のようなフィールドをアプリに持たせ、中継が通知したあとにREST APIでチェックを入れ、チェック済みなら流さない、という形にします。この書き戻しにはAPIトークンが要ります。
「金額が100万円以上」のような条件も、record の値を中継で比べます。
設定だけで条件を付けるならメール転送
コードを書かずに条件を付けたいなら、kintone標準の「レコードの条件通知」で絞り、メールでSlackに届ける方法があります。
- Slackで通知用のチャンネルを開き、チャンネル名をクリックします。
- 「自動化」タブでチャンネルにメールを送信する項目を選び、「メールアドレスを取得する」をクリックします(有料プランの機能)。
- kintoneで、通知を受ける担当のユーザーが、個人設定の「メール通知」を有効にします。
- そのユーザーのメールソフトで、kintoneからの通知メールを手順2のアドレスへ自動転送するルールを作ります。
- アプリの「レコードの条件通知」で条件と通知先(そのユーザー)を設定し、「アプリを更新」をクリックします。

kintoneのメール通知を使うには、kintoneシステム管理者が「利用する機能の選択」の「通知のメール送信」で「通知のメール送信機能を利用する」にチェックを入れておく必要があります。
弱点は3つあります。メール通知の本文は変えられず、Slackにはメールの形のまま出ます。「レコードの条件通知」は操作した本人には送られないので、転送役は普段kintoneを操作しない人にします。ExcelやCSVの読み込みで条件を満たしても通知されません。「通知内容」に書いた文はメールの件名に入るので、件名で何の通知か読めるようにします。
応用
逆方向:SlackやTeamsからkintoneに登録する
Slackで受けた依頼をそのままタスク管理アプリに登録する、という逆向きの使い方もあります。
Slackでは、スラッシュコマンドを使うのが基本の形です。利用者がコマンドを打つと、Slackが設定したURLへ、本文と打った人のIDなどをPOSTで送ります。中継でこれを受け取り、kintoneのレコード登録API(/k/v1/record.json へのPOST)でレコードを作ります。
- Slackには3秒以内に応答を返します。超えると利用者の画面にエラーが出ます
- 中継では、Slackの「Signing Secret」を使って、届いたリクエストが本当にSlackからのものかを確かめます。時刻が5分以上ずれているものは捨てます
- kintoneへはAPIトークンで登録します。トークンは登録先のアプリで作り、許可する操作はレコードの追加だけにします
- ルックアップでコピーされるフィールド、ステータス、カテゴリー、計算、作業者、自動計算の文字列(1行)には、APIで値を入れられません
Teamsからなら、Power Automateのkintoneコネクタのアクション「レコードの追加」を使います。アクションではチェックボックス、複数選択、ユーザー選択、テーブル、添付ファイルなどに値を入れられないので、登録先は文字列や日付のフィールドで受けます。
APIトークンの発行からレコード登録までの細かい手順は、「kintone REST APIの使い方。APIトークンの発行からレコードの取得・登録まで」にまとめています。
プラグインやJavaScriptで送る
JavaScriptで送る方法もあります。プロセス管理のアクションを実行したときのイベントで、次のステータスが「完了」なら kintone.proxy() でSlackの着信WebhookへPOSTする形で、kintoneの開発者向けサイトにもサンプルがあります。
ただし、JavaScriptのファイルはアプリを開いた人のブラウザに読み込まれるので、中に書いた着信WebhookのURLは利用者なら読めます。プラグインの kintone.plugin.app.setProxyConfig() で保存した情報はプラグインの設定画面でしか取り出せませんが、隠せるのはヘッダーやデータで、送り先のURLは呼び出しのたびに指定します。URL自体が秘密になる着信Webhookは、kintoneのWebhookと中継で送るほうが安全です。JavaScriptは画面で操作したときにしか動かず、APIや読み込みでの更新は取りこぼす点も弱みです。
市販のプラグインは、kintoneシステム管理で追加したあと、アプリの「プラグイン」で追加します。サポートは提供元が行います。
セキュリティの注意
SlackやTeamsの受け口のURLは、それ自体が鍵です。Slackの公式ドキュメントにも、URLには秘密が含まれていて共有しないように、と書かれています。URLを知っている人なら、誰でもそのチャンネルに投稿できます。
- 受け口のURLは、kintoneのWebhookの設定と中継の中だけに置きます。マニュアルやチャットに貼りません。公開の場所に漏れたSlackのURLは、Slackが見つけて無効にすることがあります
- kintoneのWebhookの設定には、送り先へ認証情報を渡す項目がありません。中継のURLは推測できない長い文字列にし、中で
app.idが想定のアプリかを確かめます - チャットに流した内容は、そのチャンネルの全員が読めます。kintoneでアクセス権を絞っている項目(給与、個人の連絡先など)は本文に入れず、リンクだけにします
- 中継で使うAPIトークンは、必要な操作だけにチェックを入れて作ります。トークンの権限は、アプリやレコードのアクセス権より優先されます
- 中継の設定者(ZapierやPower Automateの所有者)が退職すると、通知が止まります。共有のアカウントや共同所有者で持ちます
- 社外の人がいるチャンネルには、社内の通知を流しません
できないことと、その代わり
| やりたいこと | 標準でできるか | 代わりの手 |
|---|---|---|
| kintoneの通知を、設定だけでSlackのチャンネルに出す | できない(標準のSlack連携は作業者へのDMだけ) | メール転送、Webhookと中継、iPaaS |
| kintoneのWebhookでフィールドの値によって絞る | できない | 中継で絞る。レコードの条件通知とメール転送 |
| Webhookで変更前の値を受け取る | できない | 通知済みのフラグや、変更前の値を持つフィールドをアプリに置く |
| 失敗した通知を再送する | できない(リトライ機能が無い) | 実行ログを見て手で知らせ直す |
| 担当者へのDMとチャンネルへの投稿を1つの設定で出す | できない | 標準のSlack連携と、Webhookの2本立てにする |
| メール通知の本文を変える | できない | 「通知内容」で件名を工夫する。文面を決めたいならWebhookと中継 |
よく詰まるところ
| 症状 | 原因 | 直し方 |
|---|---|---|
| Webhookを設定したのにSlackに何も出ない | SlackのURLをkintoneに直接入れていて、形式が合っていない | 間に中継を置き、Slackの形に組み直して送る |
| 「Webhook」のメニューが無い | ライトコース、または共通管理で「Webhookの送信を許可する」が外れている | 契約コースを確かめる。共通管理者に許可してもらう |
| Slack連携のDMが届かない人がいる | kintoneとSlackのメールアドレスが違う | 共通管理でメールアドレスをSlackのものにそろえる |
| 一括で取り込んだ分の通知が来ない | ExcelやCSVの読み込みではWebhookも条件通知も送られない | 読み込み後は一覧で対象を拾い、知らせる |
| 朝の集中時間だけ通知が抜ける | ドメイン全体で1分60回を超えた | 実行ログで失敗を探す。大量の更新を通知の多いアプリと時間をずらす |
| 同じ受注が2回流れる | 差し戻して再度受注にした。変更前の値が来ないので区別できない | 通知済みのフラグを持たせ、中継で確かめる |
| 自分で更新したときだけ届かない | レコードの条件通知は、操作した本人には送られない | 転送役は普段操作しない人にする。Webhookに切り替える |
| Teamsの古い手順どおりにコネクタを探しても無い | チャネルのコネクタは廃止された | Teamsの「ワークフロー」のWebhookテンプレートで作り直す |
| Teamsの通知が急に止まった | ワークフローの所有者が退職した | 共同所有者を足し、フローを有効に戻す |
| Slackの本文の途中でリンクが崩れる | 顧客名などに < > & が入っている | 中継で < > & に置き換える |
| 失敗が続いていたのに誰も気づかなかった | kintoneのWebhookには失敗を知らせる機能が無い | 週に1回、実行ログを見る担当を決める |
次にやること
チャットに流す前に、kintone標準の通知でどこまで届くかを詰めたいときは「通知の設定。見落とされない通知の作り方」が先です。通知のきっかけになるステータスの組み方は「kintoneでワークフロー(承認フロー)を組む。プロセス管理の設定手順」、中継からkintoneに書き戻したり、チャットからレコードを登録したりする部分は「kintone REST APIの使い方。APIトークンの発行からレコードの取得・登録まで」が続きです。顧客や社外の人に知らせたい場合は、Slackではなく「kintoneとLINEの連携。できることと組み方」の形になります。