Slackとkintone・Salesforce・n8nの連携：業務システムの通知と承認をつなぐ

Slack（スラック）だけでは、案件や問い合わせの記録を長く残す台帳にはなりません。台帳はkintoneやSalesforceのような業務システムに置き、Slackには「記録が増えた」「承認が要る」という知らせを流す、という分担にすると、どちらの良さも生きます。この記事では、社員20名ほどのWeb制作会社「サンプルデザイン」（プロプラン）が、案件の管理表をkintoneに移したあと、kintoneのレコードの追加をSlackに知らせ、問い合わせをn8nでkintoneに登録してチャンネルに知らせ、承認をSlackのボタンで押せるようにするまでを書きます。Salesforceを使う会社向けに、公式のアプリでできることも確かめた範囲で載せます。読み終わると、自分の会社でどの形でつなぐか、どの道具を使うか、止まったときに誰が気づくかまで決められます。前提はkintoneのスタンダードコース、n8nが社外から届くURLで動いていることです。

この記事の内容

1. 先に決めること
2. サンプルデザインでつなぐものの一覧
3. kintoneのレコードの追加をSlackに知らせる
4. 問い合わせをkintoneに登録してチャンネルに知らせる（n8n）
5. 承認をSlackのボタンで押す
6. Salesforceとつなぐ
7. 応用
8. できないことと、その代わり
9. よく詰まるところ
10. 次にやること

先に決めること

3つの形のどれをやるか

業務システムとSlackのつなぎ方は、大きく3つの形に分かれます。形によって手間も、壊れたときの影響も違います。

形	例	向きの説明	手間
通知だけ	kintoneに案件が登録されたら #log-案件 に知らせる	業務システム→Slackの片道	小さい
Slackから記録する	#log-問い合わせ の問い合わせを、Slackの操作でkintoneに登録する	Slack→業務システム	中くらい
承認をSlackで押す	見積もりの承認依頼をDMで受け、ボタンで承認すると業務システムのステータスが進む	往復	大きい

最初は「通知だけ」から始めます。通知が読まれていない会社が承認までSlackに寄せても、ボタンが押されずに止まるだけです。サンプルデザインでは、通知だけを3か月回して読まれていることを確かめてから、承認に進みました。

どの道具でつなぐか

道具	向く使い方	向かない使い方
各システムの公式のSlack連携（Salesforceのアプリなど）	公式が用意している範囲の表示・共有・通知	自社の決まりに合わせた細かい条件
Slackのワークフロービルダー	Slackの中で完結する受付・依頼、用意されたコネクタの範囲	業務システムのデータを読み書きする込み入った処理
n8n	kintoneのWebhookを受けてSlackに送る、条件で分ける、まとめて送る、承認のボタン	作った人しか中身が分からない状態での運用
Zapier	kintoneヘルプでも連携の例に挙がる	公式の向き不向きは確認できていない
Incoming Webhook・Slackアプリの自作	外のシステムから決まったチャンネルに送るだけ	業務システム側の形を組み直す処理

公式の連携があるなら、まず公式を使います。公式で足りないところだけ、n8nやZapierで補います。サンプルデザインはn8nを社内のサーバーで動かしているので、kintoneとSlackの間はn8nでつないでいます。

誰の名前のトークンで動かすか

つなぐときには、Slack・kintone・Salesforceそれぞれに「誰として動くか」の鍵（トークン）が要ります。ここを担当者個人の鍵で作ると、その人が辞めた日に止まります。

つなぐ先	鍵の種類	決めること
Slack	botのトークン（xoxb-）か、人のトークン（xoxp-）	通知はbotのトークンで送る。人のトークンで送ると、その人が書いたように見える
kintone	アプリごとのAPIトークン	必要な権限（レコードの閲覧・追加・編集）だけを付けたトークンをアプリごとに作る
Salesforce	連携用のユーザー	個人のユーザーではなく、連携用のユーザーで接続する
n8n	資格情報（Credentials）	誰が作ったか、どのワークフローで使っているかを一覧に残す

開発者向けの資料では、botのトークンで動くアプリは、入れた人が停止されてもワークスペースに入ったままと説明されています。人のトークンはその人のアカウントに結びつき、書き込みも本人がしたように見えます。通知や記録はbotのトークンにしておくのが基本です。

止まったら誰が気づくか

通知の仕組みは、止まっても誰も困らない日が続き、気づいたときには1週間分の問い合わせが漏れていた、ということが起きます。仕組みを作るときに、止まったことに気づく役も一緒に決めます。

