SlackのIncoming Webhook：外のシステムからチャンネルに通知を送る

公開 書いた人 大林 諒

Slack（スラック）のIncoming Webhookは、外のシステムから決まったURLにJSONを送るだけで、Slackのチャンネルにメッセージを出せる仕組みです。サーバー監視の異常、ホームページの問い合わせ、スプレッドシートの更新のような「Slackの外で起きたこと」を、担当が見ているチャンネルに流せます。この記事では、社員20名ほどのWeb制作会社「サンプルデザイン」が #log-サーバー監視 と #log-問い合わせ に通知を流すまでを、Slackアプリの作成から、curlでの送信、Apps Scriptの例、URLの管理、送れないときの確かめ方まで順に書きます。読み終わると、自分の会社の通知を1本作って、担当が替わっても止まらない形で置けるようになります。前提はプロプランのワークスペースで、Slackアプリを作れる権限があることです。

この記事の内容
  1. 先に決めること
  2. サンプルデザインで作るWebhookの一覧
  3. Slackアプリを作ってIncoming Webhookを有効にする
  4. curlで送ってみる
  5. JSONの書き方
  6. 外のシステムから送る例
  7. Webhook URLの扱い
  8. ワークフロービルダーのWebhookトリガーとの違い
  9. 上限と、送れないときの確かめ方
  10. 応用
  11. できないことと、その代わり
  12. よく詰まるところ
  13. 次にやること

先に決めること

Webhookで足りるか、Slackアプリのbotが要るか

Incoming Webhookは「決まったチャンネルに、決まったアプリの名前で、送りっぱなしにする」ための仕組みです。送ったメッセージを後から消す、スレッドに返信を重ねる、ボタンを押した結果を受け取る、といったことはできません。公式の開発者向けドキュメントにも、Webhookで送ったメッセージは削除できず、削除したいなら chat.postMessage を使うように書かれています。

やりたいことIncoming WebhookSlackアプリのbot（Web API）
1つのチャンネルにお知らせを流すできるできる
送り先のチャンネルを送るたびに変えるできない（URLごとに1チャンネル）できる
送った通知をスレッドにまとめる返ってくる情報だけではできないできる
送ったメッセージを後で消す・書き換えるできないできる
ボタンを押してもらって結果を受け取るできないできる
必要な準備アプリを作ってURLを発行するだけスコープ・トークン・受け口のサーバー

サンプルデザインの通知は、サーバー監視の異常、問い合わせの着信、案件の管理表の更新のどれも「見て気づければいい」ものなので、Webhookで足ります。送った通知に対して誰かが対応したかを記録したい、ボタンで「対応する」を押してもらいたい、と思った時点でbotを作る話になります。その場合はSlack APIとbotの作り方の記事で書いています。

1つのURLは1つのチャンネルに結びつく

Webhook URLは発行するときに送り先のチャンネルを1つ選び、そのURLからは他のチャンネルに送れません。公式にも、Webhookは1人のユーザーと1つのチャンネルに結びつき、送るときにチャンネル・名前・アイコンを上書きできないと書かれています。通知先が3つあればURLを3本発行します。1つのSlackアプリの中に複数のURLを作れるので、アプリを通知の種類ごとに作る必要はありません。

アプリを誰の名前で作り、どこに書き残すか

Webhook URLを発行した人がそのURLの持ち主になります。公式は、作った人のアカウントを停止したときにURLがどうなるかまでは書いていません。実際に運用していると、作った人が辞めたあと、誰も設定画面に入れずURLを作り直せない、何の通知かも分からない、という状態になりがちです。サンプルデザインでは、通知用のSlackアプリは総務Eと代表の2人が共同で管理できるようにし、どのURLがどこから呼ばれているかを一覧表にして残します。アプリを共同で管理できる人を足す設定は、開発者向けの設定画面で確かめてください。

通知を流すチャンネルを分ける

自動の通知を人の会話のチャンネルに混ぜると、会話が流れて読めなくなります。サンプルデザインでは自動の通知は log- で始まるチャンネルに集め、人が反応すべきものだけを担当のチャンネルにも出す決まりにしています。#log-サーバー監視 はエンジニア5名と代表、#log-問い合わせ は営業2名とディレクター4名が入ります。チャンネルの名前の付け方はチャンネル設計の記事で書いています。

サンプルデザインで作るWebhookの一覧

送り元送り先チャンネル送る内容送る仕組み
サーバー監視#log-サーバー監視応答なし・復旧監視サービスのWebhook送信
問い合わせフォーム（メールで届く）#log-問い合わせ件名・送信元・受付時刻GmailをApps Scriptで見て送る
案件の管理表（スプレッドシート）#team-direction公開日が決まった案件スプレッドシートのApps Script
手元での動作確認#times-エンジニアcテスト送信curl

アプリは「サンプルデザイン通知」という名前で1つ作り、その中にURLを4本発行します。チャンネルに表示される送り主の名前とアイコンはアプリの設定がそのまま使われるので、通知だと一目で分かる名前とアイコンにしておきます。

Slackアプリを作ってIncoming Webhookを有効にする

手順は2026年10月時点の開発者向け設定画面（api.slack.com/apps）です。設定画面は英語表示です。

  1. ブラウザでSlackにログインした状態で https://api.slack.com/apps を開く
  2. アプリを新しく作るボタンを押す（https://api.slack.com/apps?new_app=1 を直接開いても同じ画面になる）
  3. 作り方の選択で「Blank app」を選び、「Continue」を押す
  4. 「App Name」に サンプルデザイン通知 と入れる
  5. 「Workspace」で「サンプルデザイン」を選ぶ
  6. 「Create」を押す
api.slack.com/apps の新規作成で「Blank app」を選んだあと、App Name と Workspace を入れたところ
api.slack.com/apps の新規作成で「Blank app」を選んだあと、App Name と Workspace を入れたところ

アプリができると、そのアプリの設定画面が開きます。左のメニューから次の順に進みます。

  1. 左のメニューで「Incoming Webhooks」を押す
  2. 「Activate Incoming Webhooks」のスイッチをオンにする
  3. 画面の下にある「Add New Webhook to Workspace」を押す
  4. 送り先のチャンネルに #log-サーバー監視 を選ぶ
  5. 「Authorize」を押す
  6. Webhookの画面の一覧に、発行されたURLが出る
アプリ設定の「Incoming Webhooks」で「Activate Incoming Webhooks」をオンにし、「Add New Webhook to Workspace」が見えているところ
アプリ設定の「Incoming Webhooks」で「Activate Incoming Webhooks」をオンにし、「Add New Webhook to Workspace」が見えているところ
チャンネルを選んで「Authorize」を押す許可の画面
チャンネルを選んで「Authorize」を押す許可の画面
Webhookの画面の一覧にURLが1本出ているところ（URLの末尾は伏せる）
Webhookの画面の一覧にURLが1本出ているところ（URLの末尾は伏せる）

プライベートチャンネルに送るURLを作るときは、作る人が先にそのチャンネルに入っている必要があります。チャンネルを選ぶ画面に出てこないときは、まずそのチャンネルに参加してから作り直します。

URLは次の形をしています。末尾の英数字が鍵の役目をするので、記事や手順書には伏せて書きます。

https://hooks.slack.com/services/T00000000/B00000000/xxxxxxxxxxxxxxxxxxxxxxxx

2本目以降のURLも同じ「Incoming Webhooks」の画面で「Add New Webhook to Workspace」を押して、チャンネルを変えて発行します。

ワークスペースの設定でアプリのインストールに管理者の承認が要るようにしている場合、許可の画面で承認の依頼になり、すぐにはURLが出ません。承認の設定はセキュリティ設定の記事で書いています。

送り主の名前とアイコンを整える

Webhookで送るメッセージの名前とアイコンは、送るときに変えられません。アプリの設定画面にある表示情報の欄で、アプリ名・アイコン・背景色を決めておきます。アイコンは「通知」と分かる単色のもので十分です。