• n8nのワークフローが失敗したら、#log-システム にエラーを送る（n8nのエラー用のワークフローを1つ作る）
• kintoneのWebhookの実行ログを、月に1回見る担当を決める
• 毎朝9時に「昨日の問い合わせは何件」と送る定時の通知を置き、来なければ止まっていると分かるようにする

サンプルデザインでは、エンジニアCが作り、総務Eが毎朝の定時の通知を見る、という分担にしています。

サンプルデザインでつなぐものの一覧

つなぐもの	形	道具	届く先
kintoneの案件アプリにレコードが追加された	通知だけ	kintoneのWebhook→n8n→Slack	#log-案件
案件のステータスが「公開待ち」になった	通知だけ	kintoneのWebhook→n8n→Slack	#team-direction
ホームページの問い合わせ	Slackから記録する	n8n→kintone→Slack	#log-問い合わせ
見積もりの承認依頼	承認をSlackで押す	n8nのSlackノードの承認	代表へのDM
前日の問い合わせ・案件の件数	まとめて送る	n8nの定時実行	#log-システム

kintoneのレコードの追加をSlackに知らせる

kintone側でできることを比べる

2026年10月時点で、kintoneからSlackに知らせる方法は次の4つです。

方法	中身	注意
kintoneのWebhook	レコードの追加・編集・削除、コメントの書き込み、ステータスの更新でJSONを外に送る	送る形はkintoneが決めた形。SlackのIncoming Webhookにそのまま送っても受け付けられないので、間にn8nやZapierを挟む
プラグイン	各社の製品を入れて、画面の設定でSlackに送る	製品ごとに料金と保守の体制が違う。誰が更新するかを決めてから入れる
JavaScriptのカスタマイズ	保存のときにSlackに送るコードを書く	Webhook URLをコードに書くと、アプリを使う人が見られる場所に置くことになる
n8nの定時実行	決まった時刻にkintoneのREST APIでレコードを取り、まとめて送る	すぐには届かない。まとめの通知向き

サンプルデザインは、kintoneのWebhookでn8nに送り、n8nで文を組み立ててSlackに送る形にしています。kintone側はWebhookの設定だけで済み、送る文や送り先を変えたいときはn8nの側だけを直せばよいからです。

kintoneのWebhookの条件

kintoneのヘルプで確かめた、Webhookの主な条件です。

項目	内容
通知を送る操作	レコードの追加・レコードの編集・レコードの削除・コメントの書き込み・ステータスの更新
1アプリの上限	10個
送る回数の上限	ドメイン単位で1分間に60回。61回目以降の操作では送られない
送られない操作	Excel・CSVファイルの読み込み、複数レコードの一括削除、複数レコードを一括で扱うREST APIの操作
使えないコース	ライトコース
必要な許可	cybozu.com共通管理者がWebhookの利用を禁止していると設定できない

CSVの読み込みで登録したレコードは通知されない点に注意します。案件の管理表からkintoneへ移すときにCSVで一括登録しても、Slackに数百件の通知が飛ぶことはありません。逆に、普段からCSVで登録している業務は、Webhookでは知らせられません。その場合は、n8nの定時実行でまとめて知らせます。

手順1：n8nでWebhookの受け口を作る

1. n8nで新しいワークフローを作り、最初のノードに「Webhook」を置く
2. HTTPのメソッドを POST にし、パスを kintone-anken のように決める
3. 本番用のURL（https://n8n.sample-design.example/webhook/kintone-anken）をコピーする
4. 「Webhook」の次に「Slack」のノードを置き、「Message」の「Send」を選ぶ
5. 資格情報に、通知用のSlackアプリのbotのトークンを選ぶ
6. 送り先のチャンネルに #log-案件 を選ぶ
7. 本文を下のように書く

kintoneのWebhookは、レコードの中身を record の中に、フィールドコードごとに value を入れた形で送ってきます。n8nの「Webhook」ノードでは、送られてきた中身は body の下に入ります。案件アプリのフィールドコードが 案件名・取引先名・担当者 の場合、本文は次のように書けます。

:new: 案件が登録されました
案件名: {{ $json.body.record.案件名.value }}
取引先: {{ $json.body.record.取引先名.value }}
登録: {{ $json.body.app.name }}
{{ $json.body.url }}

type には操作の種類が入ります（レコードの追加は ADD_RECORD、編集は UPDATE_RECORD、ステータスの更新は UPDATE_STATUS、削除は DELETE_RECORD、コメントは ADD_RECORD_COMMENT）。1つのWebhookで複数の操作を送る場合は、n8nの「If」や「Switch」のノードで type を見て送り先を分けます。