アプリ設定で表示名とアイコンを設定する欄
アプリ設定で表示名とアイコンを設定する欄

curlで送ってみる

URLを発行したら、まず手元のパソコンからcurlで送って届くか確かめます。Macのターミナルやエンジニアの作業環境なら、次の1行でテストできます。

curl -X POST \
  -H 'Content-type: application/json' \
  --data '{"text":"テスト送信です。Webhookの設定を確かめています"}' \
  https://hooks.slack.com/services/T00000000/B00000000/xxxxxxxxxxxxxxxxxxxxxxxx

うまくいくと、HTTPの200と、本文に ok だけが返ってきて、選んだチャンネルにメッセージが出ます。失敗したときは本文にエラーの名前が返ってくるので、その名前で後の「送れないときの確かめ方」の表を引きます。

Windowsのコマンドプロンプトではシングルクォートが使えず、--data の中のダブルクォートを \" に書き換える必要があります。テストはMacのターミナルかPowerShellで送るほうが楽です。

curlで送ったテストのメッセージが #times-エンジニアc に「サンプルデザイン通知」の名前で出ているところ
curlで送ったテストのメッセージが #times-エンジニアc に「サンプルデザイン通知」の名前で出ているところ

JSONの書き方

textだけで送る

一番簡単なのは text だけを送る形です。text は必須で、入っていないと no_text のエラーになります。改行は \n で入れます。

{
  "text": "問い合わせが届きました\n件名: サイトリニューアルのご相談\n受付: 2026-10-31 10:24"
}

text の中は、Slackの書式（mrkdwn）が使えます。太字は *太字*、斜体は _斜体_、取り消し線は ~取り消し~、コードは ` コード 、引用は行頭に > です。リンクは <https://example.com/|表示する文字>` の形で書くと、URLの代わりに文字が出ます。

& < > を書き換える

< と > はリンクやメンションの印として使われるので、本文にそのまま入れると表示が崩れます。送る前に & を &amp;、< を &lt;、> を &gt; に書き換えます。公式も、この3文字だけを書き換え、文全体をエンコードしないように書いています。メールの送信元は 営業担当 <info@example.com> のように < > を含むので、問い合わせの通知では必ずつまずきます。

メンションを入れる

通知で人を呼ぶときは、名前ではなくIDで書きます。@デザイナーB と文字で書いても通知にはなりません。公式も、ユーザーのメンションを自動で読み取る機能は廃止したと書いています。

呼びたい相手書き方IDの調べ方
1人<@U0000000000>相手のプロフィールのメニューからメンバーIDをコピーする
ユーザーグループ<!subteam^S0000000000>ユーザーグループのページのURL
チャンネルにいてオンラインの人<!here>なし
チャンネル全員<!channel>なし
チャンネルへのリンク<#C0000000000>チャンネルを開いたときのURLの最後の部分

サーバー監視の通知では、エンジニアのユーザーグループ（@engineer）を呼びます。担当の交代はユーザーグループのメンバーを入れ替えるだけで済み、Webhookの側は直さなくて済みます。<!channel> を自動の通知に入れると、深夜でも全員の通知が鳴り、すぐに誰も見なくなります。自動の通知で使うのは、ユーザーグループか特定の担当1人までにしておきます。

Block Kitで見出しと項目を分ける

項目が多い通知は、Block Kitで見出しと項目を分けると読みやすくなります。blocks を使うときも text は入れておきます。スマホの通知やデスクトップの通知に出る文字は text が使われるので、ここが空だと通知に何も出ません。

{
  "text": "サーバー監視: sample-design.example が応答しません",
  "blocks": [
    {
      "type": "header",
      "text": { "type": "plain_text", "text": "サーバー監視：応答なし" }
    },
    {
      "type": "section",
      "fields": [
        { "type": "mrkdwn", "text": "*対象*\nsample-design.example" },
        { "type": "mrkdwn", "text": "*検知*\n2026-10-31 09:12" }
      ]
    },
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "<!subteam^S0000000000> 確認をお願いします。手順は <https://example.com/runbook|障害時の手順>"
      }
    }
  ]
}
Block Kitで送った監視の通知が見出しと2つの項目に分かれて表示されているところ
Block Kitで送った監視の通知が見出しと2つの項目に分かれて表示されているところ

Block Kitには公式の上限があります。2026年10月時点で確かめた主なものは次のとおりです。

項目上限
1つのメッセージのブロック数50
見出し（header）の文字数150文字
セクション（section）の text3,000文字
セクションの fields の数10個
fields の1つの文字数2,000文字

組み立てるときは、公式のBlock Kit Builderで見た目を確かめてからJSONを写すと、括弧の閉じ忘れで invalid_payload になるのを防げます。

外のシステムから送る例

サーバー監視から送る

監視サービスの多くは、異常を検知したときに指定したURLへ送る機能を持っています。送るJSONの中身を自分で書ける監視サービスなら、送り先にWebhook URLを入れ、本文を次のようにします。{{host}} のような差し込みの書き方は監視サービスごとに違うので、そのサービスの説明に合わせます。

{
  "text": "サーバー監視: {{host}} が {{status}} になりました（{{time}}）"
}

注意が要るのは、送る中身を変えられず、監視サービスが決めた形のJSONしか送れない場合です。Incoming Webhookは text か blocks が入った形しか受け付けないので、そのまま送ると no_text か invalid_payload で弾かれます。その場合の手は2つあります。1つは、監視サービスにSlack用の連携が用意されていればそちらを使うこと。もう1つは、間にn8nやワークフロービルダーのWebhookトリガーを挟んで、受け取ったJSONから文を組み立て直すことです。

問い合わせフォームのメールから送る

サンプルデザインのホームページの問い合わせは、info@sample-design.example にメールで届きます。Googleドライブに置いたApps Scriptで、まだ通知していない問い合わせメールを5分おきに探し、件名と送信元だけを #log-問い合わせ に送ります。本文はSlackに流さず、Gmailで開いてもらいます。問い合わせの本文には電話番号や住所が入ることがあり、Slackに流すとチャンネルの全員がいつまでも検索できてしまうからです。

// 共通: Slackに送る
function notifySlack(text) {
  const url = PropertiesService.getScriptProperties().getProperty('SLACK_WEBHOOK_URL');
  const res = UrlFetchApp.fetch(url, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: text }),
    muteHttpExceptions: true
  });
  if (res.getResponseCode() !== 200) {
    console.error('Slack送信失敗: ' + res.getResponseCode() + ' ' + res.getContentText());
  }
}

// & < > を書き換える
function esc(s) {
  return String(s).replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;');
}

// 問い合わせメールを探して通知する（時間主導型トリガーで5分おき）
function notifyInquiries() {
  const name = 'slack-notified';
  const label = GmailApp.getUserLabelByName(name) || GmailApp.createLabel(name);
  const threads = GmailApp.search('to:info@sample-design.example -label:slack-notified newer_than:1d');
  threads.forEach(function (thread) {
    const msg = thread.getMessages()[0];
    const text = ':incoming_envelope: 問い合わせが届きました\n'
      + '件名: ' + esc(msg.getSubject()) + '\n'
      + '送信元: ' + esc(msg.getFrom()) + '\n'
      + '受付: ' + Utilities.formatDate(msg.getDate(), 'Asia/Tokyo', 'yyyy-MM-dd HH:mm');
    notifySlack(text);
    thread.addLabel(label);
  });
}

設定の順番は次のとおりです。

  1. 問い合わせを受けるアカウントでGoogleドライブを開き、Apps Scriptのプロジェクトを新しく作る
  2. 上のコードを貼り付けて保存する
  3. 左の「プロジェクトの設定」を開き、「スクリプト プロパティ」に SLACK_WEBHOOK_URL という名前でURLを入れる
  4. エディタで notifyInquiries を選んで1回実行し、GmailとURL呼び出しの許可を出す
  5. 左の「トリガー」から、notifyInquiries を「時間主導型」の「分ベースのタイマー」で5分おきに動くように追加する