手順2：kintoneにWebhookを設定する

1. kintoneの案件アプリの「レコードの一覧」画面で、歯車のアイコンの「アプリを設定」を開く
2. 「設定」タブの「カスタマイズ／サービス連携」にある「Webhook」を開く
3. 「追加する」を押す
4. 説明に「n8n経由でSlackの #log-案件 に通知」と入れる（64文字まで）
5. 「Webhook URL」に、n8nでコピーしたURLを入れる（先頭の https:// は消す）
6. 「通知を送信する条件」で「レコードの追加」にチェックを入れる
7. 「このWebhookを有効にする」にチェックが入っていることを確かめる
8. 「保存」を押す
9. 「アプリの設定」に戻り、「アプリを更新」を押し、確認でもう一度「アプリを更新」を押す

最後の「アプリを更新」を忘れると、設定が反映されず通知が飛びません。設定したら、テスト用のレコードを1件追加し、#log-案件 に届くことを確かめてから、テストのレコードを消します。

説明の欄には、どこに送っているかを必ず書きます。半年後に誰かがWebhookの一覧を見たとき、何のための設定か分からないと、消してよいか判断できなくなります。

ステータスの変化だけを知らせる

案件のステータスが「公開待ち」になったときだけ #team-direction に知らせたい場合は、kintoneのWebhookの条件を「ステータスの更新」にし、n8nの「If」ノードでステータスの値を見て、「公開待ち」のときだけSlackに送ります。kintone側には「この値のときだけ送る」という条件が無いので、絞り込みはn8nでやります。

問い合わせをkintoneに登録してチャンネルに知らせる（n8n）

ホームページの問い合わせを、kintoneの問い合わせアプリに登録してから #log-問い合わせ に知らせる例です。Slackに流れてくるのは「kintoneに登録済みの問い合わせ」になるので、記録の漏れがなくなります。

流れ

1. 問い合わせフォームの送信をn8nの「Webhook」ノードで受ける（フォームから送れない場合は、問い合わせのメールをn8nで読む）
2. n8nの「HTTP Request」ノードで、kintoneのREST APIにレコードを追加する
3. 返ってきたレコード番号で、kintoneのレコードのURLを組み立てる
4. 「Slack」ノードで、#log-問い合わせ に件名と、kintoneのレコードのURLだけを送る

本文（名前・電話番号・相談の中身）はSlackに流さず、kintoneで見てもらいます。Slackのチャンネルに流すと、メンバー全員がいつでも検索して読める状態になるからです。

kintoneにレコードを追加する

kintoneのREST APIでレコードを1件追加するリクエストは、次の形です。APIトークンは、問い合わせアプリの設定でレコードの追加の権限だけを付けて作ります。

POST https://sample-design.cybozu.example/k/v1/record.json
X-Cybozu-API-Token: xxxxxxxx
Content-Type: application/json

{
  "app": 12,
  "record": {
    "件名": { "value": "サイトリニューアルのご相談" },
    "会社名": { "value": "株式会社サンプル" },
    "受付経路": { "value": "ホームページ" }
  }
}

成功すると、登録したレコードの id（レコード番号）と revision が返ってきます。n8nの「HTTP Request」ノードでは、メソッドを POST、URLを上の形、ヘッダーに X-Cybozu-API-Token を足し、本文をJSONで送ります。APIトークンはノードに直接書かず、n8nの資格情報に入れておきます。

Slackに知らせる

「Slack」ノードの本文は次のようにします。id は前のノードで返ってきたレコード番号です。

:incoming_envelope: 問い合わせを登録しました
件名: {{ $('Webhook').item.json.body.subject }}
https://sample-design.cybozu.example/k/12/show#record={{ $json.id }}

届いたらスレッドに「対応します」と書いた人が担当になり、kintoneのレコードの担当者の欄にも自分を入れます。Slackのスレッドは気づくための場所で、担当と対応の記録はkintoneが正です。

承認をSlackのボタンで押す

n8nのSlackノードの承認

n8nのSlackノードには「Send and Wait for Response」という操作があり、メッセージを送って、相手が返事をするまでワークフローを止めておけます。返事の形を「Approval」にして「Capture Who Responded」をオンにすると、Slackの中のボタンで承認・却下でき、押されるとワークフローが続きます。オフ（既定）のままだとリンクのボタンになり、押すとブラウザが開く形になります。