Apps Scriptの「プロジェクトの設定」で「スクリプト プロパティ」に SLACK_WEBHOOK_URL を入れたところ（値は伏せる）
Apps Scriptの「プロジェクトの設定」で「スクリプト プロパティ」に SLACK_WEBHOOK_URL を入れたところ（値は伏せる）

URLをコードに直接書かずスクリプト プロパティに置くのは、コードを人に見せたり、別のプロジェクトにコピーしたりしたときにURLが一緒に出回らないようにするためです。

スプレッドシートの更新から送る

案件の管理表で「公開日」の列に日付が入ったら、#team-direction に知らせる例です。スプレッドシートの拡張機能からApps Scriptを開いて書きます。上の notifySlack と esc は同じものを置き、スクリプト プロパティにはこのチャンネル用のURLを入れます。

// インストール型トリガー「編集時」で動かす
function onSheetEdit(e) {
  const sheet = e.range.getSheet();
  if (sheet.getName() !== '案件一覧') return;
  if (e.range.getColumn() !== 6 || e.range.getRow() === 1) return; // F列 = 公開日
  if (!e.value) return;
  const row = e.range.getRow();
  const project = sheet.getRange(row, 2).getValue(); // B列 = 案件名
  notifySlack(':calendar: 公開日が決まりました\n' + esc(project) + ' → ' + esc(e.value));
}

ここで多くの人がつまずくのが、関数名を onEdit にして動かそうとすることです。onEdit のような単純トリガーは、認証が必要なサービス（UrlFetchApp など）を使えないため、外に送れません。トリガーの画面から、イベントの種類を「編集時」にしたインストール型のトリガーを追加して、そちらで onSheetEdit を動かします。

Apps Scriptの「トリガー」で、イベントのソース「スプレッドシートから」、イベントの種類「編集時」を選んでいるところ
Apps Scriptの「トリガー」で、イベントのソース「スプレッドシートから」、イベントの種類「編集時」を選んでいるところ

インストール型のトリガーは、作成した人のアカウントで動きます。追加した人が辞めてアカウントが止まると、通知も止まります。共有のアカウントで作るか、担当が替わるときにトリガーを作り直す手順を一覧表に書いておきます。

Webhook URLの扱い

Webhook URLは、それを知っている人なら誰でもそのチャンネルに投稿できる鍵です。公式も、URLには秘密が含まれていて、漏れた秘密をSlackが探して無効にしていると書いています。公開されたGitHubのリポジトリにURLを書いたまま上げると、ある日突然送れなくなることがあります。

置き場所

置き場所向くか理由
Apps Scriptのスクリプト プロパティ向くコードと分けて置ける
サーバーの環境変数・設定ファイル（リポジトリの外）向くコードと分けて置ける
GitHubのリポジトリのシークレット向くログにも伏せて出る
監視サービスの通知先の設定欄向くそのサービスの中だけで使う
コードの中に直接書く向かないコピーや公開で一緒に出回る
Slackのチャンネルやスプレッドシートに貼る向かない見られる人が多く、残り続ける

サンプルデザインでは、URLそのものは1Passwordのような社内のパスワード管理に入れ、管理の一覧表には「どのアプリの、どのチャンネル向けのURLを、どこに入れたか」だけを書きます。

漏れたとき・作り直すとき

URLが漏れたかもしれないと分かったら、次の順で入れ替えます。

  1. アプリ設定の「Incoming Webhooks」で、同じチャンネルに新しいURLを発行する
  2. 送り元（監視サービス・スクリプト プロパティなど）のURLを新しいものに入れ替える
  3. テストで新しいURLから届くことを確かめる
  4. 古いURLを削除する
  5. 古いURLで送って no_service などのエラーが返ることを確かめる

先に古いURLを消すと、入れ替えるまでの間の通知が落ちます。新しいURLを作ってから古いURLを消す順にします。

ワークフロービルダーのWebhookトリガーとの違い

Slackのワークフロービルダーにも、外からURLに送るとワークフローが始まる「Webhookから」のトリガーがあります。名前が似ていますが、役目が違います。