サンプルデザインの見積もりの承認は、次の流れです。

1. 営業Dがkintoneの見積もりアプリでステータスを「承認待ち」にする
2. kintoneのWebhook（ステータスの更新）がn8nに届く
3. n8nが代表のDMに、見積もりの金額とkintoneのURLを付けて承認のボタンを送る
4. 代表がボタンを押すと、n8nがkintoneのREST APIで見積もりのステータスを進める
5. 結果を #team-sales に「承認されました」と知らせる

設定で押さえるところ

Slackの中のボタンで返事を受けるには、n8nのドキュメントに書かれた次の準備が要ります。

項目	内容
n8nのURL	インターネットからHTTPSで届くこと。手元のパソコンの localhost では動かない
Slackアプリの「Interactivity」	オンにして、Request URLに https://n8n.sample-design.example/webhook-waiting-slack を入れる
署名の鍵	Slackアプリの「Basic Information」にある signing secret を、n8nの資格情報の「Signature Secret」に入れる
スコープ	users:read と users:read.email（無いと押した人のメールが記録されない）
「Capture Who Responded」	オンにすると、Slackのボタンで返事を受け、押した人が記録される
「Restrict Who Can Approve」	押せる人をユーザーIDで絞る。空にすると、メッセージを見られる人なら誰でも押せる
「After Decision」	押したあと結果を表示してボタンを消す（既定）・ボタンだけ消す・そのまま、から選ぶ

押した結果として、承認したか（approved）、押した時刻、押した人のIDと名前とメールがワークフローに渡ります。kintoneのコメントに「代表がSlackで承認」と残すと、後から誰がいつ承認したかを追えます。

押せる人を絞っても、承認の依頼そのものはメッセージを見られる人なら誰でも読めます。金額や個人の情報が入る承認は、パブリックチャンネルではなくDMかプライベートチャンネルに送ります。また、1つのSlackアプリに設定できるRequest URLは1つなので、1つのアプリは1つのn8nにしかつなげません。

ワークフロービルダーの承認との使い分け

Slackのワークフロービルダーでも、ボタンを使った承認の流れは作れます。申請も承認も記録もSlackの中で完結するならワークフロービルダー、承認の結果でkintoneのステータスを進めるなど業務システムを書き換えるならn8n、と分けます。ワークフロービルダーでの作り方は承認フローの記事で書いています。

Salesforceとつなぐ

Salesforceを使う会社は、まず公式のSalesforceのアプリを確かめます。2026年10月時点のヘルプセンターで確かめた範囲は次のとおりです。

できること	中身	使えるプラン
Slackの検索からSalesforceのレコードを探す・更新する	検索欄で「Salesforce 内を検索」を選び、レコードを開いて編集する。更新はSalesforceにも反映される	接続済みのSalesforce組織があること
リストビュー	「Salesforce」アプリの「リストビュー」タブでビューを選び、レコードを表示・共有する。権限があれば「新規」で作成	ビジネスプラス・Enterprise
Slackbotでレコードを作る・更新する	Slackbotとの会話で依頼し、変更前に確認と承認が求められる	ビジネスプラス・Enterprise
canvasにSalesforceのデータを入れる	プラスボタンから「Salesforce データフィールド」を挿入する	ヘルプの記載が場所によって違う
Salesforceチャンネル	取引先や商談のレコードに結びついたチャンネルで、データを見て更新する	設定が要る

Slackで見たり直したりできる範囲は、Salesforceに設定されている権限と同じです。項目ごとの見える・見えないも、Salesforceの項目レベルのセキュリティで決まります。Slackにつないだからといって、Salesforceで見られないデータが見えるようにはなりません。

プロプランでは使えない機能があることに注意します。リストビューやSlackbotでのレコードの作成・更新は、ビジネスプラス以上の機能です。プロプランの会社が商談の通知だけを流したいなら、n8nの「Salesforce Trigger」ノード（商談・リード・取引先などの作成と更新をきっかけにできる）で変更を拾ってSlackに送る形も選べます。開発者向けの資料では、Slackのワークフロービルダーにも、Salesforceのレコードを扱うステップがあると説明されています。

サンプルデザインはSalesforceを使っていませんが、営業の管理をSalesforceにするか検討したときは、「Slackで商談を見られること」よりも「Salesforceに入力が続くこと」を先に考えました。Slackの連携は入力が続いて初めて役に立ちます。

応用

通知を流しすぎない設計