比べるところIncoming WebhookワークフロービルダーのWebhookトリガー
作る場所開発者向けの設定画面でSlackアプリを作るSlackの中のワークフロービルダー
送ったあとの動き決まったチャンネルにそのまま投稿されるワークフローが始まり、投稿・リストへの追加・DMなどの手順が続く
受け取るJSONtext か blocks の決まった形自分で決めた項目名のJSON（入れ子は送らない）
送り先URLごとに1チャンネルワークフローの手順で決める
向く使い方監視・定時の報告など、そのまま流す通知受け取った値で担当に振る・リストに残すなど、Slackの中で続きがある通知

ワークフロービルダーのWebhookトリガーは、受け取ったJSONの項目をワークフローの変数として使えます。開発者向けの資料にあるWebhookトリガーでは、入れ子のJSONを送るとエラーになると書かれているので、入れ子は送らない形にします。送り元の形を変えられないシステムからの通知を、文に組み立て直して流したいときにも使えます。ワークフロービルダーで作るワークフローは有料プランの機能で、Webhookトリガーの細かい条件（使えるプラン・項目の数の上限）は2026年10月時点のヘルプセンターで確かめてください。作り方はワークフロービルダーの記事で書いています。

上限と、送れないときの確かめ方

上限

公式の上限は、Incoming Webhookで1秒に1件です。短い時間に1件を超えて送ることは許されていますが、続けて送ると制限にかかります。制限を超えると、HTTPの429と、何秒待てば送り直せるかを示す Retry-After が返ってきます。監視のアラートが一斉に出たときや、スプレッドシートで100行をまとめて書き換えたときに起きやすいので、送り元では1件ずつ間をあけるか、まとめて1通にします。

text の長さは、公式では4,000文字までを目安にするよう書かれています。長いログをそのまま流すと読まれないので、要点だけ送ってログの置き場所へのリンクを付けます。

エラーの見方

返ってきたエラー意味直し方
invalid_payloadJSONの形が壊れている括弧・カンマ・ダブルクォートを確かめる。Block Kit Builderで組み直す
no_texttext が入っていないtext を入れる。blocks だけで送らない
no_serviceURLが無効・削除済み一覧にURLがあるか確かめ、無ければ作り直す
no_active_hooksWebhookが無効になっている「Activate Incoming Webhooks」がオンか確かめる
channel_is_archived送り先がアーカイブ済みチャンネルを戻すか、新しいチャンネルでURLを作り直す
channel_not_found送り先のチャンネルが無いチャンネルを消していないか確かめ、作り直す
action_prohibited管理者が投稿を制限している送り直さず、チャンネルの投稿権限を確かめる
posting_to_general_channel_denied全員のチャンネルへの投稿が制限され、URLを作った人に権限が無い通知専用のチャンネルに送り先を変える
too_many_attachments添付が100を超えている件数を減らす
team_disabledワークスペースが使えない状態ワークスペースの状態を管理者に確かめる

確かめる順番は、1つ目にcurlで同じURLへ {"text":"test"} を送ること、2つ目に送り元が実際に送っているJSONを記録して見ることです。curlで届くのに送り元から届かないなら、送り元のJSONか送り方（Content-type の指定漏れなど）が原因です。curlでも届かないなら、URLかSlack側の設定が原因です。

アプリ設定の「Incoming Webhooks」の一覧で、URLごとの送り先チャンネルが分かる欄
アプリ設定の「Incoming Webhooks」の一覧で、URLごとの送り先チャンネルが分かる欄

応用

通知の量を絞る

自動の通知は、増やすより絞るほうが難しくなります。実際に運用していると、復旧の通知・警告レベルの通知・定時の「正常です」の通知まで全部流して、1週間で誰も #log-サーバー監視 を開かなくなる、ということが起きます。異常と復旧だけを流し、警告は1日1回のまとめにすると、通知を見る習慣が残ります。チャンネルの通知設定は、#log- は「メンションのみ」にして、ユーザーグループで呼ばれたときだけ鳴るようにします。

通知をスレッドにまとめたい