業務システムの通知は、つなげばつなぐほど増えます。実際に運用していると、レコードの編集のたびに通知を流して、1日に100件を超え、#log-案件 を誰も開かなくなる、ということが起きます。サンプルデザインでは次の決まりで量を抑えています。

決まり	中身
自動の通知は log- のチャンネルに集める	人の会話のチャンネルに混ぜない
編集の通知は流さない	流すのは追加と、決まったステータスへの変化だけ
すぐ知る必要がないものはまとめる	前日の件数は毎朝9時に1通にまとめて送る
人を呼ぶのは担当だけ	@channel を自動の通知に入れない。呼ぶのは担当者かユーザーグループ
通知を増やすときは1つ減らす	新しい通知を足すときに、読まれていない通知を1つ止める

まとめの通知は、n8nの「Schedule Trigger」で毎朝決まった時刻に動かし、kintoneのREST APIで前日に登録されたレコードを数えて、1通にまとめて送ります。kintoneのWebhookはドメイン単位で1分間に60回までという上限もあるので、件数の多い業務ほど、まとめの形が向いています。

Backlogなど他のシステム

Backlogのような課題管理のシステムでも、考え方は同じです。公式のSlack連携があればまず使い、足りないところはWebhookをn8nで受けて組み立て直します。どのシステムでも「何を流し、何を流さないか」を先に決めておくと、つないだあとに通知の量で困りません。

できないことと、その代わり

できないこと	代わりの手
kintoneのWebhookをSlackのIncoming Webhookに直接送る	間にn8nかZapierを挟んで、Slackが受け付ける形に組み直す
kintoneのWebhookで「この値のときだけ」送る	Webhookはすべて送り、n8nの「If」で絞る
CSVの読み込みや一括操作をWebhookで知らせる	n8nの定時実行でまとめて知らせる
プロプランでSalesforceのリストビューやSlackbotの更新を使う	ビジネスプラス以上の機能。通知だけならn8nで送る
n8nを手元のパソコンで動かしてSlackのボタンの承認を受ける	インターネットからHTTPSで届く場所でn8nを動かす
1つのSlackアプリで2つのn8nの承認を受ける	n8nごとにSlackアプリを分ける
Slackを業務の台帳にする	記録はkintone・Salesforceに置き、Slackには知らせだけを流す

よく詰まるところ

症状	原因	直し方
kintoneにレコードを追加してもSlackに届かない	Webhookを保存したあと「アプリを更新」を押していない	「アプリの設定」で「アプリを更新」を押す
Webhookの設定画面が出ない	cybozu.com共通管理者がWebhookを禁止している、ライトコース	共通管理者に確かめる
CSVで登録した分だけ通知が来ない	CSVの読み込みはWebhookの対象外	定時実行でまとめて知らせる
一度にたくさん更新したら一部の通知が来ない	ドメイン単位で1分60回の上限を超えた	編集の通知を止める、まとめて送る形にする
n8nの本文に値が出ず空になる	body の下を見ていない、フィールドコードが違う	n8nの実行結果で実際のJSONを見て、フィールドコードを合わせる
kintoneへの登録で権限のエラーになる	APIトークンにレコードの追加の権限が無い、フィールドの編集権限が無い	トークンの権限とフィールドの権限を確かめる
承認のボタンを押しても反応しない	Request URLの設定漏れ、署名の鍵の違い、n8nが外から届かない	Interactivityの設定とSignature Secretを確かめる
誰でも承認ボタンを押せてしまう	「Restrict Who Can Approve」が空	押せる人のユーザーIDを入れる
押した人のメールが記録されない	users:read.email のスコープが無い	スコープを足し、資格情報をつなぎ直す
担当が辞めたら通知が止まった	その人のトークンで動いていた	botのトークンと連携用のユーザーに切り替え、一覧表に持ち主を書く
止まっていたのに1週間誰も気づかなかった	止まったことを知らせる仕組みが無い	エラーの通知と毎朝の定時の通知を置く

次にやること

業務システムの通知の多くは、Slackに送る最後の部分がIncoming Webhookかbotです。送る側の仕組みはSlackのIncoming Webhook：外のシステムからチャンネルに通知を送るに、受け取る側やボタンの仕組みはSlack APIとbotの作り方：Slackアプリを作ってメッセージを送る・受け取るに書いています。業務システムを書き換えない承認は、Slackのワークフローで承認フロー：申請から承認・記録までを作るのほうが手軽です。ほかの会社がどんなチャンネルと仕組みを作っているかは、Slackの活用事例：小さな会社でよく作るチャンネルとワークフロー15例にまとめています。