同じ障害の「検知」と「復旧」を1つのスレッドにまとめたい、という要望はよく出ます。スレッドに返信するには元のメッセージの ts（メッセージを特定する値）が要りますが、Incoming Webhookは送ったあとに ts を返しません。公式も、ts が要るならEvents APIや conversations.history で取るよう書いています。ここまでやりたくなったら、Webhookをやめて chat.postMessage で送るbotに切り替えるほうが早く済みます。

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

できないこと代わりの手
送るたびにチャンネルを変えるチャンネルごとにURLを発行する。多いならbotの chat.postMessage
送り主の名前・アイコンを送るときに変えるアプリを分ける。botなら追加のスコープで変えられる
送ったメッセージを消す・書き換えるbotの chat.postMessage と chat.update
スレッドに返信を重ねるbotで送り、返ってきた ts を使う
ボタンを押した結果を受け取るSlackアプリでインタラクティブな受け口を作る
決まった形以外のJSONを受けるワークフロービルダーのWebhookトリガーかn8nで組み立て直す
通知を記録・集計する台帳はkintoneやスプレッドシートに残し、Slackには知らせだけを送る

Slackは流れる場所なので、問い合わせの対応状況や障害の記録を長く残す台帳には向きません。問い合わせの件数や対応の進み具合を追いたいなら、kintoneやスプレッドシートに記録を残し、Slackには「届いた」「担当が決まった」の知らせだけを送る形にします。業務システムとつなぐ方法はkintone・Salesforce・n8nの連携の記事で書いています。

よく詰まるところ

症状原因直し方
送り先にプライベートチャンネルが出てこない作る人がそのチャンネルに入っていないチャンネルに参加してから「Add New Webhook to Workspace」をやり直す
「Authorize」のあとURLが出ないアプリのインストールに管理者の承認が要る設定管理者に承認してもらう
@デザイナーB と書いても通知されない名前の文字ではメンションにならない<@U0000000000> の形でIDを書く
メールの送信元が途中で消えて表示される< > を書き換えていない& < > を書き換えてから送る
Block Kitで送ると通知に何も出ないtext を入れていないblocks と一緒に text を入れる
Apps Scriptの onEdit から送れない単純トリガーは認証が必要なサービス（UrlFetchApp など）を使えないインストール型の「編集時」トリガーで動かす
ある日から急に送れない・no_serviceURLが削除された・漏れて無効にされた一覧を確かめ、新しいURLを作って入れ替える
担当が辞めたあと通知が止まったトリガーやURLがその人に結びついていた共同管理者を置き、一覧表で持ち主を管理して作り直す
監視サービスから送ると no_textサービスが決めた形のJSONしか送れないSlack用の連携を使うか、ワークフロービルダーのWebhookトリガーで受ける
まとめて送ると一部が落ちる・4291秒1件の上限を超えた送り元で間をあけるか、まとめて1通にする
Windowsのcurlで invalid_payloadシングルクォートが効かないPowerShellで送るか、エスケープを直す
送り元から届かないときに curl で同じURLへ送ってエラー名が返ってきているターミナル
送り元から届かないときに curl で同じURLへ送ってエラー名が返ってきているターミナル

次にやること

Webhookで「知らせる」ができたら、次は知らせたあとの動きを決めます。通知に対してボタンで担当を決めたい、スレッドにまとめたいなら、Slack APIとbotの作り方：Slackアプリを作ってメッセージを送る・受け取るに進みます。受け取った値で担当に振り分けたり、リストに残したりしたいなら、Slackのワークフロービルダー：作り方と、日報・申請・問い合わせ受付の例が近道です。案件の管理表をkintoneに移したあとの通知や承認は、Slackとkintone・Salesforce・n8nの連携：業務システムの通知と承認をつなぐで書いています。GoogleカレンダーやGitHubのように、公式のSlack連携があるサービスはWebhookを自作せず、Slackのアプリ連携：Googleカレンダー・Googleドライブ・GitHubをつなぐの手順でつなぐほうが手間がかかりません。

あわせて読む

画面に出てくる言葉の意味はSlack用語集で引けます。